敏捷框架之SAFe6.0(中)

大家好，我是rainbowzhou。

在上一篇文章中敏捷框架之SAFe6.0(上)中，我分享了我参加敏捷课程的初步感受和体验。在这一篇文章中，我想继续深入探讨我从这次课程中学到的敏捷的知识和技能，以及敏捷团队的协作和沟通。希望能够对大家有所启发和帮助。

敏捷团队的组成

敏捷强调团队的自治和授权,鼓励我们自组织成跨职能的敏捷团队。敏捷团队能作为一个整体对价值增量进行定义、构建、测试和部署，并且基于沟通与价值交付进行优化，先做好本分工作再兼任其他工作，而不是将任务一股脑儿的丢给某人让其成为瓶颈。令我印象深刻的一句话是Dean Leffingwell说的：“我们无法规模化劣质的代码（或劣质的硬件、其他任何劣质的东西）”。所以我们需要确保每个工作产品的质量一致，从测试对质量负责转变为团队对质量负责。

敏捷发布火车的组织方式

其次，我了解了敏捷发布火车（ART）的概念和作用。敏捷发布火车是一种组织敏捷团队的方式，它可以将多个跨职能的敏捷团队组合在一起，形成一个大型的敏捷团队，共同交付一个产品或者一个解决方案。敏捷发布火车要求我们围绕价值流来组织团队，而不是围绕项目或者功能来组织团队。这样可以提高团队之间的协作和沟通，减少重复工作和浪费，提高交付效率和质量。根据SAFe官方教材，使用ART的组织比传统的项目管理组织，平均提高了30%的员工敬业度和35%的团队生产力。

敏捷发布火车是基于SAFe 的一种实践方法，它可以将多达12个敏捷团队（每个团队7到12人）整合在一个ART中，每个ART可以有50到125+人。每个ART都有自己的愿景、使命、目标、路线图、度量指标等。每个ART都按照8到12周为一个PI（计划增量）来规划、执行、评估、改进自己的工作。每个PI都包含4到6个迭代（每个迭代2周），每个迭代都包含多个用户故事（每个用户故事描述一个用户需求或功能）。每个用户故事都可以拆分成多个任务（每个任务描述一个具体的工作项）。每个敏捷团队都有自己的PO（产品负责人）、SM（敏捷教练）和开发人员，他们负责定义、开发、测试、交付用户故事。每个ART都有一个RTE（发布火车工程师），他负责协调和促进ART的整体运行。每个ART还有一个或多个系统团队，他们负责提供技术支持和基础设施，以及集成和测试ART的整体解决方案。

PI规划会议的流程和内容

再次，我体验了PI规划会议的流程和内容。PI规划会议是一种协调敏捷发布火车上所有团队的活动，它可以确保所有团队拥有共同的使命和愿景，对齐业务目标和战略方向，制定合理的计划和承诺，识别和解决依赖关系和风险等。PI规划会议要求我们所有人同时参与规划，管理层以最小化的约束表达愿景，团队对自己的计划负责。

在模拟PI规划会议的活动中，我参与了需求拆分、优先级设置、工作量估算、迭代计划等环节，感受到了团队之间的互动和协作。正式进行PI会议前，云大先进行了角色分工，我担任PO（产品负责人），另一位小伙伴充当SM（敏捷教练），其余为敏捷团队成员。场景假设：团队需要在一个月后给投资人演示一个线上图书网站。我们小组需要共同完成两块看板，预期效果如下所示：

虽然都认真仔细的听完了云大讲的内容，但真正要做什么的时候，大家都有点二丈的和尚——摸不着头脑。由于我扮演的是PO角色，云大提醒我需要将用户故事的任务理清。根据场景假设，我简要的输出了我理解的User Journey Maps（用户旅程地图），并以此作为主任务，但大家看图后，就提出异议，疑问主要分为两点，一是时间就1个月，流程图中的User Story（用户故事）是否能做完？二是完成这些用户故事是否符合MVP（最小可行产品）交付，以及如何确定这些故事的优先级？大家一起头脑风暴后，内部达成了一致，确定了1个月能完成4个用户故事并符合价值交付的理念。但是对于确定优先级，我们又犯了难，即使知道使用WSJF（加权最短作业优先）方法，但是如何从0到1（得出延时成本和工作时长）呢？带着这个疑问，我们询问了云大，云大告诉了我们参考的答案，正常是继续进行拆解，将每个用户故事拆分成不同的任务，再依次估算。打开的excel里，我们发现有的任务给出了对应的Story Point（故事点），但有的没有，需要团队做出承诺进行任务的估算，这样分别累计就可以得出每个用户故事相对大小了。

当团队明确要做什么及其顺序之后，接下来需要考虑一个很重要的点，就是实际工作中，团队的capacity（容量）与load（负载）。按实际情况，我们计算得出两个迭代（Iteration）的capacity的值分别为48与41，对应的load分别为47和17。在云大的引导下，我们又完善了对应的PI目标，定义了里程碑及其时间，第三方/技术依赖，并且通过连线将任务与PI目标进行关联。然后，云大带我们重新梳理了一遍看板的基本组成元素：开始时间和结束时间、用户故事总数、对应PI目标、相关风险、团队承诺交付能力与预估用户故事点数、单周预期完成点数（load-工作点）、可能存在的风险、以及依赖项。最终完成的两块看板，如下图所示：

到此，为期两天的PI会议中的第一天的内容，大致也就完成了，之后就是多个跨职能的敏捷团队组合在一起，对齐沟通协作，进行I&A，召开PI系统演示会，发布ART绩效报告，进行BV（业务价值）与AV（实际价值）的打分，度量ART的可预测性。之后，进行回顾总结，将实际工作中进展顺利的方面与进展不顺的方面，以及我们下次可以更上一层楼的方面统统罗列出来。不断优化，交付价值，构建正循环。

构建持续交付流水线

最后，我学习了如何通过DevOps构建持续交付流水线，如何按节奏开发和按需要发布等。我认识到了内建质量的重要性，它要求我们在软件开发过程中就注重质量，并采用各种实践来提高质量，而不是在软件开发完成后再进行测试和修复。

重温了持续探索、持续集成、持续部署的概念和方法，它要求我们将软件开发过程分为三个阶段：持续探索阶段主要是理解客户需求、价值假设等；持续集成阶段是开发、构建、端到端测试、预发布等；持续部署阶段是部署、验证、监控、响应等。持续探索、持续集成、持续部署可以让我们每两周演示一次完整的系统增量，新的特性可协同工作且兼容现有功能，特性可以通过特性开关隐藏、白名单或者灰度，做到按需的、有节奏的发布，将发布要素从总体解决方案中解耦。

小结

这次SAFe6.0课程干货和精华太多，我对敏捷开发也有了更加深入的理解。所以本想分上下两篇记录的我，最后拆分成了上中下三篇。在聆听过程中，我会有很多灵感和想法闪现出来。例如，我担任PO时，不知道如何拆任务或确定用户故事大小时，问云大，云大就会引导我和小伙伴，往正确的方向上走，解决我们在PI会议中遇到的各种问题。但是在工作生活中，我们毕竟不能像在上课一样，遇到难题就问老师，老师会告诉你用你学过的什么知识就可以解决遇到的问题。我们单独决策时，经常会碰到不知道问题是什么，也不知道自己是否能解决。害怕犯错，信心不足。学了SAFe之后，我会朝着勇于试错的方向去转变，这样只要试成功的次数多了，人也就会愈来愈有自信。在下篇中，除简要介绍一下精益投资组合管理与引领变革之外，我会着重描述一下我和参与活动的小伙伴在学习SAFe中，与云大和连生老师的答疑互动。

以上，有任何想法都欢迎大家后台私信我，一起探讨交流。