scrumcn_teamwork

敏捷开发与本能反应

经常听到有人提到敏捷开发与“本能反应”非常近似,比如凡事都需“看着办”,比如“不拘泥于形式”,比如“直击代码,不写无用的文档”等等。

那么敏捷开发与本能反应之间的差别是什么呢?

简单地说,敏捷开发就是无我状态的本能反应。
无我,无人(无我,无人,无众生)

按理说,本能反应是最接近最佳路径的,一线人员,工作现场,当下的问题,一定能在事先预定的路径之外找到更好的方法,除非有个“我”字。

1. 比如测试人员最近的工作繁忙,需要多调度几个测试人员过来,才能保证测试不延期。如果按照本能反应,开发人员中的一些人极有可能过来帮忙测试,或帮助编写一些节省人工的自动测试代码(后者是01年我们团队的做法,最终结果是25个开发人员只需要1个测试人员就能完成测试);但如果“我们是开发人员,他们是测试人员”,尤其是“每发现一个缺陷,他们得10元,我们扣10元”,这件事情多半就办不成。

2. 比如有一个人在每日例会上说遇到了困难,而另有人对此有非常容易解决的方法。如果按照本能反应,可能一句话就能帮助节省几个小时;但如果“我有我的工作,他有他的工作”,尤其是“如果帮助了他,我的工作可能完不成”,这件事情也多半办不成。

3. 比如某个文档在这个产品中的确不需要写,但是“如果他们不写,做CMMI评估的时候我们EPG组就会比较难办”,那么这个文档到底要还是不要写就真成了一个问题。

这些我与别人的分隔,使得很难在事情上走最佳路径,而多半会在人和分工上走最佳路径,尤其是按“我”的利益来走最佳路径。在这种情况下,本能反应就是错误的。

无现在的我,无未来的我(无寿者)

一个人的时候,也会出问题。

1. 一个设计非常复杂,按本能反应,怎么也应该记录下来点东西。但是如果“我现在心里清楚设计不用写,未来也不一定是谁在维护这些代码”,那么就很容易不写这个文档,却在未来产生很大的麻烦。

2. 一个代码这样写未来可能产生缺陷,但是这个版本这样写最快。如果“我要按最快的方法写,管他未来是谁”,那么多半代码就会很烂。

如果一个人说:我不写文档的原因是“我把设计表达在代码里”,如果代码很漂亮则的确如此,如果代码又很烂,就可见前者只是一个借口。

说实话多数吆喝“代码即设计”的程序员代码都很烂。
创造无我的环境

在多数有我的环境中,对某件事情而言,每个人提出的解决方案都不相同,而且没有一个是与这个事情的最佳解决方案重合的,因为每个“我”都按自己的利益行事。

最终的结果,是为了让这些我能凑在一起工作,创造出无数的部门规范、工作流程、中间文档、计划、中间文档的评审标准等等,用来约束每个我的工作。本能反应也就被压抑了。

“如何创造一个无我的环境?”这个问题在每个具体环境中,都有具体的最佳答案,受到具体人、事、物的限制,很难一概而论。

但如果没有任何前提条件地回答这个问题,倒也有一个“般若”一点的答案,就是“共振”。

所谓共振,就是在能控制的范围内先取得一些成效,以此换取他人及未来的共鸣,从而推广下去的方法。世界上的各种伟人,无一不是以这种方法工作的,影响力能远达万里、千年。

作为个人,首先可以破除现在的我;作为小团队(比如3个人),可以小范围破除我人之分,共进退;作为开发组,可以局部破除分割和个体考核;作为研发部,可以在部门内部推行新的绩效考核体系,等等。

尽管这些事情看起来都有其困难之处,但与那些“万里、千年”的事情相比,却微不足道,几乎可以说基本上只要去做,没有做不成的。

不过共振的原理,就是不谋求一说就通,一做就成,而是找到事物推广的固有频率,走得太快了,难免做不成先驱,反而成为先烈。

本人曾经在10年里频繁地更换工作,目的是找到一个可以“大展宏图”的地方,但都失败了。直到在一家企业固守了3年,结局令我大吃一惊,原来每个企业都是很容易被推动的,唯一要判断的其实只有一个问题:“这个企业值得推动吗?”

共振的内容,在本系列的以后会有2篇以上的文章还会提及。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载