今天早上例会最后，我把上周五讨论到的重视质量，请大家明确验证方法说了一下，但从大家的反应看，应该是觉得对验证所需要的消耗是否值得还是心存疑问的。

 

而事实上，对这方面到底需要多大的投入，能产生多大的价值我也有疑问，毕竟，产品前期开发时间已经用了很多，市场打开后，已经有用户针对演示的版本提出了一些需求，我们的底线是不能比原来的开发模式消耗更多的人力和时间资源。

 

上周末，和老大商量后，我向几个开发Leader发出了邀请，告诉他们我们再做一个实践，有兴趣的话他们抽空来作战室观摩，也可以参加每日站会，但我们最近不打算展开试点。我们会最终等N产品出了2～3个客户定制版本，软件1.1版本结束后，对整个阶段成果评估后，再考虑是否扩大试点。这样做的目标是让大家知道当前被讨论的热火朝天的Scrum我们也在做，他们随时可以来了解我们实践的进度。

这当然一方面也是考虑到我们过程改进人员自己的工作展现，子曾经曰过

 

今天下班前，刚好负责这块产品线开发人员的Leader 来找我确认个问题－

（背景说明1：我们是弱矩阵，以产品线分开发部门，也就是说Leader是DPM的头，当然开发Leader兼重要产品、重要项目的DPM，其行政工作不多。PS：老大是开发、测试、过程改进、等所有Leader，以及PM的头

－DTL：“我混进来看过了，上次你们讨论数据库接口不是中间把我叫进来说了五分钟嘛，我觉得很好啊，期待你们的结果”，转身准备逃离我这只苍蝇

 

－我继续紧抓不放：“你好歹和我说下自己观察的感觉吧”，我用虚怀若谷的态度赤裸裸的表达着我对于赞许的渴望。

－DTL：“看上去有点好，但是我是不会这样做的，每天开会要浪费我多少时间啊，我Z产品这边开发人员现在只有4个，把所有模块分到个人手中，每周我们互相交待一个各自进度就足够了。我们4个人是资深的工程师了，有什么事情临时说下好了，没必要每天讨论的。”

 

－我：“敏捷开发更试用于有经验的工程师，现在P产品新人比较多，这是他们事实敏捷方法的先天弱势，但是他们更需要每天开会明确下任务，每天的会议对他们很有用的。”

 

－DTL真乃俊杰也，看看逃掉是不可能的了，立马把遭遇战搞成持久战，开始对我进行洗脑工作了：“我看你们操作的，看起来是比较透明，每天做什么一看就知道，但这些是虚的，关键之处在于你们怎么验证每天的任务，如果不能验证，那和我每周一次的碰头会议没有什么区别，无非更频繁了而已。”

 

“而且，对待新员工来说，即使没有你们所说的每天站会，之前新员工导师也会每天确认他的进展，你们的站会无非是更多的人帮新人出主意而已，另外，你们常说的Codereview，我们在新人这边都要看的，现在你们的做法和之前有很大改进的是看板上每个任务和需求能够关联在一起，但这些以前也有，只是颗粒度更大。”

我们的Team Leader们基本都是这样，你找他问这问那，他说得不多，但一旦他申诉的欲望被释放后，就展开了他们直指人心、见性成佛的麻辣演说，他们需要的是倾听，这时候，我应该由苍蝇变成蜘蛛了。

 

DTL随手翻着我桌上一堆关于敏捷开发的书，这是他演讲的道具了。

－“敏捷开发的书我也看了些，我觉得我没看懂，我认为真正解决问题的应该是测试先行，先写测试桩，在编码的时候增加测试代码，这样可以解决变更都会额外出出一堆Bug的情况，这样才不至于在后期投入一堆的测试资源，而且不断反复。”

 

－“但以目前的资源来看，没有人受过这方面的培训，所以，如果在毫无积累的情况下，据说试验测试驱动的模式所需要的开发工作量要超过传统编码模式的三倍以上。你明白，就目前的情况来看，不可能存在这样优厚条件的项目。”

 

－“当然，你们需要继续尝试，来做比较，看效率是否有提升，但我觉得，就现有的人力会和总体技能来说，我们的效率已经很高了，这么少的人，这么大的产品，几个月时间就要完成，管理上能带来的收益不会太多了，真正的提升应该来自于技术的改进，但恰恰是这块，需要投入更多资源来学习，这就两难了，我们的进度中并不包括学习新技术的时间。客户也不会给我们技术改进的时间，高级管理者也未必愿意负担这样的成本。”

 

－“而且，太多关于项目管理、方法的培训都是描述了理想状态，这些都是可遇不可求的项目状态，真正面临的困难太多了，我倒是很希望哪个顾问公司能有个牛人指引着我们完成一个产品，告诉我们构架到什么程度，需求细化到什么程度，怎么识别出可能的需求变更，怎么保持和客户的密切联系，我跟着一路学下来我才知道是否有效。”

 

 

 

PS：感谢Google图书项目，我买的复印本《平衡敏捷与规范》（《平衡敏捷与纪律》的中译本），不够清晰，今天居然搜索到Google图书上有