然而一个人的项目是否不需要管理?当然不是,因为有文档,有代码,有灵感,有经验,等等都需要管理。只是此刻的管理是自己完成的,可以更简单一点。我们已经有过一遍又一遍的调试以前已经fix过的bug体验,也有过一遍又一遍的查找以前自己实现过的技术的经历。软件工程的理论,在开发过程中的作用,就是指导如何做好管理,以取得软件的可用性、正确性和合理性。如果我们清楚知道这是它的目标,就可以抛开一些对自己不适用的枝节。
那么它是如何做到这一点的?
我认为软件工程中最重要的,最有实际意义的,是它界定了工作职能,从而也确定了责任归属。什么意思?说白了,就是什么人做什么事,出了问题谁负责。那么它是怎么界定工作职能的?是通过对软件开发流程的划分来实现的。软件工程把软件的开发划分成很多个相对独立的阶段,每一个阶段都有相关的人员来实现,也就有相关的人员来负责。分工不清,责权不明,是导致管理混乱的最主要的因素。所以即使是两个人的项目,也是需要软件工程来指导的,因为通过它,可以更好的知道如何可以合理分工,划分工作职权以取得最终的成果。当然,走教条主义的道路是非常愚蠢的。
那么软件工程到底是什么?
软件工程是针对“软件危机”提出来的。它是一种工程,把经验和理论应用到实践中来,解决软件开发中出现的各种问题。
这是什么意思?就是说,软件工程是用来解决实际问题的。如果软件开发中没有遇到管理问题,软件工程就不需要管理的内容;如果软件开发中没有遭遇文档混乱,软件工程就不需要文档的部分。但是如果很幸运的遭遇到了这些,那么这一切都是不可或缺的。软件工程不是一个固定的呆板的框框,而是一个有弹性的概念。所以,如果不是要去申请iso或是cmm认证,完全不必要一板一眼的按照iso或是cmm的规范去做。所谓“有企业特色的软件工程”,完全可以从吸收现有的模式和规范中完善起来。
但这并不是说所有在开发过程中出现的都是软件工程,只有那些能引导开发走向成功的才是真正有意义的软件工程。其他的,最多只是失败的尝试。
那么应该什么时候开始实施软件工程?
软件工程一定要在一个项目开始之前开始吗?一定要贯穿整个项目吗?为什么?
不是的,软件工程可以在项目进行中的任何时候开始,也可以在任何不再需要的时候结束。因为软件工程把开发流程划分成不同的阶段,所谓“生命周期”,在不同的生命周期,软件工程提供了不同的模式可以参考。
那么软件公司如何实施软件工程?
首先要知道软件工程,理解软件工程;然后要了解现有的软件工程的模式和规范。ISO、CMM或是Agility,都定义了一套规范。这些规范是经验与技术,以及理论的积累。它们存在很多合理的、可行的模式,可以引用和参考;但银弹是没有的。当然,我们可以重头再来,造他们造过的轮子,摔他们摔过的跤;但很明显,这是不必要的。
实施的最好方法,也是最可行的方法,成本最小的方法,是根据开发的客观的因素,修改那些规范,以符合我们的开发过程;但是最主要的,是修改我们的主观认识,以符合那些规范;而最重要的,是在实施中发现那些规范不合理的地方,并改正它。
那是否会变得无法适从,从而陷入混乱?
是的,有这可能,所以任何的修正都应该是谨慎的。所有的修改提议都应该是自上而下的,而决定都是自下而上的。
软件工程对项目的规模有要求吗?
我们担心过小的项目应用软件工程是否会陷入官僚主义,从而加重项目的负担?
我们再来看什么是软件工程?软件工程并没有定义什么才是软件工程!也没有定义软件工程自身的规模。软件工程的意义在于对开发阶段的划分,以及分工和责任归属。这与项目的规模没有什么冲突。相反,越是小的项目越是需要软件工程的管理。软件开发的一个共识,是把一个大的项目划分成一些小的模块,再把小的模块划分成更小的模块。如果这些小模块是独立的(或者原来就是一个独立的项目),那么软件工程至少可以提高它的重用性。
对于一个软件工程观念不深的团队,不要期望他们在接手大的项目的时候可以使用软件工程,如果他们在小项目中不愿使用的话。前者的复杂度不是他们可以想象和承受的。
应用软件工程会增加工作量吗?
是的,但只是针对那些在不使用软件工程管理的项目中很轻松的人而言的。软件工程会使他们要么失业,要么负起责任来。相对工程师而言,他们会从混乱的毫无头绪的状态中解放出来,他们的工作会变得有效率。损失的是以前尸位素餐的人将暴露出来——这可能是它的唯一的缺陷,同时也是它受到很多企业/个人抵制的可能原因之一。
我们应该怎么做?
学习!如果我们不想重头发明一个轮子的话。
尝试!如果我们希望改变的话。