我昨天和今天各花了大概四个小时时间，草读了这本书。相信其他组员都没有看过，所以我来简介一下，也希望能和其他同学一起切磋。
首先，这本书成书于1996年，中文版发行于2001年，在写书到现在的15年时间里软件行业发生了相当大的变化。因此，我觉得书上的观点，不可不信，不可全信，希望其他同学读了比较新的书以后也可以介绍一下，综合多本书的观点会比只看一本书要全面很多。
这本书基本上是从一个管理人员的角度去写的，但是没有把视角限定在某一个固定的管理职位上，比如它也会写到管理人员怎么与上级，客户等等进行沟通。我不知道我们的同学里面有多少将来目标是软件开发公司的管理人员，但是我认为，即使你的目标不是去做项目管理，这本书也还是足够有意思的。首先，希望将来做科研的同学将来会少不了以几个人的小团队的形式写代码的经历，而你如果做到一定层次，你一定要担负起管理的位置。其次，就算你并不想做任何形式的管理，也可以看看到底一个工程想要成功需要哪些因素，作为一个开发人员（或者是被老大催着写代码的研究生），你遇到的挫折是不是其实来自于你老板的错误的管理，你作为奋斗在生产第一线的人，又应该如何向他们去解释。总之，我向同学们推荐这本书，尤其是像我这样在过去的几年里想做一些努力但是总是觉得自己实现不了目标的同学们。
这本书从一个管理人员的角度去写，从另一个方面来说，也就意味着这本书不讨论具体的做法。你可能想知道怎么把代码写得易读，怎么去做设计，怎么去做测试，等等，但是这些内容本书都不涉及。它只会说宏观上你应该怎么做。
然后这本书的写法基本上是一半讲理论，一半是案例研究。理论部分有不少反复出现之处，可能为了强调吧。一个典型的例子是有一张关于一个项目的预期开发时间的分布图，被反反复复地以各种方式使用了无数次。大部分理论是经验性的，但是也有很多真正做了实验的研究结果，这些结果就会有精确的数字存在（但是不代表这些数字在当前环境下仍然准确）。案例研究基本上都是一些虚构的故事，故事的主人公就那么一群人，同样的人名字反复出现的时候也会具有类似的特点（汗），比如Chip总是因为缺乏经验而成事不足败事有余……也有一些真实的案例，但是并不以案例研究的形式出现。
这本书虽然名为快速软件开发，但是贯穿在全书中的一个很重要的概念是“有效软件开发”。作者认为，首先要确保一个团队可以实现有效的软件开发，然后再在各个因素上作出决策：是速度第一，还是开发费用最少，还是产品（质量，feature set，等等）最好？如果在有效软件开发的基础上强调速度，那么就会作出增加开发费用和质量略微变差或者Feature变少的决定。而反过来，如果你决定开发费用尽量优化，可能就会选择用更小的团队工作更长的时间，依次类推。因此，本书在谈“快速开发”之前先花了一定的篇幅谈“有效开发”。
书的第二个部分就叫快速开发。作者谈到怎么选取一个适合工程和团队特点的生命期计划和团队结构，怎么估算（讲了整整33页！），怎么定进度计划，激励机制，团队合作，功能限定，以及怎么对待提高生产率的工具，怎么进行面向客户的开发，最后，怎么在项目进行到满身疮痍的时候进行修复，尽可能地挽回颓势。
在快速开发的各类实践中，又有三个子目标：速度，进度风险，可视化。速度顾名思义就是完成得快还是慢；进度风险大致可以理解成完成时间的方差是大还是小（或者说完成时间远超出预期的坏事发生的概率）；可视化是开发过程中对完成程度估计和展示的能力（是每天都能看到有一点进步呢，还是像一个黑箱子一样一直不知道我们做了多少事情呢，还是我们知道我们做了多少，但是没法在期中做个报告向同学介绍呢）。书的第三部分就是罗列了几十个有助于快速开发的实践，并且逐一分析它们究竟是帮助你提高速度，还是降低风险，还是提高可视化程度。
最后，抱怨一个小问题，就是我手上这个中文版翻译得实在是无比之烂，比如里面提到《人月神话》(The Mythical Man-Month)的时候被翻译成了《神奇的人月》，让我这个上课解答myth是什么意思的同学感到情何以堪！类似的搞笑错误还有“Foo栏”，原文是Foobar。。。
