Scrum Master 也请了，钱也花了，敏捷是坑爹吗？

于是在越来越多的软件企业中，敏捷开发已经异化为“无人管理、无人负责” 的开发流程，产品经理、销售、老板拍脑袋加功能、改需求，然后团队就赶快“敏捷”去吧。需求调研？设计？反馈？代码评审？测试？都不存在的。

中国式的敏捷开发，没有软件开发经理，所有人都在盲人摸象，造出来的全是垃圾——超时、预算超支、充斥着各种拍脑袋的奇思妙想。完全忘了需求是否合乎逻辑，做出来的东西是否客户所想要的。

程序员每天花 8 个小时擦屁股，如果时间不够，那就 996 甚至 007，加班呗！

其实在敏捷开发盛行的西方 IT 领域，状况也没好到哪里去。Ron Jeffries 甚至建议开发者放弃敏捷开发。他表示，那些“黑暗敏捷”和“虚假敏捷”的薛定谔式敏捷，只会让开发团队的工作与生活变得更糟，也违背了敏捷宣言的初衷。

其实“敏捷”从本质上并没问题的，敏捷团队是可以很优秀的，敏捷也一定是能敏捷起来的。

客户提需求天经地义，项目需要有计划和按照预定日期交付预定验收标准也是再正常不过。关键看怎么去实践敏捷，很多公司项目，即使大公司，可能缺乏一个完整的敏捷实践体系。做敏捷也要根据项目实际情况增删一些团队角色，除了开发、测试、Scrum Master，是否需要其他的，比如架构师、需求分析师、项目管理、甚至人事经理等等。

可以一人担任多个角色，或者需要的时候某个角色才介入，但是不要缺失角色。并且每个角色要承担自己的责任，想要更好的互相协作持续高效交付，每个角色除本身职责技能外都需具备良好的沟通能力以及问题解决的思考能力。这样才能保障团队是一个成熟、高效的敏捷团队，很多项目团队把大把时间耗在流程和低效沟通上实在大可不必。

说到角色，不得不提一下Scrum Master和PO，这是不管在哪个实践敏捷的行业和企业中，必备也是核心的两个角色。

因为要能让你的团队在同样的时间内创造加倍的价值，那就值回这个钱了！让你的团队跑得更快，绝对比花钱雇更多团队来得更好。

所以，Scrum Master 就是要帮助团队提升速度，而 PO 则是负责把成果变成 “价值”。有些团队很优秀，可以迅速做出成果，可惜那些东西没人要。最惨痛的例子是昔日的手机巨头 Nokia，他们有好几个优秀的 Scrum 团队，做出手机的速度非常快，但乔布斯的 iPhone 一上市就无人问津了，Nokia 短短几年市值跌到了谷底。

所以 Scrum Master 就像教练一样，不仅帮助团队保持 Scrum 的流程畅通，排除拖累团队进度的障碍，这是他们每天“唯一”的工作。而 PO 最终负责输出成果的市场价值，因此，要想做出来的东西真正成功，PO 和 Scrum Master 之间的配合便成了成败的关键。

团队在冲刺的过程中，有时需要把PO拉进来共同讨论，这个环节叫“清单修正”（Backlog Refinement），这个环节也可以说是整个 Scrum 的成败关键。PO 要在这个时候为后面的冲刺提供各种好点子，并和团队一起将这些构想付诸实行。还需要明确项目有哪些工作必须执行，用什么样的标准来判断项目工作完成与否。

冲刺结束后，团队和 PO 要进行 Review，向利益相关方甚至客户展示已完成的工作与成果，这一定是已经真正完成的工作，而不是快要完成的工作，也不是虽然没完成但已经好努力、好拼命在做的工作。然后，PO 和团队要从与会人员处取得反馈意见：“我们喜欢这个”、“这个不行”、“我希望能 XX 更好”等… PO 要利用这些反馈重新安排待办事项清单的优先顺序，因为这些意见就是客户真正的声音，不是想象中的可能性。Review 时还要做的一件重要事情是，衡量团队在冲刺期间完成的工作量、以及他们的创造价值的速度——我们称为“团队速度”，这是 Scrum 的重要指标。因为 Scrum Master 要先了解他们有多快，才会知道能不能帮他们跑得更快。

那 Retro 和 Review 什么区别？Retro 是 Scrum 中最后一个环节，检讨团队整个的合作情况。Review 是展示工作成果，而 Retro 则是检讨这些成果如何完成。此时PO、Scrum Master 和团队要一起坐下来讨论，确认哪些方面进展顺利，哪些方面有待改善，以及团队希望下一阶段冲刺该怎样调整跑得更快，从而再开始下一阶段的冲刺。

我们都知道工作会出现变化，客户一旦看到实际成果一定会突然改变主意（提出新想法），Scrum 不会遏制这些不可避免的变化，而是拥抱变化，这就是 Scrum 文化。

反观我们传统做项目，尤其大项目，整个团队往往会卯力抗拒改变，大家都是很抵触 “需求变更“的，于是他们会要求变更之前得先提出申请，还设立某些变更控制委员会来压制需求被调整…但计划永远赶不上变化，状况会越出越多，所以他们花钱花心思干这事儿，只会拖累整个项目的进程，最重要的是更加让客户得不到想要的东西。

因此，拥抱变化才是面对项目时的“态度正确”，而 Scrum 就是在帮我们降低改变想法的成本，这锅咱不背呢！