一、設想與目標

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

• 我們的軟件主要是為了幫助那些對於挑禮物有選擇困難癥或者忙於工作與學習，沒有時間為他人挑選禮物的人。用戶通過輸入被贈送人的年齡生日信息或愛好或理想價位等，軟件將會根據條件為用戶推薦出最合適的禮物。軟件操作簡單，可使用於廣大人群。

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

• 是，在做這個項目之前，我們進行了廣泛的人群調研與需求分析，同時小組間對於本項目的各項功能是否有實用價值進行了深入的討論。

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

• 是，對於挑選禮物，我們模擬了主要的三大類典型用戶與對應的典型場景。分別是戀人之間、朋友之間、親屬之間互送禮物的需求。

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

• 是，我們通過課余時間或者晚間與周末閑暇時間進行團隊的探討與計劃安排。

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

• 在計劃階段對於計劃的安排，首先我們會對團隊成員的時間和擅長內容進行了解，然後再根據隊員實際情況進行計劃的安排。如果對於計劃隊員間有不同的意見，我們會請他們各自講出自己意見的理由，然後考慮是否能有兩全齊美的計劃安排。如果沒有，將由隊員進行舉手表決，最後由少數服從多數來進行安排。隊員間有不同意見是難免的，但一個團隊的計劃安排不應該由強權主義來決定，我們會理性的進行兼顧各方的民主安排。

二.計劃

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

• 我們計劃第一階段完成核心功能推薦禮物以及登陸註冊界面，兩項都有完成但是博客提交上稍遲了一天，演示那天組長不在也推遲了。還沒做完的是購物車以及支付功能和禮物收藏，beta階段主要做這幾個。沒有做完的原因是因為實現起來難度大唄，而且功能較多，alpha階段大家狀態都不是很好。

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

• 這倒是沒有，對於我們組來說，時間相對緊迫。要求的任務都一直做來不及了，沒有時間再去做一些吃力不討好的事。但是早期我們一直在源代碼上花時間琢磨，結果參考代碼亂七八糟的以前也沒學過java ee ,一直運行不了，詢問了其他學校軟件工程的同學，中南大學，福州大學還有我們學校的軟件工程，最終都沒有結果，我們就重新自己寫了。這也不算是沒必要吧，琢磨知識的過程.

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

• 沒有每項，代碼的提交我們在沖刺階段也沒有每天簽入，導致分數也偏低，成員之間分配任務的話很清楚，但是時間觀念不強，效率偏低。

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

• 沒有完全按照原計劃，我們犯了一個錯誤，就是太依靠核心成員，所以中間由於一些原因主力成員的缺席導致我們進度拖緩，團隊模式由一開始的功能模式有點退化為主治醫師模式，因為我們一開始是要參考老師給的源代碼在那個基礎上進行完善改進，後來發現行不通。而且我們一開始開會討論構想的功能太多而復雜，後面在實現的時候發現很難做到。項目出現的意外就是我們在敏捷沖刺階段代碼不夠完善，還有中間幾天組長的缺席也算是意外吧，風險就是沒估計到遲交博客，那幾天剛好很多事，成員之間沒有互相提醒，沒有人監督，這個下次我們一定會註意。

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

• 沒有考慮。緩沖區有作用，比如項目出現問題，可以稍微緩一緩，修復唄

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

• 會留緩沖區，應對緊急情況。成員之間建立起互相監督的機制，提高效率。我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?我們應該分配好時間，不能拖拖拉拉，和隊名一樣，不能太依賴組長，而且每項任務要定義清楚，組員之間有什麽想法及時反應，每天都應該有明確的目標。

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

• 要及時完成計劃中的任務。

三.資源

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

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

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

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

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

• 在測試方面相對薄弱，因為我們是手動測試，找出bug再解決，測試方面的資源有限，花的時間相對較少。對於美工設計我們還是相對比較重視，做出來的界面相對較美觀，覺得其做起來也是並不容易，在文案方面也是相對重視，花費了好多時間在上面，包括博客撰寫、任務分配等等。

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

• 沒有，因為每個人都有自己擅長的方面，該做測試的人員做測試，該美工的人員做美工，開發人員做開發，如果交換一下就不一定做得來了，所以還是每個人都做自己擅長的，能做得來的才能節省時間更有效率。

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

• 分配時，應該更加明確些，具體到某一點的哪些內容，否則會出現隊員做了相同的事，而產生了無用功浪費了人力物力。同時溝通真的很重要，隊員間要多多加強溝通，防止因為誤解隊員的意裏而產生誤會。

四.變更管理

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

• 每個成員都知道項目進行中的變更信息。我們小組的工作內容都發布在微信群上。小組成員都可以收到信息。為了保證，信息通知的靈活性，我們小組還有一個討論組。每個人都可以及時通知和獲得緊急信息。

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

• 首先，在接手項目的時候，我們小組就開過會討論，並確定了項目的核心功能。並且討亂了該功能實現的難易。“推遲”和“必須實現”是這樣界定的：1、核心功能中容易實現的必須在 alpha 版本實現；2、核心功能中有技術難點的推遲到 beta 版本實現。

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

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

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

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

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

• 能夠。如果得知意料之外的任務請求，我們會經過小組討，論接受挑戰。然後我們將在 beta 版本完成請求！

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

• 首先應明確整個開發過程大體要做哪些事，將較大的模塊落實到個人負責，如文檔由某成員專門負責。

五.設計/實現

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

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

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

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

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

• 有運用單元測試，基本都是每個人測試自己的模塊，在遇到實在不懂得問題，大家一起討論，在測試結果符合後再合並到一起。測試過程沒有采用工具，基本是手工測試，遇到問題就修改

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

• 因為每個人測試自己的模塊，所以有些人的不是很了解。就登陸界面來說，在登陸的時候會出現第一次正確密碼可以登錄，以後再次登陸就會失敗。後來修復了。其他的還有就是側滑框的實現不是很理想。

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

• 開發人員不多，所以能夠嚴格執行代碼的規範。

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

• 學到了很多能力都是發掘出來的，只有去嘗試，才能夠進步如果重來一次，讓組長更多地給其他組員加油打氣寫代碼，指出代碼不規範的地方，並說明該怎麽寫。

六.測試/發布

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

• 有測試計劃

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

• 也不懂什麽是正式驗，但是都有收針對各項功能都進行了測試

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

• 沒有用到測試工具

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

• 各個模塊的測試分配給各個測試組員，這些組員進行用例測試。從軟件實際運行的結果來看，這些測試工作還是挺有用的，比如可以測試出一段JavaScript代碼或PHP代碼對於邊界數據的處理是否合乎期望，測試能否成功連接數據庫以及相應的SQL語句的是否正常執行等等。改進的方面，對於測試大家都不是很熟悉，所有並不是非常到位，所以下次會進行改進

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

• 在發布過程中確實出現了一些意外，發布的時候有點晚，在博客提交的時候完了一天。

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

• 從測試中，我們也學到了測試對於整個開發過程是十分重要的，在平時自己寫程序的時候沒有發現這點，在這次團隊開發中學到了很多，雖然做得不是很好，下個階段會慢慢改進的。

七、總結:

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

• 產品核心的挑禮物功能已經實現，成熟度還不是很好。

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

• 磨合過了，要到規範階段了，來點走心的，雖然我們組這階段表現不佳，我們成員之間感情越來越好，這種情感高於我們的分數。配合也默契，有種共患難的感覺哈哈哈，我對我們接下來的表現也很有信心，希望我們越做越好。

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

我覺得我們應該預先估計到一些可能出現的問題和情況，才不至於有時候出現問題大家都很驚慌，甚至悲觀的想要放棄，做你害怕的事，可能你會發現，不過如此。還有時間觀念很重要，效率要提高，除了敏捷沖刺階段每天的站立會議，我們自己也有另外開會討論，感覺效果還不錯，大家一起討論問題解決問題，氛圍也比較輕松，我覺得面對面交流很有用，大家又是同一個班的，機會其實特別多。

4.照片

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

團隊作業10——事後諸葛亮分析