第一個Sprint 完成，歷時三週。上午進行了迭代成果的展示溝通，下午進行了內部總結會議。
這是公司第一次嘗試敏捷實踐，在沒有系統地接觸過敏捷，也缺乏相關培訓的情況下。當然，在推行前，我們內部進行了一些自學，並且指派的QA 接觸過敏捷團隊。我們挑選了一個公司的內部項目，進度壓力相對沒有那麼大可以避免大家直奔結果而放棄過程，團隊氛圍較好較其它項目組更容易接受新事務，團隊負責人嘗試意願高、態度夠積極，再加上團隊的分管領導主動提倡本次嘗試。所以，第一個Sprint 的推行相對還算順利。
在這個迭代中，嘗試的實踐如下：
1） 集中的辦公區
在本次總結中，得到最多贊同的一條。集中的辦公，使團隊的溝通成本大大降低，效率也得到了適當的提高，並有力地促進了團隊文化的形成。
2） SPRINT 規劃與估算
此項仍然得到了所有項目成員的擁護，主要作用在於項目成員對於項目的範圍、目標、進度安排均較以前有了清晰的認識，雖然存在偏差但估算過程令項目經理對項目的掌握能力增強。
但在執行的過程中仍然反思了一些問題。第一次的估算集體過於樂觀，原估算兩週完成的任務，實際上用了三週時間，並且還有一些完善性工作未完成。在SPRINT 中的BACKLOG 定義時，對那些技術預研、需求前期摸底類的工作未定義在BACKLOG 中，但實際上這些工作佔用了較多的時間，且屬關鍵路徑任務。
改進計劃：
l 識別技術預研、需求範圍確認等工作，並列爲BACKLOG 的任務包。
l 大的任務包需要更細的劃分，例如新增用戶，使程序間的耦合度降低。儘量使每天的工作輸出可編譯、可執行、可測試
l 適當預留缺陷修復的時間
3） 每日立會
這條也得到了大多數團隊成員的認可，表現爲對當天的工作目標清晰、明瞭。但也有一些大家未意識到、通過本次總結會總結出來的不足：
立會前，大家都沒有事先思考哪些信息需要在會議上得到確認或支持，立會氣氛較爲沉悶，目前會議的效果主要是認領了任務。改進建議：
l 主動地將工作中的問題（技術或配合或業務等）在會議上提出，鼓勵認領一些非本崗位的工作，提高自身技能。可能需要SCRUM MARSTER 做適當的引導。
l 在每天下班前，通過團隊的短暫例會，將第二天的計劃工作內容進行預覽，使大家在第二天的立會前有時間進行有目的的思考。
l 提高會議的效率，在會議上不糾結過於細節的問題，對於細節問題可會後擇時討論。
l 早立會中提出的任務應是當天可以完成，如果當天不能完成就需要對該任務進行分解，使大家知道功能點在計劃完成時間之內每天的進展
4） 進度牆
雖然本次迭代使用了進度牆，但是項目成員中仍無一人能夠很好地表述項目的進展情況，不知道哪些任務已經到了哪些階段，與之相關的下道工序不知道何時開展。
改進計劃：完善進度牆，進行階段劃分，將每項任務的進展通過階段進行明示。
5） 代碼走查
本 階段安排了代碼走查的工作。初期採取的方式是每隔幾天，安排一段時間（例如半天）對代碼進行集體走查。走查的結果是發現的多爲規範性問題，問題的嚴重或重 要程度都較少。後來將走查的範圍改爲代碼、產品功能展示。團隊成員對代碼走查的認同度不太統一。部分認爲走查非常好，有必要，發現了規範性的問題，學到了 編碼規範以及別人的編碼技巧等，這些以新手居多；另一些人則認爲走查未發現重要的問題，但時間較多，是否有意義？
改進計劃：階段性的代碼走查仍然會保留，但會收斂走查的範圍。並通過結對編程的方式對代碼的質量進行控制。
6） JUNIT
大概是目前公司做得最規範的項目了。項目組普遍認爲使用JUNIT 進行單元測試耗時又沒有效果。糾其原因是產品的邏輯層幾乎分佈在前臺，而後臺JAVA 部分邏輯十分簡單，應用JUNIT 如同殺雞用牛刀，而造數據又需要一定的工作量。
但出於日後迴歸測試、重構等需要，最後決定將繼續嘗試一段時間，可能對JUNIT 的應用範圍稍做收斂。
7） QTP
也是項目組普遍認爲雞肋的實踐。在本次迭代中，QTP 錄製是在DEMO 完成之後就開始進行。由於是一個新的模塊開發，所以測試人員即承擔了手工測試的任務，同時還要完成QTP 的代碼編寫，造成了測試人員的工作緊張。而此階段，自動化測試並未得到開展，等同於QTP 的產物並未得到實際應用。
測試組提出的建議是：將QTP 的編寫時間放在程序編寫完成之後，而不是DEMO 完成之後，這樣可以減少測試代碼的修改時間。另一個建議是在下一個迭代的需求階段測試小組的相對空閒期，對上一迭代的內容編寫自動化測試腳本。
QTP 是應用敏捷初期項目組最有期待的實踐，他們迫切地希望解決迴歸測試中的測試工作量的問題。而本次迭代中由於是新模塊，並不存在迴歸的問題，QTP 的作用未得到顯示。
QTP 工作將繼續進行，並參考測試組的意見進行完善。
8） 每日構建
本次迭代，初步建立了每日構建的環境，進行了短期的嘗試。目前每天都有一份當日構建報告，但並沒有成員對報告內容進行關注。這也是下階段需要重點改進的地方。
總 的來說，已經在實踐的幾個敏捷方法中，管理性的工作相對容易執行，而技術性的工作執行中存在較多的困難、疑惑。在迭代初期，大家對這些方法與實踐還抱有較 高的熱情與好奇，在迭代的中後期，又有些陷入日常事務中，逐漸模糊了敏捷的每天都要思考如何進行改進的目標，在今天的總結會議中，大家又似乎有種恍然大悟 的感覺。正如項目經理所總結的：我覺得我學習了，但還未學習到。
形似而神不似。可不是？但這個團隊還是勇氣可嘉的，加油！