每日站会，两周一迭代，有自己的“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你所在的团队有哪些敏捷实践已经偏离了敏捷的初衷？从敏捷精神出发，你还可找到哪些小而美好方法？