看完他们的故事，你一定会怀疑自己走了假敏捷！

01、我们是怎么做敏捷的

我们的敏捷实践可以简单的总结为以下几点：

1.用户需求不明确，故事地图来帮忙；

2.任务拆分与估算，粒度控制很关键；

3.每日更新燃尽图，进度、风险易监控；

4.迎接变更心态好，控制变更有策略；

5.持续交付小步跑，反馈及时调整快；

6.团队主动求创新，业务价值增亮点。

•法务流程繁琐，线下消耗人工多，且容易出现遗漏和错误；

•法务相关数据分布广，人工收集、统计耗时耗力；

•业务方迫切需要系统提高工作效率和工作准确性。

业务方要求尽快上线，心情迫切，但是需求描述十分不明确。

由于法务业务逻辑复杂，用户需求不明确，所以团队采用用户故事地图方法，一个个讨论用户故事。先对整体需求进行梳理，确定主干流程，再逐步完善次等级的故事，这样整个需求的框架和脉络就清晰了，需求的优先级也确定了。就像下面的蒙娜丽莎图一样，先画轮廓，再逐步完善细节。

整个迭代的发布计划也遵循这样的敏捷策略，逐级交付。下图黄色的为MVP功能，依次类推。

（2）任务拆分与估算

针对每一条需求，开发人员从技术实现的角度，进行技术拆分, 这也是对技术方案进行梳理和构思的过程，同时引入一名高级观察者就技术方案进行把关。任务拆分完成后，开发人员对每一项任务以扑克牌的形式进行工时估算。

如果相互偏差小于40%，则按照PERT算法的结果记为最终结果；如果相互偏差大于40%，则大家讨论研究后，重新再进行一轮估算，此轮结果记为最终结论。经过严谨的估算过程，绝大部分任务粒度被控制在3-5小时内，没有超过10小时的任务。

任务拆分和估算完成后，研发5人员自主领取任务，没有人指派。每名研发需要权衡领取任务的总工时实际可利用总工时，如果超出太多说明负荷过重。任务在研发之间有时需要相互转移，以便团队成员领取的工时基本平衡。

（3）早会制度

每天早上10点，团队成员准时召开站立会。团队内部工作进展和状态是非常透明的，每个人简短说明前一日做了什么，今天计划做什么任务，更重要的是反馈有什么问题、难点和依赖或瓶颈事项，但并不对具体问题深入展开讨论，必要的情况下会另外组会。此外，为了确保研发对业务需求的符合性，团队还会不定期的邀请业务方参加早会。

燃尽图每日更新，通过曲线的走势，可以直观地发现问题，对项目进行有力监控。

（5）内部评审会议制度

正式评审会议前，为了确保业务方评审顺利通过，团队会进行内部的预评审会议。

（6）敏捷工程实践

▼ 团队实施的敏捷工程实践

（7）应对和拥抱变化

• 团队主动拥抱变化

之前的迭代评审只有业务方接口人参加，为了提高需求的准确性，更广泛的收集用户对产品的第一手意见和反馈，团队主动邀请多名终端使用者参加迭代评审会议。这个措施起到了很好的效果，用户的需求变更数增加了3倍多。 

• 把控需求变更，引导用户发掘最根本需求

评审会议上，业务方有时提出的需求变更对项目的影响是巨大的，需要对整体架构进行改动。这种情况下，团队成员并不是一味接受需求，而与业务方一起评估需求，并提出更为可行的、高效的解决方案，最终达成一致，实现双赢。

▼ 迭代评审会

• 让业务方感到“嗨”的需求变更

研发召开头脑风暴会议，采用创新思维，讨论添加用户没有想到的需求。业务方不仅感到满意更感到意外。

（8）回顾会议

团队定期召开回顾会议，大家畅所欲言。风险和弱点有解决方案和跟踪措施直至关闭。

（9）问题与措施

在研发过程中，也遇到一些问题，我们是怎么应对的呢？ 

• 开发资源无法全部投入到敏捷项目中

每周固定运维时间处理其他工作，其余时间全部投入敏捷迭代开发

• 存在工作方式和认知层面的差异

Scrum Master不仅要指导团队按照敏捷的流程和方法进行开发工作，更重要的是引导团队转变原有的思维模式，适应、接受并运用敏捷的思维，逐步在行为中体现出敏捷的原则和价值观。例如，欣然的接受和拥抱变化；有勇气尝试自己不熟悉的领域等。 

（10）业务方的参与程度

为了确保研发出的产品最大限度地满足用户的需求，研发团队非常注重业务方的参与。

04、敏捷带来的效果

由于分级和持续地交付，业务方能够及时进行反馈，每次评审都有需求变更, 因此研发可以及时进行相应调整。这样避免了项目后期发生巨大变更造成的影响。 

上左图是每次迭代实际发生的需求变更数。由于反馈及时，产品的开发能够得到及时的调整，变更数也逐步趋于降低，变更的成本也比较低。

右图是按照传统瀑布模式进行变更假设图。 因为业务方只有在上线后才能够看到产品，变更将在上线阶段有爆发性的增长。就像一个房子建好以后要挪动房梁一样，此时的变更成本是巨大的。

（2）缩短了交付周期

高效透明的自组织管理、持续的交付与反馈以及团队及时的响应变更、拥抱变化，使得项目由原来计划的7轮迭代缩短至6轮迭代，也增加了用户的满意度。   

▼ 业务方的反馈

（4）研发人员思想的转变

面对需求变更，研发人员不仅逐渐有欣然面对的心态，而且还主动为业务方提供创新的业务价值解决方案。

05、敏捷要成功，需要一个精诚合作的团队

文章来源：京东信息化