學習並嘗試敏捷以來，目前是第三個團隊。
第乙個團隊，在乙個小公司，我負責公司兩個開發團隊之一。那是第一次帶隊開發，沒有什麼專案管理經驗，在強大的開發壓力下，有一段時間把自己搞的焦頭爛額:團隊成員比較清閒，因為他們沒能力解決複雜的問題，我自己天天忙死累活。痛定思痛的開始研究專案管理，嘗試了一些傳統的管理方式，很不給力，然後就接觸到極限程式設計、敏捷開發。
首次的敏捷嘗試，給了我很多驚喜。我們對乙個舊系統進行了較大的公升級改造（累積了數年的乙個麵條式程式，可以想象它的糟糕程度）
在這次開發過程中，我們嘗試了結對程式設計、測試驅動、立會、回顧總結等等一些敏捷的方式方法。
這是一次非常有益的嘗試，我們順利完成公升級，減少了客服部90%（客戶部給的資料）的工作量（解決客戶造成的錯誤），敏捷所推薦的方法都是非常有益的方法，但是在嘗試中也發現了一些問題
1. 測試驅動對開發人員的要求，測試驅動對開發人員的要求較高，完全的測試驅動開發是對常規開發流程的乙個顛覆，當剛從學校畢業不久的各位童鞋（公司資金有限，只好做程式設計師搖籃）對程式語言還沒有做到熟悉熟練的情況下，要求他們做到測試驅動，幾乎不可能。強制要求測試優先，幾乎讓專案進度停頓。
2. 結對程式設計對進度的影響，結對，長期堅持優勢明顯，但是1強多弱的開發團隊（很多專案組的組成結構，當時的團隊就是這樣的結構）也存在很多問題，首先就是強弱結對，有時會造成較弱一方的悲觀情緒或依賴情緒，同時也拖延了較強一方的進度（當專案進度對1強依賴較多時，進度的拖延是比較嚴重的）。兩個較弱的人結對所產生的效益是微弱的，需要很長時間才能看到明顯效果（當時感覺至少3個月到半年）。
3. 立會的效果逐漸減弱，當初期立會的新鮮感過去後，加上專案進度壓力，立會的效果有明顯的減弱，立會成為參與者簡單的應付式陳述自己的工作，互相之間並不關心對方的工作內容。
一些變異的方式：
1. 測試驅動調整為加強測試，互相測試，1強做發布測試。或者由1強的人編寫測試用例，或者使用**審核替代測試等等，以減弱對初級開發人員的要求
3. 輪流組織立會，交換論述對方工作，工作內容輪換
第二個團隊，我到了一家較大的公司。大公司的開發是體制化、編制化的，比如簡單的上傳檔案，在第乙個團隊時需要自己寫乙個（或copy乙個）上傳功能，但在第二個團隊，我們需要找負責上傳檔案的團隊所要介面。比如對大資料表的處理，第乙個團隊需要自己分表分庫處理，第二個團隊我們可以找更為核心的研發部分負責解決大資料量得問題。
第二個團隊是乙個不太開心的經歷（雖然領導、同事人都很好，雖然年終給的也較為豐厚），當第二個團隊的公司建立的時候，敏捷還未誕生，經過了多年，第二個團隊所在的公司已經形成自己的開發文化氛圍（在公司文化影響下），簡易的、快速的、產品導向的開發（不知這樣形容是否準確，這只是我自己的感覺）。
產品出原型，領導拍板，開發盡快把它弄上線，這就是我們的開發流程。在這個流程中，我負責乙個開發小組，但我卻無法推廣敏捷，原因很多：
1. 簡單的產品，第二個團隊的成員個人能力比第乙個團隊好了很多，同時產品難度不增反降，大部分專案或功能只是需要我們設計幾個表，然後以web的形式展現。這種情景下，結對、測試驅動只會浪費時間然後讓領導咆哮（速度是公司推崇的準則之一，所以挑燈夜戰是常事）。立會也變的可有可無。第二個團隊的開發壓力比較大，不是因為產品的難度，而是因為大量的簡單產品，以及這些產品不停的改版，大量的簡單的產品只能讓我們淪為了熟練工種。
2. 簡單的架構，公司有一套通用的設計框架，很簡單的三層架構，鑑於產品的簡單，複雜的架構
3. 鬆散的團隊，雖然我負責乙個開發組，但我對團隊成員不能完全掌控，我上邊的高階技術經理會越級指揮、安排小組成員的工作，團隊成員也經常會被派去支援其他組的開發（當然，有時其他組也需要派人幫助我們組開發）
等等，還有其他一些原因吧，無法一一枚舉，核心的兩點原因：
1. 團隊的開發流程已經固定，要做出改變很難，挑戰固有、惰性的文化很難
2. 敏捷開發需要高層的支援。鬆散的開發團隊，讓我想在自己小組嘗試敏捷的機會都沒有。
目前所在的是我的第三個團隊，組建的時間還不常，已經在內部推廣了一些敏捷的方法，發布了三次測試版程式，以後會慢慢總結在這個團隊中的敏捷嘗試。
總結一下自己敏捷的一些感受：
敏捷的效率：
敏捷開發需要長期的堅持，初期推行敏捷可能不會馬上看到明顯的效果
敏捷的適用性：
記得在敏捷開發剛出現時，其中乙個案例就是團隊放棄或很少使用初級開發人員，而充分利用高階開發人員的效率完成專案。和朋友、同事的討論中也基本可以認定，敏捷更適合於中高階開發人員組成的團隊，敏捷的一些準則是高階開發人員的開發流程的提煉。
對於主要或者包含很多初級開發人員的團隊，推行敏捷最好做一些變化（除非老闆允許你先對團隊進行敏捷培訓3-6個月，而不追問進度的話）
敏捷的階段性推廣
1. 立會、回顧、產品設計討論 簡單的實現原則等這是比較簡單、見效快而明顯的敏捷方法
2. 結對程式設計，長期的結對程式設計對提高團隊整體實力的效果是非常顯著的。如果敏捷開發環境不理想，做不到完全結對程式設計，松結對程式設計較好的選擇。對於結對程式設計，也可以採用必要時就結對而不是完全結對。
3. 使用者故事、迭代開發，讓我們更加了解產品，也可以使我們更快的應對產品需求的變化，在我的實踐結果表明專案進度更快了。如果無法做到讓使用者、產品人員參與到開發中，那麼及時反饋專案進度對專案的開發是很有益的。
4. 測試驅動，重構，更好的設計模式，這些方式對於團隊成員的要求較高，如果團隊成員能力沒有達到這樣的開發水品，強制推行不是乙個好主意，利用強弱組合結對、加強培訓、加強**審核+重構力度，逐漸形成乙個開發氛圍，慢慢影響團隊成員。
沒有經過正規敏捷訓練，自己摸索著實踐敏捷，一路跌跌撞撞的也有幾年了，有很多不當之處，歡迎指正交流。
敏捷開發 回顧
那該怎麼做sprint回顧呢？第一點是找出在上乙個sprint中做得好的地方，並繼續保持。分析那些導致成功的流程是非常重要 的，這樣我們才能有意識地保持下去。只有團隊中的每乙個 成員都清楚什麼才是最佳實踐，才能有效地鼓勵和保持這些實踐。除了可以鼓舞士氣外，還可以避免把回顧會議變成消極的抱怨會議。第二...
回顧ali歷程
專案 乙個人做 yahoo郵箱遷移 偏業務，網路協議要求非常了解 登入拆分 https 純技術 85 doing 純業務 參與 維納斯 純業務 2013 偏技術 一見鐘情 偏業務 10版tp 純業務 多帳號 偏技術，我做的內容是純技術 member company napoli遷移 偏技術 會員服務...
回顧ali歷程
專案 乙個人做 yahoo郵箱遷移 偏業務，網路協議要求非常了解 登入拆分 https 純技術 85 doing 純業務 參與 維納斯 純業務 2013 偏技術 一見鐘情 偏業務 10版tp 純業務 多帳號 偏技術，我做的內容是純技術 member company napoli遷移 偏技術 會員服務...