設想和目標

1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

本次項目旨在開發一款巡養修檢管理子系統，以滿足企業在設備巡養修檢方面的需求，例如提升用戶在報修、維修的效率，改善信息記錄分散、不規范，導致設備全生命周期的關鍵環節難以追溯，維修保養工作效率低下的問題。在項目啟動階段，我們明確了典型用戶為工程師和經理。然而，經過項目實踐，我們發現雖然對問題有初步定義，但在某些細節上仍存在模糊之處，例如用戶需求的多樣性超出預期，導致部分功能設計未能精準貼合所有用戶需求。

2. 是否有充足的時間來做計劃？

在項目初期，團隊預留了三天時間進行詳細規劃。雖然時間看似充裕，但在實際推進中，由于需求調研不夠深入，導致計劃多次調整，浪費了部分時間。

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

面對同事們對計劃的不同意見，我們主要通過召開多次頭腦風暴會議，讓每個人充分表達觀點，然后由組長結合項目目標和資源情況，權衡利弊后做出決策。

計劃

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

原計劃的 10項主要任務中，完成了10項，原計劃工作全部完成。

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

在項目過程中，確實發現了一些事后看來沒必要或價值不大的工作。比如在初期對一些小眾功能進行了過度設計和開發，結果在用戶反饋中這些功能幾乎無人問津，浪費了人力和時間資源。

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

大部分任務都有清楚定義的交付件，例如界面設計任務明確了交付的界面原型圖和設計文檔，開發任務明確了代碼模塊和功能測試報告。但在一些邊緣任務上，交付件的衡量標準不夠清晰，導致驗收時出現爭議。

4. 是否項目的整個過程都按照計劃進行？

項目整體進度未能完全按照計劃進行。在開發階段，由于需求變更頻繁，原計劃的開發節奏被打亂，部分任務的完成時間比預期延遲了一周以上。不過在后續階段，通過加班和資源調配，盡量追趕了進度。

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

計劃中預留了 10% 的緩沖區，主要用于應對可能出現的技術難題和需求變更。緩沖區在一定程度上緩解了項目進度的壓力，緩沖區時間讓我們有足夠的時間進行技術攻關，避免了項目徹底延誤。

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

未來計劃中，我們將重新評估緩沖區的定義，根據項目實際風險情況動態調整緩沖區比例。同時，對于加班情況，將嚴格控制，盡量通過優化流程和提高效率來避免過度加班，確保團隊成員的工作生活平衡。

資源

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

在項目初期，我們評估認為資源基本充足，但隨著項目推進，發現部分資源存在不足。例如在開發階段，由于任務量增加，開發人員的配置略顯緊張，導致部分任務進度緩慢。測試階段，雖然預留了足夠的人力，但測試工具的種類和功能不夠完善，影響了測試效率。

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

各項任務所需的時間和其他資源估計精度一般。對于開發任務，時間估計相對準確，但對美工設計和文案等非編程任務的難度估計不足。例如美工設計任務，原本預計3天完成，實際用了5 天，原因是設計過程中需要多次修改以滿足用戶審美和功能需求。

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

測試階段雖然預留了足夠的人力，但測試工具的種類和功能不夠完善，影響了測試效率。對于美工設計和文案等非編程任務，確實低估了難度，導致實際工作時間超出預期。

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

部分任務確實存在分配不合理的情況，但是通過團隊成員的溝通分工已經很好的解決了，每個人負責自己擅長的模塊。

變更管理

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

團隊成員都能夠及時知曉變更消息，但偶爾會出現個別成員因請假或溝通不暢而錯過變更通知的情況。

2. 我們采用了什么辦法決定“推遲”和“必須實現”的功能？

在決定“推遲”和“必須實現”的功能時，我們主要依據用戶需求的優先級、對項目目標的影響程度以及資源消耗情況。例如，對于一些不影響核心功能且實現成本較高的功能，果斷推遲到后續版本；而對于用戶反饋強烈、能顯著提升產品競爭力的功能，則優先實現。

3. 項目的出口條件（Exit Criteria）有清晰的定義么？

項目出口條件有較為清晰的定義，包括功能完整性、性能達標、用戶驗收通過等。但在實際操作中，由于部分功能的性能指標不夠明確，導致驗收時出現了一些爭議。

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

對于可能的變更，我們制定了初步的應急計劃，例如在需求變更時，重新評估影響的任務優先級和時間安排。但在面對一些突發的、影響較大的變更時，應急計劃的靈活性和有效性仍需提升。

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

成員在處理意料之外的工作請求時，都表現的不錯。

設計/實現

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

設計工作主要集中在項目初期，由團隊成員共同負責。

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

在設計工作中確實遇到了一些模棱兩可的情況，例如界面交互的細節設計。團隊通過查閱相關設計規范、參考競品案例以及多次內部討論，最終解決了這些問題。但這一過程耗時較長，影響了整體進度。

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

團隊在開發過程中運用了單元測試、測試驅動開發（TDD）等工具，也嘗試使用了 UML 進行設計建模。

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

工單提交產生的 Bug 最多，主要是因為該功能涉及復雜的業務邏輯和多個子模塊的交互。

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

代碼復審由團隊成員共同負責，基本嚴格執行了代碼規范。

測試/發布

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

團隊制定了詳細的測試計劃，包括單元測試、集成測試、系統測試和驗收測試等階段，明確了各階段的測試目標、測試用例和測試人員。測試計劃的制定為項目的質量把控提供了有力保障。

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

進行了正式的驗收測試，邀請了部分典型用戶參與。通過驗收測試，及時發現了軟件在實際使用場景中的一些問題，例如界面操作不夠友好、部分功能響應速度較慢等，并及時進行了修復。

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

團隊沒有使用自動化測試工具來輔助測試。

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

團隊通過性能測試工具測量并跟蹤軟件的效能，從實際運行結果來看，測試工作基本達到了預期效果，但也發現了一些問題，例如在高并發場景下，軟件的性能瓶頸較為明顯。未來需要進一步優化測試策略，增加對高并發等復雜場景的測試覆蓋。

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

在發布過程中，遇到了一些意外問題，例如服務器配置與開發環境不一致，導致部分功能無法正常運行。經過緊急排查和調整，問題得到了解決，但這一事件也提醒我們在發布前需要更加細致地進行環境測試和配置檢查。

總結

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

結合 CMM/CMMI 模型，目前團隊處于 CMMI 的已定義級（Level 3）向已管理級（Level 4）過渡的階段。我們已經建立了一套較為完善的項目管理體系，包括計劃、變更管理、質量控制等流程，但在數據驅動的決策、過程優化等方面仍有提升空間。

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

從團隊發展階段來看，目前處于規范階段。團隊成員已經熟悉了項目流程和協作方式，能夠按照既定規范開展工作，但在面對復雜問題和變更時，仍需進一步提升應對能力和靈活性。

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

相比前一個里程碑，團隊在需求管理和變更管理方面有了顯著改進。通過引入變更通知確認機制和更加嚴格的優先級評估流程，減少了因需求變更導致的混亂。同時，測試計劃的完善也提高了軟件質量，減少了發布后的問題。

4. 你覺得目前最需要改進的一個方面是什么？

目前最需要改進的是資源管理和任務分配的合理性。我們需要更精準地評估各項任務的資源需求，合理分配任務，避免核心成員過度負擔低價值任務，同時引入外部資源來處理一些重復性工作，提高整體效率。