引论－谈下我的软件和团队之路

2大伤痛

软件开发了这么多年，也带了很多的团队，真的没什么心得，只能说有点感慨。

软件开发到底难不难，这真的是一个问题，刚刚毕业的时候，觉得做软件乐趣很大，困难很很小，结果呢，到现在还没有一个项目令自己满意。既然不难做，但为什么就是做不好，这真的是一个揪心的问题。

软件团队到底需要多少人，这已经不能称为一个问题，而是一处伤痛，初出茅庐的时候也曾经认为一人一机就是软件，但遥望印度千人团队，真心不知道他们在干嘛，为什么要那么多人，难道他们都很苯？

如果说有什么心得，还不如说我心中的2大伤痛，以搏一笑：

1.       软件只需要开发就可以完成，团队只需要开发就可以组成。

2.       软件出了问题是可以改的，而且不难改

 

软件就是开发

也许大家会笑，当事实上大部分人都会被这2个问题伤到，而且伤了好多年。

软件只需要开发，这个看上去是一个很浅显的道理，就像古龙式的大侠那样，杀人就是用刀划过敌人的身体，就这么简单；是的，软件开发就是把代码编写出来，编译运行，交给客户，的确就这么简单。

细细品位这第一个伤痛，我发现这个问题其实是看似偶然中的必然；软件的最小组成就是代码，有了代码就有了软件的实体，有了实体就可以认为完成了软件，这个是非常实际的想法。加上老板最关注的是项目的成本和时间，那么为开发团队增加开发人员看似是最“有效经济”的方法，一人开发一周，那么2个人最不济开发3天应该够了把――大家都会如此思考。

当然，软件开发还真的是神奇的所在，它的一个神奇之处就在于，无论如何，软件的生产过程还是可以完成的，无论如何，在一定的时间和努力之后，软件还是诞生了，他的诞生时候似乎是必然的，不可阻挡的,那么我们还在担心什么呢。

 

软件没有失败

有人说,软件完成仅仅是万里长征第一步,还差的远呢,客户的要求还远远没有结束. 真正的修改还在后面.是的,软件开发的第二个神奇之处就是,软件可以通过不断的修改来弥补以前的错误,不管你提交的软件是100分还是20分,它都可以通过不断的修改而继续存活下去,可以这样说,只要还能修改,软件就没有失败,那我们还担心什么呢.

2大神奇法则

这里,我们引出了软件开发的2大神奇法则:

1.       软件只需要开发就能进行,并且基本都能完成.

2.       软件只要修改就可以存活,而且很少最终失败.

首先,我们必须感谢这2个神奇的法则,它大大降低了软件开发的入行门槛,使得很多团队和个人,即使懵懂幼稚,即使身无长处,亦能昂首踏入这个行业,以各种各样的姿态开始自己的职业生涯.

其次,这2个法则也深深的伤害了很多团队和个人,在进入这个行业若干年以后,很多人发现,这2个法则所营造的就是一个迷魂阵,一个无底洞; 软件总能完成却从未结束;软件不会失败却从未成功; 困惑与当下的实践,迷茫于未来的发展.

 

我在担心什么

我在担心什么,其实我也说不太清楚;

首先,那些必然完成的软件没有给我和我的团队任何美妙的感觉,做的好不好,是否可以算成功,这个问题几乎没有人可以回答,那么自然也就没有答案了.

其次,永无止境的修改,最终的结果只能是伤痛,日积月累的疲惫感,不断受挫的成就感,加上毫无希望的未来. 几乎没有人会喜欢这种”永不言败”的感觉,团队的崩溃和软件的摆烂,几乎是必然的结果.

最后, 梦想和发展,几乎已成奢望,遥望欧美令人羡慕的先进开发方式,展望自己30岁以后的发展空间,总是觉得那么遥不可及,对职业生涯的希望已经到了破碎的边缘.

 

寻找突破

如何突破,无非是自身寻求突破和效仿先进模式;自身寻求突破太过理想化,如果自己有这个能力,要突破早突破了,何必等到现在.

效仿他人先进模式是必然的,当也绝不能盲从: 别人的先进模式是大学毕业水平,而我们刚刚走出幼儿园,怎么学,学什么,并没有想象那么简单.

这里就谈2个大家都耳熟能详的模式: CMMI和敏捷开发.

CMMI是一个非常不错的体系,当我希望大家知道的是,CMMI就是大学毕业水平,给我们这些幼儿园和小学的小朋友来用的确是有点一知半解. CMMI2 就基本要求到20人团队(一个项目),试问一般中小公司有多少单个开发团队可以到20人? 更不要说团队内部的人员素质是否达标这个问题.也有人谈到裁剪,这个是没错的,但问题是谁来裁剪? 让我们这些小朋友来裁剪大哥哥的论文? 靠谱吗? 难上加难. 我也曾寄希望与国内的CMMI培训团队来帮我们裁剪,最终也是发现这也是勉为其难. CMMI能用,但全用是邯郸学步,裁剪是困难重重.

敏捷开发,这个更是一个冷笑话,敏捷开发是什么,是高中水平吗,完全错了,敏捷开发是研究生水平,是参透了大学水平的更高层次的升华,软件开发没有”银弹”,没有捷径,如果小学还没有毕业,就先用研究生的手法来解题,其结果只能是彻底的失败. 我的看法是,如果CMMI2都觉得遥不可及的团队,不要轻易尝试敏捷开发,先打好自己的”内功”根基.

 

我的”银弹”

l 学习:学习了解先进模式和理念

l 自省:认真分析自身团队和成员的能力

l 定制:寻找最小模式,从零开始,重新组建合理团队,搭建合理流程.

l 发展:走上不断积累提高之路

这里我认为有以下几点心得:

不去了解先进模式是闭门造车,必然失败.

不根据本身团队情况是盲目改革,必然失败.

软件开发有其规律,最小模式绝对不是”两把菜刀闹革命”,没有办法获得最低资源要求,就不要改革.

如果你的改革不能形成有效的积累模式,就不要改,改革为的是将来不断壮大而不是现在解决一时疑难,没有发展通道的改革还不如不改.

 在下一篇文章里面,我将会对软件开发和团队的最小模式做一个探索.