大型企业的敏捷管理实践——公司Rally培训笔记

近日公司开始将项目管理工具从JIRA迁移到Rally并进行了Rally培训。Rally 是一个企业级的项目管理工具，能够支持规模化敏捷框架（Scaled Agile Framework®，SAFe®）

主要目标是提升项目效率，主要方式是通过将产品负责人（Product Owner）和开发者结成工作小队（Squad），缩短用户和开发者的距离并提升工作效率。

归根到底Rally只是一个工具，学习Rally的使用更重要的是理解背后敏捷管理的理念。

SAFe

所有这些改变的背景基于规模化敏捷框架（Scaled Agile Framework®，SAFe®），如下图所示：

SAFe®有一套完整的概念体系，并非一篇博客可以覆盖，通常需要参加为期2天的针对性培训并获取相应认证证书。针对公司中不同的角色（Roles），SAFe®提供不同的认证

这篇文章作为开发者记录一下自己简单的理解

组织机构的层级是一个传统的概念，类似若干员工组成一个工作小组，若干个小组组成一个部门，若干部门组成一个事业部等等，这里的用词在不同的公司都不一样，但本质是一样的，这里不再赘述

工作的分层是规模化敏捷的一个重要内容。企业中的一项工作可以非常大，例如一个持续若干年的大项目；也可以非常小，例如一行简单的代码修改。因此需要对不同的工作进行层级划分：

个人认为，以上的不同层级上的任务虽然使用了特别的术语（如 Theme、Epic、Story），但本质上都是一个一个具体的目标和任务，之间最大的区别就是任务的复杂程度、所需要的时间和资源、以及资金规模。

这种任务分层方式也可以应用到日常生活中，例如：完成一份博士论文是一个为期3年的Theme，那么它可以由三篇小论文组成（Business Outcome），每一篇论文的完成都需要调研、实验、总结、讨论、撰文等多个Epic组成，而其中每一个Epic都涉及到一些具体的工作（Feature），以此类推。

通常的任务执行流程是：

这里有一个特别的概念是发布列车（release train），有点类似赶火车的概念。企业的任何重大发布需要在特定的时间进行（类似火车的列车时刻表），错过了一个发布时间窗口就要等下一趟列车。所有互相依赖的发布内容需要一起等火车，不能让任何一个feature先走。

至于基础层级的任务Story则使用传统的Scrum或者Kanban模式来实施，例如每一个任务都有从backlog 到 review 到Done的生命周期。

同时整个team一起做计划（planning）、执行（execution）和反思（retrospective）

每周都需要对以下三个层级的Backlog上进行细化安排（一般需要2小时*3）

所有的计划不一定需要一次性计划清楚未来的具体细节，只需要越靠近未来、计划约清晰即可。

上文提到的几大类SAFe证书已经暗示了在实施SAFe过程中包含的三大类角色：

这三种分工在不同层级上有不同的称呼，如下：

层级	Devops	Support	Business
Story 级别	Agile Team	Scrum Master	Product Owner
	System Arch/Engineer	Release Train Engineer	Product Manager
	Solution Arch/Eng	Solution Train Engineer	Solution Manager
Epic 级别	Enterprise Architect		Epic Owner
	Head of tech / Domain architect		Domain leadership

以上不同的称呼可能会因公司架构差异而不一样，本质上SAFe将公司的员工归为三大类，并规范了三类角色如何在不同的任务层级上相互协作。

此外这种规范化的管理模式，也为个人发展指明的道路，你可以清晰的看到个人如何承担更多的责任，负责更大规模的任务的职业发展路径。

培训的最后推荐了一本书《 Scrum and XP from the Trenches》，希望自己有空能读一下