Scrum落地关键实践

Posted 2021-04-25 PM搞事情

    为什么你的Scrum总是难以落地？而大多数都是“形似而实非”的“敏捷Cosplay”。我们都知道，Scrum流程是简单的，那么落地的难点在哪里呢？其实是人，人是最难搞定的。所以，如何搞定形形色色的人呢？或许，你少了很多敏捷实践，帮你打通各个角色间的竖井，真正的实现价值的流动。

---

    1.为什么你觉得Scrum难以落地？

    每天都在讲Scrum，你可以徒手画出Scrum的框架图吗？那个经典的“3355”，还记得吗？不妨试试看。

    思考：

     1）Scrum流程本身有问题吗？

    2) 若流程没问题，那么到底哪里出了问题，没什么难以落地？

    3) 还记得《敏捷宣言》第一条吗？

     所以是个体和互动（人）出了问题！也就是人出了问题！

    很多人可能都看过甚至可以对《敏捷宣言》倒背如流。但是，你看过2001年在美国犹他州雪鸟山那次会议上， Andy Hunt 当时记录的《敏捷宣言》手稿吗？

    有发现吗？从手稿上来看，4条宣言的排序上，17位敏捷大师们有过多次纠结且一定伴随了多次的讨论， 但是只有第一条“个体和互动高于流程和工具”是始终排在第一位没有变动过的。 所以，Scrum难以落地的根源，一定是最根本的“个体和交互”出了问题。

    继续思考， 如果每种角色间的交互都会形成一堵墙，Scrum会变成怎样？

    是的，会形成很明显的边界，或者你可以叫做 “竖井”。业务如何变成需求，需求如何传递业务，研发如何实现业务价值等，这类问题就会变得很棘手，甚至形成角色对立。  

---

  2.如何打通各个域，让价值流动起来？

    上图是在IDCF训练营学习时，王立杰老师取自李涛老师原创的一个MoMoCo模型，为了更加便于理解，所以对命名进行了小小的修改。

    从宏观的角度的展示了，如何利用影响地图，用户故事地图，及看板，来打通业务域到需求域再到实现域的一个框架体系，下面我们来详细的看下。

    在这里不得不的提到一个非常牛X的法则—— 黄金圈法则！

    扩展一下：

    1）什么是黄金圈？

    很简单，三个同心圆，最里面的一个是Why，中间一层是How，最外面一层是What。

    2）什么是黄金圈法则？

    举个例子，比如一般的电脑公司的市场营销会这么做：我们做了最好的电脑(What)，我们的产品设计很好，使用简单（How）。接着会问：怎么样，你想买一台吗？典型的从外向内的交流和沟通的方式，也是大多数市场推广的方式。上来先告诉你我们是干什么的，我们是怎么不一样，然后期待着别人的反应。但其实这种沟通的方式是很低效的。

    我们再来看一看，用黄金圈法则的苹果公司，他们是怎么做的？首先告诉你，我们做的每一件事都是为了创新和突破，我们坚信应该以不同的方式来思考（Why)，接着我们挑战现状的方式是将产品设计的十分精美，使用简单并且界面友好（How）。最后再告诉你，我们顺便也就做出了一台最好的电脑、最好的Iphone（What）。你想来一台吗？

    其实这种逆向思维的真相在于：要想最大程度影响他人，最关键的不在于传递“是什么”的信息，而在于给出“为什么”的理由

    大量的事实已经证明，人们在决定购买的时候，买的并不是产品，而是在为你的信念和宗旨在买单。因为认同，所以买单。不是你把产品卖给了需要产品的人，而是卖给了跟你有相同理念的人。你看看苹果出新品的时候，那些彻夜不眠排队的大军，就是认同的人。

    为什么要提到这个黄金圈法则呢，因为他和我们接下来提到的影响地图（Impact Mapping）很像，而且和OKR的原理也有像，都是从Why出发，聚焦目标价值。

    再聊回我们在业务域上碰到的问题，看一看影响地图在其中是如何发挥作用的。

   

    如果你还不了解“影响地图”，那么你可以建议大家去看看上面推荐的那本书。这里不做赘述。或者你对它感兴趣，可以留言，如果感兴趣的人多，我会做个专题分享。

    总结下：有的产品，它还活着，其实已经死了；还有的产品，还没发布，就已经已经被判死刑。太多的产品失败的案例，源于方向性错误，基于错误的假设，功能与业务目标/价值之间缺乏必然的关联与一致性，在做的事与期望的目标南辕北辙。而影响地图（Impact Mapping）就是这样一种试图通过结构化、可视化、协作化的方式来从源头解决上述问题的工程实践。

---

    首选要弄清楚什么是需求？很多时候，我们从源头就搞错了，结果后面肯定是一错再错！

    需求就是客户想从你这里获得的 价值服务，但不一定是他说的那样 ！

    所以，我们一定要避免把用户描述的他想要的功能或解决方案当作需求记录下来，这样很危险！

    其一，用户可能描述不清楚，掩盖了价值的本意；

    其二，用户不了解现有技术架构，所以可能提出了不适宜的解决方案，以至于实现成本很高。

    比如：用户说，我要一座桥。产品把这个当作需求记录下来，然后叫研发去做。过了N久，用户一催再催之下终于交付了，可是用户已经不需要了，因为他已经租了一条船，早早的过河去了。从这个例子中，我们可以看到，用户的需求到底是什么？其实就是——尽早的过河。   

    学会，多问几个Why，直到问到和用户切身利益相关为止。想了解更多，访问《6 Success Questions You Must Ask》：https://www.slideshare.net/AndreasVonderHeydt/6-success-questions-you-must-ask

    

    

    关于，用户故事，用户故事地图，用户价值地图，用户体验地图，这具体怎么玩，我就不展开了，默认这些基础知识是大家都懂得，如果不懂的，同样可以看看上面推荐的书籍，或者对什么感兴趣，可以留言，留言多的话，我会做一个专题分享。

---

    需求研发是一个很重要的环节，如何保证按需开发，内建质量，这里一定离不开—— XP 极限编程！

    用户故事到行为驱动的链路打通：

    关于实现域，极限编程一定是不可轻视的，不然每天crud的堆烂代码，于公于私，意义何在？

---

    两个工坊会议参考，点击访问和

---

3.写在最后

    1）问题多不要怕，Scrum就是帮你暴漏问题；

    2）坚守，而不轻易裁剪，Shu-Ha-Ri；

    3）学会借助工程实践，打通全流程；

    4）Scrum做好的前提下，再考虑LeSS或SAFe等大规模框架。

  

---

欢迎喜欢搞敏捷项目管理的同仁们，加微信多交流！