我的 20 年软件开发经验总结

软件开发是一个发展很快的行业,作为一名程序员需要具备开放的心智,以应对不同的环境下不同的开发模式。提出有用的软件开发方法并不容易。困难不在于定义它们,而是说服别人遵循。本文作者从《人类简史:从动物到上帝》一书中透过现象看本质,解析初创团队到大规模团队的软件开发模式不同之处,分享其 20 年的软件开发经验。

智人和集体创作模式

最近我阅读了 Yuval Harari 的《人类简史:从动物到上帝》一书。这本书的基本论点是:人类需要“集体创作”,因此我们可以在多于 150 人的情况下进行合作,我们的大脑足以应付。集体创作针对那些无法在现实世界中看见和摸到的事物。诸如宗教、民族主义、自由民主或波普尔哲学。虽然这些事物不存在,但是当我们像他们一样行事时,我们很容易忘记他们并不存在。

IT 行业的集体创作模式

1. 瀑布模型

这促使我联想到当今一些关于软件工程领域的事情,它们困扰着我。20 年前当我投身软件行业时,瀑布模型占据统治地位。我加入了一个约 400 人的咨询公司,他们在着手项目之前会写很长的软件规格说明书,这些规格非常细致,精确到每一个 Java 类和属性。这些规范写好之后会提交给客户,但是有时候并不知道具体是谁和客户确定的需求并且书写了这些规范。之后开发人员就按照这个规范开始开发、交付,直至收到项目款项。然后皆大欢喜,其乐融融。

但是实际上大多数时候都会出现另一种情况:客户抱怨规范与交付不符,并且交付的产品往往与规范不一致,因为在项目进行的过程中,很多“事情”发生了变化。换句话说,瀑布模型是一个“集体小说”,给了我们足够的稳定性和一致性来合作,我们按照事先定好的规范把产品开发出来并得到报酬。

这个咨询公司在我加入后不久就倒闭了,无疾而终。

2. 初创公司的一段经历

之后我以第 39 号员工的身份加入了另一家软件公司,公司的开发工作量很大并且没有使用瀑布模型。事实上,公司内部根本没有任何的项目文档,需求和规范都是通过电话确认。设计、原型和产品开发很难区分。我感觉这样的情形混乱不堪,完全和我学到的软件工程理念相违背。但是没有更多时间思考应对方法,因为公司项目很多,开发任务繁重,这样的开发状态就这样一成不变地继续。

事实是,我们公司小到甚至不需要命名一个集体小说。项目需求和相关细节可以保留在我们的脑海里,如果你需要帮助直接在办公室喊一声就行。基调是这样的

当然,这是集体小说,我们只是没有为其命名:

  • 我们永远不会有任务说明。
  • 我们不需要人力资源或企业的沟通。
  • 我们只雇用最好的员工。

随着我们公司规模的逐渐壮大,有客户开始询问我们的软件开发方法和规范。我肯定不能说我们的开发方法就是写代码。更不能告诉客户我们有现成的使用 C 语言开发的服务器程序,它运行速度很快,针对不同项目我只需花费一周左右对其做简单的调整即可完成开发工作。

事实上有一种叫做“快速应用程序开发”(RAD)的东西强调了原型设计。我们告诉客户我们做了RAD,他们似乎很高兴。听起来感觉我们很专业,但说实话,我不知道我们当中是否有人真正理解或者阅读过它。

作为“集体小说”模式它是有效果的,仿佛客户在监视我们的开发。

很快,我们公司的规模翻了一番,从狭窄的小办公室搬到了一个更大的场所,办公桌更加宽敞,楼层更多。因此你不能在办公室喊出你的问题了。团队变得更大,一些名为“项目经理”的人开始出现,他们谈论“规范”并且收集“需求”。我们试图从零开始重写整个平台,但是失败了。

是的,我们好像又回到了瀑布模型的开发模式,但是又有所不同,因为工作周期越来越短,但是因为客户不断变化的需求而产生的争议依然存在。到底是不是瀑布模型呢?我们也不太清楚。

3. 敏捷

我首次听到“敏捷”一词大概是在 2003 年。但是,实际上我并没有深入了解它。我对敏捷的了解源于网上的零散介绍,以及客户和敏捷拥护者谈论的只言片语。当我咨询那些声称自己对敏捷很了解的人时,不同人的解释和理解好像出入很大。实际上那些深谙敏捷模式的开发者在向非敏捷客户发布软件时依然充满压力。因此,我们继续依照传统的规格书进行软件开发,也会使用少量的敏捷术语。比如,会议被称为“scrum”,但是其他的情况却与之前的情形并无太大差异。

作为一个集体小说它是有效的,因为在我们编写软件时,它使我们保持和客户以及项目经理的沟通。

此后,我曾在一家拥有 700 人的公司工作,目前在一家拥有 10 万名员工的公司工作,但模式基本相同。

你不相信吗

我不会排斥这些开发模式,因为排斥是无意义的。即使软件开始模式不存在,也会有其他的模式被发明出来,因为我们需要借助这些模式进行有效地合作。有了这些开发模式才能扩大软件开发规模。敏捷模型对于员工流动性大的公司来说非常有用,并且这不是巧合。

《人类简史》一书中有许多有趣的论点,其中之一是:由于这些集体小说不能充分地解释世界,往往相互冲突,文化的有趣部分在于感受到这种紧张局势。幽默通常源于这些紧张局势。

“对于心智最高级的考验是能够同时持有两个相反的想法,仍然正常运转,互不干扰。” -- F. Scott Fitzgerald

当在一个小团队之外使用敏捷时,我不知道其他人是怎样,我个人反正是感觉非常紧张的。当一个我从未见过的并且对我的工作一无所知的人提议我删掉我的任务计划(这些任务是外部决定且没有商量余地的)时,我除了苦笑还能干嘛?

当你的控制权在每一个环节都有人否决时如何保持敏捷?基础设施、审计、安全、财务规划、财务结构都有助于快速提供有意义的产品迭代的能力。这里的客户是谁呢?我们很绝望:

当我看到这样的代表敏捷的图表时,我只能用我与同事分享的黑色幽默来回应:像在教堂后面咯咯笑的小孩。

在一个规模较小且运作良好的团队中,敏捷的理念会忽略,剩下的是(当它很好的时候)一个相互信任的团队、对自己的试验的开放、可以找到协议和解决方案的清晰的结构(正式或非正式)以及有效的合作。谷歌最近对其进行了阐述。

换种方式阐述

你可能会认为答案是提出一种更好的新方法,而不是像我们曾经尝试过的:

原文发布于微信公众号 - 网络安全社区悦信安(yuexin_an)

原文发表时间:2017-10-29

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

人工智能取代不了什么?

人工智能取代不了什么? 2017年12月31日,有一场思想跨年的晚会吸引了我的眼球。有一个环节讨论的是人工智能,其中一个嘉宾说,跟人打交道的工作是需要了解人的表...

19470
来自专栏云计算D1net

不再为别人作嫁衣!IDC服务商转云成必然

过去,IDC服务商不得不思考这样一个问题:传统业务是不是“为他人作嫁衣裳”?如果只是为客户提供一些基础资源,例如机架、带宽、供电,等同于在为基建、运营商、电力“...

438110
来自专栏腾讯大讲堂的专栏

重磅|微信发布2015微信生活白皮书

今天在腾讯全球合作伙伴大会微信分论坛上,微信团队对外做了“微信·生活”的分享。现在,就让我们一起,从微信视角来看看中国人的喜怒哀乐、衣食住行。以下是报告的全文,...

239100
来自专栏机器人网

追踪国外的人工智能进展 关注热点

探讨人工智能,就要回答什么是智能的问题,综合各类定义,智能是一种知识与思维的合成,是人类认识世界和改造世界过程中的一种分析问题与解决问题的综合能力。对于人工智能...

29950
来自专栏哲学驱动设计

中国软件工程大会总结

    今天参加了一年一度的《中国软件工程大会》,听了许多前辈在台上精彩的演讲,自己也有很多感触。接下来,我会先把几个重要的演讲总结一下,最后再写一个自己的心得...

202100
来自专栏腾讯大讲堂的专栏

7个小时,7万人的产品经理大会,究竟发生了什么?

很久没有参加一个会议,干货太多厕所都舍不得去,宁愿憋伤自己。 --摘自参会者 hibaby 的朋友圈 由人人都是产品经理与腾讯大讲堂联合主办的2016中国产品经...

218100
来自专栏镁客网

8i的出现或将改变VR的格局

19430
来自专栏量子位

3个问题,1套非技术人员的AI方法论 | 哈佛商业评论最新热文

这篇《哈佛商业评论》最新推荐的热文,来自一位叫Emma Martinho-Truswell的战略咨询专家,她是“牛津洞见”的联合创始人及COO,他们这家公司就是...

10500
来自专栏互联网数据官iCDO

分享经济数据化监测在市场活动场景中的应用分析【精简版】

前言:近年来,分享经济在中国迅速崛起和发展,作者从数据监测的角度出发, 分析了在市场活动场景中的应用 在今天,”分享经济”这个词已经不再是一个陌生的词汇的,依据...

27370
来自专栏程序员互动联盟

作为刚培训出来的程序员,面试的时候被问到的好多技术都不会,越面试越被打击该怎么办?

作为一个在软件行业已经混了十几年的老司机,初学者参加面试收到打击是很正常的事情,这个和是不是参加培训没有太多直接的关系,关键还是经验能力上的问题,基本上入行之前...

74830

扫码关注云+社区

领取腾讯云代金券