Alpha 事後諸葛亮（團隊）

Deadline：2017年11月19日 22：00

送出： 1篇問題總結随筆，組内可共享，要求每位組員一份。

Alpha沖刺，很多同學經曆了“Learning by doing”的學一門新的程式設計語言、學Git、學做一個完整的項目。但是，各組對于軟體工程的“Learning by doing”的意涵了解的還不深刻，遇到的問題也不少。停一停，開個總結會，來次事後諸葛亮，為了下一步走的更好。請各小組在Deadline之前，以小組為機關釋出一篇針對問題的總結。總結的提綱内容，請參照鄒欣老師的部落格：項目管理之事後諸葛亮會議

鄒欣老師的模闆引用：

現代軟體工程 項目Postmortem 模闆

設想和目标

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
2. 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?

3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?

   有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?

計劃

1. 是否有充足的時間來做計劃?
2. 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
5. 是否每一項任務都有清楚定義和衡量的傳遞件?
6. 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
7. 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
8. 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）

我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?

資源

1. 我們有足夠的資源來完成各項任務麼?
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
4. 你有沒有感到你做的事情可以讓别人來做（更有效率）?

變更管理

1. 每個相關的員工都及時知道了變更的消息?
2. 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
3. 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
4. 對于可能的變更是否能制定應急計劃?
5. 員工是否能夠有效地處理意料之外的工作請求？

設計/實作

1. 設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
4. 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
5. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？
2. 是否進行了正式的驗收測試？
3. 團隊是否有測試工具來幫助測試？
4. 團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
5. 在釋出的過程中發現了哪些意外問題？

團隊的角色，管理，合作

1. 團隊的每個角色是如何确定的，是不是人盡其才？
2. 團隊成員之間有互相幫助麼？
3. 當出現項目管理、合作方面的問題時，團隊成員如何解決問題？

每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：

我感謝 _______<姓名>______對我的幫助， 因為某個具體的事情: _____________________。

總結:

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

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

你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?

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

對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

部落格要附上全組讨論的照片。

繼續更新自己的學習進度條，參考：http://www.cnblogs.com/vertextao/p/7469789.html