架構和設計是對需求的回應。某位大神曾經說過，超前架構和設計（big design upfront）的問題是將導致浪費很多功夫——一項行業統計：35%的需求會產生變更，且其中超過一半的變更，實際上都用不上。
在scrum實踐中，我們因需進行架構設計。那些驅動著架構設計的非功能性需求通常也有比較高的價值，絕不能從product backlog中遺漏。我們必須能在每個sprint中構建至少乙個面向業務的功能，所以我們僅構建足夠的架構和設計來支援那功能，又用適當的架構設計來滿足非功能性需求（穩定性，安全性，響應時間等等）。然後，在後面的sprint，隨著對越來越多的業務功能的回應，越來越多的設計將浮現。這樣做的目的，是僅構建對真實需求、高優先順序業務需要呼應的架構設計。這麼做我們能滿足三個需要：證明架構設計是對的；從使用者得到反饋；以及改進我們的估算。隨著專案或發布的進展，架構設計的工作慢慢減少，而實現的業務功能逐漸增加。
好了，前面這些說的，都是一些理論化的東西。在實踐中，我覺得比較難拿捏的是：怎麼樣的架構設計才是恰當的？
例如說，如果「可修改性」是乙個專案的需求，架構師就需要知道架構中的哪些元素時需要支援可修改性。這就必須有一點前瞻的分析和設計了。因此，對於架構和scrum而言，我們改如何做？乙個可以嘗試的辦法，就是考慮，花一到兩個sprint週期來捕獲high priority的功能性和非功能性需求，並設計乙個high level的架構，放到後面再實現。當然，這個是架構師（在scrum開發團隊中，沒有這個角色；架構應該是每個開發人員的共同責任；在這裡，只是稍強調了一下職責。）在一到兩個sprint中逐漸考慮的事情，而非一定有乙個具體的task與之相對應。等到考慮充分、達成基本共識之後，就可以轉化成一些技術task，通過refactoring的方式，或者在實現某些feature的過程中，逐一實現。重要的是，一定要堅持「盡可能小且必要」的價值最大化原則。
記住，"the only thing that is constant is change."，架構也要不斷地審視和積極演變。否則，不用到6個sprint，就要撞牆了，不是嗎？
敏捷專案管理（摘錄） 敏捷流程架構
楚凡科技 www.trufun.net 10年間致力於做中國最專業的軟體工程解決方案提供商 規範軟體開發過程 優化軟體開發流程 保證軟體開發質量 提高軟體開發效率 trufun uml2建模工具 trufun bacon 需求管理工具 trufun 研發雲管理工具等 流程也許不如人那麼重要，但它絕非...
軟體架構 敏捷和架構的關係
實施敏捷方法和設計企業架構之間似乎總是存在某種衝突。從表面上看，敏捷開發強調隨著對業務領域的深入理解，逐步調整設計和計畫。架構設計則要求建立起技術架構 technology stack 它可以滿足質量屬性 quality attributes 也可以向感興趣的利益關係人進行展示，作為一種溝通的途徑。...
敏捷專案管理架構 APMF
研讀許秀影博士的 敏捷專案管理 基礎知識與應用實務 一書，其中提到傳統專案管理與敏捷專案管理的混合管理模式 敏捷專案管理架構 agile project management framework,apmf 估計是普遍大部分公司所需要的，也比較認可的模式，可以很好的實現傳統專案管理向敏捷專案管理轉型。...