設想和目標

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

• 軟體以微信小程式為載體，以影象識別為方向，以CNN神經網路為模型，以ENAS為優化工具進行設計開發，主要解決ENAS的CNN模型實現問題。
• 軟體定義為科研專案，實際上對專案產品的定位並不是非常的清晰，通過與老師交流後初步定義為上述框架，主要呈獻給使用者的就是微信小程式。
• 對於典型使用者，實際上所有微信使用者都可以作為產品的使用者，這是一個異常龐大的團體。而對於典型場景來說，理想狀態下是對某一物體或場景不認知時提供識別幫助，實際上我們目前所做的訓練集較為簡單，識別出的物體也侷限於現有的很容易認知的事物。

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

　　從專案完成情況來說，確實達到了預期的目標，本次迭代主要以框架部署搭建為基準進行實施，為第二次迭代開發作為軟體基礎，主要實現了以下功能塊：

• 原計劃功能：

　　　　前端頁面設計與頁面互動，資料互動，伺服器搭建及環境配置，識別手寫體功能實現及部署

• 實現情況：

　　　　前端頁面基本按照設計完成，頁面互動的設計已經實現，但是在和伺服器進行連線的過程中還不夠完善，資料的傳入傳出和資料庫的建立還沒有實現。

　　　　伺服器搭建已經成功實現，並且已經成功將程式碼部署在伺服器上，實現了對伺服器的應用。

　　　　能夠成功實現手寫體識別，並且實現了影象處理功能，使得程式可以直接識別使用者上傳的內容，並且具有一定的精準度。

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

• 科研專案，以我認知而言沒有使用者量這一概念，並且由於小程式的稽核，https加密，域名備案等限制小程式的上線和釋出，所以就當前開發版本而言沒有使用者量可言，並且使用者量在該專案中變得毫無意義。
• 前端、後端以及前後端框架實際上在本次迭代中都已經完全部署，我們的最終目標實際上大頭部分為ENAS的實現，小頭部分為微信小程式功能的實現，現在第二部分實際上都已經實現，可以說離目標更進一步。

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

　　以我而言，專案的分工實際上並不明確。這在本專案中確實很難做到，我作為前後端連線部分以及後端模型的實現，實際上要把前端後端和flask框架均要學習，滲透到專案的方方面面。這當然會導致一部分工作過剩，另一部分工作無法分配的情況。組內成員的分工也變得異常困難。當然如果重新再開始一遍，小組內的人員分工從一開始就應該劃分好界限，哪怕一些人在α迭代中只作為學習人員，也不能混合起來。專案作為ENAS的應用實現，對於組內大部分人員都有很大的難度挑戰，專案的學習週期過長，沒有很好的將時間利用起來。

計劃

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

　　時間相對來說還是較為充足，專案本身較為簡單，並不是大型的專案，只是對演算法要求相當的高。但是因為指導老師並沒有給我們明確需求的原因，整個專案的計劃並沒有十分的明確，知道α迭代結束時，我們也只是象徵性的做了一個需求分析的嘗試，具體的需求很多需要在專案跟進的情況下繼續去實施。因此而言，我們很早的就開始著手進行專案的開發和學習，在不斷的摸索過程中進行深度的動態需求分析。

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

 　　團隊實際上分工是由PM來決定，但是由於專案的演算法性質，以及團隊裡面的開發人員有較為豐富的演算法經歷，所以大部分計劃分工或者是不同的意見都是優先考慮我和另一位開發人員，罕有不和的時間，有也是組內人員少數服從多數或者商量糾正。

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

 　　團隊的工作除了資料庫的部署和設計放在了第二次迭代計劃中，其他都完成。

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

 　　有。由於整個專案，我做前後端連線部分，因為沒有任何經驗，甚至連框架都不知道用什麼，開始學習了很久的diango框架，最後採用的flask框架，做了很多無用功。其次在伺服器https的配置上也走了很多彎路，導致Apach和Nginx並存的現象出現。

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

 　　沒有，大家都在一起做，溝通都很及時，沒有絕對標準，標準隨時溝通調整，分別做出來可以分別跑通以後就直接整合對接。

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

•  是按照計劃進行，但是有意外發生，在做模型時意外發現忘記考慮使用者上傳圖片與測試集的處理，又分出了額外的大部分精力去處理影象。
• 顯然上面的影象處理就是一個沒有考慮到的風險，當時考慮到框架和模型，但是做計劃時並沒有考慮到資料的流通和格式匹配問題。

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

　　有留下緩衝區，在緩衝區時間裡對專案程式碼的規範性做了優化以及處理測試時遇到的意外情況。

8. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

 　　由於接下來的專案難度較大，所以可能會需要較長時間專注於專案，並且要著重實現完成專案，可能會減少緩衝區的設定，多加班。

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

　　顯然在專案中我完成了從0到1的蛻變過程，從根本上理解了一個專案的框架時如何建立的，整個專案是如何搭建起來的。同時對於伺服器的配置以及前端設計都做了詳細的瞭解，可以說已經開始入門，同時對於CNN神經網路的認知有提升了新的高度。

資源

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

　　時間資源上，我們的時間還是比較充分的，完成任務的過程中也沒有時間緊張感，但是也由於前期任務工作量過少，導致現階段迭代任務量大，難度過高。軟體資源上，我買了一個騰訊雲伺服器和域名除此之外沒有其他資源的支援，實際上老師所給的ENAS論文資源已經足夠支撐起整個專案的研究。

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

• 時間主要是按任務量估計，時間按各自的安排估計。
• 其他資源不多，估計度這裡不再給出。
• 專案整體精度不好，不能總是保持高效且時間安排總會有意外的衝突。實際上整個專案在α迭代完成時也沒有給出迭代開發每個計劃任務的時間節點，只有最後一個總的deadline，這是不好的。

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

• 測試沒有系統、詳細的安排，在最終整合之後，有做了簡單的測試，沒有花費很多時間。
• 人力資源足夠（即便我們組人數最少），硬體缺一個好的GPU伺服器來提高演算法的速度。
• 美工的任務量較少，需要完成的內容不是很多，但是美工的資源實際上從網上進行下載之外並沒有其他的途徑，美工資源不足並且第一次跌代截止時美工尚有待提高。

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

　　並沒有，實際上我的任務量不是很大，主要是難度上的問題，包括伺服器配置和前後端連線。在這個過程中與小組內的其他同學也進行了詳細的交流，有問題大家一起學習和解決。

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

　　沒有向指導老師尋求更多的幫助，比如伺服器域名資源，影象測試集和UI資源等。

變更管理

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

　　每天都會在群裡討論，確保所有人的資訊平等全面。

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

 　　一開始就決定了主體功能，主體功能沒有調整過，附加功能都屬於可推遲（但並沒有推遲）

3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

　　完成CNN對普通圖片的處理並將結果通過微信反饋給微信前端。

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

 　　並沒有制定應急計劃，實際上並沒有計劃變更。而且我有資訊在需求變更時及時對需求設計進行調整，總體來說並不會有大的變更，演算法部分更不可能。

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

 　　哈哈哈算是有吧，老師突然要求製作一個數據集，全組人員不分白天晝夜分分鐘跑出來馬不停蹄的把資料集做了出來。

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

　　變更管理之一部分實際上並沒有特別多的事情，專案都在有條不紊的進行，當然對於需求來說，如果要變更專案，需要提前小組內開會討論具體的專案實現。實際上老師在第二次迭代時請求過變更專案方向，整個小組做了緊急討論，最終敲定一個最終結果，還是寫一個應急計劃為好。

設計/實現

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

　　整個模式的設計是在專案初期，由pm和老師溝通商定的。實際上在前八週設計開發過程中都有設計工作。

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

　　沒有，每一個設計都需要詳細的討論是否可行，每一個做出的決定都帶有很強的目的性和可行性，不存在模稜兩可的情況。

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

　　小組使用UML圖進行詳細的專案分析管理，通過活動圖、用例圖等分析專案的需求和物件。下面是小組設計的整個框架模型：

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

• 文件更加豐富了，會在專案推進中，不斷完善、更新文件。同時隨著對專案的不斷理解，對UML文件進行了更新與完善，加強了對UML文件的設計。
• UML需要更新，我們沒有設計ENAS演算法的UML圖，實際上整個演算法才是專案的核心內容，在聽取老師建議後需要對演算法設計UML圖。

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

 　　通過組與組之間程式碼互審進行的。我們的程式碼的程式碼規範有些缺失。

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

 　　多使用UML對專案進行設計，專案的類和需求等嚴格按照UML設計的內容進行分析，同時互動性的對UML圖進行更新和完善。同時建議使用程式碼管理平臺，否則更新時對伺服器不友好，而且已經導致了不少因為伺服器衝突導致專案測試出錯的案例。其次需要對程式碼的規範性進行復查和嚴格稽核，程式碼的規範性尚有待提高。

測試/釋出

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

　　有針對驗收標準進行商議和參考，但是沒有針對具體的計劃。因為在初期迭代期間，我們以實現為主，完成是我們的工作重心。很大一部分專案都在摸索和嘗試性的進行，完不完成都是一個未知數，更別提測試。當然第一次迭代之後會對專案設計測試計劃，對ENAS的效能進行系統測試。

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

　　是

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

　　沒有

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

　　暫未考慮

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

　　小程式的釋出需要備案稽核等，不考慮進行釋出。

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

 　　程式的完成與測試還是重點，同時要合理安排時間，留下確切的冷卻期。專案做的過程中就會有很多次測試，如果第二次迭代開發有剩餘時間，大家可能會制定比較詳細的測試方案，同時在以後專案設計過程中要進行測試設計，專門分出專案測試員對專案進行系統且規範的測試。

團隊的角色，管理，合作

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

　　團隊角色確定，以尊重個人意願為首要因素，再根據實際情況協商確定角色。雖然分工有點混亂，前期主要以學習和幫助為主，我個人認為一個現階段專案還是多讓大家參與為主。

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

　　大家相互幫助才能共同進步，同時加快專案的進展。

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

　　大家共同商量，綜合每一個人的意見，選取最符合大家要求的解決方式。

總結:

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

　　屬於CMMI一級，完成級

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

　　磨合基本完成，接下來是規範

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

　　大家彼此更加熟悉，互相的配合會比之前更有效率，同時漸漸有了明確的分工和側重點，比如我們這邊PM側重前端開發，而其他人員多側重與後臺演算法設計，我主要側重與前後端互動部分。

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

　　提高效率，劃分分工界限。

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。 

　　在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。我們小組每週都有交流，也每週都會開會討論，不管線上線下（雖然有的時候沒有寫會議記錄）。大家相互之間的交流也有助於我們進步。而且大家相互幫助，在面對問題時互相助力，共同解決。