- 1【开发工具篇】git 常用命令合集_git镜像地址
- 2LT9611UXC双端口 MIPI DSI/CSI 转 HDMI2.0，带音频
- 3Vue入门开发_vue create -p
- 4一万字一篇文20分钟学会C语言和Python，十四年编程经验老鸟传授经验之道_c语言一万字
- 5Kafka（一）使用Docker Compose安装单机Kafka以及Kafka UI_docker-compose部署单机最新版本的kafka
- 6强化学习（四）—— Actor-Critic_actor-critic网络架构
- 7Android Developer Registration_developer registration fee
- 8哈希表算法原理_value.bucket 哈希算法
- 9【2024】基于springboot的高校食堂点餐管理系统
- 10【论文精读】大语言模型融合知识图谱的问答系统研究_基于大语言模型的问答系统 论文
3人2周上线，2人1周上线，Solo明天上线！开发周期果然不能用搬砖模式计算......
赞
踩
有10000块砖需要我们去搬，1个人1天可以搬1000块，那么总共要10天搬完。为了更快的完成任务，如果我们派10个人去一起搬砖，那么1天就可以搬完。
这个简单的道理，每个人都懂，如果要让事情做的话，那我们就派更多的人去做就好。然而，在我们的开发工作中，这样的道理不但没有用，有时候反而会成为遭难！
如果你在一些颇具规模的it公司待过，你就会发现一个神奇的规律，那就是团队人数越是多，同样工作量的项目的开发周期越是长！
往往那些动不动就有几百个人参加的项目，从项目立项、排期到开发之前，一般都要经历1个月甚至更久，而这个项目如果只是给一个几十人的小团队去实施，或许1个月的时间已经开发了大半。
其实，这之中涉及到了工作量与进度之间的玄妙关系，it项目中最简单的用来评判工作量的单位就是人月，是指一个人做一个月能完成的工作量。
但是，20个人10个月的工作量，20人月，表面看是10个人干10个月的工作量，10人月的2倍，但是实际上，并非可以简单的用乘以2来简单的形容这两者之间的差距，并不代表20个人的进度就比10个人的进度一定快！
因为项目当中有很多其他因素要考虑，比如20个人去完成一个项目，那么20人中每两个人就得沟通一次，也就是190次，这些就是传说中的沟通成本，而10个人只需要45次（我们暂且认为每个人的沟通效率是一样的，其实往往人越多，沟通效率只会越来越低）。
所以说，这20个人中，其实会有大量的时间并不是真正意义上的“工作”，而是交流沟通，而与人的交流沟通往往是最费时费力的。比如你以为你告诉别人了这是甜的，可能别人以为你喜欢苦的，但双方都认为自己理解对方的意思，最终的结果就是到交付时发现不对，进行返工。
所以往往在IT界并不是说，人越多工作的进度一定越快，可以完成的工作量一定越多，也就是并不意味着效率越高！
有时候一个项目经理发现项目比预期时间慢了，那么90%的人的第一反映可能都是项目人手不够，需要增加人手，但其实往往这种做法就是火上浇油，新加的人往往要花费不少时间去熟悉项目，而且仓促之间的上手，会造成项目质量的下降，导致更多的时间花在测试和修复bug上，恶性循环。
小编此刻就想起了程序猿圈子里的一本经典之作人月神话，作者是FrederickP.Brooks.Jr.。小编上述对于项目人月的理解也大多来自于此书。
这本书在软件工程管理领域畅销40多年，对于软件工程整体管理中碰到的各种问题进行了详细的解读，既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见。书中就反复提到大型编程项目深受由于人力划分产生的管理问题的困扰。
其实这本书为什么会被翻译成这个名字，小编的解读是：
人是程序员，月是时间，如果说1人干10个月如果等同10人干1个月，那就成了神话。
所以，简单来说，人月的概念，并不能是说一个人干十个月就等于十个人干一个月。
书中就提到过，人月这个概念，看似表示人员数量和时间是可以互换的，其实只有在将任务分解给参与人员后他们之间不需要互相交流的情况下，人数和时间才是可以互换的。
而在实际真实的软件项目中，只要项目具有一定规模，不论是设计、开发、测试、部署，随便哪个阶段都会有分解任务给不同人员，而且这些阶段本身也属于一种任务的分解，在不同人员间分解任务就不可避免的引发额外的沟通成本。
因为软件开发本质上是一项系统工作，在错综复杂的关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
书中还提到，有研究表明，在同样有两年经验而且受到同样培训的情况下，优秀的专业程序员的生产率是较差程序员的10倍。所以在软件项目中，一个小型的、精干的队伍是最理想的，这样既减少了沟通成本，又提高了生产率。
但是对于真正意义上的那些大型系统来说，小型精干的队伍因为项目本身体量实在太大的原因，往往意味着太慢。这就是软件项目的矛盾的所在，对于效率和概念的完整性来说，最好由少数精干的人员来设计和开发，而对于大型系统来说，则需要大量的人手，以使产品能在时间是满足市场的需求。
而解决这个问题目前来看，最好的办法还是需要一个精明能干杰出的首席程序员，就像类似于一场外科手术中的主刀医生一样。
首席程序员亲自定义功能和性能技术说明书，设计程序，编制主架构源代码，测试以及书写技术文档。首席程序员一般会配备一个副手，副手的主要作用是作为设计的思考者、讨论者和评估人员。
与传统的两人队伍每人负责一部分工作的设计和实现不同，这两个人需要一起了解所有的设计和全部的代码。其他的程序员以及管理者，文档编辑人员等围绕着主架构的设计来具体实现功能以及推进项目。
这种队伍的好处就在于既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
可能很多人都觉得自己项目的架构师就是这个首席程序员，但国内大多数项目的架构师，还是不够称职，并没有达到真正的一丝不苟地专注于体系结构，并了解整个项目的编码情况，换通俗的讲法，就是还不够深入的参与到整个项目，往往一般的所谓的架构师就是初期设计一番随便开个会之后，就任务完成了，对于项目的整体把控尤其不到位，尤其是在银行业的科技部这种情况更为严重，至少小编有好几位圈子里的朋友都来诉苦说他们行的架构简直就是最没有存在意义的部门。
所以我们回到最初的问题，软件项目开发周期与员工规模的神秘关系，是不是有点明白这关系的神秘所在了？
如果你想更深一步的研究下人月方面的知识，建议你读一下这本人月神话。
如果你在自己的编程生涯中有深刻的体验，欢迎留言大家一起探讨下！
往期推荐
Netflix 开源用于 Spring Boot的 GraphQL 服务框架DGS
如果你喜欢本文，欢迎关注我，订阅更多精彩内容
关注我回复「加群」，加入Spring技术交流群
⚔ 这些葵花宝典，无须自宫，免费领取 ⚔
喜欢的这里报道
↘↘↘
