設想和目標：
1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
問題定義：目前有一種情感維度理論，我們要用機器學習的方式給出人臉的維度值。
典型場景1：使用者通過視訊檔案輸入，軟體需要輸出視訊中每一幀人臉情緒的維度值。
典型場景2：使用者通過本地攝像頭實時獲取人臉資料，軟體需要實時給出情緒維度值。
2. 我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)
場景一的功能實現了，但只是在程式碼階段，沒有做到易操作的客戶端上。場景二功能還未實現。
3. 和上一個階段相比，團隊軟體工程的質量提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
有所提高，軟體質量和團隊合作都有提高。現階段客戶端介面更加美觀，團隊合作更加緊密，合理根據成員特性分配相應任務。
4. 使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
重要功能和預想一致，但使用者體驗未達到預期。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
除了學會了很多技術，更重要的是知道了如何更好的團隊合作。如果重新來過，我們客戶端肯定會利用開源模板和框架以加快開發，以及團隊合作的任務任務分配會更加細化，
不會像之間一樣籠統，因為任務劃分不細每週會議上很難評估。

計劃

1. 是否有充足的時間來做計劃?
一開始對專案需要的技術和難道不夠了解，導致第一次迭代計劃不合理。
2. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
共同商議投票決定。
3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
都有安排做，但有些未完成，因為有些內容涉及的技術比較難。
4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
有，有些工作做了一半發現可以以更簡單的方式實現。
5. 是否每一項任務都有清楚定義和衡量的交付件?
沒有細緻的分配任務，大多工都是籠統的一句話：實現什麼什麼功能，具有什麼輸入什麼輸出，也沒有衡量交付件。
6. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
按計劃進行。
7. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?
沒有留緩衝區。快取區可以解決出現的計劃之外的難題。
8. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
之前規劃的第二階段功能可能不能實現。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
專案前了充分了解才能做出合理的計劃；任務佈置一定要詳細，並且要有衡量交付件。

資源

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

• 時間不足，訓練集比較大，訓練的速度慢，沒有更好的硬體環境，導致神經網路模型優化緩慢
• 總的技術水平不足導致人力資源不夠，隨著知識的學習而有所改善

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

• 專案開始時由於對專案不熟悉，時間與資源估計不到位
• 精度不足，經驗與知識的不足，導致許多工衝突，而拖累了進度

3、 測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

• 簡單整合之後進行了測試，發現存在不少bug，測試時間不夠
• 硬體資源不足，網路模型的測試較為花費時間
• UI的設計一般，最後採用了網路上的模板

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

• 任務的分工我們是按照不同人擅長的技術而進行的分配，基本不存在這個問題

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

· 時間估計不足，python與jsp的整合難度估計不到位

• 更加註重前端的設計，以及前後端的連線問題，而不是把重心放在後臺網絡模型，由於硬體的限制而拖慢了專案的程序

 

 變更管理
1.       每個相關的員工都及時知道了變更的訊息?
都可以及時知道，這是因為我們每週都會召開不定期的小組會議，就現階段遇到的問題進行討論和解決，這使得我們每位小組成員都很清晰地知道我們的專案進度；我們還有一個專案日誌，記錄著修改程式碼的時間以及操作人，便於進行管理，同時每個小組成員都會擁有一份程式碼，保證程式碼不會丟失。
2.       我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
我們小組採用了集中討論並且尋求有類似專案經驗的學長以及老師的意見和建議的方法來決定“推遲”和“必須實現”的功能;其中，最重要的一點還是我們以專案的核心演算法為核心來確定其為“必須實現”的功能，類似於部署到伺服器上為“推遲”功能。
3.       專案的出口條件（Exit Criteria）是否得到清晰的定義?
“出口條件”，其實就是專案有沒有達到設計的標準，也就是說專案能不能滿足使用者的各種需求，在我們小組的專案中，是直接奔著使用者的需求去做的，也和使用者（也就是老師）就行了很多溝通，能實現人臉情緒識別，所以Exit Criteria得到了很好地滿足。
4.       對於可能的變更是否能制定應急計劃?
基本沒有，雖然在專案中每個人都有自己的分工，但是每週召開的小組會議以及遇到問題無法解決及時討論，再加上專案開始的前期，整個小組都是集中一起在學習專案的核心演算法內容，每個小組成員都對專案的整體框架有著大致清晰的把握，所以對於可能的變更，小組內部經過短時間的討論就能制定一個簡易的應急計劃。
5.       員工是否能夠有效地處理意料之外的工作請求？
每個人的分工是由每週的進行的小組討論總結決定的，在分工的過程中，是根據每個人的能力以及空餘時間情況，相對公平科學合理的分配的，對於處理意料之外的工作請求，PM也會先召開小組會議，在根據實際情況來處理這個意料之外的工作請求。

 

設計/實現

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

整體設計是在專案開始時討論設計出來的，後續多次小組討論，與老師交流對原有設計進行修改，調整；在迭代時對設計進一步優化，美化。設計工作非一蹴而就，全組成員都為設計工作貢獻了一份心力。

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

有。就看具體執行的人是如何解決的，有的解決得好，大家並不知道出過問題；有的經常拿出來討論，大家討論解決問題。功能需求方面的問題則是同指導老師交流，徵求老師的意見和需求，最終敲定需要實現的功能和滿足使用者的需求。

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

運用了騰訊敏捷開發平臺（TAPD）記錄專案，建立周計劃與總結文件安排每週工作和總結每週的成果。還對每個階段每個人要完成的總體功能了進行了規劃與安排。較為有效，實現了對專案工作實時追蹤與記錄。

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

前後臺的連線方面問題較多，主要是因為前臺用Java編寫，後臺功能程式碼是用Python編寫的。不同程式語言間的互動連線還是有困惑之處。

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

程式碼複審是小組交換審查，主要還是程式碼變數、函式、類命名的問題，大家寫程式碼搭建框架時都專注於功能是否完成，命名方面注意的很少，大多命名都不太符合規範；部分程式碼可能來源於網路的開原始碼，只關心能不能用，結果對不對，哪管命名是否符合檢查要求。再就是註釋問題，有的地方缺乏註釋，有的地方註釋又太多，影響對程式碼的閱讀。

 

測試/釋出
1.團隊是否有一個測試計劃？為什麼沒有？
暫時沒有，因為程式設計過程中就包含了測試
2.是否進行了正式的驗收測試？
第一次迭代驗收
3.團隊是否有測試工具來幫助測試？
暫時沒有
4.團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
自行進行了資料的測試，測試工作有用，我們發現專案中還存在一些bug，有待修復，我們也發現一些功能實現效果體驗欠佳，有待完善與優化。

 

 

團隊的角色，管理，合作

1. 團隊的每個角色是如何確定的，是不是人盡其才？
根據每個人已掌握的技術和感興趣的方向安排的，可以說是人盡其才了。
2. 團隊成員之間有互相幫助麼？
在會議上和共同討論技術時都是互相幫助，回去後在團隊群裡的需求幫助可能缺少。
3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
讓沒人人說出自己的理由和利弊，大家投票表決。

總結

1，你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
處於初始階段
2，你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
磨合階段
3，你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
主要體現在團隊合作上會更加熟練和合理
4，你覺得目前最需要改進的一個方面是什麼?
任務佈置不夠細化，沒有合理的衡量指標