有关SAFe实质概要介绍

面向企业的Scrum-SAFe

常规的敏捷框架适用于中小型项目团队,而且不具有扩展性。基于常规的敏捷框架,SAFe定义了一个可扩展的敏捷框架模型,它适用于大型团队的合作开发,可以提高团队之间的协作性,降低团队管理的复杂性。

SAFe是企业层面的Scrum

若企业已从Portfolio(投资组合)、team(团队)、计划(Program)三个层面清晰定义了敏捷的框架,你可以按照以下的方式来定义和细化你的敏捷架构。

首先,SAFe架构Portfolio层,由PPM来负责定义和驱动投资策略如何形成和资金的组合形式,然后将其体现成为叙事诗(Epics)。一个Epics可以是一列单独的敏捷火车(Agile Release Train)来执行,也可以是几个火车的组合。Epics 是直接面向客户的,设计架构级别的业务解决方案。

接着,在第二层计划层由产品经理(Product Manager)负责把等待安排的计划(Backlog)进行排序,并且把投资策略转化成具体的新功能(Feature),同时和业务负责人一起设计出项目的愿景和路线。

最后,在第三层团队由产品负责人(Product Owner)和团队成员根据上面的定义细化出用户故事(User Story)和验收标准,开发团队可以从候选的用户故事里面优先选择可以提前开始的内容,其余的留到故事池里面等待后续的选择。

由此可见,SAFe 从三个层面保证了团队和企业的投资组合的最终愿景一致。同时,在实施过程中,需要一系列的里程碑事件来保证最终的实现和高层愿景设计的持续一致。而里程碑事件的制定主要通过计划发布(Release planning)和系统的展示(System Demo)来保证。

SAFe 的几个关键的角色:

SAFe 执行过程中,我们必须掌握几个关键角色:

Scrum 火车 工程师 (Release Train Engineer, 简称 RTE)

Scrum 主 管 (Scrum Master, 简称 SM)

如图 2 所示,基于 SAFe 的一个企业级的投资策略往往由多列敏捷发布火车(Agile Release Trains)来组成。

RTE 是一列敏捷火车(Train)总的 Scrum 主管,其中每列敏捷火车有一个 RTE 。请注意一列敏捷火车是由多个团队组成的。RTE 负责一列敏捷火车的总体执行,包括在执行过程中移除阻止火车前进的障碍,以及管理各个团队之间的集成(Integration)。

而 Scrum 主管 (Scrum Master) 是团队级别上 Scrum 的负责人,确保 scrum 的正确使用并使得 Scrum 的收益最大化。

图 2.大规模的敏捷的火车

SAFe 在计划管理面有一个时间控制,就是递增的 Sprint 计划(Program Increments,简称 PI), 用来对一列敏捷火车的提交和发布时间进行总体规划。而在团队管理层主要是通过 Sprint 来做为一个时间箱标准,一般一个 Sprint 为 2 到 4 周。

SAFe 的计划和发布

让我们来认识下 SAFe 下和计划和发布相关的几个重要概念,这是实现和运用大规模的敏捷框架的最重要的部分。

递增的 Sprint 计划 (Program Increment, 简称 PI)

在首个 Sprint 开始之前,需要召开一个递增的 Sprint 计划。用来计划和确定一列敏捷发布火车的时间维度,通过定量的时间递增(Sprint)来保证编码实现和我们计划任务(Mission)的持续一致。如图 3 所示,一个 PI 周期可以是 8 到 12 周的长度,包含一个位于最末端的 IP (Innovation and Planning) Sprint。

PI 将在固定的时间箱内计划出一个可量化、可实现和最终可测量验收的计划路线图。

每个 Sprint 都需要经历同样的工作: 设计,编码和用户故事的测试

任意一个 Sprint 都必须产出是对计划任务有价值的内容,在较短的时间箱(2 周)内防止实现和计划任务的偏离。一旦发现偏离,可以及时纠正。

所有的敏捷火车都共享同一个发布项目时间表,比如在 2016 年的 2 月份的发布是从 2015 年 11 月 15 日到 2016 年 2 月 19 日,那么所有的敏捷火车都遵守这个项目发布时间表。

在每列敏捷火车中,代码编写、提交和测试是基于单个 Sprint 时间范围内有节奏的进行,但是各个发布火车代码的最终发布和部署是根据实际情况来决定的。也就是说,并不是每个火车一定在 PI Sprint 后才可以发布。比如说,一列敏捷火车的代码在第二个 Sprint 可以完成,那么它就可以在第二个 Sprint 来发布。当然在部署到最终产品环境之前,一定要完成对所有的用户故事的验证测试。

图 3.SAFe 的递增的 Sprint 计划

创新和计划(Innovation and Planning, 简称 IP)

IP Spring 是位于整个增量计划周期里的最后一个阶段,也是两周的时长。

通常在第一周,我们会对整个新功能进行系统级别的验证和回归测试,估算下一次增量计划的缓冲时间,总结我们在实施项目过程中哪些是做的好的地方,可以继续;哪些地方需要改进,总结经验和教训。最后,我们可以对下一次的增量发布进行提前计划。

在 IP Spring 的第二周,可以在这个阶段对即将发布的代码进行规划,包括各个相关团队做发布包等的筹备。但是也有例外的情况,如果项目的时间比较紧张,开始和测试不能在 IP Sprint 完成,那么 IP sprint 的第一个周也可能用作一个回归测试。

发布计划(Release Planning)

在我们进入首个 Sprint 阶段之前,需要举行一个发布计划会议。

发布计划需要遵循下面的的几点:

一般来时,推荐进行时长两天的面对面的计划会议。

在上一个 PI 的基础上,计划下一个发布计划的 PI。

始终保持开发工作和业务需求以及计划一致,从而保证每个 Sprint 的产出对用户或者业务而言是有价值的。

对将要实现的新功能进行排序,筛选出优先级前十的功能和特征。

辨识出每个 sprint 的 sprint 目标、存在的风险,并且把各个团队之间的依赖和阻碍记录到计划展示板(Program Board)中。

确保大家对新功能的优先排序保持理解一致。

图 4. 计划展示板

敏捷的团队需要做哪些工作

在每个 Sprint 的开始阶段,需要进行 Sprint 计划会议。通过会议,确定在本 Sprint 需要完成哪些用户故事,保持开发人员,测试人员和相关人员的理解是一致的。以及用户故事提交顺序安排。如图 5 所示,对相临近的 Sprint 可以进行同样的计划和安排。不需要把所有 Sprint 都提前进行计划,可以遵循近详细,远粗略的原则。

另外,在实践中我们引入一个探针(Spike)的概念。如果在某个 Sprint 开始时,我们无法精确估算将要完成的工作量,那么我可以加一个探针来探测我们大约需要的工作量和时间。探针的使用一般在整个 PI 周期的第一个 Sprint 里使用。前提是可能需求不够清晰,也可能是我们对自己要进行的开发辅助工作量不好衡量。例如,我们在 Sprint 1 需要完成用户故事 A,但是在完成用户故事 A 前,需要做大量相关代码的重构工作,但是在用户故事里面这个工作没有体现,而且我们对代码重构的工作量也不能准确估算,这个时候我们可以引入探针。

每天一个 Scrum 会议, 简短的更新进度和问题。

在 Sprint 结束前,对所完成用户的故事进行展示。并且,开展一个回顾会议 (Respective)。

图 5. 团队计划

敏捷发布火车需要做哪些工作

每列敏捷的发布火车都需要做下面一些事情:

在正式的 Sprint 开始之前,需要召开发布计划会议(Release Planning)。在一个 PI 完成后,而下一个 PI 开始前,这个会议在上一个 PI 的 IP Sprint 期间召开。

由 RTE 来主持一个 Scrum 会议,会议的频率根据项目的具体情况而定。 会议参与人包括本次发布火车上各个团队的主要负责人产品经理产品负责人等必要的人员。会议的内容包含各个团队工作进度的更新、目前存在的主要问题等。如果问题是跨团队的,需要一起讨论解决方案

实践经验总结

本人进行的实践项目是一个面向 IBM 内部销售代表使用的 WEB 电子上午网站,需要支持客户在使用中提出的业务功能改进方案。业务功能的支持团队是由位于中国和美国的六个团队组成的 , 我们采用了 SAFe 的框架来实施敏捷。请注意在此提供的经验总结仅供参考, 而不是必要的法则。那么,让我来开始分享下我们的经验吧。

必要的敏捷火车 scrum 会议

由 RTE 主持的 Scrum 会议上,RTE 维护出一个包含所有团队工作进度的列表。 让处于同一列敏捷火车的团队成员知道除了自己之外,其它团队的进度。如果发现某个团队的一些用户故事不能及时部署到对应的测试环境,RTE 需要调查原因,移除障碍,从而保证整列敏捷火车高速前进。如图 6 所示,在工作列表的纵列是本列敏捷火车的相关团队,横列是各个团队在不同测试环境下的工作进度。紫色的部分列出了没有完成的用户故事在某个 Sprint 下。浅蓝色代表用户故事已经提交到两个测试环境,但是测试还没有结束。浅黄色背景代表在用户验收环境的验收测试已经完成,可以部署到产品环境了。

工作进度列表对各个团队的工作状态显示的一目了然,最主要的是可以保证整个敏捷测试的策略是清晰的。例如,哪些部分现在可以测试了,哪些部分受到阻碍以及哪些部分有依赖,不能进行端到端的测试等。

工作进度列表是实时更新的,更新的频率取决于敏捷发布火车会议的频率。

图 6. 团队进度列表

知识全面的敏捷测试人员

在单个 Sprint 期间,敏捷测试包括用户故事的测试和端到端的测试。我们的项目涉及到六个开发团队。所以一个端到端测试,需要经历四五十个测试步骤。而我们的团队是分布到美国和中国的不同时区,所以在顺利的情况下,完成一个端到端的测试也需要至少两天的时间。那么在敏捷的框架下,我们的测试箱是有限的。如何在有限时间内完成如此步骤繁杂的测试呢?需要我们的测试人员对业务知识的了解是是全面的,拥有各个团队的相关业务知识背景和访问权限。

通常情况下,我们前端的测试人员会在中国时间内完成其它团队的测试,从而确保一个端到端的测试用例在一个工作日内完成。除非发现异常情况,那样我们必须等待美国其它团队的测试人员重新确认测试结果。

实时更新的用户故事

产品负责人把新功能分划成具体的用户故事过程中,用户故事不是一成不变的。随着需求的逐步确认和沟通,用户故事的内容和验收标准需要实时更新。请注意,通过问题队列(测试案例或者测试结果)来跟踪需求是非常不好的敏捷实践。它会导致敏捷火车上的相关人员对用户故事有不同的理解。产品负责人有责任实时更新用户故事和验收标准。

结束语

通过上述对 SAFe 基本特征的介绍,以及项目实践经验的分享,读者可以对 SAFe 的概念和实施方式有一个基本的了解,在将来项目实施大规模的敏捷框架时,可以借鉴相关的实践经验。

敏捷框架SAFe(Scaled Agile Framework)实践相关推荐

  1. 三分钟了解SAFe(Scaled Agile Framework)

    1.SAFe 概述 SAFe(Scaled Agile Framework)是一种面向大型企业的敏捷开发框架,旨在协调多个团队和部门的协同工作,以实现高效的软件开发和交付.下面是SAFe框架的简单介绍 ...

  2. 大规模敏捷框架SAFe模型简介

    一.SAFe简介 SAFe是ScaledAgile Framework的简称,由DeanLeffingwell创建,是用于在企业范围内定义和实施敏捷软件开发过程的最佳实践和经过验证的成功模式的集合,被 ...

  3. Scaled Agile Framework (SAFe) 和产品管理间到底有什么关系 ?

    SAFe 就是将 RUP (Rational Unfied Process), Lean, Scrum 给搅和在一起. SAFe 也许解决了大团队在制定版本计划与协作上的一些问题. 但我实在不明白,S ...

  4. 洞悉规模化敏捷框架 Scrum@Scale 、LeSS 、SAFe (上篇)

    引言 本文以多个维度不同视角向你呈现Scrum@Scale .LeSS 和SAFe三个规模化敏捷框架的共性和各自的特点.包括Scrum团队容器.沟通机制.沟通饱和度.适应性.系统思考.实施路线图.原则 ...

  5. scrum回顾_沙龙回顾 | 大规模敏捷框架-Essential SAFe介绍

    作者:袁翠 2019年1月20日,这是一个周日的晚上,尽管如此,来参加沙龙的人还是不少,与其在家无所事事,不如来一场知识的火花碰撞. 按照惯例,先是进行自我介绍.如果说这次自我介绍与以往有任何不同的地 ...

  6. 规模化敏捷框架何从入手?这篇文章把SAFe讲透了!

    摘要:敏捷软件开发理念已渐渐被业界普遍接受,越来越多的公司和团队不得不面对一个新的问题,就是规模化敏捷的引入和实现.目前市场上规模化框架主要有SAFe,Less,Scrum of Scrums, Sp ...

  7. 什么是SAFe(规模化敏捷框架)1——全景图基础层

    接下来分几篇文章,简单介绍下什么是SAFe,本文内容是基于SAFe4.0与SAFe5.0 的总结.本篇文章先介绍下SAFe的全景图及基础层. SAFe(Scaled Agile Framework,规 ...

  8. ACP敏捷4.规模敏捷.多团队多迭代多产品.敏捷框架

    规模敏捷就是要解决多并发敏捷开发的问题. 1. 多团队Scrum要素扩展 团队要素纵向扩展(单团队->多团队扩展): 规模化敏捷团队人数上限150. Robin Dunbar数: 英国人类学家罗 ...

  9. 《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一 3.13 故事

    本节书摘来自华章出版社<SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架>一书中的第3章,第3.13节 作者[美]迪恩·莱芬(DeanLeffingwell),更多章节内容可以 ...

最新文章

  1. 从键盘输入一行字符,写入到string.txt文本文件中
  2. 删除一个数的K位使原数变得最小
  3. opencl高斯源码整理
  4. python栈是什么意思_Python数据结构——栈
  5. ADO之connection
  6. checkpoint_通过Main的Checkpoint Restore加快Java启动速度
  7. 6大主流开源SQL引擎总结,遥遥领先的是谁?
  8. C# 属性、索引器(二)
  9. 计算机管理是什么控件,Win7旗舰版系统WMI控件的功能作用是什么?
  10. 基恩士PLC实例笔记①--立项及编程
  11. class文件反编译后的汉字乱码问题
  12. win10 -- 增加新建 TXT 文档快捷键
  13. LPC845-BRK开发板运行Blinky示例程序
  14. Shannon-Fano编码——原理与实现
  15. 2018年深圳,武汉房价走势分析
  16. 排序算法——鸽巢排序 Pigeonhole sort
  17. grads 相关系数_气象统计方法实习报告材料
  18. 剪映导出帧率选多少_剪映帧率是什么 剪映帧率在哪设置
  19. 【论】Strategic sourcing selection for bike-sharing rebalancing: An evolutionary game approach
  20. HECTF 部分wp

热门文章

  1. 归并排序-拓展至三路归并
  2. win10 android软件下载,windows10模拟器安卓版
  3. 关于小米电视不能访问电脑共享文件的解决方案之一
  4. 介绍一下3D游戏开发的简单常识,以及最终幻想13游戏流程为什么会过于线性的原因。
  5. 固定资产的日期之接管日期
  6. R5 7640H参数 锐龙R57640H性能怎么样相当于什么水平级别
  7. verilog实现计算均值
  8. mybatis入门学习之环境的搭建——helloworld
  9. 【C语言知识梳理之分支语句】
  10. Unity Shader 麻将平面阴影高光