敏捷指南 · 软件之外的敏捷
敏捷软件开发如何运作：实践与最佳实践
敏捷正是从软件开发起步的。团队以短迭代方式交付可工作的软件，并以工程实践为支撑，在需求变化的同时保持高质量。
要点总结
- 敏捷软件团队以短迭代方式交付可工作的软件。
- TDD、CI/CD、代码评审和重构可在变化中保持高质量。
- DevOps 将敏捷延伸到发布和运维。
开发周期
- 产品负责人对用户故事待办事项列表进行排序。
- 在 冲刺计划会，开发人员挑选故事并将其拆分为任务。
- 开发人员同时编写代码和自动化测试。
- 代码经过评审后频繁合并到共享的主分支。
- 持续集成会自动构建和测试每一项变更。
- 已完成的故事在冲刺评审会上进行演示并发布，有时一天发布多次。
参见 敏捷开发生命周期 了解更广泛的流程。
核心工程实践
| 实践 | 是什么 | 重要性 |
|---|---|---|
| 测试驱动开发（TDD） | 先编写一个失败的测试，再编写能通过测试的代码，然后进行重构 | 缺陷更少，设计更好 |
| 持续集成（CI） | 至少每天合并和测试一次代码 | 尽早发现集成问题 |
| 持续交付（CD） | 让软件始终处于可发布状态；实现部署自动化 | 快速、低风险的发布 |
| 结对编程 | 两名开发人员共同完成一项任务 | 质量与知识共享 |
| 代码评审 | 由另一位开发人员检查每项变更 | 质量与共同所有权 |
| 重构 | 在不改变行为的前提下改进代码结构 | 保持代码易于修改 |
| 基于主干的开发 | 短生命周期的分支，快速合并 | 避免痛苦的合并过程 |
敏捷与 DevOps
DevOps 将敏捷从开发延伸到运维：团队对其在生产环境中的软件负责，实现基础设施自动化，监控实际使用情况，并从故障中快速恢复。广泛使用的 DevOps 指标包括部署频率、变更前置时间、变更失败率和服务恢复时间。
最佳实践
- 让故事保持足够小，以便在几天内完成。
- 让 完成的定义 包含自动化测试。
- 持续偿还技术债务；每个冲刺预留产能。
- 实现构建、测试和部署的自动化。
- 频繁发布小的变更，并使用功能开关将部署与发布分离。
- 尽早让用户参与，并在发布后衡量实际使用情况。
- 在事件发生后进行无责审查。
本主题的免费模板
常见问题
敏捷软件开发与 DevOps 有什么区别？
敏捷侧重于团队如何以迭代方式规划和构建软件；DevOps 将这种协作和自动化延伸到软件的发布和运行中。
敏捷软件开发还需要文档吗？
需要：足以帮助用户和未来开发人员的文档即可，例如清晰的代码、自动化测试、API 文档和简短的决策记录。
什么是敏捷软件开发？
由小型跨职能团队以短迭代方式构建软件，频繁进行集成、测试和发布，并定期获取用户反馈。
敏捷软件开发中的测试驱动开发是什么？
先编写一个失败的自动化测试，再编写能通过测试的代码，然后进行重构。它能减少缺陷并带来更好的设计。
敏捷软件开发中的持续集成是什么？
至少每天合并和测试一次代码变更，并配合自动化构建和测试，以便尽早发现集成问题。
在敏捷软件开发中，持续集成与持续交付有什么区别？
持续集成频繁地合并和测试变更；持续交付通过自动化部署让软件始终处于可发布状态。
敏捷软件开发中的结对编程是什么？
两名开发人员在同一块屏幕前共同完成一项任务，以提高质量并传播知识。
敏捷软件开发中的基于主干的开发是什么？
一种做法：开发人员使用短生命周期的分支，并频繁合并到主分支，以避免痛苦的合并过程。
敏捷软件开发中的重构是什么？
在不改变代码行为的前提下改进其结构，使代码易于修改。
敏捷软件开发中的技术债务是什么？
在代码或设计中走捷径在未来带来的代价。如果不加以管理，它会拖慢团队，并可能表现为速度下降。
在敏捷软件开发中，用户故事应该多大？
要小到能在几天内完成，以便在一个冲刺内完成构建、测试和集成。参见 用户故事.