淘客熙熙

主题:【原创】闲聊敏捷开发——SCRUM(一) -- 哈酷

共:💬141 🌺325
全看分页树展 · 主题 跟帖
家园 【原创】闲聊敏捷开发——SCRUM(四)

上一篇讲完优先级,应要求写了个实际的poker-plan流程

链接

总结就是:高效的沟通取决于沟通前的功课是否做好了,poker-plan逼迫PO做功课。

如果有同学也开过poker-plan会,可以对照是不是也是这样的,如果不一样,拿来探讨一下。

我写到这里想先把SM的角色讲一下,因为这是比较特别的部分。Sprint以及sprint plan留到后面讲。

必须从瀑布式管理说起,因为瀑布式管理没有SM。

瀑布式管理的优点是计划性强,非常逻辑,先考虑清楚,再把需求写下来,然后估计工作量,然后运用甘特图之类的东西或者project这样的软件,就有了一个个时间节点。如果能够踩准这些时间节点完成既定任务,那么项目将完美结束。我干那么多年,每个点都准确踩准的只有好多年前的一次,那次没有遇到什么需求变更。

把计划都安排好了,让做什么就做什么,按计划干就行了,每件事情的工作量原则上必须有高你一层的技术骨干来决定(给你自己定啊?那肯定虚报怠工啊)。在过去这样干活没啥问题。可是需求变更遇到了困难,因为需求变更就意味着新的工作量,而这些新的工作量是当初没有被计划进去的。在过去这样也还行,因为变更小。少量的变化造成的新增工作量可以突击消化掉,只要是计划安排的还过得去。

新行业的出现带来了巨大的需求变更需要,于是当遇到很多变更的时候就只能不断的调整计划了。

很多人把善于做这种调整称为“管理的艺术”。好吧,暂且不论艺术不艺术。之所以还在艺术是因为变化还不够多,当需求变更多到一定程度,计划再也赶不上变化了。

对于被要求修改的开发人员,情绪必然是抵触的,他陷入了一种困境,即使他心中清楚改动具体有多麻烦,但是他难以告诉客户到底多麻烦,他只能说“很”麻烦。或者说需要1个礼拜来改(客户不会相信他)。

开发人员的抵触是可以理解的,对于他个人而言,这种变更是对他前面工作的否定,他前面基本就是白干了,而且在他看来再也没有人会记得他之前干过的那些,他潜意识里必须想个办法让人知道他的苦难,让上司知道是一个办法,至少不算太白干,他有种本能要把事情搞大,让他的上司出马去顶(顶不过至少也算知道了)。 而对他的上司,困境是类似的,有时甚至不如实际开发人员了解到底这个麻烦的程度。

当然,在代码里尽可能的留下修改的余地这只是妥协的手段罢了,治不了本,而且为了留下修改余地搞出了额外工作量。

对于开发组而言,怨恨目标自然是白痴客户,因为在他看来,由于客户的鼠目寸光,导致了他的困境。开发组吃饭时一起骂客户是常见的消遣方式。

但从客户角度讲,也有个困境,他没有办法真正让开发人员理解这个修改多么重要,而且他也不知道这个开发人员只是因为怕麻烦不想改,还是真的很麻烦,他见惯了开发人员向他抱怨麻烦,于是他到处找人,找那些能帮他把需求修改“压”下去的管理人员,比如lead之类,如果还是被顶回来,就一级一级往上找,究竟要找到多高,取决于这个修改在他们心中到底有多重要。

就像我在(一)里面说的,需求修改其实是常态,在双方不断的处于这种困境的情况下,双方变得很难互相信任,所以高唱要建立信任是很重要的,也是很难的,需求变更越多,就越难。怎么可能信任呢?今天你要这样改,明天你要那样改,我能信你?我改的越快你变的更快,我改出来你看看不喜欢,又要那样改了。客户也不信你,你说很麻烦不能改,我找你头头一压,你不是很快改好啦?你不肯改,我找别人改,别人很快改好了诺。

看看SCRUM怎么解决。

PO把自己的需求变更写下来,然后拿去poker-plan一把,最终都会得到一个公正可信的价格,他了解了这个需求到底有多麻烦。尽管有时候他还会假装惊呼“好贵啊”之类的话,但这个和你买东西问完价格喊贵的道理一样,你不一定是真觉得贵,只是希望再杀杀价,人之常情。

有了价格以后,PO好好思考了一下到底值不值得做的问题,比如要把夹板门换成实木门,20个点,值不值呢?花在这里20个点,是不是宁愿花20个点给夹板门装个高级门锁呢?

就和我们拿着皮夹逛商店的想法差不多。只要皮夹里的钱是有限的,我们就会自觉排列优先级。

然后TEAM里无论谁拿到这个story,修改么,也只是一个story而已。前面虽然夹板门白做了,但是夹板门的5个点是着实被记录下来了。不做这个story也要拿别的story做的,否则积不到点数。(这里和考评有关,后面详细说)

我对SCRUM的处理方法概括就是:“给所有的变更估价,以价格为导向形成内部的市场经济体系”。于是简单了,所有的改动都可以接受,只有标价不同而已——没有买不到的,只有买不起的。PO只是在这个体系中买东西,TEAM是在卖东西,不强买强卖。听上去一买一卖倒挺合理,为啥还要一个SCRUM MASTER呢?

这个SM到底起什么作用?大家想一想,既然我说了这是市场经济体系,那么市场经济必须是在一个法制社会中进行,否则有人抢东西怎么办?SM就是法官+警察,维护秩序的。谁会抢东西呢?一定是PO,PO有种我是客户我说了算的习惯思维。简单说就是当惯了皇帝不太习惯于去市场付钱买东西,常常越界。PO们总是迷恋权力的(指手画脚惯了),当PO发现自己的需求需要更改的时候,通常他们第一个想到的不是另写一个story,而是直接走到某TEAM成员那里去:“小王,上次那个夹板门不好看,还是改实木门吧!”,

小王回答“改实木门很麻烦的,我做不了主,需要请示”。

于是找到小王的LEAD,接着开始斗嘴,最后无论改不改,双方已经浪费了大量的时间在这种本不应该出现‘沟通’上了。从此以后,无论是TEAM还是PO都再也不把poker-plan会议当回事了,一切回到熟悉的从前。我见过好多这样沉沦下去的项目。

谁的错呢?PO和小王都有错,他们都忘记身处一个市场经济中,应该用钱说话。

小王正确的回答应该是:“请问有story了么?如果没有请写个story”,对于TEAM中的小王而言他真的不需要记住太多规则,他只需要记住自己只认story,因为只有story才能给他带来点数。就像店小二只需要认识钱就可以了。

如果PO强行让他做,那就是抢东西了,小王需要做的是打110——找SM来。

SM就是个法官+警察,也就是说,他干的就是法制建设的工作。

听上去是不是很滑稽啊,反正这完全是我自己的理解,这个说法也没见过别人说过。

SCRUM搞那么多规则其实就是法律啊。只有搞市场经济才需要法律,老是有人抢东西的情况下是不需要什么法律的。


本帖一共被 1 帖 引用 (帖内工具实现)
全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河