項目經過了迭代一階段，總體來說我對team還是比較滿意的，盡管也出現了不少的問題，但在這些問題暴露出來后領導們就認為我這樣管理team是不正確的，我對team的過于信任導致了這次迭代一出現了目標偏差的現象，但我個人不這么認為，在團隊管理上我一直堅信應該建立在對team的信任以及建立team的一致作戰能力、一致榮譽感上，而不是步步對team進行制度性的防范和監控，這個我是不太認同的，盡管這樣的做法通常來說確實能得到一個比較好的結果，但是我認為在那樣的team中工作是不快樂的，會容易造成team的疲憊感，工作除了付出自己的辛苦得到物質收獲外，我覺得最重要的還是讓team得到精神上的快樂，我倡導快樂工作。
不過當然，既然暴露出問題，自然值得總結，在總結后發現現在的team確實是有些松散，還不夠緊密的團結，重要的是沒形成統一的榮譽感，在這樣的情況下我仍然認為并不是通過制度、監控等方法去控制team，而是仍然給team一定的空間，簡單的說說這次出現的問題和自己的解決思路：
1、迭代版本產生了偏離需求和UI的現象
出現這個現象我覺得最主要的原因是在提煉用戶故事時做的不夠好，同時在用戶故事的錄入上的控制
也不夠好，針對這次出現的現象，我覺得在用戶故事上必須表達出一個成功的業務場景的詳細描述(通
過附帶UI來說明)、業務規則的說明以及用戶故事驗證的說明。
判斷一個用戶故事是否完成的標準就是成功的業務場景的執行、業務規則的滿足以及是否能夠通過用
戶故事驗證。
驗證工作由on-site customer做，多數情況下on-site customer就是項目經理、BA或需求分析人員。
通過頻繁發布的持續集成版本將自己實現的用戶故事與用戶故事驗證人員進行頻繁的溝通和交流。
開發人員往往對細節不夠重視也是造成此現象的原因，開發人員往往只注重主體功能的完成，但把細
節卻給忽略了，這個在以后的迭代中需要進行糾正，培養開發人員對于用戶故事完成的概念的認識。
2、開發人員在實現任務時出現了不知如何下手的現象
造成這種現象的發生我覺得最主要的仍然是CRC設計以及任務分解上出現了問題，按照CRC設計的要
求以及任務分解的要求這種現象出現的情況應該是不會發生的，盡管這次team的能力是有些欠缺，但
CRC設計加上任務分解其實會形成非常明確的詳細設計以及如何實現詳細設計的任務，在這點上解
決方案就是在下一次迭代會議上加強CRC設計以及任務分解這兩塊，CRC設計一定要能通過情景測
試，任務分解一定要分解的足夠清晰，讓開發人員都能明白是怎么做的，至于碰到難點的地方自然是
先安排為Spike任務。
3、開發人員在進行任務跟蹤時出現偏離的現象
開發人員仍然沒能形成很好的任務跟蹤的習慣，這點只能不斷的糾正，培養開發人員形成這樣的習
慣。
4、接口依賴造成的瓶頸現象
這是此次迭代出現的一個較大的問題，未形成一個迭代中的接口依賴的全貌圖，導致了在任務分配后
接口依賴常常集中在一個人的身上，出現了瓶頸現象，這點在第二個迭代中需要改進，增加整個迭代
的接口依賴圖，這個可根據CRC設計提取形成。
5、任務自行挑選造成的任務完成有難度的現象
此次迭代中出現了這個現象，部分人員挑選了超過其能力很多的任務，最后導致了任務完成的過程中
出現了很多的問題，這個我仍然覺得一方面是CRC設計的問題，另一方面是缺少PP的原因。
6、持續集成失敗次數過多的現象
此次迭代中造成持續集成失敗的原因竟然多是測試代碼編寫的不正確以及測試代碼對于運行數據的依
賴，這個我在項目總結會議上進行了講解，由于這個項目壓力太大，而且team能力確實有些不足，所
以我未強制執行TDD，不過仍然極度鼓勵；第二個原因則是在造成了持續集成失敗后未列為最高優先
級的事去做。
這次出現這些問題雖然有些是和團隊個人相關，但我更多的認為這就是整個團隊的責任，而不是某個人的，因此在第二個迭代中我仍然是以培養整個團隊的一致榮譽感為首，并且仍然給予團隊足夠的空間以及充分的信任；而且在第一次迭代中出現這些問題也是好事，畢竟這是一支全新的團隊，在團隊能力欠缺的情況下我對于團隊的表現是比較滿意的，在后續我仍然的更多是依靠交流、反饋以及共同作戰來彌補上面的問題，而不是依靠制度和強制性的監督。
比較可喜的是Team開始接受整個軟件過程，TDD也開始得到接受，而且team成員的能力提升也是比較的明顯，這其實對我而言就已經達到目標了，相信這樣的一支團隊是不會讓我失望的。