先上照片，最后一次開會了啊。。。

?

計劃

• 你原計劃的工作是否最后都做完了??如果有沒做完的，為什么？

答：沒有全部做完，到目前為止，我們的還有幾個實驗的報告生成功能沒有上線。這幾個實驗的數據處理文件已經寫出來了，但是由于實驗報告生成功能最后整合人員劉乾同學任務量比較大，沒有多余的時間完成這幾個實驗的整合。同時由于后期物理實驗本身的停止選課，項目經理于是優先考慮了論壇方面的發展與測試。

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

答：沒有，有了第一階段的經驗，在第二階段中我們做的每一件事都發揮了或多或少的價值。

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

答：是的。經過第一階段之后，沒有了關于學習上的任務。項目經理對每個人安排的任務都是根據每個人的能力安排的，不需要時間來學習。除此之外，每個人的任務都是可以定義任務的大小和完成質量。比如，關于一個數據處理的任務，根據第一階段的經驗，完成一個數據處理任務大概需要花2~3個小時（根據實驗的難度），而最終完成的數據處理文件都有規定模板（強制要求的注釋，代碼格式），因此這個任務完成的質量很容易區分。

• 是否項目的整個過程都按照計劃進行，有什么風險是當時沒有估計到的，為什么沒有估計到？

答：整個項目的過程不完全按照計劃進行。在β階段的迭代開發過程中，我們的課程上的壓力達到了極點，有很多課程都有大作業需要做，因此原本計劃在某個時間完成的任務，我們推遲了完成。這就是一個風險，差一點就導致我們的軟工項目停滯不前，但是大部分團隊成員選擇熬夜也堅持將軟工項目一點點向前推進，雖然速度比較慢，但是我們還是在盡我們最大的努力去完成。

• 在計劃中有沒有留下緩沖區，緩沖區有作用么？

答：留下的緩沖時間在1月25某一門考試之后的那一周。緩沖區作用挺大，前端人員實現了實用小工具界面。我們也有時間盡量找bug，完善我們的項目。

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

答：暫時沒有下一次迭代開發的計劃。

? ?

• 我們學到了什么??如果歷史重來一遍,?我們會做什么改進?

?答：第二階段學到了很多東西，主要是思想上或者說是感性上學到了很多東西。在第二階段開始的時候，團隊中大部分成員都有課程上的壓力，但是我們沒有放棄，我們努力突破自己，突破的不僅僅熬夜，突破是自己的心理承受能力。一次次的壓力讓我們不斷學會承受，讓我們強大。如果歷史重來一遍，我們會選擇早點完成其他課程上的任務，讓這一階段有足夠的時間讓我們完成開發。

?

資源

• 我們有足夠的資源來完成各項任務么？

答：資源永遠是不夠用的，這次軟工項目讓我更深刻的認識到了這一點吧。資源+勞動力=生產價值，正是在有限的資源內最大發揮人的工作潛力，才能體現一個項目的價值。在本項目中，我們多次調整了資源緊缺（尤其是人力資源和時間資源）與需求的沖突問題，盡可能去精簡計劃，保留其中的核心部分，并尋求捷徑加以實現，以保證在資源不足夠的情況下仍能將各項任務完成到一個可以令人滿意的狀態。

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

答：β階段有很多課程的大作業臨近截止，時間資源相對緊缺并且處于極端不穩定的狀態。因此我們只好動態估計各項任務所需的資源，即采用兩路并行的策略，將主站功能的完善和新功能的前后端工作分開，在最開始的scrum meeting中將整體的工作規劃布置下去，盡可能將流水線的工作模式劃分為工作碎片，依據每個人的需求動態地將大任務劃分為一個個小任務從而得以估計時間需求。項目的工作是圍繞人展開的，因此工作中的時間需求和任務規劃也要重視這一點。通過一段時間大家的磨合，我們也對彼此的工作模式有了一定了解，在任務的部署和分配上，對每個人工作所需時間資源的估計也可以做到更加準確。具體來說，我們估計時間資源并分配任務的方式是大教堂計劃思想與人文思想相融合的。

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

答：均不足夠。對于不需要編程的資源沒有低估難度，在UI方面投入比較大，并且為了減輕前端邏輯的壓力直接采用了現有的成熟方案，節省了大量的時間在其上進行優化與改進。

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

答：整個團隊的人員配置已經比較精簡了，每個人所負責的任務也相對較合理，所以每個人在團隊中所扮演的角色都是無可替代的。目前整個團隊的負荷已經達到飽和狀態，這也是拜本學期各大高壓課程所賜吧。

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

答：實話說饒彎子的地方是有的，而且還不少。如果不考慮能力方面提升的話，我們會在時間規劃上做一些改進，在課程選擇上有所取舍吧。

?

變更管理

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

答：大部分時候是的，得到通知的員工會進行相關的反饋，如果一段時間內得不到反饋，會再次進行聯系確認該員工收到了變更的消息。

• 我們采用了什么辦法決定"推遲"和"必須實現"的功能？

答：我們通過社交網絡建立了用戶反饋機制，通過用戶的反饋及時調整功能實現的優先級，優先處理熱門實驗和用戶期待度較高的功能。

• 項目的出口條件（Exit Criteria – 什么叫"做好了"）有清晰的定義么？

答：當壓力測試和兼容性測試完成并且這兩個測試基本沒有問題，我們就認為可以發布了。

• 對于可能的變更是否能制定應急計劃？

答：還沒有……

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

答：這個可以處理，項目經理給定工作請求時會通過結對編程的方式給予一定的新手入門和指導，從而能夠有比較好的處理問題的能力和針對具體問題有著具體的解決方案。如果還有別的問題或者突發情況，我們會在scrum meeting中討論，確定下一步的計劃。

• 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

答：這一點上我們覺得做的還是相對較好，重來一遍我們會更加注重團隊之間的互動與聯系，并且可能考慮更加方便與即時的方式對消息的變更進行通知與推送等。

?

?

設計/實現

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

第二階段開始之前，所有人開會討論了一下第二階段我們網站可以考慮的一些發展方向，包括各種功能的添加和原有功能的擴充等，所有人各自發表了自己對網站前景的見解，最后通過討論，確定出意見一致的發展方向

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

感覺這個階段并沒有明顯的遇到這種情況，因為關于設計，我們開會的時候都詳細地討論過各種方面的可能性，也經過充分的磨合和考慮，至于具體的架構或前端畫面設計我們就全權交給負責人來定奪，他們覺得這樣好就是好，我們充分地信任他們的能力。

?

• 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？

由于上階段所做的測試不夠充分，所以我們在這個階段加強了對測試的力度，通過更加全面和完整的方法去進行網站各種功能的測試。

• 什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?

本階段數據計算核心部分bug較少，主要是經過了不少開發者或用戶的測試了。這個階段的主要問題在于論壇的各種權限問題，某些權限的用戶在使用時會面臨按鈕的顯示問題或一些功能無法正常使用的情況。還有就是論壇的一部分功能還需要進一步完善，論壇的顯示也有一部分bug。我們的負責人們將會盡快完善這些bug。

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

代碼復審是由嚴格的管理層次進行的，數據處理的主程序員、前端工程師、后端工程師的代碼都需要經過我的復審。大部分代碼是遵從代碼規范的，沒能做到所有的都嚴格執行代碼規范。

• 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?

其實我覺得，我們團隊從項目開始到結束，各個方面做的都蠻好的，大家的自律性也都比較強，而且對產品也都希望能做到越精致越好，我覺得這是我們團隊的優勢。如果歷史重來一遍，我們還會走現在的路，也許我們會更加精進各個方面，但是我們還是會按著現在的軌跡走。

?

測試/發布

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

按照我們的計劃，我們會在開發完成后進行黑盒測試，之后線上進行壓力測試。對于實驗處理文件的單元測試已經做了，對瀏覽器的兼容性進行了回歸測試和黑盒測試。對于網站架構單元測試和回歸測試由于人力和時間關系并沒有做太多。

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

進行了正式的驗收測試，我們測試了基本大部分大眾瀏覽器的每個界面的顯示與功能情況。

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

在壓力測試時，我們首先使用了安全分析和攻擊工具burpsuit來模擬高并發請求，我們發現在1G內存時，其并發請求處理的最大數是6,之后服務器端的mysql服務會崩潰，我們分析mysql的錯誤日志，發現這個崩潰的原因是因為mysql在申請innodb_buffer的時候無法申請到內存，也就是說，報告生成這個操作吃盡了1G內存，之后為了使并發量提高，我們修改了mysql的配置文件，將innodb_buffer_pool_size的大小從16M改為8M，之后再測試時，其并發峰值到達了16，有了顯著提高。

之后，為了進行準確的壓力測試，我們使用了siege進行并發壓力測試，使用top監視服務器運行狀態，使用wireshark監視網絡流量。大體測試結果如下圖：

上圖為對網站頁面的普通get請求的測試。

測試結果

上圖是對報告生成的并發測試。

測試結果。

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

（1）使用瀏覽器插件firebug監控響應和資源請求時間，將某些資源做緩存處理。

（2）使用top監視報告生成的資源消耗，我們發現一開始使用的latex框架消耗資源巨大，之后我們更換了輕量級版本，使其效率提高了幾倍。

• 在發布的過程中發現了哪些意外問題？

發布時由于服務器端部署比較復雜，涉及到一系列數據庫視圖操作，恢復數據操作，改變結構操作，所以為了避免出現操作失誤，我們在部署當晚12點暫時關閉對外服務，備份鏡像和數據庫，進行新服務的部署。

由于在服務端上wecenter的安裝完后和遠端git倉庫的最新版本之間存在不可自動合并的沖突，這時我將服務器端代碼下載到本地，想進行手動合并，然而我為了方便又直接reset HEAD –hard了，結果這樣之后，線上程序跑不起來，并且完全不知道哪個地方出了問題，并且reset到某一log后并不是原來的文件，所以我把剛才下載的代碼手動在本地合并后覆蓋掉服務器端的文件，這才解決了問題。

• 我們學到了什么??如果歷史重來一遍,?我們會做什么改進?

熟練使用git ，relog功能。

總結

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

答：我覺得團隊目前的狀態屬于已定義級別，有維護的標準文檔，有嚴格的代碼復審流程，團隊協作比較協調。

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

答：我覺得我們團隊目前處于規范階段。

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

答：整個團隊在這個里程碑與前一個相比，改進最大的地方是配合分工更加默契：在前一個里程碑中，我們必須不斷確定彼此的分工，由項目經理進行每天的任務調度和安排，項目的管理更人工化，而在這一階段，我們團隊中每個人的任務基本上可以保證傳遞實現，即一個人的任務完成后需要交付給下一個人，每個人拿到他人交付下來的任務后才能在此基礎上完成自己的任務，管理自動化更高。雖然可能會出現一環接不上，整體停滯的問題，但是根據實踐的總體情況來看，效果還是不錯的。

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

答：受限于Beta階段時間的極度壓縮，即使在努力趕工，但是新做的許多物理實驗還各自缺少一小部分內容，不足以發布。由于PDF轉HTML太吃服務器資源，最終被迫放棄了這一想法，這一想法的放棄意味著我們必須放棄手機端的客戶，這是一個重大的損失。我們目前正在思考措施挽回手機端的客戶，并且能夠實現需求文檔里所述。

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

答：我覺得我們團隊目前處于規范階段。我們的團隊通過會議公開討論流程和工作方式，整個團隊的目標更加現實和明確。這個階段中，我們逐步建立屬于我們這個項目的分工規定，協調調度更加自動化，項目經理在上一階段的分配任務的工作逐漸被流暢的合作模式代替，成員之間的配合更加默契。

?

相比于α階段，我們改進了什么？

相比于α階段，我們最終改進了幾個部分：

1、全員使用git：這一點我認為是一個最大的進步，共同進步才是進步。α階段團隊commit只有項目經理和前后端工程師在做，而β階段團隊所有隊員在github上都直接參與了團隊項目的開發。這是集體的進步：）

2、注重單元測試：β階段嚴格遵守了開發就要測試的原則，對后端的數據處理進行了大量的單元測試并且部署了自動運行單元測試的drone.io。

3、團隊協作模式的改進：從中心依賴制度變更為互相依賴的類環系統，加強了每個人對團隊項目的影響力。

4、時間的合理安排：項目經理在統籌兼顧各個成員的課業壓力后，合理安排開發時間在編譯實驗稍微空閑的時間段，最終也取得了不錯的效果。

相比于α階段，我們保持了什么特點？

1、一如既往的好的用戶體驗度：在第二階段的開發中，我們不論是在選擇論壇、注冊頁面的改寫以及前端小工具的制作中，我們都保持了跟α階段一樣的一如既往的好的用戶體驗，這樣的用戶體驗是前端工程師下辛苦捉摸與設計的。

2、緊跟用戶需求：網站始終以用戶需求為第一驅動力，所以一直在跟進用戶需求，在用戶反饋Bug后盡可能快速解決，最終影響力擴大到了其他學校，甚至有高中的學生，大學的物理老師等。

3、調研：在計劃好β階段的任務后，我們又進行了一輪調研，最終根據實際用戶需求調整了開發計劃，最終確定了優先級最高的幾個feature來做。

轉載于:https://www.cnblogs.com/buaase/p/5117706.html

總結

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

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