做化工的在哪个网站做平台好,长期做网站应该购买稳定的空间,手机应用商店下载app,推广关键词排名查询一、关于人月神话这本书记得在上大学的时候#xff0c;就经常听学长和老师讲起《人月神话》#xff0c;但是却一直没有阅读。记得当时一听到这个书名#xff0c;还以为是个神马科幻类别的书#xff0c;结果是个软件工程方面的书籍。这本书是“图灵奖得主、“IBM360系统之父… 一、关于人月神话这本书 记得在上大学的时候就经常听学长和老师讲起《人月神话》但是却一直没有阅读。记得当时一听到这个书名还以为是个神马科幻类别的书结果是个软件工程方面的书籍。这本书是“图灵奖得主、“IBM360系统之父”作者Brooks写的人们都说它颠覆了项目管理领域是一本长久不衰的传奇经典畅销了40多年。的确在我们熟悉的豆瓣读书上面它的评分达到了8.6满分10分不可不畏是一本好书。最近快速地阅读完后按照我的老规矩也需要总结总结写一篇笔记来日后回顾之用。二、什么是“人月神话” “人月”这个词英文原文是“Man Month”代表一个人一个月的时间内能够完成的工作量在软件开发项目管理中常用来估算任务量比如“这个项目需要多少个人月”。很多时候我们或多或少都有过这样的经历很多的项目管理人员总是希望通过增加更多的人手来加快软件工程的完成进度。比如一个工作量为10个人月的项目如果只有一个人做需要10个月才能完成。于是我们的项目管理人员认为只要再加入9个人那么10个人一起做就只需要一个月啦。然而实际情况并非如此因此软件工程的各项工作之间往往存在着一个前后继承的关系完成了这一项下一项才能开始。那么加进来的人手呢他并不能立即开始工作。所以想要通过增加人手来缩短工程时间其实只是一个“神话”而已。这里就不得不提经常被拿来举例的一个例子一个孕妇生一个小孩需要10个月那么请10个孕妇来就只需要1个月啦显然是不可能完成的任务。 而“人月神话”反映出的就是软件开发在项目管理中所遇到的难题管理人员因为盲目乐观对项目开发过程中的困难没有充分的认识在计算项目的工作量和交付时间上采用了错误的计算方法忽略了细节对整体的巨大影响而这很可能会导致项目延期。三、如何处理“人月神话”的难题首先作者建议以小团队的方式开展工作。 这里不得不说作者在当时提出了一个类似于外科手术团队的组织结构来开展工作。外科手术团队的奥秘就在于它是以主刀医生为核心其他像负责助理医生、麻醉师、护士等人都是为主刀医生服务的大家各司其职、齐心协力从而保证手术顺利完成。那么反映到软件工程上面就是以架构师或者高级程序员充当主刀医生的角色而团队管理者充当副手或者服务人员其他团队成员则分别负责单元代码编写功能单元测试文档管理工具开发及技术支持等等。即使整个项目团队的人数庞大但只要根据工作边界将大家划分到一个个类似于外科手术队伍那样的小团队当中去就可以保障在一定程度上的效率提升。其次要进行行之有效的沟通。 定期召开项目进度例会对数据结构进行监督和全员反馈等等都是常见的增进沟通的手段。而近年来流行的敏捷开发模式例如Scrum这种敏捷开发流派就特别倡导小团队的高频率的沟通每个迭代大概2周一个迭代都会完整经历计划会议、每日站立会议、项目评审会议、团队回顾会议等特别是每日站立会议虽然一般只有短短15分钟但是确是增进沟通的主要行之有效的方式。 此外作者还在特别强调了两个点使用产品文档“手把手带”的沟通方式最后要“防微杜渐” 关于“防微杜渐”作者具体给出了几点建议在项目推进的过程中设立一些关键节点作者称之为“里程碑事件” 我所在的团队每天的站立会议都会设立“今日目标”也就是一些里程碑在每天下班时后看看这些里程碑事件完成了多少如果完成100%那么久擦掉如果没有就说明情况和问题留到下一个工作日继续完成。为项目设立一个专门的规划和控制小组项目管理必须认清一个现实“唯一不变的就是变化” 我所在的团队经历过多次需求大改的情况迫使我们每次修改都要面向未来考虑变化点和可扩展性为了避免项目延迟和失败要尽可能地提前集成测试 只有尽快集成测试才能暴露前后端在对于backlog的理解上存在的问题有没有完成AC验收条件四、“人月神话”为何无法彻底解决 “人月神话”中的一些问题其根源在于软件工程本身的特性是无法彻底解决的这也是广大IT从业人士的共识。其原因归根结底有以下几点计算机技术的发展实在是太快了 想想摩尔定律到现在前后端的框架变化我们时常感叹前一阵子学的东西现在又被淘汰了是否要开始学习AI了软件研发本身的内在的特性也制约了软件工程的进展 作者用了4个词来概括这种特性复杂性、一致性、可变性和不可见性。五、改善软件开发根本难题的建议 虽然作者说到上面提到的这些困境是软件开发的根本困难无法彻底解决。但是它还是给出了三方面的建议来尽可能改善这种困难造成的困境采用新技术 使用高级语言总比低级语言方便吧使用.NET Core总比.NET Framework程序性能和跨平台好吧“快速开发原型”然后再做“增量开发” 其实跟我们的敏捷开发思想一致通过在不断地迭代反复中堆成一个完整的系统在精益创业中也有一个MVP最小可用产品的概念它提倡快速原型试错快速获取市场反馈然后再慢慢完成最后的完整的产品。聘用卓越人才 这一点毋庸置疑有了新的技术和敏捷开发还需要合格的、追求卓越的程序员人才这让我想起了ThoughtWorks这家公司它是一个尊重技术提倡敏捷并且积极追求卓业人才的代表性企业Martin Fowler是其首席科学家无数的咨询师走上了技术布道之路敏捷开发DDD微服务等实践总结和分享雨后春笋般地出来向ThoughtWorks致敬。整体脑图参考资料弗雷德里克·布鲁克斯《人月神话》王福强《喜马讲书人月神话》
