設想和目標
我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
我們軟件是服務於電力系統的信息管理系統
典型用戶：電力系統的工作人員
典型場景：變電站
我們達到目標了么（原計划的功能做到了幾個？ 按照原計划交付時間交付了么？ 原計划達到的用戶數量達到了么?)?
原計划功能：實時數據展示，報警信息展示，工單處理
實現情況：
實時數據展示已在技術上實現了單個數據項的動態曲線展示
報警信息展示功能，已模擬實現實時數據按設計好的規則進行報警，並在客戶端展示了，但未將報警數據實時存到數據庫中。
工單處理：已實現工單展示，新建工單，我的工單三個子模塊的交互樣式，頁面展示，后台未實現。
用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?
暫未投入使用，用戶實際接受成度未知
由於我們做的是整個完整系統的一部分，即應用層開發，難以直接投入使用。
有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
首先，整體實現難度大，客戶需求的技術較新，全組人沒有誰接觸過，其次，部分組員學習能力有限，難以跟上開發的進程，再者是這個項目不是一個完整的項目，涉及底層物聯網技術，但那塊工作不屬於我們項目組，因此，如果重來一遍，會考慮換個項目
計划
是否有充足的時間來做計划?
計划總是趕不上變化，最開始的計划根據進度不斷調整，到最后就拋棄了計划，趕+肝也解決不了問題，因為都是從0開始，而且后台人員進度跟不上，每次都調整進度，每次都補，可每次都補不回來。
團隊在計划階段是如何解決同事們對於計划的不同意見的？
基本上都由我一個人來掌控進度，相對新穎的技術、難點也是我去了解，因此計划階段討論都很順利，沒有太多不同的意見，可能這也是不足的地方。
你原計划的工作是否最后都做完了? 如果有沒做完的，為什么?
總體上都做過，各模塊功能都有，但后台缺失很多。首先是我們低估了注冊功能的后台連接的難度，其次是因為前期大多數時間都用來學習，實際開發的時間沒有多少，前端可以套用模板，相對容易做出成果；然后是我花費了大量時間學習新的知識，了解技術難點，新的插件，例如：websocket通信，echarts插件，元件庫制作（構建電力房間圖，導出SVG），NoSQL數據庫（包括MongoDB、Redis內存數據庫），因此我沒有能夠及時了解或幫助后台的開發。
有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
1、仔細學習了echarts插件的相關實現，其實只要會應用就可以了，而且它的圖相當多，不可能每個都會用，應該按需學習；
2、了解了SpringMVC框架，想用它來構建工程架構，但由於大家都沒學過，都是小白，就選擇手擼代碼了；
3、被小班課老師（某邊老師）批評過數據庫的設計后，詳細修改，也可以說是重新設計了之后，太詳盡了，以至於有些多余。
是否每一項任務都有清楚定義和衡量的交付件?
沒有，大家都在一起做，溝通都很及時，沒有絕對標准，標准隨時溝通調整，大家都覺得ok就直接整合對接。但是，由於后台開發進度慢，往往每次都是等后台設計完成，跟着馬上對接。除了我前端后台一起做的，只需和其他人的模塊進行集成。
是否項目的整個過程都按照計划進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?
沒有完全按照計划進行，計划總是調整中
前端界面有些對不上，調用了一些莫名的插件，然后前端人員又解釋不通，往往對不上的時候，我都會叫他們給一份可行的方案，最終還是能對上，雖然可能不那么規范；但最麻煩的是，后台進度慢，這是橫亘在開發路上的一座大山，我嚴重高估了后台人員的工作效率，但他們也是從零開始接觸。
風險主要是時間太少，我已經盡可能多地集中開發了，用於互幫互助。
在計划中有沒有留下緩沖區，緩沖區有作用么?
有緩沖區：睡眠+休息
有用，deadline前的效率都相當高，有時間就有產出
將來的計划會做什么修改？（例如：緩沖區的定義，加班）
在團隊合作方面，還是繼續和以前一樣，團隊在一起工作是最重要的，還是會盡可能多地開會，但也不能天天開，因為組員會產生排斥心理，然后就是要督促后台加快開發進程，前期學習時間花費多，后期熟練了，應該加快速度。
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
我了解到了很多新的技術，上面說過了，也知道了一個web工程大致的架構，如果可以重來，我希望大家都能對項目多上心，每一個人都能用私下的時間去學習相應的技術。
資源
我們有足夠的資源來完成各項任務么?
沒有，時間嚴重不足，資源也不足，全靠自己學，老師提供了學長供我們請教，但組員們都不主動，涉及到物理意義上的資源，例如：插件，也沒錢買，一切和RMB有關的，都繞開了，當然，服務器繞不開，淚奔。
各項任務所需的時間和其他資源是如何估計的，精度如何?
時間主要是按任務量估計，時間按各自的安排估計
精度不好，不能總是保持高效且時間安排總會有意外的沖突
測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度?
測試沒有系統、詳細的安排，第一次迭代根本就沒有時間測試，做都做不完，哪里來的系統測試，只能靠一邊開發一邊測試，盡可能寫好的代碼。（驗收前都還在對接）
人力資源嚴重不足，后台的勞動力不足之外，有部分相對基礎較弱的同學，沒有技術特別好的同學，都是從零開始學起的萌新。
同時也低估了整個項目的難度
你有沒有感到你做的事情可以讓別人來做（更有效率）?
不知道，但我感覺我分析相對來說較新的技術，或者對我們來說算難點的東西比較有意思，換另一個角度想，如果是我做簡單的后台連接，像servlet，usebean之類的，可能后台完成的會多點，但一些新技術，或者說“難點”就沒有人觸碰了。
有什么經驗教訓? 如果歷史重來一遍, 我們會做什么改進?
我會把每個人的任務都更加細分，更加具體，這也是我現在正在做的事情，讓每一個人都知道具體要做什么，我會少花時間在了解“新技術”上，多幫助基礎較弱的同學，集中開發的時候，更加注重效率，和總結。還有，我的工程結構設計得不好。
變更管理
每個相關的員工都及時知道了變更的消息?
我會在群里，或者當面跟他們說，變更了哪些，有時也會一起討論。
我們采用了什么辦法決定“推遲”和“必須實現”的功能?
一開始就決定了主體功能，主體功能沒有調整過，附加功能都屬於可推遲，但很多任務都是一拖再拖，很難進行管理。
對於可能的變更是否能制定應急計划?
沒有提前制定應急計划，但有變更時會及時做出反應和調整
員工是否能夠有效地處理意料之外的工作請求？
這方面做得很差勁，一旦落下，基本就很難補得回來，很難跟得上進度，但我們不得不往下做，所以工程的完成度是符合“木桶原理”的。
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
效率！提高效率！督促后台！
設計/實現
設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？
整個模式的設計是在項目初期，由pm和老師溝通商定的，但具體的設計完成得並不好，當時沒有想到很細致，受限於知識水平，也不知道難度多大。
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
有，先隊內一致討論，若沒有產生都同意的結果，會去問指導老師的意見；但往往大家都沒什么意見，讓我（PM）常常在事后或者匯報時，才發現問題，我覺得大家應該多質疑。
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效么？
有UML圖來幫助設計，用StarUML設計圖，用騰訊工蜂管理代碼，用TAPD管理文檔。
比較項目開始的 UML 文檔和現在的狀態有什么區別？這些區別如何產生的？是否要更新 UML 文檔？
文檔更加豐富了，會在項目推進中，不斷完善、更新文檔
什么功能產生的Bug最多，為什么？在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?
第一次迭代中，沒有什么太嚴重的bug，因為后台大多沒有完成。
還沒有發布
沒有想到，后台開發太慢，沒有達到預期目標。
代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規范？
現階段沒有執行代碼復審，也沒有嚴格的代碼規范
測試/發布
團隊是否有一個測試計划？為什么沒有？
有制定詳細的驗收標准，但沒有詳細的測試計划
完成都完成不了，哪里來其他的要求。
是否進行了正式的驗收測試？
是，第一次迭代助教驗收，主要看了一下進度。
團隊是否有測試工具來幫助測試？
暫未考慮
團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？
暫未考慮
在發布的過程中發現了哪些意外問題？
暫時不考慮發布
我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?
還是以完成項目功能為首要任務，測試方面暫時沒有精力、時間考慮
團隊的角色，管理，合作
團隊的每個角色是如何確定的，是不是人盡其才？
團隊角色確定，以尊重個人意願為首要因素，再根據實際情況協商確定角色
團隊成員之間有互相幫助么？
當然，每天的工作都是和諧友愛、互幫互助的~
當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
我要感謝團隊中的每一個人，感謝大家的努力和付出，感謝大家的互相幫助和配合，每個人個性、能力都不同，但我希望每個人都能當“雞與豬”故事中的那只豬，接下來的時間，更加注重效率，每個人都找到自己的貢獻點。
總結
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
屬於CMMI一級，完成級
你覺得團隊目前處於 萌芽/磨合/規范/創造 階段的哪一個階段?
磨合
你覺得團隊在這個里程碑相比前一個里程碑有什么改進?
大家彼此更加熟悉，互相的配合會比之前更有效率，當然，學習到了很多知識，開發的效率有所提升。
你覺得目前最需要改進的一個方面是什么?
溝通不足，前端只顧做前端的，后台只顧學習，前后不溝通，或者說溝通得不多。其次是后台效率低，每個人不能很好地找到自己的貢獻點。
5.對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。因此，我們基本上每周都會開會，都會聚集開發，經常去圖書館的研討空間。
