【转】敏捷开发,你真的做对了吗?

缘起

2017年3月,应移动事业群智能营销平台项目管理部负责人邀请,我开始支持智能营销平台CRM团队。智能营销平台是阿里文娱广告团队,是阿里巴巴淘外变现的主力军。CRM团队负责开发和维护CRM系统。CRM系统服务于销售和代理商,串起商机管理、客户开发、合同管理、风控审核、账户管理、财务结算等业务链条。CRM系统的质量和交付速度,直接影响销售和代理商服务广告主的效率和体验。

3月初我访谈了销售、产品、开发、测试等团队核心成员,并观察了团队的周会、站会和需求讨论会。当时团队的目标是在3月25日交付框架合同功能,主要工作围绕框架合同功能开展。根据访谈内容梳理出框架合同项目研发过程的时间线如下:

75f0346ea6652427ee0acf376594717c09c3206c

从图中可以看出,这个项目基本按照瀑布模式推进,开发2个月后整体提测,测试1个月后一次性发布。开发2个多月后,业务方才有机会试用产品并给出反馈。

这个项目暴露了瀑布模式的弊端:

1.接力棒的协作模式带来信息差

9a212d1655c7cdca5ec74c4191d4685c02aa9013

瀑布模式下,业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理,再从产品经理传递给研发团队。信息每经过一次传递都有损失,业务方、研发团队得到的大部分是二手信息;产品经理成为团队沟通的瓶颈,业务方和研发团队直接讨论可以解决的问题,要经过两轮甚至多轮沟通才能达成共识;业务方和研发团队缺乏相互理解,研发团队不了解需求背后真正的业务诉求,业务方不了解技术方案背后的权衡。

2.难以响应变化

瀑布模式下,所有的需求分析和设计工作在开发前完成,并假设需求不会改变,研发过程只需遵循最初的项目计划和范围。实际项目中,变化在所难免。 即使再多花一倍的时间评审需求和制定项目计划,也无法预见所有的变化。事实也正如此,框架合同项目中业务方组织结构调整,客户URL与销售的映射关系发生变化,原有的设计无法兼容这种变化,已实现的功能需要重新设计。正如何勉老师在《精益产品开发》所说:“希望一开始就能设定完整和正确的需求,这对软件产品越来越不可能,因为用户也不知道或说不清楚自己想要什么。事实上,对需求的发掘和理解,应该是一个持续的过程,需要不断地反馈。”

3.很迟才得到用户反馈

瀑布模式下,所有的产出在项目末期交付,项目的风险也累计到最后,项目过程中没有机会验证假设和得到真实反馈。框架合同项目中,业务方在3月初才第一次试用产品,此时距离发布时间不到两周,反馈的大部分问题在发布前来不及修改。3月底发布后,产品功能持续迭代了数月,才达到业务方的期待。

CRM团队深受其痛,团队的诉求主要有:

1.业务、产品、研发密切协作,作为一个团队为共同的目标努力。

395f02f6d38cdae2596fcb133fd2afa50a75d4d5

2.缩短需求交付时长,贴合业务需要完善CRM系统。

改进方案和落地实施

结合团队的诉求和CRM团队的实际情况,与智能营销平台业务、产品、研发、项目管理负责人沟通后,确定了改进方案。改进方案聚焦于两点:

1. 组建One Team,促进跨部门协作

One Team由业务、产品、研发核心成员组成,后来又加入了负责产品落地的运营同学。

c2cc79cc4fed6f7ec81e46fa8e0e55f6fbe1e5ce

One Team负责制定季度产品规划。以往各职能部门分头组织季度规划,业务、产品、研发的目标可能有偏差,执行过程中容易对需求优先级产生分歧。One Team成立后,成员共同制定季度规划。目标对齐后,团队的工作围绕季度规划展开,对需求优先级容易达成共识。看一下CRM KA的例子:

6afde9e82d3bf721bbce35f8fb3dca1a3dd84da7

 

产品路线图

e17623e777fd5b010ebd0c8b64834d0699833baf

2018财年Q1的季度规划执行情况

 

One Team召开双周会,会议有3个固定议题:

  • 回顾上个迭代已发布功能的用户反馈;
  • 同步当前迭代的进展;
  • 梳理下个迭代的核心需求。

通过One Team双周会,串起了需求反馈环。大家不再局限于部门和角色分工,快速同步信息,迅速解决问题。以前用户反馈的问题在部门间层层流转可能几个月才解决,现在双周会上大家商量一下方案立即排期解决。

be757a2d90ae13cd45647df115dba675f64359ab

2. 向迭代模式转型,缩短需求交付时长

One Team成员商议后,在月迭代和双周迭代之间选择了更有挑战的双周迭代。

从瀑布模式向迭代模式转型有两个关键的实践:拆分需求和建立节奏。

拆分需求是小步迭代的前提,对于刚刚转型到双周迭代的团队,我们没有一刀切。进入研发环节前,需求最好拆分到1周内可以提测的粒度,以便在一个迭代内发布。如果需求确实难以拆分,也可以跨迭代交付。同时我们会关注需求的开发时长,以此衡量需求的粒度。期待随着实践的深入,越来越多的需求可以在一个迭代内发布。

需求拆分采用用户故事地图方法:对于一个复杂的大需求,按照用户在特定场景下要解决的问题切分出用户旅程,每次发布尽量交付一个完整的用户旅程。一般会按照从简单到复杂的顺序,先实现MVP(Minimum Viable Product),交付一个最简单的用户旅程。在此基础上不断丰富和完善,逐步实现附加功能和定制功能。以下是一个需求拆分的实例,其中“普遍品专询价”和“普通品专合同”组成了一个MVP。

d969f4ebed378b2efdcb023fd68c18d08ae77b2f

对敏捷开发有个普遍的误解,敏捷就是快,需求没定义清楚就急于开工。事实上,这么做往往得不偿失。正如Marco Behler所说:程序员的生产力始于“恰当的需求”。

0a2ee5b9ab9e7b64b6b4a9b7c91254d001186b36

为了减少研发过程的返工和浪费,需求进入研发前要符合准入标准DoR(Definition of Ready),发布前要符合准出标准DoD(Definition of Done)。需求发布后,产品经理会观测埋点数据,业务和运营会搜集用户反馈。One Team会上大家根据用户反馈决定下一步的改进和优化。

ebe57fc6428ee39147e2b04dff02494dc7379d47

迭代活动有节奏地进行,迭代才能有序运转。One Team成员商议后,一致同意尝试如下的节奏:

 

47a49f532841f51f7e2c966ed286cf114618de98

从图中可以看出,本迭代的开发测试与下迭代的需求分析并发进行,这样可以最大限度地减少研发环节的等待。代价是部分开发和测试同学要投入一些精力梳理下个迭代的需求,例如评估技术可行性、澄清验收标准。大部分的需求梳理工作在One Team双周会上进行,如果双周会上发现一些待确认的问题,会记录下来并由专人负责跟进。

 

迭代第一天,研发团队按照优先级把符合准入标准的需求拉入迭代,做初步的设计和估算。根据估算做出严肃的承诺,并制定研发计划:

 

ce0d1225724d3dcd1f040e6328485fabebe4a932

从图中可以看出,为了降低风险和分散压力,团队尽量做到小批量逐步提测。提测前测试同学会设计好测试用例,提测时开发同学要跑通P0、P1测试用例。测试同学验证基本功能可用,立即邀请产品经理和业务同学试用,以便尽快发现体验问题。功能发布前,业务方验收即将发布的版本,业务验收通过后才可以发布。

 

在确定节奏的同时,我们对迭代活动的产出、责任人、截止日期做了明确约定。大家分工协作,迭代很快有序运转起来:

ff66ac88cd81c265109157dcbf03d0610d760bfa

为了增加透明性,我们用工作流描述需求状态的流转:

 

8aeb41095ec4aa91b3c09e2f8b66b5ce4523d867

用看板跟踪需求的状态:

 

6df76268bdd0798cd2836cc7fd343d42125b3b4a

效果评估

1.One Team机制促进跨部门协作

业务、产品、研发之间曾经相互埋怨,业务觉得交付的功能不是最需要的,急需的功能反而没给做,研发觉得辛苦做出来的功能没人用非常冤,产品夹在中间两头受气。

One Team机制落地后,大家综合权衡业务价值、技术风险、人员情况、外部依赖、投入产出比等相关因素,一起决定需求优先级。即便最初大家的意见不一致,通过开诚布公的讨论,对最后的结论也能够认可,并积极推进执行。CRM SME双周会上,产品经理预先准备了一些产品优化需求。业务方提出目前更需要看到数据报表。大家迅速达成共识,数据报表是最高优先级,产品优化需求靠后。

CRM产品团队季度总结时,CRM KA的产品经理和业务接口人表示:One Team机制建立以来,跑通了业务需求从提出到上线后反馈的大闭环,业务、产品、研发有序协作,接下来会把这个机制顺利地运转下去。

CRM SME的业务接口人在邮件中提到:“目前中小CRM的产品工作在正常有序推进,项目进行的同时,也在积极进行存量需求的消化”,并感谢团队付出的努力。

智能营销平台的技术负责人高度评价One Team机制:“不仅提升了团队的开发效率,也提升了团队的沟通效率”。

One Team成员在持续的协作中,增进了信任和了解,研发更了解业务,业务也更体谅研发。以下是两个具体的例子:

05a51cc53370fdf73e9b184b95241b8124904cef

2.双周迭代缩短需求交付时长

CRM团队的所有需求都在Aone中跟踪,团队在站会上更新需求状态,根据需求状态流转生成的统计图表能够反映真实情况。

双周迭代的首要目标是缩短需求交付时长。结合这个目标,我们主要关注2个指标:开发时长和从开发到发布的交付时长。需求拆分得越小,开发时长越短,越适合迭代开发。交付时长越短,研发团队的适应性越好。业务需要时,团队能够迅速实现需求并交付到用户手里。

CRM KA团队从6月中开始尝试双周迭代,开发时长和交付时长的周移动平均值如下:

 

9191e57dc487bfb50a92096b9fce547a193526dd

从图中可以看出,开发时长从12天缩短到6天以下,说明需求拆分得更小了。交付时长基本都在20天以内,唯一的例外是7月31日至8月6日一周。原因是这部分功能要跟关联方同步上线,CRM KA团队完成了开发测试后,等待两周才与关联方联调上线。

 

值得一提的是,在向双周迭代转型的过程中,CRM团队保持了很高的质量水准,无论是提测质量、线上质量还是缺陷修复速度,都达到了集团领先水平。

e297ade2357f9319d2ba1bada15aae243767005d

更短的交付时长、更频密地交付功能,有利于快速验证假设、交付价值、响应变化。以业务方急需的数据报表为例,CRM团队把55个业务指标按照优先级分批交付,确保每两周都交付一些报表,缩短了业务方的等待时间,贴合业务方的反馈快速调整和优化,赢得了业务方的高度肯定。

应对挑战

在人力有限的情况下,如何以最快的速度、最低的成本迅速满足业务发展的需要,是CRM团队在未来一段时间内面临的最大挑战。One Team和双周迭代的实践为团队通力协作、小步快跑、持续改进奠定了基础,未来继续深化敏捷实践能够获得更大的收益。

1. 聚焦于持续快速交付业务价值

相比于交付更多功能,我们更应关注为业务带来了多大价值。从众多的需求中,如何发掘提炼出业务价值最高的需求?在多种解决方案中,如何找到最佳迭代路线优先解决业务痛点?把80/20原则发挥到极致,我们就有机会以小博大,为业务发展赢得更多机遇。要做到这一点,需要我们善于取舍,相比于决定做什么,更重要的是决定不做什么。相比于一次性交付一个大而全的解决方案,更合理的是先实现一个小而轻的方案满足核心用户的核心诉求,迅速交付给用户使用,基于真实的用户反馈迭代优化。

2. 用技术手段提高生产率

相比于项目结束时一次性发布,每两周都发布的确会带来额外的发布成本,例如回归测试的成本、部署上线的成本。为了获得双周迭代带来的灵活性,我们要想办法不断降低发布成本,直至发布变得如此容易以至于我们完全可以忽略发布成本。这正是持续集成、持续部署等敏捷工程实践解决的问题。

持续部署流水线能够实现从代码提交到单元测试、静态扫描、编译、打包、部署、测试、发布全流程的自动化。把一切重复的工作交给机器,解放工程师去做更有创造性的工作,是提升效率的根本之道。CRM测试团队已经实现部分自动化测试,也有自动编译打包的Jenkins job,再努力一步完全可以实现持续集成、甚至持续部署。智能营销平台测试团队已经在朝着这个方向努力,这是非常有价值的工作。如果研发同学也加入进来,大家齐心协力,相信很快就有成果。

总结

通过One Team机制,业务、产品、研发间增进了信任和了解,彼此协作更顺畅。

通过拆分需求和有节奏的短迭代,CRM团队从瀑布开发模式比较顺利地转型到了迭代开发模式。发布频率从数月一次变为两周数次,基本做到6天以内提测,20天以内发布。更可喜的是,在转型过程中,团队保持了高质量。

研发团队持续快速交付业务急需的功能,得到了业务团队的高度认可。

转自:《敏捷开发,你真的做对了吗?阿里文娱广告团队敏捷实践总结》 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/439140.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

CCNA-第七篇-思科私有路由协议-EIGRP-初级

CCNA-第七篇-思科私有路由协议-EIGRP 首先呢这个EIGRP之前呢, 路由协议是分几种的 一个叫距离向量协议RIP,IGRP(都过时了) 一个觉链路状态协议OSPF,IS-IS这些 还有个叫混合型的EIGRP 但是呢,这些只是书本上的定义,实际上没人会跟你说这个东东 这个怎么区分呢? 第一个呢,只传递…

CCNA-第八篇-OSPF-上

CCNA-第八篇-OSPF OSPF,最常用的路由协议,他来了他来了 OSPF呢怎么说呢 是一个比较重要而且比较基础的点,出到去外面要是说不会OSPF,那还算啥网络工程师 但是呢,他也不是那么的完全重要.因为很多小地方压根就用不到.但是列你不能不会呀 到了OSPF呢,配置就会逐渐的多那么一点点…

CCNA-第九篇-OSPF下+VLAN开篇初介绍

CCNA-第九篇-OSPF下VLAN开篇初介绍 补充一下官网的PPT对于DR/BDR的描述 邻居-drothers 和drothers之间的关系–2WAY 彼此之间只会交换hello包来让邻居正常通信,不交换LSA 邻接-dr/bdr/drothers的关系,-FULL 交换hello包与LSA信息 224.0.0.5-公用 224.0.0.6-仅有DR/BDR监听 其…

CCNA-第十篇-VLAN-下

CCNA-第十篇-VLAN-下 讲真,这个技术点没啥好讲的,很好理解.也很基础 通俗的说就是一个框框. . 其实理论上来说呢,CCNA是应该先教交换的再到路由的,哈哈,不过倒过来了,倒就倒吧.这里开始讲交换技术 LAN-内网 WAN-外网 VLAN虚拟局域网(一般用于内网) 交换机可以转发广播数据…

Office Web Apps安装部署(一)

系统要求为Windows Server 2012, 注意:安装Office Web Apps的服务器除了Office Web Apps之外,不能安装其他应用。包括不能安装Office,lync,,sharepoint等应用,即要单独部署。 安装IIS 7.0 打开服务器管理…

CCNA-第十一篇-VTP+STP(上)

CCNA-第十一篇-VTPSTP(上) VTP:VLAN中继协议(VLAN Trunking protocol )利用第2层中继帧,在一组交换机之间进行VLAN通信 STP:生成树,交换机的冗余协议 MSTP:多实例生成树,STP的进化版本. 然后先说说上次接口 思科有2种,华为有3种 access,t…

Office Web Apps安装部署(二)

SharePoint 2013调用Office Web Apps 注意:调用OfficeWebApps的sharepoint应用的身份认证必须是基于声明的身份认证(claims-based authentication) 首先安装好SharePoint2013,我在此部署文档中使用的是免费的sharepiont foundat…

CCNA-第十二篇-STP+ACL(下)

CCNA-第十二篇-STPACL(下) 首先说说要跳跳了 立个小FLAG, 两个月内急速完成CCIE理论LAB实操 因为接了个工作,主要我能做到就能做这份工作. 其实NP中间的点很多都会,只是因为笔记弄不急了, 就放到CSDN上重新复习学习一次. 下几篇开始就要起飞到CCIE了 后面还有个NAT还有一点SDN…

CCNA-第十三篇-NAT-上

CCNA-第十三篇-NAT-上 NAT- netword address translation 网络地址转换 NAT不仅仅是用于共享地址上网,NAT是一个很大的东西 核心思想是转换地址,以及端口号 NAT也分静态和动态 TAG:NAT很多时候也叫做端口映射,只是一个叫法而已 不只是设备,电脑本身也有端口号的哦! 电脑查…

entity framework6 edmx文件详解

entity framework中的edmx文件作为代码与数据库沟通的桥梁,作用是至关重要的。如果edmx文件出了问题,ef就基本上没得用了。虽然edmx文件是由ef自动生成的,但是一些特定的操作可能会引发ef的bug,从而导致edmx文件出错,并…

CCNA-第十四篇-NAT-下+链路聚合(LACP)+DHCP

CCNA-第十四篇-NAT-下 这一篇是是针对一下华为设备的nat,然后讲讲链路聚合 下一篇来一个DHCP一点点的SDN的介绍 **然后讲完SDN就基本上CCNA结束了哦**华为的链路聚合叫Eth-trunk 思科的链路聚合叫Ether-Channel 华为静态NAT 环境如下 首先把他的telnet开起来,server也是…

[Sharepoint2007对象模型]第一回:服务器场(SPFarm)

Sharepoint是微软一个很重要的服务器产品,它可以方便的创建和维护一个网站,在Sharepoint的管理中心提供了很强大的管理工具。同时为了更加灵活的后期定制和开发,Sharepoint提供了完整的对象模型,对象模型也就相当于Sharepoint的二…

CCNA-第十五篇-DHCP配置+SDN介绍(最后一章)

CCNA-第十五篇-DHCP配置SDN介绍 各位好,如果有一直看下来的谢谢支持 这里是CCNA的最后一篇了,如果真的能吸收很多内容,那么普通的东西基本上都没什么大问题了.除非就是工作经验 下一篇就到一个CCNA的综合实验了 DHCP 思科 创造一个dhcp地址池名字为dhcp 宣告网段为192.168…

[Sharepoint2007对象模型]第二回:Web应用程序服务(SPWebService)

在上一回中说了Sharepoint中的服务器场,在服务器场中最重要的一个服务就是Web应用程序服务。我们自己的Sharepoint网站都是借助于这个服务才能正常运行的,也就是说所有的Sharepoint站点都是搭建在这个服务之上的。Web应用程序服务对应的对象模型为&#…

CCNA-第十六篇-综合实验

CCNA-第十六篇-综合实验 环境以及拓扑图如下 TAG:个人说明,做到最后我才发现hostname打错了,IDC-1打成ISP-1了,不过也没关系,知道就行了,全部的IDC都打成ISP了还有一个的话 ,如果经常弹这个东西可以自己解决 这个是半双工和全双工的意思,毕竟这里是模拟器.也正常, 在接口下打…

[Sharepoint2007对象模型]第三回:Web应用程序(SPWebApplication)

在Sharepoint的管理中心创建一个网站的顺序大致如下:创建Web应用程序-〉创建网站集。所以Web应用程序是网站的一个基础,在一个Web应用程序下可以创建多个网站,本回就主要来介绍Web应用程序这个对象模型以及如何使用对象模型来创建一个Web应用…

CCNP-第一篇-思科SLA+华为BFD+ODR+浮动路由

CCNP-第一篇-CCNP-第一篇-思科SLA华为BFDODR浮动路由 从这就开始NP了,老规矩,先路由后交换,开搞 到了NP之后的配置会多很多很多哦!一篇很长过万字都不出奇. 思科静态路由浮动路由SLA检测 什么叫浮动路由呢?在双线的情况下做备份. 我们知道,路由都是有cost有优先级这个东西的…

SharePoint 2013开发入门探索(二)- 列表操作

我们如何用代码对SharePoint列表做些例如增删改查的操作呢?如果您的程序可以部署到服务器上,就可以使用 服务器对象模型,因为服务器对象模型提供的功能最多,限制最少;否则可能要选择客户对象模型等其他方式&#xff0c…

CCNP-第二篇-SLA扩展+EIGRP高级版(上)

CCNP-第二篇-SLA扩展EIGRP高级版 还是这个环境的SLA 我们想一个问题哈,如果会有抖动呢? 比如左边是主线路,右边是备用的,那如果左边的时候只是偶尔断了一个包,然后他就跳到备用了,然后bfd检测到又跳回来了,这样如此循环,这个就叫做网络抖动,我们有啥办法让他不这样操作呢? …

SharePoint 2013开发入门探索(一)- 自定义列表

在SharePoint 2013中创建自定义列表的方式有很多,在网站内容页面添加应用程序就可以创建(站点内容-〉 您的应用程序),也可以通过SharePoint Designer 2013创建,而本文将描述的是用Visual Studio 2012 创建自定义列表的…