設想和目標
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
2.是否有充足的時間來做計畫?
答：有 也對每個階段的工作做了計畫
3.團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
答：第一階段還沒涉及這個問題。
計畫
1.你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
大體上做完了，有一兩個本來想要實現的功能由於並沒有和下一組銜接好，暫時擱置了
2.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
暫時沒有，我們認為在軟工實踐中的嘗試都是有意義的
3.是否每一項任務都有清楚定義和衡量的交付件?
算是吧，我們的最終衡量就是能用。
4.是否專案的整個過程都按照計畫進行，有什麼風險是當時沒有估計到的，為什麼沒有估計到?
整個專案主體按照計畫進行，中途遇到的一些bug通過大家的努力都得到了解決。為了降低風險，我們首先在保持介面不變的情況下對程式的效能進行了改進。對於新增的功能，我們依然選擇嵌入到原有的介面上。這在很大程度上保證了軟體的穩定性。
5.在計畫中有沒有留下緩衝區，緩衝區有作用麼?
有留下，當然有作用，由於並不是每個成員都能及時地完成任務，尤其是大家都有其他任務在身，留下緩衝區可以為以後的任務調整留出時間
6. 將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
計畫可能會更加緊湊一點，pm也會將任務更加細化。
同時我們會加強對組員的督促，以是的軟體的質量更高。
我們學到了什麼?如果歷史重來一遍,我們會做什麼改進?
比較可惜的是，對於迭代專案，我們沒有機會體驗軟體工程的整個流程。同時由於歷史遺留下來的文件缺乏問題，我們也沒能體驗到軟體迭代開發的好處。主觀感受上我們更像是消防員的角色，拿到缺乏注釋的**，在沒有其他資訊和幫助的情況下將**調通並進行優化和功能的增加。因此，更多地，我們是通過反例而來學習軟體工程的。
資源
1.我們有足夠的資源來完成各項任務麼?
2.各項任務所需的時間和其他資源是如何估計的，精度如何?
初步主要是憑我們自己對某個任務的難易程度進行估計的，估計的時候都考慮了一些機動時間，總體來講這些估計偏差不大。
3.測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
1)事實上，我們缺少對一些好用的測試工具的掌握，這也是在下一階段我們要解決的問題
2)因為這是乙個後台軟體，美工完全不需要考慮，而文案是每個軟體專案都十分需要的。足夠詳細的文案使軟體的開發和維護都能得到極大的方便。在文案方面，我們面臨的困難不大。原因基於以下幾點：1.這是乙個功能集中的專用軟體，不需要根據使用者的不同情況書寫數以萬字或更多的使用文件。2.在開發過程中，因為讀懂**本來就是我們工作的基礎，所以為**留下詳細的注釋也不造成挑戰。
4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?
我們都感到自己在完成自己的任務時還未能盡全力，又總是覺得別人做的很快，從這個角度來講，是的。
變更管理
1.每個相關的員工都及時知道了變更的訊息?
是的，我們充分利用了tfs的專案管理
2.我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
1)根據專案交付時間和任務預估時間的比較
2)根據同前後兩個組交接的必要性來看
3. 專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
將提取到的資訊存入資料庫中是基本的出口條件。
資訊的準確程度是更高要求的出口條件。目前，我們只能通過直觀感受判斷準確程度。
4. 對於可能的變更是否能制定應急計畫?
事實上，對於專用的軟體，我們預期不會有很大的變更。如果發生了變更，我們會根據時間的緊迫程度確定是走一遍完成的需求分析+設計流程還是直接著手完成最基本的要求。
5. 員工是否能夠有效地處理意料之外的工作請求？
我們在實現過程中確實遇到了一些情況需要對計畫進行改變，通過pm的及時溝通，大家都能完成。比如由於伺服器端沒有office相關外掛程式導致office相關轉換不能使用時，及時刪減了發布版本的功能。
設計/實現
1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
由pm主持，後來大家開會進行了確定，是合適的。
2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
有。開始的時候對任務了解不夠，設計了一些不需要的功能，後來在實現過程中，隨著對**的了解加深，我們及時糾正了設計，也重新安排了任務。
3. 團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
受限於資料庫連線的問題，我們只測試了除了資料庫連線以外的一些方法，對於發現bug是乙個好辦法，但是仍然存在構建測試用例比較麻煩的情況。
後面tdduml我不懂``這你都不懂，太渣了
因為這不是乙個很大的專案，也不需要重頭設計，我們認為不需要使用tdd和uml
4. 什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
目前還沒有發布後的情況
5. **複審（code review）是如何進行的，是否嚴格執行了**規範？
首先是採用了結對程式設計的形式,從程式設計開始就減少了**規範和bug等的出現,另外,任務組之間交叉進行了黑盒測試,pm也對主要功能進行了測試.
測試/發布
1.團隊是否有乙個測試計畫？為什麼沒有？
沒有.我們在本階段對測試的重視不夠.
2.是否進行了正式的驗收測試？
進行了.在發布前,程式設計人員坐在一起按程式流程走了一遍,將各種情況都做了測試,保證發布時程式能夠正常執行
3.團隊是否有測試工具來幫助測試？
我們使用vs提供的單元測試工具對一些核心功能相關的函式進行了測試
4.團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
我們的軟體效能的關注較少。從實際的執行結果看，完全可以再可接受的時間內完成資料的處理。
5. 在發布的過程中發現了哪些意外問題？
出現了一些和檔案相關的bug，比如檔案不存在，內容無法讀取，部分迴圈的效率過低等，我們都逐一解決了這些問題
總結:
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
規範.你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
大家能夠以乙個團隊的姿態在一起工作,也開始懂得按照事先約定的規定來寫程式
你覺得目前最需要改進的乙個方面是什麼?
整個團隊都需要以一種更緊湊的方式運作.
附成員討論**：
Alpha階段 M1事後報告
答 我們的軟體要解決的是包括北航在內的全國高校物理實驗的問題。定義比較清晰，對典型使用者和典型場景有比較清晰的描述，在需求規格說明書中有。答 專案經理第一周花了較多的時間進行整體的規劃與設計，在後期細化任務的時候至少提前三天根據不同的執行力和效率將大任務細分為小任務。所以還是有充足的時間用來做計畫。...
團隊事後分析
gamma階段原計畫的密碼找回功能，排名功能，移動端的適配功能等均做到了，按照時間交付了，原計畫的目標使用者200已經達到，目前django後台記錄的數目為243個使用者。整個團隊的軟體工程質量提高了，我們有wiki來儲存所有的完整文件，所有的檔案均有完整的注釋，並且通過code review，測試...
Alpha階段事後分析
團隊計畫的任務都已經完成，計畫內容可以檢視我們的github issue，關閉的issue都是已經完成的任務計畫。根據前幾次部落格的燃盡圖也可以看出，我們團隊在alpha階段最開始進度慢於預期，主要是因為團隊成員對於前端頁面開發都不熟悉，邊學邊開發需要消耗大量時間，但是在alpha階段的後期我們團隊...