【BUAA軟工】Beta階段過後分析

設想與目標

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

• 解決的問題
  • 整體解決的問題：新手編程者配置編程環境難、本地編寫的代碼跨設備同步難、本地ide安裝使用過程繁瑣等問題
  • alpha階段解決的問題：基本項目的建立，自動補全，編譯運行
  • beta階段新增：
    • 隨手寫簡單代碼、項目多人合做中的分享和協做開發
    • 美化功能，讓使用者感受更加賞心悅目。
    • 進一步解決軟件啓動速度問題。
• 定義是否清楚：
  • 定義的很清楚，可參見以往博客設計與規化：Alpha階段規劃，Beta階段規劃
• 是否對典型用戶和典型場景有清晰的描述：
  • 有，面向簡單使用、臨時使用的用戶。如，用戶只想測試一個語法特性。
  • 具體用戶場景描述能夠參見以往博客：
    • 單個典型用戶場景描述以及測試
    • 多用戶場景，能夠考慮爲多個典型用戶同時使用，例如在學校的上機測試，上機實驗環節，多用戶場景測試

咱們達到目標了麼（原計劃的功能作到了幾個？按照原計劃交付時間交付了麼？原計劃達到的用戶數量達到了麼?)

• 咱們的基本目標基本已經達到了，原計劃的語言支持功能（包括自動補全，查看定義，代碼糾錯等），編譯運行功能已經完成，而且支持了cpp和python語言。
• beta階段計劃的功能也是完整的實現了：
  • 咱們實現了菜單欄美化、主題設置等alpha階段的功能完善
  • 實現了新增的包括單文件和多文件的斷點調試功能
  • 實現了草稿紙和代碼模板等全新的便捷性功能
  • 實現了項目協做功能。
• 按原計劃交付了，甚至比原計劃要提前3天交付
• 用戶量也是基本達到目標（計劃：100，實際：92）

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

• 質量明顯提升了，主要在如下幾個方面體現：
  • 在代碼更新時說明（commit）和PR、issue等信息上有了重大進步，開發者對本身已完成和待完成的工做更加明確了（有github的ISSUE記錄以及石墨文檔的工做安排記錄），同時PM也能經過commit記錄/issue和PR記錄等更方便地瞭解項目的實際進展了。
  • 測試方面，咱們每週都會安排一個時間點（週日）將這一週完成的全部功能打包併發布到服務器上進行實際測試
  • 代碼質量方面：統一使用Vscode自帶的格式化工具進行格式化處理
  • 功能質量方面：明顯提升，在測試階段發現的bug數量比alpha階段少不少

用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

• 基本一致
• 從用戶反饋來看，用戶對重要功能的接收程度和咱們事先的預想基本一致，咱們也的確知足了用戶的需求，不管是UI設計仍是功能的豐富性，都獲得了用戶的好評，相比於alpha階段，咱們離最初定下的線上便捷ide的目標更加接近。
• 離咱們目標更近了，在Beta階段實現了Debug功能，完善了IDE頁面各類UI以及功能，在實際使用上更像一個IDE了

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

• 如今的需求分析都是組內6人開會討論出來的，可能存在脫離普通用戶的狀況。若是再來一次，咱們可能會使用調查問卷等方式研究普通/專業/入門用戶等不一樣用戶的實際需求和意見。
• 關於郵箱驗證方面，咱們使用的發送驗證碼的郵箱會被部分郵箱認定爲垃圾郵件進行屏蔽。插件的使用人數也沒有達到預期。若是重來一遍，咱們會提早調研好郵箱驗證可能會遇到的麻煩，而且大力推廣插件。
• 產品推廣時機很差。若是重來，會提前進行產品的推廣，儘早將用戶吸引到咱們的產品上來。
• （alpha階段的經驗）在不熟悉一門技術的前提下，對完成功能和完成所需時間進行估計不太現實。有一些功能實現起來比想象中困難，有一些功能沒能找到最合適的解決方案。若是能再來一次，我會嘗試儘可能找到有豐富前端經驗的人詢問清楚。

計劃

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

• 有足夠的時間進行計劃。小組討論了很長時間來決定產品要實現哪些功能，並給不一樣功能的實現劃分到了不一樣的階段。
• 在Alpha階段開始前，小組共召開了4次組會討論項目的詳細細節，而且在計劃時間結束前完成了整個Alpha的規劃
• 在Beta階段開始前，小組共召開了2次組會討論Beta階段新增功能的具體細節，以及要修繕的各類功能。

團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

• 對於不一樣的意見，首先是一塊兒討論後進行投票決定；若不一樣意見分歧比較大，會讓你們去作好調研工做後開一次研討會，再進行一次深刻討論投票。

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

• 基本上都完成了。有個編輯器下拉菜單被遮擋的問題到了最後也沒有解決，主要是由於該問題對功能的正常使用影響很是小，所以優先去開發了新功能，對該問題進行了擱置，其次一些通用解決方法通過嘗試並無成功解決此問題，最終做罷。
• 沒有解決的都是一些不影響全局的小bug，而且難以發現的bug。在過後咱們還會慢慢進行解決

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

• 前端方面：在完成主題切換時，重構了許屢次css樣式及其改變的控制方法，主要是因爲對iview組件以及vue模塊的技術不是很熟悉，網上資料的解決方法也都七零八碎，所以踩了不少坑走了許多彎路，最終咱們也將解決方法進行整理做爲技術博客發佈。
• 並且部署版本與開發版本樣式不統一，最初在開發版本上調整好的樣式發現部署時不生效，又得從新調整，浪費了一些時間
• 後端方面：Beta階段工做都進展的很順利，沒有價值不大的事情。

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

在前期計劃階段，對於每個功能的實現，沒有清楚定義和衡量的交付件，但實際操做時影響不大。

• 首先大部分功能都不是新發明的功能，所以開發者對該功能有本身的合理預期（如和其餘產品或本身使用過某產品的體驗相似）。
• 這樣，若代碼達到了預期功能則進行交付。雖然沒有明確書面定義交付件，但PM和開發者和用戶對該功能的理解幾乎相同。若代碼基本完成了預期功能但尚有bug/缺陷/未完成細節，咱們將當前issue關閉、開啓一個新的issue解決該問題。在開啓新issue時，天然會對須要提升和維護的內容進行自我梳理和明確。
• 所以雖然沒有明肯定義的交付件，但交付標準是團隊的共識和常識，所以對咱們的產品開發過程來講不是問題。

在後期的每一個人開發階段，每一個人對本身的任務進行細化，幾乎每一個任務都有清楚的定義和衡量的交付件。涉及到本身的部分和其餘人負責的部分交互的時候，就須要清楚定義每一個部分實現的功能以及傳遞的信息，須要作到封裝完善，沒有bug 纔會交付。

在alpha階段的基礎上，beta階段須要修復的遺留bug和須要實現的每一個新功能都很是明確。好比說，前端的遺留bug都很細碎且數量多，只憑各人想到有什麼就修什麼，不能高效地全覆蓋全部bug，並且修復的粒度過細、可能並不適宜用常規issue來管理。所以咱們花費了一些時間將遺留bug拆分紅多個獨立的條目，並記錄在共享文檔中，前端團隊的每一個成員都及時認領，並在解決問題後在共享文檔中標記已完成，這樣就可以清晰地把握進度。

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

• 大部分任務基本按計劃進行，除了部分任務與預計計劃有些許誤差：
  • 對於瀏覽器插件的審覈和發佈機制把握得很差，致使最終瀏覽器插件沒有很好的對外推廣。由於瀏覽器插件項目的開發工做啓動較晚，啓動時基本沒有額外時間處理這方面的問題了。
  • 前端部分的意外主要是部署版本和開發版本樣式不統一致使樣式須要反覆調整。

在計劃中有沒有留下緩衝區，緩衝區有做用麼? 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

• 計劃初期有緩衝區，對於每個階段安排了最後一天進行上機對接測試;在整個項目完成後，安排了3天時間進行對接測試
  • 前期緩衝區做用：提早作好對接工做，不至於後續對接時手忙腳亂
  • 後期緩衝區做用：提早部署，作好測試準備
• 可是實際上與計劃並不一致。咱們將Beta階段分爲時間幾乎均等的兩個子階段。但操做中第一個子階段用了超過一半的時間才結束，第二個子階段只用了不到一半的時間就完成了。其緣由是對任務的估計和分解不許確，致使部分同窗在第一個階段就在作第二個階段涉及功能的支持了，至關於將部份內容從二階段遷移到了一階段，致使看起來一階段拖延了工期，但實際上在第一階段已經超額完成了大部分功能。
• 所以整個Beta階段在最後預留下的緩衝區比計劃的要多。
• 所以應該的改進是： 1. 進一步細分和明確任務 2. 準確估計任務所需時間 3. 顯式地留出緩衝區和絕對意義的DDL，避免存在拖延DDL的心理（緩衝區前爲軟DDL，實在沒完成能夠拖延至緩衝區，但緩衝區後爲硬性DDL）。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

就上面所提的出現的風險來講，「具體規劃」這件事不能在一開始定得太死，致使後期大修大改，也不能開始得太晚致使拖延進度。又或者說，也許沒有必要在前一個任務徹底完成後纔開始下一個任務的規劃。提前規劃，可讓已經完成前一個任務的空閒工做力投入到下一階段中。計劃中最好進一步細分和明確任務，準確估計任務時間，以便對後續時間作更好的評估。

資源

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

• 勞動力資源：基本足夠，但感受若是多一名擅長美工設計的人員會更好？
• 前端部分學習資源：
  • 基本足夠，有官方文檔，官方教程，官方論壇輔助debug
  • 代碼資源如組件模塊之類的，基本上不須要重複造輪子，有現成的組件和框架。
  • 前端部分也不須要什麼硬件資源。
• 後端資源：
  • 就目前用戶量而言，資源基本足夠，由於併發度並不高
  • 若是要作更大的推廣，則須要更強大的後端服務器，由於該項目自己後端就很吃資源
  • 另外郵箱資源是個問題，沒有一個被信任的郵箱，成天被攔截。

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

• 修復bug方面，會根據此bug的難度預估必定的時間；新功能方面，會首先進行功能技術實現的調研，而後根據難易程度進行時間上的估計。
• 精度基本準確

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

• 因爲咱們前端是邊開發邊部署進行迴歸和集成測試，每一個人完成一個新功能自測後，都會通知團隊其餘人，再各自測試使用，所以測試方面比較充足，bug也能及時發現。
• 美工的確低估了難度，好比在完成主題切換、美化樣式時低估了須要花費的時間，最終總的實現時間比預估要長一些。

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

• 沒有。因爲功能劃分足夠細緻，每一個人都各有專攻，人盡其用。

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

• 若是重來一遍，必定要好好衡量好後端資源需求，及時申請配置更增強大的後端服務器。

變動管理

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

• 因爲咱們基本上是天天一例會，團隊有了什麼新想法、新問題也都會在羣裏及時交流，所以都是及時知道的。
• 後端遇到問題會兩我的及時交流，通常沒有一拖一整週的狀況

咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

• 根據NABCD模型和項目功能四象限的劃分，若是遇到特別難以解決的問題，會開會討論，根據其重要性決定是否繼續在上面花費時間，好比前端編輯器右鍵菜單遮擋問題難以解決，且不影響正常功能的使用，就將其推遲，先開發「殺手功能」。
• 在石墨文檔上記錄待辦事項，在備註欄註明事項的緊急程度
• 在github的ISSUE上新增標籤，註明事項重要程度

項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

• 有，功能完善，單元測試經過，UI美觀就是出口條件

對於可能的變動是否能制定應急計劃?

• 能，咱們小組每一個人基本都負責對應的具體領域，另外也有中間人即作前端也弄後端。
• 若是那個部分由突發狀況沒法按時交付，可讓中間人幫忙。

員工是否可以有效地處理意料以外的工做請求？

• 能，咱們小組的全部成員能力都很強，都能按時完成本身的任務，那處理意外任務更是綽綽有餘。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 可能會嘗試在項目開始時就徹底決定好樣式設計。其實最初的計劃也是這樣的，可是因爲種種緣由沒能堅定執行。若是可以再來一次，可能會定死在第一階段堅定完成，而且約定以後再也不進行大的變更。
• 沒有什麼經驗教訓，若是重來一遍，咱們還會按照當前的流程順利完成任務。

設計/實現

設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

• 設計工做在正式開發以前
  • 是PM發起，團隊一塊兒討論決定的設計方案。
  • 是合適的時間：你們都充分閱讀了用戶反饋，並對項目的下一步走向進行了分析和思考。
  • 是合適的人：PM領頭，團隊共同討論。
• 咱們是在開發階段的前若干天以集體討論的形式完成的，但效果並很差，緣由一是不一樣人有本身的不一樣的想法和風格，有的人喜歡各抒己見，有的人卻不喜歡提出新點子也不喜歡對方案表達明確的喜惡，致使團隊難以民主地決定一個具體的方向和方案。其實應該經過用戶調查的方式來肯定，但咱們沒有，咱們六人閉門造車卻意見不一樣，才致使這種狀況發生。另外一個緣由是設計和思考須要時間，咱們不該該期望在一次會議中將目標徹底定下來，應當先讓各自提早思考，再一塊兒頭腦風暴，最後討論充分後進行決定。設計和計劃佔一個星期的時間不是沒有道理，咱們應當好好利用的。

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

• 有。先大體規劃方向，交由負責的小組具體討論。

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

• 有運用單元測試，先後端均有
• 具備必定效果，可以幫咱們排除一部分bug
• 有區別，區別在於開發進行過程當中發現一部分接口並不能很好的實現預想的目標，須要修改或新增接口。

什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

• 美化樣式方面的bug最多。因爲對iview組件和前端框架的不熟悉致使的，並且開發版本與部署版本樣式不統一，一開始沒能發現。
• 發佈以後發現的重要bug：重名項目的重名文件會因爲vue生命週期而出現內容保留的問題。開發的時候考慮到了同一項目的重名文件問題，但沒有考慮和測試周全，覺得同一項目的問題解決了，不一樣項目也就沒問題了。是關於生命週期的bug，發生這些情況的主要緣由仍是前端開發經驗不足、不能完善地考慮各類問題。

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

• 最開始是在每日例會上，由你們共同檢查沒問題後，才進行代碼的簽入。
• 後來發現了github的review提醒功能，引入該功能，每次有人想要簽入代碼時，提醒相關人員進行代碼複審，沒問題後才贊成簽入，提升了很多效率。
• 咱們有嚴格的開發流程和代碼規範規定（PR流程），你們都在嚴格執行。

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 測試十分重要，若是重來，會採用其餘好比測試驅動開發等開發模式，讓測試更規範。
• 開發流程很是重要，若是重來，咱們會依舊採用咱們流暢的PR流程
• 設計過程很是重要，若是重來，咱們會從新認真考慮用戶需求，真實的去採訪用戶詢問他們真正的需求，而不是單純幾我的在構思。

測試/發佈

團隊是否有一個測試計劃？爲何沒有？

• 有測試計劃，安排每週一天將當前已完成的版本打包發佈測試
• 在最後一週的測試中，有一位同窗專門進行一次壓力測試，測試併發狀況；另外的同窗分別對本身寫的部分進行單元測試

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

• 有進行驗收測試，詳見測試報告

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

• 有
• 後端使用SpringBoot的單元測試框架，以及nodejs的單元測試框架
• 另外也有使用Jmeter進行壓力測試

團隊是如何測量並跟蹤軟件的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

• 經過JMETER定製測試，採用多線程模擬多用戶進行壓力測試。
• 有用，經過壓力測試發現了前端的性能問題，從而進一步採起了相應的對策解決了前端性能問題
• 例如前端後續就進行了cdn優化以及gzip優化，再次進行測試後前端加載速度提升了近3倍

在發佈的過程當中發現了哪些意外問題？

• 沒有意外

咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?

• 測試必定要使用好框架，開發必定要定好流程，這樣效率很高而且bug率很低。

團隊的角色，管理，合做

團隊的每一個角色是如何肯定的，是否是人盡其才？

• 角色是按照先報名後分配的方式肯定的，有明確角色意願的同窗首先被知足，沒有明確方向的同窗補上剩下的崗位。

• 在Alpha階段的學習和歷練以後，每一個同窗因爲本身的分工（開發流程中的分工、實現功能不一樣的分工……）不一樣，使得每一個人都成爲了某領域獨一無二的「專家」。所以在團隊合做中，常常有涉及到其餘同窗所精通領域的時候，咱們都會主動與對應的同窗溝通請教，讓專業的人作專業的事，不只作到了人盡其才更提升了工做效率。

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

• 有，前端組員會互相交流共性問題的解決方案；若是一人的任務出現了暫時難以解決的問題，其餘已經完成本身任務的團隊成員會主動認領新任務、保證項目順利推動。
• 後端兩位組員會積極討論，共同解決出現的各類問題

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

• 必定要積極溝通，不要怕問「弱智問題」可能致使的尷尬。
• 積極溝通才能瞭解對方在幹什麼，規劃好本身要幹什麼，共同完成同一功能

每一個成員明確公開地表示對成員幫助的感謝

成員	感謝信
李PX	我感謝韓WZ對個人幫助，由於他積極和我探討後端各類優化的方法 我感謝向WL對個人幫助，由於他總能提出一些使人意想不到的想法，幫助咱們更好的解決問題 我感謝田ZJ對個人幫助，由於他總能在咱們遇到bug的時候，提出修復方案，幫助咱們修復bug 我感謝韓FJ對個人幫助，由於耗費大量精力完成了很牛逼的文件樹拖拽功能，幫助團隊省下了不少美化工做 我感謝萬ZF對個人幫助，由於每一次對接時只要說一遍萬ZF就能理解，並且能快速完成對接任務
田ZJ	我感謝李PX對個人幫助， 由於他邀請我進入這個新的充滿活力的團隊，在熟悉項目方面有什麼疑問，他也都積極幫我解答，也和我一塊兒討論terminal相關模塊的實現和設計，幫我發現了一些bug，還幫我複審了代碼。 我感謝向WL對個人幫助，由於他協助我完成了debug的功能實現並幫我測試出了一些bug，在美化樣式方面也提出了一些很好的建議和幫助，教我如何在本地進行build版本的測試。 我感謝韓FJ對個人幫助，由於她跟我一同討論iview組件樣式覆蓋的問題，幫我熟悉文件樹部分的代碼邏輯，幫我複審過代碼，共同完成草稿紙頁面的實現。 我感謝萬ZF對個人幫助，由於他幫我熟悉了登錄註冊部分的代碼邏輯，共同完成了草稿紙頁面的實現。 我感謝韓WZ對個人幫助，由於他在團隊會議上幫我講解了後端的實現邏輯，讓我對整個項目實現有整體上的把握，還幫我進行了docker的完善支持了gdb等功能，對項目功能的規劃也很是積極熱心地提出了許多好的建議。
韓WZ	我感謝李PX對個人幫助，由於他幫助我對後端項目的質量進行把控，提出了不少不錯的建議
向WL	我感謝李PX對個人幫助，由於遇到bug常常能耐心聽我小黃鴨式debug，聰明的大腦也能很快想到問題所在；同時團隊內有一些工做也會主動包攬，減輕了其餘同窗的負擔。
韓FJ	我感謝李PX對個人幫助，由於某個具體的事情: 爲前端提供清晰的接口文檔；完成前端待解決任務文檔，push效果顯著 我感謝萬ZF對個人幫助，由於某個具體的事情: 共同完成了文件樹的許多新功能；完成菜單欄代碼的編寫，爲我完成草稿紙菜單欄提供了很好的參考 我感謝田ZJ對個人幫助，由於某個具體的事情: 解決了許多第一階段前端遺留的bug，對項目質量的提升幫助極大 我感謝向WL對個人幫助，由於某個具體的事情: 高效明確地完成前端爲了實現新功能對編輯器的提出的新需求
萬ZF	我感謝李PX對個人幫助，由於某個具體的事情：替我解決了文件上傳的bug 我感謝田ZJ對個人幫助，由於某個具體的事情：幫我解決了某些組件主題切換的bug 我感謝韓WZ對個人幫助，由於某個具體的事情：和我積極交流了帳號郵箱綁定的新想法

總結

你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

• 第三檔

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

• 我認爲已經作到了「規範」，進入了「創造」階段
• 其中一部分緣由是團隊確實有很好的規範和習慣，從項目管理到團隊合做都已通過了磨合和規範期的不穩定。但更大一部分緣由是團隊內部對於軟件工程方法論的依賴程度並不高，你們都是以工程師的心態進行合做，不須要過多的條條框框進行約束和額外規範，相互的幫助和協做成爲了工程師文化的一部分、是優秀的習慣，所以目標、規範與習慣、計劃等都較爲一致，難以產生大的矛盾，注意力主要都集中在產品和開發自己上。

你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

• 有了更加規範的開發流程和統一的代碼規範
• 團隊的活力更強了，你們的投入度更高，配合更加默契，每一個人對於本身以及團隊的工做進度都可以有比較全面的把握。

你以爲目前最須要改進的一個方面是什麼?

• 項目推廣方面須要加大力度
• 儘管和上一階段相比更有活力了，但仍是感受團隊比較嚴肅，雖然在問題上你們很活躍，可是團隊總體氛圍仍是十分嚴肅的。

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

• 高效的每日例會：每日例會上高效的進行工做彙報以及交流討論
• 最小功能集開發：遇到棘手的、不影響功能的問題，及時將其移出正常的開發流程，以後再解決，以避免被卡住進度
• 代碼管理：善用github。
• 業務人員和開發人員必須相互合做。咱們團隊的全部成員都是開發成員，也都會參與到功能性的設計中
• 常常地交付可工做的軟件。在alpha階段中一切工做以努力完成一個可用的IDE爲目標。在beta階段，將工做劃分爲多個新任務，每每在前一個任務徹底結束後纔開啓下一個，基本沒有遺留問題。

正如咱們前面提到的， 軟件的質量 = 程序的質量 + 軟件工程的質量，那團隊在下一階段應該如何提升軟件工程的質量呢？

• 進一步增強測試方面的工做，真正實現測試驅動開發。

代碼管理的質量具體應該如何提升？ 代碼複審和代碼規範的質量應該如何提升？

• 繼續嚴格執行定好的代碼規範，代碼複審要更加仔細，複審時開發人員和複審人員同時在場。

整個程序的架構如何具體提升？ 如何經過重構等方法提升質量，如何衡量質量的提升？

• 經過對代碼模塊進一步解耦、模塊進一步細分來提升代碼質量，代碼的拓展性能夠衡量質量的提升。

其它軟件工具的應用，應該如何提升？

• 前端jest單元測試工具的使用須要進一步落實，保證前端也能作到全部代碼的高覆蓋率。

項目管理有哪些具體的提升？

• 引入了一套標準化的開發流程。具體見github，contibute.md文件

項目跟蹤用戶數據方面，計劃要提升什麼地方？例如大家是如何知道每日/周活躍用戶等數據的？

• 經過管理數據庫的用戶信息、登陸服務器查看訪問量來知道每日/周活躍用戶等數據

項目文檔的質量如何提升？

• 約束文檔撰寫規範，保證文檔的使用者能很清楚的明確含義

對於人的領導和管理， 有什麼具體能夠改進的地方？ 請看《構建之法》關於PM、績效考覈的章節， 或者 《人件》等參考書

• 對於鼓舞團隊士氣、凝聚團隊人心的工做明顯不足。若是說Alpha階段的主要動力來自於對功能目標的追求、對新鮮事物的興趣、對完成項目的野心，在Beta階段團隊的主要動力就是持續工做開發新功能的慣性、和每日例會本身不能摸魚的基本心理。在團隊動力不足的時候，做爲PM應當使用向團隊展現項目進度 / 預發佈項目並收集用戶積極反饋等手段，推進團隊繼續前進並提振士氣。

• 擁有一個明確可達的目標也是重要的手段之一，在Alpha階段PM作出了詳細且可信的功能規格說明書，從而讓你們有明確的目標努力。然而在Beta階段PM並無給出像Alpha階段同樣的功能規格說明書和技術規格說明書，使得團隊成員的目標只是口頭描述的樣子，可信程度和明確程度都不高，心理上不免產生摸魚的動搖（如典型的「到時候再說」）。

對於軟件工程的理論，規律有什麼心得體會或不一樣意見？ 請看閱讀做業。 (這個做業的期中閱讀)

• 團隊會議的確可以提升團隊開發效率，鞭策隊伍不要拖延。