一、简述 敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。 二、敏捷开发宣言价值观： •人和（人与人的）交互 优先于过程和工具。 •可以工作的软件 优先于求全责备的文档。 •客户协作 优先于合同谈判。 •随时应对变化 优先于循规蹈矩。 三、敏捷开发原则： •对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。 •我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。 •经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 •业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。 •围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。 •在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。 •可以工作的软件是进度的主要度量标准。 •敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。 •对卓越技术与良好设计的不断追求将有助于提高敏捷性。 •简单——尽可能减少工作量的艺术至关重要。 •最好的架构、需求和设计都源自自我组织的团队。 •每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。 四、对比其他方法： 对比迭代方法：相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。 对比瀑布式开发：两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。 有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如极限编程。 五、敏捷方法的适用性： 在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有： •组织文化必须支持谈判 •人员彼此信任 •人少但是精干 •开发人员所作决定得到认可 •环境设施满足成员间快速沟通之需要 六、用于敏捷开发团队的项目管理工具： 已经有一些项目管理工具用于敏捷开发，可以用它们来帮助规划，跟踪，分析和整合工作。 这些工具在敏捷开发中扮演的重要的角色，也是知识管理的一种方法。 通常包括：版本控制整合，进度跟踪，工作分配，集成发布和迭代规划，论坛和软件缺陷的报告和跟踪。 七、方法列表： 目前列入敏捷方法的有： •软件开发之韵，Software Development Rhythms •敏捷数据库技术，AD/Agile Database Techniques •敏捷建模，AM/Agile Modeling •自适应软件开发，ASD/Adaptive Software Development •水晶方法，Crystal •特性驱动开发，FDD/Feature Driven Development •动态系统开发方法，DSDM/Dynamic Systems Development Method •精益软件开发，Lean Software Development •AUP（Agile Unified Process） •Scrum •XBreed •极限编程，XP Extreme Programming •探索性测试 •ATDD 八、深入理解敏捷理念： 统一认识：敏捷=理念+优秀实践+具体应用 敏捷包括3个层次 ： 理念（敏捷核心思想）； 优秀实践（敏捷的经验积累）；具体应用（能够结合自身灵活应用才是真正敏捷）。 团队在透彻理解敏捷理念的基础上，可以灵活选择最适合自己的实践，避免教条化。 深入理解“聚焦客户价值” 标识和消除软件开发中的浪费 交付刚刚好的系统 随时构建质量，不容忍缺陷 及时消除技术债务，持续保持快速响应 深入理解“激发团队” 认清团队的基本事实 敏捷方式下管理者的转变 敏捷方式下团队成员的转变 九、敏捷软件开发核心——迭代开发 迭代开发将整个软件生命周期分成多个小的迭代（一般2-4周），每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。 迭代式开发的好处： 通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险 通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要 通过小批量减少排队，提供更灵活、快速的交付能力 平滑人力资源的使用，避免出现瓶颈 敏捷团队包括3个核心角色: PO(Product Owner)、Scrum Master(Scrum教练)和Team(开发产品) 十、敏捷团队实践：完整团队 敏捷开发中，以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。 完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员、资料人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。 完整团队的关键要点： 成员来自多功能领域：团队拥有完成目标所需的各职能成员； 坐在一起办公：团队成员无障碍地沟通； 团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键。 敏捷管理实践：迭代计划会议 每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog； 多团队迭代计划会议要分层召开版本迭代计划会议：将产品Backlog（需求）分配给团队； 团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog（任务） ，分配给团队成员； 迭代计划会议内容： 澄清需求、对“完成标准”达成一致 工作量估计、根据团队能力确定本轮迭代交付内容； 细化、分配迭代任务和初始工作计划。 敏捷管理实践：每日站立会议 每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加 聚焦在下面的三个主题： 我昨天为本项目做了什么？ 我计划今天为本项目做什么？ 我需要什么帮助以更高效的工作？ 每日站立会议的好处： 增加团队凝聚力，产生积极的工作氛围 及时暴露风险和问题； 促进团队内成员的沟通和协调。 每日站立会议的关键要点 准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯； 高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）； 问题跟踪：Scrum Master应该记录下所有的问题并跟踪解决。