写点什么

企业级敏捷转型三部曲

2019 年 10 月 21 日

企业级敏捷转型三部曲


本文根据宁锐和张迎辉 TiD2019 分享话题《数据驱动的企业级敏捷转型》整理,经嘉宾授权进行刊发。


很荣幸有机会跟大家交流,今天分享的内容分为四部分:


  • 背景

  • 效果

  • 方案

  • 总结和展望


背景


剔除股权激励费用后,2018 财年阿里健康首次扭亏为盈。实现这个突破,需要开辟新业务,同时老业务要提效。这些最终都会落到产品技术上。阿里健康的技术负责人给我们一个愿景,就是研发绝对不能拖业务的后腿。这是敏捷转型的大背景。具体来讲,阿里健康敏捷转型主要为了解决研发过程中出现的不透明、不准时、响应慢的问题。


不透明


有个团队,研发同学说产品经理不关心研发进展,交付了就行。实际上产品经理自己维护了一个 Excel 表格,记录需求的排期计划和当前进展。产品经理要逐个问研发,才能获得最新进展。还有一个团队,业务想了解研发进展,分头找开发负责人和产品负责人,得到两份不同结果,都不知道该信哪一个。敏捷转型后,研发进展一目了然,这些问题都解决了。


不准时


有些业务线延期的情况比较严重,不是延期几天,是延期几周甚至几个月。改进之后,业务同学反馈延期情况大有改善。


响应慢


以前大一点儿的需求基本都要一个多月才开始交付。改进后,基本一周内有交付。


效果


给大家看一下敏捷转型的效果。


我们从质量、响应力和准时性三方面来看。


2018 年 11 月才有数据,给大家看的是从 2018 年 11 月到 2019 年 2 月的数据。


质量



我们主要看线上问题的数量。2018 年 12 月有一条业务线做了比较大的技术改造,线上问题比较多。除此之外,线上问题很少。


响应力


我们看两个指标:周发布需求占比和平均交付时长。



“周发布需求占比”统计一个月内,7 个自然日内发布的需求(从开始开发到发布结束)占所有当月发布需求的比例。左侧是整体指标,右侧是各业务线指标。2018 年 10 月我们定的目标是周发布需求占比达到 40%。2018 年 11 月的基线数据是 4.5%,2019 年 1 月达到了 64.2%,2019 年 2 月进一步提升到了 68.9%,而且各业务线周发布需求占比都达到了 40%以上。



“平均交付时长”统计一个月内,发布需求的平均周期时长(从开始开发到发布结束)。2018 年 11 月的基线数据是 20 天,2018 年 12 月提升到了 8 天,2019 年 1 月和 2 月也保持了这个水准。各业务线的平均交付时长有起伏,基本趋势在下降。


准时性



我们看需求交付累计偏差。


“需求交付累计偏差”统计一个月内,需求的实际交付日期与承诺交付日期的偏差之和。偏差为正,延期较多;偏差为负,提前较多。2018 年 11 和 12 月延期比较多,2019 年 1 月和 2 月稍有提前。这个指标越接近于零越好,说明交付既准时又靠谱。


以上是敏捷转型的效果。


方案


我们怎样做到,接下来看一下方案:


  • 透明过程,获取基线

  • 建立反馈环,自驱改进

  • 立体式辅导,赋能团队


这就是企业级敏捷转型三步曲


按时间顺序,这个方案挺容易理解:


一开始先摸一模情况,就要提升透明性。


然后,根据愿景定远期目标。远期目标一步到不了,先看下一步去哪里,就有了近期目标。研发过程透明了,随时知道现状。现状跟目标有差距,尝试改进。改进一段,看看现状:离目标近了,改进有效继续保持;离目标远了,改进无效尝试新招。这样就建立了一个基于反馈的改进环。不用敏捷教练推动,团队自己就能往前走。


过程中出现一些问题,可能是团队缺少全局视角或没有经验,敏捷教练要及时引导。还有一些具体技能,比如,怎么把大需求拆小,需要帮团队快速 get 起来。这就需要赋能团队。


透明过程,获取基线


先给大家介绍第一步“透明过程,获取基线”。


透明过程


先看“透明过程”。



所谓“事在人为”,要做事,先圈人。首先,识别干系人,把关键的干系人都动员起来,围绕共同的愿景和目标一起来做这件事。其次,明确角色和职责,大家分工协作,一步步推动目标实现。


有一些新角色,给大家介绍一下:


  • 产品负责人 - Product Owner


产品负责人是产品团队的领导者,负责产品的大方向和价值排序。


  • 特性负责人 - Feature Owner


如果把实现复杂特性当做一个项目,特性负责人(以下简称 FO)就是这个项目的项目经理。FO 起到穿针引线的作用,不是所有事情都自己做,而是把不同角色的工作串在一起,使得协作更顺畅,风险更可控。



FO 什么时候进入?基本上产品经理有了需求的概要设计,就可以跟技术团队的负责人申请 FO 支持。FO 由开发或测试自愿兼任,一般选择相对熟悉这个特性的同学。FO 会参与需求的全流程,从需求分析,到排期计划、交付上线,直至效果验证。FO 的工作像空气,平时不容易感到它的存在,缺了它却难受至极。不少同学说工作特别忙乱,却不知道从何处下手,也许就是缺了 FO 带来的清新流畅。


  • 团队教练 - Team Coach


我们是公司层面的敏捷教练,团队教练是团队层面的敏捷教练,帮助所在的团队提效。团队教练也是开发或测试自愿兼任。


大家也许会好奇,FO 和团队教练一样要干活,也不多拿钱,谁愿意做呢?有经验的工程师都知道,做一个需求,写代码只是其中一部分,沟通协调常常花掉更多时间。项目要成功,团队需要有人擅长沟通协调。做 FO 和团队教练可以很好地锻炼沟通协调能力。做得好,团队会认可,将来遇到合适的机会就有更多的发展空间。另外,我们经常给团队教练和 FO 开小灶,帮助大家发展各种软技能。因此,还有挺多同学自愿举手的。


以需求评审为分界点,之前是需求规划阶段,之后是需求交付阶段。需求规划阶段产品经理主导。需求交付阶段 FO 推进。


新角色到位,各司其职。我们看一下需求规划和需求交付过程中,大家怎么分工协作?



需求规划阶段,我们建议让 FO 早点儿进去。为什么呢?我们的业务挺复杂。如果开发在评审时才第一次看到需求,很难在短时间内理解这么复杂的东西。这个评审可能进行得不彻底,很多东西没聊明白,就糊里糊涂进开发,开发过程中就会有很多问题冒出来。因此,我们建议 FO 作为先遣部队早点儿进去。


那 FO 都协助产品经理做什么呢?归根结底一句话,帮助产品经理提升需求的质量。比如需求颗粒度比较大,FO 可以跟产品经理建议拆一拆。产品经理赞同的话,FO 可以组织一个用户故事地图工作坊。做完工作坊,需求按用户场景拆开了,优先级也明确了。然后按优先级逐步澄清需求,滚动进入开发。需求颗粒度合适了,需求澄清到位了,进入开发后很少出现反复,交付过程更顺畅,大家都觉得很舒服。


图中的树状视图,帮我们保留了需求之间的层次关系。有了这棵树,拆分后我们仍然知道为什么要做这些叶子需求,能跟最终的业务目标挂上钩。



需求通过了评审,研发同学会把它接过来。为了接得好,FO 要做不少工作。


第一个是做计划。需求评审后开工前,FO 要组织相关的开发、测试、依赖方一起制定排期计划,并请产品和业务同学确认交付日期能够满足业务需要。


有人说敏捷不需要计划,走哪儿算哪儿。今天一看交不了,就找产品经理说我们遇到困难了明天交付。明天遇到困难就后天交。这样开发是挺爽,产品和业务怎么办?可以说,只要跟别人合作,就需要计划。有了计划,大家才能更好地协同。困难在于,做软件是一个跟意外做斗争的过程,很少有需求在做的过程中没有任何意外。所以,计划不能没有,但是可以调整。



认为计划定了就不能调,恐怕是把计划和承诺混为一谈。其实,计划和承诺是有区别的。


不出现严重的不可抗力,一定要按承诺日期交付。图中的期望日期就是承诺日期。研发的交付日期可能会影响到产品和业务同学的工作安排,所以承诺日期一定要跟产品和业务确认。出现风险时,也要第一时间跟大家商量。


计划则是在当前情况下根据了解的信息做的一个最好猜测。情况发生了变化或者有了新的信息,计划当然要跟着调整。


为了达成承诺,在计划交付日期之外可以留几天缓冲。还有很重要的一点,不要过早承诺。需求评审通过了,说明需求聊得比较清楚了,方案也比较可行了,这时候再去承诺比较靠谱。对需求还不了解,就盲目地拍一个承诺日期,对团队和业务都不好。


另一个是推动进展。研发过程中遇到困难,团队是想办法还是找理由,结果还是挺不一样的。我们鼓励团队优先想办法,努力达成承诺。实在不能按期交付,可以先舍弃部分低优先级功能,仍然按期交付最重要的功能。对于潜在的风险,要主动识别并制定预案。自己做足功课,而不是把结果交给运气。


有了前面的铺垫,研发同学只要及时更新需求状态,干系人就可以随时了解研发进展。


获取基线


再看“获取基线”,这里主要介绍研发过程的度量。


其实度量的方法取决于目标。如果减肥的目标是变苗条,就要度量身体的维度。如果减肥的目标是变健康,就要关注体脂率。从这个角度看,度量是客观世界的反馈,帮你看看是不是走在接近目标的方向上,离目标还有多远。



这是我杜撰的:SMART goals,REAL data : )


  • Relevant


目标来源于想解决的问题,度量指标则取决于目标。有句话说:“度量什么,就得到什么”。其实也可以反过来,想得到什么,就度量什么。


  • Easy To collect


我们只选择那些容易获取的度量指标。最理想的情况下,研发正常做自己的工作,不需要任何额外的开销,度量指标自动就获取到了。现在研发只要更新需求的状态,就能自动获得度量指标并生成报表。


  • Accurate


我们只选择那些能说清楚的、大家有共识的指标。我们曾经想统计发布频率。可是怎样才算一次发布呢?是发布一次变更还是一个完整功能?如果一个功能涉及到多个应用,算一次发布还是多次发布呢?既然一时说不清,我们只好先舍弃这个指标。


  • Least side effects


我们希望度量如同一面镜子,给团队一个客观反馈。要做到这一点,需要一个合理的指标体系。比如前面提到的需求交付累计偏差,团队多留一点缓冲肯定都准时交付了。不过这样一来,交付时长就会增加。



有效的反馈一定要及时。目标可以按月定,却不能月底时才看指标。因为为时已晚,想努力也来不及了。我们做了一个工具,可以自动发日报。如果觉得日报还不够及时,可以在网页上随时看查看最新的度量数据。


我们还嵌入了一些简单的规则,比如需求进入开发时要填写排期计划。没填的话,工具会标红提醒。另外,开发中和测试中停留时长特别短,可能没及时更新状态。这种情况会提示需求时长数据不准确,时长再短也不会计入周发布需求。





给大家看一下日报的汇总、在研需求进展和已完成需求详情。这些都是工具生成后自动推送到邮箱的。


建立馈环


接下来给大家介绍第二步“建立反馈环,自驱改进”。


组建改进小组


这次敏捷转型涉及到 3 个事业部,覆盖 7 条业务线。这么大的范围,一定要上下结合:既要获得决策层的支持,又要得到一线团队的认可。


为了把大家团结在一起,我们组建了周发布小组。这是一个虚拟的小组,成员包括各业务线开发负责人、测试负责人、职能经理和团队教练。这个小组对公司层面的改进目标负责,帮助团队解决问题移除障碍。


周发布小组每两周碰面,回顾上一期的 action,review 近两周的研发效能指标,确定下一期的 action。Review 效能指标时,每个团队都跟两周前的自己比。有些团队进步很大,就跟大家分享经验。有些团队遇到了困难和瓶颈,大家一起帮忙分析原因想办法。令我们感动的是,阿里健康研发部负责人挤出时间参加周发布小组的会议,认真倾听团队遇到的问题,主动帮忙推动解决,给了我们极大的支持。


引入丰田改进板



丰田改进板与普通的改进环有一个不同,就是团队要先有一个愿景。这个愿景必须是团队非常想要的。我们一般会问团队:先不考虑眼前的困难,真正想要的理想状态是什么?想得越清楚细致越好,最好活生生的画面就在眼前。为什么要让愿景变成活生生的画面?因为这样才有动力。如果先去想有多少困难和问题,团队动能很低,容易被困在原地;如果先去想一个很美好的未来,团队动能很高,愿意去行动。美好的愿景通常一步到不了,就需要一步步分解成够得着的目标。想想下一步可以到哪里,做什么才能往前走。


这里是一个团队的丰田改进板。上面有到 2019 年 3 月底的财年目标,还有分解到每个月的月度目标。团队教练每周会更新这个板,绿色说明进展很顺利,红色说明有风险。比如最近研发过程的缺陷比较多,理想目标是研发过程零缺陷,第一步先减少会 block 测试的严重缺陷,对应的 action 就是提高提测质量,确保自测用例通过。


立体式辅导


最后,我们来看一下“立体式辅导,赋能团队”。



通过前面两步,团队有目标了,也知道差距在哪儿,还能能想出一些不错的改进方法。不过团队可能缺少经验,比如不知道需求该怎么拆,不知道怎么高效开会,甚至都不知道自己不知道什么。这时敏捷教练要及时辅导。团队处在不同的阶段,辅导方式也不同。


一开始找对问题很重要。2018 年 10 月,我们访谈了很多人,包括业务、产品、开发、测试,有 leader 也有一线员工。搜集的问题和建议我们反馈给研发团队。团队感到很意外,因为有些问题他们从未意识到。有团队交付了一个功能给业务小二用,研发挺开心的以为可以帮助业务提效。业务反馈说功能有了,体验真的有点坑。操作起来非常复杂,本来十分钟可以搞定,现在要一个小时。经过这件事,研发和业务的联动密切了,研发经常往业务那边跑,看看业务同学到底是怎么操作的。这时,敏捷教练相当于一个桥梁,把问题带回来,看有哪些改机的机会。可喜的是,很多研发 leader 现在会主动跑去问产品经理和业务同学,最近上线的功能好不好用,研发这边有什么需要改进的。摸清了问题,就知道劲儿往哪里使,改进目标就清晰了。


每个团队的问题不一样,目标也不一样。结合团队的目标和实际情况,我们会出一个建议方案。最终采不采纳,由团队决定。只要能达成目标,团队完全可以决定改进方案和落地节奏。


辅导团队的过程中,我们发现对于什么是敏捷以及为何要敏捷,大家还不是很清晰,就做了一个敏捷导入培训,帮大家澄清敏捷的理念和原则。到了具体的技能,我们发现培训效果不是特别好,反而是实战效果更好。比如用户故事地图,我们就拿真实需求来拆解。先是敏捷教练引导,然后教会团队教练,团队教练再教 FO,会的人越来越多了,这个实践就扎实了。


敏捷落地在神不在形,很多时候要根据具体的上下文检视和调整。我们没有把重点落在规范流程上,而是把重点落在培养人上。我们花大力气培养了团队教练和 FO,给他们开小灶,创造机会练习。比如,我先组织一个回顾会,我做你看。然后,我和团队教练共同准备下一个回顾会,团队教练来主持,你做我看。看完以后我给你反馈。下次你再做,就比之前进步了。越做越好,后来就放心让你独立做了。2019 年 3 月阿里健康举办了敏捷分享沙龙,很多团队教练从实践中悟出来独到的东西,非常接地气,引起了大家的共鸣。


敏捷教练不会永远在团队身边,发现团队越来越会自己走的时候,我们会逐步地往后退一些。以前发现问题我们会第一时间提醒团队,现在会等上几天,团队多半都会自己发现自己解决,这也意味着到了要放手的时候了。


以上是阿里健康的企业级敏捷转型三部曲。


总结和展望


我们先做一个简单的总结。



先看一下敏捷宜忌。


有些同学觉得做敏捷就是把需求拆小,让数据好看。其实我们不是为敏捷而敏捷,更不是为数据而敏捷。我们不断引导团队快速低成本交付价值,拿到业务结果,为价值而敏捷。


有些团队自我感觉很好,看数据的时候,才发现还有不少值得改进的地方。主观感觉有时给我们虚幻的安全感,客观数据可以把我们拉回现实。


甩锅给别人很容易,可是不解决问题。比如说需求太大,研发团队可以责备产品经理没有拆需求,也可以拉上产品经理一起拆。产品经理发现拆解过程中,需求梳理得更清晰了,下次就会主动邀请研发一起拆需求。从自己能做的做起来,做出效果,伙伴们也会受到感染一起做起来。


家里小朋友发烧了,是不是立马吃退烧药?多半不是。要查明原因,对症下药才行。我们看到团队的问题,通常也不会立马扑上去救火,而是挖掘深层次的原因,从根源上解决和预防。



接着,跟大家分享一下对未来的展望。


过去,我们的重点在提升效能。未来,我们的重点在助力业务。


敏捷转型从研发部发起,主要解决研发效能跟不上业务发展的痛点。当研发效能不再是瓶颈,我们要引导团队关注业务价值。从被动地接需求,到主动思考:这个需求给谁做,解决什么问题,对业务成长有什么贡献。



需求开工前,我们希望团队思考需求的价值。这是我们配置的一个模板,新建需求时自动引导大家去填写客户价值和业务价值。这个实践已经落地一段时间了。不少同学反馈:一开始填不出来,因为以前很少去想为什么要做这个需求,要达到怎样的效果,都是拿来需求就想怎么实现。深挖一下,最后发现是可以填出来的。这个过程中,开始从客户视角和业务视角来考虑问题。这是非常好的转变。


需求交付后,我们希望团队验证需求的效果。我们增加了两个属性:客户体验效果和业务价值效果。客户体验效果,给内部小二做的需求,由小二来填,给 C 端用户做的需求,产品经理代表用户填。业务价值效果,一般由运营同学根据业务指标来填。需求发布了,我们还要跟踪效果,分析业务数据,优化产品,形成基于业务价值的反馈闭环。


今天的分享就到这里。谢谢大家!


嘉宾介绍:


宁锐,阿里健康敏捷教练,全栈工程师。辅导阿里健康研发团队敏捷转型,支持阿里健康企业级敏捷转型。


张迎辉,敏捷教练,独立咨询师。开发和讲授阿里巴巴多门敏捷公开课,支持淘宝直播、优酷、阿里健康敏捷转型。TiD2018、RSG2018、PMI2017 项目管理大会讲者。


2019 年 10 月 21 日 14:281383

评论

发布
暂无评论
发现更多内容

多个 SSH keys 的配置,方便 Git 对不同仓库的使用与管理

与光

git GitHub SSH

TOTO 2020再次荣获iF、红点两项国际设计大奖

极客编

《Linux就该这么学》笔记(二)

编程随想曲

Linux

用SpreadJS实现在线Excel的录入与展示,提升企业医保信息化服务水平

Geek_Willie

SpreadJS 医保信息化 在线excel

使用jdbcSstoragerHandler 处理mysql、oracle 、hive数据

杨飞

Java 编程基础

michaelliu

我常用的在线工具清单

彭宏豪95

效率 效率工具 工具

智浪

Neil

后浪 智能时代 智浪

KubeFATE:在Kubernetes上部署联邦学习平台

亨利笔记

人工智能 学习 FATE KUBEFATE

CDN云课堂 | EdgeRoutine技术专家教你把JS代码跑到CDN边缘

巨侠说

Java CDN edge

基于XGB单机训练VS基于SPARK并行预测(XGBoost4j-spark无痛人流解决方案)

黄崇远@数据虫巢

学习 算法

如何推动与影响中型前端团队的成长

堂主

前端 研发管理 团队建设

GrowingIO 微服务 SaaS 与私有部署运行实践

GrowingIO技术专栏

大数据 微服务架构 SaaS

可视化 Tekton 组件 Tekton Dashboard

郭旭东

Kubernetes cicd

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (四)关于单元测试的常见错误观念和做法

编程道与术

Java 编程 软件测试 TDD 单元测试

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (五)第一个单元测试

编程道与术

Java 编程 软件测试 TDD 单元测试

通过一个聊天应用学习 Deno

寇云

typescript 后端

想退休,可能没机会了

池建强

读书感悟

延时任务的几种实现方式

郭儿的跋涉

Java 延时任务 延时消息

工作两年简历写成这样,谁要你呀!

小傅哥

面试 小傅哥 Java 面试 简历优化 找工作

交易上链——中心化数字资产交易所的完美解决之道

MaxHu

区块链 智能合约 数字货币 去中心化网络 数字资产

算法工程师的发展路径

Lucien

DD 测试linux性能

HU

CDN云课堂 |可编程CDN – EdgeScript应用场景、语言速览和实操演示

巨侠说

CDN百科 | 最近,你的APP崩了吗?

巨侠说

CDN

CDN百科 | 假如没有CDN,网络世界会变成什么样?

巨侠说

Spring 中不同依赖注入方式的对比与剖析

Deecyn

spring

谈谈控制感(2):怎么让我们更健康

史方远

个人成长 心理

视达荣登ChinaBang Awards 2020智慧零售榜Top10

极客编

MySQL数据类型DECIMAL用法

Simon

MySQL

聊聊Serverless

kimmking

NLP领域的2020年大事记及2021展望

NLP领域的2020年大事记及2021展望

企业级敏捷转型三部曲-InfoQ