團隊Beta階段事後分析

設想和目標

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

我們的軟件要解決用戶的休閑娛樂問題，為用戶提供好玩的模擬經營類的遊戲，遊戲主題是軟件開發公司的成長歷程。對典型用戶和典型場景有清晰的描述。

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

我們的功能達到了基本目標，總共5個功能做了3個，但沒有按照原計劃按時交付延期發布，並因此用戶沒有達到基本目標。

和上一個階段相比，團隊軟件工程的質量提高了麽？ 在什麽地方有提高，具體提高了多少，如何衡量的？

和上一個階段相比，我們團隊的關鍵工程質量有了提高，首先是文檔更加齊全，主要完善了美工文檔和策劃文檔，並重點更新、維護了策劃文檔；此外整體的風格更加統一了。衡量標準主要是github上的wiki文檔的數量以及完備度。

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

用戶量還在增長，也接受了我們做出的重大功能，與我們的預想基本一致，離目標更近了。

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

如果要說經驗教訓的話，我們在當初設計的時候應該選擇簡單的益智類或者類似的遊戲類型而不是模擬經營類遊戲，因為模擬經營類遊戲在短期來看我們沒有良好的美術功底並不能做到在等待過程中很好的遊戲體驗。

計劃

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

我們計劃時間很充足，在beta階段我們總共花了1周多的時間進行策劃完善和設計計劃。

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

我們通過每天晚上的長時間的策劃會議征集大家的意見，並最終由PM決定是否保留爭論或者定下功能進行下一步的計劃。

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

我們原計劃的工作到最後並沒有全部做完，因為時間上不太充足，遇到了重大的技術障礙導致我們的工作效率嚴重下滑。Cocos creator不能支持多人同時開發UI並由於他的環境依賴無法做有效的測試這些都導致了後面開發過程十分緩慢的問題。

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

在計劃初期一直在橫向廣度上進行功能的探索而不是對於一個功能更加細致的進行設計規劃。這個工作在第二周才開始，導致整體進度有些拖後。

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

是，我們每一項任務都有一個issue以及對應的文檔寫入或者代碼簽入可以衡量。

是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?

沒有按照計劃進行。項目在中期出了美工開發進度沒有趕上開發，這個主要是由於沒有及時的督促、進度管理導致的；項目中後期出現了嚴重的技術問題，主要是當初選擇的cocos creator框架的問題，當時沒有估計到是因為對這個框架本身沒有做過很細致的調查導致的。

在計劃中有沒有留下緩沖區，緩沖區有作用麽?

我們留下了緩沖區，有些作用，但由於強大的技術風險緩沖區瞬間填滿並沒有發揮全部作用。

將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）

將來的計劃上，加班是一定的，緩沖區上我們需要更加細致的定義，將預留時間改為頻繁多輪叠代來設置緩沖區。

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

我們學到了在選擇框架等技術問題上需要貨比三家，多加調研後再去決定，要不技術風險巨大又無法承受。如果歷史重來一遍我們首先不會再使用cocos creator並多加調研使用更適合本項目的框架再去進行開發。

資源

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

我們的美工資源並不足夠，組內沒有足夠的有美術功底的人進行總體的美工設計。其他資源足夠完成各項任務。

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

各項任務根據任務量的大小進行時間估計並寫在issue上，並完成後在issue上評論實際所花時間來進行衡量，對下一次任務估計有所幫助。精度上基本都跟預測的一樣，比較準確，只是任務量的估計上有些差錯。

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

在alpha階段，我們對不需要變成的資源低估了難度導致沒有出來好的需求設計等文檔以供後續開發，開發流程上也有些混亂。這次我們投入了三個人進行策劃設計，兩個人進行美工設計，其余進行開發，人力、軟件資源都足夠，沒有低估難度。

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

我感覺基本上沒有，我把能讓別人來做更有效率的事情盡可能分配了。

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

在資源上我認為下次應該再招收有美術基礎的人進行美工設計會更好。

變更管理

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

我們采用了什麽辦法決定“推遲”和“必須實現”的功能?

項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽?

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

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

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

設計/實現

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

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

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

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

代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

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

測試/發布

團隊是否有一個測試計劃？為什麽沒有？

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

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

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

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

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

團隊的角色，管理，合作

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

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

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

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

總結:

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

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

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

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

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

全組討論的照片。

團隊Beta階段事後分析