項目初嘗試——α迭代感想

　　

設想和目標

1. 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

咱們的項目名稱是基於pytorch圖像識別的enas，從名字上就能瞭解到這是一個比較偏向於技術的項目，屬於一種科研性項目。軟件最終只須要實現簡單的圖像識別便可，可是難點在於要實現enas優化，而且須要是在pytorch框架下運用CNN網絡進行實現。從項目名稱來講這個項目的定義仍是很清楚的。

在典型用戶和典型應用場景的描述中，咱們並無指定很明確很具體的用戶，幾乎是全部可使用小程序的，須要進行圖像識別的均是咱們的用戶，而場景就在於用戶對某一物品不夠了解，或者不能肯定這個是什麼東西（不過咱們的訓練集中涉及到的物品都比較簡單，沒有很具體詳細的劃分），在這樣的場景下進行使用。

 

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

在α迭代版本，咱們主要是對服務器進行部署，而且初步實現CNN網絡識別，可是你們都不具有經驗與項目基礎，因此咱們在初期運用手寫體的識別進行項目入門。

• 原計劃功能：

　　　　前端頁面設計與頁面交互，數據交互，服務器搭建及環境配置，識別手寫體功能實現及部署

• 實現狀況：

　　　　前端頁面基本按照設計完成，頁面交互的設計已經實現，可是在和服務器進行鏈接的過程當中還不夠完善，數據的傳入傳出和數據庫的創建尚未實現。

　　　　服務器搭建已經成功實現，而且已經成功將代碼部署在服務器上，實現了對服務器的應用。

　　　　可以成功實現手寫體識別，而且實現了圖像處理功能，使得程序能夠直接識別用戶上傳的內容，而且具備必定的精準度。

 

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

 暫時未投入使用，小程序並無發佈，用戶實際接受程度未知。

經過本次迭代，成功鏈接先後端，完成前端頁面，實現服務器的配置與使用，距離目標固然更進一步。

 

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

 本次迭代實現了預期的安排，可是當時在安排的過程當中對項目的分工不夠明確與合理，致使前期工做量不是很大（你們主要在於學習與理解，經過多種方式實現本身的技術困難）。可是無論如何後期工做量都比較艱鉅，實現須要時間與精力，在後期任務較爲艱鉅困難。若是重來咱們會對開發的階段進行從新分工，讓分工更爲合理，也更加早的開始完整項目的實現。

 

計劃

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

首先咱們的項目需求比較簡單，從項目總體進行分塊的話也不會分不少塊，因此在計劃階段比較麻煩。在前期確立需求花費時間較少，可是在對項目進行細分的時候就遇到了問題，在作計劃時也是沒有很順利的將計劃作出，只是有了一個大概的輪廓。

 

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

 

計劃階段討論都很順利，沒有太多不一樣的意見，可能這也是不足的地方。

 

3. 你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

 

團隊總體項目推動較爲，alpha版本的計劃都作完了

 

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

 你們的工做過程都是比較有意義和價值的，沒有存在沒價值的狀況。只是戰線較爲拖延，花費時間較長，有一些沒必要要的時間浪費。

 

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

 沒有，你們都在一塊兒作，溝通都很及時，沒有絕對標準，標準隨時溝通調整，分別作出來能夠分別跑通之後就直接整合對接。

 

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

 

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

 

 

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

有留下緩衝區，而且在實際運用中證實緩衝區是頗有做用的。

 

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

 因爲接下來的項目難度較大，因此可能會須要較長時間專一於項目，而且要着重實現完成項目，可能會減小緩衝區的設置，多加班。

 

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

 在此次咱們每一個人都有所收穫，我學到了許多前端的相關知識，經過製做小程序，瞭解到了小程序的製做要求和許多關於小程序的API與設計的相關內容。咱們會更加準確的分工，明確時間，對任務進行正確而詳細的劃分。

 

資源

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

咱們的時間仍是比較充分的，完成任務的過程當中也沒有時間緊張感，可是也因爲前期任務工做量過少，致使現階段迭代任務量大，難度太高。

 

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

 時間主要是按任務量估計，時間按各自的安排估計。項目總體精度很差，不能老是保持高效且時間安排總會有意外的衝突。

 

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

測試沒有系統、詳細的安排，在最終整合以後，有作了簡單的測試，沒有花費不少時間。人力資源足夠（即使咱們組人數最少），硬件缺一個好的GPU服務器來提升算法的速度。美工的任務量較少，須要完成的內容不是不少，也就順利完成。

 

 

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

因爲項目比較難，因此大佬們都去攻克較難的關卡了。若是個人任務讓大佬們去作確定會更快也更輕鬆容易就能夠完成的，可是同時難關就不是很好解決了。因此雖然結果是確定的，可是咱們如今的佈置與安排也是沒有大問題的。

 

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

 分工不夠細緻，你們至關因而一團人一塊兒去作一件事情。時間安排上也不太合理。若是能重來，要把分工作的更加明確，將時間調整作的更加詳細具體。

 

 

變動管理

1. 每一個相關的員工都及時知道了變動的消息?

你們天天都會在羣裏討論，確保全部人的信息平等全面。

 

2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

 

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

 

 

3. 項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

完成手寫體的識別而且成功用小程序實現。

 

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

 

沒有提早制定應急計劃，但有變動時會及時作出反應和調整

 

 

5. 員工是否可以有效地處理意料以外的工做請求？

 你們的及時調整都很棒，對於意外的發生也能作出迅速的反應

 

 

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

這一部分你們都作得不錯~ 

 

設計/實現

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

 

整個模式的設計是在項目初期，由pm和老師溝通商定的

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

 

2. 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

沒有

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

有UML圖來幫助設計，也有不少的設計素材網站爲咱們提供了不少圖片素材

 

4.比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

檔更加豐富了，會在項目推動中，不斷完善、更新文檔。同時隨着對項目的不斷理解，對UML文檔進行了更新與完善，增強了對UML文檔的設計。

 

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

 經過組與組之間代碼互審進行的。咱們的代碼的代碼規範有些缺失。

 

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

 增強代碼規範，加強代碼的可讀性。

 

測試/發佈

1. 團隊是否有一個測試計劃？爲何沒有？

有針對驗收標準進行商議和參考，可是沒有針對具體的計劃。由於在初期迭代期間，咱們以實現爲主，完成是咱們的工做重心。

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

是

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

沒有

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

暫未考慮

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

 小程序的發佈須要備案審覈等，不考慮進行發佈。

 

咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?

 程序的完成與測試仍是重點，同時要合理安排時間，留下確切的冷卻期。

 

團隊的角色，管理，合做

    1. 團隊的每一個角色是如何肯定的，是否是人盡其才？

 

　　團隊角色肯定，以尊重我的意願爲首要因素，再根據實際狀況協商肯定角色

 

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

　　你們相互幫助才能共同進步~

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

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

 

總結:

你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

屬於CMMI一級，完成級

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

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

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

　　　你們彼此更加熟悉，互相的配合會比以前更有效率

 你以爲目前最須要改進的一個方面是什麼?

　　你們總體較好，須要增強效率，提升每個人的相互熟悉配合程序。

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。 

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