一、設想與目標

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

•  我們的軟體主要是為了增強使用者的遊戲體驗，增加更多的趣味性。

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

• 是，在做這個專案之前，我們進行了廣泛的人群調研與需求分析，同時小組間對於本專案的各項功能是否有實用價值進行了深入的討論。基於alpha階段的工作，beta階段吸取了之前的教訓，效率上有所提高，時間相對充裕。

3. 團隊在計劃階段是如何解決成員對於計劃的不同意見的？

• 如果對於計劃隊員間有不同的意見，我們會請他們各自講出自己意見的理由，然後考慮是否能有兩全齊美的計劃安排。如果沒有，將由隊員進行舉手表決，最後由少數服從多數來進行安排。隊員間有不同意見是難免的，我們會理性的進行兼顧各方的民主安排。我們會一起開會討論，各抒己見，對於一些複雜的功能，實現不了的就放棄了，意見遵循少數服從多數的原則，綜合考慮各種因素，我們手上所有的資源以及我們的實際能力，和能達到的水平都會一起討論分析，成員們也都是非常樂意聽取意見的人，在這方面問題不大。

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

• 團隊成員之間的分工要針對個人所擅長的領域，避免事倍功半。個別成員參與度不高，這也是一個問題。如果歷史重來，首先分工儘量明確，讓每個人都有任務可以做並且是願意做的，能做好而不是草草應付，或者說因為不擅長而做得很費勁。

   

二.計劃

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

• 我們計劃beta階段完成遊戲聯網功能

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

• 這倒是沒有，吸取了alpha階段的教訓，我們直奔主題，配合也越來越默契，效率也提高很多。

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

• 程式碼方面有所欠缺

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

• 基本按照計劃，就是支付功能最終無法完整實現。一開始以為是可以的，高估自己的能力了。

5. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?

• 沒有考慮。緩衝區有作用，比如專案出現問題，可以緩一緩

6. 將來的計劃會做什麼修改？

• 會留緩衝區，應對緊急情況。成員之間建立起互相監督的機制，提高效率。

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

• 要及時完成計劃中的任務。任務分配應該合理而明確。

三.資源

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

• 資源問題的話，說不夠也不夠說足夠也足夠。首先，不夠的話，我們一開始有一些資源，就是老師給的參考程式碼，但是畢竟自己團隊對程式碼的規範跟標準與別人的不一樣，所以大部分都看不懂，資源也就差不多都沒用上了。還有缺少就是時間資源吧，因為大三課程較多，尤其是實驗課最多，除了課餘的討論時間，也就僅僅一兩天時間去做專案。要說足夠的話，我們最好的資源就是有一位在程式設計方面比較擅長的組長、還有擅長介面設計的隊友、擁有PS技能的人員、擅長部落格編寫的人員；雖然時間資源不夠，但是我們有豐富的精神資源，熬夜寫程式碼，寫部落格，隊友之間互相鼓勵、支援。

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

• 每次做任務之前，組長會將每個人的任務分配好，基本是按一天完成幾個任務，任務精度級算是精確到每天。

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

• 測試的話，之前有說過，我們在測試方面相對薄弱，因為我們是手動測試，找出bug再解決，測試方面的人力資源足夠而軟體資源有限，導致測試花費好多時間。對於美工設計我們還是相對比較重視，做出來的介面相對較美觀，覺得其做起來也是並不容易，在文案方面也是相對重視，花費了好多時間在上面，包括部落格撰寫、任務分配等等。

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

• 沒有覺得，因為每個人都有自己擅長的方面，該做測試的人員做測試，該美工的人員做美工，開發人員做開發，如果交換一下就不一定做得來了，所以還是每個人都做自己擅長的，能做得來的才能節省時間更有效率。若是不考慮效率光說做不做的來的話，我想互相教一教還是可以做的來，但是團隊做專案，效率還是很重要的。

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

• 在這個階段我們學到很多東西，在團隊方面學會合作互相幫助，在專案上面，學會如何測試，如何美工，如何程式設計。如果歷史重來一遍，分配時，應該更加明確些，具體到某一點的哪些內容，否則會出現隊員做了相同的事，而產生了無用功浪費了人力物力。同時溝通真的很重要，隊員間要多多加強溝通，防止因為誤解隊員的意裡而產生誤會。       

四.變更管理

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

• 每個成員都及時知道專案進行中的變更資訊。我們小組是由兩個宿舍組成的，一個隊友知道的變更訊息，會告訴自己的舍友，傳播速度快。除了這個，我們的的工作內容都發布在微信群上。小組成員都可以收到資訊。為了保證，資訊通知的靈活性，我們小組還有一個討論組。每個人都可以及時通知和獲得緊急資訊。

2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

• 在剛接手專案的時候，我們小組就開過會討論，並確定了專案的核心功能。並且討論了各個功能實現的難易。“推遲”和“必須實現”是這樣界定的：1、核心功能中容易實現的必須在 alpha 版本實現；2、核心功能中有技術難點的推遲到 beta 版本實現。後來也是按照這個方法完成了專案。

3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

• 小組對專案出口條件的定義是：專案能夠滿足《畢設導師智慧分配系統》的需求。一定的使用者先體驗，反饋良好。

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

• 對於重大的變更，我們暫時沒有應對計劃,但是，我們有應對資料庫變更的計劃。我們對資料庫進行了備份，能夠在需要的時候使用恢復備份以及擴充套件資料庫。

5. 成員是否能夠有效地處理意料之外的任務請求？

• 可以。如果得知意料之外的任務請求，我們會經過小組討論接受挑戰，爭取完成任務。

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

• 學到了為防變更而制定應急計劃，既對資料庫進行備份。如果歷史重來一遍，首先應明確整個開發過程大體要做哪些事，將較大的模組落實到個人負責，如文件由某成員專門負責。

五.設計/實現

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

•  設計工作是在Alpha階段衝刺的時候開始的。由我們的隊長領導，團隊成員一起討論來完成。在適合的時間，適合的人員中完成了適合的事情。

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

• 有的。原型設計的時候，每個人對於某一內容的實現方式有不同的想法，介面的風格，顏色的搭配，等有了很大的分歧，最終是通過投票進行選擇的。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

• 有運用單元測試，UML測試，等測試工具。這些工具很有效，大大的提高了測試的效率，降低了手工測試的工作量。同時有的測試工具還有提供一些小問題的解決辦法。為我們減輕了很多負擔。但測試出現的大多問題都會記錄下來然後團隊討論解決方案。

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

• 因為進行程式碼測試時，大家會把出現的問題記錄下來共同解決。所以經過統計出現bug最多的是坦克的移動攻擊，因為它實在有些複雜。而在釋出之後發現功能並不能完全實現，不知道是什麼問題。因為大家都是新手第一次做這樣的專案，所以難免會不能考慮周全。在設計開發之前有過對此功能的預想設計但是仍然不夠完備。

5. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

• 在程式碼開發之前我們就有規定程式碼編寫的規範問題，所以為程式碼複審帶來了很大的便利。程式碼複審的工作由參與程式碼編寫的人員來執行，互相檢查彼此的程式碼然後找出問題，再共同解決。因為參與開發的人員不多，所以能夠嚴格執行程式碼的規範。

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

• 我們學習到了，人只有在不斷的挑戰自己的極限中才能得道最大的進步。不論是對工作任務上的挑戰還是心理承受上的挑戰，都能使我們得到成長。因為人的很多能力都是發掘出來的，只有去嘗試才能夠進步。而對於本次專案在程式碼編寫或是部落格編寫的方面學到的東西更是不言而喻的。如果重來一次，我們會在事前做更完備的計劃分析，不僅要考慮到每個人的任務，也要考慮到如果沒能按時完成或某位成員更不上進度的解決方案。

六.測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？

• 有測試計劃

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

• 有對每一部分功能進行正式的驗收測試

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

• 有

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

• 各個模組的測試分配給各個測試組員，這些組員進行用例測試。從軟體實際執行的結果來看，這些測試工作還是挺有用的，比如可以測試出一段JavaScript程式碼或PHP程式碼對於邊界資料的處理是否合乎期望，測試能否成功連線資料庫以及相應的SQL語句的是否正常執行等等。改進的方面就是大家應該在如何運用測試軟體上多做些學習，這樣可以保證正確的執行測試任務同時節約時間提高效率。

5. 在釋出的過程中發現了哪些意外問題？

• 出現的意外有，釋出的時候有晚點，在部落格提交的時候完了一天。

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

• 我們學習到了要認真遵守規定，時間觀念一定要重視。晚了就是晚了，即使是在學習任務上也不能說寄希望與別人給予通融。如果重來一遍我們會時刻注意應該完成的任務。然後養成良好的時間觀念。

七、總結:

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

 遊戲的基本功能已經實現，但流暢度還不是很好。

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

• 磨合過了，到了規範階段了，經過alpha階段隊員們之間熟悉了很多，有問題也會直接指出，不以規矩不成方圓，凡事還是規範化做起來效率較高，不用顧慮太多其他因素，規則定在那裡就去執行。

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

我們都在做自己擅長的雖然效率提高，但是也缺乏探索和創新能力，沒有積極主動地去往自己不會的領域發展，多方面的發展自己。遇到難一點的東西做了失敗了以後就會打退堂鼓，覺得不行了沒法完成了也就沒有再花時間去嘗試到底能不能成功。缺乏一種鑽研的精神。

八、團隊成員在Alpha階段的角色和具體貢獻: