敏捷開發已經成爲常態化，隨着計算機與網絡技術的日漸成熟，互聯網以及以互聯網爲平臺的各種網上應用如火如荼，在給傳統產業帶來無限商機的同時，也帶來更多的挑戰。首先，經歷多年的激烈競爭歷程，企業之間的競爭已達白熱化狀態，產品生命週期愈來愈短，產品更新換代速度愈來愈快，爲企業盈利的新產品壽命比工業社會的產品明顯縮短。隨着B2B(企業對企業)、B2C(企業對顧客)等各種模式電子商務的應用，全球物流配送系統的迅速發展，跨地區、跨國界網絡交易行爲的邊際成本趨平，任何一家企業都將面臨國際化、全球化的市場競爭。其次消費個性需求復歸，許多消費者不再滿足於毫無個性的流水線產品，他們更希望能夠影響、最好是親自參與到產品的設計製造過程中來，而網上開辦的個性訂購使這種需求成爲可能。
競爭環境的劇烈變化，使單純依靠企業內部資源孤軍奮戰的競爭形式顯得力不從心，跨企業甚至跨行業的聯盟競爭成爲網絡時代的主流。協作突破企業邊界，促使供應鏈觀念從線性向網絡變革，並逐步形成今天的敏捷供應鏈思想。
對於敏捷，其核心仍然是短週期迭代交付，可視化，自適應調整，開放式及時溝通，所有的敏捷實踐基本都是圍繞這些核心展開，如果再要對敏捷的核心抽象就是迭代+自適應。
原公司實施敏捷後確實帶來了很多的變化。原來可能大家都說很忙，確實是否真的很忙不清楚，原來一個任務來了來安排不下去，原來客戶要的東西遲遲交付不了，或者是交付後就陷入到持續的變更。實施敏捷後這些問題都得到了一定的程度的改善，這麼好的東西怎麼原來沒有引入進來，在CMMI上浪費了這麼多的時間。
敏捷開發離不開架構？架構離不開敏捷開發？難道得出這些問題答案非要經由一場諷刺漫畫般、基於根深蒂固價值觀的針鋒相對，而不能在二者清晰定義之上、基於開放的、推理式的對話？也許，更通俗地描述問題是回答它的良好開始：除了專注于敏捷方法之外，我們還需要廣泛考慮各種開發過程？而且，與提出假設性問題相比，我們應該思考更開放、中立的問題——架構與過程之間的關係是什麼？
架構和過程
架構一詞常通常被定義爲“系統的結構性拆分，包括模塊劃分、塊間關聯、交互機制以及系統設計的指導原則”
儘管從技術角度看它並不正確，但這一定義卻可以支持廣泛的解釋。它上可指與技術、代碼、實際系統架設幾近無關的高層抽象設計，下可代與很多類、代碼級細節密切相關的大而僵化的預先設計。然而，實際情況卻是，這兩種指代既不足以指導實際項目開發流程，又不足以爲“好”架構帶來必要的貢獻。前者太抽象以至很難涉及具體細節；後者尚未得知相關事實就早早下了論斷。因而，敏捷社區的部分人不把架構當作真實項目開發的核心要素也就不足爲奇了。
相形之下，Grady Booch3和 Martin Fowler4共同提出了價值導向的軟件架構定義。他們把架構定義爲昂貴且難於改變的重大決策。Paul Dyson和Andy Longshaw 在架構的結構性定義之上作了指導設計決策方面的論據補充。這些定義有助於我們將架構視爲功能需求、操作特性和開發者適居性等需求所對應的解決方案。
實際上，從一份手擬初稿到各項關鍵細節，描述軟件架構少不了各類決策：有些決策恰當而明確，有些決策需要假設條件，還有些決策做時無心，事後卻發現很重要。
這樣看來，架構是爲開發能達成一系列商業和技術目標6的軟件系統而提供的指導性服務，以最適合於交流和分享的形式呈現；它本身並不是什麼技術造物，要借純粹的形式化描述存在。
過程可以被看作一系列問題的答案：誰在做什麼？什麼時間？爲什麼做？爲誰做？每個軟件開發項目都對應於一個過程，即便它並不明顯：無論鬆散或正式，無論團隊是否主動控制開發，過程都在爲這些問題作答。
然而，你也可以看到，我們在項目成員、預算和規劃方面做出的決定會極大地影響到架構的選擇和可行性。這一結論適用範圍很廣：從無視最初版本的康威定律7指導的系統分劃帶來的強大影響，到技術選擇和技能、預期範圍、發佈模式，甚至實際系統設計方面的問題。
這些影響相互依賴，再加上隨時間變化這一趨勢，需要過程爲架構的相關切面建立清晰的決策鏈和直接且有意義的反饋環，從而將最新的信息融入決策，以便應對不可避免的發明或發現帶來的影響。過程要爲項目團隊提供支持，而不是顛倒過來，項目團隊是爲了交付可運行軟件而不是爲了遵循過程。這正是敏捷過程的目標。
一、什麼是敏捷開發
敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效率和響應能力。
除了原則和實踐，模式也是很重要的，多研究模式及其應用可以使你更深層次的理解敏捷開發。
敏捷開發現已成爲絕大多數IT企業採用的項目管理方法。
IT企業主要採用的項目管理方法學
敏捷開發以用戶的需求進化爲核心，採用迭代、循序漸進的方法進行軟件開發。
敏捷精神（The spirit of agile）：**透明、溝通、協作**
二、什麼是Scrum
Scrum 是一個框架,在這個框架中人們可以解決複雜的自適應問題,同時也能 高效並有創造性地交付儘可能高價值的產品。
Scrum 是:輕量級的、容易理解的 、難以精通的
Scrum 不是開發產品的一種流程或一項技術,而是一個框架,在這個框架裏可以應用各種流程和技術。 Scrum
能使產品管理和開發實踐的相對功效(relative efficacy) 顯現出來, 以便進行改進。
Scrum 框架由 Scrum 團隊及其相關的角色、事件、工件和規則組成。框架中的每個模塊都有其特定的目的, 對Scrum
的成功實施和運用都至關重要。
Scrum 基於經驗型流程控制理論, 或者稱爲經驗主義。經驗主義主張知識源於經驗, 而決策基於已知的事物。Scrum
採用迭代增量式的方法來優化可預測性和管理風險。
透明性、檢視、調整是經驗型流程的三大支柱,支撐起每個經驗型控制流程的實施。
三、Scrum組成人員
Product Owner –產品負責人（PO/PM）
每個Sprint中團隊都要花一些時間來爲下一個迭代做準備工作（即產品列表梳理活動），包括產品列表條目的創建、細化、估算、排序等工作。每個Sprint最多分配10%的時間來協助產品負責人完成這些工作。
Sprint計劃會 – 在Sprint計劃會團隊一起決定Sprint內要完成哪些故事，並進行任務分解和估算。檢視和調整產品與過程 –
即參加Sprint評審會（檢視調整產品）和Sprint回顧會（檢視調整過程）。
四、Scrum流程
架構對敏捷開發而言意味着什麼？
與軟件社區的某些討論相比，敏捷開發並非要求像船貨崇拜那樣熱衷於Scrum或其他過程、工具和方法學，儘管我們的確看到了這一現象並認爲這是個問題。敏捷的要素是響應性、不斷學習和充分。敏捷表現爲軟件及其開發過程的可持續和高質量，非持續的低質量開發有悖于敏捷。敏捷宣言中寫道“對卓越技術和良好設計的持續關注有益於敏捷”，這爲架構指明瞭敏捷開發中扮演的角色——無需大量預先設計。即便從任何敏捷的立場出發，如果一個架構因爲未能很好地分析與實現目標而阻礙你做出變化的話，結果將既得不到好的過程也得不到好的架構。這樣的架構不可能與開發團隊一起持續提高對系統目標及實現的理解，相反會與團隊及源源不斷的需求唱反調。
談到敏捷，務實的架構師有必要關注一個簡單的問題：哪些架構問題會妨害團隊敏捷。問題很簡單，但答案既不簡單也不容易，因爲技術高手和設計專家需要就若干關注點進行協商。模塊化與應用領域模型間的衝突、不必要的耦合、頻繁的組件間交互，都有礙於程序員（對架構）的理解，推高了的構建和交付所需的時間，不利於程序員測試、做小變動和嘗試。任何設計4中不必要的不可逆性、輕率、無結構的技術債都會帶來提高成本，降低宜居性，並傷害敏捷。
迭代式軟件開發
敏捷供應鏈的性質和特徵等都已經有過很多表述,但是這些概念要真正融入到企業的供應鏈系統中,則需要符合這些準則的運行模式來實現。虛擬團隊就是這樣產生的。其性質特徵是:團隊成員均表現了目標導向性；成員在地理分佈上處於分散狀態；成員更多是在不同地理區位進行協同工作；團隊成員通過計算機支持的網絡一同工作完成共同目標；成員各自實施的相關活動在時間上並行進行；成員一起爲團隊目標負責；團隊成員一起解決問題和決策；團隊只在短期內爲某個目標而存在,很少團隊會持續地存在。
虛擬團隊消除了物理上的團隊整合,使製造商可以突破地理限制,快速而持續地與世界範圍的供應商進行協作。虛擬團隊的潛力是巨大的,它可以超越契約關係或者別的短期的即時的交易性途徑,減少供應鏈的波動。至於虛擬團隊能夠給供應鏈提供敏捷性,其表現爲:
1、成員們都一致執行敏捷戰略,團隊建立在確定的變化基礎上。虛擬團隊把任何一個不穩定因素都看成是整個集體的問題。變化、分歧或其它的以外情況不會被認定爲任何一個單個成員的錯誤。
2、團隊成員們一起發現新的解決問題的途徑,而這種新方法在單個個體企業內是不可能被發現的。
3、團隊成員之間充分而持續的信任關係會使各個成員給予彼此的協作更多優先權,即當成員同時有幾項工作在進行時,良好的夥伴關係會使其首先關注與虛擬團隊成員的協作。信任取代了組織等級和上下級之間管制。
4、即使成員們很少有機會見面交流溝通,虛擬團隊的簡單結構和建立團隊的技術手法使得團隊成員能夠建立和維持這種信任關係,並且不用擔心受到各自的出資公司的干預。
5、供應鏈上的不穩定因素來源於各個環節的內部,團隊成員深入或者接近各自所在的企業運營,能夠快速地發現和報告這些問題,並及時對其影響做出評估。團隊中的同步信息系統,如聲頻或視頻會議和一些共享軟件,使團隊可以在很短時間即時會集共同討論解決問題的辦法。時間上的延誤往往造成供應鏈上的紊亂。
構建一個虛擬團隊,必須具備三大要素:流程、技術和人員。流程包括創建清晰目標,建立共同願景和藍圖；建立共享的假設前提；根據虛擬的數字化環境設計流程；定義和溝通流程方法；設計並行工作的協作流程。技術包括拓展數字化工作空間的知識；設計溝通交流的形式和擬定方案；用有效可行的工具進行溝通；創造支持虛擬團隊的環境。人員包括沒有壓力地管理虛擬團隊；；克服人際關係、文化和權威的壁壘；維持團隊的生命週期；建立相互的信任和尊重；；將團隊提升到企業管理者的層面。
網絡經濟改變了傳統產業所面臨的競爭環境，也改變了企業之間的競爭方式，企業必須尋找全新競爭優勢，才能在新經濟時代取得優勢地位。敏捷供應鏈觀念是一種全新的戰略思想，它是在網絡經濟的促動下誕生的，因此必然順應時代潮流，爲傳統產業帶來全新競爭優勢，成爲傳統產業在網絡經濟環境下的必然選擇。
主要輸入輸出工作流程
Scrum 是一個用於開發和維持複雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱爲一個Sprint，每個Sprint的建議長度是2到4周(互聯網產品研發可以使用1周的Sprint)。在Scrum中，使用產品Backlog來管理產品的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常爲用戶故事。Scrum團隊總是先開發對客戶具有較高價值的需求。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它爲Sprint backlog。在每個迭代結束時，Scrum團隊將遞交潛在可交付的產品增量。 Scrum起源於軟件開發項目，但它適用於任何複雜的或是創新性的項目。
Scrum流程
Scrum以經驗性過程控制理論（經驗主義）做爲理論基礎的過程。經驗主義主張知識源於經驗, 以及基於已知的東西做決定。Scrum 採用迭代、增量的方法來優化可預見性並控制風險。
Scrum 的三大支柱支撐起每個經驗性過程控制的實現:透明性、檢驗和適應。Scrum的三大支柱如下：
第一：透明性（Transparency）
透明度是指，在軟件開發過程的各個環節保持高度的可見性，影響交付成果的各個方面對於參與交付的所有人、管理生產結果的人保持透明。管理生產成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內容。也就是說，當某個人在檢驗一個過程，並確信某一個任務已經完成時，這個完成必須等同於他們對完成的定義。
第二：檢驗（Inspection）
開發過程中的各方面必須做到足夠頻繁地檢驗，確保能夠及時發現過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發生變化。當規定的檢驗頻率超出了過程檢驗所能容許的程度，那麼就會出現問題。幸運的是，軟件開發並不會出現這種情況。另一個因素就是檢驗工作成果人員的技能水平和積極性。
第三：適應（Adaptation）
如果檢驗人員檢驗的時候發現過程中的一個或多個方面不滿足驗收標準，並且最終產品是不合格的，那麼便需要對過程或是材料進行調整。調整工作必須儘快實施，以減少進一步的偏差。
Scrum中通過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，做出調整，從而優化次日的工作價值；Sprint評審和計劃會議檢驗發佈目標的進展，做出調整，從而優化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經完成的Sprint，並且確定做出什麼樣的改善可以使接下來的Sprint更加高效、更加令人滿意，並且工作更快樂。
架構設計是一種權衡（trade-off）。一個問題總是有多種的解決方案。而我們要確定唯一的架構設計的解決方案，就意味着我們要在不同的矛盾體之間做出一個權衡。我們在設計的過程總是可以看到很多的矛盾體：開放和整合，一致性和特殊化，穩定性和延展性等等。任何一對矛盾體都源於我們對軟件的不同期望。可是，要滿足我們希望軟件穩定運行的要求，就必然會影響我們對軟件易於擴展的期望。我們希望軟件簡單明瞭，卻增加了我們設計的複雜度。沒有一個軟件能夠滿足所有的要求，因爲這些要求之間帶有天生的互斥性。而我們評價架構設計的好壞的依據，就只能是根據不同要求的輕重緩急，在其間做出權衡的合理性。
目標
a. 重用：爲了避免重複勞動，爲了降低成本，我們希望能夠重用之前的代碼、之前的設計。重用是我們不斷追求的目標之一，但事實上，做到這一點可沒有那麼容易。在現實中，人們已經在架構重用上做了很多的工作，工作的成果稱爲框架（Framework），比如說Windows的窗口機制、J2EE平臺等。但是在企業商業建模方面，有效的框架還非常的少。
b. 透明：有些時候，我們爲了提高效率，把實現的細節隱藏起來，僅把客戶需求的接口呈現給客戶。這樣，具體的實現對客戶來說就是透明的。一個具體的例子是我們使用JSP的tag技術來代替JSP的嵌入代碼，因爲我們的HTML界面人員更熟悉tag的方式。
c. 延展：我們對延展的渴求源於需求的易變。因此我們需要架構具有一定的延展性，以適應未來可能的變化。可是，如上所說，延展性和穩定性，延展性和簡單性都是矛盾的。因此我們需要權衡我們的投入/產出比。以設計出具有適當和延展性的架構。
d. 簡明：一個複雜的架構不論是測試還是維護都是困難的。我們希望架構能夠在滿足目的的情況下儘可能的簡單明瞭。但是簡單明瞭的含義究竟是什麼好像並沒有一個明確的定義。使用模式能夠使設計變得簡單，但這是建立在我熟悉設計模式的基礎上。對於一個並不懂設計模式的人，他會認爲這個架構很複雜。對於這種情況，我只能對他說，去看看設計模式。
e. 高效：不論是什麼系統，我們都希望架構是高效的。這一點對於一些特定的系統來說尤其重要。例如實時系統、高訪問量的網站。這些值的是技術上的高效，有時候我們指的高效是效益上的高效。例如，一個只有幾十到一百訪問量的信息系統，是不是有必要使用EJB技術，這就需要我們綜合的評估效益了。
f. 安全：安全並不是我們文章討論的重點，卻是架構的一個很重要的方面。
規則
顧名思義，就是把功能分解開來。爲什麼呢？我們之所以很難達到重用目標就是因爲我們編寫的程序經常處於一種好像是重複的功能，但又有輕微差別的狀態中。我們很多時候就會經不住誘惑，用拷貝粘貼再做少量修改的方式完成一個功能。這種行爲在XP中是堅決不被允許的。XP提倡"Once and only once"，目的就是爲了杜絕這種拷貝修改的現象。爲了做到這一點，我們通常要把功能分解到細粒度。很多的設計思想都提倡小類，爲的就是這個目的。
所以，我們的程序中的類和方法的數目就會大大增長，而每個類和方法的平均代碼卻會大大的下降。可是，我們怎麼知道這個度應該要如何把握呢，關於這個疑問，並沒有明確的答案，要看個人的功力和具體的要求，但是一般來說，我們可以用一個簡單的動詞短語來命名類或方法的，那就會是比較好的分類方法。
我們使用功能分解的規則，有助於提高重用性，因爲我們每個類和方法的精度都提高了。這是符合大自然的原則的，我們研究自然的主要的一個方向就是將物質分解。我們的思路同樣可以應用在軟件開發上。除了重用性，功能分解還能實現透明的目標，因爲我們使用了功能分解的規則之後，每個類都有自己的單獨功能，這樣，我們對一個類的研究就可以集中在這個類本身，而不用牽涉到過多的類。
根據實際情況決定不同類間的耦合度
雖然我們總是希望類間的耦合度比較低，但是我們必須客觀的評價耦合度。系統之間不可能總是鬆耦合的，那樣肯定什麼也做不了。而我們決定耦合的程度的依據何在呢？簡單的說，就是根據需求的穩定性，來決定耦合的程度。對於穩定性高的需求，不容易發生變化的需求，我們完全可以把各類設計成緊耦合的（我們雖然討論類之間的耦合度，但其實功能塊、模塊、包之間的耦合度也是一樣的），因爲這樣可以提高效率，而且我們還可以使用一些更好的技術來提高效率或簡化代碼，例如Java中的內部類技術。可是，如果需求極有可能變化，我們就需要充分的考慮類之間的耦合問題，我們可以想出各種各樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個抽象層次可以是具體的類，也可以是接口，或是一組的類（例如Beans）。我們可以借用Java中的一句話來概括降低耦合度的思想："針對接口編程，而不是針對實現編程。"
設計不同的耦合度有利於實現透明和延展。對於類的客戶（調用者）來說，他不需要知道過多的細節（實現），他只關心他感興趣的（接口）。這樣，目標類對客戶來說就是一個黑盒子。如果接口是穩定的，那麼，實現再怎麼擴展，對客戶來說也不會有很大的影響。以前那種牽一髮而動全身的問題完全可以緩解甚至避免。
其實，我們仔細的觀察GOF的23種設計模式，沒有一種模式的思路不是從增加抽象層次入手來解決問題的。同樣，我們去觀察Java源碼的時候，我們也可以發現，Java源碼中存在着大量的抽象層次，初看之下，它們什麼都不幹，但是它們對系統的設計起着重大的作用。
這篇文章的寫作思路很多來源於對模式的研究。因此，文章中到處都可以看到模式思想的影子。模式是一種整理、傳播思想的非常優秀的途徑，我們可以通過模式的方式學習他人的經驗。一個好的模式代表了某個問題研究的成果，因此我們把模式應用在架構設計上，能夠大大增強架構的穩定性。
抽象
架構的本質在於其抽象性。它包括兩個方面的抽象：業務抽象和技術抽象。架構是現實世界的一個模型，所以我們首先需要對現實世界有一個很深的瞭解，然後我們還要能夠熟練的應用技術來實現現實世界到模型的映射。因此，我們在對業務或技術理解不夠深入的情況下，就很難設計出好的架構。當然，這時候我們發現一個問題：怎樣才能算是理解足夠深入呢。我認爲這沒有一個絕對的準則。
一次，一位朋友問我：他現在做的系統有很大的變化，原先設計的工作流架構不能滿足現在的要求。他很希望能夠設計出足夠好的工作流架構，以適應不同的變化。但是他發現這樣做無異於重新開發一個lotus notes。我聽了他的疑問之後覺得有兩點問題：
首先，他的開發團隊中並沒有工作流領域的專家。他的客戶雖然瞭解自己的工作流程，但是缺乏足夠的理論知識把工作流提到抽象的地步。顯然，他本身雖然有技術方面的才能，但就工作流業務本身，他也沒有足夠的經驗。所以，設計出象notes那樣的系統的前提條件並不存在。
其次，開發一個工作流系統的目的是什麼。原先的工作流系統運作的不好，其原因是有變化發生。因此纔有改進工作流系統的動機出現。可是，畢竟notes是爲了滿足世界上所有的工作流系統而開發的，他目前的應用肯定達不到這個層次。
因此，雖然做不到最優的業務抽象，但是我們完全可以在特定目的下，特定範圍內做到最優的業務抽象。比如說，我們工作流可能的變化是工組流路徑的變化。我們就完全可以把工作流的路徑做一個抽象，設計一個可以動態改變路徑的工作流架構。
有些時候，我們雖然在技術上和業務上都有所欠缺，沒有辦法設計出好的架構。但是我們完全可以借鑑他人的經驗，看看類似的問題別人是如何解決的。這就是我們前面提到的模式。我們不要把模式看成是一個硬性的解決方法，它只是一種解決問題的思路。Martin Fowler曾說："模式和業務組件的區別就在於模式會引發你的思考。"
在《分析模式》一書中，Martin Fowler提到了分析和設計的區別。分析並不僅僅只是用用例列出所有的需求，分析還應該深入到表面需求的的背後，以得到關於問題本質的Mental Model。然後，他引出了概念模型的概念。概念模型就類似於我們在討論的抽象。Martin Fowler提到了一個有趣的例子，如果要開發一套軟件來模擬桌球遊戲，那麼，用用例來描述各種的需求，可能會導致大量的運動軌跡的出現。如果你沒有了解表面現象之後隱藏的運動定律的本質，你可能永遠無法開發出這樣一個系統。
關於架構和抽象的問題，在後面的文章中有一個測量模式的案例可以很形象的說明這個問題。
架構的一些誤解
我們花了一些篇幅來介紹架構的一些知識。現在回到我們的另一個主題上來。對於一個敏捷開發過程，架構意味着什麼，我們該如何面對架構。這裏我們首先要澄清一些誤解：
a. 誤解1：架構設計需要很強的技術能力。從某種程度來說，這句話並沒有很大的錯誤。畢竟，你的能力越強，設計出優秀架構的機率也會上升。但是能力和架構設計之間並沒有一個很強的聯繫。即使是普通的編程人員，他一樣有能力設計出能實現目標的架構。
b. 誤解2：架構由專門的設計師來設計，設計出的藍圖交由程序員來實現。我們之所以會認爲架構是設計師的工作，是因爲我們喜歡把軟件開發和建築工程做類比。但是，這兩者實際上是有着很大的區別的。關鍵之處在於，建築設計已經有很長的歷史，已經發展出完善的理論，可以通過某些理論（如力學原理）來驗證設計藍圖。可是，對軟件開發而言，驗證架構設計的正確性，只能夠通過寫代碼來驗證。因此，很多看似完美的架構，往往在實現時會出現問題。
c. 誤解3：在一開始就要設計出完善的架構。這種方式是最傳統的前期設計方式。這也是爲XP所摒棄的一種設計方式。主要的原因是，在一開始設計出完美的架構根本就是在自欺欺人。因爲這樣做的基本假設就是需求的不變性。但需求是沒有不變的（關於需求的細節討論，請參看拙作『需求的實踐』）。這樣做的壞處是，我們一開始就限制了整個的軟件的形狀。而到實現時，我們雖然發現原來的設計有失誤之處，但卻不願意面對現實。這使得軟件畸形的生長。原本一些簡單的問題，卻因爲彆扭的架構，變得非常的複雜。這種例子我們經常可以看到，例如爲兼容前個版本而導致的軟件複雜性。而2000年問題，TCP/IP網絡的安全性問題也從一個側面反映了這個問題的嚴重性。
d. 誤解4：架構藍圖交給程序員之後，架構設計師的任務就完成了。和誤解2一樣，我們借鑑了建築工程的經驗。我們看到建築設計師把設計好的藍圖交給施工人員，施工人員就會按照圖紙建造出和圖紙一模一樣的大廈。於是，我們也企圖在軟件開發中使用這種模式。這是非常要命的。軟件開發中缺乏一種通用的語言，能夠充分的消除設計師和程序員的溝通隔閡。有人說，UML不可以嗎？UML的設計理念是好的，可以減輕溝通障礙問題。可是要想完全解決這個問題，UML還做不到。首先，程序員都具有個性化的思維，他會以自己的思維方式去理解設計，因爲從設計到實現並不是一項機械的勞動，還是屬於一項知識性的勞動（這和施工人員的工作是不同的）。此外，對於程序員來說，他還極有可能按照自己的想法對設計圖進行一定的修改，這是非常正常的一項舉動。更糟的是，程序員往往都比較自負，他們會潛意識的排斥那些未經過自己認同的設計。
架構設計的過程模式
通常我們認爲模式都是用在軟件開發、架構設計上的。其實，這只是模式的一個方面。模式的定義告訴我們，模式描述了一個特定環境的解決方法，這個特定環境往往重複出現，制定出一個較好的解決方法有利於我們在未來能有效的解決類似的問題。其實，在管理學上，也存在這種類似的這種思維。稱爲結構性問題的程序化解決方法。所以呢，我們完全可以把模式的思想用在其它的方面，而目前最佳的運用就是過程模式和組織模式。在我們的文章中，我們僅限於討論過程模式。
我們討論的過程僅限於面向對象的軟件開發過程。我們稱之爲OOSP（object-oriented software process ）。因爲我們的過程需要面向對象特性的支持。當然，我們的很多做法一樣可以用在非OO的開發過程中，但是爲了達到最佳的效果，我建議您使用OO技術。
那麼，我們應該如何避開這些誤區呢，或者，換句話說，敏捷軟件開發是如何做架構設計的。這裏有幾種過程模式：
敏捷架構過程模式概覽（High-Level）
在接下去的篇幅中，我們會逐一對各種過程模式進行介紹。然後再站在全局的角度分析各個模式之間的關係，並將之歸納爲架構設計的模式。
敏捷供應鏈的概念及內涵
所謂敏捷供應鏈，是指在不確定性、持續變化的環境下，爲了在特定的某一市場機會中獲得價值最大化而形成的基於一體化的動態聯盟和協同運作的供應鏈，以核心企業爲中心，通過對資金流、物流、信息流的控制，將供應商、製造商、分銷商、零售商及最終消費者用戶整合到一個統一的、無縫化程度較高的功能網絡鏈條，以形成一個極具競爭力的戰略聯盟。
敏捷性是美國學者於1990年代初提出的一種新型戰略思想，當時提出這種戰略思想主要是針對製造技術領域，目標是提高製造系統對外部環境變化的應變能力。
在競爭日趨激烈、市場需求更爲複雜多變的網絡時代，有必要將敏捷化思想運用於整條供應鏈管理，其實質是在優化整合企業內外資源的思想上，更多地強調了供應鏈在響應多樣化客戶需求方面的速度目標。同原來的一體化供應鏈觀念相比，敏捷供應鏈有着顯著不同的內涵。
1、戰略目標：傳統管理思想的靈魂是高成本、低效率，而這一思想的理論假設是認爲消費者偏好更多地傾向於價格和製造質量。一體化供應鏈管理沒有擺脫傳統企業管理思想的束縛，質量和價格依然是其主要戰略目標，敏捷供應鏈觀念則順應時代潮流，將戰略目標定位於對多樣化客戶需求的瞬時響應。
2、資源觀念：一體化供應鏈管理也強調對資源的充分利用和挖掘，但是其資源觀點侷限於企業內部，敏捷供應鏈從擴大的生產概念出發，將企業的生產活動進行前伸和後延，把上游的供應商和下游的客戶納入企業的戰略規劃之中，實現對企業內外資源的最佳配置。
3、供應鏈驅動方式：依賴傳統生產組織方式是很難真正實現以需定產的，因爲缺乏即時按單生產的能力，一體化供應鏈管理只能按照從供應到生產再到銷售的推動生產方式進行，結果造成各個環節大量庫存的堆積。敏捷供應鏈在敏捷製造技術、信息技術(IT)及並行工程技術 (OE)的支持下，成功地實現了客戶需要什麼就生產什麼的訂單驅動生產組織方式，降低了整條供應鏈的庫存量。
4、組織機構構建：新戰略依賴新型組織機構，敏捷供應鏈的成功實施依賴於虛擬組織的構建，即：若干相互關聯的廠商，基於戰略一致性而構成的動態聯盟。與傳統的實體組織相比，虛擬組織具有如下幾個特點：(1)超組織性，它不一定是一個獨立的法人實體，而是爲了特定目標或項目由相關結點企業形成的聯盟；(2)動態性，虛擬組織不是一成不變的，當市場需求或組織目標發生變化時，原先的組織即刻解體；(3)網狀組織，它改變了傳統的等級分明的金字塔結構，允許信息橫向傳遞與交流，使信息利用更爲充分及時。
5、與結點企業的關係：一體化供應鏈觀念沒有超越企業的邊界，依舊把供應商看成討價還價的利益博弈對手，把客戶看成服務對象，敏捷供應鏈突破以往框架，重新定位與上下游節點企業的關係，與供應商結成利益一致的合作伙伴，客戶則被看成是企業能夠創造價值、使產品增值的重要資源。
敏捷供應鏈的特點
敏捷供應鏈區別於一般供應鏈系統的特點在於，敏捷供應鏈可以根據動態聯盟的形成和解體，進行快速的重構和調整。敏捷供應鏈要求能通過供應鏈管理促進企業間的聯合，進而提高企業的敏捷性。在敏捷供應鏈中如何實現對各企業之間的物流、信息流進行計劃、協調和控制，使得能夠取得共贏的結果，並對整個供應鏈進行全面的優化管理，及時響應外界條件的變化，增加企業對外界環境的響應速度，是敏捷供應鏈管理的主要任務
市場敏感
所謂市場敏感是指企業應該掌握並對實際需求進行反應。企業的生產計劃應該以市場需求爲驅動，而不是基於對歷史銷售數據統計分析的基礎上所做的需求預測。企業能夠以最快的速度通過供應鏈響應定製客戶的需要，整個供應鏈保持持續的動態，以能夠充分滿足核心企業響應客戶的需要。
虛擬鏈
通過使用信息技術在供應鏈上下游的各個環節之間共享數據形成一個虛擬供應鏈。許多在供應鏈上游的企業不能掌握供應鏈末端最終用戶實際需求，這些企業只能根據其直接下游客戶的定單安排生產計劃，由於最終用戶的實際需求在從供應鏈下游向上遊傳遞過程中產生的扭曲形成所謂的“牛鞭效應”，即最終用戶實際需求的微小變化會導致上游企業訂貨量的大幅度變動，而敏捷供應鏈可以有效消除“牛鞭效應”的問題。即最終用戶實際需求的微小變化會導致上游企業訂貨量的大幅度變動。
流程集成
流程重組意味着在合作伙伴之間協同運作，在採購商和供應商之間實現協同工作、產品共同開發、通用系統以及信息共享。通過這種流程集成的方式企業可以更關注其核心競爭力開發，把其它活動外包出去。 敏捷供應鏈從擴大的生產概念出發，將企業的生產活動進行前伸和後延，把上游的供應商和下游的客戶納入企業的戰略規劃之中，實現對企業內外資源的最佳配置。
基於網絡
供應鏈應該是像網絡一樣聯繫在一起的合作伙伴的聯合體。個體企業不再是以單獨的形式進行競爭，而是以供應鏈網絡的形式進行競爭，最終能夠勝出的將是那些能夠更好組織、協調和與其合作伙伴的關係，使其所處網絡能夠提供更好、更貼近和更快的服務給其最終用戶企業。
敏捷供應鏈的競爭優勢
任何一種戰略運用是否成功，取決於能否獲得超過對手的競爭優勢。按照美國著名戰略學家波特的觀點，競爭優勢的獲得源於企業能夠向顧客提供超過競爭對手的價值，或者是以低於對手的價格向顧客提供同等的效用，或者是以同等價格提供更多的效用。基於波特的定義，我們可以把競爭優勢描述爲，在公司的任何維度或特徵中所存在的不對稱性或差異性，正是這些維度或特徵使公司能夠比競爭對手更好地服務於顧客並因此創造出更好的顧客價值。波特的理論經過實踐的驗證被證明是有效的，網絡經濟時代，儘管企業所面臨的競爭環境發生變化，市場需求不確定性增加，知識更新速度加快，但是企業所必須遵循的最基本競爭原則卻沒有改變，要獲得成功，就必須取得差異性競爭優勢。
敏捷供應鏈是一種全新理念，它將突破傳統管理思想，從以下幾個方面爲企業帶來全新競爭優勢，使企業能夠在未來經濟生活中再展雄風。
速度優勢
這裏的速度就是最快地滿足消費者的個性化需求，企業能及時提供顧客所需要的產品和服務，企業實行敏捷供應鏈戰略的一個重要競爭優勢就在於速度。在傳統企業運作方式中，從接受訂單到成品交付是一個漫長的過程：首先，企業要將所有的訂單信息集中彙總到計劃部門，由計劃部門分解任務，從採購原材料開始，從前到後按工藝流程完成訂單生產，除了必備的作業時間，中間不可避免地產生諸多等待現象。企業如果按敏捷供應鏈觀念組織生產，其獨特的訂單驅動生產組織方式，在敏捷製造技術支持下，可以最快速度響應客戶需求。敏捷供應鏈增加了對市場反映的靈敏度，通過供應鏈上多個合作企業的信息共享，可以全方位地對市場情況做出響應，因此提高了企業的反映速度。同時，由於各個企業都專心於自己的核心優勢，可以減少產品的生產與物流時間，可以實現供應鏈的即時銷售、即時生產和即時供應，將消費者的定貨提前期降到最低限度。
敏捷供應鏈管理的基本原則
系統性原則：敏捷供應鏈是對參與供應鏈中的相關實體之間的物流、信息流、資金流進行計劃、協調與控制，提高供應鏈中所有相關過程的運作效率和所有環節的確定性，在最大化整體效益的前提下實現各實體或局部效益的最大化或滿意化。因此，必須堅持系統性原則，將供應鏈看成是一個有機聯繫的整體，運用系統工程的理論與方法，管理與優化供應鏈中的物流、信息流、資金流，達到整體效率及效益提高、成本降低、資源配置合理的目標。
信息共享原則：在敏捷供應鏈中，對物流及資金流進行有效的控制依賴於正確、及時的相關信息，預見並降低供應鏈中各環節的不確定性。形成供應鏈信息集成平臺，爲供應鏈企業之間的信息交流提供共享窗口和交流渠道，同時保證供應鏈同步化計劃的實現，實現按照客戶需要訂單驅動生產組織方式，降低整條供應鏈的庫存量。
敏捷性原則：敏捷供應鏈處於競爭、合作、動態的市場環境中，市場存在不可預測性，快速響應市場變化是敏捷供應鏈的要求。因此，必須堅持敏捷性原則，從供應鏈的結構、管理與運作方式、組織機制等方面提高供應鏈的敏捷性。
組織虛擬性原則：由於市場的變化和不可預測性，要求有效運作的企業組織結具有靈活的動態性，根據市場的需要及時對企業組織結構進行調整或重組。
利益協調原則：企業或企業聯盟的各種行爲都是圍繞價值最大化這個最終目標展開的，敏捷供應鏈管理的內在機制在於各成員利益的協同一致，沒有共贏的利益協同機制，就會使參與實體的目標偏離整個供應鏈的目標。因此，必須堅持利益協同性原則，根據相關實體的特徵、信譽等級、核心競爭力等因素，在實體間建立適當的協作關係，明確各自的責任義務與利益，使供應鏈中的相關實體在共贏的利益基礎上，平等合作，取長補短，互惠互利。
建立敏捷供應鏈管理系統的關鍵技術
在供應鏈管理系統中，最核心的研究內容之一是，隨着動態聯盟的組成和解散，如何快速地完成系統的重組。這不可避免地要求各聯盟企業的信息系統也能進行重組，如何採用有效的方法和技術，實現對現有企業信息系統的集成和重組，保證它們和聯盟企業的其他信息系統之間的信息暢通，是供應鏈管理系統要重點解決的問題。供應鏈管理系統的另一項核心研究內容是多種異構資源的優化利用。在跨企業的生產計劃調度和資源控制方面，聯盟內各企業的信息系統往往是異構的。如何有效地利用這些資源，支持它們之間的協同工作，是供應鏈管理系統必須解決的關鍵問題。
敏捷供應鏈管理的研究與實現，是一項複雜的系統工程，它牽涉到一些關鍵技術，包括：統一的動態聯盟企業建模和管理技術、分佈計算技術，以及互聯網環境下動態聯盟企業信息的安全保證等。
1、統一的動態聯盟企業建模和管理技術
爲了使敏捷供應鏈系統支持動態聯盟的優化運行，支持對動態聯盟企業重組過程進行驗證和仿真，必須建立一個能描述企業經營過程和產品結構、資源領域和組織管理相互關係，並能通過對產品結構、資源領域和組織管理的控制和評價，來實現對企業經營管理的集成化企業模型。在這個模型中，將實現對企業信息流、物流和資金流以及組織、技術和資源的統一定義和管理。
爲了保證企業經營過程模型、產品結構模型、資源利用模型和組織管理模型的一致性，可以採用面向對象的建模方法，如統一建模語言(unified modeling language，UML) 來建立企業的集成化模型。
2、分佈計算技術
由於分佈、異構是結成供應鏈的動態聯盟企業信息集成的基本特點，而 Web 技術是當前解決分佈、異構問題的常用代表，因此，我們必須解決如何在 Web 環境下，開展供應鏈的管理和運行。
Web 技術爲分佈在網絡上各種信息資源的表示、發佈、傳輸、定位、訪問提供了一種簡單的解決方案，它是現在互聯網使用最多的網絡服務，並正在被大量地用於構造企業內部信息網。 Web 技術有很多突出的優點，它簡單、維護方便、能夠很容易地把不同類型的信息資源集成起來，構造出內容豐富、生動的用戶界面。但是，隨着應用的不斷深入， Web 技術一些嚴重的缺陷也暴露了出來，主要有 Web 技術所依賴的傳輸協議 HTTP ，從本質上來說，它是一個面向靜態文檔的協議，難以處理複雜的交互操作； Web 效率低，對複雜和大規模的應用越來越不適應； Web 服務器負擔越來越重。
3、互聯網環境下動態聯盟企業信息的安全保證
動態聯盟中結盟的成員企業是不斷變化的，爲了保證聯盟的平穩結合和解體，動態聯盟企業網絡安全技術框架要符合現有的主流標準，遵循這些標準，保證系統的開放性與互操作性。企業面對着巨大的壓力來保護信息的安全，這種保護主要體現在如下五個方面：身份驗證 (authentication) 用來確信用戶身份的真實性。用戶、服務器等任何參與通信的一方，均需要能明確對方的真實身份。訪問控制 (access control) 則對任何資源僅允許被授權的用戶訪問。由安全策略管理員限定合適訪問的資源。訪問控制用於保護企業敏感信息不被非授權訪問，並且針對不同的數據有不同的權限設置，像工資表、項目計劃除相應工作崗位的人員外，可能只是有選擇地對一些員工開放，而市場策略、談判計劃則只有極少數高層人員纔有權訪問。信息保密 (provacy) 是任何安全環境的基礎。根據信息的重要性，不論是存貯還是傳送，信息必須被加密，並保證未授權的第三方不可解密。信息完整性 (integrity) 也很關鍵，因爲通信雙方必須確信信息在傳送中沒有被截獲後篡改，或完全就是假造的信息。
腦圖用例分析第一步
帶寬查詢用例
首先把業務需求分析結果填寫到目標中，然後分析功能（如果沒有系統，可以只看原型圖），找到頁面的相關元素，逐個列入腦圖中，再爲每個元素使用一些測試方法，例如：等價類、邊界值，進行局部決策，這樣子，所有元素的分析完畢，就進入第二部全局。
腦圖用例分析第二步
帶寬查詢用例
第二步繼續完善，進行全局分析以及列舉一些非功能性需求：
全局分析：
找到需求描述或者跟開發溝通代碼有限制條件的地方，而不是針對某個元素；
對不同元素組合有依賴關係的，也需要列出來
非功能性：
這個在文檔中可能沒有給出，需要根據經驗來評估，可以參考團隊積累業務的測試經驗，通用的點：出錯的用戶體驗是否ok、查詢時間效率如何等等
風險：
儘可能琢磨需求，挖掘風險，例如需求說：根據選定頻道，但是沒有說這個頻道不屬於客戶怎麼辦？這個就是思考的強大力量了。
腦圖用例分析第三步
帶寬查詢用例
第三步是最關鍵一步，產出測試故事點，根據風險、目標、要點分析得出，這裏舉了簡單例子，可以使用關鍵路徑組合的方法來做。
當然，做完一二三步，也只是在第一個時間窗口而已（這個時候也可以直接用於測試環境探索下，驗證一些關鍵思路，增強信心），後續還需要重構-測試，在下一個時間窗口，查漏補缺，不斷完善纔可以用於時間測試。
腦圖用例指引
個人認爲，大腦對於圖像的記憶，比文字更長久。富腦圖，注重以圖片、圖標、圖標、關聯關係等記憶爲主。
富腦圖示例
注重以簡潔文字記憶爲主：
輕腦圖示例
團隊可以在不同場景，選擇合適的模板來發揮、擴散測試的思維點。
6 總結
傳統的用例編寫，團隊大概經歷了半年，就轉向敏捷腦圖用例，之後一直堅持了三年，期間也不斷完善用例的展現以及思考的出發點。其實，在整個開發、測試環節中，思考、溝通是最重要的環節，把產生的、達成共識的內容記錄下來，彙集在腦圖中展現，就可以看到整個需求點測試的全景圖，然後再不斷細化成測試故事點，這完全符合思維擴散以及總結的模式，大腦也容易接受，而且可以不斷重構->測試->重構->測試，不斷迭代下去。
其他具體的敏捷原則
以下思維導圖是其他具體的敏捷原則的說明。
作爲敏捷衆多流派中的被廣泛實踐的 Scrum 流派，同時也是我工作之後的兩年多時間裏團隊中使用的敏捷開發方式，下一章我們來初步瞭解一下。
不過正式介紹 Scrum 框架之前，我想有必要先談談一個詞 ——『 敏捷型組織 』。在實踐敏捷的過程中，個人要敏捷，團隊要敏捷，更重要的是組織也要敏捷，而且我認爲組織的敏捷是團隊和個人真正實踐敏捷的重要基石。
敏捷型組織的優缺點
敏捷性組織具有如下優點：
1.組織邊界適當變小，有效地降低情感性衝突（部門或者團隊之間的互相推諉和相互抱怨）；組織人員豐富多樣，提高認知性衝突（經驗、技能和關係的多樣性帶來更優的解決方案）；
2.衝突有好壞之分，好的衝突（認知型衝突）是健康的爭辯，是團隊關於該做什麼或者爲什麼要做（以及該怎麼做）而發生的衝突，它涉及更大的視角和更多的經驗；壞的衝突（情感型衝突）基於角色，經常涉及該誰做，糾纏不清的基於角色的討論往往被認爲是政治性或者領地性的，如果處理不當會對團隊產生不良影響。
3.認知型衝突有助於團隊擴大行動的可能範圍，不同的見解和經驗湊在一起有機會從多角度出發解決難題；
4.情感型衝突會帶來組織的創傷，結果會在戰術和戰略上限制選擇，爭鬥關閉了我們思維的選擇空間，意味着結果可能不是最佳的。
5.通過營造開發、尊重的文化氛圍，推動健康的爭辯，吸納各類人在技能和視野上互補，最大化策略的選擇範圍，把認知性衝突最大化，情感型衝突最小化，讓團隊快速成長。
6.團隊共享一個目標，榮辱與共，不再爭論誰負責什麼或誰應該執行哪些任務，個體對提供高質量、高可用性並能滿足商業目標的服務負有更多的責任，並有能力處理產品或服務的全生命週期；
7.團隊被充分授權，有權力做出決定，高效地完成高質量的任務的動力更足，能進行產品的自主研發；
8.團隊溝通協作更爲充分和順暢，信息共享更爲實時，提高團隊的創造力與表現水平。
敏捷性組織的缺點：
1.敏捷性組織去除了部門傳統的管理角色，比如“工程副總裁”，有組織架構調整的緩衝期；
2.敏捷性組織需要原來團隊按照組織設計中面向用戶的服務重新組織。
3.沒有一個組織結構是完美的，即便敏捷型組織存在着弊端，那些正在掙扎着試圖解決不良的服務支持、大量的衝突、員工自我驅動力不強和整體缺乏創新的公司來說，敏捷型組織模式是個理想的選擇。
4.我個人一個淺薄的觀點：公司內部建設走“戰區主戰，軍種主建”之路，其中的“戰區”正是由相應的業務、產品，研發，測試、運維，設計等主力提供智能投顧和餘額代償服務的相關人員共同組成的敏捷型組織的陣地。
5.敏捷的相關知識介紹到此，接下來主要是介紹 Scrum 框架，首先從 Scrum 的含義、起源和發展開始。
Scrum 框架概述
Scrum 概要框架說明
上圖描述了一個 Scrum 衝刺的概要框架，就像大家所熟知的那樣：
1.『 產品列表 』首先要建立產品列表 —— 一個按優先級排序的、有粗略估算的、成功開發產品所需特性及其他功能的列表。
在產品列表的指導下，我們總是先做優先級最高的條目（比如上圖中的特性 A、B、C）；
換句話說就是，當一個衝刺完成時，已完成的條目都是優先級最高的。
2.『 衝刺計劃會 』一般情況下，產品列表中的工作量遠遠不是一個短期衝刺內能夠完成的。所以衝刺開始時，團隊需要制定計劃，說明在下一個衝刺中要創建產品列表中的哪幾個高優先級的特性。
3.『 衝刺 』工作本身是在一些短週期、時長固定的衝刺中完成的，每個衝刺從一週到一個月。
在每個衝刺中，自組織，跨職能的團隊完成所有必需的工作 —— 例如設計、開發、構建和測試 —— 產生完整的、可工作的、可以放入產品的特性。
4.『 衝刺評審會回顧會 』在衝刺結束時，團隊與利益干係人一起評審已經完成的特性，獲得它們的反饋，產品負責人和團隊既可以對下一步工作內容進行修改（在評審會上），也可以修改以前的工作方式（在回顧會上）。
評審會上，如果利益干係人在看到一個完成的特性時，意識到自己沒有考慮到另一個必須包含在產品中的特性，此時，產品負責人只需要建立一個代表該特性的新條目，並把它以適當的有線順序插入產品列表，留到後面的衝刺中完成。
回顧會上，如果開發團隊在回顧衝刺過程中，意識到自己沒有考慮到依賴風險導致開發過程不必要的等待時，開發團隊可以提出下一衝刺計劃會上考慮依賴風險並做好相應的控制。
5.『 潛在可發佈產品增量 』在衝刺結束時，團隊應當得到一個潛在可發佈產品（或者產品增量）。如果業務上適合，就可以發佈；如果不適合在每次衝刺後發佈，可以把多個衝刺的一組特性合併在一起發佈。
到這裏爲止，我們對 Scrum 框架有了個初步的瞭解，這時候我們可能會有疑問，爲什麼我們要使用這樣的框架來做軟件開發呢？它適用於所有的軟件開發活動嗎？下面一節我們來做個簡單的探討。
Cynefin 框架與 Scrum 適用性
我們先來看一下著名的 Cynefin 框架，它可以幫助我們更好地理解工作環境並確定適合的工作方式。
Cynefin 框架最早是在 1999 年威爾士學者 Dave Snowden 在知識管理和組織戰略中提出的。Cynefin 是威爾士語，意爲 “棲息地” 或 “住所”，指人們對生活環境的共同文化、宗教、地理和部落的總體經驗和感受。這個框架用於描述問題、環境與系統，說明什麼環境適合使用什麼解決方案。
Cynefin 框架定義了五種域：複雜、繁雜、混亂
、簡單和無序，並且比較了各個域的差別，以及描述了 Scrum 適合哪些域。
1. 複雜域
特徵與處理方式：
1.在處理複雜問題時，不可預測性 > 可預測性
2.如果有正確答案，也只有事後才知道
3.問題是涌現的。
4.需要研究探索才能認識問題、進而根據認知進行檢視、調整
5.處理複雜問題需要創造性的創新的方法
6.需要爲試驗活動營造一個容忍失敗的環境，以便獲取重要信息
7.大量的互動和交流必不可少
Scrum 框架適用性： 特別適用
適用的軟件開發活動舉例： 創新的新產品的開發
2. 繁雜域
特徵與處理方式：
1.在處理繁雜問題時，可預測性 > 不可預測性
2.因果可以發現，但不是很明顯
3.可能有很多正確答案，需要專家診斷並找出這些答案
4.繁雜問題是專家控制的良好實踐域
5.通過測量數據獲得控制權
6.Scrum 框架適用性： 適用，但非最佳方案
適用的軟件開發活動舉例： 1. 性能優化（性能優化工作需要調整參數來找出系統的最佳整體性能，這個問題最好能找到專家，讓他們評估情況，調研幾種備選方案，根據實踐做出響應）2. 軟件日常運維
3.混亂域
特徵與處理方式：
1.在處理混亂問題時，需要快速度響應，立即採取行動，然後檢視，看情況是否穩定，然後調整並把環境遷到複雜域中
2.需要作出很多決定，沒有時間思考
3.立即採取行動，重新建立秩序
4.尋找可行（而非正確的）答案
5.新領域，沒有人知道
6.沒有清晰的因果關係
7.Scrum 框架適用性： 適用，但非最佳方案
適用的軟件開發活動舉例： 1. 突發情況（已經沒時間再排列優先級並確定下個迭代做什麼工作，需要立即採取行動，果斷止損）；2. 處理外部依賴缺陷（比如通過立即升級來處理 fastjson 缺陷）
4.簡單域
特徵與處理方式：
1.在處理簡單問題時，因果關係顯而易見
2.問題和解決方案相對穩定，不太可能變更
3.有已知的解決方案，評估後選一種合適的解決方案。
4.評估實際情況，將情況分類，根據已經確定的時間提出響應措施
5.適合使用一組明確的、可重複的、已知能夠解決問題的步驟
6.Scrum 框架適用性： 適用，但非最佳方案
7.適用的軟件開發活動舉例： 1. 生產同樣的產品；2. 部署環境
5. 無序域
如果不知道自己處於哪個域，說明就是在無序域中。因爲無法理解自己的處境，所以這個域很危險；如果處於無序域，要考慮的不是在無序域中如何使用 Scrum，而是要儘早擺脫這個域；擺脫無序域需要把問題分解爲小的組成部分，並安排到另外 4 種域之一中。
特徵與處理方式：
1.不知今後很長一段時間有多少工作，無法爲一週或者更長時間的迭代指定可行的計劃，即便知道有多少工作，也很可能收到高優先級的支持請求並把預定的長遠計劃替換掉（比如客服）
2.Scrum 框架適用性：不適用，適合看板
3.適用的軟件開發活動舉例： 1. 常常被打斷的支持與維護工作（非日常運維）
參考下圖，圖中綠色標記的是三大角色（產品負責人、Scrum Master、開發團隊）、藍色部分標記的是三大工件（產品列表、衝刺列表、潛在可交付產品增量）、橙色標記的是七大活動（衝刺、產品列表梳理、衝刺計劃會、衝刺執行、每日站會、衝刺評審會、衝刺回顧會）。
產品負責人概述
1.是有授權的產品領導力中心，是唯一有權決定要構建哪些特性並以何種順序構建這些特性的人；
2.需要保持一個清晰的構想並把它傳遞給每一個參與者(包括利益干係人、開發團隊等)；
3.產品負責人的身份決定他要對正在開發和維護的解決方案全面負責；
4.還有責任確保總能完成價值最高的工作（可能包括偏技術的工作）；
5.與 Scrum Master 和開發團隊積極合作，及時解答 Scrum Master 和開發團隊提出的問題。
產品負責人勾勒產品願景、爲產品指明方向、計劃開發節奏、考慮開發成本等，他責任重大，一方面要理解組織中利益干係人、客戶、用戶（有時候還包括開發團隊）的需求，是他們的代言人，擔任的是產品經理的角色；另一方面，對正在開發的特性和開發順序，要和開發團隊緊密合作，驗收開發出來的產品，擔任的是業務分析員和測試人員的角色。
以下思維導圖是產品負責人主要職責的說明。
雖然優秀的產品負責人體現出很多特徵或技能，但可以歸爲四類：領域知識，人際交往能力，決策力和責任心。
以下思維導圖是產品負責人主要特徵或技能的說明。
爲了更好地理解產品負責人的職責，這裏也通過一張圖大致列一下產品負責人的日常工作內容。
以下圖片是產品負責人主要日常工作內容的說明。
Scrum Master 既是 Scrum 團隊的教練、是 Scrum 過程權威，也是團隊服務型領導、“保護傘”和“清道夫”，一個真正優秀的 Master 同樣不易養成。
以下思維導圖是 Scrum Master 主要職責的說明。
Scrum Master 必須見多識廣，具備領域知識和技術知識，要善於提問，要有耐心和協作精神，要懂得保護團隊，並且讓溝通公開透明。
以下思維導圖是 Scrum Master 主要特徵或技能的說明。
爲了更好地理解 Scrum Master 的職責，這裏也通過一張圖大致列一下 Scrum Master 的日常工作內容。
以下思維導圖是 Scrum Master 主要日常工作內容的說明。
由多種職位的人組成的多樣化跨職能團隊，負責產品的設計、研發、測試等，包括架構師、開發人員、測試人員、數據庫管理員、運維人員等；
開發團隊成員整體具備的技能足以實現產品負責人要求交付的業務價值。
當然，有些人會問：腦圖用例裏面的故事點怎麼保證人人都看懂，能做到100%覆蓋需求，bug爲0嗎？軟件測試不可能找到100%的bug，這是對測試的誤解，因此不建議實施腦圖用例的幾點：
抱着通過腦圖用例把需求覆蓋100%、bug爲0；
對業務不熟悉，看不到腦圖用例的故事點，因爲它有時候比較隱晦；
團隊及主管沒有耐心；
通過外包做測試，需要詳細用例執行步驟、測試報告；
研發、測試沒有溝通，只有研發完成交付，測試才介入；
腦圖用例，不僅對研發自身素質要求高，測試要求也高，不單單要有相關測試經驗，而且也要有相關開發經驗，可以理解開發過程遇到的問題甚至有時候需要滲入到開發代碼中去排查。最後一張圖，展示了腦圖用例在Scrum框架中所處的位置，實際是貫穿整個從需求到運營階段：
其實我個人理解原來的過程改進和CMMI一點都沒有浪費時間，就像原來我們經常說瀑布都做不好如何去做好RUP軟件過程？基本的CMMI過程都做不好如何去做好敏捷？做任何事情我們都必須經歷的階段是簡單-》複雜->簡單的過程，只有經歷過了複雜你才知道如何來簡化，如何來吸取精華去除糟粕。CMMI裏面確實很多過程都比較重，但是很多的核心過程思想必須要有，只是用更加敏捷的方法來實現這些思想。
公司實施敏捷，開始使用user story card，這是很好的，但是我們要注意到product backlog和sprint backlog絕對不僅僅是user story。很多人任務敏捷拋棄了文檔，而實際上敏捷只是濃縮了文檔，backlog中有user story，有詳細的業務場景描述，有優先級，有規模和工作量估計，有類型，有如何演示，如何實現，如何測試等各種內容。這些內容可以看到一直從需求覆蓋到設計和實現和測試。這可以說是敏捷裏面最重要的一份文檔，而且這份文檔是完全可以結構化的文檔，結構化的條目就是user story，用戶故事是最開始的最小粒度單元，關於用戶故事的需求，設計和測試所有內容都在這裏，體現方式最簡單就是excel，這個東西太好了，你這樣做你發現原來CMMI需求管理中要做的需求追蹤沒必要了，這個excel文檔本身就實現了需求追蹤。單獨的測試用例文檔好像也沒有必要了，需求文檔也不要了，而且需求比原來的描述方式更好，體現了業務場景站在用戶視角，沒必要還要像原來搞個用戶需求文檔+軟件需求文檔，項目管理的複雜文檔也可以不要了，就在這裏估算安排人員，確定時間。所以可以看到濃縮的都是精華。
再回過頭看來，架構到哪裏去了？backlog裏面能否體現架構的核心內容？我個人的答案是不能的，仍然沿用《人月神話》裏面觀點的話，架構需要保證高度的概念完整性，否則談不上架構。backlog裏面的如何實現好像體現了部分架構的內容，讓我們感覺架構也是可以迭代的，漸進式的，這個觀點沒有錯，但是這個只能算做是低層級的概要設計，高層的架構還是沒有。所以我原來一直強調了一個思路，對於變更型和增量版本型的項目特別適合用scrum，而對於全新的項目根據適合RUP的思路，體現用例驅動和架構爲核心，在迭代版本規劃出來後再考慮敏捷的思路。
在崗位細分後，軟件開發裏面分出了獨立的需求分析師和架構設計師崗位，大家可以回想下原來沒有細分前，這兩個崗位其實和合併爲一個的，即原來的系統分析員。這其實是實施敏捷後我們需要做的一個迴歸，重新會產生類似系統分析員角色，系統分析員負責需求和高層架構。低層的一些架構下沉到sprint backlog的每一個迭代裏面來做。高層架構做的內容包括全局用例分析，全局數據視圖，集成視圖和接口交付，其控制的邊界在於這些內容是否跨越了多個迭代版本，這好比一個數據實體設計，如果是在某一個迭代版本內部體內循環則不一定要在高層架構設計，但是如何是涉及到多個迭代版本使用則需要在高層架構識別和設計。對於全新的產品研發，高層架構不穩定，直接導致不斷迭代加入進來的內容結構混亂，這個問題必須要重視和考慮。
很多時候我們都在想，我現在新研發一個產品，原來公司類似的一個產品已經用過這個架構了，或者說公司已經有相應的技術平臺，所以架構工作沒有必要了。注意我們通常說的產品平臺或技術平臺，SSH框架等都是框架，是架構中非功能性架構的內容。而實際根據產品需求或用戶需求過來，考慮的子系統，模塊組件規劃等是功能性架構的內容，不要以爲有了平臺或框架就沒有架構的內容了。
通過前面分析，敏捷下架構能否迭代的問題就比較清楚了。對於不屬於高層架構的內容是可以迭代的，到了每一個迭代版本中再來做架構，對於高層架構的內容一般不能迭代以保證設計的概念完整性。對於高層架構本身，整個設計和方案思路是不能迭代的，但是實現過程本身是可以迭代的，如同一個接口，設計必須體現做，這個做了接口本身的實現可以和其它功能模塊的開發並行。
附件：敏捷知識庫：http://lib.csdn.net/base/agile/structure