《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一 第3章 SAFe团队层-阿里云开发者社区

开发者社区> 华章出版社> 正文
登录阅读全文

《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一 第3章 SAFe团队层

简介:

本节书摘来自华章出版社《SAFe 4.0参考指南:精益软件与系统工程的规模化敏捷框架》一书中的第3章,第3.1节 作者[美]迪恩·莱芬(DeanLeffingwell),更多章节内容可以访问云栖社区“华章计算机”公众号查看。



第3章

SAFe团队层

 

3.1 团队层介绍

我们、工作、知识是一个整体。

——本书作者

摘要

SAFe团队层是项目群层的组成部分,但有时会分开讨论。所有的SAFe团队都是敏捷发布火车(ART)的一部分——ART是项目群层的核心组成部分。团队层为敏捷团队的活动提供了组织、工件、角色和流程模型。由每个敏捷团队自己负责定义、构建和测试来自团队待办事项列表中的用户故事,这些工作在一系列固定周期的迭代内进行,通过使用共同的迭代节奏,并与其他团队同步和对齐,从而保证整个系统开发的迭代执行。所有团队都使用ScrumXP或团队看板,开发和交付高质量的系统,并每两周进行一次系统演示,从而确保在ART上的所有团队可以共同创建出一个经过集成和测试的系统,利益相关者可以通过快速反馈进行评估和响应。系统演示提供了一个常规的 “拉动事件”,用于在特定节点拉取不同团队的成果,让困难的集成和测试工作尽量提前。这种方法与“阶段–门限”模型有所不同,“阶段–门限”模型通常在项目生命周期的后期才进行集成和测试工作。

详述

团队层描述了敏捷团队如何驱动敏捷发布火车。敏捷团队采用SAFe ScrumXP或团队看板,同时应用内建质量的实践,确保最终产品质量。每个团队有5~9名团队成员(ScrumXP),并包括所有必要的角色,确保在每一次迭代中构建一个高质量且有价值的发布增量。ScrumXP角色包括Scrum Master、 产品负责人、全职工作的团队成员,以及其他能为团队创造价值的资源。看板团队的角色没有严格的定义,许多SAFe看板团队也使用ScrumXP的角色。每个团队都会得到项目群层中成员的支持,这些成员包括:发布火车工程师、产品经理、系统架构师/工程师、系统团队、共享服务、DevOps和其他必要的角色。因此,团队应该完全有能力在每次迭代中定义、开发、测试和交付可以工作并经过测试的系统。

项目群增量和迭代

所有团队遵循相同的迭代起止日期和时间周期,也就是有相同的迭代和项目群增量(PI)边界,以便与ART上的其他团队保持同步和集成。每个PI都起始于团队的PI计划,他们构建团队的PI目标,再汇总成项目群的PI目标,这些目标有助于指导团队的迭代执行。

团队会按照事先确定的迭代目标,计划和执行迭代,每个迭代的时间盒为两周。每个迭代提供有价值的新功能增量,迭代过程按照以下模式循环进行:迭代计划、承诺交付一些功能 、通过构建和测试用户故事执行迭代、演示新功能、执行迭代回顾,在下一个迭代再重复进行这些活动。在每次迭代结束时,团队也需要支持系统演示,它是ART的关键集成点。在一个包含多个ART的大型价值流中,团队还需要支持解决方案的演示,整个解决方案由多个ART全面集成和测试,进行整体演示。

创新与计划(IP)迭代为团队提供了一个探索和创新的机会,有专门的时间用于计划、回顾并通过正式和非正式渠道进行学习。如果发布处于PI的边界上,团队需要做最终的系统审核、验证和文档工作。为了能提供一个缓冲,团队不会在IP迭代中计划用户故事的实现,所以对于每个PI而言,资源利用率不会达到100%。这样做增加了流动、吞吐量和交付的可靠性。

PI的时间盒可以用于将大型的、系统级的功能聚合为有价值且可评估的项目群增量。这些功能可以在PI的边界上进行发布,也可以更加频繁的发布。项目群应该有节奏地开发,并支持任何时间的发布。

每个PI的迭代数量

SAFe把开发周期分为PI内的一系列迭代。在SAFe全景图中描述了如何通过PI计划会议启动一个PI,接下来是4个实施迭代,最后是1个创新与计划迭代。这种模式具有启发性,不过有些武断,其实在一个PI中有多少个迭代是没有固定规则的。经验表明,PI持续时间一般是在8~12周的效果最好,并且倾向于最短的持续时间。

用户故事和团队待办事项列表

团队使用用户故事来交付价值,产品负责人负责用户故事的创建和接收。用户故事承载客户的需求,通过价值流进入到实现阶段。团队待办事项列表由用户故事和使能故事组成,其中大部分故事是在PI计划中,当产品经理向团队展示愿景、路线图和项目群待办事项列表时进行确定的。在团队层基本的需求管理流程是:用户故事的识别、排序、排期、细化、实施、测试和接收。

参考资料

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
最新文章
相关文章
官网链接