我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
答：我們《雪人兄弟2019》是一款懷舊遊戲，主要目的在於喚起使用者童年記憶的同時在遊戲中加入我們的獨特風格，讓玩家感到更加地愉悅和舒心。
我們達到目標了麼（原計畫的功能做到了幾個？ 按照原計畫交付時間交付了麼？ 原計畫達到的使用者數量達到了麼?)?
答：原計畫是做到遊戲地圖的建立和遊戲人物的建立和順暢移動這裡，到目前為止，完成的功能有 ：
1，實現了雪人的基本功能例如跳躍，移動打怪
2，遊戲基本布局頁面的實現，
3，實現本地雙人聯機
並且按原計畫按時交付了。但是由於我們的遊戲尚未完成，因此除了我們這些開發人員，使用者數量幾乎為零，不過仍在計畫的預料之中。
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
答：是的
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
答：經驗教訓：計畫應考慮到各種因素，設計出合理的計畫。
是否有充足的時間來做計畫?
答：由於近期課程考試和各種實驗，導致專案時間有些緊迫，故沒有太充足的時間去計畫。
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
答：線下開會以及qq群線上討論和投票
你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
答：基本都完成了，沒完成的任務主要還是時間緊。
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
是否每一項任務都有清楚定義和衡量的交付件?
答：是的。
是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
答：專案整體依舊還是按照計畫走的，專案目前未出現意外，風險也在可控範圍之內。
在計畫中有沒有留下緩衝區，緩衝區有作用麼?
答：有，因為時間緊，大部分時間都留給了**學習和具體實現，正是緩衝區的存在使得我們的**測試有了充裕的時間。
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
答：暫時沒有修改的打算。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：學到了一些遊戲引擎的使用以及遊戲介面的設計，若是能重來一遍，我們將採取更為合理的時間規劃來完成計畫。
我們有足夠的資源來完成各項任務麼?
答：我們組共11人，因此人力還是充足的，而研發遊戲的引擎和相應知識也可以從網上獲得，總的來說資源並不緊張。
各項任務所需的時間和其他資源是如何估計的，精度如何?
測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
你有沒有感到你做的事情可以讓別人來做（更有效率）?
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
答：暫無。
每個相關的員工都及時知道了變更的訊息?
答：通過qq通知，每個成員都能及時了解專案的情況和變更。
我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
答：對所有要實現的功能進行優先順序排序，再確定對現階段而言優先順序更高的功能。
專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
答：遊戲人物與怪物行動邏輯確定且流暢，遊戲介面友好。
對於可能的變更是否能制定應急計畫?
答：能。
員工是否能夠有效地處理意料之外的工作請求
答：對於突發情況，我們小組成員都是比較積極的，誰手頭沒有很急的任務，且能夠解決突發情況，就會主動承擔下。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：及時通知組員專案變更情況可以避免許多多餘的設計和測試。
設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
答：alpha階段的設計工作是在alpha階段初期，團隊成員開會共同討論完成的。
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
答：沒有。
團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
答：是的，使用這些測試工具可以使我們的專案明確了實現方向以及優化方向。
比較專案開始的 uml 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 uml 文件？
答：暫無區別。
什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
**複審（code review）是如何進行的，是否嚴格執行了**規範？
答：通過檢查**是否符合需求和規格說明，以及**的可讀性和易維護性進行**複審。是的。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：無。
團隊是否有乙個測試計畫？為什麼沒有？
是否進行了正式的驗收測試？
答：沒有，因為現在的專案的功能太簡陋了，暫時無法進行測試。尚未。
團隊是否有測試工具來幫助測試？
答：還未考慮。
團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
答：目前依舊是通過目測。
在發布的過程中發現了哪些意外問題？
答：沒有發現重大的意外。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：無。
團隊的每個角色是如何確定的，是不是人盡其才？
答：群裡分工採用自願原則，每個角色都是各自選擇的。
團隊成員之間有互相幫助麼？
答：有。
當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的部落格裡）：
我感謝 趙鎮 對我的幫助， 因為某個具體的事情:他在團隊裡起到了很大的作用，他負責與每個人溝通，安排並指導他們做事，而且在**上給了我很大幫助，提供了很多思路，並且幫我找到了很多bug，特別是就在今天的乙個難以置信的vs的bug。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
答：自願原則使得組員的積極性可以得到保證。
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
答：初始級。
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
答：磨合階段。
你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
答：大家都有用心去完成各自的工作了。
你覺得目前最需要改進的乙個方面是什麼?
答：時間管理。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
答：可以經常性的交付可以執行的軟體----隔一段時間便交付實現的遊戲軟體
? 以工作得到軟體作為首要的進度衡量標準----以階段性完成的遊戲軟體作為進度的體現
第02組 Alpha事後諸葛亮
目錄3.答辯總結 6分 4.全組討論的 1分 5.psp與學習進度條 4分 我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?有什麼經驗教訓?如果歷史重來一遍,我們會做...
第02組 Alpha事後諸葛亮
目錄3.答辯總結 6分 4.全組討論的 1分 5.psp與學習進度條 4分 我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?使用者量,使用者對重要功能的接受程度和我們事先的預想一致麼?我們離目標更近了麼?有什麼經驗教訓?如果歷史重來一遍,我們會做...
第02組 Alpha事後諸葛亮
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 我們 雪人兄弟2019 是一款懷舊遊戲，主要目的在於喚起使用者童年記憶的同時在遊戲中加入我們的獨特風格，讓玩家感到更加地愉悅和舒心。我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到...