很多⼈认为 ，每天开站会 ，有固定时⻓的迭代 ，有⾃⼰的 “Scrum Master” ，就是在开展敏捷实践了 ，其 实不然。
具备敏捷之形的团队有很多 ，但是 ，真正掌握敏捷精髓的 ，却并不多⻅ 。这是因为 ，敏捷⽅法属于simple but not easy（简单但并不好做）。结合我这么多年的体会来看 ，与其说敏捷是⼀场研发⽅式的变⾰ ，不如 说是⼀场思维⽅式的变⾰。
今天 ，我会结合我在某试点团队中深度实践敏捷的经历 ，来跟你分享⼀下 ，我对敏捷精神的理解 ，以及在敏 捷应⽤过程中的实施建议。
为什么引⼊敏捷？
敏捷的特点 ，就是⼩即是美（Small is beautiful）。这个⼩⽽美 ，体现在⼈ 、 事、 时间三个⽅⾯：
1. ⼈：拆分成⼩规模（5〜7⼈） 、跨职能的⼩团队；
2. 事：拆分成⼀系列⼩⽽具体的交付物 ，按优先级排序 ，增量交付；
3. 时间：拆分成固定⼤⼩的短迭代（1〜4周） ，在每个迭代结束后 ，对可⼯作的产出进⾏演⽰。
总体来说 ，就是⽤⼩团队在⼩块时间 ，做出⼩块的东西来 ，并且周期性地集成组装。 为什么我们当时会考虑 引⼊敏捷呢？这就要从第⼀个版本的发布讲起了。
这个新业务的第⼀个版本 ，原本预计在春节前发布。我们基于WBS做了完整的项⽬计划 ，⽤两个⽉时间进⾏ 模块开发 ，然后⽤⼀个⽉的时间来做发布前的联调、功能及性能测试。
开发联调开始之前 ，⼀切都⾮常理想。我们有⾃认为完备的计划 ，有周会、周报和各种⽂档 ，还有任务系统
的监控报表。我们从种种途径获取到的信息 ，都在告诉我们： “⼀切正常！”
直到有⼀天 ，我们开始代码集成 ，准备测试了 ， “ 嘭！”各种意外超出了我们的想象 ，项⽬越来越不可控：
集成联调⽐我们想像得要更复杂； 性能稳定性调优花了更多的时间； 有⼀名主要开发⼈员离职；
这期间赶上了过年 ，要放⼗来天假； 测试⼈员是个新⼈ ，还在学习期
所有因素加在⼀起 ，把这个项⽬拖⼊了完全失控的深渊 ，⼀直到 “ 三·⼋”妇⼥节才正式提交给了⽤⼾ … …
最初引⼊敏捷 ，原因很简单 ，就是想要发布周期更短。
痛点⼀ ：发布时间不可控（快速的增量交付）
考虑到项⽬的实际背景 ，我们把迭代周期定为⼀个⽉ 。我们每个⽉都会跟内部客⼾⼀起做Sprint计划及 Review演⽰ 。这种做法 ，给我们带来了哪些改进呢？
提早集成与测试。这让问题得以及时暴露 ，带来了更快的反馈及应对；
及时规避⻛险。 意外仍然会有 ，但⼤多数情况下 ，我们可以在Sprint内部消化掉 ，避免更⼤的影响；快速响应变化。 在Sprint 1演⽰会后 ，我们收到了新客⼾提的紧急需求 ，⽴即做了相应的调整。如果按照 之前的模式 ，这个时候 ，可能很多事情我们都只做了⼀半 ，想调头没那么容易。短周期让我们可以灵活调 整⽅向 ，每个Sprint都是潜在可交付的产品。
另外 ，在Sprint 3之后 ，我们临时安排了⼀个⼩的Sprint ，⽤来快速地将“潜在可交付”变为“真正可交付”。我们发现 ，在每个周期内 ，能够真正把事情做完 ，跟我们的最终⽤⼾⼀起分享阶段性成果 ，对团队来 说 ，也是⾮常好的激励。
这时 ，发布周期的问题已经基本解决了 ，我们的交付灵活性⾼了很多 ，客⼾也更满意了。那么 ，我们是否可 以号称是个Scrum团队了呢？
痛点⼆：摆脱 “接⼒综合征”（从对抗⾛向协作）
经过仔细地观察和总结 ，我发现 ，团队各个⻆⾊之间的协作⽅式仍然存在着⼀些问题 ，我把这叫作 “接⼒综 合征”。 虽然交付周期变成了每⽉⼀次 ，但⼤家却仍然在按照过去的⽅式⼯作。具体表现有以下两点：
1.宁愿选择等待
每个⼈都等着上⼀环节的⼈把东西弄好送到⾃⼰⾯前来 ，才能开始⼯作。 ⽐如 ，我经常听到这样的说法： “ 需求⽂档还没理清楚 ，急啥？” “接⼝设计⽂档还没确认 ，怎么做啊？”这种情况 ，在传统的项⽬管 理中是很正常的。但是 ，这些空耗的时间 ，并不能给产品带来直接的价值。
2.⻆⾊间泾渭分明
每个⼈都觉得 ，只要把⾃⼰份内的事做完就⾏了。 ⽐如 ，开发把⼯作做完了 ，也不管做得效果咋样 ，⼼想： “反正要丢给测试 ，我先撤了 ，测出问题再说。”测试测出来Bug ，⼼想： “等开发全部完 我再接着测 ，反正我都测完了。”
在这种情况下 ，各⻆⾊之间是有⼀定的对抗的。项⽬中的任何⼀件⼩事都有可能造成冲突。最终⼤家都耗在 那⼉ ，每个⼈更在意的是 “这是你的问题 ，不是我的问题” ，却没有把焦点放在达成整体⽬标上。
在传统的项⽬管理中 ，项⽬经理的很⼤⼀部分⼯作就是要厘清各⽅责任 ，界定权利与义务 ，疏通对抗情绪 ， 并解决随之⽽来的突发问题。但在敏捷的情境中 ，更加快速的交付压⼒ ，使得这种等待和界限变得越来越不 可接受 ，我们不得不改变思路。
敏捷的打法，就好⽐是打橄榄球，所有队员都时刻关注着场上的⽐分。 虽然彼此之间有分⼯ ，但作为⼀个 team ，进球才是最关键的。敏捷也是⼀样。我们从敏捷思想中得到启发 ，开始进⾏⼀系列的改进。
⾸先 ，开发和测试把位置搬到了⼀起 ，并且设定了共同的Sprint⽬标和完成标准。
开发做完了⼯作以后 ，如果发现测试进度被卡 ，就会跟着⼀起着急 ，⼀起想办法解决问题 ，因为这影响到了 整体的进度。
其次 ，从“你完成-我开始”，到我们⼀起完成。
在敏捷团队中 ，开发⼲得热⽕朝天的时候 ，测试也没闲着 ，测试代码与开发代码⼏乎是同时在写的。往往代 码刚 “ 出炉”就测上了 ，⽽且只有在测试结束并确认没有Bug的时候 ，开发的⼯作才算结束。
我们使⽤故事点燃尽图 ，来衡量整体进度的偏差 ，并且团队会约定好 ，只有⼀个功能点完全测试通过 ，燃尽 图才能往下⾛。 这个燃尽图成了团队的计分牌 ，每个⼈都关注着同⼀个⽬标。
同时 ，我们还发明了⾥程碑燃尽图 ，⽤来衡量每个迭代对于整体进度的贡献 ，以及多个迭代之间累积需求总 量的变化 ，相当于⼀个赛季的累积记分牌。我给你分享⼀份燃尽图型项⽬进度模版
这些措施打破了⻆⾊之间相互切分和推诿的局⾯ ，共同的⽬标让我们变成了⼀个价值共同体。
毕竟，只有协作，才能达成⽬标。
痛点三：需求理解不⼀致 （⾯对⾯澄清及估算）
⾄此 ，团队的⼒量得到了很好的凝聚。在复盘会上 ，⼤家畅所欲⾔ ，共同讨论了下⼀个待改进项 ，那就是是 需求理解。这应该是技术类项⽬的⼀个共性问题。
当时 ，我们团队没有专职的策划 ，开发⼈员在理解需求时 ，经常会感到⾮常困难。我们打开敏捷宝箱 ，找到 了⼀条重要的价值观 “个体与交互>过程与⼯具”。相⽐于更多、 更⻓的需求⽂档 ，我们决定采⽤更多的⾯ 对⾯交流来解决这个问题！
于是 ，我们把迭代计划会分成了两个部分：
1. 产品负责⼈向团队和⽤⼾代表 ，⾯对⾯地讲解收集来的各⽅需求 ，最终明确需求的优先级及验证条件， 也就是说 ，在迭代结束的Demo演⽰会上 ，我们要给⽤⼾呈现什么。
2. 团队估算。我们采⽤敏捷估算扑克的形式 ，由团队成员共同给出估算结果 ，最后综合得出这个迭代要交付哪些内容。
团队估算的过程 ，其实是个双向互动的环节 ，可以帮助团队和产品负责⼈共同加深对条⽬的理解。 同时 ，产 品负责⼈也会根据⼤家的反馈 ，及时修改条⽬ ，完善条⽬。
具体估算时 ，为了避免⼲扰估算结果 ，当所有成员选择好代表⾃⼰估算值的纸牌后 ，⼤家同时亮牌。 同时亮 牌的好处是 ，不会有⼈跟⻛出牌，每个⼈的估算都是经过独⽴思考得出的 ，这也是扑克估算的精华所在。
如果估算值差距明显 ，代表⼤家对该条⽬的⼯作量没有获得共识 ，团队需要对该条⽬的评估结果进⾏讨论， 由最⼤值和最⼩值的牌主 ，分别说明⾃⼰的估算理由 ，并重新讨论 ，确定最终的评估结果。
经过实践检验 ，这样⾯对⾯的需求沟通及评估 ，⾄少带来了以下三⽅⾯的好处：
1.需求探索更深⼊。
在计划会上 ，团队会直⾯⼀线⽤⼾ ，需求可以得到⾯对⾯的交流和澄清。 另外 ，团队估算其实也是⼀个团队 共同探索需求的过程。 因为只有到真正考虑要花多少成本去做的时候 ，才会有各种各样的问题暴露出来。这 个⽅法对于在早期进⼀步挖掘需求细节 ，特别有帮助。
2.估算结果更加全⾯、细致。
在传统的项⽬管理中 ，我们也做估算。 ⽐如 ，WBS分配好了任务 ，然后每个⼈估算⾃⼰的。 因为每个⼈都只 对⾃⼰的那部分任务⽐较熟悉 ，估算时往往会有⽋考虑 ，⽽团队估算 ，就很好地补⾜了这⼀点。
每⼀个故事都会由全员出牌 ，各⽅从⾃⼰的⻆度出发想问题 ，可以互相补充。 ⽐如 ，在估算时 ，测试的成本 也会被考虑进去。对于测试成本⾼的功能点 ，开发会主动想办法加强单元测试等⽩盒测试⼿段 ，这样⼀来 ， 估算结果⾃然更细致、全⾯。
3.找到了更优的整体解决⽅案。
由于各⽅共同参与估算 ，前端、 中间层、后端、测试的思路可以在⼀起交流碰撞 ，这样就⾮常利于找到最优 的解决⽅案。
我们团队的这⼀系列敏捷尝试，始终都是围绕着项⽬中切实的痛点展开的。 从最开始缩短发布周期、经常交 付可⼯作的软件 ，到应对 “接⼒综合征” ，提升团队的整体⽬标感和协作效率 ，再到探索更加有效的需求理 解及团队估算⽅式 ，在增进团队交流的同时 ，⼜保障了需求质量。
敏捷实践的应⽤ ，为我们带来了诸多好处：
1.提升客⼾体验
更低的延误率
阶段性可⻅的产出
更快的反馈、适应与调整
2.提升管理者体验
团队⾃主运⾏ ，管理更轻松
变 “赶”为 “ 引” ，为共同⽬标奋⽃
3.提升团队体验
更⾼的⽣产⼒
更强的责任感、 主⼈翁意识
总结
今天 ，借助⼀个实际案例 ，我跟你分享了我们在应⽤敏捷⽅法的过程中 ，对于敏捷思想的体会和运⽤。
你可以看到 ，对于敏捷⽅法 ，我们并不是拿来即⽤的。我们所采⽤的这些⽅法 ，⼤多是以敏捷思想为指导 ， 以敏捷⽅法为基础 ，在实际场景中不断演化 ，⼀点点改进出来的。 实际上 ，没有任何⼀种⽅法、 ⼯具可以放 之四海⽽皆准 ，每个⼈都需要在⾃⼰的场景中思考。
真正决定⼀个团队是否敏捷的 ，不在于是否应⽤了那些实践 ，⽽在于实践背后是否体现了敏捷精神。通过我 们的⻓期实践和观察理解 ，我提炼出了实战中三项最重要的敏捷精神 ，那就是：快速可靠交付，⽤⼾价值驱动，持续⾃发改进。
我希望你能坚持敏捷精神 ，⽽不是僵化地套⽤特定的做法。在团队中实践应⽤敏捷时 ，也应该遵循⼩⽽美的 原则 ，每次⼀⼩步 ，挑⼀个痛点去集中解决 ，⼩步快跑 ，不断尝试和优化。 只要你做到了以上三点敏捷精神 ，那么 ，你的团队就是⼀个敏捷的团队 ，你的组织就是⼀个敏捷的组织。
