敏捷开发常见问题解答：第一部分

目录

• 引言
• 敏捷是什么意思？
• 你能解释一下敏捷建模吗？
• 敏捷建模的核心原则和补充原则是什么？
• 敏捷文档背后的主要原则是什么？
• 实施敏捷有哪些不同的方法？
• XP 是什么？
• XP 中的用户故事是什么，它们与需求有什么不同？
• 谁来编写用户故事？
• 什么时候说一个故事是有效的？
• XP 中何时编写测试计划？
• 你能解释一下 XP 开发生命周期吗？
• 你能解释一下极限编程中的规划游戏是如何运作的吗？
• 我们如何在敏捷中进行估算？
• 故事可以基于什么进行优先级排序？
• 你能指出敏捷和传统 SDLC 之间的简单区别吗？

引言

本文是敏捷的快速常见问题解答。通过阅读本文，您将了解敏捷的基础知识以及实施敏捷的不同方式。

本文的第 2 部分可以在这里查看.

敏捷是什么意思？

敏捷的字典意思是“快速移动”。那么这如何应用于软件呢？敏捷开发方法将软件视为最重要的实体，并接受用户需求变更。敏捷倡导我们应该接受变更并以小版本发布。敏捷将变更视为常态，并鼓励最终用户提供持续反馈。

下图展示了敏捷在原则上与传统方法的不同之处。

• 拥有高端工具和流程不是必需的，但良好的团队互动可以解决许多问题。
• 可工作的软件比文档更重要。
• 管理层不应只关注客户合同，而应与客户互动并分析需求。
• 在传统方法中，我们承诺坚持我们的计划，但敏捷说“如果客户想要改变，请分析并相应地改变你的计划”。

以下是敏捷方法的原则

• 欢迎变更并适应不断变化的需求。
• 可工作的软件是衡量进度的主要指标。
• 客户满意度是最重要的，可以通过快速、持续交付有用的软件来实现。
• 业务人员和开发团队之间每天的会议是必须的。
• 业务和开发人员必须协同工作。面对面沟通是最重要的。
• 定期交付和更新软件。在敏捷中，我们不是一次性交付软件，而是频繁交付，并首先交付重要功能。
• 围绕积极、信任的团队来构建项目。
• 设计和执行应保持简单。
• 在设计和执行方面力求技术卓越。
• 允许团队自我组织。

你能解释一下敏捷建模吗？

敏捷建模是软件开发建模方面的一种方法。它是软件系统建模和文档编制的实践。简而言之

它是以轻量级方式进行软件建模的最佳实践集合。

抽象地讲，我们可以说它增强了其他软件流程。例如，假设您的公司正在使用 UML，然后敏捷将方法实践应用于 UML。例如，“保持简单”是一种敏捷方法。所以这意味着我们不需要在项目中用到所有的图表，只使用那些需要的。如果我们总结一下，可以说敏捷建模的原则是“只做必要的，不多做”。

敏捷建模的核心原则和补充原则是什么？

敏捷建模定义了一套实践，可以指导我们成为成功的敏捷建模者。这些实践分为两部分：“核心原则”和“补充原则”。下图以图示形式展示了这一点

让我们逐一了解这些原则的含义。

核心原则

• 简单性：不要创建复杂的模型，保持简单。当您可以用笔和纸向团队解释时，不要通过使用 Rational Rose 等建模工具使其复杂化。不要为了炫耀而增加复杂性。如果开发人员只理解流程图，那么就用流程图向他解释；如果他理解伪代码，那么就使用伪代码，依此类推。因此，根据您的团队的理解能力来准备文档。
• 欢迎变化：需求会随着时间增长。用户可以随着项目的推进而更改需求。在传统的开发周期中，您总是会听到“冻结需求”的说法，而敏捷的出现改变了这一点。在敏捷中，我们欢迎变化，这反映在项目中。
• 增量式改变：一开始没有任何东西是完全正确的。您可以将您的开发分为“最需要的”、“所需的功能”和“奢侈功能”。在第一阶段，尝试交付“最需要的”，然后增量式交付其他功能。
• 模型因目的而存在：模型应该因目的而存在，而不是为了存在而存在。我们应该知道模型是为谁制作的目标受众。例如，如果您正在制作技术文档，它是供开发人员使用的，PowerPoint 演示文稿是供高层管理人员使用的，依此类推。如果模型没有目标受众，那么它就不应该存在。简而言之，“只交付足够的，不多余的”。
• 轻量化：您创建的任何文档或工件都应随着时间的推移而更新。因此，如果您制作了10个文档，您应该注意，随着源代码的更改，您还需要更新这些文档。因此，尽可能使其轻量化。例如，如果您的技术文档是由 UML 中的图表组成的，那么随着时间的推移更新所有图表就变得很重要，这又是一件痛苦的事情。因此，保持轻量化，制作简单的技术文档，并在项目有逻辑终点时更新它，而不是定期更新。
• 保留多个模型：项目问题因项目而异，同一项目的行为也因组织而异。所以不要认为一个模型可以解决所有问题，保持灵活性并考虑多个模型。根据情况应用模型。例如，如果您正在使用 UML 进行技术文档，那么 UML 中的每个图表都可以以不同的方式反映相同的方面。例如，类图显示项目的静态视图，而流程图显示动态视图。因此，通过使用不同的图表并查看哪个最适合您的项目或场景，保持灵活性。
• 软件是最重要的：软件项目的主要目标是生产高质量的软件，最终用户可以有效地利用它。许多项目最终都会产生大量文档和管理工件。文档是为了软件，而不是软件为了文档。因此，任何不为项目增加价值的文档或活动都应受到质疑和验证。
• 获得快速和定期的反馈：软件最终是为用户制作的。因此，尝试定期从最终用户那里获得反馈。不要孤立工作，让最终用户参与进来。与最终客户密切合作，获得反馈，分析需求，并努力满足他们的需求。

补充原则

• 内容比呈现更重要：外观不重要，内容或内容要传达的信息才重要。例如，您可以使用复杂的 UML 图、简单的流程图或简单的文本来表示项目架构。绘制复杂的 UML 图可能看起来很花哨，但如果最终开发人员不理解 UML，那么它就毫无用处。一个简单的文本解释就可以满足向开发人员/程序员传达架构的需求。
• 诚实开放的沟通：接受建议，诚实，并对新模型保持开放心态。如果您的项目落后于计划，请与高层管理人员坦诚相待。项目中的开放自由环境能保持资源积极性，并使项目健康发展。

敏捷文档背后的主要原则是什么？

敏捷的主要交付成果是可工作的软件，而不是文档。文档是获得可工作的软件的支持。在传统的交付周期中，设计和需求阶段会生成大量文档。但我们确信，大部分文档都是为了创建而创建的。以下是一些使文档敏捷的关键点

• 在创建任何文档之前，请问我们是否需要它，如果需要，谁是利益相关者。文档只有在需要时才应该存在，而不是为了存在而存在。
• 最重要的是，我们需要创建文档以提供足够的数据，不多也不少。它应该简单，并能向利益相关者传达需要传达的信息。例如，下图“敏捷文档”显示了一个简单类图的两种视图。在第一个视图中，我们显示了 `Customer` 和 `Address` 类的所有属性。现在看看第二个视图，我们只显示了这些类的更广泛的视图以及它们之间的关系。第二个视图就足够了，不多余。如果开发人员想了解详细信息，我们可以在开发过程中进行。
• 只为现在而不是未来编写文档。简而言之，我们现在需要什么文档，就应该生产什么，而不是我们未来需要什么。文档在每个周期中都会改变其形式。例如，在需求阶段是需求文档，在设计阶段是技术文档，依此类推。所以只考虑您现在想要创建的文档，而不是为未来考虑。

实施敏捷有哪些不同的方法？

敏捷是一种软件开发的思维方法，它承诺解决传统瀑布方法存在的问题。为了在项目中实际实施敏捷，我们有各种方法。下图“敏捷方法”详细展示了这一点。

注意：我们将在接下来的部分详细介绍每种方法。

XP 是什么？

极限编程（也称为 XP）是一种敏捷软件开发方法。XP 专注于软件编码。XP 有四个核心价值观和十四条原则。

XP 具有这四个核心价值观

• 沟通：团队应该定期沟通、分享信息、讨论解决方案等等。经常沟通的团队能够更有效地解决问题。例如，当一个问题以隐秘的方式解决时，向整个团队发送一封电子邮件。这确保了知识与每个人共享，并且在您不在的情况下，其他开发人员可以解决类似的问题。
• 简单性：保持简单。从流程、技术或文档的角度来看。过于复杂的流程或技术架构只会带来问题。
• 反馈：最终用户的定期反馈有助于我们使项目保持正轨。因此，应启用最终用户和测试团队的定期反馈。
• 勇气：带来改变或尝试新事物需要勇气。当您试图在组织中带来改变时，您会面临巨大的阻力。特别是当您的公司遵循传统方法时，应用 XP 将始终受到抵制。

从以上四个核心价值观中，可以推导出14条原则。价值观提供了更广阔的视角，而14条原则则深入探讨了如何实施XP。

• 快速反馈：开发人员应该从最终用户那里获得快速反馈。这避免了在交付前最后一刻的混乱。在瀑布模型中，反馈收到得非常晚。这在 XP 中得到了最小化。
• 保持简单：鼓励项目设计和流程的简单性。例如，与其使用复杂的工具，不如在白板上绘制简单的手绘流程图来解决问题。
• 进行增量变更：无论何时更新补丁和更新，都以小块形式发布。如果您一次性更新大量补丁，如果存在缺陷，将很难跟踪它们。
• 拥抱变化：不要对客户说我们已经签署了需求，所以我们不能改变架构。客户或用户终究是人，所以他们会随着项目的进展而改变……如果改变是合乎逻辑的，就接受它。
• 轻量化：保持文档和流程尽可能简单。不要用不必要的文档过度劳累开发人员。开发人员的主要工作是编码并确保代码没有缺陷，所以他应该专注于代码而不是文档。
• 交付质量：您交付的任何代码都应该没有缺陷。致力于您的工作并交付无缺陷的代码。
• 从小做起，逐步壮大：很多时候，最终客户都想从大爆炸理论开始。他从一个大团队开始，希望第一次发布就能拥有所有功能等等。从小团队和“必须具备”的功能开始交付。随着我们增加功能和工作量的增加，逐步增加您的团队实力。
• 全力以赴：采取一切必要措施使项目成功。任何类型的截止日期和承诺都应以真正的精神履行。
• 鼓励诚实沟通：促进诚实沟通。如果沟通是面对面的，那么需求泄露就会减少。鼓励最终用户与开发人员坐在一起并提供反馈；这会使您的项目更强大。
• 诚实地进行测试：测试计划不应为创建而创建。测试计划应证明您已按计划进行。
• 根据情况调整：没有两个项目是相同的，没有两个组织是相同的，不同的人行为方式也不同。因此，我们的方法也必须根据情况进行调整，这一点非常重要。
• 度量指标的诚实性：不要为了收集或向外部人员炫耀您的项目有多少度量指标而收集度量指标。选择对您的项目有意义并能帮助您衡量项目健康状况的度量指标。
• 承担责任：不要强加或分配人们不喜欢的任务。相反，询问资源他喜欢哪些任务，并相应地分配。这将大大提高生产力，并保持项目热情高涨。
• 顺应人们的直觉：通常在一个项目团队中，有高度积极的人，中度积极的人，和积极性较低的人。所以，把权力交给你们积极的团队成员，并鼓励他们。

XP 中的用户故事是什么，它们与需求有什么不同？

用户故事无非就是最终用户需求。用户故事与需求的不同之处在于它们简短而精炼。简而言之，它们恰到好处，不多不少。用户故事理想情况下应该写在索引卡上。图“用户故事索引卡”显示了一张卡片。它是一张 3 x 5 英寸（8 x 13 厘米）的卡片。这将使您的故事尽可能小。需求文档需要很多页。由于我们保持故事简短，因此易于阅读和理解。传统的需求文档冗长，它们往往会失去项目的主要需求。

注：记得我以前在一家跨国公司工作时，一份需求文档的前50页都是历史、回溯、文档作者等内容。等我开始阅读核心需求时，我已经完全筋疲力尽了。

每个故事都有标题、简短描述和估算。估算部分我们稍后会讲。

注意：理论上，有卡片是好的，但在实际情况下，你不会有。我们看到在实际情况下，项目经理将故事保存在文档中，每个故事不超过 15 行。

谁来编写用户故事？

它由最终客户编写和拥有，而不是其他人。

什么时候说一个故事是有效的？

如果一个故事可以估算，那么它就是有效的。

XP 中何时编写测试计划？

测试计划在编写代码之前编写。

你能解释一下 XP 开发生命周期吗？

XP 开发周期包括两个阶段：“发布规划”和“迭代规划”。在发布规划中，我们决定要交付什么以及按什么优先级交付。在迭代规划中，我们将需求分解为任务，并规划如何交付发布规划中确定的那些活动。下图“实际本质”展示了这两个阶段实际交付的内容。

如果您仍然记得旧的 SDLC，下图“映射到传统周期”显示了这两个阶段如何映射到 SDLC。

那么，让我们更详细地探讨这两个阶段。“发布规划”和“迭代规划”这两个阶段都有三个共同的阶段：探索、承诺和指导。

发布计划

发布规划在每个项目开始时进行。在此阶段，项目被分解成小的发布。每个发布又被分解成一系列用户故事。现在让我们尝试理解发布规划中的三个阶段。

探索：在此阶段，通过使用用户故事概念（请阅读前面关于用户故事的问题以理解用户故事的概念）进行需求收集。在此阶段，我们理解需求以获得更高层次的理解。请注意，仅仅是更高层次的。用户故事卡通常尺寸为 3 X 5 英寸，因此您无法在该尺寸的卡片上真正深入细节。我们认为这绝对没问题，而不是编写大量文档；拥有重点明确的需求段落听起来很合理。因此，以下是探索阶段如何进行的逐步解释

如果开发人员无法估算，则将其退回给用户以修改和阐述用户故事。

• 第一步是用户在用户卡上编写故事。
• 故事写好后，开发人员对其进行分析，并确定我们是否可以估算用户故事。
• 一旦用户故事清晰且可以估算，就会计算理想天数或故事（在接下来的问题中阅读有关故事点、理想天数和估算的内容）。
• 现在是时候告诉用户，我们不能一次性交付所有东西，所以你能优先排序吗？在此阶段，最终用户对用户故事进行排名（在下一节中，我们将讨论用户故事如何排名）。
• 用户完成故事优先级排序后，就该确定速度了（在接下来的章节中，我们将有一个关于速度确定的完整问题）。
• 敏捷就是接受最终客户的改变。在此阶段，我们给最终用户一个机会，让他们决定是否要改变任何东西。如果他们想改变，我们要求用户更新故事。
• 如果一切顺利，我们将进行迭代规划。

图“发布计划”以图示形式展示了上述步骤。

迭代规划

迭代规划就是深入分析每个用户故事并将其分解成任务。此阶段也可以称为每个用户故事的详细说明。迭代规划就是将用户故事转化为任务。以下是迭代规划的详细步骤

• 在此迭代中需要交付的用户故事被分解为可管理的任务。
• 然后对每个任务进行估算。估算结果是理想工时或任务点（我们将在接下来的部分讨论任务点和理想工时）。
• 任务估算完成后，我们需要将任务分配给开发人员。每个程序员选择一个任务并承担完成任务的责任。
• 一旦开发人员承担了责任，他就应该估算工作量并承诺完成它。
• 在 XP 中，任何开发任务都应由两名开发人员共同完成。在此阶段，开发人员选择他/她的伙伴来开发任务。
• 在此阶段，我们进行任务设计。我们不应制定冗长而全面的设计方案；相反，它应该小而专注于任务。在传统 SDLC 中，我们有一个完全专门用于设计的阶段，其产出是一个冗长而复杂的设计文档。软件项目的一个重要特点是，当我们接近执行时，我们就会越清晰。因此，最好在执行之前准备好设计。
• 既然您和您的伙伴都熟悉了设计方案，现在是时候编写测试计划了。与传统 SDLC 相比，这是一个巨大的不同之处。我们首先编写测试计划，然后才开始执行。在编码之前编写测试计划，可以清楚地了解代码的预期结果。
• 测试计划完成后，是时候执行代码了。
• 在此阶段，我们运行测试计划，查看所有测试计划是否通过。
• 没有什么是一开始就完美的，它必须被完善。完成编码后，审查代码，看看是否有重构的空间（重构将在后续章节中更深入地解释）。
• 然后我们运行功能测试，以确保一切都达到标准。

需要认识到的一个重要点是，项目被分解为一系列发布，这些发布通过简短的用户故事进一步分析，用户故事又被分解为任务，由开发人员估算和执行。一旦一个发布完成，下一个发布就会被交付。例如，图“发布、故事和任务”中显示的项目有两个发布。

你能解释一下极限编程中的规划游戏是如何运作的吗？

上述问题的答案也回答了这个问题。

我们如何在敏捷中进行估算？

如果您仔细阅读敏捷周期（在上一节中解释过），您会发现敏捷估算发生在两个地方

• 用户故事级别估算：在此级别，用户故事使用迭代团队速度进行估算，输出结果是理想工日或故事点。
• 任务级别估算：这是第二个级别的估算。此估算是在开发人员级别进行的，根据分配的任务。此估算确保了用户故事估算的准确性。

估算发生在两个层面：当我们获取需求时，以及当我们非常接近执行时——即任务层面。这看起来非常合乎逻辑，因为当我们非常接近完成任务时，估算会越来越清晰。因此，任务层面估算只是作为用户故事层面估算的交叉验证。

用户故事级别估算

敏捷中用户故事的估算单位是“理想天数”或“故事点”。

理想天数无非就是开发人员花在或将花在纯粹编码上的实际时间。例如，接电话、开会、吃饭和早餐等时间不包括在理想天数内。在旧的估算技术中，我们估算八小时是开发人员编码的完整时间。但实际上，开发人员不会连续编码八小时，所以如果我们考虑完整的八小时工作日，估算可能是错误的。

估算单位也可以用故事点表示。故事点是用来表示故事大小的抽象单位。在正常情况下，一个故事点等于一个理想日。故事点是相对度量。如果一个故事是一个故事点，另一个是两个故事点，这意味着第二个故事需要第一个故事两倍的精力。

速度确定定义了一个迭代中可以完成多少个用户故事。所以首先用户决定迭代的长度。迭代的长度取决于发布日期。速度通常是从历史数据中确定的。因此，无论上次团队历史速度是多少，都将用于进一步的估算。但如果没有历史数据，则将使用以下公式

上图中包含两个公式：第一个公式用于我们没有项目历史数据的情况，第二个公式用于我们有迭代历史数据的情况。以下是公式中所有参数的详细信息

• 开发人员数量：迭代中的开发人员总数。
• 负载系数：这表示开发人员在项目上投入的生产时间。例如，如果负载系数为 2，则开发人员只有 50% 的生产力。
• 迭代持续多少个工作日：一个迭代包含多少个人日。

图“迭代和发布计算”显示了一个简单示例，团队规模为 5 人，负载系数为 2；一个迭代需要 11 个工作日，项目中有两次发布。

任务级别估算

随着敏捷周期的推进，用户故事被分解成任务并分配给开发人员。任务层面的工作量以任务点或理想工时表示。理想情况下，一个任务点代表一个理想工时。理想工时是开发人员只用于编码而不做其他事情的时间。

个人速度确定定义了开发人员在一次迭代中有多少理想工时。下图“个人速度计算”详细展示了如何计算开发人员在一次迭代中的理想工时。以下是一个示例计算，显示了每天工作 8 小时，一个迭代 11 天，以及负载系数为 2（即开发人员只编码 50% 的时间，即 4 小时），我们在该迭代中为该开发人员获得了 44 个理想工时。

故事可以基于什么进行优先级排序？

用户故事通常应从业务重要性的角度进行优先级排序。在实际场景中，这并不是唯一的标准。以下是优先级排序用户故事时需要考虑的一些因素

• 按业务价值排序：业务用户根据业务需求分配价值。业务价值有三个评级级别
  • 最重要的功能：没有这些功能，软件就毫无意义。
  • 重要功能：拥有这些功能很重要。但如果这些功能不存在，用户可以通过其他方式管理。
  • 锦上添花的功能：这些功能不是必需功能，而是最终用户的额外福利。
• 按风险排序：此因素帮助我们从开发角度按风险排序。风险指数介于 0 到 2 之间，并分为三个主要类别
  • 完整性
  • 波动性
  • 复杂性

下图“风险指数”显示了数值和分类。

你能指出敏捷和传统 SDLC 之间的简单区别吗？

图“敏捷和传统 SDLC”指出了两者的一些主要区别。如果您同时使用过这两种方法，您可能会发现更多区别。

• 冗长的需求文档现在变成了简单短小的用户故事。
• 估算单位“人天”和“人时”现在分别是“理想天数”和“理想工时”。
• 在传统方法中，我们冻结需求，完成完整设计，然后开始编码。但在敏捷中，我们按任务进行设计。因此，开发人员在开始任务之前才进行设计。
• 在传统的 SDLC 中，我们总是听到“签字后不能更改”；在敏捷中，我们为客户服务，所以我们接受更改。
• 在传统 SDLC 中，单元测试计划是在编码之后或编码期间编写的。在敏捷中，我们是在编写代码之前编写单元测试计划。