| 编辑推荐: |
| 本文来自于csdn，介绍了什么是敏捷开发，敏捷软件开发宣言，遵循的原则，敏捷设计，敏捷开发方法框架等。 |
|
《敏捷软件开发》读书分享
由于书是由英文书籍翻译，读起来会难免拗口，本次分享是由《敏捷软件开发》结合网上相关资料总结而成。
传统的瀑布式开发
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
有论文统计他是造成70%软件开发失败的原因。
大体分为这几个阶段：需求分析、设计、编码、测试、维护。
瀑布模型
传统和敏捷开发比较 
什么是敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发知识体系 
敏捷开发知识体系整体框架 
敏捷开发流程图 
敏捷软件开发宣言
个体和交互胜过过程和工具。
可以工作的软件胜过面面俱到的文档。
客户合作胜过合同谈判。
响应变化胜过遵循计划。
理解：
以人为本，强调个体及个体间的沟通与协作在软件开发过程中的重要性。
目标导向，自解释的友好的代码和架构。
客户为先，理解客户的需求，懂得如何与客户合作。
拥抱变化，在客户断变化的需求中了解其真正的需要。
虽然右项也具有价值，但敏捷软件开发认为左项具有更大的价值。
敏捷宣言遵循的原则
敏捷软件开发遵循以下原则：
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单——使未完成的工作最大化的艺术——是根本的。
最好的构架、需求和设计是出自于自组织的团队。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷设计
拙劣设计的症状
僵化性：设计难以改变。
脆弱性：设计易于遭到破坏。
牢固性：设计难以重用。
粘滞性：难以做正确的事情。
不必要的复杂性：过分设计。
不必要的重复：复制黏贴。
晦涩性：混乱的表达。
这些症状在本质上和代码的臭味相似，但是它们所处的层次稍高一些。它们是遍及整个软件结构的臭味，而不仅仅是一小段代码。
面向对象的设计原则
1.SRP 单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。
2.OCP 开发-封闭原则
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。
3.LSP Liskov替换原则
子类型必须能够替换掉它们的及类型。
4.DIP 依赖倒置原则
抽象不应该依赖于细节。细节应该依赖于抽象。
5.ISP 接口隔离原则
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
23种设计模式：http://www.runoob.com/design-pattern/design-pattern-intro.html
我们最常用的spring框架就使用了很多种设计模式，例如BeanFactory中的工厂模式，AOP中的代理模式。
最佳的实践
设计原则和设计模式都代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。它们是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
总结
敏捷开发人员应该：
1.遵循敏捷实践去发现问题。
2.应用设计原则去诊断问题。
3.应用适当的设计模式去解决问题。
敏捷开发方法框架
1.Scrum
2.极限编程（XP）
其中，Scrum是使用最普遍的敏捷开发方法框架。
Scrum
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
理论基础
1.透明性（Transparency）
2.检验（Inspection）
3.适应（Adaptation）
主要内容
角色
产品负责人（Product Owner）
Scrum主管
开发团队
活动
冲刺计划会议（Sprint Planning Meeting）
每日站立会议（Scrum Daily Meeting）
冲刺复审会议（Sprint Review Meeting）
冲刺回顾会议（Sprint Retrospective Meeting）
主要工件
产品待办列表（Product Backlog）
冲刺待办列表（Sprint Backlog）
燃尽图（Burn Down Chart）
scrum框架图
工程实践
持续集成
(TDD)测试驱动开发
重构
《敏捷软件开发》中对重构一个生动的比喻
重构就好比用餐后对厨房的清理工作。第一次你没有清理它，你用餐时会快一点。但是由于没有对盘碟和用餐环境进行清洁，第二天做准备工作的时间就要更长一点。这会再一次促使你放弃清洁工作。的确，如果跳过清洁工作，你今天总是能够很快用完餐，但是脏乱在一天天的积累。最终，你得花费大量的时间去寻找合适的烹饪器具，凿去盘碟上已经干硬的食物残余，并把它们洗擦干净以使它们适合于烹饪。饭是天天要吃的。忽略掉清洁工作并不能真正加快做饭速度。
何时重构
重构应该随时随地进行。
添加功能时一并重构
修复Bug时一并重构
复审代码时一并重构
总结
在具体的敏捷开发实践中，必须实事求是地采用合适的敏捷实践，以实用主义为指导思想，面向业务结果和价值，切不可为了敏捷而敏捷。 |
