案例分享：敏捷培训和轻量级落地实践指导在硬件开发中的应用

一家世界500强企业的硬件产品部门希望给一个开发固件(Firmware/FPGA)的团队导入敏捷开发方法。了解到该硬件产品的固件开发涉及到硬件产品部门的上游软件团队和下游的硬件团队，整个硬件产品的开发规模在60人以上。而且固件开发团队已初步开始了敏捷方法的实践，但由于缺乏足够的敏捷知识和实践经验，产生的效果有限，特别是与上游的软件团队的沟通协作问题一直没有很好的解决。团队内部存在孤岛式的开发现象。管理层和团队希望派一个人参加敏捷培训课程，回来后指导团队的敏捷实践。

通过前期用户需求的调研，我们提供了两套方案：一是指派一个人参加培训课(注：有一定的盲目性，不知道培训学到的敏捷方法是否适合该部门开发团队的特点？)；另一个是让整个团队成员参加有针对性的敏捷培训再加上轻量级、定制化的大规模敏捷SAFe方法落地实践的专业指导。

这两套方案都给用户做了详细说明。前套方案虽然培训后参加考试可以拿到证书，但回到公司面临敏捷方法导入的实际问题时，因为个人认知，专业和经验的局限性，仍然会束手无策。后套方案让固件开发团队所有成员参加培训可以减少敏捷方法导入时的团队认知障碍，加之外部教练的现场指导，可以根据临场随时获得的反馈和问题对SAFe方法的导入及时调整，取得的效果对部门和团队收益更大。用户仔细斟酌后决定采用后一种方案，事后也证明这种选择是正确的。

培训前用户在了解培训课件大纲的基础上，希望增加看板知识的内容。如此同时，课前也为团队提供了许多大规模敏捷SAFe的学习资料。

课程开始时让团队成员讨论并列举工作中的关键痛点，希望老师能在课堂上针对团队的具体痛点帮助提升认识并找到问题的解决方案，共同达成培训课的目标和成果。

由于60多人同时工作在同一产品上，除了固件开发，还涉及到软件和硬件开发。产品开发的复杂程度暴露出固件开发团队存在的突出问题：

• 为了跟上硬件发布，有时急冲冲地计划需求和抢速度。

• 与上游的软件开发缺乏沟通，不知道他们正在开发的情况，如开发需求进度是否对齐，来自软件开发团队的突发性需求等等。

• 应对需求变更和修改缺陷没有灵活或足够的时间或空间。

• 在开发流程、跟踪进度、识别瓶颈等方面上缺少透明度或可见度。

• 工作在不同项目上的团队成员之间各自为政，缺少互动如同行评审、相互备份和支持等。

培训课上除了讲授SAFe核心价值，精益敏捷价值和原则，实践方法，技能等基本知识之外，还根据整个硬件部门产品和固件开发团队的特点，结合SAFe业务敏捷七大核心能力，如团队和技术的敏捷力，使学员认识到解决痛点问题的关键点在于：

整个产品开发实际上涉及到软件团队、固件团队、硬件团队之间的沟通和协作。SAFe ART团队作用在于能在固件团队、硬件团队、软件团队的干系人之间建立起定期沟通和合作机制，保持整个产品的软件、固件以及硬件的需求开发价值流和发布时间的一致性。

针对该硬件产品开发的复杂程度，老师讲授了一个复杂产品或解决方案的开发如何围绕价值流来组织各个团队。固件开发团队在SAFe价值流的组织中的角色定义为：复杂子系统团队或组件团队。它围绕特定子系统进行组织的团队，这类子系统需要深厚的专业技能和专业知识提供支持。

PI (Planning Interval)规划会议是一项有固定节奏的活动，可作为敏捷发布火车的心跳，确保敏捷发布火车上的所有团队拥有共同的使命和愿景。

帮助学员理解在探索不确定问题的解决方案时，固件团队应如何建立起与软件团队和硬件团队之间的良好协同机制，例如，通过SAFe的PI规划会，做好需求规划、需求排序、迭代周期保持一致，不过度承诺需求交付的同时预留20%工作时间应对突发需求变更和突发事件的处理。

针对开发流程、跟踪进度、识别瓶颈缺少透明度或可见度的问题。讲授如何理解SAFe的团队看板价值流的概念来创建固件团队开发流程的看板，增强日常工作可见性或透明度。通过看板跟踪进度指标，如需求交付周期(Leading time)，即卡片从需求分析开始到完成交付的时间；卡片老化时间(Aged time)，即卡片在某个流动状态时停留的总时长；识别瓶颈指标，如在制品(Work In Progress)，即在某个流动状态时正在工作的数量。

SAFe的内建质量是贯穿整个企业组织各个领域的质量建设，包括业务职能部门，软件应用，IT系统，硬件和网络物理系统。不只是专注软件应用的内建质量。针对团队成员之间缺少互动，如同行评审、相互备份和支持等问题，帮助学员理解什么是SAFe内建质量的原则和实践，如学习左移，代码集体所有制和T型人才，同行评审和结对，制品标准和完成标准，以及工作流自动化等。

两天的强化培训，大家感到收获满满。最后，老师建议团队回到工作中要大胆实践，团队自我管理勇于探索实践适合团队自身特点的敏捷方法，三个月后老师再进场指导团队，对团队实践大规模敏捷SAFe中碰到问题和疑问进行研讨......

三个月后，老师作为敏捷教练回到固件团队现场进行指导。轻量级指导是两个一天的问题解决研讨会。针对三个月来团队实践遇到的实际问题，与团队成员一起探讨问题的答案。

研讨会上，了解到团队要承担一系列产品的固件开发。面对的内部用户繁多，需求繁杂，紧急性的需求和缺陷等问题开展讨论。

例如，以前团队成员开发设计固件软件(FPGA)是各自为政，单兵作战，相互不了解各自所做的事情，需求管理分散。研讨会上引导团队达成问题解决的方案：一方面来自海外产品经理的不同项目的需求和另一方面来自团队的需求统一进入产品待办列表进行管理。以固件产品开发为导向，对不同项目的需求团队成员一起分析、细化需求。增强横向跨领域T型人才发展。

研讨会上，引导学员采用SAFe特性优先级排序方法，即Weighted Shortest Job First (WSJF，加权最短工作优先)。例如，以前团队几乎没有排优先级的意识，更多的是单从依赖性考虑。SAFe从更全面的维度考虑价优先级，如用户商业价值、时间紧迫性、降低风险或获取机会，以及工作大小或时长考虑计算出分值，也就是延迟成本最大能并在最短时间内交付的需求优先考虑或者先做。要求大家对已就绪的或梳理好的一组需求按照相对大小原则一起打分，然后按照分值大小排出需求或特性的优先级。

研讨会上，还了解到海外产品经理已根据SAFe的精益产品组合管理(LPM)的实践方法制定出优化现有产品的战略主题和史诗。老师结合这点在研讨会上简要地概述SAFe的精益产品组合管理(LPM)的实践方法(注：LPM培训课程有更详细说明)，帮助固件开发团队全局性地理解和拆分需求，如下图所示。产品经理通过产品路线图将战略主题和执行联系起来传递给团队。团队通过每月迭代的初始计划和每周详细计划，如将Epic拆分成Features以及Tasks，回答了拆分过程中的许多具体问题，团队成员有了满意的收获。

在第一次研讨会上，发现团队在JIRA工具上的开发工作流定义尚不完整，通过展示以前实际用户的看板示例，引导团队分析优化现有看板存在的问题，团队成员能够很快地理解并决定改正。

在修改了JIRA看板工作流程后，第二次研讨会上团队展示了修改后的更适合固件开发特点的看板工作流，如下图所示。(注：看板做了必要的技术处理)

回顾两天的敏捷培训和问题解决(Problem-solving)工作坊， 当问到给大家带来什么效果时，团队成员给出的回答是：

通过学习和实践相结合的方式，比较单纯学习理论知识，能够更好的学以致用，知行合一，对概念的理解也能够更加深入。

• 工作氛围更加愉悦了，员工的满意度提高了。如现在出去旅游度假时，自己的工作任务有其他同事来承担，再不用担心休假时自己干的工作受到影响，能够很开心地度假和游玩。

• 质量提升了。现在固件开发团队所有项目的需求都进入同一个大漏斗，即产品待办列表。大家一起讨论需求的优先级和细化，相互了解对方领域知识，提升了各自的开发能力。各个项目的代码集体所有，有利于同行评审和相互验证，发现更多的质量问题，质量比以前更好了。

• 团队成员的生产效率和以前相比有了一定的变化。以前每人负责各自的项目开发，有时会忙闲不一。现在不分项目以产品为导向，每个人都可以开发不同的项目，相互支持，项目开发生产效率相对以前提升了。

关于缩短上市时间。由于是对现有产品的优化，海外产品经理已制定出产品路线图和相关发布的里程碑来协调软件、固件、硬件开发的进度保持一致性，是否缩短上市时间有待后续进一步观察。

我们与客户约定，三个月后再回访他们，帮助客户进阶升级到更高端的SAFe实践方法。

敏捷方法的导入不能盲目和僵化，是采用Scrum？Kanban？还是SAFe？，应该倾听专业敏捷教练的建议和指导。学员培训完回到公司实践敏捷遇到各种问题时，也迫切希望有实战经验的专业教练临场指导。我们也在探索一种创新的模式，即在向学员讲授敏捷思维方式和新的工作方法的同时，采用短、平、快的轻量级方式在客户现场进行一、二次的临场专业指导，帮助他们尽快地找到与自己产品开发的实际情况相匹配的敏捷方法。对于这次尝试客户领导层的反馈说：“效果是超预期的好。”

如果你想进一步学习大规模敏捷理论知识和实践，欢迎报名全球知名的SAI机构提供的SAFe培训认证课程，也欢迎加入我们的敏捷社区。

点击链接：Leading SAFe 6.0 大规模敏捷 上海面授2024春季班火热报名中！