第一次迭代已經結束，總的來說收穫很大。a版本主要進行了網站的開發，從最開始的第一個頁面到最後一個頁面，開發速度越來越快，效率越來越高，html、css、js也運用的越來越熟練，但還是需要更加深入的學習。

設想與目標

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
   • 產品定義：基於深度學習構建時間預測序列，實現資料視覺化。
   • 典型使用者：資料分析師，量化分析師。
   • 典型場景：股票預測、房價預測等。
2. 我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?
   • 原計劃功能：實現使用者通過網站登入、註冊、找回密碼、檢視幫助文件、上傳資料集、建立模型。
   • 實現情況：功能基本完成，網站介面還需要繼續優化。
   • 交付與使用者：介面中規中矩，功能還不完善。
3. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼？ 
   • 暫未交付使用，對使用者量未知。
   • 對重要功能的認知應該會與使用者相一致。
   • 離目標更近了。
4. 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
   • 第一次迭代，前端網頁分為多個部分由小組成員分工開發，最後整合的時候，導致頁面大小不統一，整合頁面也花了兩天的時間。
   • 後臺的搭建一開始選擇的Django,最後才選擇用flask。

計劃

1. 是否有充足的時間來做計劃? 
   • 在第一次迭代前期因為知識儲備的不足，有一些功能沒有在預定的時限前實現，有些許感到時間不足。不過在之後因為熟練的緣故，所以都按時完成了。
2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
   • 每週的小組例會上進行討論，有意見也可私下向PM提出，大家進行修改。
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
   • 已全部完成。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
   • 網站相同的部分可以構建一個單獨的html，所有頁面均可使用。
5. 是否每一項任務都有清楚定義和衡量的交付件?
   • 是。因為這些都是通過與組內成員相互討論出來的。
6. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
• 無未預估分險。
7. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
   • 沒有緩衝區。
   • 緩衝區的作用為解決專案中的 bugs，完善專案。
8. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
   • 計劃加快進度，為最後能多留出時間來進行專案的完善。
9. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 資料庫設計不合理，在專案後期多次更改了資料庫。改進為：應更謹慎地設計資料庫。
   • 在開發之前如果先將技能知識學會就好了。

資源

1. 我們有足夠的資源來完成各項任務麼?
   • 網上的多種資源進行專案技術的學習，然後利用技能完成任務。
2. 各項任務所需的時間和其他資源是如何估計的，精度如何?
   • 因為第一次進行團隊開發，任務的時間與資源分配較為隨意。
   • 精度不高。
3. 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度? 
   • 沒有系統的測試規劃，由成員自行測試。在專案合併後再進行整體測試。各資源都較為充足。
   • 低估了網頁介面設計的難度。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
   • 大家分工合理，效率都比較高
5. 有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
   • 網站搭建程式碼純手寫，其他組很多都使用了框架，開發起來效率高，介面也比較完美，下次一定要先進行知識的積累，增加開發效率。
   • 改進：不過我想，那時團隊成員均無開發經驗，也難以對整體專案有明確的認知，分工不明確仔細似乎在所難免。希望要先在對專案工作量後有大概的瞭解後再進行分工。

變更管理

1. 每個相關的員工都及時知道了變更的訊息?
   • 有關於專案的訊息變更都會第一時間在組裡進行公告，小組成員都能及時瞭解。
2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
   • 小組協商，根據實現難度和是否必要進行劃分。
3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
   • 實現預期功能，在基本使用過程中無 bug。
4. 對於可能的變更是否能制定應急計劃?
   • 有，當開發時間不夠的時候，小組成員合理分配，互幫互助。
5. 員工是否能夠有效地處理意料之外的工作請求？
   • 能。
6. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 專案變更實在不好。影響整個團隊的開發進展。
   • 改進：任務分配重新調整

設計/實現

1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
   • 主要由 PM 完成。老師提供建議，團隊成員討論確立設計。
   • 是合適的時間，合適的人。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
   • 團隊共同協商，最終確定設計目標。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
   
   • 是。
   • 有效。
4. 比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
   • UML 圖例發生了多次的更改。
   • 因最初 UML 的相關知識並不充足，後期又根據具體的開發進度發生了相應的更改。
5. 什麼功能產生的 bug 最多，為什麼？在釋出之後發現了什麼重要的 bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
   • 要與伺服器資料庫連線的功能的 bug 最多。
   • 原因在於對資料庫連線操作的不熟練，產品還未釋出。
6. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
   • 程式碼複審是團隊成員各種檢查各自的程式碼，是按照程式碼規範執行的。
7. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 產品原型設計應付出更多的時間和人力，如果重來一遍會花費更多的精力去進行產品原型設計。

測試/釋出

1. 團隊是否有一個測試計劃？為什麼沒有？
   • 無測試計劃，大多數時間都在進行開發，時間緊迫。
2. 是否進行了正式的驗收測試？
   • 是。
3. 團隊是否有測試工具來幫助測試？
   • 沒有。
4. 團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
   • 沒有進行相關測試。
5. 在釋出的過程中發現了哪些意外問題？
   • 暫未釋出。
6. 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
   • 會多留出更多的緩衝區時間，來進行測試。

團隊的角色，管理，合作

1. 團隊的每個角色是如何確定的，是不是人盡其才？
   • 結合個人意願由 PM 統籌。
2. 團隊成員之間有互相幫助麼？
   • 有。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
   • 通過團隊討論解決的。

總結

1. 你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
   • CMMI 的初始級。
2. 你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
   • 規範階段。
3. 你覺得團隊在這個里程碑相比前一個里程碑有什麼改進? 
   • 有了更深的瞭解，團隊個人相關知識也得到了提高。合作效率也因此提高。
4. 你覺得目前最需要改進的一個方面是什麼?
   • 果然還是應該先掌握具體知識再進行專案開發會比較高效。
5. 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 
   • 我們團隊每週結束時都會對上週的工作進行討論，並計劃下週的任務，所以能時時總結如何提高團隊效率，並付諸行動