《快速软件开发》读书心得

这本书在豆瓣上的评分很高，评价也很好，经过各种纠结，最终决定读这本书，虽然这本书最厚。

这本书基本上是从一个管理人员的角度去写的，但是没有把视角限定在某一个固定的管理职位上，也就意味着这本书不讨论具体的做法。

我主要发现了下面几个问题：

1. 风险管理

做什么事都有风险，做任何决策也都有风险，软件开发也不例外。软件工程是一个很复杂的过程，其中的“风险”很难量化评估和控制。即使很难量化和控制也要尽可能准确的评估，并且有效的控制，否则一个一个软件项目几乎不可能成功。常见的风险识别方法是进度计划风险，在风险分析的过程中要顾及损失的大小，评估损失发生的概率。而且不同的风险有不同的优先级，通过监控来避免并且化解风险。风险管理这个名词我第一次接触，我们组的team project也没有涉及风险管理，所以不太熟悉。

2. 激励机制

激励机制实在是太重要了！在team project中我是PM，如何激励大家开心高效的写代码让我费了不少脑筋。书中提到了最重要的5个激励因素：成就感，发展机遇，工作乐趣，个人生活，成为技术主管的机会。感觉这五个激励因素离我们都还很远，太专业了，我们还是学生，似乎在一起多吃吃饭更有效果。。。在饭桌上大家都混得非常熟，很多问题都在饭桌上解决了，反正大家都是要吃饭的，还不如组里的同学一起吃。另一点就是鼓励大家分享，因为我们组各位同学的任务都差不多，几乎是平行的，所以一个人遇到的问题，其他人也会遇到。当一个人解决了一个技术难题之后，我们鼓励他把方法分享出来，这在某种程度上也激发了大家的开发热情。

3. 面向客户的开发

这一点我感触比较深。书中提到了客户对于快速开发的重要性，它可以提高效率，减少返工，降低风险，消除矛盾。在具体实践中，我们也深深体会到了客户的重要性，因为无论如何，你的软件最终是要给客户用的。我们脑子中所设想的用户通常和真正的用户有很大区别。很多我们希望实现的feature对于用户而言根本就没有用。比如说，我们最开始准备支持创建活动，后来发现如果一个用户想要创建一个活动，他根本不会在手机上这么做，这么复杂的动作他必然会在电脑上完成。况且实现这个feature需要花不少时间，基本不会有人用，最终我们决定不做这个feature了。

4. 团队结构

团队结构这个问题又是涉及到人的问题，又是一个很复杂的问题。书中提到了很多很有意思的团队模型，比如“戏剧团队”，“搜索救援团队”，“专业运动员团队”，“主程序员团队”等等。专业的团队结构必然要分工明确，沟通畅通无阻。说实话，我们team的团队结构有很多问题，比如我们没有学设计的同学，做出来的东西很难看，我们没有设专门的测试人员，每个人都开发，每个人也都测试，我们的PM也要写代码(PM比较喜欢写代码)，这些问题在专业团队中都是要尽量避免的。

5. 为什么叫做“快速软件开发”

书中第一章专门介绍了什么叫“快速”，并且给出了很多建议。然而单单快速就可以了吗？显然不是，书中的第二部分介绍的就是有效开发，可见快速不是以牺牲质量为前提的。在startup界有一个非常有名的说法，是“Iterate Fast and Release Often”，觉得很是赞同。需求在变，用户在变，市场在变，如果不能做到快速，很快就会被淘汰。

陶宇

转载于:https://www.cnblogs.com/meng-meng/archive/2011/10/10/2205253.html