之前已经说过很多关于敏捷开发的东西，过多的鸡汤就不再鳌述。其实，敏捷开发已经成为常态化，随着计算机与网络技术的日渐成熟，互联网以及以互联网为平台的各种网上应用如火如荼，在给传统产业带来无限商机的同时，也带来更多的挑战。首先，经历多年的激烈竞争历程，企业之间的竞争已达白热化状态，产品生命周期愈来愈短，产品更新换代速度愈来愈快，为企业盈利的新产品寿命比工业社会的产品明显缩短。随着BTOB(企业对企业)、BTOC(企业对顾客)等各种模式电子商务的应用，全球物流配送系统的迅速发展，跨地区、跨国界网络交易行为的边际成本趋平，任何一家企业都将面临国际化、全球化的市场竞争。其次消费个性需求复归，许多消费者不再满足于毫无个性的流水线产品，他们更希望能够影响、最好是亲自参与到产品的设计制造过程中来，而网上开办的个性订购使这种需求成为可能。

竞争环境的剧烈变化，使单纯依靠企业内部资源孤军奋战的竞争形式显得力不从心，跨企业甚至跨行业的联盟竞争成为网络时代的主流。协作突破企业边界，促使供应链观念从线性向网络变革，并逐步形成今天的敏捷供应链思想。

对于敏捷前面谈的很多，其核心仍然是短周期迭代交付，可视化，自适应调整，开放式及时沟通，所有的敏捷实践基本都是围绕这些核心展开，如果再要对敏捷的核心抽象就是迭代+自适应。

周末和我一个老同事聊天，觉得在原公司实施敏捷后确实带来了很多的变化。原来可能大家都说很忙，确实是否真的很忙不清楚，原来一个任务来了来安排不下去，原来客户要的东西迟迟交付不了，或者是交付后就陷入到持续的变更。实施敏捷后这些问题都得到了一定的程度的改善，这么好的东西怎么原来没有引入进来，在cmmi上浪费了这么多的时间。

敏捷开发离不开架构？架构离不开敏捷开发？难道得出这些问题答案非要经由一场讽刺漫画般、基于根深蒂固价值观的针锋相对，而不能在二者清晰定义之上、基于开放的、推理式的对话？也许，更通俗地描述问题是回答它的良好开始：除了专注于敏捷方法之外，我们还需要广泛考虑各种开发过程？而且，与提出假设性问题相比，我们应该思考更开放、中立的问题——架构与过程之间的关系是什么？

架构和过程

架构一词常通常被定义为“系统的结构性拆分，包括模块划分、块间关联、交互机制以及系统设计的指导原则”

尽管从技术角度看它并不正确，但这一定义却可以支持广泛的解释。它上可指与技术、代码、实际系统架设几近无关的高层抽象设计，下可代与很多类、代码级细节密切相关的大而僵化的预先设计。然而，实际情况却是，这两种指代既不足以指导实际项目开发流程，又不足以为“好”架构带来必要的贡献。前者太抽象以至很难涉及具体细节；后者尚未得知相关事实就早早下了论断。因而，敏捷社区的部分人不把架构当作真实项目开发的核心要素也就不足为奇了。

相形之下，GradyBooch3和MartinFowler4共同提出了价值导向的软件架构定义。他们把架构定义为昂贵且难于改变的重大决策。PaulDyson和AndyLongshaw在架构的结构性定义之上作了指导设计决策方面的论据补充。这些定义有助于我们将架构视为功能需求、操作特性和开发者适居性等需求所对应的解决方案。

实际上，从一份手拟初稿到各项关键细节，描述软件架构少不了各类决策：有些决策恰当而明确，有些决策需要假设条件，还有些决策做时无心，事后却发现很重要。

这样看来，架构是为开发能达成一系列商业和技术目标6的软件系统而提供的指导性服务，以最适合于交流和分享的形式呈现；它本身并不是什么技术造物，要借纯粹的形式化描述存在。

过程可以被看作一系列问题的答案：谁在做什么？什么时间？为什么做？为谁做？每个软件开发项目都对应于一个过程，即便它并不明显：无论松散或正式，无论团队是否主动控制开发，过程都在为这些问题作答。

然而，你也可以看到，我们在项目成员、预算和规划方面做出的决定会极大地影响到架构的选择和可行性。这一结论适用范围很广：从无视最初版本的康威定律7指导的系统分划带来的强大影响，到技术选择和技能、预期范围、发布模式，甚至实际系统设计方面的问题。

这些影响相互依赖，再加上随时间变化这一趋势，需要过程为架构的相关切面建立清晰的决策链和直接且有意义的反馈环，从而将最新的信息融入决策，以便应对不可避免的发明或发现带来的影响。过程要为项目团队提供支持，而不是颠倒过来，项目团队是为了交付可运行软件而不是为了遵循过程。这正是敏捷过程的目标。

一、什么是敏捷开发

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。

除了原则和实践，模式也是很重要的，多研究模式及其应用可以使你更深层次的理解敏捷开发。

敏捷开发现已成为绝大多数IT企业采用的项目管理方法。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

敏捷精神（Thespiritofagile）：**透明、沟通、协作**

二、什么是Scrum

Scrum是一个框架,在这个框架中人们可以解决复杂的自适应问题,同时也能高效并有创造性地交付尽可能高价值的产品。

Scrum是:轻量级的、容易理解的、难以精通的

Scrum不是开发产品的一种流程或一项技术,而是一个框架,在这个框架里可以应用各种流程和技术。Scrum

能使产品管理和开发实践的相对功效(relativeefficacy)显现出来,以便进行改进。

Scrum框架由Scrum团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的,对Scrum

的成功实施和运用都至关重要。

Scrum基于经验型流程控制理论,或者称为经验主义。经验主义主张知识源于经验,而决策基于已知的事物。Scrum

采用迭代增量式的方法来优化可预测性和管理风险。

透明性、检视、调整是经验型流程的三大支柱,支撑起每个经验型控制流程的实施。

三、Scrum组成人员

每个Sprint中团队都要花一些时间来为下一个迭代做准备工作（即产品列表梳理活动），包括产品列表条目的创建、细化、估算、排序等工作。每个Sprint最多分配10%的时间来协助产品负责人完成这些工作。

Sprint计划会–在Sprint计划会团队一起决定Sprint内要完成哪些故事，并进行任务分解和估算。检视和调整产品与过程–

即参加Sprint评审会（检视调整产品）和Sprint回顾会（检视调整过程）。

四、Scrum流程

架构对敏捷开发而言意味着什么？

与软件社区的某些讨论相比，敏捷开发并非要求像船货崇拜那样热衷于Scrum或其他过程、工具和方法学，尽管我们的确看到了这一现象并认为这是个问题。敏捷的要素是响应性、不断学习和充分。敏捷表现为软件及其开发过程的可持续和高质量，非持续的低质量开发有悖于敏捷。敏捷宣言中写道“对卓越技术和良好设计的持续