在上次的博文敏捷開發之道（八）設計中，我們講解了一下在傳統開發過程中的設計存在的一些缺陷和原因。今天我們講解一下敏捷開發是如何對待設計的。
在實際的開發過程中，經常會存在兩種設計極端，一種是過度設計，一種是設計不足。兩種情況對於專案來講都會造成不好的影響，所以在開發過程中應該盡量去避免這兩種極端，但是這兩種極端的尺度對於專案開發人員來講又不是特別的容易界定，所以這就造成了我們在實際的開發過程不可避免的出現兩種極端。如何解決呢？
過度設計通常是指開發人員在編寫**的過程中，經常會封裝一些類、在一些地方預留一些介面或者方法等等，這對開發的靈活性來非常重要，但凡是都有利弊兩個方面，如果在開發的過程中過度的進行封裝、預留一些無用的介面或方法，那麼對於開發人員來講就不會產生一些額外的工作，同時也會將一些簡單的問題變的複雜。過度設計，通常出現在一些經驗較為豐富，但在開發過程中考慮的情況太多而缺乏針對性的開發人員身上。
設計不足是指設計出來的系統復用性差、擴充套件性不強、不能靈活的應對變化，換一種說法就是不能夠靈活的應對需求的變化，編寫的**在某些特定的地方被一些特定的方法處理或呼叫，相似的功能多次編寫，類似的結構無法復用等等，這樣對於開發人員來講就造成了重複編寫一些無意義的**對於開發人員的積極性來講就造成了致命的打擊。設計不足，多半是因為經驗有限，設計能力有限所致。
敏捷開發之道（六）計畫（續）
當開發人員和客戶確定了使用者素材和本次的迭代計畫之後，首先要做的就是將制定的計畫發布，這樣便於開發人員對整個迭代有乙個清晰的認識，換句話說就是讓開發人員對本次迭代的目標有乙個了解，增強開發人員對本次迭代的信心。計畫的發布通常採用活動掛圖 白板或其他工具，以列表的形式列出任務，開發人員逐個領取他們想要...
敏捷開發之道（八）設計
上次的博文敏捷開發之道 七 測試中，我們講了一下敏捷開發中對測試的相關認識，今天我們繼續講解敏捷開發中的另乙個重要概念 設計。在傳統軟體開發的時候，通常需要做的首先是了解需求，其次會進行乙個簡單的設計，例如畫乙個uml或者ui介面等等。然而，在進行軟體開發的時候，更多的時候，開發者會發現隨著時間的流...
敏捷開發修煉之道
敏捷開發宣言 敏捷的精神 敏捷的修煉之道 敏捷工具箱 做事欲速則不達 對事不對人 排除萬難，奮勇前行 敏捷需要不斷的學習和充電 跟蹤變化 對團隊投資 懂得丟棄 打破砂鍋問到底 把握開發節奏 沒有任何計畫在遇敵後還能繼續執行。讓客戶做決定 讓設計指導而不是操作開發 好設計是一張地圖，它也會進化。設計指...