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

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

一、背景

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

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

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

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

1. 二者都需要“望闻问切”，系统全面分析问题，才能做出正确判断。

2. 疗效如何要看病情是否缓解，要尽快建立反馈环，获得客观全面的反馈。

3. 有哪些治疗方案，各方案的好处弊端都要一五一十告诉病人，由病人选择治疗方案。病人做好准备再开始治疗，不可欺骗病人，更不可威逼利诱。

4. 治疗过程并非坦途，病人中途胆怯退缩在所难免。唯有热情鼓励和耐心引导，不可遇难而退。

5. 授人以鱼不如授人以渔，教会病人强身健体的方法，病人可以自助甚至助人，才是上佳结果。

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

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

二、问题和解法

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

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

我为大家一一详述。

1. 建立稳定的特性团队

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

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

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

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

2. 目标对齐，过程透明

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

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

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

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

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

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

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

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

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

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

4. 协作澄清需求

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

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

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

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

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

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

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

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

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

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

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

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

5. 看板管理流动

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 实现持续集成

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

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

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

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

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

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

7. 目标驱动改进

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

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

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

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

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

三、结语

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

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

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

最后，关于敏捷管理，给大家推荐一门我最近也在看的课程：

---

号外：最近整理了之前编写的一系列内容做成了PDF，关注我并回复相应口令获取：

- 001 ：领取《Spring Boot基础教程》

- 002 ：领取《Spring Cloud基础教程》

更多内容陆续奉上，敬请期待 

- END -

 近期热文：

2019

我在星球与大家聊聊技术人的斜杠生活

看完，赶紧点个“好看”鸭

点鸭点鸭

                                                                                                       ↓↓↓↓