組長部落格連接配接：https://www.cnblogs.com/cmlei/p/11924459.html
1.設想和目标
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
解決福大校園内學生難以釋出任務以解決自身需求的問題
定義清楚，多指人力需求任務，如跑腿、宿舍維修等，
對典型使用者和典型場景有清晰的描述，如：A需要人幫忙從食堂帶一份外賣，在同學幫平台釋出任務并留下聯系方式，B在同學幫看到該任務并選擇接取，拿到外賣後通過聯系方式聯系到A完成任務，獲得報酬
2.我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?
做到了以下七個：利用資料庫技術對使用者釋出的各種資訊進行管理。使用者可以釋出任務，撤銷任務 ，通過個人頁面檢視自己已釋出的任務和接受的任務。并且通過任務詳情内的聯系方式完成交易雙方的溝通，最終完成任務/交易。APP 内提供搜尋功能，幫助使用者快速找到自己期望的任務或者交易物品。
已按照原計劃時間傳遞
使用者數量達到
3.使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
使用者量不一緻，暫時使用的隻有組裡幾個人
接受程度一緻，組員們都用的還行
更近了
4.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
預先做好詳細的團隊部署，精确到每日安排與備用計劃，做好每個功能在開發過程中的代碼配置設定
2.計劃
1.是否有充足的時間來做計劃?
有，我們很早就開始了計劃，時間上較為充足
2.團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
在開會時各抒己見，将各人的意見記錄下後，主導大方向的意見通過投票決定，其餘意見通過讨論合适程度拍闆
3.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
4.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
5.是否每一項任務都有清楚定義和衡量的傳遞件?
每一項任務都有很清楚的定義，但衡量傳遞标準則不一定，因為例如前端UI界面設計這一類随開發人員審美變化大的任務無法進行硬性界定
6.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
中間因為碰到多次考試而導緻在準備階段與沖刺階段項目的實際建立過程出現延緩，我們因疏忽而未提前做好預先分工調配，沒有為每個人安排第二任務以便突發情況下填補人手，導緻項目開發進展并不順利
7.在計劃中有沒有留下緩沖區，緩沖區有作用麼?
沒有，因為計劃時不了解緩沖區的概念。
8.将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
将來會将任務集中在一段時間完成，而不是平攤到整個任務周期。
9.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
長痛不如短痛，遠見勝過疏忽，預先安排人手分工與準備突發情況備用計劃，一次性完成任務是最好的
3.資源
-
我們有足夠的資源來完成各項任務麼?
有，本組有數位優秀的同學帶飛，如熔炜，潤秋，洪威等巨佬，伺服器也具備，但因尚未進行高壓測試是以暫時無法估計伺服器資源是否足夠 -
各項任務所需的時間和其他資源是如何估計的，精度如何?
各項任務所需的時間和其他資源的估計是基于團隊成員過往經驗以及詢問有開發經驗的學長所得，十分粗糙
精度方面，我們沒有确切估計，但是相比于我們咨詢的學長，我們在本項目上的耗時相對更多一些，但是品質方面卻無從考究
-
測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
測試的時間，人力與軟體/硬體資源足夠，難度上可能略微低估了美工設計的難度 -
你有沒有感到你做的事情可以讓别人來做（更有效率）?
按大家來看的話，每個人都在自己最合适的位置上，但是若考慮到效率這一方面的話，肯定多少會存在差異性 -
有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
我們會更均等安排各人任務，不讓大佬承擔太多擔子，同時也要考慮大家個人時間是否充足，讓計劃在制定時突出人性化
4.變更管理
1.每個相關的員工都及時知道了變更的消息?
組内成員都有及時知道變更的消息，我們有建立QQ群，随時在群内交流
2.我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
一般是PM根據實際情況決定
3.項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
我們計劃要完成的項目功能就是我們的出口條件。
4.對于可能的變更是否能制定應急計劃?
能，組長與攥寫文檔的同學随時溝通，備有後備計劃
5.員工是否能夠有效地處理意料之外的工作請求？
在與目前任務不沖突的情況下可以，大家都很厲害
6.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
計劃趕不上變化，無論如何都會出現意外情況（比如考試期間無暇分心，影響了alpha版本開發的進度），在計劃的時候要設定緩沖區以應對未知的變更。
5.設計/實作
1.設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
設計在分工結束後就由各分組負責人完成，時間和人選都很合适
2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有，比方說不确定這個任務能不能按這樣的設計實作，解決方式是詢問學長、查詢資料與開會讨論
3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
使用了Pycharm和單元測試功能與人力手動測試
4.比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
差別極大，如某個功能一開始我們設想的極為全面，但現在的狀态下該功能我們進行了一定的精簡與優化，相印的内容也進行了修改，項目開始時的文檔是基于我們的空想完成的，實際開發過程中不斷地在調整，需要更新的
5.什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
資料接收方面，代碼上可能有一點小疏漏，比如釋出任務後無法自行重新整理，需要手動退出再進入才能重新整理， 開發的時候有考慮到，但是這個是要通過大量的訓練才能解決且疏漏時而難以避免，開發過程中隻能盡力而為
6.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
時間緊任務重，未能進行代碼複審，也未能嚴格執行代碼規範。
7.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
代碼編寫任務配置設定需平均，代碼複審應該随時進行，而不是等項目完結後再進行。代碼規範亦是如此。
6.測試/釋出
1.團隊是否有一個測試計劃？為什麼沒有？是否進行了正式的驗收測試？
有，但較為粗糙，就是在完成雛形之後先使用人力測試
2.團隊是否有測試工具來幫助測試？
無
3.團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
暫無這方面的安排
4.在釋出的過程中發現了哪些意外問題？
軟體暫未釋出
5.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
配置設定足夠的人手進行測試，同時測試計劃應該緊随開發計劃之後指定，并随實際開發進度調整
7.團隊的角色，管理，合作
1.團隊的每個角色是如何确定的，是不是人盡其才？
角色主要是成員自薦，基本上自薦之後就完成了分工。目前看來基本上達到了人盡其才
2.團隊成員之間有互相幫助麼？
有，大家都很熱情，也都很有耐心，開發過程中互相之間會交流合作
3.當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
平心靜氣地讨論解決
每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
我感謝 對我的幫助， 因為某個具體的事情:
我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
溝通是解決問題的唯一途徑，不急不躁方可成事
8. 總結:
1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
屬于CMMI一級 ， 軟體組織對項目的目标與要做的努力很清晰，項目的目标可以實作。但是由于任務的完成帶有很大的偶然性，軟體組織無法保證在實施同類項目時仍然能夠完成任務。項目實施能否成功主要取決于實施人員
2.你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
磨合階段，大家彼此之間交流很愉快，但尚缺少些許默契
3.你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
形成了合作意識，培養了制動性
4.你覺得目前最需要改進的一個方面是什麼?
任務配置設定需要更加合理，計劃也應提前制定，即預見性和大局規劃還要加強
5.對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例
避免不必要的開銷：我們的項目計劃和文檔加起來一共隻有三篇，我們開發過程中計劃的制定與更改多以口頭讨論和網絡交流為主，減少了耗費在文本紙墨上的時間
說真話：我們不說假話，不說空話，胡亂編造隻會加大開發難度
本次貢獻比例：
| 組員 | 貢獻占比 |
|---|---|
| 陳明磊 | 9% |
| 林镕炜 | 15% |
| 韓洪威 | 7% |
| 楊潤秋 | |
| 李欣凱 | 8% |
| 陳舒洋 | |
| 陳錦傑 | |
| 陳振旺 | |
| 胡浩楠 | |
| 鐘偉碩 | |
| 陳錦鴻 | |
| 陳思涵 | 1% |
1.PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
|---|---|---|---|
| Planning | 計劃 | 30 | 45 |
| Estimate | 估計這個任務需要多少時間 | 1300 | 1700 |
| Development | 開發 | 1100 | 1500 |
| Analysis | 需求分析 (包括學習新技術) | 10 | 150 |
| Design Spec | 生成設計文檔 | 60 | 90 |
| Design Review | 設計複審 | 40 | |
| Coding Standard | 代碼規範 (為目前的開發制定合适的規範) | ||
| Design | 具體設計 | 6 | |
| Coding | 具體編碼 | 50 | 700 |
| Code Review | 代碼複審 | 100 | |
| Test | 測試（自我測試，修改代碼，送出修改） | 220 | 280 |
| Reporting | 報告 | 200 | |
| Test Report | 測試報告 | 12 | 130 |
| Size Measurement | 計算工作量 | ||
| Postmortem & Process Improvement Plan | 事後總結, 并提出過程改進計劃 | ||
| 合計 | 1330 | 1845 |
2.學習進度條
| 第N周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 1 | 對應學的架構有一個初步的了解 | ||||
| 2 | 24 | 對應學的架構有一個初步的應用 |