前言：由于我读了邹欣老师的《构建之法:现代软件工程(第二版)》，因此对敏捷软件开发有了比较大的兴趣。于是我在 上找了一些论文，比如Requirements Engineering and Agile Software Development、A decade of agile methodologies: Towards explaining agile software development。在读了这些论文之后，对敏捷软件开发有了大致的了解。这篇博文主要是简单介绍敏捷软件开发，重点集中在主要的敏捷开发方法和它的优势，同时也作为一个备忘录，来记录我在这个过程中收获到的重要的知识。
目录
1. 敏捷开发简介
2. 传统软件开发方法的缺点
3. 敏捷的优势
4. 主要的敏捷方法
4.1 Scrum
4.2 极限编程（eXtreme Prgramming）
4.3 精益软件开发（Lean Software Development）
5. 参考文献
1. 敏捷开发简介
软件工程一直是一项复杂的任务，而纵观其历史，软件工程也发展出了许多不同的理论。从最开始的原始状态，到逐渐成型的瀑布模型，软件工程正在不断发展。在二十一世纪初，有专家又提出了敏捷开发的概念，并且这个概念在近些年来被大量实践。因此，本博客将主要介绍敏捷软件开发的优点以及具体内容。
敏捷不是某一种方法论、过程或框架，也不是字面意义上的敏捷，而是一组价值观和原则。这些价值观和原则由17位软件开发领域的领军人物在2001年通过《敏捷宣言》传递给世界，也在那个时候宣告了全球敏捷开发运动的开始。
敏捷宣言
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每组比对中，后者并非全无价值，但我们更看重前者。
敏捷12原则
1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持持续稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
符合敏捷价值观及原则的主流敏捷开发方法包括：极限编程（eXtreme Prgramming），精益软件开发（Lean Software Development），动态系统开发方法（DSDM）,Scrum等等。
2. 传统软件开发方法的缺点
传统型软件开发是基于“瀑布模型”的开发方式，以软件架构为核心，采用结构化设计以及分析方法将软件生命划分期限，并且开发进度按照从上而下的顺序相互衔接，如同瀑布一般。瀑布模型是Winston Royce在1970年提出的一种软件开发模型，其严格遵守计划、分析、编码、测试、维护的步骤。阶段之间通过文档流通，每个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段流下了的文档的要求，如果不符合就逆流到上个阶段检查并修正，以此往复，直到流到最后阶段产品通过测试后进行发布及运行期间的维护。
图2 scrum 过程
Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
4.2 极限编程（eXtreme Prgramming）
极限编程（eXtreme Prgramming），是一种软件工程方法学。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。极限编程规定了一些实践和简单规则，包括：编写用户故事、架构规范、实施规划、迭代计划、代码开发、单元测试、验收测试等等。
像所有其他敏捷方法一样，极限编程预期并积极接受变化。它具有以下的价值观或原则：
互动交流。团队成员不是通过文档来交流，文档不是必须的。团队成员之间通过日常沟通、简单设计、测试、系统隐喻以及代码本身来沟通产品需求和系统设计。
反馈。反馈是一种信息的交流，能使系统更加完善。反馈也和交流密切相关，客户的实际使用、功能测试、单元测试等都能为开发团队提供反馈信息。同时，开发团队也可以通过估计和设计用户案例的方式将信息反馈给客户。
简单。极限编程提倡简单的设计，简单的解决方案。极限编程总是从一个简单的系统入手，并且只创建今天可能需要的功能模块。因为它认为，创建明天需要的功能模块可能会由于需求的变化而成为浪费。
勇气。极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。
团队。极限编程提倡团队合作，相互尊重。极限编程以建立并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。比如，为了尊重其他团队成员的劳动成果，每个人不得将未通过单元测试的代码集成到系统中。因此，每个人的代码质量必须过关。
图4 精益软件开发原则
对于上述的每个原则，都有一些相应的实现工具。这些工具包括价值流图（Value Stream Mapping），基于集合的开发（set-based development），拉系统（pull system），排队论（queuing theory），等等。和其它敏捷方法相比，精益软件更重要的是不断完善开发过程的一种思维方式。因此，将精益模式与其他敏捷开发模式一起使用将会取得很好的效果。
5. 参考文献
[1]. 敏捷开发宣言 http://agilemanifesto.org/iso/zhchs/manifesto.html
[2]. 敏捷开发十二条原则 http://agilemanifesto.org/iso/zhchs/principles.html
[3]. 《构建之法:现代软件工程(第二版)》 邹欣
[4]. Scrum 维基百科 https://zh.wikipedia.org/wiki/Scrum
[5]. 敏捷软件开发 维基百科https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91
[6]. 极限编程 维基百科 https://zh.wikipedia.org/wiki/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B
[7]. Dings?yr, Torgeir, et al. “A decade of agile methodologies: Towards explaining agile software development.” Journal of Systems and Software85.6 (2012): 1213-1221.
[8]. Paetsch, Frauke, Armin Eberlein, and Frank Maurer. “Requirements Engineering and Agile Software Development.” WETICE. Vol. 3. 2003.
相关资源：《敏捷软件开发:原则、模式与实践》【带完整书签版】.pdf
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！