Alpha 事後諸葛亮（團隊）

設想和目标

• 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
• A：我們制作一款能夠讓人們利用碎片時間來放松的遊戲。遊戲流程短，工作或學習中的短暫休息時間可以打開我們制作的遊戲遊玩放松。
• 2.我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?
• A：原計劃将所有基礎功能全部完成，但是由于能力和時間問題隻完成了遊戲人物基本的行走，打擊動作兩個功能。
• 3.使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
• A：遊戲未完成暫無使用者。

• 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
• A：未實作了解清楚開發工具。重來的話會先了解好開發工具的實用性以及是否有足夠充足的資料教程供我們學習。

計劃

• 1.是否有充足的時間來做計劃?
• A：不算非常充足但有做一定的計劃。
• 2.團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
• A：投票決定。
• 3.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
• A：沒做完。能力的問題，以及沒有充足的時間。
• 4.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
• A：花了一天時間在cocos2d上學習以及瓦片地圖的制作。
• 5.是否每一項任務都有清楚定義和衡量的傳遞件?
• A：每項任務都有明确要實作的功能。
• 6.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
• A：并沒按照計劃進行。主要是進展緩慢，學習和開發一款遊戲比想象中困難許多。
• 7.在計劃中有沒有留下緩沖區，緩沖區有作用麼?
• A：alpha階段暫無。
• 8.将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
• A：加快程序，多花時間，争取趕上原來的計劃。

• 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
• A：學到了制作一個好計劃的重要性。重來的話花更多的時間來做一個更好的計劃。

資源

• 1.我們有足夠的資源來完成各項任務麼?
• A：有
• 2.各項任務所需的時間和其他資源是如何估計的，精度如何?
• A：第一次做對所需時間的把控不到位，也不清楚大概需要的時間，隻能在有限的時間裡平均配置設定。
• 3.測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
• A：測試的時間不足。低估了不需要程式設計的資源難度。
• 4.你有沒有感到你做的事情可以讓别人來做（更有效率）?
• A：在我們組的工作配置設定裡暫時沒有。

• A：應該更重視不需要程式設計的資源。

變更管理

• 1.每個相關的員工都及時知道了變更的消息?
• A：能及時知道。
• 2.我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
• A：組内進行讨論達成一緻，遊戲的基礎功能必須實作，劇情及額外的推遲。
• 3.項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
• A：不是特别清晰，暫時的定義是将各個基礎功能做完，加上完整的劇情。
• 4.對于可能的變更是否能制定應急計劃?
• A：沒有制定。
• 5.員工是否能夠有效地處理意料之外的工作請求？
• A：并不能很有效的處理。

• A：制定應急計劃，以及對項目的出口條件更清晰的定義。

設計/實作

• 1.設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
• A：項目開始的時候由組長完成。
• 2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
• A：有，因為我們碰到這種情況的工作量比較少，通過讨論将差不多的工作劃分到一塊由一人完成
• 3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
• A：有通過UML來幫助設計，但未更新，沒有充分利用這些工具
• 4.什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
• A：人物的動作功能，因為這塊的代碼複雜，需要對人物模型每一塊進行分解分别編碼。Alpha釋出後暫時沒有發現bug，後續還有很多功能未加入。在設計的時候并不了解人物模型動作的編碼是以沒有想到。
• 5.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
• A：沒有進行代碼複審，因為使用的工具相同，有自動縮進等功能，函數等命名上盡量使用英文。

• A：更多更有效地借助第三問裡的工具來設計和實作。

測試/釋出

• 1.團隊是否有一個測試計劃？為什麼沒有？
• A：沒有制定，因為Alpha階段是先把遊戲的基礎功能實作，内部測試能實作即可。
• 2.是否進行了正式的驗收測試？
• A：有進行驗收測試。
• 3.團隊是否有測試工具來幫助測試？
• A：由Unity3D生産.exe檔案直接進行遊戲測試
• 4.團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
• A：并沒有做到問題中提到的事。
• 5.在釋出的過程中發現了哪些意外問題？
• A：在Alpha階段的展示中沒出現意外。

• A：應該制定一個細緻的測試計劃。

團隊的角色，管理，合作

• 1.團隊的每個角色是如何确定的，是不是人盡其才？
• A：團隊裡有擅長文案的來寫部落格，編碼上來說都是新手，算是人盡其才。
• 2.團隊成員之間有互相幫助麼？
• A：有。
• 3.當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
• 進行協商讨論，無法解決最後進行組内投票。

• 每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
• 我感謝峻雄對我的幫助， 因為某個具體的事情: 初期原打算制作瓦片地圖遊戲時，幫忙解決在網頁上無法運作的問題。

• A：一個好的團隊非常重要。需要更好的磨合。

總結:

• 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
• A：第二級可重複級
• 你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
• A：磨合
• 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
• A：相比以前有更明确的目的
• 你覺得目前最需要改進的一個方面是什麼?
• A：需要對項目投入更多。
• 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
• A：擁抱變化原則。團隊一開始打算利用cocos2d制作一款2d遊戲，但是由于cocos2d的教程太少，沒辦法很好的學習，馬上更換了開發引擎，并且适應。

讨論照片