学习
实践
活动
工具
TVP
写文章

编写软件需要多少人?

讲个笑话,问:拧个灯泡需要几个程序员?答,需要:一个业务分析师,一个产品经理,一个流程或者项目经理,一个架构师,一个DBA,一个设计师,一个QA经理,一个发布经理,一个测试人员……嗯,我忘了谁了吗?

真是个糟糕的笑话。

现在,大多数组织都有很多人参与软件创作。现代软件开发通常有大量专职化的角色,包括程序员。

在1981年我开始工作的时候,大部分的角色不是独立的人,很多情况只有两个:经理和程序员。我工作的国防承包商基本上拥有:经理和程序员,需要程序员的经理。当我被经理指派为程序员时,要做任何工作:编程,测试,交付,记录文档——无论什么都做。当时有个程序员-分析员的概念,用来区分谁做第一部分,但我记得我是什么都做了。

当然,其它公司怎么做的是个谜——没有互联网和现代的沟通渠道,别人怎么做的,我们无从知道。

什么都做有个好处,我对好多事情,包括和客户沟通,设计界面,识别和跟踪计划,架构,还有其它各种非编程工作,都感到舒适。今天,除非是在一个启动环境(有时候甚至没有),作为程序员,除了编码很少做任何事了。人们甚至取笑程序员做像设计这样的工作。

在80年代,程序员要做的好多事,今天都是专职的做了。当然那时的应用只有很少的交互部分,如网络和数据库。但我们的工作环境缺乏:外部帮助、开源工具、以及任何现代沟通工具,如电子邮件等。

另一个区别是大型团队基本上无法组织。想象一下100个程序员一起做一个应用,没有电子邮件或Slack,代码库,JIRA之类的工具,而且只能通过联邦快递和磁带驱动器来协调软件。团队之间合并代码是个手动过程——除非你真的非常小心谨慎,否则很容易出错。

我的团队就非常典型:我们在得克萨斯,作者在纽约,在8个月里每隔一天通过联邦快递交换代码。后来在1993年左右Deltagraph的最后一个版本中,因为加利福尼亚州的出版商增加了两个程序员,我们又做了一次交换代码。

今天没有人会这样创建软件。今天我们有网络,工具和流程来协调庞大的团队,但是成本非常高,创建了许多不同的专业角色来支持这个团队。有趣又让人惊讶的是,有了这么多工具,却需要更多的人来做事。

这些年我一直在小型编程团队,除了Deltagraph在1993年最后一个版本中有6个程序员,墨西哥的一个项目在2000年年中有40个(一个巨大的失败),4个是我做过的项目(包括大项目)里最多的。

当然,在过去的几十年中,项目的非编程方面已经获得了越来越多的角色。有趣的是我们如何用4个程序员,2个测试员和一个产品经理,创建了Deltagraph,并且创建了一个领先全球的产品。今天,我在一家庞大的非技术公司工作,有80个iOS程序员和更多的非程序员,支持人员和管理人员。然而,整个应用程序(基本上有两个类似的)功能并不是那么复杂。

我工作的团队现在只有两个iOS程序员(共有三个人),我们为两个程序员创建了一个大的应用程序,将它移植到第三个业务单元的应用程序,并在同一时间内构建了三个内部应用程序。

另一方面,墨西哥的项目有来自三个国家的40名程序员,每星期飞往同一个房间辛苦工作。三个月后,整个项目陷入了僵局——客户的钱用完了。

在旅行公司(我的两个工作之前)我们也有一个小团队,用20人,设法创建和支持7个产品,其中一半是程序员(4个iOS)。

我仍然喜欢做更多事,不仅限于取工单,做工单,优化代码,更改工单状态,这些现代程序员的角色。

今天的程序员没有和我一样的“经历”,只有你亲自去做,才能体验到它,这就是在初创公司工作的真正有价值之处。从我所知道的情况来看,也不总如此,初创公司往往认为整套的支持人员是必要的,程序员除了编码之外别无他用。这很可能产生高昂的风投资金。

即便有了现代工具和流程,庞大的程序员团队现在是非常普遍的。最近一次会议上,我问过他们的移动团队有多大,有几十个程序员是常态。Uber有100多个,不敢想象Facebook有多少。

他们都做些什么?我认为现在的程序员与80年代相比,每天写的交付代码很少。我认为正规的是写很少的代码,写很多的单元测试,花大量的时间在流程和会议上。如果做这些事,相比之下,我们那个时候可以完成更多交付代码。那时候我们只有很少的工具,没有电子邮件,没有知识库,没有流程,除了我们想到的,坐在一起通过交谈沟通。我们有更多的时间思考构建什么,如何构建,如何测试它;至少我的两家公司(1985-1994)每6个月左右交付一次。因为用软盘装盒发布,要对发行版负责,所以不能经常发布。

请注意,我们不是瀑布方式,创建的所有东西,都是以很久之后被称作敏捷的方式完成的。

今天人们通过自动化管道推出软件,并且每一两周发布一次。在我的工作中,尽管所有人都经历过一个及其讨厌的过程,幸运的是我们每两个月发布一次。如果有大量的人员,各自负责一个大型自动化测试管道组织的很少一部分,就能够很快地把它发布出去,但是要花费很多钱,而且不保证结果一定是好的。

我通常在资源有限的团队工作,即使是大型项目中,我们也有更多的自由来完成任务,但不会定期每周交付产品。大型自动化团队的代价是否值得?也许对有些公司是值得的。

对我来说,宁愿一个非常小的团队,只需要更少的支持人员,做更多的事情。我无法在100个程序员的高压力团队中工作,听起来就无趣。我不知道怎么比较这两者:4个人花费的时间,由100人每周抽出来的产品。

我宁愿做更多的事情、花时间来创建一个优质的产品,而不是花大量的钱,短时间内发布产品。最后,对于您和您的公司来说,重要的是能承受什么代价,有多大的意愿花钱组织很多人,或者消耗多一点时间少花些钱。

是组织更多的人,每个人做的更少,并且需要很多支持人员;还是很少的人各自做得更多?两种方法各有主张。我只是想成为后者的一部分。

http://thecodist.com/article/how_many_people_does_it_take_to_write_software

译者介绍:

陈晏娥,鞍钢矿业运维,专注云和虚拟化实施和技术,云技术社区译者

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180319A1QUWJ00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券