《敏捷软件开发》读书分享

由于书是由英文书籍翻译，读起来会难免拗口，本次分享是由《敏捷软件开发》结合 上相关资料总结而成。

传统的瀑布式开发

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

有论文统计他是造成70%软件开发失败的原因。

大体分为这几个阶段：需求分析、设计、编码、测试、维护。

瀑布模型

什么是敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发知识体系

敏捷开发流程图

工程实践

持续集成

(TDD)测试驱动开发

重构

《敏捷软件开发》中对重构一个生动的比喻

重构就好比用餐后对厨房的清理工作。第一次你没有清理它，你用餐时会快一点。但是由于没有对盘碟和用餐环境进行清洁，第二天做准备工作的时间就要更长一点。这会再一次促使你放弃清洁工作。的确，如果跳过清洁工作，你今天总是能够很快用完餐，但是脏乱在一天天的积累。最终，你得花费大量的时间去寻找合适的烹饪器具，凿去盘碟上已经干硬的食物残余，并把它们洗擦干净以使它们适合于烹饪。饭是天天要吃的。忽略掉清洁工作并不能真正加快做饭速度。

何时重构

重构应该随时随地进行。

• 添加功能时一并重构
• 修复Bug时一并重构
• 复审代码时一并重构

总结

在具体的敏捷开发实践中，必须实事求是地采用合适的敏捷实践，以实用主义为指导思想，面向业务结果和价值，切不可为了敏捷而敏捷。

敏捷不是银弹。