编辑注:软件开发是一个快速发展的行业,作为一名程序员,需要在不同的环境中适应不同的开发模式。介绍一种有效的软件开发方法并非易事。难的不是给他们下定义,而是要说服他人。本论文从《人类简史:从动物到上帝》一书中,透过现象看本质,解析初创组到大型团队的软件开发模式的差异,并分享他们20年的软件开发经验。
智慧与集体创造模式
近来,我阅读了 YuvalHarari的《人类简史:从动物到上帝》一书。本书的基本论点是:人类需要“集体创造”,这样我们就可以合作超过150个人,而我们的大脑已经足够应付了。群体创造是为了那些在现实生活中看不到和触摸不到的东西。比如宗教,民族主义,自由民主,或者波普哲学。尽管这些东西是不存在的,但当我们像他们一样行动的时候,很容易忘记它们并不存在。
IT产业的集体创造模式
1.瀑布模式
它让我想起了如今软件工程领域中令我烦恼的一些事情。当我在20年前进入软件业的时候,瀑布模型占据了主导地位。我加入了一个有400人左右的咨询公司,在开始项目前,他们要写很长的软件规格说明,每一个 Java类别和属性都要详细说明。在编写完规格说明后,提交给客户,但有时并不知道是谁和客户确定的需求,也不知道编写规范。在此之后,开发人员将根据该规范开始开发、交付,直到收到项目付款。接着是欢乐和快乐。
但事实上,大多数时候都有另外一种情形:顾客抱怨规范与交付不相符,而且所交付的产品常常与规格不一致,因为在项目进行的过程中,许多“东西”已经改变。换言之,瀑布模型是一种“群集小说”,给予我们足够的稳定性和一致性,我们可以根据预先设定的规则开发产品并获得回报。
我加入后不久,这家咨询公司便毫无问题地关闭了。
2.创业公司的一段经历
在那以后,我作为第39号员工加入了另一家软件公司,该公司的开发工作非常繁重,没有使用瀑布模型。实际上,公司中根本没有任何项目文档,要求和规格说明都通过电话确认。难以区分设计、原型和产品开发。这种情况令人困惑,完全违背了我所学到的软件工程理念。但由于公司项目众多,开发任务繁重,这种开发状态一直持续不变,因此没有更多时间思考应对方法。
事实上,我们的公司都很小,甚至不需要一本集体小说的名字。如果你需要帮助,直接在办公室大叫一声,项目需求和相关细节可以留在我们的头脑中。主要内容如下:
这当然是一部群集小说,我们没有给它命名:
我们从来没有任务描述。人力资源和企业之间不需要沟通。我们只雇佣最好的员工。
由于公司规模的不断扩大,许多客户开始询问我们
软件开发的方法和规格。当然,我不能说我们的开发方法只是编写代码。更加无法告诉客户我们有用 C语言开发的现成服务器程序,它运行得很快,对于不同的项目,我只需要一个星期左右就可以完成开发工作。
实际上,有一种叫做“快速应用程序开发”(RAD)的东西强调了原型设计。我跟客户说我们做了 RAD,他们看起来很开心。看起来我们好像很专业,但是老实说,我不知道我们中有没有人了解或读过它。
它具有“群集”模式的效果,就好像客户在监控我们的开发。
不久,我们公司的规模翻了一倍,从狭小的办公室转移到更大的地方,桌子更宽敞,楼层更多。所以在办公室里,你不能大叫问题。随着团队规模的扩大,一些被称为“项目经理”的人出现了,他们谈论“规范”并收集“需求”。我们尝试从头重新编写整个平台,但没有成功。
没错,我们似乎又回到了瀑布模型的开发模式,但又有区别,因为工作周期越来越短,但由于客户需求的变化,争论仍然存在。这是一个瀑布模型吗?而且我们也不清楚。
3.敏捷
第一次听到“敏捷”一词可能是在2003年。然而,我对此并没有深入研究。在网络上,我对敏捷的认识是从一些零碎的介绍和客户和敏捷支持者们所说的。在咨询那些宣称对敏捷非常了解的人时,不同人的解释和理解似乎相差甚远。事实上,有经验的敏捷开发人员在将软件发布给没有敏捷的客户时仍然有压力。所以,我们按照传统的规范继续进行软件开发,同时还将使用一些敏捷术语。比方说,会议被称为“scrum”,但其它的情况与先前的情况并没有很大不同。
这是一部很有效的集体小说,因为这能让我们在写软件的时候与客户以及项目经理进行沟通。
从那以后,我在一家有700多人的公司工作,目前在一家雇员达10万人的公司里工作,不过模式大致相同。
相关推荐