您好!
欢迎来到京东云开发者社区
登录
首页
博文
课程
大赛
工具
用户中心
开源
首页
博文
课程
大赛
工具
开源
更多
用户中心
开发者社区
>
博文
>
Being Agile!跨团队协作3/4攻略
分享
打开微信扫码分享
点击前往QQ分享
点击前往微博分享
点击复制链接
Being Agile!跨团队协作3/4攻略
自猿其说Tech
2021-01-11
IP归属:未知
23480浏览
计算机编程
前端
大数据
大型复杂组织的联系千丝万缕,也许只有魔法师可以挥挥魔杖轻松搞定;通往霍格沃茨魔法学校的站台是9又3/4站台,给你一个“3/4”攻略,也许能帮你找到你们团队的9又3/4站台。 #### 识别价值流 你知道敏捷的一切都围绕“价值”开展,所以识别你的团队所负责交付的价值的流转路线是组织协作的第一步。 ##### 价值流定义:一系列长期存在的步骤:从概念转化为最终交付给客户的实际有形的成果,从而创造价值。 **举个例子:** ![](//img1.jcloudcs.com/developer.jdcloud.com/2eaa0302-8de4-4907-825f-52029698f23520210111140953.png) 上图中第一层说明了价值执行的步骤,第二层是支撑价值流的系统。针对示例的业务,由于对于不同的需求,涉及的系统之间耦合情况是不一样的,有时可以互相独立发布,有时必须共同集成,所以我们把每一个支撑系统都看成一个独立的ART。 #### 定义解决方案火车 先说下ART的概念:ART是敏捷发布火车的缩写,发布火车是个很古老的名词了,ART就是敏捷团队的发布火车,这个应该很好理解。 ##### 在我们向客户不断交付价值中,一个解决方案可能会涉及多个ART,这时,产生了一个新的名词:解决方案火车。 在前面的例子里,TC业务就涉及到了上下7、8个系统;可以把TC业务看成一个解决方案火车,这个火车涉及了多个敏捷团队负责的ART。 ![](//img1.jcloudcs.com/developer.jdcloud.com/eedf6a86-c250-4d1c-8df9-bdba63cfb3be20210111141117.png) #### 对齐开车时间 记得刚启动敏捷的时候,有很多同学问跨团队怎么敏捷?饭要一口口吃,路要一步步走撒。小团队的敏捷是地基,在经过4个月的推进,目前已经有30左右的团队是按2周的节奏在迭代,加上将要进行的三班十几只团队,我大胆估计你涉及到要协作的团队至少有50%已经可以跟你聊聊迭代范围了。那为什么迭代这么重要,因为这意味着,协作的团队可以有: - 相同的迭代启动、结束时间 - 相同的前置需求排期时间 - 敏捷团队历史交付速率值是有的,基于交付速率更容易评估投入时长 有了上述三点,对齐就会容易些!协作会更有规律! **如果你涉及到的团队已经在迭代交付,但起止时间对不齐,请你来找我。** #### 解决方案按节奏计划并且可视化 前面已经提过,价值流是长期存在的,所以解决方案可以按节奏做计划。还是以TC业务为例,如下图展示: ![](//img1.jcloudcs.com/developer.jdcloud.com/cbf04501-eda6-44c6-a687-332e893d438920210111141306.png) 1. 各ART迭代周期2周,即每2周都应有增量交付 2. 迭代前置1周对齐需求(可根据情况设定,前置不宜超过1个月) 3. 每2周上下游对齐一次需求 4. 对于有强依赖关系的上下游系统要对齐集成时间(最好以集成时间倒排) **注意:解决方案火车按需发布,与迭代节奏是解耦的。** #### SoS会议对齐进度 计划确定后,进入迭代中,对齐各自进展是十分重要的事情,解决方案火车Owner团队组织SoS会议,对齐进度。SoS会议内容: 1. 你的团队完成了什么? 2. 下次会议前要完成什么? 3. 有什么风险?对其他团队有什么可能影响? **SoS会议一周两次,建议周一、周四下午下午5-7点之间进行;会议时长在15-30分钟。会议组织者由解决方案火车STE担任。** #### 关键角色 在跨敏捷团队协作中,有几个关键的角色或组织 1. 解决方案管理者:决策方案的目标、需求范围 2. 解决方案火车工程师(STE):引导和指导各ART的协作,负责验收各ART的交付 3. PO:解决方案分解到各ART的产品代办负责人 4. Scrum Master:ART团队交付负责人 #### 关键实践 除了团队级敏捷的管理实践外,跨敏捷团队的良好协作还有几个工程实践要做保障: 1. 契约测试;保障双方接口协议各自开发,不会因未同步的变更导致集成延期 2. 需求拆分;需求拆分的粒度要小于10人天,在一个迭代周期内完成集成 3. 持续集成;尽早集成,及早消除依赖 #### 还剩1/4是什么? 那剩下的四分之一是什么呢?可能是: - 需求优先级不能对齐:需求的优先级就是价值流的优先级;一方面要减少跨部门(中台的作用),一方面需要业务侧有原则性的优先级指导…… **也许还有其他的问题……跨团队协作是个说不完的话题,如果你的团队对这个方案感兴趣,请联系我们!我们一起探讨!** ------------ ###### Being Agile 京东物流技术发展部效能提升部 ###### 作者:效能提升部 宋宁 ![](//img1.jcloudcs.com/developer.jdcloud.com/903963f1-df0f-49c3-906e-95155f4314d020210111141817.png)
原创文章,需联系作者,授权转载
上一篇:遗传算法实现
下一篇:Apache ShardingSphere数据脱敏全解决方案详解(下)
相关文章
Taro小程序跨端开发入门实战
Flutter For Web实践
配运基础数据缓存瘦身实践
自猿其说Tech
文章数
426
阅读量
2149964
作者其他文章
01
深入JDK中的Optional
本文将从Optional所解决的问题开始,逐层解剖,由浅入深,文中会出现Optioanl方法之间的对比,实践,误用情况分析,优缺点等。与大家一起,对这项Java8中的新特性,进行理解和深入。
01
Taro小程序跨端开发入门实战
为了让小程序开发更简单,更高效,我们采用 Taro 作为首选框架,我们将使用 Taro 的实践经验整理了出来,主要内容围绕着什么是 Taro,为什么用 Taro,以及 Taro 如何使用(正确使用的姿势),还有 Taro 背后的一些设计思想来进行展开,让大家能够对 Taro 有个完整的认识。
01
Flutter For Web实践
Flutter For Web 已经发布一年多时间,它的发布意味着我们可以真正地使用一套代码、一套资源部署整个大前端系统(包括:iOS、Android、Web)。渠道研发组经过一段时间的探索,使用Flutter For Web技术开发了移动端可视化编程平台—Flutter乐高,在这里希望和大家分享下使用Flutter For Web实践过程和踩坑实践
01
配运基础数据缓存瘦身实践
在基础数据的常规能力当中,数据的存取是最基础也是最重要的能力,为了整体提高数据的读取能力,缓存技术在基础数据的场景中得到了广泛的使用,下面会重点展示一下配运组近期针对数据缓存做的瘦身实践。
最新回复
丨
点赞排行
共0条评论
自猿其说Tech
文章数
426
阅读量
2149964
作者其他文章
01
深入JDK中的Optional
01
Taro小程序跨端开发入门实战
01
Flutter For Web实践
01
配运基础数据缓存瘦身实践
添加企业微信
获取1V1专业服务
扫码关注
京东云开发者公众号