一、敏捷的背景与动机
1.1 软件危机及软件工程的出现
速度是企业竞争致胜的关键因素，软件项目的最大挑战在于，一方面要应付变动中的需求，一方面要在紧缩的时程内完成项目，传统的软件工程难以满足这些要求， 所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。
1.2 软件项目的复杂
解决复杂性问题需要采用经验式方式：解决问题的两种方式：1、预定义过程控制（富士康流水线生产），2、经验性过程控制（摸着石头过河）， 如果复杂度超过预定义方式的能力范围，应该采用经验性方式， 经验性方式的三大支柱：可见性、检查及适应
1.3 他山之石
互联网时代的出版模式：
作者最开始的时候并没有想出一本书，而只是把多年的积累梳理出来写成了博客，凭借博客的成功最后得到了出版商和纸版读者的认可。在写成本书的过程中，作者是渐进式的进行的，每写完一个章节，放到博客上去征求读者的反馈，很多反馈意见在后面的章节或修订中及时地体现出来，这样就形成了与读者之间的良好反馈，在出版之前就锁定了大量的读者。这就是敏捷开发提倡的“增量迭代、及时交付”的思想。 这种模式能最大程度地不偏离客户需求的本质。
精益制造：
消除浪费、关注流程、建立无间断流程以快速应变 、降低库存 、一次做对、基于顾客需求的拉动生产 、标准化与工作创新 、尊重员工，给员工授权 等
二、敏捷宣言及原则
2.1敏捷的历史
敏捷软件开发又称敏捷开发，从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。
2001年初，因观察到许多的软件团队身陷不断扩大的流程之中的困境，一群业界专家聚集在一起，勾勒出一些能让软件团队迅速工作，以及响应变化的价值观和原则。他们自称为Agile Alliance。
之后的七个月里，他们创造具有价值的声明，也就是敏捷软件的开发宣言。
十五人中包括：大名鼎鼎的Kent Beck（XP,TDD的创始人,Junit的创始人之一）、Ward Cunningham（Wiki概念的发明者）、Martin Fowler（《企业应用架构模式》作者）、Robert C. Martin、Ken Schwaber
2.2敏捷价值观之敏捷宣言
敏捷开发的核心思想是：以人为本，适应变化。
敏捷价值观之敏捷宣言-1 个体和交互胜过过程和工具：
人是软件项目获得成功最为重要的因素；合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要；方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；
敏捷价值观之敏捷宣言-2 可以工作的软件胜过面面俱到的文档：
过多的面面俱到的文档往往比过少的文档更糟；软件开发的主要和中心活动是创建可以工作的软件；直到迫切需要并且意义重大时，才进行文档编制；编制的内部文档应尽量短小并且主题突出
敏捷价值观之敏捷宣言-3 客户合作胜过合同谈判：
客户不可能做到一次性地将他们的需求完整清晰地表述在合同中；为开发团队和客户的协同工作方式提供指导的合同才是最好的合同；
敏捷价值观之敏捷宣言-4 响应变化胜过循环计划：
变化是软件开发中存在的现实；计划必须有足够的灵活性与可塑性；短期的迭代的计划比中长期计划更有效
2.3敏捷开发的12个原则
(1)我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
(2)即使到了开发的后期，也欢迎改变需求。
(3)经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好 。
(4)在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
(5)围绕被激励起来的个人来构建项目。
(6)在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
(7)工作的软件是首要的进度度量标准。
(8)敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
(9)不断地关注优秀的技能和好的设计会增强敏捷能力。
(10)简单化是根本（不做过度设计和预测）。
(11)最好的构架、需求和设计出自于自组织的团队。
(12)每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。
三、敏捷方法是什么？
3.1什么是敏捷方法？
敏捷方法是一类软件开发流程的泛称；敏捷方法是相对于传统的瀑布式软件过程提出的；敏捷方法可以用敏捷宣言（4条）、敏捷原则（12条）来概括；敏捷原则通过一系列的敏捷实践来体现出来；敏捷方法有很多种。
问题1，请举出你知道的2个以上敏捷方法名字来
敏捷的方法(Agile Mthods):
Extreme Programming (XP)极限编程
Scrum
Adaptive Software Development (ASD)自适应软件开发
Crystal Clear and Other Crystal Methodologies水晶方法
Dynamic Systems Development Method (DSDM)动态系统开发方法
等
3.2敏捷方法VS瀑布模型
敏捷方法：
完整地开发，每少数几周或是少数几个月里可以测试功能；强调在获得最简短的可执行功能的部分，能够及早给予企业价值；在整个项目的生命周期里，可以持续的改善、增加未来的功能。
瀑布模型：
固定的、没有弹性的； 很困难去达到互动； 假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的model是比较不适合的。
3.3敏捷项目管理VS传统项目管理：
敏捷项目管理:
对整个项目做一个粗略的估计,每一次迭代都有详细的计划；
鼓励变化, 客户价值驱动开发；信任和赋予权力;合约使变更变得简单，增加价值；客户和开发人员之间是紧密的连续的合作关系；每次迭代都产生可交付的软件；专注于交付软件；第一次迭代就可交付能工作的版本，风险发现的早。
传统项目管理：
事先对整个项目进行估计、计划、分析；反对变更; 变更需要重新估计、重新规划；严密的合同来减少风险, 如果改变需求要走 CR 流程；项目作为一个“黑盒子” ，对客户与供应商的可视性差；文档和计划驱动的方法；软件交付时间晚, 意识到风险的时间晚；WBS,甘特图,关键路径分析。
敏捷 与CMMI双剑合璧：
CMMI更加关注于流程，敏捷更加关注于人；CMMI自顶向下，敏捷自底向上；敏捷并不排斥必要的文档；敏捷的很多实践是对CMMI的一种实现，比如sprint计划会议就是PP的实现，每日例会就是在做PMC；很多CMMI4~5级的公司也在应用敏捷，比如说宝信、华为；项目级的敏捷实践通过CMMI可以在组织级得以重用；
3.4Extreme Programming（极限编程）：
XP我们一般称为极限编程，是最轻量级的开发流程。
最主要的精神是：『在客户有系统需求时，给予及时满意的可执行程序』，所以最适合需求快速变动的项目。
它强调客户所要的是：workable的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作。
XP的实践包括：
完整团队、计划游戏、客户测试；简单设计、结对编程、测试驱动开发； 改进设计、持续集成、集体代码所有权；编码标准、隐喻、可持续的速度
3.5Scrum开发流程
3.6为什么采用敏捷? –预期的收益
采用敏捷方法得当的话，可以：（1）更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险;（2）快速交付, 每次迭代都能交付可运行的软件;（3）最高风险和最高优先级的需求，最优先进行开发;（4）改善应对变更能力, 减少大量的重计划;（5）改善项目沟通;（6）更好的客户参与, 避免错误的假设.
总之:（1）提高了生产率; 减少“浪费” （不需要的文档，重复工作等） ，项目的每次迭代都有明确的目标;（2）提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结束产生可以运行的软件;（3）改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）
