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)，我們有了一些經驗，也制定了一些標準，但是還不夠成熟。

你覺得團隊目前處于 萌芽/磨合/規范/創造 階段的哪一個階段?

創造階段。大家的目的都是讓產品做得更好，所有人都在主動為項目貢獻自己的力量，無需監督。同時為實現功能實現的技術成員也會進行自學。

你覺得團隊在這個里程碑相比前一個里程碑有什么改進?

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

你覺得目前最需要改進的一個方面是什么?

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

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

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

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

散伙前合影：

轉載于:https://www.cnblogs.com/hotcode5/p/8281398.html

總結

以上是生活随笔為你收集整理的Beta阶段事后分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。