【Beta階段】M2過後分析

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

 

計劃

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

答：沒有所有作完，到目前爲止，咱們的還有幾個實驗的報告生成功能沒有上線。這幾個實驗的數據處理文件已經寫出來了，可是因爲實驗報告生成功能最後整合人員劉乾同窗任務量比較大，沒有多餘的時間完成這幾個實驗的整合。同時因爲後期物理實驗自己的中止選課，項目經理因而優先考慮了論壇方面的發展與測試。

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

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

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

答：是的。通過第一階段以後，沒有了關於學習上的任務。項目經理對每一個人安排的任務都是根據每一個人的能力安排的，不須要時間來學習。除此以外，每一個人的任務都是能夠定義任務的大小和完成質量。好比，關於一個數據處理的任務，根據第一階段的經驗，完成一個數據處理任務大概須要花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太吃服務器資源，最終被迫放棄了這一想法，這一想法的放棄意味着咱們必須放棄手機端的客戶，這是一個重大的損失。咱們目前正在思考措施挽回手機端的客戶，而且可以實現需求文檔裏所述。

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

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

 

相比於α階段，咱們改進了什麼？

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

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

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

三、團隊協做模式的改進：從中心依賴制度變動爲互相依賴的類環系統，增強了每一個人對團隊項目的影響力。

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

相比於α階段，咱們保持了什麼特色？

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

二、緊跟用戶需求：網站始終以用戶需求爲第一驅動力，因此一直在跟進用戶需求，在用戶反饋Bug後儘量快速解決，最終影響力擴大到了其餘學校，甚至有高中的學生，大學的物理老師等。

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