摘要
本文旨在介绍和分析敏捷做法。根据作者以及这个可能更广泛的社区，敏捷做法可以成功地用于商业组织转型，能够帮助一个商业组织变得更加敏捷，从而使其具有更强的竞争力。这种转型被称为敏捷业务转型（ABT）。
本文还介绍了一个组织从瀑布式软件开发方法转变为敏捷软件开发方法的主要优势，同时也对这些方法在组织中的主要表现形式进行了对比。
最后，本文介绍了促使敏捷业务转型的人员以及转型的变动管理方面，并简要概述了敏捷业务转型和敏捷的主要信息：敏捷是一个自适应方法，而不是规范性方法，因此进行敏捷业务转型的组织应进一步继续适应最有效的工作途径。
 本文请求同行审查，希望更多人就如何改进提出看法。如果您觉得本文应该做些改进，请随时进行修改。
简介
当今市场上的大多数组织，即使仅仅想维持最低利润，也需要根据外部市场因素不断进行调整、演进和提高。若想成为市场上的竞争强者或引领者，组织必须正确预测市场趋势，进行自身转变来引领市场潮流，并且定义市场规则。因此，竞争力强的组织需要创新，并可快速改变战略方向；其中IT就是大部分战略运营策略（实施）的核心。频繁的组织变更以及起辅助作用的IT变更的重要性日趋明显。
接下来的问题就是：如果组织采用僵化的瀑布型软件开发流程——瀑布型软件的交付周期为一年或者更长——的话，那么组织的商业软件又将如何辅助策略的实施呢？在这期间，商业环境又会发生改变，可能都已经面目全非（例如，想一想当今的“信用危机”的影响
），那么为开工项目所做的所有努力都将付诸东流。
如果组织在战略层面上有一定灵活性，那么软件开发部门则需要针对此种改变寻找对策，并且尽快为组织带来效益。开发软件显然与楼房构建截然不同，因为楼房构造需经过长期的分析阶段。尽快带来效益的方法就是采用敏捷软件开发方法，并且实施敏捷业务转型（ABT）。
现阶段已经有一些敏捷软件开发方法，例如极端编程和Scrum。所有这些方法都具有敏捷宣言中的特性，并且有很多的通用做法。它们之间的主要相似点就是：敏捷方法并不是规范性的方法论，而是调整性的方法论，其中会涉及很多的反馈机制来实现持续调整、流程改进和成本削减。
本文将对敏捷业务转型进行有效的描述，包括主要的转型敏捷做法、领导敏捷业务转型所需要的人员和变更管理。ABT中的敏捷做法在大多数敏捷软件开发方法中都是通用的；笔者认为它们是敏捷业务转型成功的关键因素。
本文结构如下：第二部分通过对比瀑布型软件开发方法和敏捷软件开发方法，分析敏捷型的优势；第三部分分析主要的转型做法；第四部分关注ABT中所需要的人员；第五部分研究变更管理；最后在第七部分对本文进行总结。
本文从商业和流程角度分析敏捷型方法。敏捷型团队的分析、质量保证和开发方法，例如结对编程、测试驱动开发、持续集成、自动化测试、域驱动设计和其他内容将会在MIKE2.0的其他文章中探讨。
敏捷业务转型的优势
敏捷业务转型是将业务从瀑布型开发方法转化为敏捷型开发方法的过程。笔者在此并无贬低瀑布型方法的意思，在很多工程领域例如土木工程和电气工程中就应用瀑布型开发方法；笔者只是认为瀑布型方法固然有其独到之处，只是不适用于开发业务类型软件。
瀑布开发方法由一系列按顺序完成的、分散独立阶段组成（分析-开发-测试-部署）。这些阶段除了在不同阶段交接时所涉团队之间会有沟通外，并无任何重合之处。瀑布型开发方法一般会有一个冗长的分析阶段；就是因为做了太多详尽的分析，开发团队需要很长时间来全面理解分析工件，进而导致开发过程的停滞。另外一个问题就是：在软件开发中，只有开始实施之后，才会看到设计中存在的问题，而此时还必须重新分析，并且对如此之多的文档加以修改！还可能由于竞争对手的动作，业务部门必须做出反应，就会在几个月之后分析已经完成之时，改变要求……，所有这些改变都会带来沉没成本和管理费用。很多组织并不完全符合这种极端的瀑布型描述，然而可能也与之很相近。
瀑布型项目的开发阶段，也和分析阶段一样，当有变动发生时，成本会很昂贵，并且软件编码也不灵活。
然而，敏捷开发方法的初期分析阶段比较短暂，往往为1-4周（取决于域的复杂程度和规模大小）；并且它们也认为由于一直会有变更，即使花费更长的时间做分析，将来这些分析结果也都不会派上用场。敏捷方法的初期分析只是确定范围，详细分析会在以后进行。结果就是，会在很短的迭代周期内将软件交付业务部门，鉴于分析-开发-测试-部署阶段具有连续性，这些迭代周期也互相重合，并且也不需在功能流间进行项目移接，因为他们将会一起工作，直至项目结束。一旦接到新的变动或者优先级更高的要求（例如，对竞争对手的反应），可以“及时”地对其进行分析，并且在下一个迭代周期或者当前迭代周期内进行开发。当然，如此的敏捷性也需要不同的代码实现方法——这些留待MIKE2.0中的其它文章解释。然而，由于只是进行了少量的初期分析，沉没成本会大大减少，也使业务部门的投入产生更大价值。下表中的图示清楚的表明了两种方法的不同之处。
表中上方的模块群表示敏捷开发方法中不同工作流（分析-开发-测试-部署）的运行方式；表下方的的长条模块表示在瀑布型开发方法中的运行方法。从上表中可看出，6个“分析（A）”模块等同于一个“瀑布-分析（W-A）”模块，其它的功能模块也存在同样关系。为了表示方便，上图中假设性地表示出开发流程中的所有工作流会花费同样长的时间。请注意，在瀑布式开发模式中，业务部门会等待很长时间才可以看到效益。如果上图中的每个模块都等同于同样的成本，那本表则表示两种方法的成本相同，本文中不会对此情况进行分析。敏捷方法中，不仅仅由于变更成本降低（如所述）而降低成本，而且其专注于持续改进并对丰田生产体系中的精益原则进行利用，也会降低成本。
别处可能有关于二者之间更详细对比的解释，但是此处我们完全可以得出下列结论：组织采用敏捷开发软件方法会具有下列优势（这些也是敏捷业务转型的优势）：
敏捷业务转型的做法
企业向“更加欢迎变更”（低成本变更）、更加精益且更具有竞争力模式的转型过程中，有六种主要的敏捷做法：迭代式开发软件、通过用户故事搜集业务需求、通过故事墙来搜集团队进程反馈和迭代周期中的制约因素、定期举行站立会议和团队回顾会议可以从生产力角度持续改善、经常性地向业务部门展示工作成就以及根据优先级开发软件功能。
这些做法和敏捷业务转型配备人员，即敏捷冠军，一起构成敏捷业务转型项目成功的两个主要方面。曾经应用过敏捷方法论，并且曾在项目中领导过敏捷功能流，可以根据不同的环境对做法进行调整，并且透彻理解为何采用敏捷方法的专家，就是笔者在本文中所指的“敏捷冠军”。这些人是敏捷业务转型中的关键因素，人员变更将会在以下章节探讨。敏捷冠军和这些做法结合在一起，可以改变人们的想法，进而可以实现企业转型的优势。敏捷业务转型中的人员是成功的核心因素，敏捷方法“相比于流程和工具而言，更看重个人和互动”
敏捷冠军累积了不易传达的隐形知识，因为这些知识都是暗示或暗含的。而此处将要解释的做法都是显性知识，如果缺少敏捷冠军，至少在敏捷业务转型的初始阶段缺少敏捷冠军的话，优势不会得以充分实现。
迭代周期
迭代周期一般为跨度一周到一个月的完整开发周期（分析-开发-测试-部署）。通过迭代式交付的敏捷做法的目的是：通过研发很多可以正常工作的最终系统版本来交付软件，但是每次都只是加入一些子集功能。
一般来说，开发团队的规模越大、能力越强，迭代周期就越短，因为迭代周期的长短应该由对业务带来的价值来确定，也就是每个迭代周期都应该能够带来显著的业务效益。例如，如果只有两个开发人员在开发编码，他们可于一周之内完成数据录入界面的布局调整
，那么此迭代周期应该比一周要长，因为界面调整所带来的商业效益并不够显著—显著效益取决于业务部门的说法，并且需要附上财务数据。
下面是迭代式开发软件的优势和缺点的分析。
迭代式开发的主要优势：
- 对团队的真实进展、代码开发、测试、团队动态以及业务需求的搜集和沟通效果提供快速反馈，可以即刻进行确认并且采取相应动作。
- 尽早实现商业效益，因为随着每个迭代周期的完成，软件功能都会发布到现有系统中或者对软件产品进行更新，所以收入开始流入或者可以快速实现生产力效益。
- 迭代式支持流程、编码和其他创新项目，可以采用迭代式试验一个新想法，并会很快地对其价值得到反馈——因此此处“适用快速失败原则”。创新是竞争力优势的源泉，而且很多时候都是可持续竞争优势的源泉。
- 最小化与商业软件要求的不可预测性相关的沉没成本，因为我们只需要在现行的迭代周期内保持稳定的要求，对未来只需要有个前景规划即可，而并不需要完整的要求规格。如前面解释的一样，如果要求改变的话，沉没成本会很少。另外由于敏捷团队开发代码的方式（在本文档探讨的范围之外），其余代码变更成本也很低。
- 确定业务需求，而不是想法——由于可以快速交付可以工作的软件，终端用户在使用之后，可以针对他们的真正需求提出反馈。为了详细地解释这个重点——要求软件功能的业务部门通常在项目开始时了解他们所缺乏的功能，但是由于构建新软件时，企业股东和用户可能并不能确定他们的真正需求，因为很难想象出每个人的需求，尤其是细节方面的需求。只有人们开始使用或者尝试使用之后才会清楚。
迭代式开发的可能缺点
- 迭代式可能需要大量的管理费用，因为如果部署成本大的话，过度频繁地向运行系统进行迭代式部署会增加费用。
- 需要持续的将软件客户和用户包含在开发过程之中，因为在现行迭代周期内，必须对下一个迭代周期的业务需求或需求变更进行详细分析（即时分析）。
用户故事
用户故事是一种用来搜集业务需求的敏捷做法，并且对即将发生对话进行提醒，进而进行即时分析。用户故事一般都写于卡片上，以方便业务干系人和业务分析师的协同创造。本部分接下来就会对用户故事的内容、创建过程以及如何从概念分解为细节用户故事以进行即时分析、还有应用它们记录业务需求的优缺点进行简略描述。
用户故事本身由两部分组成：用户故事的描述和接受标准，业务部门就根据此接受标准来决定要求是否得到满足并接受产品。可以视接受标准为开发内容的“软”合同。它之所以是“软”合同，是因为如果变更会给业务带来更多价值的话，它则总是在变化。写作接受标准、用户故事和创建故事树（用以管理分析结构）指南在Mike2.0的其他文章中有描述。接受标准不外乎是以“事先条件-动作-后置条件”模式的肯定声明。下面就是一个用户故事描述的范例：作为一个投资银行家<谁>，我想让我所有的投资情况都显示在一个资料窗中<什么>，进而我可以一目了然的看到我的投资情况的变化<为什么>。此描述应该表明此要求是为“谁”而设，此要求的内容是“什么”，并且“为什么”此要求会产生效益（也就是它会创造何种价值）。
简要描述为开发团队和每个人提供了很多需要考虑的信息，并且最重要的是会促生对话，并且从富有建设性的对话中，针对即将出现问题的新颖解决方案也会浮出水面。“谁”告诉大家谁是此功能的主要受益者，这一点很重要，因为开发团队必须随时将终端用户牢记于心，才可以交付高质量的功能。此处的重点是开发者经常花费大量时间和精力开发某个新功能，然而将客户牢记于心则意味着：如果可以准确的知道谁会使用这些功能以及他们为什么需要此功能，他们就可以通过更低的成本研发出创新性替代办法。用户故事的“什么”部分自身就说明了一切，是关于企业股东或者用户需要内容的声明，必须用商业（域）语言书写。它不应该包括具体实施步骤；例如：需求不可以如此写“我想要一个弹出框，对删除内容进行提醒”，因为弹出框可能并不是最好或者成本最低的实现目标的方法，开发者和用户界面专家对如何满足“为什么”——对删除内容进行提醒——有着更深刻的了解。
最终，“为什么”可能是用户故事中最重要的部分，因为如果没有为什么或者对为什么需要此要求没有进行详细规划，那么开发团队就会被常见问题“但是为什么业务部门需要这个呢”所困扰。当开发团队需要知道“为什么”，但是没有人对此功能作出解释（“为什么
”）时，这就会引发和业务部门的对话，而且有可能发现可能并不需要这个功能。而且，业务分析师发现业务部门不能明确地传达为什么需要此功能时，应该对此功能的业务价值提出质疑。当然在用户故事编写所在的两周前时，这可能还是一套不错的需求。
而且，用户故事是轻量级方法，易于创建和废弃，所以可以进行即时分析。在项目伊始，通过用户故事来搜集概要需求，然后，当开始策划软件开发的时候，就会通过用户故事来搜集细节（实施）的业务需求。实际上，在开发迭代周期之前，敏捷分析团队会分析概要用户故事，并将其分解为细节用户故事，但是到那时为止，用户故事搜集了对即将发生的对话的提醒——所以，这是一个即时分析。若不进行即时分析，将会产生大量的工作项目库，而这些工作项都不会用来创造收入
；还有当需求改变时，这些保存项可能会完全丧失其价值，并都不再适用（例如，当市场变化时）。
下图描述了业务需求的层次——从项目目标开始，到概要用户故事（对目标进行分解得到）和可以实施的细节用户故事。图中，黄色椭圆中的故事表示初期项目范围，紫色和粉红色椭圆中的故事表示在迭代周期1和迭代周期2已经开发完毕，剩余的蓝块是即将需要开发的故事。请注意：图中仅有很少的前期分析——很少
的“第三级故事”。细节用户故事或者迭代层用户故事已开发完毕，当必需的时候才会做分析——只要不耽误开发就可以。请注意目标和交付的用户故事之间的明确联系。首先进行分析和开发的故事是优先级最高的故事——在敏捷方法中，并没有对范围加以明确，因为要求一直都在改变，但是团队一直都是从事优先级最高的功能。
用户故事的主要优势
- 将业务人员放于驾驶座上——用户故事专注于业务需求，并且所有用户故事都是用业务语言书写，因此业务很容易进入相关对话并做出决策。
- 作为对话的提醒——并且促生对话，不仅由于描述的模式（谁-什么-为什么），还因为接受标准从来都未得到完整收集，目的是就是在开发过程中允许创新性想法的引进。
- 使即时分析得以实施——用户故事是对即将发生的对话的提醒，因此一旦形成概要用户故事的书面文件（对业务目标加以分解得到），若无必要，就不会再对其继续进行分析，只需用来为有用的对话搜集足够的细节。这也避免了多余的前提功能分析，因为如果将来需求变化了
，这些功能可能不再被开发。
用户故事的可能缺点
- 可能的依赖性——有时候业务需求分解为独立的细节用户故事的过程会很复杂，同时也必须将它们之间的依赖性考虑在内。这些依赖性会引起迭代性策划问题，并且会导致优先级低的故事首先得以交付。
故事墙
故事墙是用来公开跟踪管理迭代周期内用户故事进度的方法。故事墙既可以在实体白板上描绘，将故事粘贴上去，并且按顺序移动；当团队成员分散各地时，则可以采用电子版本。团队可以决定诸如故事墙的列内容、应当采用何种故事状态等细节问题。下图中的故事墙是对故事墙的阐释，图中表明在在某一时间点上团队在迭代周期中的进展状态。红色的长方形模块是用户故事。
上表中，第一列是计划在迭代周期中开发的故事，这些故事都已经过仔细分析，可以进入实施阶段。直到业务部门满意并且同意用户故事完成时，一切才算完成。因此，每个用户故事都要求求业务人员“签收”，所以在图中也有此列。
除了向全体团队成员通告进展状况，故事墙还可以显示所涉及子团队（测试员-分析师-开发者）的资源容量缺乏情况，故事墙可以快速地阐明长期资源限制和临时性限制（例如：某组的一个成员某天生病）的影响。可以通过仔细的工作项目计划将长期资源限制最小化，然而即使那时，个人的生产力还取决于他们的工作经验和其它很多因素。因此由于在计划阶段不可准确预测的因素，资源限制可能会一直存在，但是这些会通过故事墙明显地表示出来，若某一列累积的用户故事过多，则表明某个子团队就是限制因素。而且，故事墙可以直观的展现出暂时限制（例如，某个人的缺席会如何影响团队的整体工作流效率）。从上面的故事墙中，可发现某个潜在限制：业务部门不签收已经开发且测试完毕的用户故事；所以团队必须对此假设性限制展开调查，并针对它采取措施。
故事墙的主要优势
- 可以快速发现资源限制——会针对这些限制采取措施，而避免浪费。并且随着新限制日趋明显，也可以针对其采取动作，效率因此就会持续提高（Goldratt
& Cox, 2004）。可以通过转移某些资源来解决暂时限制，例如，开发者可以帮助作从事些测试工作。
- 开放且廉价的进程跟踪——当团队成员完成某个故事时，他们可以简单地将其移动至下一列；基本上以零成本就实现了流程的跟踪，而且还实现了组内的公开沟通。
- 展示迭代周期的全景——通过故事墙，可以传达出全景。鉴于用户故事是分别独立的，进行某个具体用户故事的开发团队可能会看不到总体目标，或者看不到迭代周期的“主题”；在迭代周期内有一点很重要，就是每个人都必须明确全景和集体工作目标。
故事墙的可能缺点
笔者看来，故事墙没有任何缺点。
回顾会议和站立会议
在部分项目中，经理强行实施软件开发过程；然而笔者看来，以前与笔者合作过的很多人也都同意的一种看法是：流程应该是“自下而上发展起来”的，在敏捷冠军领导下的团队，选择针对目前项目团队最有利而且最经济的流程和做法。因此在项目开始之前，采用的流程和做法不应当也不可能完全选择完毕；一旦项目开始，团队应该对不得不调整做法或者选择对组织最有利的崭新做法做好准备。这是敏捷软件开发意识中最重要的内容——敏捷性是一种调整性方法而不是规范性方法。
针对项目进展和过程的量化反馈（效率指标）可通过项目经理记录的迭代指标加以明确，但是针对过程的质量反馈则是通过团队回顾和站立会议来实现的，这也是为什么质量反馈做法如此重要且起补充作用的原因。这种公开反馈对流程和做法的调整是有必要的。
团队回顾是非正式但是结构化的团队会议，应该在每个迭代周期结束时进行回顾，为在迭代周期开始之际选择好的做法发挥作用留出充裕时间。整个团队都应参加回顾过程，包括经理、分析师、质量保证分析员、以及所有的开发者。同时也鼓励业务干系人参与回顾，因为在敏捷团队中，与业务的沟通一直都在进行中，所以业务干系人的反馈是非常重要的。
在回顾会议过程中，团队应该讨论并记录团队工作的好地方、不足以及疑惑（例如，某些决策），并且要创建行动清单为将来如何改善提供指导。改善建议应当在整个组内进行公开讨论，然后在正式引进之前，也应对其经济影响力进行核查。如果讨论环境不够安全，那么回顾就不会产生多大效用；之所以采用回顾，就是基于此想法：即每个人都可以公开表达其想法并做出建设性贡献。
每日站立会议对回顾会议起辅助作用。由于回顾会议是基于每周、双周或者每月进行的（取决于迭代周期的长短），而每日站立会议则可以更加快速的提供反馈，因为站立会议每天都举行的。每日站立会议需要将整个团队都包括进来，大家站在故事墙旁边，每个成员对昨天的工作内容、今天的工作计划以及遇到的任何困难讲出来。必须将开发难题提出来，因为其他的团队成员可能在那一领域是专家，可以提供帮助或者彻底解决此难题——例如，某个开发者在JAVA脚本方面遇到困难，但是另外一个JAVA脚本的专家则在从事另一个不同的项目，这种情况下，如果交换成本低，可以将两人对调，或者可以就此提供建议。同时，此流程和做法中相关的任何问题都应在站立会议上提出，然后才可以针对此反馈采取动作。
回顾和站立会议的主要优势
- 为项目提供定性反馈——如若不能提前知道，其中某些问题可能会毁掉整个项目。例如：分析师认识到业务部门并不能明确其真正需求，且不能对其进行优先级排序。
- 可以持续改进——因为反馈得到搜集并且采取了相应措施；这也考虑到：为实现最大效益，对采用做法和过程的持续改进。
- 支持团队之间的知识分享——尤其在站立会议上，团队成员可以向团队通告自己正在进行的工作内容。
回顾和站立会议的可能缺点
- 需要加以管理——在这两种反馈做法中，不可漫无边际的展开对话，必须确定产出，并针对产出采取措施。
展示
展示是开发团队向业务部门展示他们在上个迭代周期内所完成内容的敏捷做法。此演示通常不是以系统用户为目标，因为在每个迭代周期内他们都会应用新功能并且知晓进展；展示的目标群体是高层的业务干系人。
展示使开发者对他们的工作成果产生强烈的所属感，他们也不会认为他们在为“某处的某些业务用户”开发程序。开发团队还会产生强烈的成就感，因为他们满足了业务需求，并且他们的交付产品及其产生的价值会也会得到客户的感激。展示也会在双方之间形成重要关系，而这种关系会使业务部门或团队与开发团队之间的沟通更加自由地流通；如果没有这种沟通，就会导致业务需求规定不明确或者理解不彻底，而导致项目失败。
展示也会从业务线经理处得到认可，而这也是ABT和任何变更项目中，至关重要的因素。在典型的瀑布项目中，高层业务干系人需要等待如此长的时间，才可以看到功能的实现；而在项目实施过程中他们所知道只是成本，而看不到一丝成效。
展示的主要优势
- 得到高层业务干系人的认同——因为他们会频繁看到他们的资金所带来的巨大效益。
- 提高开发者的所属感——这一活动让开发者责任感更强，会让他们更加热爱工作并且提高质量。
展示的可能缺点
- 可能会增加大量管理费用——因为很多的高层领导需要抽出时间参加展示活动，而同时很多的项目团队成员也会从项目工作中抽调出来，所以举行展示的成本会是非常巨大的。这一活动应该举行，但是高层领导可以轮流参加展示活动。
优先级驱动开发
优先级驱动开发做法保证项目团队始终都是开发业务部门认为优先级最高的功能。优先级最高的功能一般都是可以带来最高业务价值的功能。不应该开发纯技术的软件，除非它们比可以其他任何软件功能提供更高的商业价值。
确保团队一直都在开发优先级最高的软件功能（或用户故事）是核心部分，所以客户和业务部门的资金会得到最大回报，进而对交付产品满意。因为软件功能迭代式地应用到现有系统中，可以更早的产生收入，而这也会缩减投资回报期间，同时资本支出项目就会变成自我维持项目，并且为业务带来收入。而且，即使由于某种外部市场原因原因导致项目缺乏资金，团队也将会在拥有的预算内交付最高价值的软件。
因此，优先级驱动开发意味着：
1) 业务部门应该对所有要开发的软件功能进行优先级排序——因此业务部门必须举行优先级排序会议来决定概要用户故事和细节用户故事的优先级别；因为当概要用户故事分解为细节用户故事时，可能会有一些重要程度稍低的细节故事。
2) 交付软件的团队始终都在开发优先级最高的功能——因此应对进入迭代周期的用户故事进行管理，将优先级最高的故事包括在内。
关于第一点，业务部门将会基于此功能给他们带来的效益和开发此功能的成本，来进行决策。此规则有两种例外情形：软件功能是技术必需品，或者必须交付此功能才可以进行其他功能的研发交付。最终，所有的技术功能也应该由业务部门根据成本/效益权衡进行优先级排序。
优先级驱动开发的主要优势
- 统一团队和组织的目标——优先级排序保证了团队的工作重点一直都是最重要的内容，并且整个团队都统一为组织创造价值，这也是最终目的。
- 实现短期回报——首先将会交付巨大的商业价值（高效益和低廉的开发成本），进而实现短期回报。
- 使项目的有形产出风险最小化——不管由于何种原因项目而终止，优先级最高的功能会尽早得以交付并且完全发挥作用。
优先级驱动开发的可能缺点
- 有时会很难对某个低层软件功能的商业价值进行量化-但是可以采用对相对优先级进行排序，进而用来区分软件商业价值的大小。
与其它敏捷做法的关系
下图清楚地解释了敏捷业务转型的主要做法和全球范围内敏捷团队所应用的其他做法之间的联系。在内环里的做法是敏捷业务转型的核心，然而，若想完成向敏捷的转型，组织也必须采用其他的敏捷做法，包括项目和迭代周期管理、商业分析、质量保证和编码开发功能。
笔者认为，组织若想在其软件开发过程中拥有敏捷性，并被冠以“敏捷”之名，它至少需要执行在本文中描述的敏捷业务转型中的主要做法。其它做法，根据项目角色可以进行分组（管理-业务分析-质量保证-编码开发），也都十分重要，在MIKE2.0中关于敏捷方法的其他文章中有讲解。
在敏捷业务转型中的敏捷冠军
所有的业务转型都需要冠军，敏捷业务转型需要的就是敏捷冠军，敏捷冠军将会领导敏捷业务转型做法和项目的功能方面（或者角色），即他们应该领导项目管理、分析、开发和测试。尽管可能没有敏捷冠军，敏捷业务转型做法中的某些效益也可能达到，笔者认为若没有敏捷冠军，其效益不可能充分实现。
除了敏捷业务转型的主要做法外，还有很多的其他有益做法，敏捷冠军可以对其进行应用，并领导组织完成向敏捷方法的完整过渡。例如，开发者应该引导结对编程、持续编码集成、测试驱动开发和自动化测试等。这些角色的所有具体做法都在本文探讨范围之外，会在在Mike2.0的相关文章中予以解释。
下图表明了在敏捷项目团队中的主要项目角色，以及这些角色履行的活动。请注意这些角色之间的重复活动，尤其在要求确认方面的重复活动。软件项目之所以失败的一个主要原因就是他们它们没有实现需求，或者实现了错误的需求。因此，在敏捷项目团队中，随时对为什么开发这个功能提出疑问是整个团队的职责。
变更管理
变更管理是敏捷业务转型中的重要部分，必须将干系人认可、关于变更的沟通、变更规划/计划以及引领变更的敏捷冠军都包括在内。而且不言而喻，敏捷业务转型应该是业务场景驱动的，并且要跟踪其进展。变更管理的职责分散于整个敏捷团队，但是所有权一般都是归项目经理所有。
本文中谈及的敏捷业务转型做法涉及很多的隐形知识，这也是为什么从书本上很难学习敏捷方法的原因之一，也是为什么需要敏捷冠军来为所有敏捷团队角色在变动中树立榜样的原因之一。
下图表明随着业务转型为敏捷方式，可能发生的思想改变；此新思想反映了敏捷宣言中的敏捷价值。
总结和结论
敏捷业务转型的目的是提高软件开发和交付团队的敏捷性，并同时降低软件项目的风险，尽早地提供效益，并且让软件开发团队和业务部门有同样的目标——创造商业价值。
敏捷业务转型主要做法和敏捷冠军二者的结合将会引领转型，上文已经对其进行解释和分析。并且，也对适合总体敏捷做法场景的敏捷业务转型做法（与不同角色相关的所有做法）加以了说明。
最后，所有的敏捷做法用处都很大；但是核心做法，即敏捷业务转型中的做法，是转型的主要推动力，可以将敏捷性引进到软件开发过程和团队中。
| 
