构建之法阅读随笔一

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了构建之法阅读随笔一相关的知识,希望对你有一定的参考价值。

《构建之法》一书已完成了第一遍的阅读,接下来,我将随机抽取其中的一段进行精读。

移山公司的项目进行了一段时间,TFS上也积累了不少数据。大栓做了“数据挖掘”,整理出来一些统计信息,向各位领导汇报。

大牛:哇!前端组的这位开发人员是冠军呀,他导致的Bug总量约等于所有其他成员的总和。

二柱:那是有客观原因的,你可能不知道他的工作量是最大的。

大牛:那也不能因此产生这么多Bug,而让整个团队的进度停下来吧。

二柱:别人工作得这么辛苦,我倒是不太忍心再批评他。阿超,其实我觉得我们应该鼓励成员多做贡献,错误总是难免的,但是你知道他上星期完成了两个功能,明显比别人快多了。别的同事和他一比,就慢多了。

大牛:我不太同意,从TFS的数据来看,他的Bug数量远比别人多,而且不少Bug都有一段时间了,你说的“慢”的人,好像没有多少Bug,也是差不多按期完成的。问题是你希望团队成员是“萝卜快了不洗泥”型的,还是“慢工出细活”型的?

阿超:我有一个故事,假设团队里来了两位年轻人,嗯,就叫“萝卜”和“白菜”。萝卜做事很快,是“萝卜快了不洗泥”类型;白菜是“慢工出细活”类型。分配了任务后,萝卜很快就说做好了!白菜还在吭哧吭哧地跟项目经理和测试人员讨论。领导很高兴,让萝卜去做更多的事。开发阶段结束了,萝卜比白菜多做了不少功能。稳定阶段开始了。大家发现萝卜负责的功能出了很多问题,白菜的模块倒是比较稳定。然而萝卜在团队中的曝光率很高,很多问题都在等着他解决,从统计数据上看,他也修复了不少小强。白菜搞定了自己负责的模块,开始帮助其他人,由于不熟悉其他人的模块,白菜修复的缺陷不多。由于萝卜的设计有缺陷,导致模块非常复杂,萝卜也成了唯一了解其模块的开发人员。项目最后阶段,几乎都是萝卜工作得最晚,把最后几个缺陷给修复了。领导们说:有问题,找萝卜!项目结束了,开始了绩效考核,领导A认为白菜绩效不错,模块按时完成,没有大多问题,然后还能帮助其他成员;领导B认为萝卜是超级明星:第一个完成模块,修复的缺陷最多,而且掌握了最复杂的模块,离开他不行,工作得也很晚,有突出贡献。至于白菜,领导B没感觉他做了啥,仅仅是按要求完成任务了。萝卜白菜,各有所爱。那萝卜和白菜谁该得到奖励,谁该得到批评呢?假如领导B的评价方式占了上风,萝卜得到奖励,白菜离开了团队,你觉得下一个版本会出现什么情况?

大牛:我估计萝卜会成为“构建大师”,每天忙得不可开交。然而项目进展不一定会像以前那样顺利……

二柱:有人会怀念白菜。

大牛:你的意思是团队的领导者文化决定了团队的风格。但是当前该怎么办呢?阿超:所以我们要让“萝卜快了不洗泥”的人慢下来,这样能减少他们的危害。大牛:授予他们“萝卜大师”的称号?

阿超:恐怕不行,我们要胡萝卜和大棒并用。我们的大棒就是“小强地狱”(Bug Hell)。

 

这么一个故事,充分体现了软件开发过程中的“质”与“量”不易兼顾的问题,过于追求“量”,会导致BUG偏多,模块可读性不高,影响整体团队进度等问题;同样地,过于追求“质”,则会在修复BUG上花费较多时间,一样会影响整体的团队进度。但是相比而言,过于追求“量”的情况更多,危害也更大,因此,对这一情况加以限制也显得非常重要。而《构建之法》书中给出的方法便是“小强地狱”,即让导致BUG数量超标者进入小强地狱,期间只允许修复BUG,不允许参与其他开发工作,直到其导致的BUG数量低于阈值为止。这样的方法,只要阈值设置得合理,就可以很有效地使团队成员自觉把控“质”与“量”之间的平衡,从而提升整体团队的工作效率。

以上是关于构建之法阅读随笔一的主要内容,如果未能解决你的问题,请参考以下文章

构建之法阅读随笔二

《构建之法》第1216章阅读随笔

《构建之法》第四次随笔

《构建之法》第四次随笔

《构建之法》第三次随笔

构建之法第六次随笔