标签：求和 strong 难题 复杂 相互 集中 意义 display 生产力
前言：由于我读了邹欣老师的《构建之法:现代软件工程(第二版)》，因此对敏捷软件开发有了比较大的兴趣。于是我在网上找了一些论文，比如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. 参考文献
软件工程一直是一项复杂的任务，而纵观其历史，软件工程也发展出了许多不同的理论。从最开始的原始状态，到逐渐成型的瀑布模型，软件工程正在不断发展。在二十一世纪初，有专家又提出了敏捷开发的概念，并且这个概念在近些年来被大量实践。因此，本博客将主要介绍敏捷软件开发的优点以及具体内容。
敏捷不是某一种方法论、过程或框架，也不是字面意义上的敏捷，而是一组价值观和原则。这些价值观和原则由17位软件开发领域的领军人物在2001年通过《敏捷宣言》传递给世界，也在那个时候宣告了全球敏捷开发运动的开始。
敏捷宣言
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每组比对中，后者并非全无价值，但我们更看重前者。
敏捷12原则
1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持持续稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
符合敏捷价值观及原则的主流敏捷开发方法包括：极限编程（eXtreme Prgramming），精益软件开发（Lean Software Development），动态系统开发方法（DSDM）,Scrum等等。
传统型软件开发是基于“瀑布模型”的开发方式，以软件架构为核心，采用结构化设计以及分析方法将软件生命划分期限，并且开发进度按照从上而下的顺序相互衔接，如同瀑布一般。瀑布模型是Winston Royce在1970年提出的一种软件开发模型，其严格遵守计划、分析、编码、测试、维护的步骤。阶段之间通过文档流通，每个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段流下了的文档的要求，如果不符合就逆流到上个阶段检查并修正，以此往复，直到流到最后阶段产品通过测试后进行发布及运行期间的维护。
图1 瀑布模型开发过程
由于各个阶段需要文档相互流通，在软件开发前期就需要对整个软件的架构进行设计。优秀的架构可以使软件足以支撑整个功能体系以及便于维护，而这样优秀强大的框架通常需要在十分有经验并且有着独特眼光的架构师在完全理解开发用户的需求之后才可能设计出，通常难度是较大。并且软件的框架一旦确定下来就很难改变，甚至会牵一发而动全身，难以适应的客户需求。此外，在软件开发过程中需要人员之间交流的并不多，每一个阶段对代码的编写或者测试都由文档规定。由于各个阶段要自上而下相互衔接，各个阶段的沟通要通过大量臃肿、复杂的文档来传递信息。这样的软件开发通常会将每一块的功能做的相对完善，而模块之间的衔接以及充分理解文档的时间将显得非常长。
敏捷方法主要通过迭代过程来应对需求和技术的变化。在每一次迭代周期结束时，都应交付用户一个可用的，可部署的系统，使得用户可以尽早的体验系统并给予反馈。每次迭代周期应尽可能短，以便能及时频繁地处理需求变化和用户反馈。
采用敏捷开发方式将会给企业和用户带来诸多好处：
交付用户需要的软件。它将带给用户其真正需要的软件系统。瀑布模式通常会在产品的起点与最终结果之间划出一条直线，然后沿着直线不断往前走。然而当项目完成时，用户通常会发现终点已经不是他们真正的目的地。而敏捷方法则采用小步的方式前行，每走完一步，都需要及时调整并确定下一步的方向，直到抵达真正的终点。
更高的质量。敏捷对迭代周期的产出有严格的质量要求。敏捷提倡使用测试驱动开发（test-driven development），即在正式开发功能代码之前，先开发该功能的测试代码。这为敏捷项目的整个开发周期提供了可靠的质量保证。
更快的将产品推向市场。敏捷提倡避免大规模的前期计划，认为那是一种很大的浪费。因为很多预先的计划的东西都会发生改变，大而全的前期计划通常是徒劳的。敏捷提倡逐步完善的计划。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能尽早地投入开发，缩短产品上市的时间，或者说使得软件可以更早的交付使用。
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更加高效、更加令人满意，并且工作更快乐。
极限编程（eXtreme Prgramming），是一种软件工程方法学。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。极限编程规定了一些实践和简单规则，包括：编写用户故事、架构规范、实施规划、迭代计划、代码开发、单元测试、验收测试等等。
像所有其他敏捷方法一样，极限编程预期并积极接受变化。它具有以下的价值观或原则：
互动交流。团队成员不是通过文档来交流，文档不是必须的。团队成员之间通过日常沟通、简单设计、测试、系统隐喻以及代码本身来沟通产品需求和系统设计。
反馈。反馈是一种信息的交流，能使系统更加完善。反馈也和交流密切相关，客户的实际使用、功能测试、单元测试等都能为开发团队提供反馈信息。同时，开发团队也可以通过估计和设计用户案例的方式将信息反馈给客户。
简单。极限编程提倡简单的设计，简单的解决方案。极限编程总是从一个简单的系统入手，并且只创建今天可能需要的功能模块。因为它认为，创建明天需要的功能模块可能会由于需求的变化而成为浪费。
勇气。极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。
团队。极限编程提倡团队合作，相互尊重。极限编程以建立并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。比如，为了尊重其他团队成员的劳动成果，每个人不得将未通过单元测试的代码集成到系统中。因此，每个人的代码质量必须过关。
图3 极限编程示意图
精益思想的核心思想是查明和消除浪费。在软件开发过程中，bugs，没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法消除。精益开发的其它原则包括:
强调学习。软件开发过程是一个不断学习的过程。每个团队成员都需要从日常的失败，互动，交流以及信息反馈中学习，不断改进所开发的产品和开发效率。
在最后时刻做决定。这样可以避免在可能改变的事情上做无谓的努力，从而有效的避免浪费。
用最快的速度交付用户。较短的迭代周期能够加速产品的开发及交付，加快交流，提高生产力。
给团队自主权。激励团队并让所有团队成员自我管理始终是所有敏捷方法获得成功的基本因素之一。
诚信。确保整个系统正常工作，真正满足客户的需求是整个团队需要努力坚持的诚信和和对用户的承诺。
全局观。精益开发强调整体优化的系统。无论开发的组织还是被开发的产品， 从整体上考虑优化比从各个局部去优化更高效。
图4 精益软件开发原则
对于上述的每个原则，都有一些相应的实现工具。这些工具包括价值流图（Value Stream Mapping），基于集合的开发（set-based development），拉系统（pull system），排队论（queuing theory），等等。和其它敏捷方法相比，精益软件更重要的是不断完善开发过程的一种思维方式。因此，将精益模式与其他敏捷开发模式一起使用将会取得很好的效果。
[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.
标签：求和 strong 难题 复杂 相互 集中 意义 display 生产力
原文地址：http://www.cnblogs.com/wirehack/p/5988617.html
