项目管理沙龙第六次聚会纪要--模式“苹果酒屋”

长平狐 发布于 2012/10/23 14:16
阅读 58
收藏 0

项目管理沙龙第六次聚会纪要--模式“苹果酒屋”

《项目百态》模式36名字叫“苹果酒屋”。大意是说,苹果酒屋是工人们下班之后的聚会场所,他们经常在吃完饭之后,一起爬到房顶上去乘凉,喝啤酒。于是女主管就制订了苹果酒屋规则,基本上就是“不许爬到房顶上”,“不许喧闹”等诸如之类的规定。可想而知,这种“苹果酒屋规则”不会有人遵守的。因为规则的制定者从来不会在苹果酒屋住宿,也当然不会知道屋顶上是那里唯一凉快的地方。

这种“局外人”制定规则的情况在企业内部非常常见,最终的结局也都和“苹果酒屋规则”差不多。会上列举了几种常见的推广场景,一种是“强推法”。比如“空降”到项目组或公司的能人,经常会不顾公司的现状,强行给他的下属制定各种规则,试图将做出改变。这种强推的手法,经常会导致项目组的动荡,进而引发人员的非正常变动。但是强推并不总是坏的,当年华为从IBM引进并推行制度的时候,也是一样是强推,并且任正非还特意强调几年之内不许改。一种是“循序渐进”推进法,一点一点地让“局内人”去体验,逐步获取经验,然后加入更多的规则,最后所有的规则都生效。这种做法需要耗费很长的时间,并且还需要专人进行跟踪和分析;一种是“自制规则”,这个也是《项目百态》的作者推荐的方法,即由游戏者自己来指定规则。这样无论是规则的接受程度,还是实施的效果,都会非常的好。但是这种方法容易走弯路;另一种是“专家法”,即通过利用具有专家身份的人,来向大家推行新规则,并且在规则的实施过程中不断地解答游戏者提出的问题。专家可以让游戏者快速地形成共识,并且朝正确的方向前进,但是同样需要在实施过程中进行跟踪和监督,及时对方向调整。

这些做法都各有利弊,归纳起来,无非就是时间、空间和效果上的折衷和平衡。谈到这里,有人从自身的经历,谈到了程序员做了一段时间的测试之后,再回去写代码的话,代码质量会变得很好,很容易测试。这种角色的互换,比推行任何一种“测试要求”/“测试标准”的效果都要好。这时,有人举出了DT网项目的例子,因为第一期已经进入了维护阶段,所以该项目的下一阶段的开发项目就明显开始注重质量了。

相比这种通过“自身实践”得到的改变,让专家对工作进行总结,得到“最佳实践”方法之后,在全公司推广并评估效果,这种效率就会高很多。其实这么做也就回到了我们刚才讲的“专家法”的推广了。

因为刚才谈到了“测试”问题,所以话题继续围绕测试展开。有人谈到了测试人员的水平问题。现在很多公司里,程序员的薪资水平要比测试人员要高很多,也就是程序员的编程水平通常比测试人员要高。可是引出了一个问题,就是水平最高的那个程序员的代码,谁有能力测?这个问题的答案并不简单,首先要看公司处于什么样的市场地位,处于领先地位的公司更考虑质量一些,处于追赶地位的公司更偏重功能,所以前者的测试要求会比后者高一些。其次要看公司的价值导向,眼光长远的公司对质量及测试的要求就高,急躁一点的公司对测试的关注度就小一些。还有就是要看项目的类型,对于产品型的项目,质量要求就会高,而对于一次性的定制项目,质量要求就低一些。其他还有很多的因素,包括公司的大小、技术能力等,都会影响到对测试的编制、地位和安排。

虽然如此,但是测试人员的水平大于开发人员的假设也并不一定成立。因为测试所需要的并不只是个人能力,和开发相比,测试有更多的流程,更多的工具,也有更多的有成效的方法来弥补与开发人员的技术水平差异。从某种程度上来说,产品的测试并不是依赖测试人员,而是开发者自己来进行的。因为所有的测试类型中,“单元测试”是最重要的测试,而单元测试的主要编写者恰恰是程序员自己。可是我们发现大部分的中国程序员都十分痛恨单元测试。我们一位与会者给大家解释了一大堆的“单元测试”概念,比如测试覆盖率,条件测试,边界值测试等等,以及单元测试的重要性又是如何如何。这些话从公司管理人员、项目经理、测试人员、客户以及维护人员,都非常消受,可是从程序员的角度听来,则是非常刺耳。虽然从实践中来看,有适当的单元测试覆盖的产品和没有单元测试的产品相比,后期的BUG量可以减少六至八成,但是这么重要的一种编程行为,即单元测试对于程序员的意义,哪怕是TDD都没有明确地强调出来:
 
“单元测试可以极大地降低调试的难度,加快开发的速度!!!”

这个其实也是我们沙龙要对所有程序员发出的强调。实际上,程序员的水平越高,对于测试也就越重视。当然,除了提高人员的自觉性之外,要推广单元测试还需要流程和制度的安排,比如结对测试。另外,测试的独立性也很重要,现在的测试都是被开发牵着鼻子跑,这种情况严重降低了测试的效率。

在讨论中,有人提到了一种反面现象,就是如果片面强调单元测试覆盖率的话,会有人只写出测试“永远正确”的单元测试来(显然这是中国式应试教育的变种)。经过讨论,大家认为这种情况并不严重:通过培训,可以提高程序员们对测试的能力;通过引导,可以让程序员们意识到1到2年的开发时间和10年为单位的运行维护时间相比,眼光应该更多落在持续的维护和升级上,避免一些短期行为对产品质量的影响。

最后,大家总结出来了一种“代码show”的方法,就是项目组不定期地召开“代码秀”,让项目组每个成员都找出自己写的最好的代码和最差的代码,展示并解释给大家,并集体讨论和分析,甚至还可以请专家点评。会议不做记录不批评更不做考评,让与会者可以没有后顾之忧。通过这种方式,我们觉得是有助于提高大家编码能力的。

嗯,这样算是“专家推广法”么?哈哈!


原文链接:http://www.cnblogs.com/BigTall/archive/2011/11/14/2247732.html
加载中
返回顶部
顶部