|
本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者，也适用于团队领导人，项目经理，产品经理，开发经理，测试人员，质量保证经理，质量保证工程师，技术作者，用户体验设计者，以及任何与制做发布软件相关的人员。本文着重于技术团队怎么很好的合作去计划，开发并发布软件。本文不着重于编码，技术细节或微软工具。希望本文能改善你的专业生活和团队效率。
背景下图是Winston Royce的瀑布式开发模型：
 （ "Managing the Development of Large Software Systems"，1970 IEE paper）
无论项目有多大有多复杂，有两个关键的步骤常用于所有的计算机程序开发：1) 分析 2) 编码。 接下来，Winston Royce介绍了最重要的五步： 第一步：程序设计分配任务处理流程，功能，数据库处理，明确数据库流程，分配执行时间，明确操作系统间的接口与处理流程模块，描述输入与输出流程，并且明确初步的操作流程。撰写容易理解的，信息量大的，当前时新的概要文档。
第二步：撰写设计文档管理软件开发的第一条规则就是无条件服从的执行文档需求。
第三步：重复两次第二个非常重要的成功标准以产品是否完全原始为重中之重。如果把还有疑问的计算机程序开发为第一版，考虑到严格的设计/操作领域，那么给客户正式部署的版本实际上是第二版本。
第四步：计划，控制，监控测试在成本和计划方面上，这是最有风险的一步。当备选方案几乎或一点不可用时，它会出现在日程安排的最近时间点上。
第五步：让客户参与让客户参与到项目中是非常重要的，因为客户可能在最终发布之前较早的认可项目工作。
仔细阅读Royce的文章后发现：
不幸地是，上面列出的步骤当中，设计迭代从来没被限制成连续的步骤。
 下面这些东西都是什么？
 答案是：
 敏捷开发并不意味着只是一种方法。上面雨伞下的术语代表着不同的敏捷开发方法。
敏捷软件开发宣言我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
也就是说，上面右侧（蓝色字体）内容有其价值，但我们更重视左侧（红色字体）产生的价值。 敏捷宣言的十二条原则我们遵循以下原则：
很多开发者都经过这样的噩梦：没有任何实践可以辅佐的项目。由于缺乏有效的实践，项目变得不可预测，重复出现错误，还有白白浪费的辛苦。计划延期，超出预算，质量低下使客户感到失望。开发者也由于更长时间的工作而换来更糟糕的软件而心灰意冷。
DSDMDSDM（Dynamic Software Development Method），动态软件开发方法，通过提供一个负责整体开发周期的框架来弥补RAD(Rapid Application Development)快速程序开发的不足。下面是DSDM的主要功能：
FDDFDD（Feature Driven Development），功能驱动开发，是一种包装方法学。它允许你在非常高的级别上应用一个方法来管理项目，但它也允许你在较低的级别上应用其它方法学。FDD的着重点是能够把估算，日程计划，项目状态汇报作为一个整体或放到颗粒级别上，但是FDD不会规定一个非常细节化的方法让你应用去创建日程计划，相反FDD让你去觉决定该用什么方法。FDD的观点是你可以查看一下你的项目，陈术一下项目的确切状态，如项目进度是否及时，延时或过早等等。
LeanLean思想是一种进行系统优化的途径，它关注于减少浪费，提高整个系统总体流程。Lean在制造业上有着丰富的历史，近几年在在软件开发行业也越来越流行。Lean来源于制造业中的Lean(Lean Manufacturing: http://www./pages/article/newSTR_44.htm)，它是一组为满足质量，速度和客户需求而定制的原则。
七大Lean软件开发原则：
软件产品的交付工作应用这些原则并不是我们的最终目的。我们并不是说让我们用Lean吧，而是把Lean原则做为决策的向导或参考去选择可以改善整体系统的技术。比如，TDD测试驱动开发，通过在每一个功能点上创建功能自我测试从而构建软件的完整性和完善性。
Plan（译外话：指瀑布式开发Waterfall Development）在计划驱动开发中，如果一个项目确切的按照计划执行，那么它就是成功的。因此，在软件开发中计划驱动开发依赖于需求的稳定性，明确性和固定性。你或许知道这些奢侈的性质是在大多数软件项目中不存在的。
计划驱动方法学，在初期的设计阶段的需求变更中成本花费较低，但是一旦到了开发阶段需求变更将会花费昂贵的代价。所以，很多的工作被要求在初期计划设计阶段完成。然而，软件开发不同于普通的项目，我们不能保证将来的开发阶段会完全按照初期的设计进行，无论你的设计有多么出色。
"Walking on water and developing software from a specification are easy if both are frozen."- Edward V. Berard
在水上行走和开发软件都只有当它们被冻结时才会变得容易。
敏捷开发打破了对需求稳定性的依赖，它有一个专门的流程用于负责需求变化，主要体现在它的自适应计划和进化式设计。
自适应计划，意思是多次的仔细检查整体项目流程，经常会再次制定计划并再次适应。
进化式设计，有一些实践对它很有帮助，如自我测试代码，持续集成，重构，简易设计等。
敏捷开发是价值驱动，传统的瀑布式开发是计划驱动。这并不是说计划驱动就没有价值，在特定的实际情况下它们都有各自的有优缺点。关键是怎么平衡使用两种方法，在特定情况下采取它们的长处而回避它们的短处。
Plan VS Agile计划驱动开发模式和敏捷驱动开发模式在基本原理差异上有两大不同。
第一大不同：计划驱动模型中只能在项目完成时才能部署一个新模块，而且是较大的模块。敏捷驱动模型中可以频繁的部署新模块，甚至较小的模块。
第二大不同：计划驱动是序列化的，敏捷驱动是并发的。在计划驱动模型中，一个流程的开始必须在前一个流程完全成功结束的前提下进行。在敏捷驱动模型中，任何时候都可能在做计划，流程是并发的或互相穿插的。
“Plan your work, then work your Plan” by Martin Fowler and Neal Ford
先计划你的工作，后工作你的计划。
   敏捷开发和计划驱动开发(瀑布式开发)：
适应变化能力(Y轴) 时间(X轴)
 可见性(Y轴) 时间(X轴)
  在敏捷开发中：
客户满意度是以迅速，持续的交付可用软件为导向。
强调人和互动要高于强调流程和工具。 客户，开发者，还有测试人员一直保持互动。
可用软件频繁的被交付使用（按周交付高于按月交付） 面对面交流是最好的沟通形式。
业务人员和开发者保持近距离的，日常的协作。 持续关注出色的技术和设计。 适应易变情况。 需求中较晚的改动也受欢迎。 善于使用计划驱动模型的管理团队同样也能够善于使用敏捷开发方法。 缺乏能力使用计划驱动模型的管理团队也没有能力使用敏捷开发方法。 敏捷开发Agile敏捷软件开发的原理和价值用于帮助团队打破流程循环膨胀，着重于用简单的技术去实现目标。目标？什么是目标？ 每一个软件开发者，开发团队的主要目标是为老板和客户制造尽可能高的价值。 敏捷开发的核心是把传统的软件开发方法(瀑布式开发)的五个步骤压缩成一个一周的开发周期。用敏捷开发方法去开发一个系统时，项目中会不断贯穿着重复的周期开发和较小模块的开发，并在开发过程中允许开发者测试和检查。高速度，低成本，灵活性是敏捷开发的主要优势。
 敏捷开发发展极为迅速，从2001年的只有1%的开发者使用敏捷开发到现在的60-80%的开发者在使用敏捷开发。更大的吸引力是因为敏捷开发提供：
敏捷开发使用者从来不会害怕变化。他们把需求变化看作是好事，因为这些变化意味着团队又收获了更多关于怎样满足客户的经验。敏捷开发团队成员一起协作项目的方方面面。每一个成员都允许为项目整体提出意见或做贡献。没有一个团队成员是单一的负责架构或者需求或者测试。团队分享这些责任，同时每个成员都会对它们产生影响。 我们有很多的敏捷开发流程：Scrum，crystal，BDD(Behavior-Driven Development行为驱动开发)，TDD(Test-Driven Development测试驱动开发)，FDD(Feature-Driven Development功能驱动开发)，ADP(Adaptive Software Development自适应软件开发)，XP(Extreme Programming极限编程)，等等等等。然而，大量成功的敏捷开发团队从所有这些方法中吸取经验与知识，进而调整生成他们自己特有的敏捷开发方式。这些改编后的方法通常与SCRUM还有XP组合在一起，SCRUM实践用来管理使用极限编程XP的团队。 极限编程XPAs developers we need to remember that XP is not the only game in town.- Pete McBreen
作为开发者，我们需要记住极限编程并不是城里唯一的游戏。 极限编程强调团队合作(经理，客户，开发者)。它从五个关键点改善软件项目：沟通，简明，反馈，尊重，还有勇气 维基百科对极限编程的定义：极限编程XP是一种软件开发方法，它的意图是提搞软件质量及对用户需求变化的响应能力。作为一种敏捷软件开发方法，它提倡在短开发周期中频繁地发布，从而提高软件生产力并提出新客户需求能够被采纳的检查点。 极限编程是一系列嵌入到敏捷开发中的简易并坚实的实践。极限编程是一个非常好的通用软件开发方法。许多项目团队都采用它，同时更多的团队通过添加或修改实践来把它变得更适用。
“迫使它们走向极端”是什么意思呢？是不是如下图一样？
或者下图
不，这不是极限编程。让我们看看它的真正意思：
极限编程是一系列遵循敏捷开发原则和价值的实践。极限编程是离散的方法，而敏捷开发是一类方法。有很多的敏捷开发方法，极限编程只是其中一种。
极限编程在敏捷开发方法中是范围宽阔，出类拔萃的。Scrum有些类似极限编程，拥有极限编程的大多数特征。但是在细节是它们有很多的不同，公平的说Scrum是是极限编程的子集。甚至，许多Scrum团队争论着要把极限编程实践加入Scrum流程中，如满意度测试，结对编程，持续集成，以及测试驱动开发。
在所有敏捷开发方法当中，极限编程是唯一的一种方法为开发者的日常工作提供深度的，意义深远的开发准则。在这些准则中，测试驱动开发是最革命性的。下图中都是一些出色的极限编程实践。 ScrumScrum是和种迭代式及递增式的敏捷软件开发框架，它用于管理软件项目，产品，或程序的开发。它的着重点是一个灵活的，全面的产品开发策略，它把一个开发团队通常作为一个单位进而实现一个常规目的。相反，它不着重于传递的序列化式的方法。Scrum会问传统瀑布式开发“为什么我们要花费这么长时间，这么多努力去做一件事？为什么我们不能衡量出做一件事所需时间和人力？” Scrum拥抱变化和创造力，因为这是人们的工作方式。Scrum有一个流程学习结构，能够让团队评估他们做了什么以及他们怎样做的。
Scrum角色三个核心角色：
产品持有人 Product Owner
开发团队 Development Team
|
|
|
来自： 昵称10504424 > 《工作》
