快速交付 敏捷开发的特点_京东产品经理谈敏捷：如何推动团队持续敏捷转型...

推行传统团队进行持续敏捷转型，需要天时、地利、人和。因为业务发展需要，我们新增加了B仓的业务模式，在针对相关业务设计产品时，不论从业务发展还是从产品规划角度，短期的确定性和长期的不确定性与敏捷的特性不谋而合。

为了能够让产品快速落地试错，我首先与研发团队的leader进行了沟通，让人欣喜若狂的是，他是一个敏捷推崇者，并且已经具有多年实践的经验。为了让敏捷在团队推行顺利，我建议整个研发团队能够固定人员，同时申请敏捷教练加入，期望先通过单个项目来推动团队持续的敏捷转型。

7FRESH资深产品经理 吕彦

破局第一步：转变产品设计思维方式

作为产品经理，在敏捷实践的过程中，最深刻的体验莫过于产品实现思路的转变。在转变的过程中我更深刻地感受到瀑布式思维对产品经理的“戕害”，长周期的开发封闭，要求产品必须站的高看的远，在一开始就必须把产品设计的大而全。文档变成了又臭又长的“裹脚布”：与其说文档是为了帮助测试研发详尽地了解需求，不如说是产品经理为自己后续一个多月内答疑准备的备忘录。瀑布式的设计思维同样也导致在交付研发后，大而全的模块无法持续、快速交付并且往往在最后交付的时刻出现各种各样的“惊喜”。

以往的工作经验告诉我，研发和测试更加需要先看到“锦绣河山”，再逐步去探寻一座座大山中的瑰宝。怎么能从大而全再聚焦当下，像树木生长出的年轮那般，一圈一圈，一个闭环一个闭环去设计自己的产品，是对产品的考验，是需要我们持续关注和改进的地方，也是推进敏捷和引导研发快速交付的制胜点。

为了快速让产品和业务方看到效果，产品经理比研发团队更需要敏捷的思想。成本中心针对新业务模式核心要实现的就是能够即时监控相关成本的发生，对成本进行提前预估，以及成本的预实对比等功能。在瀑布式管理产品时，我会按照从基础配置到最终展现的方式去规划优先级和顺序，按照这种方式预估工作量几乎得花去2个月的时间，我们的业务部门已经饱受摧残，如此之长的等待时间恐怕是早已心灰意冷不会再爱了。

而在通过敏捷去推动产品落地时，我对产品模块的拆分方式和优先级评估方式进行了改变。以终为始，将业务方关心的核心指标划分优先级，再来评估为了实现每一个指标的计算和展示，前置的产品模块需要实现哪些功能，最终以此确认每个迭代具体要交付的内容。这样能够让业务方按照重要程度逐步、尽可能快地看到心中所想，以解他们燃眉之急。

从设计到体验，在这一过程中我们引导业务方更加深入的参与到每个迭代中来，团队持续的向业务展示实现的功能，在迭代过程中也不断根据业务方反馈进行后续产品故事的规划，这种互动方式得到了业务方的认可，同时也有利于调动研发团队的主动性，持续增强团队信心，稳定团队的研发交付节奏。

破局第二步：理论结合实践高效故事拆分

在敏捷推行的过程中，我还体会到了别样的拆分敏捷用户故事（user story）的方式：故事并不是产品经理（Product owner）一步拆好的。敏捷教练为了让大家对故事都有更深的理解，PO只需要拆到比较大的故事模块（EPIC故事），模块下具体的用户故事是由研发来完成的。团队通过用户故事地图的方式，将需求拆分并梳理清楚后，PO排列优先级并进行版本划分，然后研发再集体估算用户故事的工作量，并在此基础上划分出整体的迭代计划。这种做法起先引起了我的困惑，从前的理论到实践都告诉我，PO全权负责故事的拆分，且只需要评估当前迭代可以完成的故事内容，当我带着困惑再去仔细琢磨敏捷的理论知识时却惊奇地发现王新老师的引导做法完全满足了故事拆分DEEP的原则。这个方法不仅体现了敏捷的特点，还增加了创新性的内容，更容易落地：从产品演进过程来看，产品和需求依然是滚动式的从模糊到清晰的过程；团队按照敏捷持续交付的方式开发，与产品演进过程相匹配。从与业务方沟通角度来看，通过团队开发能力来预估未来需要实现的所有故事所需要的周期，可以为业务方提供项目大致完成的时间点以及产品演进的大致规划；从研发角度，团队通过故事拆分，全局观较强， 能更深理解用户故事，对技术架构和产品脉络有更全面的了解，可以有效避免团队在后续迭代计划拆分任务时陷入瀑布式的思维方式。考虑敏捷的特点，前期的产品规划是适度和高效的，这种迭代计划会前进行的产品规划会有很重要的意义。

破局第三步：深入计划誓与团队肩并肩

在sprint计划会中，再一次体现出产品经理深度参与的重要性以及开计划会的必要性。在第一轮迭代计划会前，我们已经进行过三次需求讨论和一次用户故事地图拆分会（前期产品规划会），PBL中的需求也更为清晰。敏捷教练王新老师也觉得，迭代计划会议应该会很顺利，如果实在太忙， 在研发讨论如何技术实现的环节，产品可以提前离场。但是之前的经验告诉我，还是坚持到底为妙。果然，每拆一个任务，都会发现大家对产品故事细节理解存在不一致。对产品来说，即使之前觉得特别合理的功能点，放到当下再去思考，都未必值得去实现；对研发团队来说，之前大家对将一个任务拆分到4~8小时这种细粒度多少有些抵触，但在此时才发现很多细节其实或是被忽略了，或是团队对同一个任务理解不一致，或是上下任务关联有漏掉考虑的地方。至此，大家才理解了细粒度拆分的必要性。而研发同学对每个故事用心的思考，对拆分任务合理性的评估，都大大降低了产品经理日常被叫去答疑的概率，研发团队开发的过程也顺畅了很多。大家都充分利用了sprint plan的时间把风险和问题提前暴露并解决了。第一个迭代我们按时完成了本轮迭代所有的用户故事。

在后续的迭代中，虽然我们仍然有问题暴露，但是通过敏捷的方式，交付的需求能够得到迅速的验证和反馈，我们有机会及时进行任务调整、故事更新，最终保证了整个产品的成功。

写在最后的感慨

这个竞争异常残酷的世界，谁快谁就能活，谁能低成本试错，谁就有机会，如果我们能够做到一天一集成，一天一发布，我们前进的步伐肯定也会发生质的飞跃。我非常赞同目前敏捷逐步推行的方式，不对理论生搬硬套：故事拆分的改变、项目推行和敏捷的结合、大众熟知的“人天评估”替代“点数评估”，引导团队尽可能早的交付业务最关心的内容。

正是在敏捷教练王新老师的引导下，整个团队都在努力思考如何才能尽可能早的让业务方体验产品。在每一个迭代结束后，通过敏捷回顾，不断让团队主动意识到敏捷对工作效率的提升。

任何事情都不是一蹴而就的。我想，我们的团队还需要不断磨合，不断调整自己的工作方式。在后面的产品故事设计和产品需求交付时，作为产品经理的我一定会坚持深入到敏捷团队中，摒弃伤透研发心的“死生不复相见”模式，开启“朝思暮想”模式，让产品在敏捷中不断强大，更高效地服务于业务。

敏捷教练结束语：“这个产品之所以能获得成功， 产品经理起到了至关重要的作用。产品经理理解持续、快速交付的重要意义，因此持续交付的源动力来自价值流的上游，通过产品经理的牵引力带动团队持续交付的节奏。”

（来源：京东零售技术 产品经理吕彦）