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

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

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

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

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

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

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

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

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

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

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

嗯，这样算是“专家推广法”么？哈哈！