关于人月神话引起的思考
引言
人月神话，一本很经典的软件工程著作，经典到它已经畅销了40多年还如此经久不衰。虽然我还是一个开发工程师，但是这不妨碍我阅读如此优秀的书籍*
随便找了张书的图片，至于书中的具体内容，可以去阅读原著。我这边只是结合我身边的具体情况来论证人月神话这本书到底是真的是神作还是到底是由人们吹嘘捧上去的
人月顾名思义就是人和月人和月，项目的完成时间取决于人和月，打个比方说吧，一个项目如果一个人来完成需要12个月，那么需要交付的客户肯定等不了这么长的时间，那么往这个项目加点人吧，加三个人，一共是4个人那么这个项目的完成时间就是3个月了？答案是否定的，如果一个人要完成12个月，那么我加11个人1个月就完成这根本不可能。
书中对于这个问题，很清楚的说明了如下的观点
用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话”并提出*s法则：“想进度落后的项目中增加人手，只会使进度更加落后。(Adding manpower to a late software project makes it later )”
如果说开发软件好比造房子的话，那么开发好比房屋工程的泥瓦工，对于多数企业而言，人员的变动是不可避免的，大公司小公司多多少少会有人员的变更交替，那么假设一个工程6人团队的，预计3个月完成一个项目，中间有出现一次人员变更，人事很快找到了接替的人，那么这个项目能否按时完成？答案也是否定的
软件开发可不像砌水泥那么简单，很多不是技术出身的管理层觉得，既然出现了人事上的变更，那么我再找一个不就可以填补上这个漏洞了，往往因素是在人身上，这里引出一个观念 “沟通成本”
我们在进行工作量估算时，往往省略了团队规模扩大之后的一个重要事件成本——沟通成本。而沟通成本由两个部分组成：培训和相互的交流。每个成员需要进行技术、项目目标、总体策略以及工作计划的培训。这种培训是不能分解的，因此这部分增加的工作量随人员的数量呈线性变化。
上述提到的培训成本是线性的，还是可以接受的。而相互之间的交流成本更麻烦一些。一个大型、复杂的软件项目往往都是相互关联的，为了保证一个目标在团队之间达成一致，最坏情况下是每个部分必须分别于其他部分单独协作，则工作量按照n(n-1)递增。这是一个很可怕的增长。
如果说一个项目进度落后了，对于大多数的团队都是一样请求加派人手，要么就是抽调人员要么就是招新人，抽调公司人员老成员还好，对于整个项目进度都不会落后太多，而对于很多团队而言加派的都是新人。我曾记得我那个时候我负责我们当地医院的某个项目，那个时候新招了个人，领导让我负责带带他，但是我手里任务又很多，没啥时间去负责培训新人，给的活都是不涉及到具体复杂的业务，非常简单的活，那个时候就想影分身了。沟通是花时间成本的一件事，要让一个刚入职的人迅速接手这个项目只有2种可能（1.业务领域的专家 2.技术领域的专家）2种别无他选，技术上很强的，沟通也不会成问题，但是沟通必定会打断我们当前的工作，1天8个小时的工作时间，很难说8个小时都完完全全的投入到某项任务的开发中去，很多时候都要被打断中进行我们手头上的工作。1:1的沟通还好，那么人越多，沟通的成本也就越大，所以眼看项目还有1个月的时间就要验收了，突然领导跑过来说我给你加派几个人手，能按时验收吧？所以大多数项目经理而言，潜意识的都会回答到可以按时完成，但是事实上的结果是8成概率要延误。
那么一定要按时完成？只有这种可能，放弃质量，随之发布的版本会存在很多问题
布鲁克斯定律说“为一个延误的IT项目增加人员，将导致更多的延误”，意思是任何软件的开发都有所谓的“关键路径”，因此任何一个软件的开发都需要一定的最少时间，靠增加人力投入不可能缩短这个最低时间。
那么怎么样正确的合理加快进度？
1.增加原团队成员比增加新人带来的风险要小很多
2.减小目标，调整需求范围，规划更多可迭代的软件版本，分期提供功能
这个就是传说中的“砍需求”，但是同样也是效果最好的，这样客户还可以及时反馈软件使用情况出现的问题
因为大部分公司采用的基本都是传统的瀑布式开发模型，而其实是瀑布式的开发模型都没有好好的达到，首先瀑布式开发模型，人数一定要达到，因为人数的巨多，沟通的复杂，所以才会有文档型驱动着瀑布式模型一层一层往下走下去，但是缺点也很明显，时间过于长，对于客户而言客户并不知道交付到客户手中的产品是啥样的，中间瀑布式模型管理的不妥当，出现*s法则那也是在所难免的。人越多管理项目的开发复杂度也就越高，任务分配的也不一定均衡妥当。比如说你刚拉入一个新人，但是你不知道对方的水平，给了他一个很复杂的任务，过了几天你要验收的时候，发现并没有很好的完成，这个时候再安排别人去做项目就已经落后了，软件项目经理如果团队中没有技术经理，那么项目经理也必须要技术上有所掌控，再来使用新技术，对项目的不可控因素也大大增加了。
国外就推行敏捷开发模式，以沟通为核心，与客户沟通，与团队成员沟通，降低瀑布式模型的复杂的一些交流流程，定期发布一个版本，做好版本的迭代，利用devops的运维方式，在人少的团队中，效果绝对是优于瀑布式开发的。
今天就先写到这里，over