班級：軟件工程1916|W
作業：事后諸葛亮（團隊）
團隊名稱：Echo
作業目標：完成Alpha沖刺的事后諸葛亮

目錄

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

設想和目標

1、 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

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

• 對于定義，我們覺得很清楚。

• 對于用戶和場景，我們也做了較詳細的描述。

2、 我們達到目標了么（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？ 原計劃達到的用戶數量達到了么?)

基本達到，詳見總結隨筆

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

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

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

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

5、 有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?

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

計劃

1、 是否有充足的時間來做計劃?

我們在alpha沖刺前就完成了計劃，所以是有充足的時間來做計劃的

2、 團隊在計劃階段是如何解決同事們對于計劃的不同意見的？

我們如果出現不同意見，主要采用了集體討論的方式，在每天的會議中提出并討論審議。

3、 原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?

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

4、 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?

沒有

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

是的，基本都有

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

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

7、 在計劃中有沒有留下緩沖區，緩沖區有作用么?

有的，我們提前預留出了時間給對接工作

8、 將來的計劃會做什么修改？（例如：緩沖區的定義，加班）

因為我們的得力干將kwm被迫換組，后續的管理端計劃可能會根據具體情況稍作修改。

9、 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

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

資源

1、 我們有足夠的資源來完成各項任務么?

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

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

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

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

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

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

我們團隊成員都是按照自己能力來分配任務，所以似乎沒有出現這樣的情況。

5、 有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?

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

變更管理

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

因為每天都會開會，有什么問題也會在群里討論，所以消息傳遞效率還是有保證的。

2、 我們采用了什么辦法決定“推遲”和“必須實現”的功能?

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

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

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

4、 對于可能的變更是否能制定應急計劃?

基本沒有。

5、 是否能夠有效地處理意料之外的工作請求？

沒碰到意料之外的工作請求。

6、 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

• 目前除了在alpha階段后kwm被迫換組，沒有遇到什么變更情況
• 如果在重來一遍，可能就是會提前做好這種換人的準備吧

設計/實現

1、 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？

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

2、 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

沒有碰到模棱兩可的情況，一般一起討論后就會有結果。

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

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

4、 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?

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

5、 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？

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

6、 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

• 代碼規范很重要
• 如果重來一遍，我們會強制給每個人的idea上裝上阿里巴巴的插件

測試/發布

1、 團隊是否有一個測試計劃？為什么沒有？

有。

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

還沒有到驗收階段

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

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

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

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

5、 在發布的過程中發現了哪些意外問題？

沒有遇到問題

6、 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

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

團隊的角色，管理，合作

1、 團隊的每個角色是如何確定的，是不是人盡其才？

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

2、 團隊成員之間有互相幫助么？

有。

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

還未出現過這樣的問題。

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

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

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

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

• 李東權
  感謝kwm對我的幫助，即使離開團隊，也能超額完美的完成團隊安排的前端任務，并且能正常與我的后端相對接，合作愉快

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

總結

1、 你覺得團隊目前的狀態屬于 CMM/CMMI 中的哪個檔次?

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

2、 你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段?

我覺得我們到了磨合期，正在邁向規范期。

3、 你覺得目前最需要改進的一個方面是什么?

我覺得目前最需要改進的方面是前端和后端之間報錯信息的統一。

照片

組員交接工作及方案

熟悉項目：查看alpha沖刺前的需求文檔、設計文檔等

熟悉開發內容：查看API相關文檔、前端代碼相關說明等

開始接手前端開發工作

轉載于:https://www.cnblogs.com/magicNumber/p/10820082.html

總結

以上是生活随笔為你收集整理的事后诸葛亮（团队）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。