企业将敏捷实践用于开发之外

将敏捷实践运用于整个企业是有益的。若干近期发表的博文探讨了在开发之外使用敏捷的可能性。Gartner 的 Jake Sorofman 写了一篇题为《敏捷是否是最后留存的竞争优势》的文章，点出了在企业中使用敏捷方面他所看到的趋势：

我们都知道这一哲学改变了软件开发实践。而我们刚开始了解的，是敏捷实践正在向业务的其他方面蔓延。

之前 InfoQ 报道了在企业中如何将敏捷实践运用于市场营销（敏捷市场人员在 SprintZero 研讨会上创建了一个敏捷市场宣言）和销售（销售和敏捷，油和水? ）。人们逐渐清晰地认识到，对企业而言敏捷能够为软件开发之外的活动带来益处，Jake 对此写道：

（……）敏捷实践是我们对任何事物的变化本质的简单回应。它帮助我们面对现实：一切都在飞速前进，真相往往是不透明的，而对于业务方面尽管我们允许在小事上犯错，但在大事上必须正确。实际上，在敏捷中，通过小处试错我们往往能够使大事正确。

他展示了精益创业和敏捷如何通过专注于向客户持续交付价值而结合在一起：

在新业务孵化遍地的世界里，我们谈论着“最小可行产品”，并将其称作追寻真相的探针，它定义了你可以交付的最小价值增量。幸运的是，这引领我最终认识到：敏捷的广泛运用带来了最小化的价值生命。

在博文《企业敏捷：在开发之外扩展敏捷流程》中，Mendix 的首席技术官 Johan den Haan 分享了他对于在整个企业中采用敏捷实践的理念。他首先阐述了对企业而言采用敏捷有什么不同：

只有整个组织机构都采用这样的思维方式，敏捷才有可能成功：在敏捷企业里，组织机构的市场和销售方与产品开发达到平衡。在敏捷企业里，整个业务通过一种能快速响应市场变化的方式来组织。各部门完全与总体价值流整合，形成了端到端的敏捷。

他描述了敏捷实践能够为市场营销提供的价值：

以稳定节奏频繁发布使得市场营销更容易创建他们自己传递消息的节奏，但更重要的是它能够尽快将价值带给客户。

敏捷软件开发使频繁交付成为可能。为了获得对这些交付物的反馈，Johan 建议服务也应该采用敏捷实践：

（……）服务也应该在早期纳入流程。确保你能听到他们对产品的反馈，将其引入早期的迭代 /sprint 会议，并让他们有机会在新版本实际发布前就开始付诸行动。

Johan 通过描述你如何能够在企业中采用敏捷来总结他的博文：

采用敏捷方式入手！不要通过创造政策等手段来自上而下的开始。从一支而不是多支团队入手，一旦你拥有多支“正在进行”敏捷的团队，你可能就需要额外的努力来协调他们了。这时你或许只能从由 Scrum 会议组成的 Scrum 入手了。如果你团队里的开发流程采用了敏捷，那就开始扩展你对“完成”的定义。向其他部门逐一推行（采纳敏捷）并确保高级管理层能支持向整体敏捷价值流的转变。

在《向软件开发之外的团队介绍敏捷技术》一文中，该作者（也是一位敏捷教练） Rachel Davies 分享了她在开发之外运用敏捷实践的经验：

我们公司成立的时候以 XP（极限编程）为核心软件开发方法。公司的成长伴随着产品的成功，现在我们除开发部门以外的若干涉及日常工作的其他部门（例如财务、基础设施和结合了人力资源与设备管理的“人 & 位置”）都有兴趣沿着同样的（敏捷）路线管理好他们自己的工作。

她描述了如何向非软件开发团队引入敏捷：

我们慢慢构建（敏捷机制）而不是用敏捷理论和原则来轰炸这些团队。我们以简单的草图入手，讲述如何将每周的工作展现在墙上并用超级便利贴将其归拢在一起（……）围绕着贴板，我们维持一个简单的会议周期：将下一周的工作列举并排序，每天进行站立会议并进行每月回顾。

在 Agile 2012 上，Rachel 组织了一场开放的讨论。在那次讨论中，她针对如何发起敏捷交流列出了以下几点可供参考的实践建议：

• 大家围着啤酒桌或坐在咖啡馆里互相阐述自己对敏捷价值的理解
• 引入建导技术 (facilitation) 使会议变得更有趣
• 让管理人员担任布道者
• 安排一次对敏捷软件团队的参观
• 寻找一位开放并好奇的人
• 构建团队信心——使每个人都成为支持者
• 为开发之外的团队安排一位敏捷教练
• 制作一个有趣的电梯演讲
• 用有趣的东西来唤起兴趣

查看英文原文： Applying Agile Practices in Enterprises Outside Development