• CSPO+A-CSPO直通车
  • 敏捷领导力(CAL E+O / ALJ)认证培训
  • Five_reasons_three
  • Hardware-agile-practice-20231012
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • CSM A-CSM一站式培训
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • ShineScrum捷行出版书籍
《用户故事地图》书评

大概是《用户故事地图》这本书在的国内的第一个书评。这是因为它的中文版刚刚出版,好几个电商网站甚至还没有上线,能在清明节假期能拿到这本书本身就是有很大的运气成分的,感谢京东吧:)

 

很多人会在看到user story后第一时间联想到敏捷,这没什么问题。但如果因为不熟悉敏捷或者认为user story只是敏捷团队的专属而错过本书的话,那会是一件非常遗憾的事情。回顾软件开发的历史并不是一件难事,毕竟软件开发这件事情并没有那么长的历史,但是因为软件开发的出现本身和人类历史中信息化是天然捆绑在一起的,所以这并不长的历史其实是非常精彩的,当然这不是本文讨论的内容,我只是想说明因为软件开发出现的时间较晚,所以会天然的在工程方法上在已成熟的学科上寻找「模板」,所以架构师、工程师这种工种的命名并不奇怪,而在最初的开发方法上(包括现在很多公司还在使用的方法),你可以很轻易找到除了工种的名字以外很多和建筑学类似的东西,需求说明书很像一个大楼的招标方案、而架构图就是盖楼的图纸,测试好像和验收工程也蛮像的。

 

这种风格的管理方式在早期包括现在的很多行业仍然是适用的,但是越来越多的项目被发现用这种方式管理会出现超预算、延期、团队氛围差等结果。为什么呢?软件不是盖楼,很少有楼在施工中会改方案,但是软件不一样,也许是业务变了、也许是出了一种新技术、也许是有「热钱」进来了,软件业务天生面临着时刻被改的风险。这是因为这种风险的倒逼,我们可以在上文提到的不长的历史中发现,软件工程师一直孜孜不倦在用各种方法试图去找到软件开发过程中更好的保证效率的方法,scrum、tdd、bdd、kanban、ci...

最后这些方法有了一个共同的名字——敏捷。好吧,当你终于准备开始敏捷之前,先看看下边的故事吧。

 

于谦的爸爸接了一活儿,完事能挣三十万……拿过图纸一看,盖一40米的烟囱,都盖好了,人家本家来一看,把他爸爸打了一通,图纸看倒了,人家让挖口井。——非著名敏捷教练郭德纲

 

想想吧,上边的故事虽然夸张,但是不是你经常经历的,你拿到一个文档,通常是需求文档,然后开干,然后得到一句话「那根本不是我想要的」。也许于谦的父亲和施工的本家坐下来聊聊,就不会发生井变烟囱的事情了。如果在一开始的需求就是错的,或者开发理解错了需求,采取敏捷只会让你错的更快,离挨打更近。本书是为了解决把需求变成故事,以便于团队更好的沟通,提高效率的书籍,是一本避免挨揍的书:)

 

明明三年,三年后又三年,三年后又三年,差不多十年了,老大。——被估算坑苦了的陈永仁

 

很明显在无间道里,黄秋生扮演的黄SIR并不是一个好的估算工程的老板,他和陈永仁说的三年就结束一转眼变成了十年。不讨论他是否故意的原因,单纯的想为什么估算会出现这么严重的问题?本书也许给出了答案,最靠谱的估算,来源于真正理解自己在干什么的的工程师。

 

有多少工程师在拿到需求文档真正知道自己要干的是什么吗?这种情况下给出的估算是准确的吗?使用用户故事也许可以让团队中的人真正坐在一起来引发讨论,注意是引发讨论而非达成共识。而如何进行更好的讨论请看第7章。另外,切记请把故事用嘴讲出来;也请不要追求故事本身的完美,只要干活的人都能在协作中使用、沟通就可以了。

 

有一个项目总监在某天加班后回家的路上不小心摔倒磕破了头,于是他见到了上帝,没想到上帝发现不应该让他死,于是准备复活他并实现他一个愿望作为补偿,项目总监希望中国男足世界杯夺冠,上帝考虑了下说太难了让他换一个,于是项目总监把愿望替换成了让自己带的产品和开发不要经常打架,上帝叹了口气,“还是讨论男足夺冠的问题吧”——《格林童话》

 

把故事的所有细节交接给开发人员,以这种方式来组织开发工作的做法是行不通的,千万不要这么做。——来源于本书第9章

 

开发人员喜欢什么样的产品经理呢?知乎上的高票答案是这么告诉我们的:

不仅告诉你做什么,还告诉你为什么这样做

努力说服你,而不是简单说:上面就要这么干

同意你关于一些细节的建议与修改

...

 

我们几乎可以看到,以上几条几乎都是和沟通相关的,事实上你很难想象一个不懂的沟通技巧的人是怎么做产品经理的,而现实中真的就这样发生了。用户地图可以帮助产品和开发更好的沟通,因为你们说的不是晦涩难懂的需求,而是故事(怎么讲好一个故事?who-what-why怎么用?参考本书第5章和第7章),我相信当产品和技术说「同一种语言」的时候,沟通会更高效。

 

写到这,对于本书的书评基本告一段落,是的,我在书评中连用户故事和用户故事地图是什么都没有写清楚,定义固然重要,更重要的是你去实践他。本书的精彩之处也绝不是下了几个关键定义而已,关于如何从你身边的事情开始一个故事、如何创建用户故事地图、如何把故事由大切小、如何mvp、如何开始一个故事工作坊...这些精彩的点不胜枚举,正好回应我文章开头的那句话,不管是不是敏捷团队,都不应错过它:作为一个产品经理你能学习到如何更好地定义需求定义故事;作为一个PO,你会利用起用户故事更好的来和团队沟通;作为一个项目经理,你不用祈求遇见上帝才能调节好产品和开发的矛盾;而作为一个敏捷教练或者是过程改进负责人,你能从中找到更好的在团队中推进敏捷的破冰方法。

 

当然,客观上本书也并不是一点问题没有,在作者的序中,作者仅仅想写出一本小册子来,这可能导致他在写作前并没有完整的提纲来引领本书的写作,所以这本书的脉络似乎有点乱,但好在有非常多的实拍图(没错,就是作者在项目中的或者朋友项目中的一些用户故事地图的照片)和手绘图,可以让阅读更有趣味,结合图去理解作者的思路,跳出章节的束缚,本身也是「征服」这本书的一种乐趣。

 

最后,为两位译者wuli涛哥和阿东的翻译工作鼓掌,翻译绝非易事,据我了解涛哥在百度的工作繁重,仍然抽出时间去用翻译本书的方式推广敏捷,而且在线下组织故事工作坊,实时的把翻译所得的知识传播出去,实在令人敬佩。我发布在朋友圈的这个书评被看到的概率估计很小,看到的人也不会转发(哭脸),不过这都不要紧,希望所有看到的人在为其他朋友荐书时不要忘记这本新鲜出炉的书,就是对两位译者最主要是对被推荐去看书的人最大的收益。

 

你在踏青时拈花惹草,我在家里看书写稿,不辜负假期都是一样的,求打赏。