关于敏捷开发方法读后感
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发宣言
Should you go agile?
敏捷方法的一个新的问题是，从哪里开始。秉承任何新技术或工艺，你需要自己的衡量，这可以让你看到它如何适应您的环境。
敏捷开发之所以敏捷，原因就是统一团队（个人理解）。统一团队包括了开发中各种角色的人员。这些人员在同一个团队中能很好的交流，就减少了出正式文档的时间成本，误解能第一时间得到纠正。实际执行过程中发现，虽然名义上是一个团队，但不同角色人员的立场不同，有时很难保证真正的“统一”。这就需要各个组的管理者真正站在项目的角度，给执行者更大的自由度，并且平时减少矛盾，多组织团体活动增进默契。但是当矛盾不能解决的时候，这样反而会让开发变得更加的艰难。
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中，自动化编译程序每天至少一次自动从配置库上取下代码，执行自动化代码静态检查（如PCLint），单元测试，编译版本，安装，系统测试，动态检查（如Purify）。以上这些自动化任务执行完毕后，会输出报告，自动发送邮件给团队成员。如果其中存在着任何的问题，相关责任人应该及时的修改。可以看到，整个开发组频繁的更新代码，出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉，取决于自动化单元测试和系统测试能力是否足够强大，特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作，则新合入代码的隐患将很难被发现，并遗留到项目后期，形成大的风险。而实际上，提升自动化测试的覆盖率是最困难的。
总结和反思。每个迭代结束以后，项目组成员召开总结会议，总结好的实践和教训，并落实到后续的开发中。
