×

微信扫一扫,快捷登录!

如何达成第一阶段的团队级敏捷

标签: 暂无标签
团队级敏捷,指的是以5~9人的小团队为单位开展敏捷转型。一般来说,大部分企业想尝试敏捷转型,都从选择一个或几个团队开始试点。每个团队各自独立交付产品,彼此之间不一定需要有关联。当试点有效果后,组织往往会继续拓展敏捷转型的范围,鼓励更多的团队加入敏捷的阵营。

团队级敏捷的实践一般包括:

  • Scrum或看板方法;
  • 持续集成;
  • 涌现式架构设计;
  • 领域驱动开发;
  • 行为驱动开发;
  • 自动化测试;
  • 结对编程;
  • 测试驱动开发。

如果单个敏捷团队可以独立发布产品,他们可能会进一步尝试一些工程技术实践,比如:

  • 微服务;
  • 持续交付流水线;
  • 自动化运维。


但是,对于那些由多个团队协作交付的大型项目来说,即使每个团队都在开展敏捷实践,也未必能够看到整个项目明显的收益和效果。因为大型项目关乎的是整个版本、产品的交付效率和质量,团队与团队之间需要互相配合才能交付整个产品。

同时,对于每一个团队来说,在他们尝试敏捷的过程中,必然会碰到一些与敏捷相抵触的项目流程、管理和协作方式,这对团队的效率是一层枷锁,而这又是团队很难改变的。

一家通信企业B的一个产品线的底层协议通信部门共有3个Scrum团队,每个团队都已经实践Scrum一年的时间,每个团队都搭建了持续集成(ContinuousIntegration,简称CI)系统,开始了自动化测试。

此外,处于该产品系统架构上层的单板软件层,由另一个部门交付。他们有6个Scrum团队,每个团队尝试Scrum也有几个月的时间,也在进行CI持续集成、自动化测试、TDD测试驱动开发、结对编程等技术实践。这6个Scrum团队从底层协议通信的3个Scrum团队获得协议通信代码后,与自己的单板软件代码集成后,作为单板软件整体发布出去。

由于这6个Scrum团队依赖那3个底层协议通信团队,所以若要交付出对客户有价值的产品,在整个产品线的项目组织结构里,这9个团队缺一不可。单独任何一个Scrum团队交付的内容都不能产生价值。

而这几个团队虽然自己都在运行Scrum,但是没有确保彼此之间用步调一致的机制来运作。每个Sprint都出现上层单板的A团队在等待底层协议B团队的一个组件就绪的情况,导致A团队交付延期。

该产品线度量了Scrum试点前后的上市周期时间(TimeToMarket,简称TTM),虽然每个团队都在做敏捷转型,但是整个产品的TTM没有明显缩短。

对于这样的组织,就需要发展到更上一层的敏捷:产品级敏捷。






上一篇:如何设计敏捷转型的路线图
下一篇:如何达成第二阶段的产品级敏捷
FYIRH

写了 198 篇文章,拥有财富 1122,被 1 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

返回顶部