組長部落格連結（2分）
小李的部落格
現代軟體工程 項目Postmortem 模闆（27分）
設想和目标（2分）
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
- 答：我們的軟體需要解決使用者們點外賣時，部分商家起送費高、配送費高的問題。定義的比較清楚，在典型使用者和典型場景中也有清楚的描述。
2.我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)?
- 答：我們原計劃的功能實作了三個，按照原計劃傳遞時間傳遞了，沒有達到原計劃的使用者數量。
3.使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
- 答：差不多吧，在部分功能沒有實作的情況下，大家對我們的軟體還算比較接受，我們也離目标更近了。
4.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
- 答：在定義軟體的功能時，需要提前考察一下軟體部分功能的實作方式。我們對支付接口的了解不夠，導緻前期大餅畫出來，後期沒法實作。
計劃（5分）
1.是否有充足的時間來做計劃?
- 答：是，我們計劃的很充分。
2.團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
- 答：大家讨論選擇最優解決方案。
3.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
- 答：否，因為隊員的能力有限，部分還需後續加油。
4.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
- 答：暫時沒有發現，後續應該會有。
5.是否每一項任務都有清楚定義和衡量的傳遞件?
- 答：也不是，其實對于有些任務的把握我們做的還不夠好。
6.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
- 答：否，意外就是支付接口搞不定，一下子減慢了整體進度。沒啥風險，隻有意外沒有估計到，因為前期并沒有去調查支付問題是如何解決的。
7.在計劃中有沒有留下緩沖區，緩沖區有作用麼?
- 答：有，我會讓大家提前一天完成原計劃的任務，留有時間來修改和集思廣益、頭腦風暴。
8.将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
- 答：不加班！緩沖區還是要有，對于人員分工還是要調整一下。
9.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 答：我們學會了早點向大家彙報進度，如果搞不定還是要及時提出，别因為個人原因影響整個組的期望和工作進度。
資源（3分）
1.我們有足夠的資源來完成各項任務麼?
- 答：沒有
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
- 答：根據大家的能力和經驗吧，精度不是很高，偏差較大。
3.測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
- 答：人力、時間、軟體足夠，硬體不足夠。對于美工文案的難度還是有低估，但是大家能力還是比較強的。
4.你有沒有感到你做的事情可以讓别人來做（更有效率）?
- 答：沒有，我還是比較有效率的。
5.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
- 答：這個闆塊暫無。
變更管理（4分）
1.每個相關的員工都及時知道了變更的消息?
- 答：是的，我會及時在群裡通知。
2.我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
- 答：根據大家的工作進度。
3.項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
- 答：有，如果能讓所有人滿意，才算做好了。
4.對于可能的變更是否能制定應急計劃?
- 答：當然要制定。
5.員工是否能夠有效地處理意料之外的工作請求？
- 答：還是需要組長多操心關注才能有效地解決。
6.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 答：要留有資源去處理應急事件。
設計/實作（4分）
1.設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
- 答：設計工作在前階段由想法提出者：曾宇輝同學完成，時間合适，人員合适。
2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 答：有，團隊在會議中去解決這個問題。
3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
- 答：沒有。
4.比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
- 答：我們沒有做什麼UML文檔。
5.什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
- 答：目前都還好，注冊功能吧，因為資料庫定義的不夠精确。釋出之後還沒有發現重要BUG。
6.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
- 答：由細心的人稽核，是。
7.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 答：設計時還是要考慮可行性。
測試/釋出（3分）
1.團隊是否有一個測試計劃？為什麼沒有？是否進行了正式的驗收測試？
- 答：有，是，正在進行中。
2.團隊是否有測試工具來幫助測試？
- 答：準備用腳本和工具去測試伺服器的壓力。
3.團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
- 答：分組測試，不斷地使用，提出不同的需求想法。有用。暫無需要改進的。
4.在釋出的過程中發現了哪些意外問題？
- 答：正在進行中，暫無。
5.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
團隊的角色，管理，合作（3分）
1.團隊的每個角色是如何确定的，是不是人盡其才？
- 答：由組長去詢問大家的能力，然後按能力分工，大多數是人盡其才。
2.團隊成員之間有互相幫助麼？
- 答：在組長在的時候，大家溝通較多，組長不在，大家也不怎呢溝通。
3.當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
- 答：還是去主動找相關人去溝通，來的快一點，如果不溝通，大家都不愉快，資訊不對稱很煩人。
-
每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
我感謝陳超星對我的幫助， 因為某個具體的事情: 他幫助了我很多，在軟體的設計和實作方面做了很多的事。
我感謝瑪爾孜亞對我的幫助，因為某個具體的事情：她時刻提醒我DDL的截至還有沒有做完的事。
我感謝曾宇輝對我的幫助，因為某個具體的事情：他在前期我很迷茫的時候提出了軟體的構思和想法。
我感謝張偉佳對我的幫助， 因為某個具體的事情: 他在軟體的支付寶接口調查工作中做了很多貢獻。
我感謝翟鑫亮對我的幫助， 因為某個具體的事情: 他在軟體的地圖接口調查工作中做了很多貢獻。
我感謝劉烨對我的幫助， 因為某個具體的事情: 他在原型設計方面做了很多貢獻。
我感謝王銀對我的幫助， 因為某個具體的事情: 他在微信支付接口調查工作中做了很多貢獻。
我感謝黃斌敏對我的幫助， 因為某個具體的事情: 他在會議中提出很多想法。
我感謝王懷騁對我的幫助， 因為某個具體的事情: 他在平常也提出了很多建議和意見。
我感謝李福佳對我的幫助， 因為某個具體的事情: 他在軟體編寫過程中提出了很多有用的思想。
4.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
- 答：對于軟體的設計和定義需要早點去做，盡量細緻和清晰。
總結（3分）
1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
- 答：CMMI二級
2.你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
- 答：規範吧。
3.你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
- 答：大家懂得了合作和溝通的重要性，在下個階段還是要建立集體榮譽感。
4.你覺得目前最需要改進的一個方面是什麼?
- 答：大家其實對于任務還是不夠積極，都得組長來安排才能進行。
對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
- 答：說真話，不會做就是不會做，能早點完成就能早早交，這點大家做的很不錯。
部落格要附上全組讨論的照片。（1分）
答辯總結（6分）
評估團隊中每個人對本次作業的貢獻比例，描述為本次作業的工作流程、組員分工、組員工作量比例（禁止一鍋端平的情況，如果沒有評估，全組平均後，組長得分減 50%）
| 姓名 | 貢獻比例 |
|---|---|
| 李昕晖 | 15% |
| 曾宇輝 | 10% |
| 瑪爾孜亞 | |
| 翟鑫亮 | 20% |
| 張偉佳 | 5.25% |
| 陳超星 | |
| 劉烨 | |
| 王銀 | |
| 李福佳 | 7% |
| 黃斌敏 | |
| 王懷騁 |
求出本組的現場答辯得分：去除最高總分，最低總分，求平均分（保留1位小數）
- 90.3
收集其他組對本組提出的問題，并回答（每少回答一點，該項得分扣除10%，扣完為止）
- 第一組：無
- 答：正好
- 第二組：後期維護困難
- 答：問題不清晰，我覺得還行，認真就可以做。
- 第三組：界面可以優化一下，支付問題
- 答：我們後續會好好優化，支付問題我們目前沒辦法解決，如果有官方的檔案支援，我們可搞！
- 第四組：希望對原始的産品進行優化改進
- 答：我們後續會好好優化的
- 第五組：希望能夠繼續實作功能，答辯時不要使用太多時間
- 答：我們後續會逐漸實作所有功能，答辯我們出了錯誤，耽誤了很長時間，十分抱歉，但是給大家帶來了十分鐘的休息，嘻嘻
- 第六組：功能還有一些欠缺，可以繼續加油完善，圖形界面可以設定的更好。
- 答：功能我們後續會逐漸實作的，圖形界面也是我們前期沒有做完。
- 第七組：進一步完善，并修改bug
- 答：收到，我們會繼續努力的。
- 第八組：大家都很棒，第八組最棒。
- 答：我也覺得
- 第九組：項目可以進一步完善。
- 第十組：界面不夠美觀，功能還需繼續完善
PSP與學習進度條（4分）
| PSP2.1 | 任務内容 | 計劃完成需要的時間(min) | 實際完成需要的時間(min) |
|---|---|---|---|
| Planning | 計劃 | 45 | 40 |
| Estimate | 估計這個任務需要多少時間，并規劃大緻工作步驟 | 30 | 20 |
| Development | 開發 | ||
| Analysis | 需求分析 (包括學習新技術) | ||
| Design Spec | 生成設計文檔 | 10 | - |
| Design Review | 設計複審 (和同僚稽核設計文檔) | ||
| Coding Standard | 代碼規範 (為目前的開發制定合适的規範) | 5 | |
| Design | 具體設計 | 25 | |
| Coding | 具體編碼 | ||
| Code Review | 代碼複審 | ||
| est | 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | ||
| Test Report | 測試報告 | ||
| Size Measurement | 計算工作量 | ||
| Postmortem & Process Improvement Plan | 事後總結 ,并提出過程改進計劃 | 60 | 80 |
| Summary | 合計 | 285 | 265 |
| 第n周 | 新增代碼（行） | 累計代碼（行） | 本周學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 250 | 15 | 進一步熟悉python、Java與API | |||
| 500 | 750 | 35 | 學了java的程式設計，繼續學習python的資料分析内容模組化 | ||
| 150 | 900 | 學了java的程式設計、python的GUI | |||
| 300 | 1200 | 65 | 學習了java前端和Androidstudio的使用 |