Jar*_*red 36 project-management
本书是在分时系统,程序编程和大约30年的软件工程经验时代编写的.随着现有图书馆,更高级别语言,IDES以及互联网上可用的文档和示例数量的改进,本书的大部分内容仍然适用吗？
虽然我可以相信在项目中添加新人可能最初会减慢速度,但我认为单元测试,关注点分离以及其他形式的自动化和设计改进等事情会让团队的新成员更快地提高工作效率.在书中,假设项目具有良好的设计文档和流程.
我没有大型项目或大型团队的经验,所以我很想知道那些与他们有经验的人的想法.编辑:我想知道像Wikis,即时消息和互联网这样的新通信工具是否会减少通信时间.基于每个人的答案,我会说通信效率的任何增加都被复杂性的增加所抵消.
daf*_*daf 57
今天仍然和它写的那天一样真实.这是因为它基本上是关于在同一个项目上工作的人之间的沟通,而过去30年的进步都没有大幅改变.
当然,我们在这30年中已经学到了很多东西,但是根据布鲁克斯的"无银弹"预测,我们的工具和承诺的所有改进都是渐进式的.
Gat*_*tor 42
难道这不像是问孙子的战争艺术是否仍然适用于战争,因为我们拥有现代化的设备？
小智 17
这本书还有一些东西需要告诉我们,而且对于一个人来说,我遇到了团队规模增加带来的沟通问题.您应该知道,单元测试,关注点分离等不是新概念.
然而,有些事情经得起时间的考验.我不相信在您的代码中编写ASCII流程图是一个好主意,并且建议的"手术团队"方法已经被几个人(MS的Charles Simony,最着名的人)尝试过,并且发现不能很好地工作.
Ada*_*icz 10
这个想法不是"大型团队不工作",而是"将问题投入人员/金钱不是答案".像单元测试,关注点分离等事情正在做其他事情,而不仅仅是让人们解决问题.这些其他的东西可以让你在适当的地方仔细添加更多的人来加快速度.如果有的话,你提出的观点支持这本书的想法.
两个着名的布鲁克斯着作,"无银子弹"和"神话人月"分别是编程语言和项目管理的基本限制的解释.
虽然有些章节比TMMM中途稍微远一点处理过当时的技术,但其余的章节今天仍然和写作时一样重要.
在TMMM中,布鲁克斯遵循"概述问题","展示一些错误的开始"和"提出我自己的解决方案"的技术.上面的一些评论家指出,他自己的解决方案在这一点上可能被认为是过时的,但他对大型项目固有问题的简明描述使这本书值得一读.
他不断回归的一个主题是通信开销是大型团队的限制因素.作为思想实验,考虑互联网作为程序员的通信媒介的影响,以及对大型开源项目的催化剂.
就个人而言,我会读这本书只是为了"工艺的欢乐"部分.我从来没读过什么,所以优雅地描述了编程在它的最好的感觉等.(如果你很好奇,那就是第7页,可以在amazon.com上看到"Look Inside!"功能)
我当然认为像"没有银弹"这样的东西今天和几十年前一样适用,特别是当我们看到越来越多的年轻人进入工业界并认为x是最新最好的杀手语言/技术和所有其他技术会因此而死.
当然,对Ada或共享计算机的引用是过时的,但是意外和基本困难的概念,购买与构建,代码如何复杂,因为我们不重复部分,所有其他理论主题仍然完全准确和相关的.
TMMM与之相关的另一个论点是,它不是关于软件本身,而是关于程序员如何完成工作.通过这种方式,它很难变得过时.
在我的脑海中突出的两个:"版本2"仍然适用,"添加更多人不一定更快".
Spolsky以自己的方式讨论"第2版".我不记得他是否特意链接到MMM,但它在概念上非常相似.
与确定MMM相比,沟通变得更有效率,但是,我认为这一切都是成比例的.与编写MMM时相比,制作软件生产需要更多的准备工作.
有人说,计算机科学中的所有东西都是在1960年被发现的,从那以后一切都是衍生的.
| 归档时间： |
|
| 查看次数： |
4384 次 |
| 最近记录： |