敏捷软件开发 源码-敏捷开发 瀑布式开发

本文第一部分阐述了敏捷软件开发的业务目标——“持续的快速交付和强大的灵活性”。 这一目标的实现需要多层面的支持。 如图（1）所示，商业成功是最终目标，需要有效的开发模式作为保证； 开发模式的实施离不开团队组织和技术实践的支持； 最后，通过持续改进和系统优化，持久成功。 在这种层次关系中，外层是内层的对象，内层为外层提供支持。

图（1）由外而内看敏捷

本系列文章将按照图中标注的五个部分，由外而内地讲解敏捷软件开发的各个方面。 这就是文章标题（从外到内的敏捷）的由来。 本文讨论敏捷软件开发模型。 和上一篇一样，我们还是会递增地提交观察报告。

一、从问题域到解决域⇒围绕问题域的开发过程

软件开发的任务是“提供解决用户问题的方案”。 软件开发的过程就是通过有组织的活动，实现从“问题域”到“解决方案域”的转换过程。 开发团队是从问题域为核心开始开发过程，还是以解决方案域为核心？ 在这一点上，传统的软件开发方法和敏捷软件开发方法是不同的，其效果也有很大的不同。

图（2）问题域到解决方案域的映射过程——传统模型

图（2）反映了传统软件开发模型下问题域到解决方案域的映射过程。 其典型特征是：“在解决方案域分解系统，围绕解决方案域展开开发过程”。 首先，业务分析师获取并分析用户需求，完成初步规格说明； 然后，架构设计人员根据规范将任务分解为解决方案域中的软件代码模块，分配给不同的开发人员； 然后分别实现各个模块的编码和测试； 最终完成系统的集成验证，实现最终的解决方案。

这种模式无法满足敏捷软件开发快速迭代交付价值、灵活应对变化、与客户紧密合作的需求：

无法交付价值的快速迭代交付

将系统分解为解决方案域中各个模块的工作，所有模块完成后才能进行系统集成和验证，不能按部就班地完成产品功能并迭代交付。

缺乏应对变化的灵活性

在解决方案域内分解工作后，所有需求的开发同时开始。 在整个开发过程中，功能始终处于半成品状态，例如设计待实现、代码待集成、集成待验证。 同时，任何需求的变更、增减都意味着对这些半成品的返工，缺乏应对变化的灵活性。

开发者和用户之间的心理联系被打破

在这种模式下，用户和业务人员工作在问题领域，从问题领域出发，思考问题，描述问题，交流问题； 业务人员常用的词汇和交流环境无法与用户建立心理联系。 在体验为王的今天，这恰恰是决定产品竞争力的必备要素。 而且，每个开发者只接触和负责解决方案的一部分，而不是用户原来的问题。 这样就会造成闭门造车和局部优化，失去问题的创新机会。

图（3）问题域到解决方案域的映射过程——敏捷模式

与侧重于解决方案域的传统软件开发不同，敏捷开发侧重于问题域。 图（3）反映了敏捷软件开发模型下问题域到解决方案域的映射过程。 其典型特征是：“在问题域内分解系统，围绕问题域展开开发过程”。 如图所示，用户、业务人员和开发团队充分沟通，在问题域内将需求拆分成端到端的子项； 同时，整个开发团队围绕一小部分用户需求紧密合作，完成设计开发和集成验证工作，生成能够运行并满足部分需求的完整系统，并根据用户和业务人员的反馈获取反馈。在上面。 系统逐渐增长，直到交付完整的解决方案。 该模型有效解决了上述问题敏捷软件开发 源码，即价值的迭代交付、对变化的灵活响应以及开发者与用户之间心理联系的建立。

提交了第一份《从开发模式看敏捷》的观察报告

从开发模式看敏捷

- 敏捷软件开发模式下，开发过程围绕问题域展开，系统在问题域内分解，便于价值迭代交付，灵活应对变化，建立开发团队与用户之间的心理联系

……

二、软件开发的过程是一个知识创造的过程⇒延迟决策是更好的决策

图（4）项目决策时间模型——传统模型

软件开发是一个知识创造的过程。 随着开发过程的推进，团队逐渐积累业务需求、市场环境、技术方案、实施技术等方面的知识。 如图（4）所示，团队拥有最多知识的时刻是在项目结束时，也是可以做出最正确决策的时刻。 然而，相应地，在传统的软件开发模式中，大部分决策都是在项目的早期阶段做出的，例如：设定产品需求、提交项目计划、确定架构解决方案。 此时的决策只能基于非常有限的团队知识，其质量肯定是有问题的，但一定会成为后期项目执行的基础和约束。 过早的决策也为后续的需求、技术、计划的变更引入了不必要的成本，这显然是不合理的。

图（5）项目决策时间模型——敏捷模式

敏捷软件开发提倡“延迟决策”。 如图（5）所示，在项目开发过程中，市场和技术环境发生了变化； 客户对他们的需求有更清晰的了解； 会员对业务和技术的掌握更加全面和深入。 团队各方面的知识都在不断增长。 相应地，项目决策也是一步步做出的。 团队在项目启动阶段做出一些基本决策，并且在每次迭代中做出更多决策。 为了更好地延迟决策，提高决策的有效性和质量，敏捷开发团队需要：

正确的决定是在正确的时间做出的

决定不能无限期地拖延。 问题是，什么时候做决定最好？ 答案是“最后的责任时刻”。 如果此时不做决定，一个重要的决定选项就会丢失，或者因为时间到了，系统会选择默认方案（比如不做任何动作，或者继续使用已有的方案）。 方式等），这通常不是最好的决定。

对于不同类型的决策，“最后责任时刻”也不同。 例如，每次迭代要完成的内容和相关计划在迭代开始时最终确定，具体实施计划在实施时确定。 项目的总体目标，实施语言和框架的决定，很可能需要在第一次迭代之前做出。

刻意发现，最大限度地积累决策所需的知识

故意发现（Deliberate Discovery）是由丹·诺斯提出的。 他指出，在项目启动时，团队缺乏业务领域、构建技术、遗留代码、工具等方面的知识，处于对项目最懵懂的状态，其中还包括对无知的无知。 无知是制约项目开发进度和质量的最大因素。 反应性的、基于知识的决策是不够的。 在开发过程中，团队要通过有计划的活动，有意识地探索和发现，尽快消除影响项目进度的无知。 这个过程被称为深思熟虑的发现过程，它加速了软件开发的知识创造过程，同时为项目决策提供知识和技能支持。

在敏捷软件开发中，风险驱动规划、技术探索需求（spike story）、早期反馈、探索性测试、演化设计等都是深思熟虑的发现过程，有力地支持了项目执行、技术和业务的成功。

延迟决策的技术支持

采用适当的技术实践可以更好地支持延迟决策。 例如，采用低耦合的架构模式有利于延迟架构和设计的决策； 更容易修改和验证的代码降低了延迟需求决策的成本； 接口和实现的分离，让底层细节的决策尽可能延迟； 持续的重构增加了延迟决定系统实现的可能性。 这方面将在技术实践部分进行更详细的讨论。

《从开发模型看敏捷》观察报告第二次提交

从开发模式看敏捷

- 敏捷软件开发模式下，开发过程围绕问题域展开，系统在问题域内分解，便于价值迭代交付，灵活应对变化，建立开发团队与用户之间的心理联系

- 敏捷软件开发在开发过程中积累业务、产品和技术知识，延迟决策敏捷软件开发 源码，通过深思熟虑的知识发现过程，提高决策的有效性和团队的价值交付能力

……

三、敏捷迭代开发模式⇒关注三个核心概念

迭代开发模型是指将整个开发过程分成多个连续的迭代，每次迭代都是一个包括需求、设计、实现和测试的完整过程，并生产出可以验证概念或交付的软件。 迭代开发模型的出现比敏捷软件开发方法的出现要早得多。 敏捷迭代开发模型有哪些特点？

图（6）敏捷迭代开发模型

图（6）总结了敏捷迭代开发模型（至少涵盖XP和Scrum方法）——在每个时间盒内，完成一部分端到端的产品功能，并生成一个潜在可交付产品增量的演化开发过程。 时间盒、潜在可交付产品增量和演化开发过程是敏捷迭代开发模型的三个核心概念。

时间盒

大多数敏捷开发方法使用固定长度的迭代周期，也称为时间盒，指的是，1）固定的迭代开始和结束时间； 2）当迭代结束时间到达时，不管什么情况都是Iteration； 3）每次迭代的时间相等。 Scrum 的典型时间盒长度为 2 至 4 周，而 XP 为 1 至 2 周。 它的含义是：

形成发展节奏（节奏）

时间、内容和资源是软件开发的三要素。 在敏捷项目中，资源相对固定。 通过定长时间盒，时间元素也是固定的。 这样，每次迭代中唯一要操作的元素就是内容。 也就是说，在每个时间框内，计划并完成适量的内容。 时间盒形成了一种开发节奏，在操作上简化了计划和跟踪的复杂性，同时提高了项目的可预测性。

战胜“帕金森定律”

帕金森定律的意思是，“无论有多少时间可用，工作都会扩展，直到用尽所有时间。” 在产品开发阶段定义里程碑的项目中，您几乎总能看到帕金森定律在起作用。 这也被称为学生综合症——“你必须等到考试前一刻才能完成作业复习”。

较短的固定长度时间盒将迫使团队在一段时间内专注于一组有限的功能。 与几个月的里程碑相比，一到几周的交付目标显然更容易引起关注和紧迫感。 一方面，这降低了项目进度风险的可能性； 另一方面也降低了进度风险发生时的影响。 在项目结束时，至少可以交付完成迭代的内容，与错过最终发布周期相比，80%的交付是按期完成的。 内容（通常是最重要的 80%），显然更成功。