項目名稱：大學生信用培養平臺

大學生信用培養平臺

隊名：

我們還可以搶救一下

小組成員：
隊長：蘇華 180320063
隊員：範媛媛180320074
隊員：趙曉南180320078
隊員：陶濤 180320076

1)設想和目標

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

• 我們完成的一個信用培養和記錄的網站系統，提供學生信用的記錄功能，設計並提供許多有趣的信用活動供學生參與，從而主動吸引和引導學生培養自己的信用素質。我們認為定義的還是很明確的，對用戶場景的描述也很清晰(可參考我們項目之前需求報告中的用戶場景章節)

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

• 我們在Alpha沖刺階段的目標是完成用戶管理模塊（註冊、登錄、忘記密碼、修改個人資料）和活動管理模塊（活動發布、活動報名、同意報名、開始活動、活動結束、活動評價），雖然還有些bug但目前已基本全部完成。項目按照要求在Alpha沖刺截止時間前提交了，總體來說我們達到了目標。

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

• 目前處於Alpha沖刺，後一階段還未開始。

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

• 因為項目並未發布出去，用戶量還不知，但我們請了其他的小夥伴來使用我們的系統，整體活動流程和我們事先的預想的沒有太大出入，但有些地方還不夠完善，還有所欠缺，比如頁面布局不夠美觀吸引人等等，總體來說我們更接近了目標但還有距離。

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

• 前期我們花了很長時間在討論項目框架的搭建上，回顧沖刺後期階段我們發現，前期工作很重要，考慮越詳細越全面，能很大程度上減少後期的修改代價。另外一開始安排整體進度時，未考慮到有些模塊難度，時間安排緊湊，導致項目不如預期，好在後期沖刺趕上進度，以後應該會註意這塊。
  

2)計劃

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

• 在項目沖刺前期我們花了很長時間來討論計劃，而且基本每天也會在午休時間進行當天項目的討論以及之後的安排，所以做計劃的時間還是很充足的。

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

• 在計劃階段，隊員之間有不同意見時，我們會進行商討，然後進行適當調整。

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

• 在前期原計劃工作基本都會延後到第二天，到後期隊員之間配合也越來越好，項目進度也都趕上甚至提前完成，基本上原計劃工作也都做完了。

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

• 我們基本每天都在忙於完成項目的一些基本模塊的功能點，並沒有做太多其他的工作。

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

• 我們每日安排的任務基本都有比較清楚的定義，比如完成登錄功能，就要實現登錄頁面，用戶輸入正確用戶名密碼可以進入系統主頁。關於衡量的交付件，就是每日在完成功能時，所有人進行該功能的測試，沒有問題或者BUG就繼續後面的功能。

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

• 整體來說，項目是按照計劃進行的。雖然前期一些工作並不能按計劃當日完成，但通過中後期調整漸漸趕上進度。整體來說沒有太大波瀾。

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

• 在沖刺階段中期，我們留了一天的緩沖區，用於解決前期的一些遺留問題，同時為後期的一些工作做準備，緩沖區用於調整整個項目的進度。

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

• 緩沖區放在中期我們覺得能起到一個承上啟下的作用，是個不錯的選擇。但在前期出現問題，能立馬進行調整，能使得有些地方能立馬得到解決，而不用延到中期。

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

• 計劃通常來說只是基線，很多時候並不能按照這個劇本走，因此要留一個緩沖區進行調整，我們在前期時計劃時很多時間節點都定得比較死，當天項目完不成後續就會不斷堆積，如果再來一遍，我們大概會把計劃調整得更加靈活。
  

3)資源

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

• 人力資源：我們團隊有4個人，大家都有一定的開發基礎；
• 設備資源：四人都有自己的電腦，足夠用來完成各自的開發任務；
• 時間資源：時間上稍微有些緊張，大家都有其他課程的作業以及各自實驗室的任務，不過時間嘛，擠擠還是有的。

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

• 團隊分配好各自的任務後，組員先進行自我評估，團隊再結合整個項目進行總體評估，由於是主觀評估因此精度不是很準確。

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

• 測試的時間有點不足，由於時間比較緊，團隊沒有專門的測試人員。

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

• 由於每個人負責各自的模塊，所以要做的事情都差不多，總體來說，只要團員互幫互助，效率就能提高。

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

• 遇到問題如果自己花了很多時間都不能解決，就要盡早提出來，大家一起解決，團隊的交流和溝通是非常有必要的，否則就會降低效率。

4)變更管理

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

• 我們有三個隊員在一間宿舍，並且建了一個團隊的qq群，有新變更馬上就能通知到所有隊員。

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

• 在時間較緊急的情況下，按功能的重要性，把較重要的功能分為“必須實現”的功能，把可以暫時緩一緩的分為“可以推遲”的功能。

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

• 我們的項目的出口條件定義就是：項目能夠達到《需求報告》中的要求。

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

• 項目需求分析的時候有考慮到一些可能變更並在設計階段做出了相應的設計，面對需求變更，希望能夠做到改動量最小化。

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

• 如果說有額外的工作請求，我們大家都會一起討論並統一意見作出相應的計劃。

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

• 如果重來一遍，我們會設專門的測試人員和美工。

5)設計/實現

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

• 系統的設計工作是由我們小組的四個成員不斷的開會來討論決定的，基本是在系統開發初期的前幾天設計完成。小組的成員都是很熟悉的人，大家在討論的期間基本沒有什麽意見的沖突，是合適的人。

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

• 在設計活動進程的管理時，團隊討論初期就設定了幾個活動流程，後來在開發的過程中發現參與者與發起者對於活動的控制不一樣。團隊進而又對該需求進行了詳細的分析，設計出了比較好的活動流程控制。

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

• 團隊使用了UML來對系統的類進行分析，在設計過程中繪制了用例圖來明確系統需求。使用單元測試，對系統後臺實現的函數進行測試。UML工具幫我們更加明確了系統功能，類間關系。單元測試幫助我們在開發過程中更好的排錯測試。這些工具都起到了很大的作用。隨著項目的進行，UML文檔也在不斷的更新，這些區別的產生原因在於我們增加或刪減了部分的功能，還有一部分原因是由於當初設計考慮情況的欠缺。需要部分更新UML文檔。

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

• 在活動流程控制的過程中產生的Bug最多。因為活動流程涉及到兩個用戶，發起者與參與者對於相同的活動狀態有著不同的操作，控制較為復雜。系統發布後發現，用戶只有在重新登錄後才能收到新消息。這個原因在於我們在開發的過程中，都是在不同的用戶之間切換，沒有考慮到兩個用戶同時在線的情況。

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

• 我們從以下幾個部分對代碼進行了審查：代碼符合需求和規格說明。代碼可讀性較好。代碼功能塊劃分較好，易維護。設計遵從常用的設計模式。較少存在重復無用的代碼。開發過程嚴格執行了代碼規範。

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

• 我們學到在開發初期，必須多花時間做需求分析，在需求分析過程需要站在用戶的角度，考慮多種情況的發生。如果歷史重來一次，我們會在更加認真的做前期的需求分析。
  

6)測試/發布

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

• 有的，團隊在開發過程中，對每一個新開發的功能點都會進行測試。最終開發完成後，還進行了一次完整的系統測試。

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

• 進行了。團隊對整個系統編寫了規範的測試用例，並在系統開發完成後對系統進行了全面的測試。對測試出的問題進行了改正與復測。

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

• 使用myeclipse中自帶的Junit jar包，其余大多是我們團隊成員自己進行的黑盒測試。

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

• 我們團隊在開發過程中，沒新開發一個功能點，會進行一次自測，然後發布給團隊另外三個成員進行互測。測試是很有用的，在我們四個人的測試中，總是能發現開發沒有想到的情況，根據測出來的錯誤，系統進行了改進。

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

• 發布較為順利沒有發現什麽意外的問題。
  

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

• 這個過程中，我們意識到了測試的重要性，測試總是能測出很多自測時沒有意識到的錯誤。如果歷史重來一遍，我們會盡可能學習一些測試工具的使用，使得我們的測試更加完備些。

7)團隊的角色，管理，合作

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

• 我們根據每個人的擅長方向不同，分配等量的工作，以大家興趣為主要依據來進行任務分配。每個人都發揮了自己的優勢和特長，男女搭配，幹活不累，所以我們的合作是高效的。

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

• 那必須的。一個項目的完美完成離不開項目成員每個人的努力，是集體智慧的結晶。每個成員都是這個項目的一環，離開誰都不行，環環相扣，自然離不開相互合作和幫忙，團隊成員配合默契，氣氛友好和諧。這也是我們項目組能很好完成項目的最大優勢。

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

• 在項目協作完成過程中，肯定會出現意見分歧的情況，每個人對項目的理解和看法，基於此我們采取求同存異，以投票的方式選出最優的解決方案，遵循少數服從的原則，所以當團隊中出現意見分歧時，歸根結底還是要保持溝通和信息的對稱，讓每個人都可以發表自身看法，碰撞出創意的火花。

每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的博客裏）：

• 感謝我們隊的每一位成員。 從最開始的選題到如今快要收尾，我們項目組經歷了很多，很感謝各位隊友的積極配合和互相鼓勵，千言萬語都不能表達我對各位的感謝。這段時間，我們團隊經歷過困難和絕望，我們憑借著永不言敗的精神以及互相鼓勵挺過來了，攻克了一道道問題和困難，也經歷過歡聲笑語，那是項目進度趕上預期的時候，大家都很開心，這段時間大家都表現的很優秀。總之，還剩最後一個階段，大家不要虎頭蛇尾，繼續保持這個狀態，繼續加油，為我們的項目完美收尾繼續努力，沖鴨，各位！

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

• 開發團隊作為一個整體，遇到問題就要及時解決，不要覺得這個問題很簡單問了會丟人，如果歷史再來一遍，我們會繼續保持這種狀態。

8)總結:

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

• 我覺得團隊目前狀態更傾向於CMM。

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

• 我們團隊目前的階段應該是過了磨合期進入規範期。

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

• 隊員之間交流更加無障礙，對軟件開發整個過程更加熟悉。

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

• 註重開發過程中的測試，學會多種測試工具。

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

• 快速反饋。我們在開發過程，每天都會利用午休時間進行討論，有好的Idea時、想法或者思路時就會進行討論，如果覺得可行就去動手實踐。

事後諸葛亮（團隊）