先專注於案例
1非常明顯，這一條建議應該被包含在任何乙個關於軟體開發建議的列表中；如果乙個程式設計師在嵌入前做了所有適當的預防措施，進行了足夠的測試，是絕不會導致構建失敗的；如果構建失敗了，說明有人想走捷徑；
當編寫某個類的時候，你應該在腦海中有乙個與之對應的使用案例，同時你應該只提供對這個使用案例來說是必需的方法。有時候程式設計師會考慮這個類潛在需要的一些功能，此時你應該把這些考慮作為注釋加在旁邊，但是決不要寫任何**，直到這些潛在功能真正被需要用到的時候；
這一條建議跟前面一條一樣，只是它的物件變成了類的資料成員。有時候可能看起來很明顯某條「使用者」紀錄將會在某處被使用；但是你絕對不應該去新增那個資料成員，直到你有乙個具體的使用案例明確地要用到這個資料；
敏捷軟體開發的精要就是應對不確定性和快速響應變化。在開發工作的前期，你可能沒有獲得完整的資訊，因此你應該盡可能延遲做決定；但是有的時候這個決定不得不做以便開發工作能夠繼續，你沒法再繼續等待下這個決定所需要的所有資訊了；此時，你應該根據手頭所掌握的資訊先做個你認為是最好的決定，然後在獲得更多的資訊之後，也要有勇氣去改變之前的決定；
質量的改進是永無止境的，因此你應該堅持不懈地尋求可以被改進的地方，同時要注意收集識別和定位軟體質量問題的方法。
敏捷開發是用來幫助團隊應對未來之不確定性的方法，但是對已經發生的事情，是不應當存在不確定性的；所以各種型別的嘗試應該持續不斷地開展，同時每次嘗試都應該有紀錄，以此來度量其成效；
開發人員太容易把設計目標轉向技術可能性方面了。實際上最重要的是人，我們永遠不要忘了軟體的最終目的，是幫助某些人更好的完成工作；
很多開發人員和經理們認為產品只是你提交給客戶的功能及相關**，其它一切都是不重要的；事實上測試**應該被作為產品不可分割的一部分予以考慮，它值得在設計階段就開始進行全面地考量，在很多情況下，甚至應該作為最終產品的一起提交給客戶；
測試用例本身能被用來澄清乙個設計的最終意圖；而且在很多情況下，設計的缺陷會在完成測試用例的時候被發現。想想看在編碼之前先書寫測試用例的話，能有多少時間被節省下來。但是要記住：先寫用例
1的測試，然後編寫用例
1的**，這些都要在開始用例
2之前完成；
坦白地說，這已經成了乙個在任何軟體開發原則中都會被提到的陳詞濫調，因為它確實太重要了。發現並且消滅軟體開發過程中的浪費是乙個永無止境的工作。任何不增加終端使用者價值的付出都是浪費，如果你不能確信它對終端使用者有什麼價值的話，很可能你將不需要它。
請理解這樣乙個事實：一旦構建失敗了，專案團隊中的每乙個人都會受到影響，因此沒有什麼事情比確保核心**能被正確構建和測試更重要了。我曾經看到過一些團隊允許構建失效延續幾個月，因為每個人都認為它是別人的責任，每個人都忍受痛苦，卻沒有人採取行動解決問題。在這方面一點小小的努力會使整個團隊都受益，應該成為團隊的共識。
大的，複雜的專案應該被拆分成乙個個小的專案團隊，並且在小團隊內部進一步被分發到乙個個程式設計師手上；但在這個過程中，決不能失去對整個產品最終目的和終端使用者需求的理解；人們應該時刻把目光聚焦在滿足終端使用者需求的目標上面。
組織**，使高度關聯的事物位於相近的位置，如果有可能的話，最好把它們放在乙個類裡面。這是物件導向設計原則的規則之一
- 封裝，理想的情況下，所有在類外部的**，都不需要知道類的內部是如何工作的。有些程式設計師為了某種目的很喜歡在不同的檔案之間傳遞一些細節資訊，譬如為了保持所有相同的資料型別在一起，或者為了按照字母順序排列。諸如此類的操作會給系統帶來不必要的複雜性。所以指導原則是把不相關聯的東西分組，以此來降低系統的複雜度。
【譯者】有的人把這句話理解為
check in
之前執行所有的單元測試，有的人理解為執行
test cases
，實際上個人認為這些都應該在
check in
之前執行。
從微觀層面來說，**確實應該按照最優方法來寫以避免無謂的浪費，然而對於超出方法層面的優化，則應該等到整個系統經歷了壓力測試之後開展，而且這種壓力測試是基於某個具體的使用者使用案例的。
如果只基於對靜態**的理解，就做出對系統整體效能的直覺判斷，幾乎總是錯誤的。相反，對整個系統的效能進行度量，識別出那些確實對系統效能有重要影響的
1%的**，並且專注於優化這一部分**，才是王道。
當乙個開發人員實現乙個使用案例的時候，所有被改動過的，但是沒有改動完成或者沒有經過測試的**，都會產生代價。允許這些完成一半的變更持續存在幾天或者幾個星期，會顯著增加工作量被浪費的風險，因為其中很多半成品最終可能不得不重做。
假設有3
個任務，每個需要
1天來完成，若同時啟動這
3個任務，在
3天內每天都併發處理它們，這樣會導致
9個工作單元的開銷。如果順序處理這
3個任務，每天完成乙個，在前面的任務完成之前，並不開始下乙個任務，這樣只會導致
3個工作單元的開銷；
這跟我們的直覺並不相符，直覺告訴我們當有
3件事情需要處理的時候，可能同時開展
3件事情的是比較合理的；然而軟體開發跟物理的建設並不相同，短週期的，快速的，完整的任務不僅會減輕認知上的負載，而且會減少幾個人之間未完成工作的相互衝突。
完成乙個特定任務所需要的**行數，不同的程式設計師之間會有巨大的差異。**行數並不會告訴你太多關於任務完成情況或者**質量方面的資訊。導致**質量不同的因素可能多達
200個，這使得計算**行數變得毫無意義；如果要計數的話，就用使用案例吧。
在應用這條規則的時候要小心謹慎，因為有些**實在是太脆弱了，這使得改變它們變得很困難，但是總體原則是你要使這些**跟真實的使用案例相匹配，所以不應該害怕去改變它們；乙個資料成員在過去可能是乙個整數，但是當使用案例需要它成為乙個浮點數的時候，請不要猶豫，去改變它。
當涉及大塊不容易理解的**時，有一種傾向：「讓睡著了的狗躺在那吧」；其中乙個例子就是在往乙個類裡面新增新的方法替代老方法時，很多開發人員會保留舊有的方法以防萬一。這種情況下，我們應該額外付出一些努力去檢查老方法是否依然必要，如果沒有證據顯示非要保留它不可的話，就應該將其刪掉；
乙個例子是往配置檔案中新增了太多的終端使用者看不懂的東西。
你應該對於系統將要做什麼，系統架構的目標是什麼有個粗略的理解，但是除非到了開發迭代允許某個具體的設計被實現並且測試的時候，你都不應該進行詳細設計，也不要把關於某個功能實現的具體描述寫下來。
詳細設計僅需要覆蓋剛剛好能夠滿足當前使用案例需要的內容。軟體開發中最大的浪費就是花了很多時間在不需要的詳細設計事宜上，或者是由於錯誤的假設而導致的重新設計。
跟物質的加工不同，軟體是能夠被很容易地進行重大變更的。實際上有足夠的證據證明，軟體本身相對於用來描述該軟體的設計文件，更容易被改變。進一步說，就是軟體本身比說明文件更能夠說明它是被設計來做什麼的。因此，你應該把時間花在直接實現上，這樣客戶就能夠親眼看到最終設計細節。如果你未能滿足客戶要求，不得不改變最初的設計，直接變更軟體本身要比變更說明文件更加容易。更重要的是，當客戶看過系統執行以後，你所得到的關於他們希望系統如何執行的資訊要清晰得多！
程式設計師通常會懶得新增說明，以至於在丟擲的異常中，只有非常簡淺的關於問題的描述。他們以為自己是唯一乙個會看到這個問題的人，而且認為自己會根據這個含糊的描述想起該問題的詳細情形。事實上，由於不正確的，或者是不完整的錯誤描述導致的客戶支援開銷，比任何其它的原因都要高。所以對每乙個錯誤資訊的描述，你都應該假設自己在對剛走進房門的，對編碼沒有任何經驗的陌生人解釋該問題。畢竟，終端使用者以及客戶支援部門，對編碼是沒有任何經驗的。
敏捷軟體開發的12條原則
1.最優先要做的事盡早，持續地交付有價值的軟體，讓客戶滿意 2.欣然面對需求變化，即使是在開發後期。敏捷過程利用變化為客戶維持競爭優勢 3.頻繁地交付可工作的軟體，從數週到數月，交付週期越短越好。4.在團隊內，面對面交談是最有效，也是最高效的溝通方式。5.在整個專案過程中，業務人員和開發人員必須每天...
敏捷軟體開發
敏捷軟體開發 英語 agile software development 又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱 理念 過程 術語都不盡相同，相對於 非敏捷 更強調程式設計師團隊與業務專家之間的緊密協作...
敏捷軟體開發
我們知道，傳統的開發模式已經不能不適用於現在情況，原因有很多 需求經常發生變化，軟硬體更新速度很快等，這些原因都使得傳統不管是 瀑布模型 還是 增量 不管是 快速原型 還是 螺旋 模型，這些軟體開發的模型，不在實用了。所以，在2001年，敏捷宣言提出，標誌著敏捷開發模型初步形成。那麼敏捷開發和傳統開...