設想和目標

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
   • 我們軟體解決高血壓患者病情相關記錄以及與醫生溝通問題
   • 典型使用者：高血壓患者和擅長醫治高血壓的醫生
2. 我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?
   • 原計劃功能：Andorid端登入註冊, 相關資訊錄入以及修改, 藥品資訊錄入, 血壓資料錄入, 血壓資料分析
   • 實現情況：
     • 功能都基本實現
     • 存在部分資料判斷並未提示使用者, 使用者體驗較差
     • 血壓資料分析介面實現了隨機投放小貼士功能
3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
   • 暫未投入使用，使用者實際接受成度未知
   • 產品完成度一般，會在第二次迭代中吸取教訓
4. 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
   • 增強使用者體驗
   • 合理規劃一二次迭代內容

計劃

1. 是否有充足的時間來做計劃?
   • 自己程式設計時計劃較完整, 按照預期完成
   • 由於與後臺對接時剩餘時間較少所以並沒有較多時間做計劃
2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
   • 計劃階段討論都很順利，沒有太多不同的意見
   • 剩餘的不同意見也是討論後達成了統一
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
   • 團隊整體專案推進很順利，alpha版本的計劃都做完了
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
   • 開始選擇先看理論, 其實發現這是在做中學的, 浪費了一些時間
5. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
   • 沒有完全按照計劃進行，計劃總是調整中
   • 前端後端對於判斷非合法字串沒有進行統一, 導致有的都判斷了, 有的都沒判斷造成錯誤
   • 設計原型時只考慮到了美觀性以及功能是否實現, 並沒有考慮到編碼的複用性以及使用者體驗方面, 導致在程式設計過程中也一直在修改原型和實現方法
6. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
   • 本來我這邊有預留, 但由於與後端對接較晚, 就沒了, 而且導致了測試比較匆忙
將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
• 增多一起程式設計時間, 以及儘量多預留一些時間穩定以及測試
7. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 在團隊的合作中，收穫了很多課程以外的東西
   • 重來, 要提高效率和溝通, 在原型設計方面多考慮複用性問題以及使用者體驗

資源

1. 我們有足夠的資源來完成各項任務麼?
   • 時間限制，沒有做到完美
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
   • 時間主要是按任務量估計，時間按各自的安排估計
   • 精度不好，不能總是保持高效且時間安排總會有意外的衝突
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
   • 測試沒有系統、詳細的安排，在最終整合之後，倉促的測試, 結果在驗收時不理想
   • 人力資源夠
   • 原型方面只考慮了美觀, 在後期實施上出了很多問題，低估了難度
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
   • 不是很懂...
5. 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
   • 分工做的更加明確
   • 規範好介面，防止在後期都做了大面積調整甚至重做
   • 做好程式碼規範，培養好的程式設計習慣

變更管理

1. 每個相關的員工都及時知道了變更的訊息?
   • 有
2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
   • 實現難易
3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
   • 應該有吧....
4. 對於可能的變更是否能制定應急計劃?
   • 沒有
5. 員工是否能夠有效地處理意料之外的工作請求？
   • 能
6. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 增多一起程式設計時間

設計/實現

1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
   • 團隊與老師商議決定需求, 我和孫玉攀繪製原型
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
   • 沒有
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
   • 有UML圖來幫助設計，也採用了阿里巴巴向量圖示庫獲取了圖示素材
4. 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
   • 文件更加豐富了，會在專案推進中，不斷完善、更新文件
5. 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
   • 輸入吧.. 由於忘記判斷合法性或者粗心忘記更改允許最長長度等
6. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
   • 小組間進行, 算是嚴格的執行吧

測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？
   • 沒有詳細的測試計劃
2. 是否進行了正式的驗收測試？
   • 否
3. 團隊是否有測試工具來幫助測試？
   • 暫未考慮
4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
   • 暫未考慮
5. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 先以完成專案功能為首要任務, 然後通過測試完善

團隊的角色，管理，合作

1. 團隊的每個角色是如何確定的，是不是人盡其才？
   • 團隊角色確定，以尊重個人意願為首要因素，再根據實際情況協商確定角色
2. 團隊成員之間有互相幫助麼？
   • 有
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
   • 共同商議解決

總結

1. 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
   • CMMI一級，完成級
2. 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
   • 磨合基本完成
3. 你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
   • 磨合過更有效率
4. 你覺得目前最需要改進的一個方面是什麼?
   • 非法性判斷上, 在經過不斷地測試進行完善
   • 養成良好的編碼習慣, 寫規範的程式碼, 儘量圓滿的完成這個專案