小步快跑，敏捷开发的精髓！
每日站会，两周一迭代，有自己的“Scrum Master”，就是敏捷实践？No！
具备敏捷之形的团队有很多，但是，真正掌握敏捷精髓的，却并不多见。这是因为，敏捷方法属于simple but not easy（简单但并不好做）。结合我这么多年的体会来看，与其说敏捷是一场研发方式的变革，不如说是一场思维方式的变革。
今天，结合我在某试点团队中深度实践敏捷的经历，来跟你分享一下，我对敏捷精神的理解，以及在敏捷应用过程中的实施建议。
1 为何引入敏捷？
敏捷特点：小即是美（Small is beautiful）。小而美体现：
- 人：拆分成小规模（5～7人）、跨职能的小团队
- 事：拆分成一系列小而具体的交付物，按优先级排序，增量交付
- 时间：拆分成固定大小的短迭代（1～4周），在每个迭代结束后，对可工作的产出进行演示
小团队在小块时间，做出小块东西，周期性集成组装。为何当时考虑引入敏捷？要从第一个版本发布讲起。
新业务第一个版本，原本预计在春节前发布。我们基于WBS做完整项目计划，2月进行模块开发，然后用一个月的时间来做发布前的联调、功能及性能测试。
开发联调开始前，一切都理想。我们有自认为完备计划，有周会、周报和各种文档，还有任务系统的监控报表。种种途径获取的信息，都告诉我们，一切正常！
直到某天开始代码集成，准备测试，“嘭！”各种意外超出想象，项目越来越不可控：
- 集成联调比我们想像得要更复杂
- 性能稳定性调优花了更多的时间
- 一名主程离职
- 赶上过年，要放长假
- 测试人员是新人，还在熟悉业务
- ……
所有因素加在一起，把这个项目拖入了完全失控深渊，一直到38节才正式提交给用户……
最初引入敏捷就是想 发布周期更短。
2 痛点一：发布时间不可控（快速增量交付）
考虑项目实际背景，把迭代周期定一月。每月都和内部客户一起做Sprint计划及Review演示。这给我们带来哪些改进呢？
-
提早集成与测试
让问题及时暴露，更快反馈应对
-
及时规避风险
意外仍会有，但大多数情况，可在Sprint内部消化，避免更大影响
-
快速响应变化
在Sprint1演示会后，我们收到新客户提的紧急需求，立即做相应调整。若按之前模式，这时，可能很多事情我们都只做了一半，想调头不容易。短周期让我们能灵活调整方向，每个Sprint都是潜在可交付的产品
Sprint3后，我们临时安排个小Sprint，以快速将“潜在可交付”变为“真正可交付”。我们发现，在每个周期内，能真正把事做完，跟最终用户一起分享阶段性成果，对团队来说，也是很好的激励。
这时，发布周期的问题已基本解决，交付灵活性高很多，客户也更满意。
这能叫Scrum团队了吗？
3 痛点二：摆脱“接力综合征”（从对抗走向协作）
经观察总结，团队各角色协作方式仍存在一些问题。我把这叫“接力综合征”。虽交付周期变成月/次，但大家却仍在按过去方式工作。
3.1 宁愿选择等待
每人都等上环节的人把东西弄好送到自己面前，才开始工作。
“需求文档还没理清楚，急啥？”
“接口设计文档还没确认，怎么做啊？”
传统项目管理中这很正常。但这些空转时间不能给产品带来直接价值。
3.2 角色间泾渭分明
都觉得只要把份内事做完就行。如：
- 开发把工作做完，也不管做得效果，心想：“反正要丢给测试，先撤了，出问题再说。”
- 测试测出Bug：“等开发全部修完，我再接测，反正都测完了。”
各角色间有一定对抗。项目中任何一件小事都可能造成冲突。最终大家都耗在那，每人更在意“这是你的问题，不是我的问题”，却没把焦点放在达成整体目标。
传统项目管理，项目经理大部分工作就是厘清各方责任，界定权利与义务，疏通对抗情绪，并解决随之来的突发问题。但敏捷，更快速的交付压力，使这种等待和界线变得越来越难接受，我们不得不改变思路。
敏捷好比打橄榄球，所有队员都时刻关注场上比分。虽彼此有分工，但作为team，进球最关键。敏捷也一样。从敏捷思想中得到启发，开始一系列改进。
首先，开发和测试把位置搬到一起，并设定 共同的Sprint目标和完成标准。
开发做完工作后，若测试进度被卡，大家会一起着急，一起想法解决，因为影响整体进度。
其次， 从“你完成-我开始”，到我们一起完成。
敏捷团队，开发干得热火朝天时，测试也没闲，测试代码与开发代码几乎同时在写。往往代码刚“出炉”就测上，且只有测试结束并确认无BUG，开发工作才结束。使用故事点燃尽图，衡量整体进度偏差，团队约定好，只有一个功能点完全测试通过，燃尽图才往下走。
这燃尽图成了团队的计分牌，每人都关注同一目标。同时，还发明里程碑燃尽图，衡量每个迭代对整体进度贡献及多个迭代之间累积需求总量的变化，相当于一个赛季的累积记分牌。
燃尽图型项目进度模版，公众号后台领取。
这些措施打破角色间相互切分和推诿局面，共同目标让我们变成价值共同体。只有协作才能达成目标。
4 痛点三：需求理解不一致 （面对面澄清及估算）
至此，团队力量得到很好凝聚。复盘会上畅所欲言，共同得出下一个待改进项，是需求理解，技术类项目的共性。
我们没专职策划，开发人员在理解需求时，经常很困难。打开敏捷宝箱，找到一条重要价值观“ 个体与交互 > 过程与工具”。相比更多、更长的需求文档，决定采用更多的面对面交流解决这问题！
迭代计划分成：
- 产品负责人向团队和用户代表，面对面讲解收集来的各方需求，最终明确需求优先级及验证条件，即在迭代结束的Demo演示会，我们拿什么呈给用户
- 团队估算。采用敏捷估算扑克的形式，由团队成员共同给出估算结果，最后综合得出这迭代要交付的内容
团队估算过程是双向互动环节，可帮助团队和产品负责人共同加深对条目的理解。产品负责人也会根据大家反馈，及时修改、完善条目。
具体估算时，为避免干扰估算结果，当所有成员选择好代表自己估算值的纸牌后，大家同时亮牌。同时亮牌的好处： 不会有人跟风出牌，每人的估算都是经过独立思考得出，这也是扑克估算的精华所在。
若估算值差距明显，代表大家对该条目的工作量没获得共识，团队要对该条目的评估结果讨论，由max、min的牌主，分别说明自己的估算理由，并重新讨论，确定最终评估结果。
经过实践检验，这样面对面的需求沟通及评估，至少带来好处：
需求探索更深入
在计划会上，团队会直面一线用户，需求可得到面对面交流和澄清。团队估算其实也是团队共同探索需求的过程。因为只有到真正考虑要花多少成本去做时，才有各种各样问题暴露。这方法对于在早期进一步挖掘需求细节，特别有帮助。
3.2 估算结果更加全面、细致
传统项目管理也做估算。如WBS分配好任务，然后每个人估算自己的，每人都只对自己的那块任务熟悉，估算结果会有欠考虑，而团队估算就很好补足。
每个故事都会由全员出牌，各方从自己角度出发想问题，可互相补充。如估算时，测试成本也会被考虑进去，对测试成本高的功能点，开发主动想办法加强UT等白盒测试手段，估算结果自然更细致全面。
3.3 找到更优化的整体解决方案
由于各方共同参与估算，前端、中间层、后端、测试的思路能在一起交流碰撞，就利于找到最优解决方案。
这一系列敏捷尝试，始终围绕项目中切实痛点展开。从最开始缩短发布周期、经常交付可工作软件，到应对“接力综合征”，提升团队整体目标感和协作效率，再到探索更有效的需求理解及团队估算方式，增进团队交流同时，又保障需求质量。
敏捷实践的应用，带来好处：
提升客户体验：
- 更低的延误率
- 阶段性可见的产出
- 更快的反馈、适应与调整
提升管理者体验：
- 团队自主运行，管理更轻松
- 变“赶”为“引”，为共同目标奋斗
提升团队体验：
- 更高的生产力
- 更好的责任感/主人翁意识
4 总结
敏捷方法不是拿来即用，这些方法大多以敏捷思想为指导，以敏捷方法为基础，在实际场景不断演化，一点点改进出的。没任何一种方法、工具可放之四海皆准，每人都要在自己场景中思考。
真正决定一个团队是否敏捷，不在是否应用那些实践，而在实践背后是否体现敏捷精神。实战中三项最重要敏捷精神： 快速可靠交付，用户价值驱动，持续自发改进。
坚持敏捷精神，而非僵化套用特定做法。实践敏捷时，遵循小而美，每次一小步，挑个痛点集中解决，小步快跑，不断尝试优化。
做到这三点敏捷精神就是敏捷团队。
FAQ
你所在的团队有哪些敏捷实践已经偏离了敏捷的初衷？从敏捷精神出发，你还可找到哪些小而美好方法？