Agilent 的敏捷开发转型之旅
敏捷开发如何帮助 Agilent 减少错误、提高质量和产品产能
开始使用免费的敏捷路线图模板
简化您的项目，轻松规划、跟踪和管理跨多个冲刺阶段的工作。
Key Takeaways
Agilent’s Agile transformation improved release predictability, quality, and team morale through process and cultural change.
Key steps included adopting Jira, Agile training, new roles, and continuous improvement practices.
Metrics like burnup charts and capacity modeling enabled better planning and delivery.
Invest in tools, training, and cross-functional collaboration to drive successful Agile transformation.
2015 年，Agilent 的软件与信息事业部遇到了麻烦。在一次重大新产品发布期间，该团队将错过发布日期。这不是第一次，该部门只有约 20% 的版本按时发布。
错过发布日期给软件团队造成了巨大压力。Agilent 软件与信息事业部副总裁兼总经理 John Sadler 说：“当团队承受压力时，他们就会做出错误的决定。他们牺牲了质量，最终却要在后端为此付出代价。总体而言，该团队士气相对低落，很难按时交付任何东西。”
Agilent 的软件和信息事业部面临的部分挑战是，该事业部的 150 名员工分布在两个大洲，并与另一个大洲的承包商合作。这是一个由工程、营销、质量保证、技术支持和销售专业人员组成的庞大部门。该公司需要建立新的团队实践，以帮助其更快地交付价值，提高质量和可预测性，并更好地应对变化。简而言之，他们需要敏捷开发转型。
开始敏捷开发转型
2015 年，Agilent 规划了敏捷开发转型，目标如下：
关注可预测性
制定可靠的发布节奏
创建可重复的交付周期
推动持续改进
敏捷开发方法将质量放在首位，将可重复的节奏放在第二位，将范围放在第三位。Sadler 说：“如果团队不遵循这些优先事项，他们通常会把范围放在首位，时间线以截止日期的形式实施，然后质量就差强人意。”
Agilent 希望建立敏捷开发流程，将优先事项纳入其软件开发中。将持续改进确立为首要价值观意味着文化转变，为转型创造了背景。将质量放在首位意味着提高外部和内部客户的满意度。为了满足客户在现场的期望，Agilent 愿意牺牲范围。
第二个优先事项是该部门创建一个可预测的发布周期，该周期可以随着时间的推移进行微调。更短、更可靠的开发周期意味着团队将尽早避免问题并降低风险，以便有足够的响应时间。
敏捷开发转型：循序渐进
经 cPrime, Inc. 许可改编
敏捷开发培训是下一个优先事项，其目标是教授敏捷开发原理和概念，并建立共同的术语。cPrime 概述了其企业敏捷开发治理配方 (RAGE) 模式，该模式概述了关键仪式，包括发布计划会议、集群 Scrum 会议、集群 Scrum 产品负责人会议、发布待办事项列表整理会议、发布审查和发布回顾会议。
Agilent 还确立了区域产品负责人角色和项目经理角色，并使用燃尽图来衡量进度。Agilent 还采用了轻量级决策技术，执行了仪式，使用了敏捷开发 Scrum 工件，并采用了其他敏捷开发实践。
敏捷开发在行动
2015 年 11 月，Agilent 的软件和信息学部门举办了 Sprint Zero，这是一次为期两周的敏捷开发规划会议，共有 14 个训练有素的团队参加。为 OpenLAB 色谱数据系统制定了为期八个月的产品发布计划。
Sprint Zero 活动包括三个类别：
通过演示文稿和海报向团队介绍业务和技术目标、驱动因素以及 OpenLAB 的高级要求。
使用新学到的技术来制定需求并评估故事、长篇故事和缺陷。
在发布计划看板上布置故事、长篇故事和缺陷，并标记所有跨团队的依赖关系。
Agilent 很快发现，他们的敏捷开发改进不仅限于试点项目。最早的成功指标之一是内部指标。Sadler 表示，“鉴于我们必须与其他 Agilent 部门合作，因此，按照我们说的去做非常重要。”
Agilent 也看到了外部改进。客户反馈在 Agilent团队提高对市场变化的响应能力方面发挥了重要作用。通过在开发过程的早期阶段接纳客户，Agilent 提高了软件质量，同时降低了市场和集成风险。
Agilent 的洞察信息之一是将升级故事包含在每部敏捷开发长篇故事中。Agilent 软件质量总监 Babita Jain 和软件集成经理 Stefan Weiss 领导了转型实施，并帮助团队了解了项目的总体范围。Jain 说道：“除非它包括升级，否则我们不认为长篇故事已经完成。”
敏捷开发转型不仅提高了质量，还提高了可靠性。2016 年，OpenLAB 色谱数据系统按时交付。自敏捷开发转型以来，Agilent 一直稳步交付软件，现场报告的缺陷有所减少。
衡量成功
Sadler 说道，“Agilent 以低现场故障率和较高的客户忠诚度来定义和衡量其敏捷开发计划的成功。”留住客户也是关键。在生命科学行业成熟且竞争激烈的市场中，客户流失是一种风险。向老客户销售新系统的能力至关重要。
以下是 Agilent 基于 Jira 的产能模式支持的四个关键指标：
燃尽/燃尽图
Agilent 之前以工程时数、人工日或故事点来衡量工作量。现在，每个人都可以使用燃尽图来跟踪已完成的工作量和总工作量。燃尽图显示还有多少工作要做。
向市场交付的产能百分比（有效负载）
建模和跟踪产能的能力在 Agilent 衡量成功方面起着至关重要的作用。借助 Jira，Agilent 能够构建详细的产能模式。“通过这种模式，我们能够在规划阶段告诉营销部门在发布时需要处理多少故事点。营销部门可以对待办事项列表进行排序，以适应这种产能。”Sadler 说道。
交付修复的数量和中位时间
产能模式提供了更精细的视图，使 Agilent 能够了解修复现场报告的关键或严重缺陷所花费的产能与质量团队发现并报告的缺陷所花费的产能。
修复手动测试发现的缺陷所花费的时间百分比
产能模式可帮助 Agilent 衡量开发客户看重的功能所花费的时间与维护或维持现有产品所花费的时间。
在短短三年多的时间里，该部门专注于增值工作的产能比例翻了一番多，从 30％ 增加到 65％。在新的敏捷开发方法的推动下，随着软件质量的提高，以后需要修复的缺陷也减少了。
在开始敏捷开发转型流程一年后，Agilent 团队成员描述了各种前后对比的情景：
之前：绩效是以工程时数、人工日或故事点来衡量的。之后：大家商定如何衡量速度和燃尽图。
之前：接受过不同程度敏捷培训的团队对长篇故事、故事和子任务有不同的定义。之后：组织中的每个人都使用共同的语言。
之前：Scrum 主管编写代码，主持团队会议，并权衡功能优先级。之后：Scrum 主管是向产品经理汇报的任务主管。
之前：存在缺陷的功能可能会获得批准，从而将缺陷带入后续开发阶段。之后：“完成”的通用定义可确保在下一次冲刺之前消除缺陷。
之前：问题通常发生在最后一刻，导致恐慌和严重的延误。之后：所有团队使用一套共享工具可防止意外情况并有助于保持专注。
之前：没有衡量团队工作产能的工具。之后：已就如何预测和衡量每日产能达成共识。
Agilent 的敏捷开发未来
就像任何重视持续改进的文化一样，Agilent 的敏捷开发转型也绝非完美。接下来的步骤包括继续缩短周期时间，并提高从市场反馈中获得早期洞察信息的能力，这是 DevOps 指标的一些关键要素。
Agilent 已经大幅缩短了周期时间，将每年的发布时间分为两个六个月的周期，但是该公司每年都会将发布版本商业化。该公司计划将周期时间再次缩短一半，改为按季度发布。
让客户尽早并经常参与开发过程也是持续改进的主题。Sadler 报告说，他的团队发现，市场反馈中有明确的证据时，在关于产品范围的讨论中，相互竞争的利益集团之间的仲裁就会减少。保持现场客户的质量和可用性是持续的优先事项，与用户的持续互动有助于保持公司的优先事项：质量第一，然后是发布节奏和范围。
吸取的经验教训
Sadler 将成功归功于他的团队，包括领导者 Jain 和 Weiss，他们将敏捷开发视为推动快速持续改进的一种方式。借助 Jira 和 Confluence 等合适的工具，团队可以将工作整合到一个地方并衡量进度。
Agilent 发现，敏捷开发转型需要赞助商监督研发、入站营销和质量。Sadler 说道：“如果你不能三个都改变，那你就不会成功。光靠研发是无法实现敏捷开发转型的。”最重要的不是这些职能内部所做的工作，而是它们协同工作的方式。
Agilent 还发现，必须暂停这样的假设，即对客户需求的完美理解在于建筑物内部。一种敏捷开发方法是按照可靠的节奏发布产品，然后直接接收客户反馈。这种方法需要一种态度，即发布日期是不容更改的，一到时间，团队就要按时发布。
最后，Sadler 表示，敏捷开发框架使问题变得显而易见。例如，敏捷开发暴露了产能差距。它揭示了流程中导致延误并揭示质量错误的非增值部分。从瀑布式方法转变为敏捷开发方法不仅需要改变团队的工作方式，而且还需要文化转变。敏捷开发推动着一种非常具有感染力的持续改进文化。