團隊作業6--復審與事后分析

一、 Alpha階段項目復審

二、事后諸葛亮分析

一、會議照片

二、設想和目標

1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
   • 我們的軟件社團宣傳、報名招新、審核招新中存在的各種問題，有效拓展新生入學后的信息來源渠道、提升社團報名人數，有效降低社團宣傳成本，并提高社團招新活動的效率。
   • 定義清楚。
   • 對典型用戶和典型場景有清晰的描述。詳情可見《需求規格說明書》
2. 是否有充足的時間來做計劃?
   • 有
3. 團隊在計劃階段是如何解決同事們對于計劃的不同意見的？
   • 通過開線上會議進行討論，最后已少數服從多數進行決定。

三、計劃

1. 你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?
   • 基本上都做完了。
2. 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
   • 沒有，有計劃的開始做的事都是有必要的。
3. 是否每一項任務都有清楚定義和衡量的交付件?
   • 是的，必須經過測試沒有bug并且能流暢使用。
4. 是否項目的整個過程都按照計劃進行?
   • 是，因為團隊分工明確。
5. 在計劃中有沒有留下緩沖區，緩沖區有作用么?
   • 沒有，時間緊任務重，我們只計劃了必要功能。
6. 將來的計劃會做什么修改？（例如：緩沖區的定義，加班）
   • 繼續完善，根據實際使用情況改善項目。

四、資源

1. 我們有足夠的資源來完成各項任務么?
   • 有，分別是人力，物力和時間資源。
   • 人力資源：團隊共五人，能夠各司其職完成對應項目模塊。
   • 物力資源：團隊成員每人一臺電腦，并擁有一個微信小程序開發者賬號。
   • 時間資源：團隊成員從繁重的學習任務中抽出時間，保證每天有兩個小時以上的時間進行開發。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
   • 由小組的PM（產品經理）進行需求分析并估計各項任務所需的時間和其他資源。
   • 精度沒有具體統計過。
3. 用戶測試的時間，人力和軟件/硬件資源是否足夠?
   • 足夠
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
   • 沒有，每個人的工作都是由PM根據對每個人的了解以及結合一定的依據分配的，保證了效率最大化。

五、變更管理

1. 每個相關的員工都及時知道了變更的消息?
   • 由于大家是同班同學并且可以通過騰訊會議/微信群及時發布和接收變更消息。
2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能?
   • 通過線上會議對功能的必要程度以及實現的難易程度進行分析，判斷該功能的“性價比”來決定。
3. 項目的出口條件（Exit Criteria）是否得到清晰的定義?
   • 是，詳情可見《測試報告》
4. 對于可能的變更是否能制定應急計劃?
   • 能，根據團隊成員所學領域制定應對辦法。
5. 員工是否能夠有效地處理意料之外的工作請求？
   • 能，但是基本上沒有其他意料之外的工作請求。

六、設計/實現

1. 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
   • 由PL完成，在適合的時間完成，是適合的人。
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
   • 有，少數服從多數。
3. 什么功能產生的Bug最多，為什么？
   • 注冊功能產生的bug最多，因為團隊成員沒有做過這一功能，經驗不足。
4. 代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
   • 團隊成員對除自己外的代碼進行審核，嚴格執行了代碼規范。

七、測試/發布

1. 團隊是否有一個測試計劃？為什么沒有？
   • 有。
2. 是否進行了正式的驗收測試？
   • 是。
3. 團隊是否有測試工具來幫助測試？

• 沒有。

4. 團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
   • 通過對后臺的日志對軟件的效能進行跟蹤。
   • 通過試用用戶的反饋進行跟蹤。
5. 在發布的過程中發現了哪些意外問題？
   • 無。

八、總結

1. 你覺得團隊目前的狀態屬于 CMM/CMMI 中的哪個檔次？
   • CMMI二級，管理級。
2. 你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段?
   • 磨合階段。
3. 你覺得目前最需要改進的一個方面是什么?
   • 團隊提高效率，不拖延。

九、團隊成員在Alpha階段的角色和具體貢獻