Agile Software Development
大约 27 分钟
Agile Software Development
- 理解敏捷软件开发方法的原理，敏捷宣言，以及敏捷开发和计划驱动开发之间的区别。
- 了解重要的敏捷开发实践，如用户故事、重构、结对编程和测试优先的开发。
- 了解敏捷项目管理的 Scrum 方法
- 了解在开发大型软件系统时，扩展敏捷开发方法以及将敏捷方法与计划驱动的方法相结合的问题。
Rapid Software Development
快速开发和交付现在往往是对软件系统最重要的要求。
- 企业在快速变化的环境中运营，实际上不可能产生一套完整的稳定的软件需求
- 软件必须快速发展以反映不断变化的业务需求。
计划驱动「Plan-driven development」的开发对于某些类型的系统来说是必不可少的，但并不能满足这些业务需求。
Agile
快速软件开发在20世纪90年代末兴起，被称为敏捷开发或敏捷方法，其目的是从根本上减少工作软件系统的交付时间.
Common Characteristics
- 程序规范、设计和实施活动是交错进行的
- 最低限度的文档 - 专注于工作代码
- 系统是以一系列的版本或增量开发的，利益相关者参与版本的规范和评估
- 广泛的工具支持（如自动测试工具）被用来支持开发过程。
Plan-driven VS Agile
Plan-driven development
计划驱动的方法主要用于开发大型、长寿的软件系统，如航天和政府系统。
- 不一定要遵循瀑布模型 - 计划驱动的增量开发是可能的
- 围绕不同的发展阶段，在每个阶段都要有产出
- Iteration occurs within activities.
Agile development
- 规范、设计、实现和测试是相互交错的，开发过程的产出是通过软件开发过程中的协商决定的。
- Iteration occurs across activities.
Agile Methods
对20世纪80年代和90年代的计划驱动的软件设计方法所涉及的开销的不满，导致了敏捷方法的产生。
敏捷方法的目的是减少软件过程中的开销（例如，通过限制文档），并能够快速响应不断变化的需求，而不需要过度返工。
- 专注于代码而不是设计
- 是基于软件开发的迭代方法
Agile Principle
- 客户参与
- 渐进式交付
- 人而不是过程
- 迎接改变
- 保持简单性
Applicability
敏捷方法在两类系统开发中特别成功。
- 产品开发，即软件公司正在开发一个小型或中型的产品进行销售。（现在几乎所有的软件产品和应用程序都是采用敏捷方法开发的）
- 在一个组织内的定制系统开发，客户明确承诺参与开发过程，而且影响软件的外部规则和条例很少。
Extreme Programming (XP)
一个非常有影响力的敏捷方法，在20世纪90年代末开发，引入了一系列的敏捷开发技术。
将公认的良好做法推到 "极端 "水平
- 新的版本可能每天都会建立几次。
- 增量每 2 周交付给客户一次；
- 每次构建都必须运行所有的测试，只有当测试成功运行时，构建才会被接受。
XP Release Cycle
XP Principles & Practices
- 增量规划
- 小规模发布
- 简单的设计
- 测试先开发
- 重构「Refactoring」
- 结对编程「Pair programming」
- Collective ownership 「集体所有制」
- Continuous integration「持续集成」
- Sustainable pace
- On-site customer
支持XP实践中的敏捷原则
- 通过小规模、频繁的系统发布来支持增量开发。
- 客户的参与是通过客户在开发团队中的持续参与来支持的。
- 通过结对编程、系统代码的集体所有权以及不涉及过长工作时间的可持续发展过程，支持人而不是过程。
- 通过定期向客户发布系统，测试先行的开发，重构以避免代码退化，以及新功能的持续集成来拥抱变化。
- 通过不断的重构，提高代码质量，以及使用简单的设计，不对系统的未来变化进行不必要的预测，来支持保持简单性。
Key Practices
- User stories for specification
- Pair programming
- Refactoring
- Test-first development
Testing in XP
- 在XP系统中，没有任何系统规范可以被外部测试团队用来开发系统测试
- 用户故事是用户需求，但不是系统需求，因为它们往往遗漏了系统的重要信息
- XP开发了一种方法，程序在每次修改后都要进行测试。XP测试的特点。
- Test-first development.
- 从情景中逐步开发测试。
- 用户参与测试开发和验证。
- 使用自动化测试框架
User Stories for Requirements
- 在XP中，客户或用户是XP团队的一部分，负责对需求做出决定。
- 用户需求被表达为用户故事。
- 一个用户故事是一个系统用户可能经历的使用场景。
- 人们发现这些故事比传统的需求文件或用例更容易产生共鸣。
- 这些都写在卡片上，开发团队将其分解为实施任务。
- 客户根据他们的优先级和时间表的估计，选择列入下一个版本的故事。
- 很难判断是否有足够的用户故事被开发出来以覆盖所有的基本需求，或者一个单一的故事是否给出了一个活动的真实情况。
Test-Driven Development
- 测试被写成程序，然后才是代码
- 先写测试，可以避免 "测试滞后 "的问题。
- 编写测试隐含地定义了所开发功能的接口和行为规范。
- 每个测试都包括对其执行是否正确的检查。
- 当添加新功能时，所有以前的和新的测试都会自动运行，从而检查新功能是否引入了错误。
- 通常依赖于一个测试框架，如JUnit。
Customer Involvement
- 客户在测试过程中的作用是帮助开发要在系统的下一个版本中实现的故事的验收测试。
- 作为团队一员的客户在开发过程中写测试。因此，所有的新代码都被验证，以确保它是客户所需要的。
- 然而，采用客户角色的人可用的时间有限，所以不能全职与开发团队一起工作。他们可能觉得提供需求已经是足够的贡献了，所以可能不愿意加入测试过程。
Problems with Test-First Development
- 程序员更喜欢编程而不是测试，有时他们在编写测试时会走捷径。
- 例如，他们可能会写不完整的测试，没有检查所有可能发生的异常。
- 有些测试可能非常难写出增量。
- 很难判断一组测试的完整性。
Pair Programming
程序员们一起坐在同一台电脑前开发软件: 配对是动态创建的，以便所有团队成员在开发过程中相互协作。
Benefits
- 它支持对系统的集体所有权和责任的想法。
- 它作为一个非正式的审查过程，因为每一行代码至少要由两个人看。
- 它鼓励重构以改善软件结构。
- 它不一定是低效的。
Agile Project Management
- Plan-driven software development
- 管理人员为项目制定计划，说明应该交付什么，何时交付，以及谁将从事项目交付物的开发工作。
- 软件项目经理的主要职责是管理项目，以便在项目的计划预算内按时交付软件。
- Agile methods：要开发的东西和项目进展不太明显，因为，例如，团队是自我组织的，不产生文件，并在非常短的周期内计划开发。
敏捷项目管理需要一种不同的方法，它适应于增量开发和敏捷方法中使用的实践。
Scrum
Scrum是一种敏捷方法，侧重于管理迭代开发，而不是具体的敏捷实践。
3 Stages
- 初始阶段是一个纲要性的规划阶段，在这个阶段你要建立项目的总体目标并设计软件架构。
- 随后是一系列的冲刺周期，每个周期开发一个系统的增量。
- 项目结束阶段对项目进行总结，完成所需的文件，并对所学到的经验进行评估。
Sprint Cycle
- Sprint 的长度是固定的，通常为 2-4 周。
- 规划的起点是产品积压，也就是项目要完成的工作清单。
- 选择阶段涉及整个项目团队，他们与客户合作，从产品积压中选择要在冲刺阶段开发的特性和功能。
- 一旦这些达成共识，团队就会组织起来开发软件。
- 在这个阶段，团队与客户和组织隔离开来，所有的沟通都通过所谓的 "ScrumMaster "进行。
- ScrumMaster的作用是保护开发团队免受外部干扰。
- 在冲刺结束时，对所做的工作进行审查并提交给利益相关者。然后开始下一个冲刺周期。
Teamwork in Scrum
- ScrumMaster "是一个促进者，他安排每天的会议，跟踪积压的工作，记录决策，根据积压的工作衡量进度，并与客户和团队以外的管理层进行沟通。
- 整个团队参加简短的每日会议（即Scrums），所有团队成员在会上分享信息并描述自上次会议以来的进展、出现的问题以及第二天的计划。
- 这意味着团队中的每个人都知道正在发生的事情，如果出现问题，可以重新计划短期工作以应对它们。
Scrum Benefits
- 产品被分解成一组可管理和可理解的块状物，利益相关者可以与之联系。
- 不稳定的要求不会阻碍进展。
- 整个团队都能看到一切，因此，团队的沟通得到了改善。
- 客户看到按时交付的增量，并获得关于产品如何运作的反馈。
- 客户和开发人员之间建立了信任，并创造了一种积极的文化，每个人都期望项目能够成功。