敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结
jopen 6年前
<p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/94cc21316ef5a8757be6bb5d2a0f36e1.jpg" /></p> <p>很多人对敏捷开发有个普遍的误解，认为敏捷就是快，经常在需求没定义清楚的情况下就急于开工。事实上，这样做往往得不偿失。今天，我们邀请阿里巴巴敏捷教练问菊，为我们带来阿里文娱广告团队敏捷实践，看看他们是如何做敏捷开发的。</p> <p><strong>缘起</strong></p> <p>2017 年 3 月，应移动事业群智能营销平台项目管理部负责人邀请，我开始支持智能营销平台 CRM 团队。智能营销平台是阿里文娱广告团队，是阿里巴巴淘外变现的主力军。CRM 团队负责开发和维护 CRM 系统。CRM 系统服务于销售和代理商，串起商机管理、客户开发、合同管理、风控审核、账户管理、财务结算等业务链条。CRM 系统的质量和交付速度，直接影响销售和代理商服务广告主的效率和体验。</p> <p>3 月初我访谈了销售、产品、开发、测试等团队核心成员，并观察了团队的周会、站会和需求讨论会。当时团队的目标是在 3 月 25 日交付框架合同功能，主要工作围绕框架合同功能开展。根据访谈内容梳理出框架合同项目研发过程的时间线如下：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/3d4f0858817642d5f61a5d683b487085.jpg" /></p> <p>从图中可以看出，这个项目基本按照瀑布模式推进，开发 2 个月后整体提测，测试 1 个月后一次性发布。开发 2 个多月后，业务方才有机会试用产品并给出反馈。</p> <p>这个项目暴露了瀑布模式的弊端：</p> <p><strong>1. 接力棒的协作模式带来信息差</strong></p> <p> </p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/1957e614565868be2cfb6db7ef135ff3.jpg" /></p> <p>瀑布模式下，业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理，再从产品经理传递给研发团队。信息每经过一次传递都有损失，业务方、研发团队得到的大部分是二手信息；产品经理成为团队沟通的瓶颈，业务方和研发团队直接讨论可以解决的问题，要经过两轮甚至多轮沟通才能达成共识；业务方和研发团队缺乏相互理解，研发团队不了解需求背后真正的业务诉求，业务方不了解技术方案背后的权衡。</p> <p><strong>2. 难以响应变化</strong></p> <p>瀑布模式下，所有的需求分析和设计工作在开发前完成，并假设需求不会改变，研发过程只需遵循最初的项目计划和范围。实际项目中，变化在所难免。 即使再多花一倍的时间评审需求和制定项目计划，也无法预见所有的变化。事实也正如此，框架合同项目中业务方组织结构调整，客户 URL 与销售的映射关系发生变化，原有的设计无法兼容这种变化，已实现的功能需要重新设计。正如何勉老师在《精益产品开发》所说：“希望一开始就能设定完整和正确的需求，这对软件产品越来越不可能，因为用户也不知道或说不清楚自己想要什么。事实上，对需求的发掘和理解，应该是一个持续的过程，需要不断地反馈。”</p> <p><strong>3. 很迟才得到用户反馈</strong></p> <p>瀑布模式下，所有的产出在项目末期交付，项目的风险也累计到最后，项目过程中没有机会验证假设和得到真实反馈。框架合同项目中，业务方在 3 月初才第一次试用产品，此时距离发布时间不到两周，反馈的大部分问题在发布前来不及修改。3 月底发布后，产品功能持续迭代了数月，才达到业务方的期待。</p> <p>CRM 团队深受其痛，团队的诉求主要有：</p> <p>1. 业务、产品、研发密切协作，作为一个团队为共同的目标努力。</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/d764f641c8212a258f18f3fa784faeff.jpg" /></p> <p>2. 缩短需求交付时长，贴合业务需要完善 CRM 系统。</p> <p><strong>改进方案和落地实施</strong></p> <p>结合团队的诉求和 CRM 团队的实际情况，与智能营销平台业务、产品、研发、项目管理负责人沟通后，确定了改进方案。改进方案聚焦于两点：</p> <p><strong>1. 组建 One Team，促进跨部门协作</strong></p> <p>One Team 由业务、产品、研发核心成员组成，后来又加入了负责产品落地的运营同学。</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/0f0fcb33590f25d40f8fa14ac7500b16.jpg" /></p> <p>One Team 负责制定季度产品规划。以往各职能部门分头组织季度规划，业务、产品、研发的目标可能有偏差，执行过程中容易对需求优先级产生分歧。One Team 成立后，成员共同制定季度规划。目标对齐后，团队的工作围绕季度规划展开，对需求优先级容易达成共识。看一下 CRM KA 的例子：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/4a443e3757d4d52a806d5bf7108f2098.jpg" /></p> <p style="text-align:center">产品路线图</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/d526557da91b6c6ff06d8648277441b7.jpg" /></p> <p style="text-align:center">2018 财年 Q1 的季度规划执行情况</p> <p>One Team 召开双周会，会议有 3 个固定议题：</p> <ul> <li> <p>回顾上个迭代已发布功能的用户反馈；</p> </li> <li> <p>同步当前迭代的进展；</p> </li> <li> <p>梳理下个迭代的核心需求。</p> </li> </ul> <p>通过 One Team 双周会，串起了需求反馈环。大家不再局限于部门和角色分工，快速同步信息，迅速解决问题。以前用户反馈的问题在部门间层层流转可能几个月才解决，现在双周会上大家商量一下方案立即排期解决。</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/d1cae149e8a5549fb32b205f12653c00.jpg" /></p> <p><strong>2. 向迭代模式转型，缩短需求交付时长</strong></p> <p>One Team 成员商议后，在月迭代和双周迭代之间选择了更有挑战的双周迭代。</p> <p>从瀑布模式向迭代模式转型有两个关键的实践：拆分需求和建立节奏。</p> <p>拆分需求是小步迭代的前提，对于刚刚转型到双周迭代的团队，我们没有一刀切。进入研发环节前，需求最好拆分到 1 周内可以提测的粒度，以便在一个迭代内发布。如果需求确实难以拆分，也可以跨迭代交付。同时我们会关注需求的开发时长，以此衡量需求的粒度。期待随着实践的深入，越来越多的需求可以在一个迭代内发布。</p> <p>需求拆分采用用户故事地图方法：对于一个复杂的大需求，按照用户在特定场景下要解决的问题切分出用户旅程，每次发布尽量交付一个完整的用户旅程。一般会按照从简单到复杂的顺序，先实现 MVP（Minimum Viable Product），交付一个最简单的用户旅程。在此基础上不断丰富和完善，逐步实现附加功能和定制功能。以下是一个需求拆分的实例，其中“普遍品专询价”和“普通品专合同”组成了一个 MVP。</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/7a4050caf2bf0784df03d41c84308145.jpg" /></p> <p>对敏捷开发有个普遍的误解，敏捷就是快，需求没定义清楚就急于开工。事实上，这么做往往得不偿失。正如 Marco Behler 所说：程序员的生产力始于“恰当的需求”。</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/e8a9e5d3efb0c79da5d82ddc88c3dd2c.jpg" /></p> <p>为了减少研发过程的返工和浪费，需求进入研发前要符合准入标准 DoR（Definition of Ready），发布前要符合准出标准 DoD（Definition of Done)。需求发布后，产品经理会观测埋点数据，业务和运营会搜集用户反馈。One Team 会上大家根据用户反馈决定下一步的改进和优化。</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/a11a174748fdd3dfae75538bde463c18.jpg" /></p> <p>迭代活动有节奏地进行，迭代才能有序运转。One Team 成员商议后，一致同意尝试如下的节奏：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/78ecee7c5ff0f493b4ed893cc4d0e080.jpg" /></p> <p>从图中可以看出，本迭代的开发测试与下迭代的需求分析并发进行，这样可以最大限度地减少研发环节的等待。代价是部分开发和测试同学要投入一些精力梳理下个迭代的需求，例如评估技术可行性、澄清验收标准。大部分的需求梳理工作在 One Team 双周会上进行，如果双周会上发现一些待确认的问题，会记录下来并由专人负责跟进。</p> <p>迭代第一天，研发团队按照优先级把符合准入标准的需求拉入迭代，做初步的设计和估算。根据估算做出严肃的承诺，并制定研发计划：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/939027e7c574e26a8229cfaf0161273a.jpg" /></p> <p><br /> 从图中可以看出，为了降低风险和分散压力，团队尽量做到小批量逐步提测。提测前测试同学会设计好测试用例，提测时开发同学要跑通 P0、P1 测试用例。测试同学验证基本功能可用，立即邀请产品经理和业务同学试用，以便尽快发现体验问题。功能发布前，业务方验收即将发布的版本，业务验收通过后才可以发布。</p> <p>在确定节奏的同时，我们对迭代活动的产出、责任人、截止日期做了明确约定。大家分工协作，迭代很快有序运转起来：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/ae1978dad9a93a3bd9d9f61021e6833b.jpg" /></p> <p>为了增加透明性，我们用工作流描述需求状态的流转：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/d6e637880c94a703e19945cc1bf2be43.jpg" /></p> <p>用看板跟踪需求的状态：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/7cde2c360b921433a5cbaebb0035aa5d.jpg" /></p> <p><strong>效果评估</strong></p> <p><strong>1. One Team 机制促进跨部门协作</strong></p> <p>业务、产品、研发之间曾经相互埋怨，业务觉得交付的功能不是最需要的，急需的功能反而没给做，研发觉得辛苦做出来的功能没人用非常冤，产品夹在中间两头受气。</p> <p>One Team 机制落地后，大家综合权衡业务价值、技术风险、人员情况、外部依赖、投入产出比等相关因素，一起决定需求优先级。即便最初大家的意见不一致，通过开诚布公的讨论，对最后的结论也能够认可，并积极推进执行。CRM SME 双周会上，产品经理预先准备了一些产品优化需求。业务方提出目前更需要看到数据报表。大家迅速达成共识，数据报表是最高优先级，产品优化需求靠后。</p> <p>CRM 产品团队季度总结时，CRM KA 的产品经理和业务接口人表示：One Team 机制建立以来，跑通了业务需求从提出到上线后反馈的大闭环，业务、产品、研发有序协作，接下来会把这个机制顺利地运转下去。</p> <p>CRM SME 的业务接口人在邮件中提到：“目前中小 CRM 的产品工作在正常有序推进，项目进行的同时，也在积极进行存量需求的消化”，并感谢团队付出的努力。</p> <p>智能营销平台的技术负责人高度评价 One Team 机制：“不仅提升了团队的开发效率，也提升了团队的沟通效率”。</p> <p>One Team 成员在持续的协作中，增进了信任和了解，研发更了解业务，业务也更体谅研发。以下是两个具体的例子：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/8ecb7a19a70a983039ae31d5b31d81c0.jpg" /></p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/0173393e36102f7ecb4a60db3cb5a27c.jpg" /></p> <p><strong>2. 双周迭代缩短需求交付时长</strong></p> <p>CRM 团队的所有需求都在 Aone 中跟踪，团队在站会上更新需求状态，根据需求状态流转生成的统计图表能够反映真实情况。</p> <p>双周迭代的首要目标是缩短需求交付时长。结合这个目标，我们主要关注 2 个指标：开发时长和从开发到发布的交付时长。需求拆分得越小，开发时长越短，越适合迭代开发。交付时长越短，研发团队的适应性越好。业务需要时，团队能够迅速实现需求并交付到用户手里。</p> <p>CRM KA 团队从 6 月中开始尝试双周迭代，开发时长和交付时长的周移动平均值如下：</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/c107ba4efc37cf3871090199632fd486.jpg" /></p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/3b91f5305b07018d53f74a43f3f32431.jpg" /></p> <p>从图中可以看出，开发时长从 12 天缩短到 6 天以下，说明需求拆分得更小了。交付时长基本都在 20 天以内，唯一的例外是 7 月 31 日至 8 月 6 日一周。原因是这部分功能要跟关联方同步上线，CRM KA 团队完成了开发测试后，等待两周才与关联方联调上线。</p> <p>值得一提的是，在向双周迭代转型的过程中，CRM 团队保持了很高的质量水准，无论是提测质量、线上质量还是缺陷修复速度，都达到了集团领先水平。</p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/67bb3caa75a74d8517f165433f51ea28.jpg" /></p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/be50ec31d87e45b5fc5e393c306abcbc.jpg" /></p> <p style="text-align:center"><img alt="敏捷开发，你真的做对了吗？阿里文娱广告团队敏捷实践总结" src="https://simg.open-open.com/show/61a8ea041169ebdef5a57c62c9f3b34c.jpg" /></p> <p>更短的交付时长、更频密地交付功能，有利于快速验证假设、交付价值、响应变化。以业务方急需的数据报表为例，CRM 团队把 55 个业务指标按照优先级分批交付，确保每两周都交付一些报表，缩短了业务方的等待时间，贴合业务方的反馈快速调整和优化，赢得了业务方的高度肯定。</p> <p><strong>应对挑战</strong></p> <p>在人力有限的情况下，如何以最快的速度、最低的成本迅速满足业务发展的需要，是 CRM 团队在未来一段时间内面临的最大挑战。One Team 和双周迭代的实践为团队通力协作、小步快跑、持续改进奠定了基础，未来继续深化敏捷实践能够获得更大的收益。</p> <p><strong>1. 聚焦于持续快速交付业务价值</strong></p> <p>相比于交付更多功能，我们更应关注为业务带来了多大价值。从众多的需求中，如何发掘提炼出业务价值最高的需求？在多种解决方案中，如何找到最佳迭代路线优先解决业务痛点？把 80/20 原则发挥到极致，我们就有机会以小博大，为业务发展赢得更多机遇。要做到这一点，需要我们善于取舍，相比于决定做什么，更重要的是决定不做什么。相比于一次性交付一个大而全的解决方案，更合理的是先实现一个小而轻的方案满足核心用户的核心诉求，迅速交付给用户使用，基于真实的用户反馈迭代优化。</p> <p><strong>2. 用技术手段提高生产率</strong></p> <p>相比于项目结束时一次性发布，每两周都发布的确会带来额外的发布成本，例如回归测试的成本、部署上线的成本。为了获得双周迭代带来的灵活性，我们要想办法不断降低发布成本，直至发布变得如此容易以至于我们完全可以忽略发布成本。这正是持续集成、持续部署等敏捷工程实践解决的问题。</p> <p>持续部署流水线能够实现从代码提交到单元测试、静态扫描、编译、打包、部署、测试、发布全流程的自动化。把一切重复的工作交给机器，解放工程师去做更有创造性的工作，是提升效率的根本之道。CRM 测试团队已经实现部分自动化测试，也有自动编译打包的 Jenkins job，再努力一步完全可以实现持续集成、甚至持续部署。智能营销平台测试团队已经在朝着这个方向努力，这是非常有价值的工作。如果研发同学也加入进来，大家齐心协力，相信很快就有成果。</p> <p><strong>总结</strong></p> <p>通过 One Team 机制，业务、产品、研发间增进了信任和了解，彼此协作更顺畅。</p> <p>通过拆分需求和有节奏的短迭代，CRM 团队从瀑布开发模式比较顺利地转型到了迭代开发模式。发布频率从数月一次变为两周数次，基本做到 6 天以内提测，20 天以内发布。更可喜的是，在转型过程中，团队保持了高质量。</p> <p>研发团队持续快速交付业务急需的功能，得到了业务团队的高度认可。</p> <p>来自: <a href="/misc/goto?guid=4959013592490379405" id="link_source2">mp.weixin.qq.com</a></p>