转载

企业敏捷扩展的四项必备规则

敏捷方法早就证明了其在同地协作的小型团队中的效率，该方法能完美适应以灵活和速率著称的团队。但是，当超越团队层面向组织规模扩展时，敏捷实践就需要面对企业发展现状，比如分布式团队、多组件项目和传统资源管理。

事实上，无论组织多大型、多复杂或者多分布，都能采用敏捷实践，尤其是Scrum。Scrum实践在超过100人的复杂企业中的伸缩性非常好，能够在组织转变过程中给予足够的重视。下面是在多团队企业层面实施敏捷时需要遵循的四项规则。

#1.明确定义大规模敏捷意味着什么。

对敏捷开发的误解导致许多组织以一种绝对错误的方式冒冒失失的一头扎进敏捷，进而无法避免这种误解，甚至更糟。一些与敏捷相关的误解主要是人们认为Scrum无法准确提供支持组织规划的项目进度表。然而，事实是Scrum开发有足够的前期规划和分析方法，并且在支持组织规划方面，比其它大部分开发方法更有效率。

首先，敏捷实践易于管理和优先级的特征范围，使其能够轻松地利用固定资源满足最后期限，让项目成本更具有可预测性。其次，基于优先级完成特性，而不是将它们捆绑到规划阶段，这样有助于消除最终你想要变更、扩展或者取消已经完成的功能的风险。

大规模Scrum包含了所有常规Scrum的可用特性，和已经证明了的在多团队、多站点的大型环境中能够有效连接Scrum构建模块的具体要素。举个例子，假设客户参与了规模扩展；随着Scrum团队希望从客户候选人中获得不同的技能集，可能需要建立一个独立部门负责管理客户参与。

另一个例子是，在一次迭代中集成所有团队致力于一个产品的输出，实现一个潜在的可交付的产品增量。这可以通过以下方式实现：

跨越组织协调‘完成标准’，实现为每个团队完成的故事、特性和缺陷定义验收标准。
建立Scrum的Scrum会议，帮助解决跨团队问题和依赖项。每个Scrum团队应该指派一个代表参与联合冲刺评审，从而提高项目进度的整体可见性。

#2.挥手告别瀑布式的习惯。

即使是对敏捷实践有着明确的理解也不一定能从试图修改Scrum基本规则，以适应长期形成的瀑布式习惯中拯救组织。并且这种做法是极其危险的，因为它面临着最终实施两种方法最糟糕的特性，摒弃两种方法的优势的风险。

敏捷可以通过持续的需求分析、设计、构建/集成和测试获得。此外，所有这些活动的界限都是模糊的，所以任何在里程碑处试图映射到阶段的尝试都是无效的。不过，仍然有一些组织满足于Scrum的‘前期分析，前期设计/持续开发’带来的改变，并在开发工作中重新引入瀑布流程。我曾经参与过一个项目，该客户依赖Scrum来提高他们正在开发的软件产品的价值。不幸的是，公司不愿意放弃他们使用多年的正式需求审核程序。这样一来，尽管他们确实提高了团队性能，但是在每个冲刺交付中他们还是在增加特性值方面滞后。只有公司允许灵活创建和管理产品待办事项列表，他们才能保证在每次冲刺会上交付有价值的产品增量。

另一个常见的错误实践是，当在多个团队之间分裂大量共享的产品待办事项列表需求时，沿着任务线而不是功能切割用户故事。更好的方法应该是考虑将每个切割片作为更大功能的一个独立可验证的功能片，实现其在所有跨应用架构层的实施，其中应用架构包括：用户界面、业务逻辑、数据访问层和数据库。

#3.理解敏捷方法不是魔法。

转向敏捷无疑可以通过提高软件品质和改善客户关系帮助企业潜在地提高他们的业务底线。它同样可以帮助组织工作，但是它不会教导团队的每个成员，使他们成为各自领域的尖兵。走向敏捷需要耐心，因为需要加强团队协作强度；一个跨功能的团队在开始大步向前之前需要运行数个试点冲刺。此外，团队所有成员需要学习新的过程技能，这会在初始阶段减缓团队的进度。

建立敏捷团队和过程仅仅才开始了一半；为了协作和稳定运营，仍然有很多工作需要完成。应对这一挑战的一个方法是与具有成熟Scrum使用者的团队协作。例如，我们的一个客户在项目交付时处于敏捷转换过程中。他们在整个企业建立和运行敏捷团队，并期待获得稳定的速度和可预测的发布。当与项目过程进行同步时，我们发现该公司具有产品待办事项列表管理和发布计划的问题。好消息是，发现问题是整个过程中最复杂的部分。仅仅经过两个冲刺后，公司成功加强了团队，改进了计划并且给利益相关者提供了一个更好的如何发展其产品的主意。

同时请不要让敏捷成为管理依赖的拐杖。当然，管理者将会为环境设置好整体基调，通过平衡一个稳定系统传统的管理方法，和一个自组织系统更具创新的管理方法，在团队的形成、发展、改善中扮演一个重要的角色。但是，当涉及到监管自我管理的跨功能的Scrum团队时，传统项目经理的世界将会发生翻天覆地的变化。因为他们需要面临更多的挑战，比如学习新项目预算确定流程，团队人员配置，项目进度建设和协调其它部门的援助和支持。在Scrum中，团队自己决定每次冲刺时他们需要承担承诺的范围。留给项目经理唯一的工作就是利用Scrum过程的透明度，确保没有过高或者过低的承诺发生。

#4.以人为先。

Scrum不是一种开发方法，而是帮助组织工作、提升团队效率的一个框架。Scrum团队是以使成员能够加速到他们最大的生产力的方式组织起来的。为了实现这个过程，需要结合许多要素。

工作的组织 ：100%奉献到特定团队中去，在冲刺阶段不间断的运行，没有强迫加班的可持续发展的开发步伐可以避免在员工效率，质量和生产力上的损失;
工具 的可用性 ：Scrum的力量来自团队成员之间的协作，这同样适用于远程或者离岸的大规模产品开发。因此，需要协同作业工具来支持每个团队成员发展的可见性，从而实现相互的承诺。当然也有很多专门设计的解决方案——从即时通讯解决方案，用于共享信息的Wiki服务器和文件库，到网络摄像头和产品演示的共享桌面。这些方案将不在同一地点工作的团队成员，异地产品经理和离岸团队连接起来。
企业培训 ：赤裸的热情和转型的承诺还不足以使研发团队和项目经理在敏捷环境下有效率地工作。为了始终满足在组织范围内已经建立的高标准，应该发展一个长期稳定的企业培训政策，为团队成员提供初始和持续的发展培训。
卓越的技术 ：专注于实现最佳团队速度和快速交付可工作的功能时，丝毫不应该向交付代码的质量妥协。应该确保Scrum团队的所有成员精通——或者至少熟悉——这种卓越技术的实践和工具的使用，比如TDD，同行代码评审，持续集成和自动化测试。

敏捷软件开发宣言以个体和互动高于流程和工具这样的价值观更好地实现软件开发开头。在这方面，能立即考虑到的方面是跨研发团队以及团队成员之间的交互。但是，这同样有助于将与客户的交互带入一个全新的层面。加强客户参与需要团队适应客户当前的情绪、态度、需要和需求。客户将要表现出不满的迹象时，为了维护未来客户的参与力度，团队可以，比如说，从首选的高交互讨论形式更改为更内敛、访谈式的讨论形式。

最重要的是，始终着眼于客户。最后，员工生产力和客户满意度才最有助于实现组织层面的敏捷目标。

关于作者

Ivan Kot 是Itransition的部门经理。他最初的职业是开发者，在web和移动研发项目中担任不同的职位，并最终将注意点转移到项目经理和团队协作上。他目前的职责是项目监督和与企业客户建立良好的业务关系。作为一名经过认证的Scrum Master，Ivan能够确保项目管理的完成遵守了指导方针和最佳行业实践。他每天的座右铭是，“如果要做，就要做到最好。”

查看英文原文： Four Must-Have Rules for Scaling Enterprise Agile

正文到此结束