《敏捷開發修鍊之道》學習筆記3：交付使用者想要的軟體

沒有任何計劃在遇敵後還能繼續執行。

我們真正的敵人是變化。

讓使用者和客戶參與開發很重要。

習慣10：讓客戶做決定

開發人員(即專案經理)能做的一個最重要的決定就是：判斷哪些是自己決定不了的，應該讓企業主做決定。你不需要給業務上的關鍵問題做決定，畢竟那不是你的事情。

和客戶討論時，不要從技術的角度，而要從業務的角度介紹每種方案的優缺點，以及潛在的成本和利益。

習慣11：讓設計指導而不是操縱開發

設計文檔應儘可能的詳細。在高層方面，詳細描述對象的關聯關係，在底層方面，詳細描述對象之間的互動。

畫關鍵工作圖(用UML)，因為要使用類及其互動關係來描繪系統是如何組織的。然後才是開始編碼。

不要把時間浪費在編碼前具體細節的設計上。

卡片式設計方法：類名，職責(它應該做什麼)，共同作業者(要完成工作他要與其他什麼對象一起工作)

好的設計應該是正確的，而不是精確地。

習慣12：合理的使用技術

根據需要選擇技術，不要盲目的選擇技術及架構。

這個技術架構真能解決這個問題嗎？

你將會被它拴住嗎？

維護成本是多多少？

任何技術都會有優點和缺點，一定要清楚它的利弊。

不要開發那些你容易下載到的東西

習慣13：保持發行就緒

任何時候只要你沒準備好，那就是敵人進攻你的最佳時機。

在團隊工作，修改東西時必須很謹慎，你要時刻警惕，每次改動都會影響系統的狀態和整個團隊的工作效率。

防範措施：在本地進行測試；檢出最新的代碼；提交代碼

版本控制管理：CVS，Subversion，Git

習慣14：提早整合，頻繁整合

代碼整合時主要的風險來源，要想規避這個風險，只有提早整合，持續而有規律的整合。

習慣15：提早實現自動化部署

習慣16：使用示範獲得頻繁反饋

 不一致的術語是導致需求誤解的一個主要原因。保持清晰可見的開發

習慣17：使用短迭代，增量發布

反覆式開發法是，在小且重複的周期裡，你完成各種開發工作單位：分析、設計、實現、測試和獲得反饋，所以叫做迭代。迭代結束就標記一個裡程碑。

軟體開發不是精細的製造業，而是創新活動。

對付大項目，最理想的辦法就是小步前進，這也是敏捷方法的核心。

詢問客戶，哪些是使產品可用且不可缺少的核心功能。不要為所有可能需要的華麗功能而分心，不要沉迷與你的想象，去做那些華而不實的使用者介面。

使用短迭代和漸進式開發，可以讓開發人員更加專註於自己的工作。

習慣18：固定的價格就意味著背叛承諾

方法：主動提議先構建系統最初的、小的和有用的部分，第一次迭代完了讓使用者選擇。