過後諸葛亮（團隊）

班級：軟件工程1916|W
做業：過後諸葛亮（團隊）
團隊名稱：Echo
做業目標：完成Alpha衝刺的過後諸葛亮

目錄

• 設想和目標
• 計劃
• 資源
• 變動管理
• 設計/實現
• 測試/發佈
• 團隊的角色，管理，合做
• 總結
• 照片
• 組員交接工做及方案

設想和目標

一、 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

• 咱們的軟件主要針對福州大學的物業管理，用於解決目前福大物業消息通知不及時、水電繳費麻煩的痛點。

• 對於定義，咱們以爲很清楚。

• 對於用戶和場景，咱們也作了較詳細的描述。

二、 咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

基本達到，詳見總結隨筆

三、 和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

上一階段主要都在作設計、需求這塊，若是硬要說提升，那就是有產品成果了。

四、 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

還沒推廣，暫時沒考慮用戶量

五、 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

在實現過程當中沒有出現大問題，但若是歷史重來一遍，咱們會將文檔等寫的更加詳細一些。

計劃

一、 是否有充足的時間來作計劃?

咱們在alpha衝刺前就完成了計劃，因此是有充足的時間來作計劃的

二、 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

咱們若是出現不一樣意見，主要採用了集體討論的方式，在天天的會議中提出並討論審議。

三、 原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

沒有所有作完，物業管理端的繳費信息導入、人員導入都還沒作，主要是由於時間以及對文件讀取不熟。

四、 有沒有發現你作了一些過後看來不必或沒多大價值的事?

沒有

五、 是否每一項任務都有清楚定義和衡量的交付件?

是的，基本都有

六、 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

總體上按照計劃有序推動，沒有什麼大的意外。主要遇到的問題是在先後端對接時發現了一些bug。在一開始就有估計到會出這些bug了。

七、 在計劃中有沒有留下緩衝區，緩衝區有做用麼?

有的，咱們提早預留出了時間給對接工做

八、 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

由於咱們的得力干將kwm被迫換組，後續的管理端計劃可能會根據具體狀況稍做修改。

九、 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 學會了如何進行團隊協做，以及如何更加合理的安排時間。
• 若是再重來一遍，咱們應該仍是會按照原來的計劃走。

資源

一、 咱們有足夠的資源來完成各項任務麼?

有的，前端後端以及測試用的工具都比較成熟，有大量的學習資源。

二、 各項任務所需的時間和其餘資源是如何估計的，精度如何?

首先肯定咱們的任務，再根據任務難度和任務類型分配以及每一個人想要的發展方向，給每一個人分配任務，最後肯定每一個任務的完成時間。

三、 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?

• 人力、軟件資源充足，硬件上，因爲是使用騰訊雲的學生機，因此配置較低
• 美工等資源，因爲在前期原型設計的時候已經較爲完善，因此也沒有什麼問題

四、 你有沒有感到你作的事情可讓別人來作（更有效率）?

咱們團隊成員都是按照本身能力來分配任務，因此彷佛沒有出現這樣的狀況。

五、 有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

• 團隊之間要多多交流，尤爲是遇到問題的時候，可能其餘人那就有好的解法。
• 若是再重來一次，咱們仍是會繼續好好利用這些資源的

變動管理

一、 每一個相關的員工都及時知道了變動的消息?

由於天天都會開會，有什麼問題也會在羣裏討論，因此消息傳遞效率仍是有保證的。

二、 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

經過開會討論共同商議決定的。

三、 項目的出口條件（Exit Criteria）是否獲得清晰的定義?

在需求報告裏的性能、界面需求等模塊中有比較清晰的定義。

四、 對於可能的變動是否能制定應急計劃?

基本沒有。

五、 是否可以有效地處理意料以外的工做請求？

沒碰到意料以外的工做請求。

六、 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 目前除了在alpha階段後kwm被迫換組，沒有遇到什麼變動狀況
• 若是在重來一遍，可能就是會提早作好這種換人的準備吧

設計/實現

一、 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

設計工做在一開始的選題及原型設計的時候就完成了，由團隊全部人員共同參與完成，是合適的人和合適的時間。

二、 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

沒有碰到模棱兩可的狀況，通常一塊兒討論後就會有結果。

三、 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

• 團隊運用了單元測試、UML等工具幫助實現。
• 有效。單元測試有效地幫助測試了每一個類的debug，uml幫助咱們理清用戶、需求、系統功能單元之間的關係。
• uml文檔暫時尚未區別。
• 可能須要完善下uml文檔。

四、 什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

• 在報修投訴模塊的bug最多，主要是一些邊界條件沒考慮清楚
• 發佈以後，發現有的報錯信息未處理，直接提示給用戶，不夠友好。由於時間比較趕，沒有注意到這些方方面面

五、 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

• 代碼複審由隊員隨機抽查github上的代碼的格式、風格、命名是否符合規範。
• 除了管理員後端外，嚴格執行了代碼規範。

六、 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 代碼規範很重要
• 若是重來一遍，咱們會強制給每一個人的idea上裝上阿里巴巴的插件

測試/發佈

一、 團隊是否有一個測試計劃？爲何沒有？

有。

二、 是否進行了正式的驗收測試？

尚未到驗收階段

三、 團隊是否有測試工具來幫助測試？

有，使用了Junit和Robot Framework等工具進行測試

四、 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

還未進行軟件的效能測試。

五、 在發佈的過程當中發現了哪些意外問題？

沒有遇到問題

六、 咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 咱們學到了測試的重要性。
• 若是歷史重來一遍，咱們會花更多一些的時間在學習自動化測試上。

團隊的角色，管理，合做

一、 團隊的每一個角色是如何肯定的，是否是人盡其才？

團隊的角色是根據團隊成員各自選擇喜歡或熟悉的方向肯定的。有作到人盡其才。

二、 團隊成員之間有互相幫助麼？

有。

三、 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

還未出現過這樣的問題。

四、 每一個成員明確公開地表示對成員幫助的感謝 （而且寫在各自的博客裏）：

• 黃少勇
  感謝kwm在我完成任務過程當中給予的幫助，即便被迫離開團隊，也要繼續指導我完成團隊佈置任務

• 黃種鑫
  感謝kwm在前端給個人幫助，雖然小程序開發和web開發有必定的差異，可是框架的一些思想仍是相同的，kwm對於我對框架的理解有了進一步加深

• 孔偉民
  感謝kwm對個人幫助（你問kwm是誰？我不懂別問我我不知道），他在我玩手機的時候叫我起來幹活，在我遇到問題的時候幫我百度...即便離開團隊，也身在曹營心在漢。

• 李東權
  感謝kwm對個人幫助，即便離開團隊，也能超額完美的完成團隊安排的前端任務，而且能正常與個人後端相對接，合做愉快

• 林弘傑
  感謝kwm對個人幫助，在進行接口對接時及時發現了問題，對我進行反饋，讓我發現了我測試腳本的不足

總結

一、 你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

我以爲團隊目前的狀態屬於成熟度級別2 － 已管理，正在邁向級別3

二、 你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

我以爲咱們到了磨合期，正在邁向規範期。

三、 你以爲目前最須要改進的一個方面是什麼?

我以爲目前最須要改進的方面是前端和後端之間報錯信息的統一。

照片

組員交接工做及方案

1. 熟悉項目：查看alpha衝刺前的需求文檔、設計文檔等
2. 熟悉開發內容：查看API相關文檔、前端代碼相關說明等
3. 開始接手前端開發工做