設想和目標

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

我們軟體是服務於電力系統的資訊管理系統

典型使用者：電力系統的工作人員

典型場景：變電站

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

原計劃功能：實時資料展示，報警資訊展示，工單處理

實現情況：

實時資料展示已在技術上實現了單個數據項的動態曲線展示

報警資訊展示功能，已模擬實現實時資料按設計好的規則進行報警，並在客戶端展示了，但未將報警資料實時存到資料庫中。

工單處理：已實現工單展示，新建工單，我的工單三個子模組的互動樣式，頁面展示，後臺未實現。

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

暫未投入使用，使用者實際接受成度未知

由於我們做的是整個完整系統的一部分，即應用層開發，難以直接投入使用。

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

首先，整體實現難度大，客戶需求的技術較新，全組人沒有誰接觸過，其次，部分組員學習能力有限，難以跟上開發的程序，再者是這個專案不是一個完整的專案，涉及底層物聯網技術，但那塊工作不屬於我們專案組，因此，如果重來一遍，會考慮換個專案

計劃

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

計劃總是趕不上變化，最開始的計劃根據進度不斷調整，到最後就拋棄了計劃，趕

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

基本上都由我一個人來掌控進度，相對新穎的技術、難點也是我去了解，因此計劃階段討論都很順利，沒有太多不同的意見，可能這也是不足的地方。

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

總體上都做過，各模組功能都有，但後臺缺失很多。首先是我們低估了註冊功能的後臺連線的難度，其次是因為前期大多數時間都用來學習，實際開發的時間沒有多少，前端可以套用模板，相對容易做出成果；然後是我花費了大量時間學習新的知識，瞭解技術難點，新的外掛，例如：

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

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.對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。因此，我們基本上每週都會開會，都會聚集開發，經常去圖書館的研討空間。