Gamma階段過後分析

Gamma階段過後分析

設想和目標

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

• 咱們要解決的問題：實驗室招生信息分散，以及創意與實現分離難以合做
• 典型用戶：現階段面向在校生與實驗室
• 典型場景：

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

• 原計劃的功能：合做、委託、創意發佈以及基本的論壇功能；後期通過論證砍掉了委託加入了實驗室站內信關注收藏等功能
• 交付時間：雖然前階段存在開發失敗推遲交付，但Gamma徹底按照原計劃執行完畢
• 用戶數目：130+初步達到預期目標

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

有必定提升，主要體如今：

• 團隊合做：通過一段時間的磨合，你們的合做逐漸完善，每一個人都清楚本身的職責，可以積極完成任務
• 工做質量：隨着前兩階段的鍛鍊學習，可以把大部分時間分到開發上，學習新內容時間減小，代碼質量提升，bug數目減小(單階段十幾個bug減小到五六個)

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

用戶量在預期以內，可是用戶對重要功能的接受程度和咱們預想的有一些誤差。用戶更加青睞於使用實驗室功能，咱們對此調整了實現目標與用戶保持一致。

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

• 經驗教訓：必定要制定完整的計劃，而且有詳細的實現論證。在實現過程當中發現以前的一些想法實現起來不可行，調整很頻繁。
• 若是能重來：推行結對開發，對可實現性進行多方合做論證，深刻討論細節內容實現

計劃

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

是的。能夠預先拿出半周的時間進行計劃和討論。

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

實際不一樣意見並未產生不少，咱們注重考慮開發人員意見。

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

都完成了。砍掉了一部分不須要的，也加入了一些新的。

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

並無。某些功能(委託)在作以前有發現並不須要，因而提早砍掉了。

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

沒有過於具體的交付標準，考慮實現方式與實用性雙重標準，具體到頁面要求的內容，但不拘泥版式。

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

alpha階段存在開發失敗，beta階段發現了一些多餘功能，而且要從新學習新知識。項目轉會人員過於重要，後端技術人員所有轉會，形成後端重寫。沒有料想到時間會很緊張故疲於應對風險。

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

有留下兩三天的緩衝區。緩衝區用於修復一些反饋bug以及增長突發奇想的小功能。

8.未來的計劃會作什麼修改？

歸入你們的我的事務規劃，更加合理分配任務。

9.咱們學到了什麼？若是歷史重來一遍，咱們會作什麼改進？

聚合相同的任務交付一人完成，沒必要拘泥平衡任務量，提升耦合質量。

若是重來一遍，咱們將進行動態任務規劃，減小忙等待現象。

資源

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

時間資源不足。機器資源充足。

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

根據代碼量與代碼質量評估，最後階段精度很好。

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

測試時間略緊張，人力也略緊張(5人)。硬件資源充足，不須要編程的資源並很少，難度也不大。

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

有一部分任務確實能夠交付同一人作更有效率和質量。

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

人力與時間資源將極大影響進度。

若果重來一遍，咱們將在Beta階段開始時多招收兩位成員。

變動管理

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

是的。實現完成後會在羣內交流並push接任工做者。

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

根據用戶訪問量以及用戶反饋，進行權重調整。

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

要有三個標準：美觀、實用、沒有bug。

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

是的，會集中力量解決出現的問題。

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

是的，團隊成員能及時處理額外任務請求，而且自發實現接下來功能的開發實現。

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

每一個人要作好本身的事情，對團隊負責。

若是能重來，咱們會要求使用少許時間加多註釋以及寫一些開發文檔，但實際上咱們的時間並不充裕。

設計/實現

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

設計由全體成員共同制定，在實現開始之初，是合適的時間與人。

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

有一部份內容不能肯定，留待開發時進行嘗試選擇，着重考慮開發人員意見。

3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

運用了測試單元來幫助設計實現，有必定效果。相對於項目開始UML基本推到重寫，由於咱們重寫了後端。

4. 什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

站內信bug最多，發生站內信重複發送現象，缺失現象等。主要是測試不是很全面，以及測試時間不充足，發佈前實現的功能難以測試全面。

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

代碼複審主要由先後端的開發經理進行，規範並非很嚴格，還需提升。

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

敏捷工程要善於應對各類突發情況，提早一些時間完成規劃。

若是能重來，咱們準備將整個計劃提早1~2天，留下足夠緩衝區進行穩定性測試。

測試/發佈

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

團隊有一個粗略的測試計劃，測試人員有一個詳細的測試計劃。

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

進行了正式驗收，不合格將打回修改。

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

使用了Django coverage來跟蹤咱們的單元測試的代碼覆蓋率，並進行改進提升。

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

主要是壓力測試。從測試工做來看，找到了一些多餘代碼，可是用處不是很大，提高有限，大的改進仍是要看實現代碼。

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

密碼修改能夠修改成任意格式，是咱們疏於測試。

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

咱們的經驗：須要進行足夠多的測試來保證穩定性。

若是重來一遍：進行代碼實現的論證改進，實現額外的加速。

團隊的角色，管理，合做

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

考慮了我的意見，你們都是去作想作的工做。

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

有的，結對編程的習慣延續了整個開發流程。

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

肯定責任人，進行再次討論和修改，當面討論的方式頗有效。

總結

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

咱們認爲，在通過了總體開發流程後，咱們的團隊基本達到了「管理級」的要求。

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

咱們認爲咱們的團隊達到了「規範」階段的基本要求，已經有了比較高的自覺性與責任感，合做沒有出現矛盾，彼此感受良好。

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

代碼規範。這已是屢次強調的問題了，可是仍是常常發生，不一樣成員認爲的標準有一些差別。

4.對比敏捷的原則，你以爲大家小組作得最好的是什麼？

應對了屢次突發事件，艱難堅持到了最後。

• 存在開發失敗版本
• 後端開發人員轉會
• 小組成員時間緊張(工做、實驗室、比賽、考試)

可是，咱們最終按計劃完成了開發。

5.在下一階段中咱們要改進的地方

• 穩定性：提升壓力負載能力，優化代碼架構
• 代碼規範：嚴格要求格式，加大審查力度
• 宣傳工做增強：咱們用戶數量不太多，須要更加廣範的宣傳

小組成員合照

(mm同窗回家一週，暫時沒有線下合照)