posts - 296,comments - 1,views - 2981

焦油坑

第一章作者将软件系统开发比作吞噬了恐龙、剑齿虎等史前巨兽的焦油坑,许多大大小小的团队被软件开发的焦油坑所吞噬。

作者首先介绍了变成系统产品的演进,指出程序、编程系统、编程产品、编程系统产品几个概念间的区别,其中只有编程系统产品才是真正可用的面向用户的产物。

然后作者分别介绍了编程的乐趣和苦恼,当然这部分见仁见智,人类的悲欢毕竟并不相通。

人月神话

第二章作者主要介绍了软件开发项目在进度安排上经常出现的问题。也就是书名人月神话的出处。首先,由于我们对项目开发的进度估计过于乐观,我们估计出来的工作量通常会低于实际需要的工作量,尤其是对测试所需时间的安排常常是进度估算失误的重灾区,这应该是很多有经验的开发者会在估时的时候乘以一个固定的系数的原因(1.5 或者 2 甚至 3)。其次人员和时间的关系并非总是反比的关系,如果任务属于可以完全分解的理想状态话,是可能达到人员越多时间越少的反比效果的,但是,任务越复杂也就越难以分解,那任务中的沟通需求就会占用更多的时间,甚至可能导致人员越多,项目所需的时间越长。进而可以得出结论:当进度落后的时候,无脑增加开发人手可能并不能加快开发进度,甚至有可能导致进度更加缓慢。向进度落后的项目中增加人手,只会使进度更加落后,这也被成为 Brooks 法则。

外科手术队伍

基于上一章的结论:更大的队伍不一定能带来更快的开发进度,那么,问题来了,什么样的队伍才是合适的呢,小团队固然高效,但是你不能指望一个 20 人的小团队在合理的时间内去开发一套完整的操作系统吧?作者在这一章里给出了解决方案:将大项目合理地划分成更小的系统,各个外科手术队伍分别开发这些更小的系统。当然外科手术队伍只是一个小团队的方案,具体细节我认为已经不再具有很大的参考价值,但是精干的小型队伍这一理念仍然很有价值。

这里我联想到大企业病的问题,企业规模的扩大必然会导致人浮于事、效率低下的问题,于是如今一些大企业都会将企业的业务分割给各个小团队来负责,一个很著名的例子就是亚马逊的两个披萨的原则,有效地避免了大团队的导致的低效问题。

posted on   leapss  阅读(6)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 25岁的心里话
· 闲置电脑爆改个人服务器(超详细) #公网映射 #Vmware虚拟网络编辑器
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· 零经验选手,Compose 一天开发一款小游戏!
· 一起来玩mcp_server_sqlite,让AI帮你做增删改查!!
历史上的今天:
2023-05-10 每日打卡-20.2
2023-05-10 每日打卡-20.1
2023-05-10 每日打卡-19
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

点击右上角即可分享
微信分享提示