解析敏捷软件开发知识体系 分享国外敏捷转型实践案例

本文主要是介绍解析敏捷软件开发知识体系 分享国外敏捷转型实践案例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

敏捷已经逐渐地被越来越多的企业所认同，许多软件开发公司都在极力向敏捷转型或是开始尝试敏捷。许多企业取得了成功，而许多企业则又回到了原来的老路上。为什么有的企业取得了成功，有的企业却失败了？因为敏捷看似简单，但转型实施起来并不容易，往往比预期的困难得多。实施敏捷是一场变革，这些变革不仅要求开发人员也要求企业中其他的成员进行大量的付出，除了在工程技术实践上的改变，思维模式和观念的改变更加关键。

本文收集了国际敏捷大师、知名企业转型实践经验，整理出了一些敏捷转型过程当中可以参考的模式和实践，期望能给企业敏捷转型提供一些帮助。

敏捷转型实践

（注：本文主体内容皆来自于Mike Cohn的《Scrum敏捷开发》）

改善Backlog

如同Scrum开发项目使用产品backlogs，你也应该使用改善backlog（improvement backlog）跟踪记录企业实施Scrum的工作。改善backlog列举了企业在实施Scrum过程中可以做的更好的所有事项。当IBM开始实施Scrum时，它的改善 backlog包括下列事项：

• 增加使用Scrum的团队数量；
• 动化测试的使用；
• 使团队能够实现持续集成；
• 想出如何确保每个团队都能有一名产品负责人（product owner）；
• 确定怎样度量实施Scrum的影响；
• 增加单元测试和测试驱动开发的使用。

表1中显示的改善backlog是动态的，某些条目会被加入，某些条目则可能因为已完成或没有必要而被移出。

一个改善backlog是一份关于企业内部那些待发展的能力、待执行的工作、或待处理的问题的列表。

表1 企业改善Backlog示例

小部门或单个项目级别的转型使用单个改善backlog。当Scrum要在部门或企业级别上实施时，因为转型的工作很大，所以需要使用多个改善backlog，这些backlog中每个都由社区创建，这些社区的成员都是那些对改善企业抱有热情，并愿意使用特别方式的个体。例如，一个社区及其对应的改善backlog可能专注于弄清楚怎样在Scrum项目上用最好的方式做自动测试，另一个则专注于如何培养并成为伟大的ScrumMasters，等等。

另外，对于大的转型，可以有一个主要的改善backlog——它会由主导企业整体转型的小组维护。

企业转型社区

发起、鼓励与支持企业引入和改进敏捷的小组被称为企业转型社区（Enterprise Transition Community，ETC）。企业转型社区的存在是为了创造一种文化、一个氛围——那些对企业的成功抱有满腔热情的人尝试做出改变，而这些人的成功又使更多的人产生更大的热情。ETC不是通过给企业强加变革来做到这点，而是通过指导实施变革的小组，消除障碍以便做好Scrum，利用为变革创造的活力与激情来做到这点的。

ETC的成员，通常不超过12人，他们来自参与Scrum转型的最高级别人员。如果一个公司在企业范围内实施Scrum，ETC应包括工程与开发的资深人员、产品管理、市场、销售、运营、人事等等各个小组的副总裁。如果是部门级别上实施Scrum，ETC可包括工程的副总裁和QA、开发、架构、交互设计、数据库等部门的领导。其中的关键是ETC要由转型发生所在级别的最为资深的人员组成。

有时，Scrum是由企业底层的人发起的。一个团队尝试了Scrum，很成功地完成一个项目，然后别的团队对此产生兴趣，于是Scrum就此传播开来。在这种情况下，ETC通常很自然是由一些早期倡导者组成，他们得到老板批准，可以花时间帮助其他团队学习Scrum。有时出现的障碍需要老板的支持，于是老板也要加入ETC。另外一种情况是在企业范围内实施Scrum时，当我们做出要在企业广泛的范围内实施Scrum的决定时，对ETC的成员组成可能更要深思熟虑。

ETC Sprints

因为ETC与Scrum开发团队一样使用Scrum，所以他们也通过sprints取得进展。每个ETC sprint以计划会议开始，以评审和回顾会议结束。这些会议和Scrum开发团队的那些会议完全一样，也经常发生同样的问题。来自KeyCorp（一家大型美国金融机构）的Thomas Seffernick，参加了他所在公司的ETC的第一次回顾会议。他回忆了团队如何犯下许多新Scrum开发团队会犯的一个共同错误——与演示工作中取得的进展相比，他们更愿意谈论计划。

ETC sprint的长度取决于ETC成员。通常来说，两周是最好的。这也是Ken Schwaber（2007.10）所推荐的sprint长度。Elizabeth Woodward是指导IBM大规模实施敏捷的ETC成员之一，他如下描述有关他们sprint长度的经历：

我们用过两周和四周的sprints。迄今为止，我们看到最成功的是两周的sprints。我相信其中的原因在于其“交付物”展示的良好势头和对外可见的进度。我们把各个社区的工作收集到一个简短的摘要中——它是一封能让人们在15分钟内就可读完的e-mail。

发起人和产品负责人

很多成功的Scrum案例都由一个明确的发起人启动和推进的，发起人是企业中需要对转型成功负责的一位资深人士。Salesforce.com非常成功的大规模转型就由公司的一位共同创始人Parker Harris发起。作为负责技术的执行副总裁，Harris处在一个绝佳的位置，可以来支持这样的一次变革——它会极大地改变Salesforce.com开发组织中每个人的工作方式。

发起人应与企业里正在计划实施转型的部门级别匹配。Salesforce.com需要公司管理层做发起人，这是因为其转型是整个企业范围的。如果是部门的转型，那么一个部门级别的领导是合适的选择。

发起人也是ETC的产品负责人。这意味着，有时ETC的产品负责人是对Scrum没有什么直接经验的人。不过没有关系，如同所有的产品负责人一样，ETC的发起人能够通过寻求其他ETC成员的帮助来履行这个职责。作为ETC最资深的成员，发起人将在转型实施的沟通中扮演重要的角色，但他不是孤立的，他可以得到其他人的帮助。

ETC的职责

ETC是一个工作小组，而不是决策委员会。在sprint计划时，ETC承诺完成一定量的工作，并在sprint结束时演示它们。然而，比这些ETC实际要完成的工作更重要的事情，那就是激发别人的兴趣。ETC成员靠自己只能取得一点成果，他们需要依靠组织的其他人去完成实施Scrum、走向敏捷所需要的大部分工作。变革管理专家Ed Olson和Glenda Eoyang 赞同这个观点：

“在一个自组织的系统里，领导的作用很重要，但创新和持久的变革依赖于企业中不同级别、不同位置的许多个体的工作。”（2001，5）

ETC最重要的职责之一是围绕Scrum的实施而创造活力。当然不是每个人都会为变革感到激动，但ETC需要点燃那些为成功实施Scrum而工作的人的热情。ETC成员如何做到这点？那就是展示自己的热情，以及参与正在发生的变革相关的建设性对话。为了激励企业中其他人，让他们参与到这类实施Scrum所需的创新和长期的变革中，ETC的职责包括：

• 清楚表达背景。ETC不只是勾勒出企业敏捷的前景。它既要帮助雇员们懂得变革的需要，也要培养他们做出改变的意愿。这就需要清楚表达变革相关的背景：为什么？为什么是现在？为什么用Scrum？ETC成员用他们的资历、个人公信力和更多的东西去帮助其他人理解这些问题的答案。
• 鼓励对话。美好的东西总在人们的对话中出现。争辩不同技术实践的好处，分享成功的故事，探讨失败原因以及一些其他的讨论会，可以产生不错的想法。
• 提供资源。实施Scrum需要花费时间、精力和金钱。例如，试图学着怎样才能变得更敏捷的人（比如说，如何在复杂的代码库上写自动单元测试）可能需要授权获得某些开发项目以外的时间做这些事情。由于ETC包括了参与转型的大部分资深人员，它有能力确保时间和金钱两者的有效支持。
• 设置合适的目标。具备清晰定义和确实可达目标的变革尝试能有10倍的可能性获得成功（引自：McKinsey & Company 2008）。ETC负责为转型设置合适的目标，并做好沟通。随着企业的改进，这些目标有可能（而且是应该）随着时间而变化。ETC可设立的目标包括，年度发布修改为季度发布，发布后缺陷率下降50%等等的目标。

额外的职责

除了鼓励人们参与转型外，ETC还有如下额外的职责：

• 预料和处理人们的问题。ETC要尽可能预计到哪些小组或个人会极力抵触Scrum所带来的变化，并积极和他们一起解决问题。在这点上，跨职能的ETC人员组成结构很有好处，因为它能让小组从多角度对待问题。
• 预计和消除阻碍。ETC成员负责消除任何实施Scrum的过程中横亘在企业前的障碍。但是ETC不光只是解决已知的问题，它还要能预计到有哪些阻碍，并在真正变成问题前解决它们。
• 鼓励对实践和原则的同时关注。实施Scrum包括吸收新的实践，和尊重新的原则。企业不能接受没有原则指导的实践，也不能采纳没有被实践检验过的原则。一个有效率的ETC要寻找实践和原则之间的不平衡的地方。如果其中一个被接受的速度快于另外一个，则ETC通过在速度慢的那方展开对话，投入关注与资源，让两者回到同一起跑线。

改善社区

改善社区（Improvement community，IC）是由这样的一群人组成——他们聚集在一起，协作工作，以便改善企业中Scrum的使用。IC的成立，可能是因为有人开始注意到ETC改善backlog中的某个事项，并决定一起工作实现这个目标。或可能是因为有人发现了一个还没有被ETC探查到的改善机会，并对之抱有热情。例如IBM有5个IC，分别专注于测试自动化、持续集成、测试驱动开发、产品负责人的角色和Scrum自身的通常实践。

另外，请记住ETC最大的目标是创造一个环境，让改善社区能确认自己的目标，并自发地组织起来处理它们。

改善社区Sprint

你可能对改善社区是否也能用sprints工作有怀疑。从ETC来说，每个IC可以选择自己的sprint长度，但两周是被推荐的。自发组建的IC通常有自己的产品负责人，社区成员选举决定把时间投入到自己热情度最高的改善点。另一方面，如果IC是为了响应ETC指定的目标成立的，则通常会以ETC的某个成员为产品负责人，并与之一起计划sprint。

就是说，改善社区的存在不是为了服务于ETC，它是为了服务于客户：创建产品或系统的Scrum开发团队。尽管ETC成员会作为某些改善社区的产品负责人，同时也作为sprint评审的正式产品负责人，你还是希望从感兴趣的开发团队中找到可以作为活跃的sprint评审参与者。而且，聪明的ETC懂得，只有给予改善社区在实现目标的过程中广泛的自主权，它们才会取得最好的结果。这意味着在实际中，即使IC是为ETC指定的目标而成立的，也能够自己计划优先级，在企业用特定方式进行改善的需求和成员们愿在这些事情上投入工作的热情之间做出平衡。

在sprint计划会议上，每个改善社区挑出一件或多件它承诺能在这个sprint完成的目标。若改善社区是为响应ETC的某个特定目标而成立，那sprint计划可以这样开始：到ETC的backlog中挑选一个事项，把它划分成更小的事项，然后放进改善社区的改善backlog。用一个例子来说明这种情况。

在前面表1中显示的ETC改善backlog有一项“建立一份培养ScrumMaster的内部计划”。在ETC把它放入改善backlog后的一个月，一个改善社区成立了，它使公司的其余人清楚地知道发起这个计划会有价值。社区发起时只有三个人，但这已足够向该目标前进。第一次sprint计划会议上，他们讨论了ETC的“建立一份培养ScrumMaster的内部计划”的目标，创建了用于实现该目标的改善backlog，可参考表2。

表2 改善社区“建立一份培养ScrumMaster的内部计划”的backlog

在sprint计划时，社区成员分担了表2的一些条目，并定义了实现这些条目的必要任务。例如，表2中的最后一项（与本地小组讨论以分享请人演讲的经费），社区定义了如下的任务：

• 搜索网络看看本地有多少用户组。
• 创建费用的预算表。
• 发邮件给内部的贡献列表，看看这里是否有人与这些小组有联系。
• 建立电话会议，介绍自己和我们在干什么。
• 主导电话会议。看看是否有小组已经把邀请演讲者的费用和另一个公司一起分担。看看谁能和我们一起研究这个问题。
• 和Susan一起检查预算并请求批准。

在开发团队的sprint计划会议上，社区评估每一事项，并决定能够承诺在sprint中完成的任务。两周后在sprint评审会议上，团队给产品负责人，也是ETC的一位成员，展示了一个本地用户组的列表，以及一个计划，该计划是关于每年和一个用户组一起工作两次，一起承担邀请全国知名的演讲者来此的经费。

大规模敏捷

通过收集国际敏捷大师Scott W. Ambler敏捷开发实践经验，整理出了大规模敏捷转型过程当中可以参考的一些模式和实践。（注：有关Ambler敏捷相关模型和理念，所有信息来自其网站www.Ambysoft.com）

主流的敏捷方法，例如Scrum，极限编程XP以及精益软件开发Lean等，其初衷更多的是面向小型的，在同一地点办公的团队，这一点从它们所提倡的很多敏捷实践也可以得到印证，例如每日站立会议，强调面对面的沟通等。目前由于来自产品质量、团队效率、按时交付等方面（正是很多敏捷实践所解决的问题）的压力，导致很多大型团队/企业开始考虑采纳敏捷实践。Agile Journal调查研究表明，有88%的公司，大部分超过一万名员工，开始在项目中使用或评估敏捷实践。敏捷已经是事实上的具统治地位的软件开发范式。但Ambysoft调查发现，只有53%的被调查者声称他们是在有效的“敏捷团队”，这意味着敏捷方法存在过度宣传、滥用或错用的情况，事实上即使采用敏捷，也依然存在大量的团队过程混乱、项目失败的现象。

敏捷绝对不是无组织无纪律的借口，事实上，主流的敏捷方法例如XP、Scrum，都定义和要求了相应的纪律和准则，甚至比起传统开发方式要求更加严格。需要指出的是，主流敏捷方法承认其并未提供足够的针对企业软件开发转型的指导，当团队成员数量超过一定规模时，需要针对敏捷方法进行很大程度的调整。同时，主流的敏捷方法只是对整个产品/项目生命周期交付中的部分阶段提出指导，更多的关注于开发过程主体，并非针对整个生命周期。因此针对这类企业进行调整和定制将花费大量人力物力，同时带来巨大的风险。

基于上述考虑，Scott W. Ambler提出了敏捷规模化模型Agile Scaling Model (ASM)的过程框架与演进路线。

敏捷规模化模型Agile Scaling Model (ASM)

敏捷规模化模型是Scott W. Ambler集多年大型组织/团队敏捷开发实践之大成者，它定义了一个路线，以指导组织和软件开发团队有效的采用和调整敏捷战略，以达成转型目标并规避风险。其路线图如下图所示。

图1 敏捷规模化模型（Agile Scaling Model）

敏捷规模化模型定义了企业敏捷开发的三个层级，可以理解为从项目规模、团队规模、地域分布等因素衡量时，一个企业自上而下不同层面的工作重点；也同样可以理解为当企业进行敏捷转型时的不同阶段，在不同敏捷成熟度阶段，相对应的关注点。第一个层级即敏捷开发核心，这是以敏捷宣言、敏捷价值观为主的实践，具体内容可参见前面的敏捷开发知识体系核心内容。很多企业也正是从这个层面上开始进行敏捷转型的。在这个阶段，更加关注团队与个人的相关实践，特征是价值驱动，通过日常的高度协作，自组织的团队，以交付高质量的产品。通常是面对小型的团队，团员都所处同一开发场所，而产品相对直观，团队关注度在于开发环节。第二个层级即进行有纪律的敏捷交付（Disciplined Agile Delivery），将主流集中在构造实现方面的敏捷，扩展到从项目的初启直到最终交付的整个交付生命周期之上，特点是在价值驱动之上考虑风险管控以提升成功率，自组织团队之上辅以适当的管控加以平衡，由构造实现延伸到整个交付生命周期。与敏捷核心相似，这个阶段同样关注于小型同一地点开发的团队。第三个层级即Agility@Scale，是基于有纪律的敏捷交付基础上的进一步扩展。扩展性体现在例如团队规模变大，地域分布式的开发模式，领域特性进一步复杂化，技术的复杂性提升，以及企业层面，如企业架构，战略重用，组合管理等，以及合规性要求在项目中的比重逐渐上升。当存在上述一个或多个规模化变量时，组织应如何调整战略以解决团队面临的复杂性问题，是这个阶段重点解决的问题。

有纪律的敏捷交付 （Disciplined Agile Delivery，DAD）

DAD是一个演进，持续的提供高质量的产品，在整个交付生命周期以风险和价值进行驱动，在适度管控的框架下以高度协作的、有纪律的且自组织的方式运转。干系人的主动参与以保证团队理解和实现需求以及变更，最大化的提供业务价值。有纪律的敏捷交付团队能够视情况进行过程调整以提供可重复的结果质量交付。
DAD是一个混合的过程框架，吸取、重用并增强了众多主流敏捷方法的优点，例如Scrum、XP、OpenUP等的策略与实践。一个典型的重用就是DAD扩展了Scrum活动生命周期（如下图所示），Scrum以需求优先级对产品储备进行排序，以持续的时间段（Scrum称为Sprint冲刺，而其他方法例如DAD称为iteration迭代）增量的交付，举行每日站立会议，并且在每个阶段（sprint/iteration）结束进行演示以获取关键干系人的反馈。

图2 Scrum生命周期关注构造阶段

DAD继承了上述Scrum的良好实践并加以采纳和增强，将其进行扩展到整个产品/项目交付生命周期。DAD的扩展具体体现在以下几个重要方面：

1. 显性的定义了具体阶段：主流开发方法更多描述的是构造阶段，但事实上它们都会在项目起始阶段经历一个初始的投入——Eclipse Way的“热身”，OpenUP的初启阶段，Scrum的Sprint 0，其他方法的Iteration 0等。并且最终都有交付阶段（如果能交付的话），例如Eclipse Way的“游戏结束”。DAD将这些事实上存在，但没有具体说明的甚至被忽视的阶段，显性展示出来。
2. DAD包含项目的初始阶段。在初启阶段的活动包括需求设定、架构设定、初始发布计划、项目预算、建立团队等。调查统计表明，敏捷团队在初始阶段的投入平均在4周左右，89%的团队会做一定的前期需求工作，而85%的团队会做前期的架构工作。
3. DAD包含项目的发布阶段，称之为交付阶段，以向市场发布您的解决方案，典型的活动包括beta测试、最终测试、用户培训、文档定版、上线试运行等。
4. 显性的指出生产活动。大部分敏捷交付团队对现存运行的系统版本有提供支持的责任，因而会收到运维团队提交的缺陷修正要求或者业务部门提交的增强的需求变更要求，通常这些要求会进行优先级排序并作为一个新的需求纳入产品储备中。但有些严重性极高的请求，尤其是严重的缺陷，可能要求开发团队停止手头的工作，即刻定位并解决问题，提供一个patch或是hot fix，并且将修正合并到此前的工作版本。Scott认为在交付生命周期中明确定义这样的活动会有利于对运维团队的支持。
5. 显性的增强了产品储备(Product Backlog)。产品储备转化为了工作项列表，有纪律的敏捷团队不只是将需求纳入列表，同时也要处理来自于运维团队的要求例如缺陷和增强。
6. 显性的包含了关键里程碑。DAD的一个重要方面是它不止提供例如Scrum的自组织，同时包括适度管控的框架。有纪律的敏捷团队是处在一个大型的组织当中，必须遵循组织的开发规范，与相关的团队之间进行信息交互，同时向高层管理者提供各种统计分析报告。

图3 DAD关注完整的交付生命周期

有纪律的敏捷交付DAD具备一些重要特性：

• 以人为本(People first)

敏捷开发以人为本，人的因素及其协作的方式是保障软件成功的最主要因素。这一理念也正是敏捷宣言的第一条，同样渗透在DAD的整体思想中。DAD强调由跨职能型人才组成的跨职能团队，以减少任务、文档的交接，以避免可能存在的信息缺失以及时间上的浪费，同时跨职能型人才更倾向于与他人紧密协作，分析技能与经验同时从他人那里学习新的技能。DAD的团队成员应该是自组织（self organizing，主动评估和计划自己的工作并迭代协作完成）以外，还应该是自律（self-disciplined，只对自己能完成的工作进行承诺并尽可能高效的完成）和自我意识（self aware，努力发掘对工作有利/有损的因素并相应调整）的。

• 学习为先（Learning-oriented）

高效的组织往往是那些给员工营造了学习氛围的，学习氛围包括三个重要方面：1、领域知识学习：了解、探求干系人的领域有助于理解、鉴别和更好的实现需求；2、过程知识学习：学习如何在个人、团队和组织等层面进行促进；3、技术知识学习：学习软件开发及软件工程相关工具与技术。DAD在建立学习氛围方面也提出一些建议，例如基于web2.0的社区和工具等。

• 敏捷（Agile）

DAD过程框架遵循并增强了敏捷宣言的价值和原则，强调干系人满意度以及提高投资回报率ROI，结合迭代的持续的交付以及测试驱动开发和回归测试以及重构等实践，强调使用自动化工具以支持相关实践并提升执行效率以及效果，这些原则也可以从下面的“混合过程模型”中也得到印证。

• 混合的过程模型（A Hybrid process framework）

DAD从主流敏捷方法以及其他传统开发方法中汲取经验和实践并加以优化和结合，许多实践在敏捷社区广为讨论，例如持续集成、每日站立会议、重构等，其他实践可能广泛使用但由于种种原因并未广泛为人所知，例如初启需求设定、架构设定、生命周期结束循环测试等。DAD的过程框架是一个混合模型，它借鉴了众多方法论中的良好实践并将这些实践进行吸收和相互融合，Scrum是其中最重要的一个来源，DAD采纳了例如按优先级排序的产品待办列表、代表干系人的产品负责人、定期产生可交付的产品等，同时替换了一些难以理解的术语，例如用迭代Iteration替换Sprint。其他吸收的方法论思想例如极限编程的持续集成、重构、测试驱动、集体所有权等；敏捷建模的需求设定、架构设定、迭代建模、持续文档、适度建模等；敏捷数据中数据库相关的实践等；看板中的可视化工作以及在过程中限定工作两个重要概念，这也是对精益开发的七个原则的重要补充。

• 解决方案而不仅是软件（Solution over software）

DAD过程将团队的关注点从开发软件转变为提供方案——恰好能为干系人提供真实的业务价值。软件固然重要，但解决干系人的问题并提供业务价值才是开发的最终目的，关注点的转变有助于帮助开发团队从整体角度看待软件开发过程。

• 目标驱动的生命周期交付（Goal-driven delivery life cycle）

DAD关注完整的软件开发生命周期，明确定义不同阶段迭代的关注点不同，通过明确的定义初启、构造以及移交阶段，并定义轻量级的里程碑，保证在正确的时间关注正确的事情。这一点与主流敏捷方法只关注构造阶段有显著区别，可参考比较前面Scrum生命周期以及DAD完整交付生命周期两张图表。DAD的交付生命周期有几个重要特性：（1）完整的交付生命周期，涵盖从项目初启到方案交付；（2）显性的阶段，DAD定义的三个阶段也同样体现了敏捷的3C（coordinate-collaborate-conclude）；（3）明确移交过程，DAD强调开发与交付的过程衔接以及对产品的运维提供支持，及时获取反馈并及时响应。（4）明确的里程碑，适度管控并有效减少风险。DAD是目标驱动的，组织和团队在项目的不同阶段目标是不同的，因而对过程需要加以适度调整以适应不同阶段的不同关注重心，为此DAD过程总结了如下表所示的目标映射以帮助组织和团队进行过程调整。

图4 DAD完整项目过程关注目标

上面的表格仅列举出DAD过程的一些重要目标，下面是具体针对初启、构造以及交付的每一个过程，结合3C的节奏对其进行详细描述，详细内容请参见Scott Ambler 有纪律的敏捷交付相关白皮书，在此不做详细描述。

图5 DAD初启迭代概览

图6 DAD构造迭代概览

• 风险和价值驱动（Risk and value driven）

DAD过程框架定义了轻量级的风险驱动策略，从项目伊始定位相关风险，例如干系人对项目愿景的认识，系统架构等。DAD通过吸取和扩展敏捷开发方法的最佳实践以减少风险影响：1、潜在可交付的软件，减少交付风险；2、构造阶段迭代结束时的演示，一方面获取干系人反馈，减少功能性风险，另一方面证明团队工作进展，减少政治风险；3、干系人主动参与，同样可以减少交付和功能性风险。DAD通过在交付生命周期显性的定义了轻量级里程碑，并明确在这些里程碑的考察点，以进一步消除相应的风险。

• 企业意识（Enterprise aware）

DAD过程框架力图营造企业和组织内部的生态环境，同时强调敏捷开发团队需要与企业内部其他部门与团队以及现存系统合作，并非工作在真空中。企业意识对团队而言至关重要，因为团队要做的是如何更好的为企业创造价值，而不是只做自己感兴趣的，例如选择尝试新的技术，并非由于这些技术最适合项目，而是因为这有助于丰富自己的简历；或是选择重头做起，用全新的工具，全新的数据源，无视组织内可利用的现有系统和IT基础设施。DAD通过提倡诸如以下几点帮助提升企业意识：1、企业资产共享，有助于企业内部对资产的认知和使用；2、加强组织生态环境，增进企业内部团队间了解和写作；3、开发式、诚实的监管，建立企业内部基于“信任，但确认并加以指导”的企业监管策略，充分信任团队和个人的责任感，同时通过相关工具提高对项目和进度的信息透明度。4、风险驱动，加强预警机制，具体内容参见“风险与价值驱动”特性。

Agility@Scale

敏捷开发最初是针对小型的在一起工作的团队，同时项目规模和应用类型相对直接，而现今敏捷所面对的组织和项目都更加规模化，Agility@Scale正是解决敏捷规模化时面临的复杂性问题。当企业经历了敏捷核心到有纪律的敏捷交付的转型之后，规模化的因素将逐渐凸显，每一个因素都会带来一定范围的复杂性，团队结构以及工具环境都需要加以调整以适应这一情况。

团队规模化因素表现如下图所示，当规模化、复杂度上升到一定程度时，协作效率突然变得极富挑战性，同时信息流转变得困难，对开发过程管理及沟通提出更高要求，同时需要通过一定技术手段或实践方法来消除急剧上升的开发风险，例如采用构建原型、系统建模以及仿真等方式保证质量。当涉及到众多现有系统，扩展性良好的架构设计固然重要，同时需要考虑跨部门跨流程的协作问题。此外，企业不同产品、系统彼此之间市场定位、战略规划以及产品组合管理等都是需要进入企业/组织视野的。

图8 Agility@Scale

Scott W. Ambler用一个Agile Online Bartering的例子来描述大规模的敏捷过程（参见”IBM agility@scale: Become as Agile as You Can Be”）。在此案例中Scott描述了分布式的团队在处理一个复杂系统项目时的实践，包括团队分布，团队分工，分布式团队之间的沟通与协作包括其频度，每一个迭代所关注的事情，迭代结束所进行的演示的目的及取得的结果，对合规性要求的考虑，持续集成的方式，以及部分采用的工具。这样一个案例，可以作为组织在面临类似项目时的一个参考。

Scott同时对企业进行大规模敏捷实践提出了相应的建议：

1. 提高才是目的。敏捷做的再好也不会有人给你颁发金牌，除非是因为高效的提交了项目/产品，敏捷技术能在这一点上帮到你，但不要忘了传统社区、传统方法论同样有很多非常好的行之有效的方法，不要由于它们不属于敏捷的范畴就进行排斥。
2. 要有计划。要帮助你的过程改进成功实施，你必须首先决定你的目标是什么，当前状态以及面临哪些挑战。
3. 获取经验。用一个或数个中等风险的敏捷试点项目以获取组织层面的经验，并培养相关专家，同时做好思想准备，试点项目不可能尽善尽美，遇到一些问题是正常的。
4. 显性的管理过程改进的付出。定期的总结和识别潜在的改进，并付诸行动，是广为证实的经验，明确的记录改进进展更容易帮助团队取得成功。
5. 对员工进行投资。企业/组织需要训练、培养、指导员工敏捷的理念，过程，时间以及工具。先在试点项目试点团队进行适度培训，再由此向整个组织层面推广，不要忘记包括高级领导、项目管理者以及任何相关干系人。

这篇关于解析敏捷软件开发知识体系 分享国外敏捷转型实践案例的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---