Scrum敏捷开发 —实现多维度碎片化迭代_scrum多迭代多发布模型

敏捷开发已经成为常态化，随着计算机与网络技术的日渐成熟，互联网以及以互联网为平台的各种网上应用如火如荼，在给传统产业带来无限商机的同时，也带来更多的挑战。首先，经历多年的激烈竞争历程，企业之间的竞争已达白热化状态，产品生命周期愈来愈短，产品更新换代速度愈来愈快，为企业盈利的新产品寿命比工业社会的产品明显缩短。随着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