- 組長部落格
- 作業部落格
項目Postmortem
設想和目标
- 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們的軟體針對的是福大學子來到食堂會猶豫不決無法決定吃什麼的痛點，希望做出一款軟體可以根據大家的口味幫忙決定吃什麼。其中，使用者隻需要回答簡單的問題就可以得到結果，解決了普遍存在的“選擇恐懼症”。軟體的定義還是比較清楚的，這來源于我們生活中自己也遇到的問題。在編寫需求規格說明書時，我們對典型使用者進行了清晰的定義，并且通過問卷調查明确了市場上是存在對于我們的軟體的需求的。
- 我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
原計劃的目标大部分都已經完成。在實際的開發過程中，我們将一兩個功能放到了beta版本實作。
核心功能有在alpha沖刺結束時按時傳遞。盡管這次沖刺延期了一星期答辯，但大部分功能在一周前也已經基本完成。
我們的軟體分為學生端和商家端，目前完成了學生端的一個釋出版本，但還沒有公開向使用者釋出。
- 和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高，具體提高了多少，如何衡量的？
上一個階段團隊還沒有開始實際開發。如果說團隊現場程式設計作業是上一個階段的話，我們團隊的軟體工程品質的确有提高。主要展現在以下幾個方面：
- 任務分工更加清楚了，每個人有明确的分工，大家之間的配合也從無到有
- 有詳細的文檔編寫、代碼注釋風格要求。
- 團隊成員的技術水準通過學習得到了一定的提升。
- 有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
計劃
- 是否有充足的時間來做計劃?
之前有充分的時間來讨論、構想整個軟體的架構，之前布置的每一項作業——立項報告、需求規格說明書、UML圖繪制——都在不斷地讓整個軟體的輪廓在我們的大腦中變得清晰。
- 團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
在計劃階段基本沒有什麼不同意見的出現。
- 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
- 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
PM很早敲定了一些接口文檔，然而後來都廢棄了。接口文檔最後由後端實際設計前後端邏輯和設計資料庫的人來完成。可見的确PM不要涉及太具體的代碼部分的内容。
- 是否每一項任務都有清楚定義和衡量的傳遞件?
有的。在Alpha沖刺的初期，全組成員開會最主要就是讨論清楚整個業務邏輯，讨論完業務邏輯，我們再細分出各個任務，例如前端由幾個頁面組成，後端要寫哪些接口，要設計幾個表等等，這些具體的東西就是具體的傳遞件。把每一項任務配置設定給各個人，形成詳細的任務配置設定。
- 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
意外：
- 在計劃中有沒有留下緩沖區，緩沖區有作用麼?
本來是沒有緩沖區的。但是老師出差，答辯延期了一周。一下子，隊員緊繃的神經都放松了許多。然而，這多餘的一周并沒有什麼實際的額外效果。因為我們團隊在一周前也已經基本實作了大部分的功能。新的這一周，PM為團隊新制定了一些額外的目标，但基本上都沒有完成。這一插曲可以反映deadline是第一生産力這個經典的大道理。
- 将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
感覺目前整個團隊的态勢發展良好，隻要維持住目前的節奏就好了。
- 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
資源
- 我們有足夠的資源來完成各項任務麼?
有的。前端、後端各有一位小組長。這兩位同學起到了上司作用。學習資源的話，網上的資源十分豐富夠用。伺服器方面，騰訊雲10塊錢一個月的産品也是完全足夠應付目前我們的玩具産品（感謝騰訊雲）。
- 各項任務所需的時間和其他資源是如何估計的，精度如何?
其實一開始我們敲定了各個任務，但沒有衡量這些任務的完成所需時間，說實話在一開始大家都是零經驗，很難有個确定的數字。（趙暢：）不過這個情況在你真正去做了一定的開發後就有所改善，例如在有一天我完成使用者接口後，獲知寫一個敲定好邏輯的接口背景代碼需要的時間資料：寫代碼3個小時，debug+本地測試大概需要兩小時。這部分時間這麼長還是因為對于php和Web架構不熟悉的原因。如果把背景代碼部署到伺服器上讓前端對接，在前端不熟練的情況下要額外多出一天的時間預算。這樣子的精度還是足夠的，友善PM和小組長把控進度。也友善其他成員參考，留出多少時間段來進行開發。
- 測試的時間，人力和軟體/硬體資源是否足夠?
測試的時間和人力不足夠，感覺軟體還有很多缺陷，代碼也不夠完善。大家學習開發知識的同時還要應付考試，為了完成基本功能就已經費神費心，基本任務完成就感覺已經可以傳遞了，對于測試和代碼的健壯性不是太上心。
- 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
（PM：）是。将頭腦裡的設想付諸實際，其實是一件很難的事，在項目中的展現就是雖然閱讀了《material design》的設計教程，但要真正做出符合設計規範的UI界面比想象中困難很多。
- 你有沒有感到你做的事情可以讓别人來做（更有效率）?
（恒達：）任務deadline的提前量如果能更精确就好了，這樣子有利于項目進度的把控。前端界面要個确定的Ui和審美規格，重寫3次才用架構的我眼淚掉下來。
變更管理
- 每個相關的員工都及時知道了變更的消息?
Alpha沖刺時每兩日一次的站立會議交流算是一個很好的方法。此外，線上交流很友善。如果有線上聊天解決不了的技術細節問題，組内（前端組、後端組）或者整個項目組就會進行團隊現場程式設計來面對面解決。
- 我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
必須實行的功能就是項目的核心功能和Alpha沖刺實際開發過程中遇到困難較小的功能。
推遲，一般是因為這個功能可能需要較大的工作量而Alpha沖刺的時間所剩無幾，這時大家就做出推遲到Beta沖刺時完成的決定。
- 項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
在需求規格說明書中的“Alpha驗收标準”有清晰的定義。
- 對于可能的變更是否能制定應急計劃?
因為需求和項目的具體邏輯是組内制定的，好像也沒有那種變化程度太過急劇或者有提出什麼十分刁鑽的需求以至于要到“應急”的程度吧。
- 員工是否能夠有效地處理意料之外的工作請求？
項目初期對于任務的劃分基本上涵蓋了整個Alpha沖刺過程。幾乎沒有意料之外的工作變更。一般來說組長布置給組員的額外的一些小任務（例如多加個按鈕，某個邏輯有點什麼小變更，多寫個接口之類的）團隊成員也可以及時地完成。
設計/實作
-
設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
一開始準備階段就完成粗略的原型， 由 PM 實作，時間合适， 是不是适合的人...emmm...應該是了
- 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
- 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？ 比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
- 什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
-
代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
并沒有很嚴格地進行Code Review，大緻merge到master大部分都是自己在進行的，部分存在沒有完全遵守代碼規範的情況。我的部分我覺得是沒問題的 個人認為還是時間成本的問題吧，但還是應該規範起來，提高代碼的整體品質。
測試/釋出
-
團隊是否有一個測試計劃？為什麼沒有？
無
- 是否進行了正式的驗收測試？
- 團隊是否有測試工具來幫助測試？
- 團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
- 在釋出的過程中發現了哪些意外問題？
團隊的角色，管理，合作
-
團隊的每個角色是如何确定的，是不是人盡其才？
是, 分工還是較為合理的，大部分人都能做自己擅長的東西。
-
團隊成員之間有互相幫助麼？
有的，自己Android也寫的比較多，遇到的坑，爬出來的坑，相對而言多一些吧，同組的遇到問題時，能給予一些幫助。使
用過的工具也較多一些，也能給出一些推薦。
-
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
我所接觸中并沒有遇到什麼特别大的問題，最多就是一些細節問題上的探讨，将細節敲定下來就可以。
-
每個成員明确公開地表示對成員幫助的感謝 （并且寫在各自的部落格裡）：
我感謝 王彬 對我的幫助，因為某個具體的事情: 由于自身原因這階段的事情比較多，很多時候沒法很好地平衡各個事情
的優先級。然後有時候，進入無應答狀态......。然後就催促我，emm.. 然後優先級就上升了...然後得以能做完既定的東西...。
-
如果是對于我個人而言，可能需要做的就是再肝一些吧，但這學期開頭肝了一個多月，快兩個月吧，是以有點想進入點養生狀态，
是以這階段即使有熬夜也沒有特别晚就隻到一點多兩點左右，每天差不多可以說是事情都排得挺滿的，也勉強完成。
總結:
- 你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
-
你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
規範階段吧，還有一些東西能再規範一些。
- 你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
- 你覺得目前最需要改進的一個方面是什麼?
- 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | |||
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | ||
| · Design Spec | · 生成設計文檔 | 10 | |
| · Design Review | · 設計複審 | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 5 | |
| · Coding | · 具體編碼 | 50 | |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | ||
| · Test Repor | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 |
合計| | 85|80
學習進度條
| 第N周 | 新增代碼行 | 累計代碼行 | 本周學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
|---|---|---|---|---|---|
| 1 | 600 | 20 | 1. dl4j庫的使用 keras模型導入java 2. k-means java實作 3.水準投影圖像分割 | ||
| 2 | 1400 | 2000 | 30 | 1. dl4j nd4j 踩坑 還沒爬出來 2.flask最基本的使用方法。 | |
| 3 | 800 | 2800 | 25 | 75 | 1.dl4j庫存在問題(GitHub上有相同的issue) 2.準備使用dl4j訓練模型 3.複習了一些Android知識 |
| 4 | 3600 | 105 | 1.使用dl4j完成模型建立 2.處理資料集 | ||
| 4200 | 40 | 145 | 1.dl4j訓練模型 2.keras完成InceptionNet(triple loss) 3.資料集收集與處理 | ||
| 6 | 300 | 4500 | 15 | 160 | 1.溝通與項目整合 2.keras重新訓練ResNet50 3.flask完成接口 |
| 7 | 4800 | 185 | 1.複習 GRU LSTM 相關知識 2.學習word embedding, word2vec, Glove | ||
| 8 | 200 | 5000 | 1.複習Android自定義View的一部分知識 2.學習Robot Framework | ||
| 9 | 1300 | 6300 | 215 | 1.完成alpha相應任務 2.完成自己手頭上的一些任務 | |
| 500 | 6800 | 225 | 1.大部分時間投入複習要考試的科目 |