1. 設(shè)想和目標(biāo)

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

我們在Beta階段任務(wù)主要分為兩部分，一類是對原功能的擴(kuò)展，一類是新的博文功能。我們通過規(guī)格說明書定義功能，至少比Alpha階段清楚多了。典型用戶和典型場景還是沿用的Alpha階段。

1.2 我們達(dá)到目標(biāo)了么（原計(jì)劃的功能做到了幾個(gè)？ 按照原計(jì)劃交付時(shí)間交付了么？ 原計(jì)劃達(dá)到的用戶數(shù)量達(dá)到了么?)

基本達(dá)到了目標(biāo)。但是計(jì)劃實(shí)現(xiàn)的功能太多了，最終只實(shí)現(xiàn)了大多數(shù)功能，一些非核心功能就被棄掉了。我們在展示的前兩周發(fā)布，并且達(dá)到了預(yù)計(jì)的訪問量（原計(jì)劃600，現(xiàn)在達(dá)到了802），只是注冊量還差一點(diǎn)（原計(jì)劃300，現(xiàn)在達(dá)到了244），不過這個(gè)結(jié)果已經(jīng)遠(yuǎn)遠(yuǎn)優(yōu)于Alpha階段了。

1.3 和上一個(gè)階段相比，團(tuán)隊(duì)軟件工程的質(zhì)量提高了么？ 在什么地方有提高，具體提高了多少，如何衡量的？

提高了。主要體現(xiàn)在文檔更為明確了，我們會(huì)根據(jù)數(shù)據(jù)庫文檔和規(guī)格說明文檔進(jìn)行功能定義，不必在開發(fā)過程中去糾結(jié)應(yīng)該做什么，開發(fā)功能的速度明顯優(yōu)于Alpha階段。而且我們的分工更佳明確，兩名后端一人負(fù)責(zé)一大塊，減少了溝通的花費(fèi)，效率確實(shí)上升了。而且我們優(yōu)化了貢獻(xiàn)分分配的公式，更佳簡潔明了，弱化了PM主觀因素。

1.4 用戶量, 用戶對重要功能的接受程度和我們事先的預(yù)想一致么? 我們離目標(biāo)更近了么?

Alpha階段結(jié)束的時(shí)候訪問量為220，現(xiàn)在已經(jīng)突破了800，我認(rèn)為用戶量還算達(dá)到了目標(biāo)。不過在發(fā)布后又出現(xiàn)了很多問題，比如有些資源提示404（是課程中心的問題），還有同袍認(rèn)證存在問題，以及用戶上傳的資源丟失等等，這些問題都是我們之前從未預(yù)料過的。但是也有用戶反饋說獲取到了很難獲取的資源，這一點(diǎn)我們也很欣慰。實(shí)際上，我們在Beta階段新增了很多諸如課程收藏、資源評價(jià)等等提高用戶體驗(yàn)的功能，但是現(xiàn)在還沒有得到用戶的反饋。

有什么經(jīng)驗(yàn)教訓(xùn)? 如果歷史重來一遍, 我們會(huì)做什么改進(jìn)?

盡早宣傳，由于我們宣傳得比較晚，導(dǎo)致最終的用戶量和匯報(bào)時(shí)用戶量相差比較大。應(yīng)該把反饋功能盡早銜接到網(wǎng)站上，而不是依賴于用戶群。

2. 計(jì)劃

2.1 是否有充足的時(shí)間來做計(jì)劃?

有的，實(shí)際上在Alpha階段發(fā)布之后就已經(jīng)開始考慮Beta階段的功能了。

2.2 團(tuán)隊(duì)在計(jì)劃階段是如何解決同事們對于計(jì)劃的不同意見的？

在討論的時(shí)候PM主張先對原有功能進(jìn)行擴(kuò)展，而組員們的大致意見是先實(shí)現(xiàn)博文功能，以更快速地得到反饋。這一點(diǎn)PM最終還是聽從了組員們的建議。

2.3 你原計(jì)劃的工作是否最后都做完了? 如果有沒做完的，為什么?

沒有做完。因?yàn)槲覀傿eta階段少了一名前端開發(fā)，同時(shí)可支配的時(shí)間比Alpha階段要少（因?yàn)楦鞣N大作業(yè)和考試，尤其是編譯占得時(shí)間很多），導(dǎo)致時(shí)間一直很緊張。

2.4 有沒有發(fā)現(xiàn)你做了一些事后看來沒必要或沒多大價(jià)值的事?

有的。主要是后端開發(fā)了很多功能最終由于前端比較緊張沒能銜接上。早知道這樣真應(yīng)該減少一些功能，提高軟件工程的質(zhì)量。

2.5 是否每一項(xiàng)任務(wù)都有清楚定義和衡量的交付件?

只要按照說明文檔那樣實(shí)現(xiàn)就可以交付了。前端的話會(huì)事先商量，并對原型圖進(jìn)行適當(dāng)改動(dòng)。但是感覺定義得不是很清楚。

2.6 是否項(xiàng)目的整個(gè)過程都按照計(jì)劃進(jìn)行，項(xiàng)目出了什么意外？有什么風(fēng)險(xiǎn)是當(dāng)時(shí)沒有估計(jì)到的，為什么沒有估計(jì)到?

基本按照計(jì)劃進(jìn)行，最后階段有些脫節(jié)，主要是沒有想到那一陣子這么忙……

2.7 在計(jì)劃中有沒有留下緩沖區(qū)，緩沖區(qū)有作用么?

沒有設(shè)立緩沖區(qū)。

2.8 將來的計(jì)劃會(huì)做什么修改？（例如：緩沖區(qū)的定義，加班）

減少任務(wù)量，并明確各個(gè)任務(wù)的優(yōu)先級。

我們學(xué)到了什么? 如果歷史重來一遍, 我們會(huì)做什么改進(jìn)?

精簡要實(shí)現(xiàn)的任務(wù)，設(shè)立優(yōu)先級，根據(jù)優(yōu)先級依次實(shí)現(xiàn)任務(wù)，這樣就算有突發(fā)情況導(dǎo)致任務(wù)沒做完也能保證最核心的部分都實(shí)現(xiàn)。

3.資源

3.1 我們有足夠的資源來完成各項(xiàng)任務(wù)么?

并沒有，我們少了一名前端開發(fā)，Beta階段我們用來做軟工的時(shí)間也少了很多、

3.2 各項(xiàng)任務(wù)所需的時(shí)間和其他資源是如何估計(jì)的，精度如何?

首先我們有了Alpha階段的開發(fā)經(jīng)驗(yàn)，我們會(huì)把要實(shí)現(xiàn)的功能和Alpha階段已經(jīng)實(shí)現(xiàn)的功能進(jìn)行對比，比較一下難度，因?yàn)锳lpha階段任務(wù)的實(shí)現(xiàn)時(shí)間是已經(jīng)確定的，所以可以以此估計(jì)任務(wù)所需的時(shí)間。

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

我們有專門的測試人員，而且后端實(shí)現(xiàn)的功能也會(huì)簡單進(jìn)行測試，這部分資源是足夠的。我們這里沒有單獨(dú)的美工設(shè)計(jì)和文案人員，后期的宣傳大家都做了一定工作。

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

沒有，我們分工都很明確了，是可以讓別人來做，可是別人也有自己的工作啊。

有什么經(jīng)驗(yàn)教訓(xùn)? 如果歷史重來一遍, 我們會(huì)做什么改進(jìn)?

我們一定要在Beta階段開始前盡可能拉人。

4. 變更管理

4.1 每個(gè)相關(guān)的員工都及時(shí)知道了變更的消息?

是的，重大的決定我們會(huì)在會(huì)議上宣布，如果沒有開會(huì)的條件也會(huì)在群里爭取大家的意見。至少我們會(huì)讓和變更密切相關(guān)的成員第一時(shí)間了解到變更。

4.2 我們采用了什么辦法決定“推遲”和“必須實(shí)現(xiàn)”的功能?

先大約估計(jì)了一下各個(gè)功能實(shí)現(xiàn)的成本，先實(shí)現(xiàn)時(shí)間確定、成本較低的功能，也考慮了功能的重要性，但沒有將這一點(diǎn)放在主要位置。主要還是時(shí)間太緊了，擔(dān)心最后的結(jié)局是一個(gè)重要的功能沒實(shí)現(xiàn)完，其它功能也沒時(shí)間實(shí)現(xiàn)了。

4.3 項(xiàng)目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?

后端有接口說明文檔，前端有原型設(shè)計(jì)圖，如果有臨時(shí)變更也會(huì)事先打好招呼，感覺定義得還算清晰。

4.4 對于可能的變更是否能制定應(yīng)急計(jì)劃?

我們大概知道接下來要做什么，但是計(jì)劃還不是很詳細(xì)和明確。

4.5 員工是否能夠有效地處理意料之外的工作請求？

如果沒有分配太多任務(wù)的話，還是可以有效處理的。這也和其他學(xué)科的壓力相關(guān)。

我們學(xué)到了什么? 如果歷史重來一遍, 我們會(huì)做什么改進(jìn)?

主要學(xué)到的是應(yīng)變能力。Beta階段我們的變更不算太多，主要體現(xiàn)在Beta階段剛開始的計(jì)劃上，但一旦確定了大體的方向，后面變更得就很少。

5. 設(shè)計(jì)/實(shí)現(xiàn)

5.1. 設(shè)計(jì)工作在什么時(shí)候，由誰來完成的？是合適的時(shí)間，合適的人么？

大部分設(shè)計(jì)工作都在Beta開始前以及第一周開頭這一部分，主要由PM負(fù)責(zé)，是合適的時(shí)間和合適的人。但也有少部分設(shè)計(jì)是在開發(fā)過程中進(jìn)行的。

5.2. 設(shè)計(jì)工作有沒有碰到模棱兩可的情況，團(tuán)隊(duì)是如何解決的？

當(dāng)時(shí)首頁的原型設(shè)計(jì)太難實(shí)現(xiàn)了，后來就大致想做得簡單點(diǎn)，卻沒有額外畫新的原型設(shè)計(jì)，對于前端確實(shí)是個(gè)模棱兩可的情況。我們有過交流，我們交流了彼此的思路，最終效果挺滿意的。

5.3. 團(tuán)隊(duì)是否運(yùn)用單元測試（unit test），測試驅(qū)動(dòng)的開發(fā)（TDD）、UML, 或者其他工具來幫助設(shè)計(jì)和實(shí)現(xiàn)？這些工具有效么？ 比較項(xiàng)目開始的 UML 文檔和現(xiàn)在的狀態(tài)有什么區(qū)別？這些區(qū)別如何產(chǎn)生的？是否要更新 UML 文檔？

我們主要是依靠說明文檔，定義了輸入和輸出格式，測試的時(shí)候只是自己編寫測試樣例去測試。

5.4. 什么功能產(chǎn)生的Bug最多，為什么？在發(fā)布之后發(fā)現(xiàn)了什么重要的bug? 為什么我們在設(shè)計(jì)/開發(fā)的時(shí)候沒有想到這些情況?

博文功能Bug最多，這里主要是前端，一是人手不足，二是bug不太好解決，本身實(shí)現(xiàn)難度也比較大。在發(fā)布之后我們發(fā)現(xiàn)搜索的結(jié)果有小概率會(huì)出現(xiàn)不全的情況，因?yàn)槲覀兊木幋a不涉及搜索邏輯的部分，所以就沒太在意，再加上這個(gè)問題出現(xiàn)概率較低，而且出現(xiàn)了也很難注意到。

5.5. 代碼復(fù)審（Code Review）是如何進(jìn)行的，是否嚴(yán)格執(zhí)行了代碼規(guī)范？

感覺并沒有嚴(yán)格按照代碼規(guī)范，一些遺留的不符合規(guī)范的變量名并沒有及時(shí)做修正。

我們學(xué)到了什么? 如果歷史重來一遍, 我們會(huì)做什么改進(jìn)?

我們在這一階段太過注重功能的實(shí)現(xiàn)了，時(shí)間又緊，人力資源又少，一直處于一個(gè)很緊張的狀態(tài)。如果重來一遍我們會(huì)放棄一部分功能，將更多的時(shí)間用在代碼管理上，保證軟件工程的質(zhì)量。

6. 測試/發(fā)布

6.1 團(tuán)隊(duì)是否有一個(gè)測試計(jì)劃？為什么沒有？

測試計(jì)劃不是很詳細(xì)，主要是前端和后端都忙著開發(fā)，測試工作基本全部由測試人員獨(dú)自完成。

6.2 是否進(jìn)行了正式的驗(yàn)收測試？

有，除了功能測試之外，還進(jìn)行了壓力測試，優(yōu)化之后又測試了幾次。

6.3 團(tuán)隊(duì)是否有測試工具來幫助測試？

功能測試使用java版本的selenium，負(fù)載測試采用jmeter和badboy實(shí)現(xiàn)。

6.4 團(tuán)隊(duì)是如何測量并跟蹤軟件的效能的？從軟件實(shí)際運(yùn)行的結(jié)果來看，這些測試工作有用么？應(yīng)該有哪些改進(jìn)？

我們一開始保證正確性的模擬的最大用戶量是30+，這個(gè)結(jié)果已經(jīng)很差了。之后我們?yōu)檫M(jìn)程分配了更多的資源，將用戶量穩(wěn)定在100出頭。最終PM和后端又針對性能的瓶頸（課程貢獻(xiàn)分計(jì)算）做了優(yōu)化，最終大幅度降低了訪問時(shí)間，能夠承受住140+用戶的連續(xù)訪問。

感覺應(yīng)當(dāng)提高測試的頻率，降低測試的時(shí)間，降低測試的成本。有時(shí)候后端需要確定優(yōu)化的效果，需要依靠測試來確定性能瓶頸有沒有被解決。感覺應(yīng)當(dāng)每名成員都掌握部分測試能力，這樣不必完全依賴于測試人員，自己打個(gè)招呼就可以隨時(shí)測試。

6.5 在發(fā)布的過程中發(fā)現(xiàn)了哪些意外問題？

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

我們學(xué)到了什么? 如果歷史重來一遍, 我們會(huì)做什么改進(jìn)?

Alpha階段中性能瓶頸不明顯，沒有感受到優(yōu)化的重要性。如果重來一遍，我們會(huì)在開發(fā)過程中就注意盡量使用花銷較小的實(shí)現(xiàn)方式，比如遍歷數(shù)組盡量不通過下標(biāo)訪問等等，這些細(xì)節(jié)可以提高一部分性能。

7. 團(tuán)隊(duì)的角色，管理，合作

7.1 團(tuán)隊(duì)的每個(gè)角色是如何確定的，是不是人盡其才？

和Alpha階段一樣的分工，同學(xué)們經(jīng)過了Alpha階段的提高，對自己的本職工作也很了解了。

7.2 團(tuán)隊(duì)成員之間有互相幫助么？

經(jīng)常互相幫助，有不懂的問題就跟群里問一問。

7.3 當(dāng)出現(xiàn)項(xiàng)目管理、合作方面的問題時(shí)，團(tuán)隊(duì)成員如何解決問題？

及時(shí)溝通，線上說不清楚就私下說，大家住的都比較近，基本所有的問題都能通過溝通解決。

我們學(xué)到了什么? 如果歷史重來一遍, 我們會(huì)做什么改進(jìn)?

理解了溝通的重要性，以及如何明確地將任務(wù)分配給個(gè)人。

總結(jié):

你覺得團(tuán)隊(duì)目前的狀態(tài)屬于 CMM/CMMI 中的哪個(gè)檔次?

可重復(fù)級(Repeatable)，我們有了一些經(jīng)驗(yàn)，也制定了一些標(biāo)準(zhǔn)，但是還不夠成熟。

你覺得團(tuán)隊(duì)目前處于 萌芽/磨合/規(guī)范/創(chuàng)造 階段的哪一個(gè)階段?

創(chuàng)造階段。大家的目的都是讓產(chǎn)品做得更好，所有人都在主動(dòng)為項(xiàng)目貢獻(xiàn)自己的力量，無需監(jiān)督。同時(shí)為實(shí)現(xiàn)功能實(shí)現(xiàn)的技術(shù)成員也會(huì)進(jìn)行自學(xué)。

你覺得團(tuán)隊(duì)在這個(gè)里程碑相比前一個(gè)里程碑有什么改進(jìn)?

從口頭分配任務(wù)到文檔分配任務(wù)，功能的實(shí)現(xiàn)有據(jù)可依，成員分工明確，交集更少，降低無用溝通。

你覺得目前最需要改進(jìn)的一個(gè)方面是什么?

代碼質(zhì)量，開發(fā)過程太過倉促了，重視了功能，忽略了代碼的管理，導(dǎo)致代碼缺少結(jié)構(gòu)性。

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

圍繞被激勵(lì)起來的人個(gè)來構(gòu)建項(xiàng)目。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作：我們在分配任務(wù)的時(shí)候充分信任組員的能力，相信他們能夠完成任務(wù)

在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談：我們遇到困難的時(shí)候經(jīng)常私下見面，線下交流的效率遠(yuǎn)高于線上。

散伙前合影：

轉(zhuǎn)載于:https://www.cnblogs.com/hotcode5/p/8281398.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。