【Gamma】事後分析

- 設想和目标
- 計劃
- 資源
- 變更管理
- 設計/實作
- 測試/釋出
- 團隊的角色，管理，合作
- 總結
- 照片

我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

我們的軟體（網站）希望幫助同學們完成大二學年的實體實驗，包括完成實驗預習報告、實驗資料處理及最終實驗報告生成。除此之外在Beta階段我們也希望能幫助同學們複習設計性實驗。

對于要解決的問題我們認為定義的比較清楚，對典型使用者和典型場景也有清晰的描述。

我們達到目标了麼（原計劃的功能做到了幾個？按照原計劃傳遞時間傳遞了麼？原計劃達到的使用者數量達到了麼?)

在Gamma結束後我們達到了目标：

Markdown模闆報告生成功能完整接入到網站中，所有實驗都可使用Markdown模闆生成報告；
移動端對于普通使用者的功能實作完善；
設計性實驗複習頁面正常運作；
完善了大量測試、文檔、注釋等等；

由于Gamma階段起初的進度滞後，我們Gamma階段傳遞的時間也有所延誤（約2天），但由于Gamma階段工作主要針對開發者進行，對使用者的影響不大。使用者量方面原計劃設計性實驗頁面通路量達到500，截止展示日為止通路量為422，還是有部分差距。

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

與Alpha階段相比軟體工程品質是有提升的。首先是在GitHub項目管理方面，我們每個issue的關閉基本都附有對應的傳遞内容(commit、部落格連結、設計内容等)。其次在任務進行時組員采用結對的方式進行程式設計，并在每天晚上開會時對進度進行統一梳理。

使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?

使用者量沒有達到我們的預期，我們認為這是因為團隊在項目釋出後的推廣方面力度不足（之前在實體實驗大群中進行推廣的後果比較尴尬），僅僅通過朋友圈轉發的方式推薦效果一般。

使用者對重要功能接受程度尚可，設計性實驗頁面通路量雖然沒有達到預期但也達到了80%。我們離目标還是近了。

有什麼經驗教訓? 如果曆史重來一遍，我們會做什麼改進?

如果重來一遍，在推廣方面團隊可能會更大膽一些，努力在人多的一些地方進行推廣，進而讓使用者量能夠繼續上升。除此之外我們還會多聽取使用者的意見，以對網站進行進一步的改進。

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

Beta階段的計劃時間還是非常充足的，我們對Markdown以及移動端功能進行了完善的計劃。Gamma階段由于釋出和計劃在同一周，計劃的時間較為緊張。

團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？

計劃階段團隊試行的方式是首先由PM進行任務的配置設定，然後由大家各自對自己的任務進行計劃，最終由團隊統一讨論後得到執行的最終計劃。

你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

原計劃的工作都做完了。

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

總體來說Beta和Gamma階段做的事情都比較有價值，或是實作功能或是提升軟體整體的品質。可能在某些過程中走了彎路（例如單元測試、修複設計性實驗在移動端的小問題），但總體來說都是有價值的經驗。

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

在Beta/Gamma階段我們對每個任務都定義了對應的傳遞内容，在任務完成關閉issue時需要将對應内容補充在issue當中。

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

總體來說整個項目按原計劃進行。唯一的進度落後位于Gamma階段開始時，很多課程和大作業蜂擁而上對所有的組員都産生了影響，使得項目進度在開始一周停滞不前。

在計劃中有沒有留下緩沖區，緩沖區有作用麼?

預留了三天的緩沖區。緩沖區還是起到了作用，彌補了上述Gamma開始時進度延誤的問題。

将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）

在計劃時會根據團隊成員的時間配置設定進行任務的配置設定，并将比較簡單的任務放在時間不富裕的時候做。

我們學到了什麼? 如果曆史重來一遍,我們會做什麼改進？

相比于Alpha階段不明确的計劃來說，明确的計劃的确讓任務進行有迹可循，目标也更加明确。如果再來一遍，我們會在Gamma開頭階段對任務進行更詳細的拆分，使得進度更加明确。

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

項目資源來說：伺服器方面資源夠，但對于一些知識來說找到的文檔和部落格都不是非常詳細。

時間/人力資源來說：不夠。尤其臨近期末大家其他課程也開始忙碌了，時間資源不太充足。

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

Beta/Gamma階段的任務估計時間根據任務對應的成員自行估計得出，由于任務配置設定時會将相似的任務配置設定到同幾個人身上，是以大家對任務完成的難度及預期時間估計也更加準确。

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

測試的時間是充足的，尤其是在Gamma階段我們的部分團隊成員專注于進行單元測試、接口測試等内容。文案方面在Gamma階段主要面臨的是文檔的編寫，這部分由于編者對項目比較熟悉也沒有花費太多時間。

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

基本而言各位組員對于自己的任務完成的效率都較好，對于某些成員遇到困難的情況，會有其他的成員幫助其解決問題。但由于每個人都有自己的任務，是以總體來說不能把所有事情都交給同一個人做。

有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?

遇到一些開發上的難題除了自己埋頭鑽研外，也應該嘗試求助一下别人，或許能夠更快解決問題。

比如測試方面我們應當尋求一些外界的幫助，進而能夠更快度過踩坑的時間。

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

是的，即使在Beta/Gamma階段部分例會在網上召開，資訊也能很快傳達給大家。

我們采用了什麼辦法決定“推遲”和“必須實作”的功能?

首先确定該階段整體需要實作的功能，例如Beta階段需要實作“Markdown報告生成“。然後視每部分功能針對使用者的重要程度決定是否推遲甚至抛棄某些功能。例如Beta階段我們将Markdown報告生成在控制台中的接入推遲到了Gamma階段，除此之外我們抛棄了Markdown報告收藏的功能，以與原先的Latex報告生成區分開。

項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

有定義：

控制台在新增Markdown功能後原有功能不受影響，可正常增加/修改/釋出實驗，可以編輯已有的Markdown模闆。首頁公告欄僅有管理者可編輯，所有人可以看到編輯的結果。

工程品質方面盡可能完善單元測試，增加易于了解的注釋，解耦代碼中寫死的配置資訊，修訂已有的文檔并增加新的文檔來幫助新同學上手。

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

能，和往常一樣對于一些組員無法解決的問題，其他組員會幫忙嘗試解決。

我們學到了什麼? 如果曆史重來一遍，我們會做什麼改進？

針對功能的定義在計劃時做的要足夠詳細，這樣能夠捕捉到一些在開發時容易遺漏的問題，減少變更的産生。

如果再來一遍，我們在計劃時會嘗試進一步明确功能的取舍。

設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？

設計在計劃以及開發的初期完成，由對應子產品的開發者完成。事後來看是合适的時間和人，因為設計和實作的工作能夠無縫銜接。

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

在Markdown報告生成部分的确遇到了設計選擇按鈕部分模棱兩可的情況，最終的解決辦法是設計者明确其設計思路并由團隊讨論決定。

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

在後兩個階段團隊引入了單元測試、接口測試還有針對新功能的性能測試。測試工具還是非常有效的，尤其是在開發新功能時成員會一并寫好單元測試的代碼，減小了後續測試的壓力。

什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

Bug仍然積壓在社群和實驗端對接的部分。這部分考慮到社群應用較少且解決難度較大，最終團隊考慮暫時不解決這些問題。

在釋出後我們找到了一處關于控制台的Bug，即編号不能為0開頭。這部分是因為對應功能引用了往屆寫好的代碼，并且測試中也沒有考慮到這些情況。

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

在後兩個階段由于團隊開發中出現了很多結對的情況，是以複審主要有結對的同學單獨進行。代碼規範方面與上個階段相比開發時成員會更注意代碼風格的統一性。

**我們學到了什麼? 如果曆史重來一遍， **我們會做什麼改進？

設計者在遇到遇到模棱兩可的情況時應當盡早提出并與大家讨論。設計部分遇到的不明确情況應當先明确後再編碼實作。

如果再來一遍，在設計過程中我們會更加細化每個功能的效果。

團隊是否有一個測試計劃？為什麼沒有？

團隊的測試計劃仍然是在最後進行整體的驗收測試，同時各開發者在開發過程中對自己的子產品進行自測。

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

進行了。包括所有功能的驗收和複查，除此之外還包括對之前功能的回測。

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

單元測試我們采用了PHPUnit完成了對大多後端控制器的測試。

接口測試使用了Postman，并将測試樣例進行了導出，以友善之後的同學使用。

性能測試：見下

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

在Beta階段我們引入新功能後嘗試使用Jmeter對新功能和原有功能兩個接口進行了性能方面的測試。

總體來說測試工作是有用的，尤其是在進行少量變更後運作測試即可知道功能是否正常。

在釋出的過程中發現了哪些意外問題？

釋出過程中沒有遇到太多問題。

一個小插曲是臨近釋出時PM誤用了PHPUnit的同步功能，不小心把開發伺服器的代碼搞亂了，對單元測試的運作有少量影響，不過這些影響很快都被修複了。

我們學到了什麼? 如果重來一遍，我們會做什麼改進？

開發中的測試會減輕之後測試以及debug的壓力。先寫測試代碼再寫邏輯并不是一件很麻煩的事情。

如果再來一遍，我們可能會在Beta階段就開始這種測試驅動的開發模式，并盡早嘗試使用各種測試工具。

團隊的每個角色是如何确定的，是不是人盡其才？

在後兩個階段團隊盡管發生了人員變動，但角色配置設定仍按照大家的專長或之前做過的工作來進行，即盡量不讓大家接觸陌生的内容。

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

有，尤其是在某些成員遇到問題時其他成員或結對的成員能夠及時幫忙。在每天scrum例會時也會讨論一些沒有解決的問題。

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

合作方面的問題主要通過私下交流以及scrum meeting時的讨論解決。

你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?

我認為仍然處于第二級（管理級）：在項目實施上能夠遵守既定的計劃與流程，有資源準備，權責到人，對整個流程有監測與控制。

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

我認為團隊經過後兩個階段後已經進入了規範的階段，大家各司其職并且互幫互助，針對項目有着共同的目标。

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

團隊努力的目标不僅僅是提供更多的功能，在軟體品質方面也下了很多工夫，使目前項目對将來的開發者也更加友好。
團隊在軟體工程方面執行的更加規範，并且在團隊開發的過程中也引入了諸如結對這樣的模式，效率比Alpha階段要高一些。

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

圍繞被激勵起來的個人來建構項目。給他們提供所需要的環境和支援，并且信任他們能夠完成工作：開發過程中很多功能我們都是完整交給單獨的個人或兩個人來完成，其他組員會盡可能提供幫助。
工作的軟體是首要進度度量标準：團隊成員在每天例會時都會以目前功能能不能跑為衡量标準。