Beta階段過後分析

1. 設想和目標

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

咱們在Beta階段任務主要分爲兩部分，一類是對原功能的擴展，一類是新的博文功能。咱們經過規格說明書定義功能，至少比Alpha階段清楚多了。典型用戶和典型場景仍是沿用的Alpha階段。

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

基本達到了目標。可是計劃實現的功能太多了，最終只實現了大多數功能，一些非核心功能就被棄掉了。咱們在展現的前兩週發佈，而且達到了預計的訪問量（原計劃600，如今達到了802），只是註冊量還差一點（原計劃300，如今達到了244），不過這個結果已經遠遠優於Alpha階段了。

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

提升了。主要體如今文檔更爲明確了，咱們會根據數據庫文檔和規格說明文檔進行功能定義，沒必要在開發過程當中去糾結應該作什麼，開發功能的速度明顯優於Alpha階段。並且咱們的分工更佳明確，兩名後端一人負責一大塊，減小了溝通的花費，效率確實上升了。並且咱們優化了貢獻分分配的公式，更佳簡潔明瞭，弱化了PM主觀因素。

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

Alpha階段結束的時候訪問量爲220，如今已經突破了800，我認爲用戶量還算達到了目標。不過在發佈後又出現了不少問題，好比有些資源提示404（是課程中心的問題），還有同袍認證存在問題，以及用戶上傳的資源丟失等等，這些問題都是咱們以前從未預料過的。可是也有用戶反饋說獲取到了很難獲取的資源，這一點咱們也很欣慰。實際上，咱們在Beta階段新增了不少諸如課程收藏、資源評價等等提升用戶體驗的功能，可是如今尚未獲得用戶的反饋。

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

儘早宣傳，因爲咱們宣傳得比較晚，致使最終的用戶量和彙報時用戶量相差比較大。應該把反饋功能儘早銜接到網站上，而不是依賴於用戶羣。

2. 計劃

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

有的，實際上在Alpha階段發佈以後就已經開始考慮Beta階段的功能了。

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

在討論的時候PM主張先對原有功能進行擴展，而組員們的大體意見是先實現博文功能，以更快速地獲得反饋。這一點PM最終仍是遵從了組員們的建議。

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

沒有作完。由於咱們Beta階段少了一名前端開發，同時可支配的時間比Alpha階段要少（由於各類大做業和考試，尤爲是編譯佔得時間不少），致使時間一直很緊張。

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

有的。主要是後端開發了不少功能最終因爲前端比較緊張沒能銜接上。早知道這樣真應該減小一些功能，提升軟件工程的質量。

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

只要按照說明文檔那樣實現就能夠交付了。前端的話會事先商量，並對原型圖進行適當改動。可是感受定義得不是很清楚。

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

基本按照計劃進行，最後階段有些脫節，主要是沒有想到那一陣子這麼忙……

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

沒有設立緩衝區。

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

減小任務量，並明確各個任務的優先級。

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

精簡要實現的任務，設立優先級，根據優先級依次實現任務，這樣就算有突發狀況致使任務沒作完也能保證最核心的部分都實現。

3.資源

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

並無，咱們少了一名前端開發，Beta階段咱們用來作軟工的時間也少了不少、

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

首先咱們有了Alpha階段的開發經驗，咱們會把要實現的功能和Alpha階段已經實現的功能進行對比，比較一下難度，由於Alpha階段任務的實現時間是已經肯定的，因此能夠以此估計任務所需的時間。

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

咱們有專門的測試人員，並且後端實現的功能也會簡單進行測試，這部分資源是足夠的。咱們這裏沒有單獨的美工設計和文案人員，後期的宣傳你們都作了必定工做。

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

沒有，咱們分工都很明確了，是可讓別人來作，但是別人也有本身的工做啊。

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

咱們必定要在Beta階段開始前儘量拉人。

4. 變動管理

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

是的，重大的決定咱們會在會議上宣佈，若是沒有開會的條件也會在羣裏爭取你們的意見。至少咱們會讓和變動密切相關的成員第一時間瞭解到變動。

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

先大約估計了一下各個功能實現的成本，先實現時間肯定、成本較低的功能，也考慮了功能的重要性，但沒有將這一點放在主要位置。主要仍是時間太緊了，擔憂最後的結局是一個重要的功能沒實現完，其它功能也沒時間實現了。

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

後端有接口說明文檔，前端有原型設計圖，若是有臨時變動也會事先打好招呼，感受定義得還算清晰。

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

咱們大概知道接下來要作什麼，可是計劃還不是很詳細和明確。

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

若是沒有分配太多任務的話，仍是能夠有效處理的。這也和其餘學科的壓力相關。

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

主要學到的是應變能力。Beta階段咱們的變動不算太多，主要體如今Beta階段剛開始的計劃上，但一旦肯定了大致的方向，後面變動得就不多。

5. 設計/實現

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

大部分設計工做都在Beta開始前以及第一週開頭這一部分，主要由PM負責，是合適的時間和合適的人。但也有少部分設計是在開發過程當中進行的。

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

當時首頁的原型設計太難實現了，後來就大體想作得簡單點，卻沒有額外畫新的原型設計，對於前端確實是個模棱兩可的狀況。咱們有過交流，咱們交流了彼此的思路，最終效果挺滿意的。

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

咱們主要是依靠說明文檔，定義了輸入和輸出格式，測試的時候只是本身編寫測試樣例去測試。

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

博文功能Bug最多，這裏主要是前端，一是人手不足，二是bug不太好解決，自己實現難度也比較大。在發佈以後咱們發現搜索的結果有小几率會出現不全的狀況，由於咱們的編碼不涉及搜索邏輯的部分，因此就沒太在乎，再加上這個問題出現機率較低，並且出現了也很難注意到。

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

感受並無嚴格按照代碼規範，一些遺留的不符合規範的變量名並無及時作修正。

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

咱們在這一階段太過注重功能的實現了，時間又緊，人力資源又少，一直處於一個很緊張的狀態。若是重來一遍咱們會放棄一部分功能，將更多的時間用在代碼管理上，保證軟件工程的質量。

6. 測試/發佈

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

測試計劃不是很詳細，主要是前端和後端都忙着開發，測試工做基本所有由測試人員獨自完成。

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

有，除了功能測試以外，還進行了壓力測試，優化以後又測試了幾回。

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

功能測試使用java版本的selenium，負載測試採用jmeter和badboy實現。

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

咱們一開始保證正確性的模擬的最大用戶量是30+，這個結果已經不好了。以後咱們爲進程分配了更多的資源，將用戶量穩定在100出頭。最終PM和後端又針對性能的瓶頸（課程貢獻分計算）作了優化，最終大幅度下降了訪問時間，可以承受住140+用戶的連續訪問。

感受應當提升測試的頻率，下降測試的時間，下降測試的成本。有時候後端須要肯定優化的效果，須要依靠測試來肯定性能瓶頸有沒有被解決。感受應當每名成員都掌握部分測試能力，這樣沒必要徹底依賴於測試人員，本身打個招呼就能夠隨時測試。

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

過去的文件消失了，懷疑是被誤刪了，好在都是開發人員上傳的文件，不涉及用戶上傳的文件。

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

Alpha階段中性能瓶頸不明顯，沒有感覺到優化的重要性。若是重來一遍，咱們會在開發過程當中就注意儘可能使用花銷較小的實現方式，好比遍歷數組儘可能不經過下標訪問等等，這些細節能夠提升一部分性能。

7. 團隊的角色，管理，合做

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

和Alpha階段同樣的分工，同窗們通過了Alpha階段的提升，對本身的本職工做也很瞭解了。

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

常常互相幫助，有不懂的問題就跟羣裏問一問。

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

及時溝通，線上說不清楚就私下說，你們住的都比較近，基本全部的問題都能經過溝通解決。

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

理解了溝通的重要性，以及如何明確地將任務分配給我的。

總結:

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

可重複級(Repeatable)，咱們有了一些經驗，也制定了一些標準，可是還不夠成熟。

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

創造階段。你們的目的都是讓產品作得更好，全部人都在主動爲項目貢獻本身的力量，無需監督。同時爲實現功能實現的技術成員也會進行自學。

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

從口頭分配任務到文檔分配任務，功能的實現有據可依，成員分工明確，交集更少，下降無用溝通。

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

代碼質量，開發過程太過倉促了，重視了功能，忽略了代碼的管理，致使代碼缺乏結構性。

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

圍繞被激勵起來的人個來構建項目。給他們提供所須要的環境和支持，而且信任他們可以完成工做：咱們在分配任務的時候充分信任組員的能力，相信他們可以完成任務

在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談：咱們遇到困難的時候常常私下見面，線下交流的效率遠高於線上。

散夥前合影：