今天你敏捷了没有？敏捷开发以其能快速满足不断变化的用户需求正在逐渐成为互联网行业主流，这一西方国家的舶来品能够在国内流行起来绝非偶然，其强大的推动力带来的不仅是人效上的大幅提升，更是研发思想上的革命性转变。
京东企业信息化部有这样一个团队，在接触“敏捷”概念的短短半年内，他们对于“敏捷”可谓是知其然，更知其所以然。他们成功地将敏捷模式应用到逻辑复杂且需求模糊的法务系统开发项目中，不仅高质量地完成了任务而且缩短了工期，节约了大量的业务成本，获得了业务方高度赞扬。
01 我们是怎么做敏捷的
我们的敏捷实践可以简单的总结为以下几点：
1.用户需求不明确，故事地图来帮忙；
2.任务拆分与估算，粒度控制很关键；
3.每日更新燃尽图，进度、风险易监控；
4.迎接变更心态好，控制变更有策略；
5.持续交付小步跑，反馈及时调整快；
6.团队主动求创新，业务价值增亮点。
02 项目背景
业务方需求
●法务流程繁琐，线下消耗人工多，且容易出现遗漏和错误；
●法务相关数据分布广，人工收集、统计耗时耗力；
●业务方迫切需要系统提高工作效率和工作准确性。
项目难点
业务方要求尽快上线，心情迫切，但是需求描述十分不明确。
03 敏捷执行过程
需求分析
由于法务业务逻辑复杂，用户需求不明确，所以团队采用用户故事地图方法，一个个讨论用户故事。先对整体需求进行梳理，确定主干流程，再逐步完善次等级的故事，这样整个需求的框架和脉络就清晰了，需求的优先级也确定了。就像下面的蒙娜丽莎图一样，先画轮廓，再逐步完善细节。
整个迭代的发布计划也遵循这样的敏捷策略，逐级交付。下图黄色的为MVP功能，依次类推。
任务拆分与估算
针对每一条需求，开发人员从技术实现的角度，进行技术拆分, 这也是对技术方案进行梳理和构思的过程，同时引入一名高级观察者就技术方案进行把关。任务拆分完成后，开发人员对每一项任务以扑克牌的形式进行工时估算。
如果相互偏差小于40%，则按照PERT算法的结果记为最终结果；如果相互偏差大于40%，则大家讨论研究后，重新再进行一轮估算，此轮结果记为最终结论。经过严谨的估算过程，绝大部分任务粒度被控制在3-5小时内，没有超过10小时的任务。
任务拆分和估算完成后，研发5人员自主领取任务，没有人指派。每名研发需要权衡领取任务的总工时实际可利用总工时，如果超出太多说明负荷过重。任务在研发之间有时需要相互转移，以便团队成员领取的工时基本平衡。
▼ 任务拆分时展开的技术讨论
▼ 工时估算
早会制度
每天早上10点，团队成员准时召开站立会。团队内部工作进展和状态是非常透明的，每个人简短说明前一日做了什么，今天计划做什么任务，更重要的是反馈有什么问题、难点和依赖或瓶颈事项，但并不对具体问题深入展开讨论，必要的情况下会另外组会。此外，为了确保研发对业务需求的符合性，团队还会不定期的邀请业务方参加早会。
▼ 早会情形
进度和风险控制
燃尽图每日更新，通过曲线的走势，可以直观地发现问题，对项目进行有力监控。
内部评审会议制度
正式评审会议前，为了确保业务方评审顺利通过，团队会进行内部的预评审会议。
敏捷工程实践
▼ 团队实施的敏捷工程实践
应对和拥抱变化
●团队主动拥抱变化
之前的迭代评审只有业务方接口人参加，为了提高需求的准确性，更广泛的收集用户对产品的第一手意见和反馈，团队主动邀请多名终端使用者参加迭代评审会议。这个措施起到了很好的效果，用户的需求变更数增加了3倍多。
●把控需求变更，引导用户发掘最根本需求
评审会议上，业务方有时提出的需求变更对项目的影响是巨大的，需要对整体架构进行改动。这种情况下，团队成员并不是一味接受需求，而与业务方一起评估需求，并提出更为可行的、高效的解决方案，最终达成一致，实现双赢。
▼ 迭代评审会
●让业务方感到“嗨”的需求变更
研发召开头脑风暴会议，采用创新思维，讨论添加用户没有想到的需求。业务方不仅感到满意更感到意外。
回顾会议
团队定期召开回顾会议，大家畅所欲言。风险和弱点有解决方案和跟踪措施直至关闭。
▼ 回顾会议的讨论
▼ 回顾会议记录墙
问题与措施
在研发过程中，也遇到一些问题，我们是怎么应对的呢？
●开发资源无法全部投入到敏捷项目中
每周固定运维时间处理其他工作，其余时间全部投入敏捷迭代开发
●存在工作方式和认知层面的差异
Scrum Master不仅要指导团队按照敏捷的流程和方法进行开发工作，更重要的是引导团队转变原有的思维模式，适应、接受并运用敏捷的思维，逐步在行为中体现出敏捷的原则和价值观。例如，欣然的接受和拥抱变化；有勇气尝试自己不熟悉的领域等。
业务方的参与程度
为了确保研发出的产品最大限度地满足用户的需求，研发团队非常注重业务方的参与。
04 敏捷带来的效果
极大地降低需求不确定性带来的风险
由于分级和持续地交付，业务方能够及时进行反馈，每次评审都有需求变更, 因此研发可以及时进行相应调整。这样避免了项目后期发生巨大变更造成的影响。
上左图是每次迭代实际发生的需求变更数。由于反馈及时，产品的开发能够得到及时的调整，变更数也逐步趋于降低，变更的成本也比较低。
右图是按照传统瀑布模式进行变更假设图。 因为业务方只有在上线后才能够看到产品，变更将在上线阶段有爆发性的增长。就像一个房子建好以后要挪动房梁一样，此时的变更成本是巨大的。
缩短了交付周期
高效透明的自组织管理、持续的交付与反馈以及团队及时的响应变更、拥抱变化，使得项目由原来计划的7轮迭代缩短至6轮迭代，也增加了用户的满意度。
提高了业务方的满意度
▼ 业务方的反馈
研发人员思想的转变
面对需求变更，研发人员不仅逐渐有欣然面对的心态，而且还主动为业务方提供创新的业务价值解决方案。
05 敏捷要成功，需要一个精诚合作的团队
