第一次迭代總結
設想和目標
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
（1）我們的軟體要做到的是使高血壓患者通過我們的APP可以記錄自己的血壓值變化，與醫生進行繫結、互動，並且這個APP具有提醒患者定期服藥、定期訪問醫生的作用；我們的後臺管理系統具有可以對資料庫中的所有資料增刪改查的功能。
（2）定義的很清楚。
（3）典型使用者：高血壓患者、專業醫生、後臺管理人員；
典型場景：高血壓患者在我們的APP上註冊賬號後，上傳自己測量的血壓值，我們的資料庫會將其儲存起來，患者同時可以選擇醫生與自己繫結，並與其進行聊天、交流，醫生會給出包括服藥、作息等方面的建議；醫生同樣可以在APP上註冊，上傳相關證件（並通過審查）後可以接收來自患者的訊息，與患者進行互動；而後臺管理人員可以在後臺管理系統網站上檢視到所有的資料，並具有對其增刪改查的許可權。
2. 我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)
我們還沒有達到目標；
已實現：原計劃的功能中患者端的一些基本功能，像登入註冊、上傳資料、記錄自己一定時間段內血壓的變化並以折線圖的形式呈現出來；後臺管理系統的增刪改查的基本功能已經實現；
功能還有很大的欠缺，還不能交付給使用者使用。
3. 和上一個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
和剛開始的團隊狀態相比，團隊軟體工程的質量提高了很多：
組內交流更多：剛開始由於隊友之間不熟悉，隊友之間沒有過多的交流，每週只有一次會議；現在每週至少會有兩次會議，隊友之間溝通、交流遇到的技術以及對接的問題。
4. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
由於實現功能較少，我們的APP還不能交付給使用者使用，但在第一次迭代時，助教有跟我們說很多細節我們做的不夠完善、細緻，使用者體驗並不是很好，這也是我們第一次迭代扣分的地方；
但是，知道了不足的地方，我們也能針對性地改進我們的專案，不斷向目標邁進。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
教訓：我覺得迭代還是應該抓緊時間開始，因為我們的資料庫是比較簡單的，我們在第一次迭代正式開始前其實是有一些時間的，但是我們沒有充分利用好這部分時間，導致迭代開始的時候有些手足無措；
如果再來一遍，我們會盡快加強隊友之間的交流，儘快熟悉彼此，儘早開始著手程式碼部分（學習交流部分）。
計劃
1. 是否有充足的時間來做計劃?
時間相對充足。
2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
仔細探討每個人意見的好的地方，再結合我們的實際情況，和專案每一部分的重要性，有針對地探討，共同決定。（我們組還是挺和諧的。。）
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
有一部分沒有做完--美化介面的部分；我們對於迭代計劃認識不夠清晰，本來把後臺管理系統放在了第二次迭代中，但是，其實這是不合理的，所以在第一次迭代驗收之際，把之前寫的程式碼進行了改進，但是沒來得及美化。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
暫時沒有。。。感覺自己還是需要不斷學習。
5. 是否每一項任務都有清楚定義和衡量的交付件?
沒有，從程式碼規範這方面來說，大家的程式碼風格都不盡相同，並沒有一個嚴格的要求。
6. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
基本上是按照計劃進行的，意外是編寫程式碼以及對接的過程中遇到了很多奇奇怪怪的bug，並且耽誤了我們相當長的時間，而且還在驗收時出現了我們沒有預料到的bug；
沒有估計到（本地）伺服器有時候會崩盤。。當時一直在趕進度，沒有考慮到這方面的問題。
7. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
有，後臺管理平臺部分，即使APP的部分出了問題，後臺管理平臺只要連線了伺服器，依然能夠按計劃進行。
8. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
把每週的任務加多一些，使得我們的專案儘早完成，留出時間用於測試，避免熬夜與趕工。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
我學到了很多前端的知識，以及通過對JAVAEE課堂知識實踐得到了更深的體會。
如果再來一遍，我們會加強隊友之間的合作，儘早對接，修復bug。
資源
1. 我們有足夠的資源來完成各項任務麼?
有，比如我負責的後臺管理系統，與我們的JAVAEE課上講解的知識相關，把課堂上的知識用於實踐，一舉兩得。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
時間主要是根據任務量的多少進行分配；精度適當。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
不夠，由於進度比較趕，導致我們完成的部分其實都是由我們自己來測試的，導致最後的成果不盡如意；
確實低估了美工的難度，作為一個鋼鐵直女，審美堪憂，自己做出的成果自己都有點看不下去。。orz
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
感到了。。。畢竟組裡還是有大佬的，自己還是可以被替代的。。。T-T
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
一定要多和大佬交流技術問題，能學到很多自己單靠查資料查不出來的東西。
變更管理
1. 每個相關的員工都及時知道了變更的訊息?
是的
2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
商討並結合需求確定必須實現的功能以及可以推遲的功能。
3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
滿足客戶的需求，按照需求文件實現功能（有條件的話，進行適當改進）。
4. 對於可能的變更是否能制定應急計劃?
沒有計劃，但是可以及時調整。
5. 員工是否能夠有效地處理意料之外的工作請求？
能，我們是一個小組，小組內會互相學習與交流。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
對於變更要有一定的心理準備和應變能力；
我們會盡量提前商量、討論好可能的需求變更，並留出後路。
設計/實現
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
設計工作是在迭代開始之前小組成員討論共同設計的。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有，確定幾種可能的情況，延申設想，根據實際需求確定哪種更好。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？ 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
有用到UML，有效，對於專案的功能需求更明瞭，更細緻、全面，不斷的學習，已更新。
4. 什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
我負責 的部分中使用了MVC框架，在這個框架的使用中bug最多；原因是對MVC框架不熟練；有些jar包版本不匹配或衝突會導致程式報錯；使用MVC框架不熟練，連找bug都花費了很長時間。
5. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
小組之間交叉評審；基本上嚴格執行了程式碼規範，但是有部分還是很難改變自己的編碼習慣。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
設計工作在最開始的時候就應該考慮到各種可能出現的情況，並提前做好規劃。
比如，程式碼規範這方面，小組內最好也在一開始就確定使用同一種規範，這樣能在一定程度上提高程式碼的可讀性，最後整合的時候也會更方便。
測試/釋出
1. 團隊是否有一個測試計劃？為什麼沒有？
前其主要是自己測試自己負責部分的程式碼，後期，會安排專人負責測試。
2. 是否進行了正式的驗收測試？
通過了第一次迭代的驗收。
3. 團隊是否有測試工具來幫助測試？
沒有。。
4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
軟體的實現還不夠完善，還沒有跟蹤軟體的效能。
5. 在釋出的過程中發現了哪些意外問題？
還未釋出。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
迭代過程中需要不斷的測試；
儘可能留出一些時間用於軟體測試。
團隊的角色，管理，合作
1. 團隊的每個角色是如何確定的，是不是人盡其才？
組內成員商討、確定的。
2. 團隊成員之間有互相幫助麼？
有。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
互相協助完成。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
團隊需要加強交流與溝通，這樣既可以在早期及時發現並解決問題。
總結:
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
CMM 一級。
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
規範。
你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
隊友之間磨合得比上一個階段較好。
你覺得目前最需要改進的一個方面是什麼?
完善功能，美化介面。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
1.以個人為中心構建專案；我們小組是把三個主要的功能分給三個組內小團體來完成，小團體內又有一個人是核心，完成主要的功能，其他人配合、信任。
2.面對面交談；每週至少兩次的小組內討論、聚在一起寫程式碼，每週至少一次與助教溝通、討論進度與遇到的問題。