敏捷团队的病与药——阿里健康医药B2B团队敏捷转型手记-阿里云开发者社区

开发者社区> 开发与运维> 正文

敏捷团队的病与药——阿里健康医药B2B团队敏捷转型手记

简介: 作者:张迎辉,花名问菊,阿里巴巴敏捷教练,罗汉堂讲师,开发和讲授多门敏捷课程。先后支持手机淘宝、优酷、阿里文娱广告、阿里健康等多个部门的团队敏捷转型。 一、背景 2017年10月,应阿里健康研发部负责人邀请,我开始帮助阿里健康的研发团队敏捷转型。

211

扫描上述二维码或点我直达 免费领!

作者:张迎辉,花名问菊,阿里巴巴敏捷教练,罗汉堂讲师,开发和讲授多门敏捷课程。先后支持手机淘宝、优酷、阿里文娱广告、阿里健康等多个部门的团队敏捷转型。

一、背景

2017年10月,应阿里健康研发部负责人邀请,我开始帮助阿里健康的研发团队敏捷转型。

医药B2B是第一个吃螃蟹的试点团队。没想到,这个试点一点儿也不轻松:每次上线都出问题,好不容易BD来的客户都流失了,业务团队急得冒火;研发团队已经996超过两个月,辛苦又焦虑,竟然全都病倒了。

这是一个5月才上线的新业务,如果不能抓住机会证明自己,未来发展岌岌可危。幸运的是,我们挺过来了。经过3个月的持续改进,不仅质量、响应力和发布能力有了显著提升,业务也找到了突破口。

1
2
3
4
5

看到团队不断进步,如同医生看到病人渐渐痊愈,我由衷地高兴。不禁想到,敏捷教练辅导团队跟医生帮助病人康复有不少相似之处:

  1. 二者都需要“望闻问切”,系统全面分析问题,才能做出正确判断。
  2. 疗效如何要看病情是否缓解,要尽快建立反馈环,获得客观全面的反馈。
  3. 有哪些治疗方案,各方案的好处弊端都要一五一十告诉病人,由病人选择治疗方案。病人做好准备再开始治疗,不可欺骗病人,更不可威逼利诱。
  4. 治疗过程并非坦途,病人中途胆怯退缩在所难免。唯有热情鼓励和耐心引导,不可遇难而退。
  5. 授人以鱼不如授人以渔,教会病人强身健体的方法,病人可以自助甚至助人,才是上佳结果。

让我们一起来看看,如何帮助敏捷团队摆脱困境,走出低谷。

注:本文根据TiD2018和RSG2018分享内容整理

二、问题和解法

10月我进团队调研时,发现问题真不少:

6

感谢团队信任我这个三脚猫大夫,大家一起摸索试错,终于找到了解药:

7

我为大家一一详述。

1. 建立稳定的特性团队

8

刚进团队时,我竟然找不到一个熟悉业务的开发同学。原来,职能经理每个月按需求分配资源,大家临时搭伙做项目。

B2B特别艰苦,开发同学坚持了一个月就要求换业务。业务同学最大的愿望就是研发同学稳定,不然总要给新来的开发讲业务,刚讲明白就换人了。

我跟职能经理一个个聊,终于各端开发和测试经理都答应未来三个月内现有研发同学至少50%的时间做B2B业务。

50%是个神奇的数字,如果一件事占到了50%以上的时间,就不能不重视它的结果并为之努力。研发同学开始关注业务指标了。

2. 目标对齐,过程透明

9

非常感谢B2B业务负责人的支持,特意出差过来给大家讲业务目标和业务打法。药品流通环节最多有7层,通过B2B平台,可以减少到3层。研发同学第一次感受到自己的工作跟千万人的生活息息相关。

一个区域内药品批发的龙头企业(大B)只有几家,做砸了一家,这个区域就很难开展业务了。零售终端(小B)非常分散,都是业务小二一家家跑下来的。

听到业务同学三伏天骑着电瓶车拜访客户中暑摔倒了,大家都有些动容。很快,研发团队立下了军令状:上线质量要好,交付速度要快。大家终于拧成了一股绳。

10

注:图中所示看板为云效看板

立了军令状还不够,做得怎么样,还要看反馈。工作项进云效(注:阿里一站式研发协同平台,阿里内部叫Aone),大家随时都能看到研发进展和度量数据。真正做到目标对齐,过程透明。

3. 打开范围锁,严把质量关

11

发布质量差导致线上问题多,修复线上问题打断了新功能开发。业务和研发团队之间还没有建立起信任,大家更像是合同博弈,上线时间和范围早早就锁定了。

没有持续集成和自动化测试,全靠手工测试回归,测试时间又一再被压缩,发布质量可想而知。本来可以白天发布,对质量没信心,推迟到半夜没有交易了才敢发布。发了改,改了再发,折腾到后半夜几乎成了发布日的惯例。

要打破这个恶性循环,先从打开范围锁入手。我跟业务团队商量,有严格截止日期的需求保证按时发布,其它功能符合发布标准才发布,不能让客户承担质量风险。业务团队答应试一个月。

我跟测试同学对线上问题做了回归分析,有针对性地增加了回归测试用例。发布前一天做上线评审,不符合发布标准的一律打回。符合发布标准的上线前都要有预案,代码回滚、数据订正都在预发环境演练过,避免出现问题时手忙脚乱。

试了一段时间,效果很明显。原本每次上线都出问题,11月发布成功率提高到了50%,12月更是17次发布100%成功。随着发布信心的提升,发布时间也改到了白天,发布日再也不用熬夜加班啦。

4. 协作澄清需求

12

正如质量不只是测试的事,需求也不只是产品经理的事。

做产品如同寻宝,产品经理好比向导,知道宝贝在哪里;技术同学好比驾驶员,最了解车子的性能。大家一起想办法,才能快速又经济地找到宝贝。

有些技术同学一心只想写代码,殊不知代码是客观世界的映照,符合业务模型才易于维护和拓展。更何况很多隐性的业务知识无法用语言传递,谈需求时好像都共识了,验收时才发现想的根本是两回事。

既然是一个团队,当然要协作。需求是源头,协作就从需求共创开始。业务和产品大致梳理出需求概要,就拉上技术同学一起梳理。全体都参与需求梳理不现实,业务、产品加上一位开发和测试组成跨职能的需求小组。先弄明白需求给谁做,解决什么问题,大家再一起寻找解决方案。

讨论过程中,大家不自觉就突破了角色的限制,研发开始关注业务价值,业务开始关注技术可行性。

好玩的是,B2B团队由开发同学讲解需求,产品经理补充答疑。团队先后做了两个营销玩法的需求。第一个需求,评审时技术同学才参与,上线半个月了还有各种问题。第二个需求,用共创方式,上线后立即就能做活动,活动效果也特别好。

13

14

工欲善其事,必先利其器。用户故事地图和实例化需求双剑合璧,是协作梳理需求的利器。

用户故事地图最大的好处是一张图看到全貌。此外,从用户角色和用户目的出发,逼得我们想清楚需求的价值。想明白了价值,再逐个场景梳理用户旅程,走完一个旅程就能帮用户解决一个场景的问题。

实例化需求最适合厘清复杂的业务规则。如图所示,PRD上两句话,深究下去,竟然要用8个例子才能说明白。看起来需求梳理花了一些时间,实际上开发过程会省时间。拿到需求就开始写代码,并不一定最快。有一个H5页面反复改了6次,两周才做完。如果想明白再做,最多半天就搞定了。

15

如果按照从简单到复杂,从主流程到异常场景的顺序梳理用户故事地图,很容易确定发布优先级。如同地铁可以分段通车,一个用户旅程的功能也可以分段交付,只要交付的功能对用户有价值就行。

图中的营销活动需求,就分了好几段交付:先上线给运营同学用的后台功能,可以创建活动、配置活动和展示活动,运营同学可以预热招商了;接下来支持正向和逆向交易的价格调整,用户下单可以享受折扣了;为了控制活动预算,活动中要实时展示预算消耗;最后,支持每月一次跟商家对账。对账是离线统计,只要在活动开始后第一个对账日之前上线就行。

16

有了优先级,开发按照轻重缓急逐步开工,每周都有功能提测,符合发布标准的尽快上线。发布次数增加了,发布范围变小了,风险分摊了,质量更好了,上线前也不用集中加班了,让大家提心吊胆的big bang release消失了。

5. 看板管理流动

17

17_1

看板的5个核心实践在团队中如何落地?

首先,云效中建立工作流,每天更新需求状态,所有人随时都可以看到最新进展。

18

关键状态的流转,团队讨论确定了三个标准:

19
19_1
19_2

定标准不难,自律自治执行到位才是关键。

以开工标准为例,全票通过的需求才能进入开发,倒逼需求小组认真准备。结果需求评审进行得更快了,需求质量提高了,返工浪费减少了。

限制在制品数量(WIP)常常成为看板方法落地的难点,其实做起来并不难。WIP初始值可以按照每人处理一个需求来设置,如果团队有5个开发,那么开发中的需求最多5个。

同时,一定要按照优先级拉动需求,遇到紧急需求插队,就先中断最低优先级需求。确保每位同学每一个时刻只处理一个需求,尽量避免上下文切换带来的开销。领了需求,除非遇到不可抗力,一定要想办法完成。不能遇到困难就放在一边,再开始一个容易的需求。因为我们的目标不是开始更多,而是一旦开始就尽快完成。

在产品/开发和开发/测试之间设立缓冲区,时刻关注缓冲区的需求数量:需求太少了容易造成等待,需求太多了容易造成过载。通常缓冲区会储备未来1-2周的工作量。

20

新功能上线后,业务团队常要做营销和推广。研发团队和业务团队配合好,才能得到理想的效果。需求明确后,研发同学根据当前情况做一个简单的排期计划,便于业务团队安排营销活动。

软件开发出现意外一点儿都不意外,这时研发同学第一时间通知业务同学。大家一起商量对策,或是砍范围,或是推迟上线。及时沟通,通常都有很多选择。切忌hold不住了才告诉业务,这时候选择就很有限了。

21

及时记录研发过程中出现的意外以及造成的延迟,事后分析一下往往能找到改进的机会。

22

2017年12月,我们发现紧急需求插队带来了18天的延迟,占总延迟的30%。有些“紧急需求”其实没那么紧急,大家觉得划不来。于是明确了紧急需求的定义,只有真(不)正(做)紧(会)急(死)的需求才允许插队,其它需求都按优先级正常排期。

23

效果很明显,需求延迟交付的总时长从12月的61天缩短到了1月的12天。

24

6. 实现持续集成

25

明明很重要却难以落地的敏捷实践,持续集成也许算一个。其实项目启动时引入持续集成最理想:此时无论技术框架、构建工具还是自动化测试工具都有足够多的选择。而且,一旦引入了持续集成,团队在后续的技术决策中会选择有利于持续集成的方案,从而形成良性循环。

真实场景中,有些项目启动时未考虑持续集成,项目进行过程中集成问题越来越严重,才想引入持续集成。此时产品已发布,业务在持续发展,不太可能给团队大块时间建设持续集成基础设施。面临这样的挑战,如果选择合适的路径化整为零逐步迭代,团队仍能在较短时间内实现持续集成。

26

两个月内,B2B团队5个核心应用的单元测试覆盖率从40%提升到80%,同时业务开发一点儿没耽误,就是采用了“化整为零,逐步迭代”的策略。

27
27_1
27_2

代码覆盖率提高了,构建成功率提升了,构建时间缩短了。每次一小步,做起来不吃力,很快能看到收益,大家就有不断投入的动力。

28

用同样的策略,我们搭建了集成测试流水线。为了解决测试环境不稳定的问题,我们引入了HSF mock,搭建了稳定的日常环境。为了解决开发都挤到测试环境调试的问题,我们建设了项目环境,每个开发同学都有了隔离的调试环境。

“不积跬步无以至千里”,在业务开发的间隙,团队一起努力,每天建设一点点,每天进步一点点,持续集成越来越完善:代码提交后,编译、单元测试、打包、部署、集成测试全都自动化,把研发同学从繁琐的手工操作中解放出来,大家越跑越轻松。

7. 目标驱动改进

目标要发挥作用,团队要随时看到目标与现状的差距,并自主决定如何行动才能更好地达成目标。

29

30
31

以“提升响应力”为例,团队目标设定为80%的需求可以在1周内提测,2周内交付。通过云效的数据,团队随时都可以看到当前进展。

32

有明确的目标,不断检视现状与目标的差距,行动向目标对焦,形成了一个PDCA改进循环。主动承诺目标,不断改进达成目标,团队从中获得了前所未有的信心和动力,如同高速旋转的飞轮,能够很容易地保持高速发展,成为一支超强战队。

B2B业务稳定后移交其他团队维护,原有B2B团队从零开始开发智能化CRM。业务换了,团队人员也有更替,团队战斗力不减。

2019年1月数据显示,无新增或遗留线上问题,85.7%(30/35)的需求在一周内发布,需求平均开发周期(开始开发到发布完成)为6天,累计需求交付偏差(实际交付日期与计划交付日期的偏差累加)为-6天。产品负责人体验后称赞说:“我前几天体验了下我们的crm,虽然有些细节不是很完善,但是这么短时间能做成这样,真的挺不错的!”。

三、结语

33

治病需要内外兼治,改进也要内外兼修。安全信任的环境鼓励团队自律自治,团队自身的改进则要明确目标透明问题,建立起持续改进循环。

我并无医治百病的灵丹妙药,唯愿有体察病人的仁心、不断精进的医术,帮助他人疏解疾苦,焕发生机。

“有时治愈,时常缓解,总是安慰"。与读者诸君共勉。


看完本文,你有什么疑问和感想呢?欢迎在评论区与作者交流讨论。

相关阅读:

如何使用云效看板,让需求持续快速地流动和交付

阿里如何定义团队的研发效能?

开站会就是在浪费时间?看看阿里的站会姿势

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

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章