如何填掉计划会中的一个大坑

发布时间:2020-04-06

不得不承认,一个好的计划会就可以让整个Sprint成功一大半。但不得不承认的是,计划会是所有Scrum会议中最难的一场。而其中又以“我们能做多少活儿”为难度之最。毕竟当你知道你的能力极限时,很多事情就迎刃而解了。

1.jpg

抽象的计划会

常见的错误有这么几个:

1、安排的满满当当,即让每个人都将每周40个小时干满,不留一点点余地,甚至还需要将某个固定百分比加班作为考核标准;

2、安排的过于松散,这个大家都懂

3、规定某个投入度比例,必须要团队整体达到,比如70%或者80%这种(这个主要是在“基于承诺的迭代计划”)

4、不断增加迭代内故事点数要求

5、没有规定,凭感觉。

不论完成多少,PO和SM 都表示赞同

针对1和2,不用说太多,100%投入或者10%的投入都是不可取。前者让大家压力太大,后者让大家过分松散、士气不足。

针对4而言,团队交付最终会有交付上限的,不可能无限制增加。如果每次都增加故事点数要求,最终团队会有崩溃的时候。

而针对5而言,凭感觉是个赌人品的事儿,不可过分相信人性,否则这种风险完全不可控。

所以重点就放到了3上面,也就是在基于承诺的交付上,我们强制要求一个比例,所有人必须投入足够的时间在本迭代的工作中。

但是这绝对是一个烂主意!

我们先不论这个比例是否正常,但要求“团队全体”都投入这个精力,怕是有点不可行:

1、每个人会受到的影响不一致,比如某些老员工由于参与的项目较多,那么过去项目中的“不可预测”的突发问题就完全不可控;

2、研发人员的估算能力么……说100%有点过分,说80%就有漏网之鱼。

研发人员高估交付能力的是常态,那么估算偏低的,大概率是有意识的摸鱼。

在这种情况下,原本他承诺的70%的时间的工作量,怕是需要120%才能完成。因此这种情况对研发并不友好;

3、这篇文章说的,敏捷开发本身就是一场无法准确预测的活动。

强制加上一个限制,较大概率会让大家后退到瀑布时期的做法。

我们能做多少活儿

如果需要团队给出一个切实可行的计划,我一般会做两件事情:

01、接受开始几次的不完美

02、引导团队自己发现能力极限

我们都知道敏捷本身通过迭代的方式,最终交付用户真正需要的产品。但为什么我们不能接受在研发流程中,我们自己就使用迭代的方式进行日常工作呢?原本计划就是一种猜测行为,我们能做的就是怎样猜测的更准确罢了。因此只要我们接受前期几次不完美,然后在过程中发现不完美的原因,逐步调整也就可以了。

引导团队发现能力极限是个技术活,涉及到的点比较多,这里给出一种我的做法。

1.鼓励每个团队成员自行估算能完成的工作

2.将每个团队成员的估算加在一起作为团队估算

3.没了

很多人会觉得我的做法与上一章中“没有规定,凭感觉。不论完成多少,PO和SM都表示赞同”是一样的。但实际上有较大的不同。

我的做法中,我在背后至少有三件事情是要处理的:

1. 承诺团队如果工作做不完不用追责

2.  将工作进度透明化,明确每个人的工作都被看到

3.  紧密追踪团队工作情况,并在迭代结束后帮助每个团队成员分析估算偏差来源并修正

第一点不说了,如果追责,那么我们永远不要指望团队成员可以告诉我们真相,保护自己是正常行为,那么团队成员唯一能做的就是“主动降低自己估算指标”了,因此第一步就打消这种念头。

第二步解决的是团队成员划水的问题。透明化是个好工具,请大家一定要多多使用。SM、PO本身是没有能力分辨研发是否全力以赴的。那么怎么办?引入一种机制,让大家都可以全力以赴就行了。透明化就是这么一个工具。透明化之后,团队成员中每一个都可能成为“督察员”,监督其他同事的工作。要知道,研发人员可都是有一点点小傲娇的,谁都不想被其他人鄙视。因此工作透明化之后,无形间就让大家憋着一股劲,努力将自己最好的一面展现出来。当然如果全部团队成员都串通好了的话,那你的工作环境也太恶劣了一点,那也就是另一个话题了。

第三步不用说了,PDCA 循环大家都比较熟悉了对吧。这是改进工作必备流程哇。

根据我的使用经验来看,这种做法下,团队满意度与交付力可以达到较好的平衡,且短期内(5个迭代内)就可以让团队估算趋近于正确的值,并且一直保持稳定的评估结果。

最后的要点

1.不可以团队内去对比投入度——要相信并引导团队成员全力以赴。

绝对值对比是忽视项目中的其他因素,将软件开发看做了一个可以预测的事物;

2.一定要用鼓励的方式让团队估算,而不是要求的方式,更不要直接push结果给团队。

相信“承诺”的力量;

3.尽可能使用全职团队,这将会让你的估算更加可信;

4.永远不要忘记持续改进,否则你的估算什么都不是。


Copyright O 2020 All Rights Reseverd Designed by Sthspace.net PICPE150170198-1