之前已经说过很多关于敏捷开拓的东西，过多的鸡汤就不再鳌述。实在，敏捷开拓已经成为常态化，随着打算机与网络技能的日渐成熟，互联网以及以互联网为平台的各种网上运用风起云涌，在给传统家当带来无限商机的同时，也带来更多的寻衅。首先，经历多年的激烈竞争进程，企业之间的竞争已达白热化状态，产品生命周期愈来愈短，产品更新换代速率愈来愈快，为企业盈利的新产品寿命比工业社会的产品明显缩短。随着BTOB(企业对企业)、BTOC(企业对顾客)等各种模式电子商务的运用，环球物流配送系统的迅速发展，跨地区、跨国界网络交易行为的边际本钱趋平，任何一家企业都将面临国际化、环球化的市场竞争。其次消费个性需求复归，许多消费者不再知足于毫无个性的流水线产品，他们更希望能够影响、最好是亲自参与到产品的设计制造过程中来，而网上开办的个性订购使这种需求成为可能。
竞争环境的剧烈变革，使纯挚依赖企业内部资源孤军奋战的竞争形式显得力不从心，跨企业乃至跨行业的同盟竞争成为网络时期的主流。协作打破企业边界，匆匆使供应链不雅观念从线性向网络变革，并逐步形成本日的敏捷供应链思想。
对付敏捷前面谈的很多，其核心仍旧是短周期迭代交付，可视化，自适应调度，开放式及时沟通，所有的敏捷实践基本都是环绕这些核心展开，如果再要对敏捷的核心抽象便是迭代+自适应。
周末和我一个老同事谈天，以为在原公司履行敏捷后确实带来了很多的变革。原来可能大家都说很忙，确实是否真的很忙不清楚，原来一个任务来了来安排不下去，原来客户要的东西迟迟交付不了，或者是交付后就陷入到持续的变更。履行敏捷后这些问题都得到了一定的程度的改进，这么好的东西怎么原来没有引入进来，在cmmi上摧残浪费蹂躏了这么多的韶光。
敏捷开拓离不开架构？架构离不开敏捷开拓？难道得出这些问题答案非要经由一场讽刺漫画般、基于根深蒂固代价不雅观的针锋相对，而不能在二者清晰定义之上、基于开放的、推理式的对话？大概，更普通地描述问题是回答它的良好开始：除了专注于敏捷方法之外，我们还须要广泛考虑各种开拓过程？而且，与提出假设性问题比较，我们该当思考更开放、中立的问题——架构与过程之间的关系是什么？
架构和过程架构一词常常日被定义为“系统的构造性拆分，包括模块划分、块间关联、交互机制以及系统设计的辅导原则”
只管从技能角度看它并禁绝确，但这一定义却可以支持广泛的阐明。它上可指与技能、代码、实际系统架设几近无关的高层抽象设计，下可代与很多类、代码级细节密切干系的大而僵化的预先设计。然而，实际情形却是，这两种指代既不敷以辅导实际项目开拓流程，又不敷以为“好”架构带来必要的贡献。前者太抽象以至很难涉及详细细节；后者尚未得知干系事实就早早下了论断。因而，敏捷社区的部分人不把架构当作真实项目开拓的核心要素也就不足为奇了。
相形之下，Grady Booch3和 Martin Fowler4共同提出了代价导向的软件架构定义。他们把架构定义为昂贵且难于改变的重大决策。Paul Dyson和Andy Longshaw 在架构的构造性定义之上作了辅导设计决策方面的论据补充。这些定义有助于我们将架构视为功能需求、操作特性和开拓者适居性等需求所对应的办理方案。
实际上，从一份手拟初稿到各项关键细节，描述软件架构少不了各种决策：有些决策恰当而明确，有些决策须要假设条件，还有些决策做时无心，事后却创造很主要。
这样看来，架构是为开拓能达成一系列商业和技能目标6的软件系统而供应的辅导性做事，以最适宜于互换和分享的形式呈现；它本身并不是什么技能造物，要借纯粹的形式化描述存在。
过程可以被看作一系列问题的答案：谁在做什么？什么韶光？为什么做？为谁做？每个软件开拓项目都对应于一个过程，即便它并不明显：无论疏松或正式，无论团队是否主动掌握开拓，过程都在为这些问题作答。
然而，你也可以看到，我们在项目成员、预算和方案方面做出的决定会极大地影响到架构的选择和可行性。这一结论适用范围很广：从忽略最初版本的康威定律7辅导的系统分划带来的强大影响，到技能选择和技能、预期范围、发布模式，乃至实际系统设计方面的问题。
这些影响相互依赖，再加上随韶光变革这一趋势，须要过程为架构的干系切面建立清晰的决策链和直接且故意义的反馈环，从而将最新的信息融入决策，以便应对不可避免的发明或创造带来的影响。过程要为项目团队供应支持，而不是颠倒过来，项目团队是为了交付可运行软件而不是为了遵照过程。这正是敏捷过程的目标。
一、什么是敏捷开拓敏捷开拓是针对传统的瀑布开拓模式的弊端而产生的一种新的开拓模式，目标是提高开拓效率和相应能力。
除了原则和实践，模式也是很主要的，多研究模式及其运用可以使你更深层次的理解敏捷开拓。
敏捷开拓现已成为绝大多数IT企业采取的项目管理方法。
敏捷开拓以用户的需求进化为核心，采取迭代、循规蹈矩的方法进行软件开拓。
敏捷精神（The spirit of agile）：透明、沟通、协作
二、什么是ScrumScrum 是一个框架,在这个框架中人们可以办理繁芜的自适应问题,同时也能 高效并有创造性地交付尽可能高代价的产品。
Scrum 是:轻量级的、随意马虎理解的 、难以精通的
Scrum 不是开拓产品的一种流程或一项技能,而是一个框架,在这个框架里可以运用各种流程和技能。 Scrum
能使产品管理和开拓实践的相对功效(relative efficacy) 显现出来, 以便进行改进。
Scrum 框架由 Scrum 团队及其干系的角色、事宜、工件和规则组成。框架中的每个模块都有其特定的目的, 对Scrum
的成功履行和利用都至关主要。
Scrum 基于履历型流程掌握理论, 或者称为履历主义。履历主义主见知识源于履历, 而决策基于已知的事物。Scrum
采取迭代增量式的方法来优化可预测性和管理风险。
透明性、检视、调度是履历型流程的三大支柱,支撑起每个履历型掌握流程的履行。
三、Scrum组成职员每个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的三大支柱如下：
第一：透明性（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和sprintbacklog绝对不仅仅是user story。很多人任务敏捷抛弃了文档，而实际上敏捷只是浓缩了文档，backlog中有userstory，有详细的业务场景描述，有优先级，有规模和事情量估计，有类型，有如何演示，如何实现，如何测试等各种内容。这些内容可以看到一贯从需求覆盖到设计和实现和测试。这可以说是敏捷里面最主要的一份文档，而且这份文档是完备可以构造化的文档，构造化的条款便是userstory，用户故事是最开始的最小粒度单元，关于用户故事的需求，设计和测试所有内容都在这里，表示办法最大略便是excel，这个东西太好了，你这样做你创造原来cmmi需求管理中要做的需求追踪没必要了，这个excel文档本身就实现了需求追踪。单独的测试用例文档彷佛也没有必要了，需求文档也不要了，而且需求比原来的描述办法更好，表示了业务场景站在用户视角，没必要还要像原来搞个用户需求文档+软件需求文档，项目管理的繁芜文档也可以不要了，就在这里估算安排职员，确定韶光。以是可以看到浓缩的都是精华。
再回过分看来，架构到哪里去了？backlog里面能否表示架构的核心内容？我个人的答案是不能的，仍旧沿用《人月神话》里面不雅观点的话，架构须要担保高度的观点完全性，否则谈不上架构。backlog里面的如何实现彷佛表示了部分架构的内容，让我们觉得架构也是可以迭代的，渐进式的，这个不雅观点没有错，但是这个只能举措看成是低层级的概要设计，高层的架构还是没有。以是我原来一贯强调了一个思路，对付变更型和增量版本型的项目特殊适宜用scrum，而对付全新的项目根据适宜RUP的思路，表示用例驱动和架构为核心，在迭代版本方案出来后再考虑敏捷的思路。
在岗位细分后，软件开拓里面分出了独立的需求剖析师和架构设计师岗位，大家可以回忆下原来没有细分前，这两个岗位实在和合并为一个的，即原来的系统剖析员。这实在是履行敏捷后我们须要做的一个回归，重新会产生类似系统剖析员角色，系统剖析员卖力需求和高层架构。低层的一些架构下沉到sprintbacklog的每一个迭代里面来做。高层架构做的内容包括全局用例剖析，全局数据视图，集成视图和接口交付，其掌握的边界在于这些内容是否超过了多个迭代版本，这好比一个数据实体设计，如果是在某一个迭代版本内部体内循环则不一定要在高层架构设计，但是如何是涉及到多个迭代版本利用则须要在高层架构识别和设计。对付全新的产品研发，高层架构不稳定，直接导致不断迭代加入进来的内容构造混乱，这个问题必须要重视和考虑。
很多时候我们都在想，我现在新研发一个产品，原来公司类似的一个产品已经用过这个架构了，或者说公司已经有相应的技能平台，以是架构事情没有必要了。把稳我们常日说的产品平台或技能平台，SSH框架等都是框架，是架构中非功能性架构的内容。而实际根据产品需求或用户需求过来，考虑的子系统，模块组件方案等是功能性架构的内容，不要以为有了平台或框架就没有架构的内容了。
通过前面剖析，敏捷下架构能否迭代的问题就比较清楚了。对付不属于高层架构的内容是可以迭代的，到了每一个迭代版本中再来做架构，对付高层架构的内容一样平常不能迭代以担保设计的观点完全性。对付高层架构本身，全体设计和方案思路是不能迭代的，但是实现过程本身是可以迭代的，如同一个接口，设计必须表示做，这个做了接口本身的实现可以和其它功能模块的开拓并行。
