思考總結

設想和目標

1.       我們的網站要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

• 我們的網站利用了時間序列演算法，訓練使用者上傳的資料，預測未來某一時間點的資料。
• 典型使用者：期貨投資者
• 典型場景：投資時篩選期貨品種並在特定時間段內購入或拋售。

2.       我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)?

第一次迭代過程結束後，α版本的目標我們達到了。

• 原計劃的功能：實現使用者通過網站登入、註冊、找回密碼、檢視幫助文件、上傳資料集、建立模型。
•  實現情況：
  • 使用者可實現手機登入、使用者名稱登入、找回密碼、重置密碼、使用者註冊。
  • 首頁具有導航功能，可連線至可功能頁面。
  • 使用者在開發者中心可建立模型、上傳資料集。
  • 使用者可在個人中心中對基本資料進行修改並上傳頭像。
  • 開發文件中可檢視幫助文件和常見問題。
•  交付與使用者：介面中規中矩，功能還不完善。

3.       使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?

• 暫未交付使用，對使用者量未知。
• 對重要功能的認知應該會與使用者相一致。
• 離目標更近了。

4.       有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

• 第一次迭代過程中，我們做到的比較好的是及時召開會議，對上一階段任務總結和對下一階段任務分配。

計劃

1.       是否有充足的時間來做計劃? 

• 在第一次迭代前期因為知識儲備的不足，有一些功能沒有在預定的時限前實現，有些許感到時間不足。不過在之後因為熟練的緣故，所以都按時完成了。

2.       團隊在計劃階段是如何解決同事們對於計劃的不同意見的？

• 每週一次的小組討論會裡對接下來一週時間內每個人的任務分工進行明確並互相商討對於細節和整體計劃的意見，協商確定不同意見。

3.       你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

• 已全部完成。

4.       有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

• 沒有。

5.       是否每一項任務都有清楚定義和衡量的交付件?

• 是。在第一次迭代計劃中，小組成員之間互相討論，在分工實現前已明確任務點和交付件。

6.       是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

• 整體相對比較順利，未遇到未預估風險。

7.       在計劃中有沒有留下緩衝區，緩衝區有作用麼?

• 由於最後的網站搭建時間預留的有些短，所以留給緩衝區的時間也不是很多，在中期驗收當天的上午和中午全組一起測試並解決網站的bug。

緩衝區的作用為解決專案中的 bugs，完善專案。

8.       將來的計劃會做什麼修改？

• 第二次迭代計劃中我們將繼續按照原有計劃完成，但進度必須較第一次迭代有所提升，並且預留出充足的小組內部測試bug的緩衝區時間。

9.       我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

• 資料庫設計不合理，在專案後期多次更改了資料庫。
• 改進為：應更謹慎地設計資料庫。

資源

1.     我們有足夠的資源來完成各項任務麼?

• 在網站搭建過程中，網上有許多教程，這為我們的學習提供了很大的幫助。

2.     各項任務所需的時間和其他資源是如何估計的，精度如何?

• 因未有開發經驗，任務的時間與資源分配較為隨意。
• 精度不高。

3.     使用者測試的時間，人力和軟體/硬體資源是否足夠?

• 沒有系統的測試規劃，由成員自行測試。在專案合併後再進行整體測試。各資源都較為充足。
• 低估了網頁介面設計的難度。

4.     你有沒有感到你做的事情可以讓別人來做（更有效率）?

• 大家的分工都比較合理，暫時沒有這種想法。

5.       有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?

• 我們的網站搭建是從零開始，純手工劃分區域，實現功能。改進：其實對於網站的搭建我們可以使用一些模板和框架，不僅節約了一些基礎工作所消耗的時間，還能實現更多更炫的功能板塊。
• 分工不明確仔細，導致人力資源配置不合理。改進：不過我想，那時團隊成員均無開發經驗，也難以對整體專案有明確的認知，分工不明確仔細似乎在所難免。希望要先在對專案工作量後有大概的瞭解後再進行分工。

變更管理

1.     每個相關的員工都及時知道了變更的訊息?

• 大多數情況下均及時告知團隊成員了。

2.     我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

• 每週一次的小組討論會裡對接下來一週時間內每個人的任務分工進行明確並互相商討對於細節和整體計劃的意見，協商確定不同意見。

3.     專案的出口條件（Exit Criteria）是否得到清晰的定義?

• 實現預期功能，在基本使用過程中無 bug。

4.     對於可能的變更是否能制定應急計劃?

• 通過調整團隊分工和進度安排來實現。

5.     員工是否能夠有效地處理意料之外的工作請求？

• 可以。

設計/實現

1.     設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

• 設計工作在需求確定之後，主要由 PM 完成。老師提供建議，團隊成員討論確立設計。
• 是合適的時間，也是合適的人。

2.     設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

• 當出現模稜兩可的情況時，或者不能確定設計細節時，我們會通過線上討論或者利用每週的小組討論會協商確定。

3.     團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

• 運用了UML完成了專案的類圖等的設計。這些工具有效且使用方便。

4.     比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？

• UML 圖例發生了多次的更改。
• 因最初 UML 的相關知識並不充足，後期又根據具體的開發進度發生了相應的更改。

5.     什麼功能產生的Bug最多，為什麼？

• 要與伺服器資料庫連線的功能的 bug 最多。
• 原因在於對資料庫連線操作的不熟練，產品還未釋出。

6.     程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

• 程式碼複審是團隊成員各種檢查各自的程式碼，是按照程式碼規範執行的，但部分函式的命名上並未按照規範，這裡需要我們注意並修改。

7.       我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

• 產品原型設計應付出更多的時間和人力，如果重來一遍會花費更多的精力去進行產品原型設計。

測試/釋出

1.     團隊是否有一個測試計劃？為什麼沒有？

• 團隊並沒有制定一個清晰有效的測試計劃，只是在驗收前一天開始組內的測試和調整。
• 因為在後期開發節奏很快，時間有些緊張，所以完成迭代計劃中規定的功能佔據了我們小組的主要精力，而沒有意識到測試同樣需要一定的時間。

2.     是否進行了正式的驗收測試？

• 是的，由助教學姐對我們的專案進行了驗收，並提出了一些建議，我們也根據建議對β版本的部分功能塊進行了調整。

3.     團隊是否有測試工具來幫助測試？

• 無，純人工測試。

4.     團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

• 未進行相關測試。

5.     在釋出的過程中發現了哪些意外問題？

• 暫未釋出。

6.     我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

• 會制定相關的測試計劃，進行專案測試。

團隊的角色，管理，合作

1.       團隊的每個角色是如何確定的，是不是人盡其才？

• 結合個人意願由 PM 統籌。

2.       團隊成員之間有互相幫助麼？

• 有，小組成員當遇見問題時大家都會熱心幫忙。

3.       當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

• 通過團隊討論解決。

總結

1.       你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?

• 屬於CMMI 的初始級。

2.       你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

• 磨合階段。

3.       你覺得團隊在這個里程碑相比前一個里程碑有什麼改進? 

• 有了更深的瞭解，團隊個人相關知識也得到了提高。合作效率也因此提高。

4.       你覺得目前最需要改進的一個方面是什麼?

• 先掌握具體知識再進行專案開發會比較高效，並且充分利用已有資源，不要全都白手起家，從零開始。

5.       對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 

• 我們團隊每週結束時都會對上週的工作進行討論，並計劃下週的任務，所以能時時總結如何提高團隊效率，並付諸行動。