團隊過後分析

設想和目標

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

Gamma階段原計劃的密碼找回功能，排名功能，移動端的適配功能等均作到了，按照時間交付了，原計劃的目標用戶200已經達到，目前Django後臺記錄的數目爲243個用戶。

和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

整個團隊的軟件工程質量提升了，咱們有WIKI來保存全部的完整文檔，全部的文件均有完整的註釋，而且經過Code Review，測試保證等方式確保了代碼質量。

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

這個階段咱們肯定了任務的優先級，改進了燃燼圖，加了任務總量這條曲線，PM能更好地把控任務進度。由於家庭的緣由，PM有段時間未在學校，若是重來一遍的話，PM應該會更加註重進度的把控，隨時push團隊成員。

計劃

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

咱們在每一個階段的末尾都會提早討論下一階段的任務，在階段的開始又會再次肯定好階段任務，所以是有充足的時間來肯定計劃的。

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

咱們都是當面討論，討論任務的可行性和複雜性，針對你們提出的考慮來判斷是否要作這個任務。

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

都作完了，只是部分任務的完成度沒有過高，由於時間仍是有必定的不足。

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

前端的分頁功能，實現起來太過於複雜，老是出問題，其實如今以爲讓後端分頁更簡單。

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

有。每一個任務都肯定了優先級以及相關人員。

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

基本按照計劃進行。安全性問題在Alpha初期沒有考慮到，準備添加在Beta階段任務中，可是在Alpha階段末尾網站忽然被攻擊，於是採起了必定的緊急措施，恢復了網站的正常功能，避免了再次被攻擊。

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

留下了必定的緩衝區。任務執行時出現突發狀況時，緩衝區就可以避免任務整體進度出問題。

資源

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

完成全部基本功能的資源足夠，可是在完成一些比較麻煩的功能例如移動端適配的時候，時間不太足夠於是不太完美。

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

主要是由開發和測試人員依據Alpha，beta的經驗來估計，精度比較準確。

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

資源足夠，對移動端的適配低估了難度。

變動管理

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

咱們組變動管理部分作的比較好，咱們主要經過微信羣進行交流，所以項目任務有變動時團隊成員很快就能獲知。

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

咱們使用了本身設計的燃盡圖，其中有一項是當前任務總數，PM能抓住重點，及時判斷任務可否完成，進而將下一階段的任務提早或者砍掉某個任務。當某階段任務穩定而且所有完成後，就達到了該階段的出口條件。

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

咱們有必定的應急計劃，好比咱們在網站受到攻擊時，應急修復，在1.5小時就讓網站成功從新上線，儘量減小了用戶的損失。團隊對於這類意料以外的任務處理起來也比較順利，隊員能主動認領，有效處理。

設計/實現

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

後端的設計工做是在後端的線上會議的時候敲定的。設計由後端的兩位同窗，結合項目具體狀況，共同擬定。前端的設計工做是由UI和前端開發成員你一塊兒決定的。

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

在設計中，咱們遇到了這樣的狀況。好比，原項目中，並無採起先後端分離的設計方式，而是由後端所有完成，返回html給前端。咱們在發現了這個設計以後，通過討論，以爲不符合咱們的項目設計。決定更改總體的設計。

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

後端的代碼複審，一般是一位後端的開發在完成了本身的任務後，經過issue或者即便通信軟件的形式，聯繫另外一位後端開發同窗，通知他開發已經完成。再交付測試同窗以前，另外一開發同窗須要閱讀實現了的代碼，結合已經擬定好的後端接口文檔，以及代碼的規範要求，對於代碼的功能已經標準性進行復查。若是遇到不合規範的狀況，會在issue以及即時通信工具中提醒，要求開發人員進行更改。

測試/發佈

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

團隊有完整的測試計劃。也有測試工具，而且進行了驗收

Gamma測試工做反思

沒有考慮到測試樣例執行速度的問題，雖然是放着跑一下就完事了，但會佔着那麼久電腦，並且每次跑都要跑那麼久確實是個問題。
測試樣例的管理問題，雖然我當初的理想是使用tag進行管理。但事實上對上百個樣例使用tag來進行管理真的是個折磨。一套更方便的管理系統可能更好，這有助於在測試樣例執行速度沒法提高的狀況下選擇性地進行測試。
對需求變動的即時響應問題，雖然我使用了page object方便了同類測試樣例的批發式編寫，但問題是當page自己發生變動時，個人即時響應方面，雖然工做量不大，但存在較高的抽象複雜度。由於我和前端那邊對頁面的抽象方式不一樣，因此每次他們修改我都要想一想怎麼適配成我這邊的邏輯。手工工做量是減小了，但思惟工做量增長了。

總結

團隊目前的磨合很是不錯，處於「創造」階段。整個Gamma階段，在PM因特別緣由的缺席下，也能不延期地完成全部任務。同時團隊成員也注重了軟件工程的質量等，對安全性測試，兼容性測試，以及使用自動化測試工具等都很是熟練，相比起Alpha階段和Beta階段來講，咱們組已經成爲一個相對「成熟」的軟件工程團隊~