在職業生涯的大部分時間里，我都是按照瀑布模型的方式進行工作。不久之后，我加入了Xebia，開始以敏捷的方式做活。特別是，我們一直把遵循
Scrum和XP方法論與TDD相結合作為重點強調的實踐。從瀑布模型到敏捷的轉變，就像從宇宙中的一顆行星突然跨到另一顆一樣巨大。一旦完成這種轉變，
你的世界將發生翻天覆地的變化，你的思維、工作或協作方式等等，所有一切都會改變。
我參加的隊伍由8名專業人士組成，出乎我意料的是我們中有6個之前根本沒有任何采用敏捷完成工作的經驗。這樣，我們在其中2名有經驗的同伴指導下開
始工作了。一開始，讓人高興的事情并不多，大部分的事情都讓人感到沮喪。我們認識到，敏捷并不只是沖刺（Sprint）和沒有文檔 -
有不少細微之處你得花功夫學才行。
這里說明一下曾經發生過的事情：
開始的麻煩
-
思維轉變
敏捷講的全是當下的考量、當前的沖刺、當前的用戶故事等。當一路走來突然有其他某個故事出現在面前的時候，我們并不會事先考慮事情將如何發展。過去
在瀑布模型里，我們常常是首先考慮整個系統，HLD（高層設計）和LLD（低層設計）是第一步，在繼續前進之前，它們必須凍結。
相反，敏捷的內容完全是當前狀態和不斷改變，要是我們的需求未來會變化，我們的設計也將隨之演變；但是我們對于超越當前沖刺的事情并不是特別關注。要接受這一事實得花點時間。
-
持續換檔
敏捷是一個不斷變化的環境。“響應變化”是其主導原則之一。為了響應，開發者必須跟市面上的技術保持同步，否則它將讓你異常痛苦。
我們曾在項目中使用了一種搜索引擎庫，但我們中只有一人對其有了解。由于這個缺陷，我們在估時、結對、站立式會議，以及其他日常實踐里都遇到了問題。
我們面對的另一個問題是恰當地進行TDD。從技術觀點看，TDD已經有了不少選擇。你可以依賴不同的模擬和測試框架，這些往往都是你在瀑布模型里不使用的東西。要是你想采用TDD，那么就必須具備對它們的豐富知識，否則整個過程就不會太順利。
緩慢地沖刺
- 測試驅動開發說的是先寫測試，然后由測試導出業務邏輯。這是最難適應的事情之一，因為它完全顛覆了你的觀念。
在瀑布模型里，總是代碼先完成，然后再進行些測試（通常都有，但并非總是有）；但TDD則完全是紅、綠和重構。這種方法要求我們用抽象術語
進行思考，然后由它們演變出具體的事物。由于一開始難以適應，我們往往求助于先寫出邏輯，然后確保存在覆蓋它們的測試。我把這稱為開發驅動測試（DDT）
方法。
DDT并沒有增加太多的意義。假如你知道你的代碼將會很好地工作，那為何還要寫個測試呢？只是要證明這段代碼確實有效？應該不止這一點。的確是這樣。例如，寫測試可以讓你的代碼在耦合性方面表現更好，而且還能夠為將來的代碼變更提供一個巨大的安全網。
- 在敏捷里，以抽象術語進行思考是開發人員必須具備的技能。在敏捷中我們并不像瀑布模型那樣進行預先設計，通過創建抽象和開發工作流，設計到了一定的時候自然就會現身。敏捷中的開發人員必須至少精通基本的設計模式，否則他們將產生一大堆垃圾代碼，從中只能得出拙劣的設計。
TDD在這里對我們大有幫助。它要求我們按抽象術語進行思考。此外，只要我們開始修改測試，我們就必須考慮進行重構，讓我們的代碼變得更
好。DDT也能幫助我們立即識別任何質量問題，這樣它們就能及時地得到修復。這樣，我們最終認識到必須拋棄“首先編代碼，然后寫測試”的套路，后來我們重
新開始采用了TDD方法。
- 代碼質量是團隊的職責，團隊成員將時不時的重構代碼或者可能會重新編寫，直到它符合預先制訂的標準。我們不要把任何情緒跟我們的代碼關聯
起來，應該準備不斷地拋棄或重寫它。遵循Venkat
Subramaniam在集體所有制實踐方面的建議：“每次執行檢入代碼操作時，我們都應該致力于改善代碼的質量。”
- 在瀑布模型里，需求是要簽字的，有點像血誓，然后你再繼續向前移動。但在敏捷里，需求與解決方案同步演變。這幫助我們在前進的過程中讓事
情變得越來越清晰，但這也導致系統需要不時的重新設計，在最初的沖刺（1-4）里，這種情況經常會發生。此外，Backlog也能在沖刺的中間改變，因
此，團隊應該根據這些變化進行調整，因為在每個沖刺結束時交付可工作的軟件是敏捷的座右銘。
- 結對一開始讓人覺得是浪費時間和精力。兩人一起在同一故事上進行工作就像是各浪費了一半的時間和精力。而且，多人完成同一故事的不同任務似乎是導致速度下降的原因。
但是，敏捷中的團隊鐘情于這種合作做事的方式，不喜歡相同項目組或房間里的人單槍匹馬地干活。當團隊一起工作時，他們會竭盡所能地把事情向前推進，結果你有極大的可能性是以一致的方式完成事情，而不是最終在多個戰線失利。
- 在采用TDD時，結對的效果最好。Driver和Navigator一起努力開發更好的系統。但如果你是按照DDT的方式進行結對編程，
那它就不是最佳的前進之路。在這種情況下，兩個合作者都不會知道該如何前進，例如系統設計應該像什么樣子，這樣你將得到很多噪音，產生最終必須重寫的一堆
源代碼文件。
遵循TDD是最佳的方式，但要是你還沒有適應它，你仍然可以結對：利用一塊玻璃（白）板，首先畫出某個設計流程圖，然后其中一個合作者可以編寫代碼，而另一個則可以編寫測試用例。
- 在演示時交付可工作的軟件就像是沖刺的“石蕊測試”。但是，要是軟件不是可發布的，你會不會僅僅因為軟件可以構建、可工作，而認為一個沖刺就成功了呢？
當個別故事全部完工而某些沒有，這樣的沖刺算不算成功呢？那假如沖刺的全部故事基本完成但還有些煩人的小問題呢？
團隊應該關注讓整個故事完工，所有問題得到解決，并且滿足完工標準；而不是慌慌張張地盯著Backlog馬虎了事。一次實施蹩腳的沖刺沒有
任何意義，除了在繼續前進之前必須將已完成的事情返工。時間常常是一個約束條件，因此根據故事的相對重要程度，團隊應該找出一種對他們提議的解決方案更具
質量意義的實施方法。位于Backlog頂端的故事必須盡量以最好的方式開發解決，隨著我們逐漸移動到Backlog的底部，對解決方案的質量可能會有些
妥協，但并不是對完工標準而言。對于故事的實現，更好的方式是寧缺勿濫。
- 站立式會議是鐵律。它們意味著成為一個共享平臺，不只是你個人的有機會告訴其他人你做過什么和接下來要做什么。人們應該試圖去傾聽周遭發生的事情，而不只是檢查自己的檢查表看完成了哪些活動。
莊嚴的站立式會議也必須控制在一定時間之內。我們常常會抑制不住開始就某個問題進行討論的誘惑，但那是必須要避免的。
- 敏捷團隊相當小，在這樣一個環境里，人們經常會因為他們在站立式會議上的言論而被他人評判。那么，你就應該說我們在彼此進行腦力激蕩或者我昨天什么也沒做，再或者是我們重構了代碼，而現在我搞不清楚怎么回事了之類的事情嗎？這些都只會給新人造成一種尷尬的局面。
- 計劃會議肯定是費腦子和讓人精疲力竭的活兒。坐在椅子里4個鐘頭確定故事點數就像是在玩輪盤賭。這些數字將決定包含在沖刺里的內容，但是怎樣在你根本沒有經驗的時候決定數字呢？你一定會估計錯誤。
但這些數字注定就是可能會出錯的大致數字，這并不意味著你純粹是靠運氣來開始玩輪盤賭。這些數字在未來的幾個沖刺之后將給予你某種指示，告訴你能夠完成的工作量。
- 分配故事點數是一個復雜的任務，應該按階段完成。團隊內部應該首先分析故事，并與產品負責人進行討論以清晰地了解需求。在得到清晰的視圖
之后，就要進行廣泛的技術討論，考慮可以實現的最佳可能解決方案。這步要是完成不好，將導致在故事應該如何實現方面模棱兩可，進而導致有缺陷的估計。假
設，如果某個故事接觸到了一個新的未探索領域，那么它應該會相當復雜，即便它是一個簡單的任務。即使在已知領域，技術解決方案的不同也會導致故事相當復
雜。
簡單干脆的故事最容易被估算，即清楚地知道需求是什么，再加上點應該如何實現的細節。產品負責人無法提供這么干脆的故事。它們只能通過跟團隊一起討論得出來。因此，團隊必須花點時間來為下一個沖刺進行調整。
- 回顧就像是在投票時間被賜予的演講。我們應該已經完成這個或那個，在下一個沖刺里我們可以完成這個或那個，但是要是這個沖刺里沒有接受某
些活兒，什么都不會發生。人們可以表達出對于不同方面的滿意與否，但是團隊應該著眼于從回顧的觀點里得到某些具體任務，否則境況將永遠保持下去。
在扎進敏捷之前，你可以做點準備工作：
- 熟悉市面上的技術，尤其是像JUnit、Fitnesse、EasyMock這樣的測試工具。此外，人們應該不斷地為更好的解決方案而奮斗，因此出去找找改進流程的新工具和新方法，尋找解決反復出現的問題的新框架或新設計思想和模式。
- Venkat Subramaniam和Andy Hunt的“高效程序員的45個習慣：敏捷開發修煉之道”是每位涉足敏捷的開發者的必讀書籍。
- 讀讀Robert C Martin在objectmentor.com上的“Craftsman series”和“Clean Code” 。一開始，你可以不用急著去讀它們，但在你碰到一堆麻煩的時候，你就會知道什么時候該去讀了。
- 在站立式會議/計劃/討論，人們評估你建議的時候中保持一顆開放的心。說出你的觀點，或者必要的時候要求幫助，你是這個項目的受益人。
- 測試不僅僅是為了代碼覆蓋率或質量度量。它們還提供了某種類型的持續保持更新的文檔。人們可以先看看測試代碼，然后就知道該如何使用這段代碼了。
- 在項目開始就自動化構建過程的所有事情。如果像Checkstyle這樣的小事都遺漏了，那么它的結果跟其他模型里的一樣，說得多做得少。當你意識到這一點，求助于某種補救手段時，時間往往都太晚了。
學會說A到Z，然后再讓你忘記，重新學Z到A往往不會太容易。這會帶來些痛苦，但完成轉變之后，你就會知道這樣做是值得的。
話就說這么多，同志們，上路吧！！:)
查看英文原文：Confessions of A New Agile Developer