本部分的反思采取 Q&A 的形式，對這篇博客中列舉的問題進行了一一回答，從而對本團隊在 Alpha 階段所取得的成果以及不足進行系統的反思與梳理。
設想和目標
我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
我們的軟件主要解決用戶在短時間內需要大量背單詞，且傳統的背單詞 APP 無法幫助其實現長久記憶，紙質書又顯得過於笨重不夠靈活的問題。
我們將以”記憶宮殿“為理論基礎的 A4 紙背單詞法在 PC 端進行了實現，創新式提出了『詞圖』概念，旨在賦予單詞更豐富的環境信息，促進用戶對單詞的記憶，更多軟件定位請見 NABCD 文檔。
對於典型用戶和用戶場景的詳細說明請見功能規格說明書的用戶和典型場景部分。區別於目前多種手機背單詞軟件的碎片化背詞用戶，我們的主要受眾是需要在一段時間內專門背單詞的用戶群體，如正在准備四六級、托福、雅思等英語考試的而需要專門背單詞的人群。
我們達到目標了么（原計划的功能做到了幾個？ 按照原計划交付時間交付了么？ 原計划達到的用戶數量達到了么?)
根據項目發布文檔的用戶典型場景滿足情況分析，我們已經成功實現了 Alpha 階段計划的全部功能，並且根據燃盡圖，成功在原計划交付時間交付了產品。
對於用戶數量，我們達到了計划階段功能目標的保守總用戶量和日活用戶量，但是和理想情況差距較大，仍然具有很大的改進空間。具體反思請見下文。
用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
綜合考慮本軟件的性質以及 Alpha 階段的宣傳力度，用戶量與預想基本一致。
根據項目發布文檔的用戶反饋部分，可以看出用戶對目前基本功能的可用性和完成度基本持肯定態度。但是由於 A4 紙背單詞法的理念普及度不夠，教程的引導性不足，加之 PC 端的使用和注冊流程相對不便，因此用戶對本軟件核心功能的接受程度較低，大部分用戶需要花費一定的時間才能上手。具體反思請見下文。
有什么經驗教訓? 如果歷史重來一遍,我們會做什么改進?
可以說，用戶量和用戶的接受程度是本項目 Alpha 階段最嚴重的問題。因此，團隊在此進行詳細的反思總結：
| 遇到的問題 | 問題產生原因 | 改進方案 |
|---|---|---|
| 用戶注冊總量較少 | PC 端操作不便、郵件注冊不變 | 爭取支持更高效的注冊方式 |
| 用戶登錄后迷茫不知所措 | 1. 教程僅在主頁呈現，沒有在用戶訪問各頁面提供更明確的指導。 2. 新用戶我的詞圖界面過於空白。 |
1. 優化教程的實現方式。 2. 豐富新用戶的頁面內容 |
| 單詞認識程度選擇后操作不符合用戶認知 | 我們采取了扇貝單詞的跳轉邏輯，但是從用戶反饋看大部分用戶對此並不熟悉或較難適應。 | Beta 階段結合大部分用戶的使用情況對單詞的記憶狀態進行進一步改進 |
| 詞圖的部分操作不便。如單詞重疊、僅在中間出現等 | 1. Alpha 階段主要目標為實現基礎功能，對細節的要求較低 | Beta 階段對單詞的出現位置進行優化 |
| 對詞圖的部分操作不知所措 | 工具欄缺少文字解釋 | 添加 tip 等提示引導用戶操作 |
| 用戶和 PC 的交互體現不夠充分 | 1. 目前暫未添加用戶搜索單詞並添加的功能。 2. 目前暫不支持用戶上傳頭像、圖片背景等 |
對用戶主動性操作進行補充和完善 |
| 僅 PC 端限制使用場景 | 目前對平板端的適配存在一些問題 | Beta 階段完善軟件對平板的適配問題 |
以上問題總結了本項目截止到 Alpha 階段接收到的來自眾多用戶的評價和建議與所有隊員進行集體討論反思后的成果。其中大部分和團隊 Beta 階段的計划重疊，這也使得我們對 Beta 階段的開發方向更加明確。在此感謝張少昂助教對我們產品存在的問題所做出的全面透徹的剖析和評價。
計划
我們有足夠的資源來完成各項任務么
- 人力資源：由於本項目的開發難度較大，預期實現的功能較多，並且市面上目前沒有可以參考的類似軟件，因此總任務量較為繁重。但是，通過合理的分配團隊成員的任務，我們充分發揮了所有隊員的技術優勢，成功完成了 Alpha 階段的功能開發任務。但相對而言，在宣傳上，我們仍處於力不從心的狀態。
- 服務器資源：目前我們購買的服務器基本能滿足 Alpha 階段的需求。但是由於本軟件未來將涉及多種圖片的操作，對網絡帶寬的要求較大，因此目前服務器在此方面有一定的壓力。在 Beta 階段，我們將通過限制用戶上傳的圖片體量等方式綜合權衡用戶體驗和服務器負載能力。
- 宣傳資源：由於本項目的面向的受眾和北航校內的同學吻合度較低，因此需要能向社會宣傳的渠道。但是，目前隊員的自身資源不足以讓我們獲取更好的社會宣傳平台。這也是 Beta 階段我們希望能克服的問題之一。
各項任務所需的時間和其他資源是如何估計的，精度如何?
首先，我們根據預估的任務量大小和難度對每一個任務進行所需要的時間預期安排，並且在石墨文檔中進行了詳細的列舉和記錄。當隊員開始做任務時，我們將根據任務的實際情況對預期時長進行微調。所有任務精度控制在工作時間 8h 以內。
測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
由於 Alpha 階段的開發任務較大，時間較短，因此留給測試的時間和人力資源相對有限，此外我們的數據庫本身較大，因此未進行充分的單元測試，這也是 Alpha 階段存在的不足之一。但在有限的資源下，我們仍進行了全面的壓力測試、場景測試、 API 測試等，詳見測試文檔。對於前端主頁、教程等美工設計，我們成功預期了其難度，並且分配專人攻克美工問題，最終取得了比較滿意的 UI 效果。
你有沒有感到你做的事情可以讓別人來做（更有效率）?
在前期功能模塊開發階段，由於團隊內部的充分溝通和合理的任務划分，每位隊員都領到了自己擅長的任務，可以說將每個人的優勢都發揮了出來。在后期集成部分，各任務之間具有一定的交叉，我們預期到類似問題的發生，並決定在后期采用集體線下開發的方式，遇到問題及時尋找專人解決，因此開發效率較高。
有什么經驗教訓?如果歷史重來一遍, 我們會做什么改進?
經過 Alpha 階段的磨合，我們發現本團隊的成員都是悶頭開發黨，這導致我們的項目功能完成度較高，但是在宣傳力度等方面存在較為明顯的不足。因此，我們認為應當划分更多的精力在產品的宣傳方向，並且及時獲取用戶反饋並及時修正現有錯誤。另外，對於測試的進行應當提上日程，防止后期時間較緊而沒有時間進行完備的測試。
變更管理
每個相關的員工都及時知道了變更的消息?
由於我們所有的小組會議和后期開發沖刺階段全部全員線下進行，因此每一個變更都能及時傳達給團隊成員。另外，我們使用了”看板法”對任務進行了列表和匯總，完成后即使划去，清晰且高效。
我們采用了什么辦法決定“推遲”和“必須實現”的功能?
經過總結，本項目 Alpha 階段實現的所有功能的分類和大體優先級如下：
- 涉及初次登陸用戶的舒適度的功能為必須實現。
- 涉及老用戶長期使用的舒適度的功能推遲實現
- 涉及詞圖核心功能的基本功能必須實現。
- 涉及詞圖核心功能的拓展和美化推遲實現
項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?
- 功能方面：
- Alpha 計划階段的所有任務基本完成是出口的底線。
- 被使用概率較高的核心功能要達到較高的完成度，保證無較大差錯。
- UI 方面：
- 主頁足夠美觀和大氣，能夠抓住用戶眼球。
- 具有詳細的教程，並且教程入口伴隨用戶使用全過程。
- 各頁面整體銜接流暢、風格統一。
- 系統方面：
- 用戶使用流暢，各請求不能有過長的等待時間。
- 能保證用戶信息安全和數據庫數據安全。
對於可能的變更是否能制定應急計划?
- 將最核心的功能放在優先級較高的位置實現。
- 對於功能實現要求的修改，集中在發布前一天及之前進行。發布臨頭時不對核心功能進行大幅度修改，防止翻車。
- 對於會議的流程進行詳細記錄，使用 Gitlab、石墨文檔等對進展進行記錄，規范編碼的格式和注釋等，預備人員變更問題。
員工是否能夠有效地處理意料之外的工作請求？
首先，本團隊隊員具有較強的學習能力和責任心，對於意料之外的需求，大多能夠及時進行技術棧的補充並盡快完成。另外，本團隊具有較強的機動性，兩名后端和四名前端之間對接密切，當某一隊員出現特殊情況時，其他隊員能做到接手其工作並繼續開發。
我們學到了什么，如果歷史重來一遍，我們會做什么改進？
首先，我們意識到了良好的代碼風格和規范的注釋的重要性，它能幫助其他人盡快了解模塊的功能和實現機制，方便進行人員調整時的快速上手，這是我們存在欠缺並且需要改進的關鍵之一。另外，線下面對面的交流是十分必要的，能夠具有更高效的開發效率和更充分的交流。
設計/實現
設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
設計工作在 Alpha 階段計划階段系統功能設計已經完成，由本團隊的 3 名 PM 領導，全替成員參與設計完成。
從 Alpha 階段開發結果來看，目前順利完成了 Alpha 階段的與其功能，且前端 UI 和原型圖設計基本一致，充分證明了前期計划的有效性和准確性。
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
在開發的前期情況較少，由於時間充分，隊員都對功能或界面的實現給予最高要求。但是到開發后期，由於時間緊迫且任務較重，對於部分優先級較低的任務，團隊商討后允許對某些任務的完成質量要求暫時放低，並且對改任務的預期質量進行了完整的記錄，待后期補全。
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？ 比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
由於 Alpha 階段開發時間短，任務重，因此本項目未能進行完備的單元測試和 TDD，而是以功能為單位進行驅動開發。在開發階段，我們主要使用了 Gitlab 的 milestone、issues 進行任務分配，並且使用石墨文檔進行任務記錄。在 Alpha 階段的初期，對 issues 的利用比較生硬，因此效果不佳。后來在團隊成員的發掘和助教的提點下，我們采用將 commit 和 issue 進行關聯的方式，極大的提高了 issues 的意義和操作的關聯度。
至於前后端之間的交流，我們采用 wiki 書寫 API 文檔和固定 issues 的關聯的方式進行交互，效果較好。
什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
由於本項目在功能方面要求較高，完成度較高，因此發布后沒有出現嚴重的 bug。目前出現的所有 bug 都集中在前端 UI 界面顯示上，其中包括不同瀏覽器的適配、平板端的適配、分遍率的適配等。詳見項目發布的 bug 匯總部分。
代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
我們在對功能進行測試時對在實現過程中具有一定混亂情況的代碼進行了整理，並且前端和后端都使用官方代碼規范和代碼規整方式。前后端的代碼規范要求詳見項目發布博客的軟件工程質量部分。
測試/發布
團隊是否有一個測試計划？為什么沒有？
團隊在 Alpha 階段有測試計划，但綜合考慮時間和人力問題，最終計划進行了簡化並進行了初步完成。
是否進行了正式的驗收測試？
由於測試幾乎在發布前夕統一完成，因此驗收測試和軟件功能基本測試重合。
團隊是否有測試工具來幫助測試？
很多團隊用大量低效率的手動測試，請提出改進計划：至少一個方面的測試要用自動化的測試工具，自動化的測試結果報告，比較測試結果的差異，等等。
我們在測試時使用了 postman、siege 等工具進行 API 和壓力測試，並使用 Django 自帶單元測試模塊進行單元測試。今后計划從以下方面進行自動化改進：
- postman記錄請求，方便今后進行自動回歸測試
- 繼續使用siege進行壓力測試，但該軟件無法使用自動化實現
- 結合CI/CD實現單元測試的自動化
團隊是如何測量並跟蹤軟件的效能（Performance）的？壓力測試（Stress Test）呢？ 從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
我們對於服務器的各項負載能力進行了全面的分析和壓力測試。我們在 [Gitlab](https://gitlab.buaaoo.top/2021_alige_homeworks/group_projects/mei_zi_zi_tian_xi_xi_d UI /backend/wikis/API%E5%8E%8B%E6%B5%8B%E5%88%86%E6%9E%90) 中對 API 進行了數量級分析，並選取了有代表性的 API 進行壓測。除此之外，我們還對 Nginx 的最大連接數和負載均衡進行了測試，詳細測試記錄詳見測試報告。
在發布的過程中發現了哪些意外問題？
在發布當天晚上出現了服務器崩潰問題。后發現這是由於服務器短時間內突然連接數過大導致，和系統負載能力有關。之后通過重啟服務解決了此問題。
我們學到了什么?如果重來一遍,我們會做什么改進?
測試方面是本團隊 Alpha 階段相對不夠完善的方面，因此我們提出以下改進方案：
- 將測試的開始時間提前，在關鍵功能上使用測試驅動開發的方式進行。
- 前后端完善單元測試，並使用 CI/CD 進行自動化測試。
- 繼續使用 postman，siege 等進行 API 測試和壓力測試。
- 邀請內測人員提前進行功能測試，模擬用戶使用情況。
團隊的角色，管理，合作
團隊的每個角色是如何確定的，是不是人盡其才？
本團隊采用 3 名 PM 統籌方式，其中 2 名后端 PM，1 名前端 PM，每一項目大型模塊都有 PM 進行規划和管理，以減少 PM 的工作量和工作粒度。
團隊伊始，共有 4 名后端和 2 名前端。但是在分析完團隊目標需求后，我們認為前端工作量較大，因此其中兩名后端人員選擇轉型為前端，並且在后續的開發中迅速熟悉了前端技術棧且完成了前端的開發工作。
在團隊合作方面，本團隊始終堅持線下會議，並且在沖刺階段持續進行線下集體開發方式，組員之間配合默契，關系融洽，為開發營造了愉快的氛圍。
團隊成員之間有互相幫助么？
由於不同的團隊成員都有自己的開發特點，例如：
- 擅長攻克難題
- 擅長做精某個特定功能
- 擅長快速實現基本功能
結合不同組員的特點，我們在開發中不乏互相幫助，並且對幫助的情況進行了記錄。
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
由於本團隊合作氛圍較好，大家基本按照預期的計划和 PM 的規划完成任務，在項目管理方面比較順利。在合作中，有時會出現部分功能實現不匹配等問題，前后端進展不一致相互等待等問題，例如 API 文檔確定時間較晚等問題。
針對以上問題的解決，我們在統一線下開發時對沖突部分進行了融合，並且使用特定 issue 關聯 API 文檔的問題集中匯總 API 文檔的改動，從而化解合作上的不一致問題。
總結
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
目前團隊正在豐富軟件功能並完善已完成功能，處於 CMM 的已管理級（Managed）階段和 CMMl 三級，明確級。
你覺得團隊目前處於萌芽/磨合/規范/創造 階段的哪一個階段?
目前團隊處於創造階段。
你覺得目前最需要改進的一個方面是什么?
目前最需要改進的方面是宣傳力度和測試力度。具體改進方案前文已經敘述。
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
| 原則 | 完成質量（1~10） |
|---|---|
| 盡早和持續第交付有價值的軟件來滿足客戶 | 8 |
| 歡迎對需求提出變更 | 6 |
| 要不斷交付可用的軟件 | 8 |
| 項目過程中，業務人員與開發人員必須在一起 | 8 |
| 要善於激勵項目人員 | 9 |
| 最有效的溝通方法是面對面的交談 | 9 |
| 可用的軟件是衡量進度的主要指標 | 9 |
| 提倡可持續的開發 | 8 |
| 對技術的精益求精以及對設計的不斷完善將提升敏捷性 | 7 |
| 要做到簡潔，盡可能減少不必要的工作 | 8 |
| 最佳的架構，需求和設計出自於自組織的團隊 | 7 |
| 團隊要定期反省如何能夠做到更有效，並相應調整團隊的行為 | 8 |
代碼管理的質量具體應該如何提高？ 代碼復審和代碼規范的質量應該如何提高？
- 補充代碼注釋
- 進一步規范新建文件目錄樹
整個程序的架構如何具體提高？ 如何通過重構等方法提高質量，如何衡量質量的提高？
前端讓每個組件的功能明確，可能多次出現的組件使用統一組件，提高前端的性能。
后端規范 API 的實現方式和報錯代碼的含義。
項目跟蹤用戶數據方面，計划要提高什么地方？例如你們是如何知道每日/周活躍用戶等數據的？
計划增加每個用戶的停留時間和用戶留存量的記錄。
項目文檔的質量如何提高？
3 名 PM 合作完成需要發布的文檔，3 名組員幫忙准備展示視頻、測試功能等素材。
對於人的領導和管理， 有什么具體可以改進的地方
- 需要及時進行激勵，並且擁有完備的激勵機制
- 需要制定有規律的會議方式
- 隊長記得請吃飯
對於軟件工程的理論，規律有什么心得體會或不同意見？
- 在計划階段進行完整的設計可以幫助推進后期開發方向
- 計划階段對項目進展的規划和實際進展有一定偏差，需要及時進行調整
- 對於 API 文檔、測試等計划需要提前進行規范，提前開始工作
最后附一張總結反思大會現場照片：
