| 這個作業屬於哪個課程 | 班級的連結 |
|---|---|
| 這個作業要求在哪裡 | 作業要求的連結 |
| 這個作業的目標 | 召開事後諸葛亮會議，釋出一篇事後分析報告 |
團隊會議圖:
一、設想和目標
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？軟體目標：開發一款魔塔遊戲，旨在提供豐富的遊戲體驗，吸引廣大玩家。這個問題定義得非常清楚。典型使用者為魔塔遊戲玩家，典型場景就是魔塔遊戲的畫面。
2. 我們達到目標了嗎？
目標完成90%，遊戲玩法達到預期目標，但是由於時間問題，遊戲地圖設計略少，遊玩時間較短。
3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
使用者量未達到預期目標，但較為接近。使用者對重要功能的接受程度和我們事先的預想一致。我們離目標十分接近。
4. 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
首先應明確整個開發過程大體要實現那些功能，那些功能可能會加入，在程式碼框架設計之初為需要的功能留下擴充套件空間，在後續新增新功能時不僅程式碼效率更高，還能減少bug的出現。
二、計劃
1. 是否有充足的時間來做計劃?是。
2. 團隊在計劃階段是如何解決成員們對於計劃的不同意見的？
透過討論，提問，綜合成員意見。
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
原計劃的工作未全部完成。在開發的過程中學習新技術來時間遊戲玩法佔了大量時間，遊戲地圖美工和數量未達到原計劃。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
沒有。
5. 是否每一項任務都有清楚定義和衡量的交付件?
是，對每項任務進行緊迫程度的評級，能讓我們能夠優先完成更重要的任務。
6. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
沒有完美的按照計劃進行，在開發的過程總是遇到各種問題。對開發難度低估，由於技術不夠熟練總是出現奇奇怪怪的bug浪費時間。
7. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
有，為遊戲開發預留緩衝時間來任務不那麼緊迫。緩衝區在一定程度上緩解了專案壓力
三、資源
1. 我們有足夠的資源來完成各項任務麼?有。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
由於課程任務多不能專注於軟體開發，精度比較模糊,
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
足夠。沒有低估美工設計/文案難度，開始就在準備但是由於經驗問題仍有不足。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
沒有,成員選擇的工作均是各自最擅長的。
四、變更管理
1. 每個相關的員工都及時知道了變更的訊息?在發生變更時，團隊內部透過微信群溝通來確保每個相關的隊員都能及時知道變更的訊息。
2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
我們可能採用了基於優先順序、影響評估、實現難度等多種因素的綜合考慮來決定“推遲”和“必須實現”的功能。
3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
我們在專案開始前可能已經對出口條件進行了明確的定義，以確保專案能夠按照預定的目標和質量標準完成。
4. 對於可能的變更是否能制定應急計劃?
沒有制定應急計劃，團隊內開發人員都具有一定應變能力來應對可能的變更。
5. 員工是否能夠有效地處理意料之外的工作請求？
能。有時候臨時出現新的事物,成員能透過自學來了解新事物。
五、設計/實現
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？由隊長在專案開始之前完成，是。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
沒有。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
沒有。
4. 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
人物移動和互動產生的BUG最多，因為人物時遊戲操作的主體，幾乎所有功能都要對人物進行相關操作。釋出後發現連續點選小機率導致人物位移超出預期設定導致遊戲崩潰。設計時沒考慮到人物移動可能存在檢測丟失，導致出現一次兩格的位移。
5. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
由於程式碼全部都是隊長完成編寫，其一人進行程式碼複審，嚴格執行了程式碼規範，
六、測試/釋出
1. 團隊是否有一個測試計劃？為什麼沒有？有測試計劃。
2. 是否進行了正式的驗收測試？
是的，針對各項功能都進行了測試。
3. 團隊是否有測試工具來幫助測試？
用godot本身進行測試，透過多人遊玩遊戲來測試遊戲bug。
4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
在alpha版本完成後，對遊戲的各個模組進行測試，且每個隊員都遊玩一次遊戲。最後的執行結果證明了測試工作還是有用的，發現了一些之前沒發現的潛在問題。
5. 在釋出的過程中發現了哪些意外問題？
沒有意外問題。
七、總結
1.你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?磨合階段，各成員分工明確，都能積極的去完成自己的任務,但成員之間缺少交流。
2.你覺得目前最需要改進的一個方面是什麼?
團隊應多面對面交流,增強團隊凝聚力和互動性。
八、團隊成員在Alpha階段的角色和具體貢獻
| 名字 | 角色 | 團隊貢獻分 | 可驗證的貢獻 |
|---|---|---|---|
| 梁志聰 | PM和dev | 50 | 遊戲整體框架設計，各模組相關程式碼的編寫，修復bug，修改部落格初稿 |
| 李永傑 | test | 35 | 地圖設計，劇情設計，bug檢測，大部分部落格編寫初稿 |
| 曾繁曦 | dev | 15 | 遊戲素材尋找，專案複審 |