Scrum落地关键实践

举报
Bob Jiang 发表于 2020/07/14 09:19:49 2020/07/14
【摘要】 Scrum流程是简单的,落地的难点其实是人,人是最难搞定的。所以,如何搞定形形色色的人呢?

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


一、为什么你觉得Scrum难以落地?


每天都在讲Scrum,你可以徒手画出Scrum的框架图吗?那个经典的 “3355” ,还记得吗?不妨试试看。
image.png
思考:
1)Scrum流程本身有问题吗?
2) 若流程没问题,那么到底哪里出了问题,没什么难以落地?
3) 还记得《敏捷宣言》第一条吗?
所以是个体和互动(人)出了问题!也就是人出了问题!
很多人可能都看过甚至可以对《敏捷宣言》倒背如流。但是,你看过2001年在美国犹他州雪鸟山那次会议上,Andy Hunt 当时记录的《敏捷宣言》手稿吗?
image.png
有发现吗?从手稿上来看,4条宣言的排序上,17位敏捷大师们有过多次纠结且一定伴随了多次的讨论, 但是只有第一条“个体和互动高于流程和工具”是始终排在第一位没有变动过的。所以,Scrum难以落地的根源,一定是最根本的“个体和交互”出了问题。
继续思考,如果每种角色间的交互都会形成一堵墙,Scrum会变成怎样?
image.png
是的,会形成很明显的边界,或者你可以叫做 “竖井” 。业务如何变成需求,需求如何传递业务,研发如何实现业务价值等,这类问题就会变得很棘手,甚至形成角色对立。 


二、如何打通各个域让价值流动起来?


image.png
上图是在IDCF训练营学习时,王立杰老师取自李涛老师原创的一个 MoMoCo模型 ,为了更加便于理解,所以对命名进行了小小的修改。
从宏观的角度的展示了,如何利用影响地图,用户故事地图,及看板,来打通业务域到需求域再到实现域的一个框架体系,下面我们来详细的看下。


业务域

image.png

在这里不得不的提到一个非常牛X的法则—— 黄金圈法则
扩展一下:
1)什么是黄金圈?
很简单,三个同心圆,最里面的一个是Why,中间一层是How,最外面一层是What。
2)什么是黄金圈法则?
举个例子,比如一般的电脑公司的市场营销会这么做:我们做了最好的电脑(What),我们的产品设计很好,使用简单(How)。接着会问:怎么样,你想买一台吗?典型的从外向内的交流和沟通的方式,也是大多数市场推广的方式。上来先告诉你我们是干什么的,我们是怎么不一样,然后期待着别人的反应。但其实这种沟通的方式是很低效的。
我们再来看一看,用黄金圈法则的苹果公司,他们是怎么做的?首先告诉你,我们做的每一件事都是为了创新和突破,我们坚信应该以不同的方式来思考(Why),接着我们挑战现状的方式是将产品设计的十分精美,使用简单并且界面友好(How)。最后再告诉你,我们顺便也就做出了一台最好的电脑、最好的Iphone(What)。你想来一台吗?
其实这种逆向思维的真相在于: 要想最大程度影响他人,最关键的不在于传递“是什么”的信息,而在于给出“为什么”的理由。
大量的事实已经证明, 人们在决定购买的时候,买的并不是产品,而是在为你的信念和宗旨在买单。 因为认同,所以买单。不是你把产品卖给了需要产品的人,而是卖给了跟你有相同理念的人。你看看苹果出新品的时候,那些彻夜不眠排队的大军,就是认同的人。
为什么要提到这个黄金圈法则呢,因为他和我们接下来提到的影响地图(Impact Mapping)很像,而且和OKR的原理也有像,都是 从Why出发,聚焦目标价值。
再聊回 我们在业务域上碰到的问题,看一看影响地图在其中是如何发挥作用的。
image.png
image.png

image.png

image.png

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

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


需求域
首选要弄清楚什么是需求? 很多时候,我们从源头就搞错了,结果后面肯定是一错再错!
image.png
需求就是客户想从你这里获得的  价值服务 ,但不一定是他说的那样 !
所以, 我们一定要避免把用户描述的他想要的功能或解决方案当作需求记录下来, 这样很危险!
其一,用户可能描述不清楚,掩盖了价值的本意;
其二,用户不了解现有技术架构,所以可能提出了不适宜的解决方案,以至于实现成本很高。
比如:用户说,我要一座桥。产品把这个当作需求记录下来,然后叫研发去做。过了N久,用户一催再催之下终于交付了,可是用户已经不需要了,因为他已经租了一条船,早早的过河去了。从这个例子中,我们可以看到,用户的需求到底是什么?其实就是——尽早的过河。 
image.png

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

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

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


实现域
需求研发是一个很重要的环节, 如何保证按需开发,内建质量, 这里一定离不开——  XP 极限编程
image.png
image.png
用户故事到行为驱动的链路打通:
image.png
image.png
image.png

image.png

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


关于各种会议

image.png
image.png
两个工坊会议参考,点击访问《探索工坊设计与实施实录》和《年度团队回顾工坊实录》
image.png


三、写在最后


1)问题多不要怕,Scrum就是帮你暴漏问题;
2)坚守,而不轻易裁剪,Shu-Ha-Ri;
3)学会借助工程实践,打通全流程;
4)Scrum做好的前提下,再考虑LeSS或SAFe等大规模框架。


内容来源:PM搞事情
作者:Ethan 李岩
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200