学习思路：是什么？为什么？怎么办？
一、敏捷开发是什么？
1、敏捷宣言
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
2、原则：
1） 尽早的、持续的交付有价值的软件以满足客户，是我们优先要做的首要任务。
2)拥抱需求变更，甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。
3)经常交付可以工作的软件，从几周到几个月，交付时间越短越好。
4)在整个项目开发期间，业务人员和开发人员必须每天在一起工作。
5)围绕斗志高昂的人来构建项目。为他们提供所需的环境与支持，并且信任他们能够完成工作。
6)在团队内部最高效的传递信息的方式是面对面的交谈。
7)可以工作的软件是进度主要的度量标准。
8)敏捷过程倡导可持续发展。出资人，开发者和用户应该尽可能保持稳定的开发速度。
9) 保持关注先进的技术与设计有助于提高敏捷性。
10)简单---尽量减少工作量的艺术是至关重要的。
11) 最好的架构、需求、设计来源于自我组织的团队。
12）每隔一段时间，总结反思如何让团队变得更高效，并相应地调整自己的行为。
3、从市场角度思考：满足变化的市场需求以获利
1）用户价值：
人：当市场发生变化时，根据市场反馈的信息和个人经验快速灵活的调整产品，使产品重新满足市场需求，占领市场先机。
产品：产品在满足当前需求情况下，最小化时间和金钱成本，最大化商业价值；同时当需求变化时，产品能够以较低时间和金钱成本满足新需求以获取商业价值。
2）团队价值
人：为满足变化的需求，需要发挥人的创造力，要创造就要给予人更大的自由度。鼓励团队成员不断的学习和尝试新技术和新思想，不要思维固化。为了避免混乱，敏捷开发前提是 成员自我管理能力较高、团队达成共识、成员专业能力较强。
产品：软件必须能够适应变化的需求，必须在最低时间和金钱成本下，对功能进行增删改查。
3）直接沟通和信息反馈
减少因沟通不畅，导致获取不到必要的信息，导致最终产品与真实需求偏离过大。
问题：开发前期一大堆文档，最终产品无法满足客户重要需要且多出很多几乎不用的功能。解决：通过经常的面对面的直接交谈获取用户真实的需求，弱化中间介质文档。客户也是逐渐认识自身需求的。
问题：开发中后期，市场变化了，用户需要对功能简单进行增删改，找到软件开发公司，却发现修改及其困难！解决：软件开发整个周期，甚至投入使用后，必须考虑可拓展性和灵活性。
二、为什么提倡敏捷开发？---开发中遇到问题：
1、僵化性：很难对程序进行改动，因为每个改动都会迫使许多对系统其它部分作出改动；
2、脆弱性：对程序的改动往往会导致一些无关的地方出现问题；
3、顽固性：很难解开程序的纠结，使之一些功能成为其它程序能够公用的组件；
4、粘滞性：即做正确的事情比做错误的事情要困难很多，程序对环境和某些不可预料的事情太过于依赖；
5、不必要的复杂性：设计中包含不具任何直接好处的基础架构，换句话来说就是有设计过度的嫌疑，考虑的变化太多，导致系统过于复杂，影响当前功能的实现；
6、不必要的重复：代码中有重复的结构，而该重复的结构本来可以使用抽象和接口进行统一。
7、晦涩性：代码很难阅读，理解，没有很好的表现出意图；
三、敏捷开发具体怎么做？--案例分析
1、结合自身情况：结合你公司的现状，如组织结构、管理方式、规模、文化等；
1）团队在透彻理解敏捷理念的基础上，灵活的选择或创造最适合自己的实践，避免教条化！当察觉自己陷入教条化时，要问自己敏捷开发是什么？为什么采用敏捷开发？怎么做？
注释：教条化，也叫教条主义、本本主义，是一种僵化的态度。要么一切从已有理论出发，要么一切以主观出发，而不从实际出发，不客观思考，反对具体情况具体分析，否认实践是检验真理的标准。
2、Scrum--侧重于项目管理
（1）三大角色：
产品负责人（Product Owner） 个人感觉就是：产品经理。
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
敏捷教练（Scrum Master） 个人感觉就是：项目经理。
主要负责整个项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
敏捷团队（Scrum Team） 个人感觉就是：开发团队。
主要负责软件产品在Scrum流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达待办事项或迭代清单（Sprint Backlog）的目标。
（2）Scrum--迭代开发流程：
1）产品负责人确定产品列表（Product Backlog），按优先顺序排列；
2）敏捷团队根据产品列表，做工作量的预估和安排；
3）团队召开迭代计划会议（Sprint Planning Meeting） 从产品清单中挑选一个用户故事（Story）作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个用户故事进行细化，形成一个待办事项列表；
4）每个成员根据待办事项清单再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5）每日站立会议，控制在15分钟左右，每个人都发言，内容：昨天做了什么，今天要做什么，是否需要帮助？会后大家在任务看板上更新自己的任务纸条。
6）每日集成，每天下班前单元测试代码通过，签入代码并且编译通过；工具：TFS或SVN。
7）当一个用户故事完成，也就是待办事项列表被完成，也就表示一次迭代完成，这时进行演示会议（Srpint Review Meeting），也称为评审会议，产品负责人和客户都参加，团队成员向他们演示自己完成的软件产品；
8）最后就是 总结会议（Sprint Retrospective Meeting），以轮流发言，交流自己的收获和不足，放入下一轮迭代的产品需求中。
注释：
任务看板（白板、黑板）包含：未完成、正在做、已完成的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
2、极限编程（XP-）-侧重编程实践：
1）价值观
沟通：修改他人代码是要及时口头沟通，避免混乱和返工，文档、报表、计划来不及；
简单：够用就好，不要冗余设计；
反馈：经常与客户互动、单元测试、持续集成（签入编译成功）、
勇气：重构、
谦逊：互相尊重、编码规范
1）实际操作
（1）完整团队：业务人员或领域专家和开发人员尽可能在一个房间；
（2）用户故事：从产品列表中提取来的一组重要需求，细化为可自行的待办事项列表；
（3）短交付周期：前提条件是新版本有足够商业价值。
（4）结对编程：一个编码一个检查，然后轮换；
（5）测试驱动开发：先单元测试在编码；
（6）重构：先编写代码在进行重构。
（7）代码集体所有：共同所有共同负责。
（8）持续集成：提前暴露集成问题。
（9）隐喻：打比方，用客户听的懂的语言和客户交流。
（10）计划游戏：软件的范围、下一次迭代的发布时间、用户故事的优先级应该由业务人员决定；而每个用户故事所需的开发时间、不同技术的成本、如何组建团队、每个用户故事的风险，以及具体的开发顺序应该有开发团队决定。
（11）简单设计：反思“我们可以预测变化”和“需求不会发生改变”的错误，然后做出合适的设计。
（12）编码规范：在编码中逐渐形成统一规范。
（13）拒绝加班，丰富业余生活。
五、对敏捷的常见误解：
1、敏捷开发意味着不需要文档、设计和计划；
2、敏捷只适用于小项目开发；
3、敏捷只会对研发产生改变；
4、管理者不需要亲自了解敏捷，只需要管理上支持就可以了；
5、引入敏捷只需要按照既定的步骤去做就可以了；
6、敏捷只是管理者的噱头，跟编码人员无关；
7、敏捷只注重特性的快速交付，在敏捷下架构不重要了。
极端错误：敏捷开发能解决一切实际问题，好像它是完美无缺的；反之，发现敏捷开发也有解决不了的问题时就全盘否定它的优点。
六、设计原则
1、SRP：单一职责原则
思想：高内聚，低耦合；
应用：一个类应该仅有一个引起它变化的因素。
2、OCP：开发封闭原则
对扩展是开发的：出现新需求，模块能够进行功能扩展。
对于更改是封闭的：对模块扩展时，无需对原有程序代码或dal文件重新编译。
方法：接口封装、抽象机制、多态思想。
3、LSP：里氏替换原则
子类可以替换父类并出现在父类能够出现的任何地方。
4、DIP：依赖倒置原则
高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。
5、ISP：接口隔离原则
模块间要通过抽象接口隔离开，而不是通过具体的类强耦合起来。
思考：
1遵循敏捷设计去发现问题；
2应用设计原则去诊断问题；
3应用设计模式去解决问题；
注意：应用敏捷设计、设计原则、设计模式都是为了解决实际问题，切勿盲目套用，否则会导致设计难以理解的复杂性和代码的冗余。
参考资料 1敏捷软件开发解读--华为2009年
http://wenku.baidu.com/link?url=Chsf6BgfKY0BCmOLUAq5qn6znhHe4-3HCNAEw4UYua3O_B6x817wqb3hBu3erBMopdGOqb6lyWnxDMgCmAPhEZlv2LTwnDr7DcHQ4glyWEa
2敏捷开发之XP --博客园博客
http://blog.csdn.net/fw0124/article/details/48713959
3、敏捷开发之Scrum扫盲篇 ---CSDN博客
http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html
4、敏捷软件开发：原则、模式与实践（C#版）/Martin.R.C著 ，邓辉、孙鸣译