敏捷软件开发简述

前言：因为我读了邹欣老师的《构建之法:现代软件工程(第二版)》，所以对敏捷软件开发有了比较大的兴趣。因而我在网上找了一些论文，好比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年提出的一种软件开发模型，其严格遵照计划、分析、编码、测试、维护的步骤。阶段之间经过文档流通，每一个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段流下了的文档的要求，若是不符合就逆流到上个阶段检查并修正，以此往复，直到流到最后阶段产品经过测试后进行发布及运行期间的维护。

图1  瀑布模型开发过程

　　因为各个阶段须要文档相互流通，在软件开发前期就须要对整个软件的架构进行设计。优秀的架构可使软件足以支撑整个功能体系以及便于维护，而这样优秀强大的框架一般须要在十分有经验而且有着独特眼光的架构师在彻底理解开发用户的需求以后才可能设计出，一般难度是较大。而且软件的框架一旦肯定下来就很难改变，甚至会牵一发而动全身，难以适应的客户需求。此外，在软件开发过程当中须要人员之间交流的并很少，每个阶段对代码的编写或者测试都由文档规定。因为各个阶段要自上而下相互衔接，各个阶段的沟通要经过大量臃肿、复杂的文档来传递信息。这样的软件开发一般会将每一块的功能作的相对完善，而模块之间的衔接以及充分理解文档的时间将显得很是长。

3. 敏捷的优点

    敏捷方法主要经过迭代过程来应对需求和技术的变化。在每一次迭代周期结束时，都应交付用户一个可用的，可部署的系统，使得用户能够尽早的体验系统并给予反馈。每次迭代周期应尽量短，以便能及时频繁地处理需求变化和用户反馈。

    采用敏捷开发方式将会给企业和用户带来诸多好处：

　 交付用户须要的软件。它将带给用户其真正须要的软件系统。瀑布模式一般会在产品的起点与最终结果之间划出一条直线，而后沿着直线不断往前走。然而当项目完成时，用户一般会发现终点已经不是他们真正的目的地。而敏捷方法则采用小步的方式前行，每走完一步，都须要及时调整并肯定下一步的方向，直到抵达真正的终点。

　 更高的质量。敏捷对迭代周期的产出有严格的质量要求。敏捷提倡使用测试驱动开发（test-driven development），即在正式开发功能代码以前，先开发该功能的测试代码。这为敏捷项目的整个开发周期提供了可靠的质量保证。

　 更快的将产品推向市场。敏捷提倡避免大规模的前期计划，认为那是一种很大的浪费。由于不少预先的计划的东西都会发生改变，大而全的前期计划一般是徒劳的。敏捷提倡逐步完善的计划。敏捷团队只专一于开发项目中当前最须要的、最具价值的部分。这样能尽早地投入开发，缩短产品上市的时间，或者说使得软件能够更早的交付使用。

4. 主要的敏捷方法

4.1     Scrum

　　Scrum最先由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。目前Scrum是应用最为普遍的敏捷方法之一。Scrum中的主要角色包括：

　　Scrum Master: Scrum教练和团队带头人，确保团队合理的运做Scrum，并帮助团队扫除实施中的障碍；

　　产品负责人: 肯定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资报酬率负责；

　　开发团队: 一个跨职能的小团队，人数5-9人，团队拥有交付可用软件须要的各类技能。

　　在每一次冲刺或迭代当中，开发团队建立可用的软件的一个增量。每个迭代所要实现的功能来自产品订单。产品订单按照优先级排列工做需求。在迭代计划会议中，产品负责人告诉开发团队须要完成产品订单中的哪些订单项。开发团队决定在下一次迭代中他们可以承诺完成多少订单项。在迭代的过程当中，没有人可以变动迭代订单，这意味着在一个迭代中需求是被冻结的。

图2 scrum 过程

　　Scrum中经过三个活动进行检验和适应：每日例会检验Sprint目标的进展，作出调整，从而优化第二天的工做价值；Sprint评审和计划会议检验发布目标的进展，作出调整，从而优化下一个Sprint的工做价值；Sprint回顾会议是用来回顾已经完成的Sprint，而且肯定作出什么样的改善可使接下来的Sprint更加高效、更加使人满意，而且工做更快乐。

4.2     极限编程（eXtreme Prgramming）

　　极限编程（eXtreme Prgramming），是一种软件工程方法学。如同其余敏捷方法学，极限编程和传统方法学的本质不一样在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很天然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好全部需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。极限编程规定了一些实践和简单规则，包括：编写用户故事、架构规范、实施规划、迭代计划、代码开发、单元测试、验收测试等等。

　　像全部其余敏捷方法同样，极限编程预期并积极接受变化。它具备如下的价值观或原则：

　　互动交流。团队成员不是经过文档来交流，文档不是必须的。团队成员之间经过平常沟通、简单设计、测试、系统隐喻以及代码自己来沟通产品需求和系统设计。

　　反馈。反馈是一种信息的交流，能使系统更加完善。反馈也和交流密切相关，客户的实际使用、功能测试、单元测试等都能为开发团队提供反馈信息。同时，开发团队也能够经过估计和设计用户案例的方式将信息反馈给客户。

　　简单。极限编程提倡简单的设计，简单的解决方案。极限编程老是从一个简单的系统入手，而且只建立今天可能须要的功能模块。由于它认为，建立明天须要的功能模块可能会因为需求的变化而成为浪费。

　　勇气。极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其余问题上花费了太多没必要要的精力。勇气使得开发人员在须要重构他们的代码时能感到温馨。这意味着从新审查现有系统并完善它会使得之后出现的变化需求更容易被实现。另外一个勇气的例子是了解何时应该彻底丢弃现有的代码。每一个程序员都有这样的经历：他们花了一成天的时间纠缠于本身设计和代码中的一个复杂的难题却无所得，而次日回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。

　　团队。极限编程提倡团队合做，相互尊重。极限编程以创建并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。好比，为了尊重其余团队成员的劳动成果，每一个人不得将未经过单元测试的代码集成到系统中。所以，每一个人的代码质量必须过关。

图3 极限编程示意图

4.3     精益软件开发（Lean Software Development）

　　精益思想的核心思想是查明和消除浪费。在软件开发过程当中，bugs，没用的功能，等待以及其余任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，而后设法消除。精益开发的其它原则包括:

　　强调学习。软件开发过程是一个不断学习的过程。每一个团队成员都须要从平常的失败，互动，交流以及信息反馈中学习，不断改进所开发的产品和开发效率。

　　在最后时刻作决定。这样能够避免在可能改变的事情上作无谓的努力，从而有效的避免浪费。

　　用最快的速度交付用户。较短的迭代周期可以加速产品的开发及交付，加快交流，提升生产力。

　　给团队自主权。激励团队并让全部团队成员自我管理始终是全部敏捷方法得到成功的基本因素之一。

　　诚信。确保整个系统正常工做，真正知足客户的需求是整个团队须要努力坚持的诚信和和对用户的承诺。

　　全局观。精益开发强调总体优化的系统。不管开发的组织仍是被开发的产品， 从总体上考虑优化比从各个局部去优化更高效。

图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.