設想和目標

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

• 我們設計的向量圖編輯系統主要解決變電站繪製電路圖問題；
• 定義為以向量圖的方式繪製出電路圖；
• 僅及於簡單的使用者與場景，尚未進行具體典型的使用者與場景描述。

2. 我們達到目標了麼（原計劃的功能做到了幾個？  按照原計劃交付時間交付了麼？ 原計劃達到的使用者數量達到了麼?)

我們計劃實現畫元器件、新增任意元器件、對圖形進行放縮、各元器件之間的規則連線、滾動條對畫板進行拖動  更大的畫圖區域、圖形元素的點選與刪除、特殊的標註文字（自創版）、一鍵還原、畫圖時候的拖動重影、畫圖過程中右鍵可以放棄繪圖；最後在alpha版本驗收時完成了這些功能的實現；同時由於我們的時本地繪圖軟體，暫沒有實際使用者數量。

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

相比剛開始做這個專案時，團隊軟體工程質量提高了。剛開始接觸這個專案對專案不瞭解，也沒有具體分工。現在對專案所用到的工具熟悉，並瞭解了各自的分工以及該往哪個方向去發展實現功能。主要區別衡量標準即是對專案的瞭解程度以及隊友對專案的分工問題。

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

 在功能方面是一致的，實現了目標的基本功能；在使用者使用友好度方面和預想的有些差別。

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

 小組團隊開發時間增加；保持會議輕鬆愉快的氛圍, 可以考慮換一個開會的環境；務必有人做會議記錄, 最後列出所有改進意見；同時讓所有人都有充分發言的機會，各小組負責人保證要採取行動，優先執行票數最高的一些改進意見，持續優化所有需要改進的點。最後還可以在會議結束後大家一起聚個餐，改善團隊氛圍。

計劃

1. 是否有充足的時間來做計劃?  

做計劃的時間並不是很多，有點缺乏。

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

協商討論，最後選取一人意見。

3. 你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

因某些原因，原計劃進行了修改，修改後的計劃已完成。

4. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

有，比如看了一些與該專案無用的書籍，並花費了時間進行了一些不需要的技術開發。

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

並不是，有些任務只是需要達到一定的目標。

6. 是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

是按照計劃進行的，只是在中途增加了連線資料庫和使用者登入的要求。

7. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?

沒有，只是在空餘時間下就進行開發。

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

 定好計劃，預留緩衝區已被不時之需。

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

 學到了MFC新技術以及團隊開發經驗。如果再來一遍，重選一個專案，然後增加團隊開發時間。

資源

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

MFC相關程式設計資料不足。

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

時間主要是按任務量自己大概估測估計，誤差在1-2天，部分可能誤差會大一點。

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

• 測試沒有系統、詳細的安排，沒有預留太多時間放在測試上面，在最終整合之後，有做了簡單的功能檢驗。
• 人力和軟體/硬體資源十分充足，我們專案並不需要特別充分的人力和軟體硬體資源。
• 團隊主要集中在開發上，對美工關注較少，美工低估了難度。

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

大家都有能力，但興趣可能不一樣，就我們組的專案來說，都一樣。

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

注重資源的獲取，減少不必要的時間浪費。

變更管理

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

我們在團隊程式設計時間較少，所以不能保證所有的變更訊息。

2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

根據實現難度以及剩餘時間來取捨。

3. 專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

即能夠簡單明瞭的繪製向量電路圖。

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

沒有，將計劃制定好了，將任務分配到個人，而出現變更就是看屬於哪個任務由負責人解決。

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

 不能單獨解決，需要團隊一起解決問題。

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

 團隊工作很重要，確認工作的進度和對計劃的調整，有意外的需求也要先跟隊員溝通討論。

設計/實現

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

整個軟體的設計是在專案需求的確立階段，由小組全部成員和老師溝通商定的，之後在小組內協商交流討論。

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

對於頁面設計，覺得基本實現就好，有人覺得這個不行，基本是團隊討論後，選定一個人的計劃。或者有人直接做出來了，就採取這個版本了。

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

• 運用了單元測試各個元件的功能。
• 有UML圖來縱觀整個專案

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

圖形繪製時覆蓋問題，比如會產生變色等問題。有些bug需要在執行測試後才能發覺。

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

  使用了MFC框架，所以程式碼規範方面是執行了。

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

加快認識專案，從而達到最好的配合。並注重開發前的設計。

測試/釋出

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

• 測試各個功能點是否能夠實現。
• 以驗收標準進行測試。

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

是

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

藉助vs除錯工具除錯。

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

自行操作體驗軟體效能。

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

 使用者登陸以及資料庫連線與軟體的連線問題，需要進一步解決。

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

在完成實現專案功能時，要預留測試時間，設定測試點。

團隊的角色，管理，合作

    1. 團隊的每個角色是如何確定的，是不是人盡其才？

　　根據個人意願，然後組內協商確定。

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

　　有，共享學習資源；分享完成程式碼。

    3. 當出現專案管理、合作方面的問題時，團隊成員如何解決問題？

　　開會討論，確定下一步開發方案。

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

 多和團隊交流！

總結:

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

　　第一級 初始級（最低階）
      你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?

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

　　瞭解組員，知道自己該幹什麼。
      你覺得目前最需要改進的一個方面是什麼?

　　分工更加細化。

       對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。 

• 主張簡單：採用MFC框架進行開發，簡化開發流程；
• 擁抱變化：需求時刻在變，人們對於需求的理解也時刻在變。專案進行中，組內根據需求增加相關元器件即相應畫圖功能。同時去除難度較大的功能，比如電路圖中電壓判斷高階功能。