7FRESH多团队敏捷实践 供应商直送B仓项目

作者介绍

王新,京东零售技术研发中心IT服务与项目管理部敏捷教练,SAFe DevOps,SAFe 4 Certified Agilist/Certified Scrum Professional-ScrumMaster™/Certified Scrum Professional–Product Owner™,具有丰富敏捷实践经验。

7FRESH供应商直送B仓项目涉及6个团队,投入产研测人员近60人,是跨团队、跨事业部的大型复杂项目。经过大家的不懈努力,最终圆满的完成了任务。

项目上线后,业务使用频率高,目前华北区有约100家供应商共2100多个SKU送B仓。业务价值也很高:极大地降低了供应商送货成本,提高了门店送货效率,降低了门店无货风险。

在链条长、人员多、情况复杂的情况下,如何通过敏捷达到效果的呢?项目的开发参照(但没有完全照搬) 规模化敏捷SAFe 的模式进行。如图1:SAFe框架图。 

(图1)

下面介绍团队开展多团队敏捷实践中的几个关键点。

如何开计划会议?

PI计划是SAFe中非常重要的活动,要求全员到场。6个团队在一起开了第一个大计划会议(PI)。为什么要在一起?人员多的情况下,效率会高吗?

首先要回答这个问题。多团队开发最大的问题就是信息不同步、相互依赖搞不清、产品开发缺少统筹规划,这里面隐性的成本是非常高的。因此全员面对面执行大计划会很有价值,磨刀不误砍柴功。

相对于Scrum,SAFe 中的PI计划很有挑战性。把近60人组织在一起并最终输出有价值的成果,不是件容易的事情。如图2:PI计划会(1)

(图2)

1)系统层面

6个子团队知晓各自领域的业务以及技术逻辑,但是缺少跨团队的主流程以及全局系统架构层面的把控。这部分功能是program level(如图1)系统层面考虑的职责。这也是PI计划会议的核心内容之一。为的是避免各自为战的局面。

2)团队层面

在此基础上,6个子团队规划各自团队PI内的整体工作包括迭代目标、需求范围和优先级、需求拆分以及工作量估算等内容。如图3:PI计划会议(2)

(图3)

3)如何确定依赖关系?

PI计划会议上,各子团队需要分别评审其他团队的迭代计划内容。各种依赖关系会显现出来 。为减少等待时间,各子团队需要重新调整各自的需求开发优先级,以达到整体效益的最大化。如图4模拟图:(连线的是有依赖关系的需求)

(图4)

系统层面的产品集成

对业务来说,B仓项目也是探索模式,之前并没有成熟的业务解决方案。基于这样的背景,快速、持续的系统层面的产品集成至关重要。

如图1 SAFe框架图 Team level ,6个子团队都是Scrum团队。每个迭代(2周)都会输出产品增量。

如图1 SAFe框架图Program level,6个子团队的产品增量会定期的进行集成,进行系统演示System memo。

除了周期性的System memo,团队还邀请业务进行了产品MVP的验证。通过以上举措,目的是进行快速及时的验证与反馈,尽早发现问题。

保持节奏与同步

多团队敏捷虽较复杂,但也要遵循敏捷的原则与价值观。

团队跳动的节奏保持一致,子团队迭代周期均为2周;在Program level,PI的迭代周期固定为6周。相同的团队节奏使得系统级演示能够持续进行。

此外,各子团队每日举行各自的站立会;子团队代表还会执行Program level的每日站立会,保持信息同步。各团队维护自己的物理看板,为体现整体进展以及解决有的团队物理位置较远问题, 同时还建立了电子看板,信息传递更加透明和迅速。

团队回顾

图5展示的是团队成员在整个项目过程中的情绪波动曲线,可以看出项目的开发过程不是一帆风顺,而是跌宕起伏的。团队的敏捷回顾进行的非常热烈,大家从各个方面进行反思与讨论。

(图5)

听听团队成员是怎么说的?

研发骨干夏令:

“敏捷方法给项目的整体进度把控提供了切实有效的抓手。在团队人员充分沟通的基础上,让组内成员既有阶段性产出,又有成就感;同时又能让团队Leader从全局看到成员每一步的小产出,产品不断在动态递增演进,最终达成目标。这种方式更能让业务侧提前体验交互,进行验证,提前发现问题。“

主产品李敏:

“通过敏捷项目管理方式,让一个多条线、多领域、风险大的项目,变得有序可控、过程清晰;将需求拆分成小的用户故事,不仅能让团队成员更细致地了解产品构成,也使得产品可以平稳地按照迭代进行演进;通过站会、同步进度等有效沟通方式提升了跨团队成员的互动力和凝聚力。”

团队成员辛勤的努力,收获的不仅是产品成功的交付,还有着中间过程积累的经验,这些都是宝贵的财富。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章