Alpha 事後諸葛亮（團隊）

alpha衝刺，很多同學經歷了「learning by doing」的學一門新的程式語言、學git、學做乙個完整的專案。但是，各組對於軟體工程的「learning by doing」的意涵了解的還不深刻，遇到的問題也不少。停一停，開個總結會，來次事後諸葛亮，為了下一步走的更好。請各小組在deadline之前，以小組為單位發布一篇針對問題的總結。總結的提綱內容，請參照鄒欣老師的部落格：專案管理之事後諸葛亮會議

我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

我們達到目標了麼（原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?)?

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

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

是否有充足的時間來做計畫?

團隊在計畫階段是如何解決同事們對於計畫的不同意見的？

你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?

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

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

是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

在計畫中有沒有留下緩衝區，緩衝區有作用麼?

將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）

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

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

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

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

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

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

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

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

專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?

對於可能的變更是否能制定應急計畫?

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

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

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

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

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

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

**複審（code review）是如何進行的，是否嚴格執行了**規範？

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

團隊是否有乙個測試計畫？為什麼沒有？

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

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

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

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

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

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

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

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

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

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

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

你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?

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

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

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

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

繼續更新自己的學習進度條，參考：

Alpha 事後諸葛亮（團隊）

Alpha 事後諸葛亮（團隊）

Alpha 事後諸葛亮（團隊）

Alpha 事後諸葛亮（團隊）

相關推薦