在读这篇文章之前,需要大家了解文章的一些前提、假设,以免引起一些不必要的混淆(confuse)
假设一、下面谈论的观点仅仅适用于项目周期短(一年左右),最终的软件产片不会对社会或者人身直接造成伤害的软件产片、项目或者公司
假设二、 待定 :D
这几年来,随着对流程、质量控制等概念的理解以及实践,越来越觉得当今软件公司里面,尤其是大公司里面,宝贵的程序员资源在被浪费。他(她,后面都简称他们)们的时间被浪费在non-value added的流程上,汇报上,开会上以及流程混乱所引起的各种问题上。没有看到过相关的调查。但是如果做的话,也许会有惊人的发现。至少在大公司里面,一定是惊人的结果。
今天在cmcross上看到了一篇关于流程自动化的文章(An Automated Infrastructure and Workflow for Process Improvement
,http://www.cmcrossroads.com/content/view/10210/120/),再次触动了我的神经。虽然在流程自动化、敏捷编程等高效率编程上面没有太多的经验,但仍然想把我的一些体会以及想法和大家分享一下。
上面的文章中提到的几个观点,本人非常之赞同!
观点一、原文以及翻译如下:
With most tools, this requires a lot of extra work-each developer has to run the tool, look at a report of problems, sort through false positives, figure out which of the reported violations he is responsible for fixing, and then actually fix them. This extra work slows down the development process and distracts developers from the creative tasks they're hired to do.
大致的意思就是说公司或者老板为了改进流程或者质量,从而增加了设计、写代码意外的和质量相关的工作,如流程检查、看bug report、run质量改进工具,如klocwork等等。总之,程序员的精力被严重分散到与创造性工作无关的一些事情上了。而这些事情才是他们的本职工作!
大概两年前,看到过一篇类似的文章,就深有感触,并努力在实践工作中,从SCM的角度出发思考如何提高团队的效率、质量,并尽量提高程序员的产出。
其中有几个原则可以供大家参考:
1、正如上面的文章所述,设计程序以外的一些事情应该尽量自动化、高效化、简单化并且人性化、一切都要从节省程序员的角度出发
2、在设计软件开发流程的过程中,设计者经常会碰到的问题是,对于有一些只有万分之一可能性的case究竟考虑还是不考虑,考虑就意味着要增加流程的复杂度,或者增加检查环节。也许一个项目下来,只碰到不到10次以内的此类特殊情况,更甚者,只有一两次,而为了这一两次的特殊case,却花费了相当的人力、物力。因为每个流程环节的增加都会相应的增加软件开发的成本。如:
a、考虑这种特殊情况之后,根据流程的变更,往往要对相关的工具做一定的改动;
b、流程以及工具好了之后,要花时间维护、培训相关人员;
c、在日常的项目执行过程中,每一次检查,都要花费相关项目人员的effort。以SCM的流程为例,SCM要花时间检查、程序员要做pre-check、如果真的发现问题而要程序员解决,来来回回要花SCM以及程序员许多时间。同时也许在项目沟通、汇报的环节上要花一定的时间来讨论相关的问题。总之,严重浪费啊!
而从我的实践经验而言,往往这种特殊情况在工具、流程比较成熟的情况下,是可以通过人的主观能动性后者说聪明才智来解决的。而花的时间一般比较有限的!
观点二、Of course, Rome wasn't built in a day. If you try to implement this all at once, you risk overwhelming the team, which sets the stage for failure. If you really want it to last, be patient and ease into it. Incremental implementation is the path of least resistance.
翻译过来大致就是几个著名的成语:“冰冻三尺非一日之寒”,“且不可急功近利”,“如果想成功地坚持到最后,就要循序渐进”。
这几个成语众所周知,但是在实践过程中,却不那么好把握。本人体会如下:
1、想一下子把completely automated process/pratice是天方夜谭!因为计划是永远赶不上变化的;最佳的实践方式就是continous improvement and drive to automation day by day!而且就时间、空间、经验等限制,一次性搞定也是不可能的。即使是“XX专家”也要遵循同样的规律,否则同样会失败、招人背后戳脊梁 :D
2、在设计流程之初就要兼顾效率和质量,虽然要持续改进、但一样要有比较好的计划(roadmap)。在这个环节上,丰富的经验起着非常关键的作用。并且是无法速成的。对于入门者来说,除了努力学习之外,交流、积累也十分重要。
最后我也引用一下一个时髦的短语“蝴蝶效应”,意思是说,地球一端的一只蝴蝶轻轻扇动翅膀,也许导致的就是地球另一端的风暴!在流程的持续改进过程中,需要的就是团队中的每个人,尤其是各个环节的专家们不断地、敏锐地发现该进的机会以及想法。还是以SCM为例,在大公司里面,integration过程中经常出现的问题是conflict,也就是说有两个人以上同时提交了对同一个文件甚至是同一行的改动。这种问题随着build request的数量增多会越来越让人无法忍受。解决的途径之一就是more frequent integration & release,也就是continous integration。也许nightly build/run不是非常容易实现的,但是哪怕是把人工(scm)集成间隔缩短几天,也许带来的影响就不是简简单单的resolving conflict了。
>>待续!有时间,我希望能够把自己有限的一点经验、体会一点点和大家分享,希望能够引起一定的“蝴蝶效应”