摘要：在敏捷開發中有很多好的想法和實踐，但是還有一些別的并不是那么重要但被很多人接受的想法和實踐：就算你不遵守這些想法和實踐你的項目依然可以圓滿成功。
在敏捷開發中有很多好的想法和實踐，這些想法和實踐都非常管用：把項目分成小版本發布來進行風險管理和加速回饋;用時間盒(time-boxing)來限制WIP(WorkingIn Process)并讓所有人團結一致集中在項目中;僅依靠軟件來作為進程度量;進行簡單的估算并使用速度來預測團隊的表現;和客戶保持頻繁而緊密的合作;持續集成持續發布以保證代碼始終穩定可運行。
但是還有一些別的并不是那么重要但被很多人接受的想法和實踐：就算你不遵守這些想法和實踐你的項目依然可以圓滿成功，也不會有糟糕的事情發生。但是有一些想法實踐你最好不要去遵守。
測試驅動開發
做快速開發的團隊需要依賴于一個快速高效測試安全網。在一個測試先行的或者是測試驅動(TDD)的敏捷開發中，沒有任何借口可以不寫測試用例。在你開始編碼前你必須先寫好測試用例，然后你就可以采用一些高效的自動測試工具來保證有一個高水平的覆蓋測試和回歸測試。
TDD不僅僅是一種供開發人員測試他們代碼的保證手段，它更重要的一種開發技術，這種開發技術能夠得到更高質量的代碼和一個簡單整潔的設計。
微軟和IBM(通過測試驅動開發實現質量改進，微軟研究院，2008)的研究團隊發現，雖然TDD增加了15%-35%前期成本(TDD要求開發人員改變他們的想法和工作方式，這減緩了他們的的開發速度，至少在一開始他們的開發速度慢了很多)，但是跟沒有采取單元測試的團隊相比缺陷密度降低了40%(IBM)或多達60%-90%(微軟)。
但是在軟件制作第12章“測試驅動開發的有效性有多好”中，由BurakTurhan主導的研究表明雖然TDD表面上提高了質量(根據一個或多個通過的測試用例，缺陷的數量，缺陷密度，每次測試發現缺陷數，修復缺陷的工作量，修復密度，預防性維護比例等本衡量)并且可以提高測試的質量(可以使測試錯誤降低，使測試變得更加容易)，但TDD并不能一直提高設計質量。TDD似乎可以降低代碼的復雜度，提高代碼的重用率，但是它也能給耦合內聚帶來負面的影響。雖然使用測試驅動的開發可以使得方法級和類級的復雜度降低，但包級和項目級卻為之變得更加復雜。
喜歡TDD的人為之瘋狂，如果你也熱衷于TDD，那就盡管用它吧。就算你對TDD并不那么感冒，測試先行非常自然的場景也是時不時出現——尤其是當你不得不通過一種特殊的方式來解決一個特殊的問題，或者你要修正一個bug而測試用例已經為你寫好的時候。但是更重要的是，你要寫一組很好的測試用例不斷更新并且時不時運行它們，這跟你在寫代碼前還寫寫好代碼后沒有關系。
結對編程
根據VersionOneState of Agile Development Survey 2012(敏捷開發調查狀況2012)，幾乎有1/3的團隊采用了結對編程的開發方式——這是一個出乎意料的高數字，這顯示出結對編程的良好的組織紀律性，同時表明有很多的團隊使用了可以進行結對編程的XP(2%)和Scrum/XP(11%)方法。
有采用結對編程的非常好的理由：開發人員一起工作可以通過持續的非正式的審查來提高代碼質量和進行信息共享。讓開發人員結對或者讓開發人員和測試人員結對來一起工作的情況非常常見，尤其是當你在解決一個非常困難的設計問題，或者你碰到一段以前從來都沒有接觸過的代碼而以前開發過類似代碼的人就在旁邊可以請教，或者你碰到了一個高壓力的問題需要解決為此你豪無頭緒，或者你在測試系統的一個非常難的部分，或者你的團隊又加入了新的成員而這些成員需要基礎學習的時候。
一些(尤其是性格外向的)人非常喜歡結對編程，喜歡它提供的非常強大的能量和非常難得的認識團隊其他成員的機會。但是去強迫那些更喜歡自己單獨工作的人去和自己不喜歡的人進行緊密的合作，這顯然不是什么明智的作法。結對編程要花費社交成本：和一些有能力的，技術強的，有工作經驗的，有自己獨特方式的，有自己鮮明個性的或者是有自己職業道德的人一起結對編程你需要非常小心。而且長時間的結對編程讓人精疲力竭——一項研究(Vanhanenand Lassenius 2007)發現人們通常一天只結對編程1.5至4個小時，因為成天的結對編程工作強度太大以致于無法接受。
在結對《編程或許是有害的》一文中，JonEvans說結對編程對創造力有負面影響：
研究強烈支持這個觀點：當在享受更多的不被打擾的自由和隱私空間時，人們才有最好的創意......區別表現突出的大公司的開發人員的并不是更豐厚的工作經驗和更高的薪酬，而是他們可以享受的不被打擾的自由的私人空間。”一篇紐約時報的文章大罵結對編程這種所謂“新的集體思維”時這樣說。
另外在PeteMcBreen的“依然質疑極限編程”中指出了一些結對編程的其他缺點和弱點：
不鼓勵鉆研思路，結對編程時開發專注編寫代碼，所以除非有一天的時間來鉆研團隊代碼才能對代碼有一點膚淺的理解。
開發變得過度依賴單元測試，假如測試通過了，那么代碼就OK了。(這就缺乏鉆研了)
沒有進行詳細的極端測試和邊緣測試研究，特別是如果他們很難寫出測試。
當結對編程時很難做到經過詳細思考設計的編碼，除非另外一個搭檔完全控制這個編碼過程。通過平時搭檔間的權衡，很難建立技術復雜的設計，除非他們已經確定了一個獨自會話。
結對編程時的個人風格問題，并不是所有的結對者都能像其他人一樣。
和打字技能、熟練程度不同的人結對編程，往往會導致打字技能好的人完成全部的編碼而其他人變得完全被動。
在分布式團隊中結對編程顯然也不會有效(取決于距離，不同的時區，工作方式，語言)，即使這樣，一些人仍然在嘗試。
雖然結對編程相比獨自編程提高了代碼質量，你也可以通過較低代價的代碼復審來獲得同樣的代碼質量提高，并且還有一些信息共享的優勢。代碼復審——特別輕便，離線復審——比結對編程更容易安排，代價更低點并且沒有打擾。就像詹森科恩指出的那樣即使開發們結對編程，你或許仍然需要代碼復審,因為結對編程確實是共同解決問題，但是它并沒有包含所有代碼復審所涉及的全部問題。
還是喬恩埃文斯關于結對編程的老話：
真正的答案是有沒有答案：獨自編程，結對編程還是小組合作要根據環境用你最好的判斷來動態結合才是最有效的。結對編程的確有它存在的意義。(定律又沒用了!)在某些情況下，甚至是“絕對對的”。但是堅持100%結對編程是盲目的教條主義，和所有的盲目教條主義一樣，最終只會適得其反。
緊急設計和隱喻
增量開發管用，而且嘗試保持設計簡單感覺起來不錯，但試圖飛速定義一個架構是愚蠢且不切實際的。幾乎沒有人遵循緊急設計有一個原因：它不管用。
依賴于高水平的隱喻(系統是一條"流水線"或一個"物料清單"或一箱"蜂箱的蜜蜂")，這些隱喻被團隊共享為某種 代替建筑 是更加荒謬的。 卡內基梅隆大學基金會 的研究顯示，自然語言的隱喻，無論對技術和非技術項目成員之間增進溝通，還是在開發架構方面，相對來說都不是很有用。
總之幾乎無人理解系統隱喻是什么，或者它怎樣使用，或者怎樣選擇一個有意義的隱喻，或者如果你搞錯了又怎樣改變它(還有你怎么會知道你選錯了)，其中有人提出了這樣的想法：
好吧我還是不妨公開說出來—— 我仍然不能找到這種隱喻事情的竅門。我發現它管用，而且在C3項目中工作的很好，但這并不意味著我知道怎么做，更不要說如何解釋怎樣做到了。
Martin Fowler, 設計滅亡了嗎?
敏捷開發方法促進了開發的成功率，并且展現出處理許多不同軟件開發問題的更好方法——但不是架構和設計。
每日站立會議
當你有了一支新的團隊，而每個人都需要相互了解，并且需要更多的時間理解項目是關于什么的;或者當這個團隊迫于超級壓力，正在試圖修復些什么或者結束些什么的緊急的狀況，那么將大家聚集起來開工作例會，甚至也許一天超過一次，這是必要的且有價值的。但是每個人是站還是坐，最終他們在會議上討論些什么，將由你決定。
如果你的團隊已經合作一段時間也合作的很好，而他們每個人都互相了解并且知道他們在做的是什么，如果開發人員做完事情的時候，在任務板或看板上更新卡片，或者在一個電子系統里更新狀態，如果他們足夠成熟可以在需要的時候請求幫助，那么你不需要每個早上在房間里讓他們都站著。
集中式代碼所有權
讓每個人的工作都涉及到所有代碼并不總是有效(因為不是團隊中的每個人對每個問題都有必備的知識或者經驗)，并且集中式代碼所有權對代碼質量有負面影響。
共享代碼看起來似乎更有意義，但事實上卻是不是每個人或者是應該為系統的每一部分工作。
像寫故事一樣編寫需求
每一個需求規格說明都能以用戶故事的方式，以1到2行寫到卡片上的想法，需求應該簡明扼要(以致開發者必須向某人解釋真正的需求是什么)，堅持他們應該應該以相同形式的模板。
“作為某一類用戶，我有目標期望因此某些問題…”
是非常愚蠢和沒有必要的。在15年前，這同樣是一類簡單而又傳統的想法，讓每個人都用UML的用例的形式試圖去捕捉所有需求。
有更多不同的方式來有效的表達需求。有時候需求需要被規定到細節級別(當你必須滿足合規性或者符合一種標準，或是與現有系統集成，或是實現特定的算法。。。)。有時候從一個測試用例或者一個具體的用例場景或一個框架或一切別的類型的模型開始會更有效，因為這樣會讓人知道如何推進，并且有些細節已經就緒。因此，運用格式化和細節層級能更有效也更容易開展工作。
對產品所有者的依賴
依賴作為產品擁有者的人，當項目失敗的時候，就如客戶唯一的聲音和“一個發不出聲音的喉嚨”，無法擴展，無法持續，將團隊和項目以及事實上的業務推向風險的邊緣。很自然的，危險逐漸靠近正在設計的產品和管理中的開發項目，將比解決危險帶來更多的問題。
一些團隊意識到這一點，并試圖與產品所有者的想法保持一致，因為他們必須這樣做。為了成功，一個團隊需要在各個層次的真實而持續的客戶合同，他們需要對自己負責，為確保他們得到他們所需要的，而不是依賴某一個人去完成所有的一切。
