实施Microsoft Dynamics 365 CE-2. 实施方法，解释不同的项目实施方法。_dynamic 365 ce

本章将帮助您了解什么是项目以及我们如何管理项目。在这里，您将学习高级项目管理活动。除此之外，我们还将讨论项目管理方法以及我们为什么需要它们。我们还将了解不同的、常用的项目管理方法，如瀑布、敏捷、Scrum、功能驱动开发、DevOps和Microsoft Sure Step及其阶段。一旦您对项目管理方法有了想法，我们将讨论您在决定哪种方法最适合Dynamics 365 CE实施时需要考虑的主要问题。

我们将在本章中讨论的主要主题如下：

• 了解项目管理
• 了解项目管理方法
• 为Dynamics 365 CE选择方法

了解项目管理

在讨论项目管理方法之前，让我们首先确定什么是项目。项目是一组临时活动，通常被称为软件行业的任务，应该在特定的时间和预算内完成，以实现特定的目标。任务必须在特定的时间段内启动和完成。您的项目工期和项目预算取决于许多因素，包括我们将在项目中包括多少活动，以及完成这组活动需要多少资源。例如，与开发新软件产品相比，任何软件的维护项目的持续时间和预算都较小。

定义项目活动也称为项目范围界定。项目范围是负责定义需要什么以及如何实现我们的要求。最佳实践是在开始处理项目的任何活动之前，正确定义项目范围。在项目启动后添加活动可能会影响项目的时间表和预算。在下图中，您可以看到，项目分为三个高级步骤，我们从定义项目活动开始，然后开始处理这些活动，最后完成所有活动以完成项目：

 项目活动在不同阶段进行，以便更好地管理，并对产出质量进行更多的控制。这些阶段也称为项目阶段。项目阶段通常取决于前一阶段的输出，因此下一阶段可以将前一阶段输出作为输入。

让我们举一个组装自行车的简单例子，其中一个阶段是获得所有自行车零件，下一阶段是将它们组装在一起，形成一个完整的自行车。项目阶段本质上是渐进的，这意味着项目的每个阶段都需要添加一些改进，以实现项目的总体目标。既然我们已经对项目有了很好的了解，让我们来讨论一下项目管理。

• 项目管理是一个过程，对任何项目成功实现其目标都非常重要。项目管理过程控制着项目的所有阶段，并将它们连接在一起以实现项目目标。项目管理过程主要可分为五个阶段，如下图所示：

• 启动:该阶段负责确定项目的所有需求，也被视为项目活动的开始。在这个阶段，所有的项目需求都被记录下来，这样文档就可以建立项目的基础。我们也可以说，这个阶段负责确定项目的范围并设定其目标输出。在进入下一阶段之前，每个项目活动都应该定义清楚。此阶段生成的文档通常称为需求文档。
• 计划:该阶段负责确定项目的所有需求，也被视为项目活动的开始。在这个阶段，所有的项目需求都被记录下来，这样文档就可以建立项目的基础。我们也可以说，这个阶段负责确定项目的范围并设定其目标输出。在进入下一阶段之前，每个项目活动都应该定义清楚。此阶段生成的文档通常称为需求文档。
• 执行:在此阶段，所有项目活动都由各自的项目团队成员根据早期阶段生成的文档进行。在进行活动时，每个团队成员都有责任在活动本身的时间范围内完成他们分配的活动。
• 测试:一旦所有项目活动都完成了，就要根据项目要求对它们进行测试，以确保它们满足客户的期望。第一阶段中记录的需求被用作测试活动的基础。如果活动不符合要求，则将其送回各自的团队进行返工。
• 完成:这是任何项目的最后阶段。在这里，所有项目活动都已完成，项目已准备好结束。在发布项目的输出之前，将根据项目要求进行最终审查，以查看项目的最终输出是否满足所有要求。这一最终审查也有助于团队记录他们在该项目中面临的挑战，以便在未来的所有项目中都能妥善应对同样的挑战。

项目管理层负责执行之前的所有阶段，以确保根据客户的项目预期实现项目目标。为了有效地实施项目管理，我们将在下一个主题中讨论不同的项目管理方法。

了解项目管理方法论

在进行项目时，项目经理会使用不同的技术和工具来保持项目的有序性，并按时交付。项目经理做出的最关键的决定之一是选择合适的项目管理方法。我们在上一个主题中了解了常见的项目管理阶段。在实施这些阶段时，项目经理需要遵循特定的实践来规划、管理和执行项目，这就是我们所说的项目管理方法。

我们也可以称之为一种模型，可以应用于项目管理，以在设定的项目时间表和预算内实现项目目标。项目管理方法帮助管理者从项目的初始阶段到交付阶段管理他们的项目。它可以帮助管理者为不同的活动建立一个协议。例如，项目团队将如何沟通，如何将任务分配给团队成员，设置质量控制，管理项目时间表，以及交付项目输出。

毫无疑问，使用项目管理方法通过标准化业务流程、建立沟通规则、制定指导方针和降低项目失败风险，为组织提供了许多优势。公司可以采用不同的方法来实施项目，但项目将使用哪种项目管理方法取决于项目经理。项目经理根据他们过去的经验和行业要求使用项目方法，因为并非所有方法都可以用于每个项目。例如，在进行建筑项目时，特定的项目方法可能比软件项目中常见的方法更有帮助。

这里列出了我们将要研究的各种项目管理方法:

• 瀑布
• 螺旋
• 敏捷
• Scrum
• RAD
• 微软Sure Step
• 看板
• 功能驱动开发
• DevOps

瀑布法(waterfall)

这是用于项目管理的最流行和最简单的方法之一。在这种方法中，项目被划分为顺序任务，然后逐一执行，直到所有任务都完成。这类似于瀑布，水从上到下流动，因此得名。在这种方法中，您不能返回到前一阶段。相反，唯一可能的选择是回到最初阶段，重新开始。一级产生的输出变成下一级的输入。

在Waterfall方法中，每个阶段都会进行全面的文档记录，这在进行维护或项目期间新成员加入时非常有用。他们可以很容易地参考文档来了解项目的详细信息。瀑布模型将一个完整的项目分为六个不同的阶段。通过使用下图，我们可以了解这些阶段是如何逐一实现的：

让我们详细讨论这些阶段：

1. 需求分析：这是瀑布模型的第一阶段。在这个阶段，我们将了解需要什么。这个阶段需要与客户进行大量的交互，以详细了解他们的需求。使用各种技术来确定需求，我们将在后面的章节中讨论这些技术。所有要求都正确记录在必要的文件中。一旦知道了项目需求，就讨论了解决方案的可行性。对所有需求进行了适当的分析，并考虑了开发潜在系统的不同可能性。在此阶段，还将分析客户端拥有的任何现有基础设施，如现有服务器，以确定在新系统中的潜在用途。
2. 设计：在这个阶段，最终输出的蓝图是根据第一步中产生的项目需求准备的，然后选择合适的技术。所有的功能和技术设计文件都是在这个阶段与系统架构一起准备的。一旦所有的设计文档都准备好了，项目就进入下一阶段。
3. 编码：在此阶段，代码由团队成员根据设计文档进行开发。团队成员处理各个模块，这些模块一旦完成就会与其他模块集成。团队成员还对他们的代码进行单元测试，以避免任何设计时或运行时错误。
4. 测试：一旦开发出所有模块，质量团队成员将根据第一阶段生成的需求文档对其进行测试。质量团队首先使用需求准备测试用例，然后稍后进行手动或自动测试。手动测试由QA团队成员手动完成，无需使用任何测试工具或脚本，而自动化测试是使用工具和脚本来完成的。自动测试对于在代码更改或任何升级后重新测试测试用例非常有用。
5. 部署：在这个阶段，最终输出由客户端验证，这涉及到最终用户的用户接受测试。最终用户执行功能测试，以确保项目输出基于他们的期望。该阶段还举办了终端用户培训课程。
6. 维护：在这个阶段，实施部署后的更改。这包括修复任何客户端问题，为项目添加更多功能，或者在需要时升级软件补丁。

瀑布法是软件和建筑行业的一种常见方法。这种方法强调在初始阶段进一步收集所有需求，并将其适当地记录下来，以便在后续阶段使用。随着项目一个接一个地经过易于理解的阶段，这个模型很容易理解。然而，这个模型不能用于在初始阶段很难找到所有需求的项目。这是因为一旦项目启动，就很难添加新的需求。

螺旋式方法(Spiral)

这是另一个非常古老的项目管理模型，可以被认为是瀑布模型和迭代模型的组合。在螺旋模型中，为每个迭代确定一个需求列表，称为螺旋。每个螺旋的输出都是该项目的一个小原型。客户可以查看此原型并提供反馈。同样，也确定了下一个螺旋的需求。遵循此过程，直到项目完成并准备交付。正如我们在下面的Spiral模型图中所看到的，每个Spiral中都开发了一个小型原型：

螺旋模型有四个阶段。下面我们来讨论一下：

• 确定项目目标：在这个阶段，从客户那里收集需求，并针对这些需求进行可行性研究。还分析了任何现有的基础设施，以便在潜在的系统中使用。所有的规划都是在这个阶段完成的，包括为每个螺旋线准备项目时间表和资源分配。
• 发现并解决风险：在这个阶段，顾名思义，访问所有需求以识别任何潜在的项目风险。对所有风险都进行了适当的记录，并使用尽可能好的选项来解决这些风险。
• 开发和测试：所有的开发和测试都是在这个阶段完成的。在将系统交付给客户之前，将开发并测试该系统的小型原型。
• 审查并计划下一次迭代：在这个阶段，客户审查原型并提供反馈。审查后，计划下一个螺旋式需求。

该模型适用于大型项目，客户可以在每次迭代后审查项目进度，并提供有关原型的反馈。它还允许在项目启动后进行需求更改。项目风险在早期阶段就被识别并修复，以避免项目失败。然而，这种模型不能应用于小型项目，风险分析需要更多经验丰富的资源。

敏捷方法论(Agile)

这是目前使用的一种非常常见的项目管理方法，尤其是用于管理软件开发项目。当启动项目时不清楚完整的需求，但项目利益相关者对他们想要的东西有一个总体的想法时，这个模型最适合。敏捷方法论基本上实现了在多次迭代中开发软件的思想；每一次迭代都使用完整的软件开发生命周期（SDLC）过程，利益相关者也不断地参与到每一次的迭代中来提供他们的反馈。

在这个模型中，项目在迭代中移动到下一个级别，并且项目任务是根据它们的优先级执行的。项目任务的优先级列表在敏捷中被称为产品积压。团队成员共同处理产品积压工作，并根据他们的优先级提供任务估计。

SDLC是软件开发公司用来开发软件的过程。它分为许多阶段，从需求收集开始，到维护阶段结束。

我们可以使用下图来定义敏捷方法论，该图解释了高级敏捷方法论过程：

 与其他方法论相比，敏捷方法论可以帮助团队使用小迭代快速交付更好的产品。敏捷方法论使用以下主要原则：

1. 持续的团队互动
2. 使用文档的工作模块
3. 与利益相关者持续合作
4. 快速响应变化

敏捷方法论保持持续的团队沟通，包括从开发人员到客户的每个团队成员。敏捷团队不仅仅由项目经理来管理；相反，团队管理是每个团队成员的责任。每天的电话会议被称为Scrum电话会议，讨论项目进展和任何障碍。在每次sprint（通常从一周到四周）之后，都会发布一个包含完整文档的工作模型。

最终用户在每次冲刺后都会进行用户验收测试，与利益相关者的持续互动也确保了项目朝着正确的方向发展。sprint之后发布的工作模型总是基于客户的期望。敏捷项目管理能够快速应对变化。利用这一原则，项目团队
快速响应客户、最终用户、利益相关者和市场趋势，确保最终产品对最终用户有帮助，并且是他们真正想要使用的产品。

如今，敏捷被用作其他方法论的框架，如Scrum和看板，整个项目通过不断迭代和协作进行管理。毫无疑问，敏捷可以帮助团队提高灵活性和协作性，这最终会导致一个更成功的项目，在项目启动过程中，最终目标没有明确定义。

Scrum方法论

Scrum基本上是用来实现敏捷方法论的，所以我们也可以把它称为敏捷的一个子集。使用Scrum，我们在每冲刺一到两周后都会向客户交付增量产品。冲刺结束后，每个团队成员都会开会为下一次冲刺做计划。Scrum中涉及的一些高级活动是sprint计划、每日站立电话、sprint评审以及每次sprint之后的构建发布。Scrum通常用于需求变化非常快的情况。下图表示了在Scrum方法中执行的完整的常见步骤：

现在让我们讨论一下Scrum方法中包含的常见阶段。

Product backlog:

第一阶段是收集客户的高级需求并准备产品积压工作。客户需求是根据其在产品积压工作中的优先级排序的。这些要求由产品所有者确定优先级。产品积压工作包括客户在最终产品中期望的所有功能。这些需求被称为用户故事。

用户故事从最终用户的角度提供了有关需求的详细信息，重点是他们想做什么或想在产品中拥有什么功能。这些用户故事不包括完整的需求集，而是只包括客户在启动项目时脑海中的功能。客户期望的特性列表可以在实现过程中更改，但产品积压仍然是Scrum实现过程的需求文档。此文档用作sprint计划的基础文档。

Sprint planning:

在准备好产品积压工作之后，下一步是计划冲刺。冲刺计划是在每次冲刺结束后完成的。在sprint计划中，Scrum团队选择一个将包含在当前sprint中的需求列表。在sprint规划中回答了以下一些问题：

• 这次冲刺的目标是什么？
• 哪些产品积压项目将包含在这个sprint中？
• 在这个sprint中包含的用户故事的时间估计是多少？
• 谁可以参加这次冲刺？
• 在sprint之后，我们将如何交付增量构建？

sprint计划的输出是sprint backlog和时间估计。根据优先级、工作量估计和团队能力，从产品积压中选择的需求包含在sprint积压中。Scrum方法论为团队提供了关于在当前sprint中实现的用户故事的灵活性，因为sprint积压项目可以从一个sprint移动到另一个。如果任何sprint积压项目在当前sprint期间没有完成，那么它们将被移动到下一个sprint。

Daily standup:

在sprint期间，团队成员每天都会召开Scrum会议，会议时间不应超过15分钟。这些Scrum会议由Scrum团队成员管理。Scrum Master充当团队教练，激励每一位团队成员发挥最佳表现。在日常会议中，团队成员向团队更新他们的任务状态、他们将要处理的下一项任务，并讨论障碍（如果有的话）。
每日电话帮助团队获取有关用户故事状态的更新。任何潜在的问题都可以提前确定，团队共同努力解决。

在每日站会中，消耗图表会根据球队的状态进行更新。燃尽图可以被视为每日Scrum调用的输出，它可以帮助每个团队成员了解还有多少任务。

Sprint review:

sprint审查是在每次sprint结束时完成的。在sprint评审过程中，将向Scrum团队、利益相关者和最终用户演示已完成的用户故事。
利益相关者和最终用户在演示后提供他们的反馈，Scrum团队相应地对反馈采取行动。

backlog 工作细化:

一旦sprint结束，下一步就是完善产品积压工作。在此过程中，会将新的用户故事添加到产品积压工作中，并从中删除不必要的用户故事。如果需要，产品所有者可以更改用户故事的优先级。

毫无疑问，Scrum方法论有助于我们快速实施项目。
较大的项目可以分为多个sprint。就适应新变化的容易程度而言，它非常灵活。例如，如果利益相关者请求一个新功能，产品所有者可以很容易地将它们添加到产品积压工作中。但有时，当利益相关者不断请求新功能时，这会成为项目的风险。

RAD:

快速应用程序开发（RAD）是另一种用于实现敏捷的方法。RAD现在非常流行，使用这种方法的主要原因是快速有效地构建系统的工作原型。在开发过程中，这种方法在接受更改方面也非常灵活。在这里，花在规划上的时间更少，主要集中在使用迭代步骤开发原型上，这有助于项目经理和利益相关者准确衡量项目进度。

他们可以在使用原型后提供反馈，团队可以快速将其纳入其中。下图解释了RAD方法如何用于项目：

让我们讨论一下RAD中使用的常见阶段。

需求计划：

在这个阶段中，对项目进行需求收集和规划。在RAD方法中，与其他项目方法相比，规划阶段更短。收集需求以了解客户在最终产品中想要什么。本阶段还分析了当前的业务流程。一旦收集到需求，项目在获得客户对需求的批准后进入下一阶段。

开发原型：

在这个阶段，原型的设计和开发就开始了。一个团队处理在早期阶段收集的需求，以准备UI和数据模型。然后，他们根据客户反馈定制UI。在开始代码开发之前，获得客户对UI的批准是非常重要的。一旦设计和数据模型完成，团队就开始为需求编写代码。

单元测试后，向包括利益相关者在内的所有团队成员演示原型。利益相关者提供反馈，然后与团队沟通功能运行良好，但失败了。然后，团队根据提供的反馈对原型进行改进。此阶段根据需求在多次迭代中实现。在整合了所有反馈和请求的更改之后，项目进入下一阶段。

测试：

在这个阶段，QA团队执行系统和集成测试，以确保这个新的原型能够与现有系统很好地配合使用。大多数问题已经在早期阶段根据客户反馈得到解决。在RAD中，每个原型都是独立测试的，这减少了整个测试时间。在这个阶段，还测试了开发策略，以确保部署顺利进行。

发布：

这是RAD的最后阶段，最终产品发布给最终用户。这个阶段包括最终用户测试、数据迁移和转换到新系统。客户可以记录发布后遇到的任何问题。

RAD有助于在更短的时间内实现更多目标。快速迭代可以适应所要求的新更改，因此最终产品始终基于客户的期望。由于已经进行了集成测试，所以在项目发布期间遇到任何集成问题的情况都不太常见。然而，这种方法只能用于产品开发，其中模块可以独立开发，并且需要更短的开发周期。

Microsoft Sure Step

Microsoft Sure Step方法由Microsoft开发，用于为客户实施Dynamics产品。Microsoft Sure Step方法论具有实现Dynamics解决方案所需的内置过程和规程。它还包括Dynamics实施过程中各种任务所需的内置文档模板，以及成功实施Dynamics的一套指导方针和最佳实践。Microsoft Sure Step将项目分类，我们将在以下小节中讨论这些分类。

Microsoft Sure Step–项目：

这提供了有关参与Sure Step项目的不同用户的信息，包括客户和咨询方。我们可以使用下图来理解Sure Step方法论项目，并查看有关不同阶段和项目的详细信息：

 在上图中，我们可以看到，在Microsoft Sure Step方法中，我们有不同的项目类别，所以让我们逐一讨论这些项目，以了解更多关于它们的信息：

• Standard:针对单个客户站点的Microsoft Dynamics实施属于此类。此项目需要对Dynamics应用程序进行适度到复杂的自定义。
• Enterprise: 单个站点或多个站点的Microsoft Dynamics复杂实现属于此项目类别。由于这些都是复杂的实现，因此开发Dynamics解决方案需要付出相当大的努力。与其他项目类型相比，该项目的范围更大。
• Agile:此类别下的项目使用迭代方法来实现Microsoft Dynamics应用程序。在这些类型的项目中，并不是所有的需求在项目开始时都是已知的，因此可以在实施过程中添加新的需求。整个敏捷项目分为多次迭代。
• Rapid:范围有限的Microsoft Dynamics实施项目属于此类。该项目下的大多数需求都可以使用Dynamics应用程序的开箱即用功能来实现。
• Upgrade:如果客户已经在使用Microsoft Dynamics应用程序，并且希望将其更新到最新版本，则将其视为升级项目。Microsoft Sure Step提供基于不同行业的项目支持文档。这些文件是基于特定项目的选择。

现在我们对项目有了更多的了解，让我们来看看各个阶段。

Microsoft Sure Step–阶段:

Microsoft Sure Step方法论还实现了一系列阶段。每个阶段都有其重要性。让我们逐一详细了解这些阶段：

• 诊断：这个阶段的主要目标是找出需要什么。收集客户需求，并根据客户的关键需求向客户展示适当的Microsoft Dynamics应用程序。有时，还会构建一个小型概念验证（POC）来展示Microsoft Dynamics产品的功能。所有需求都收集在需求规范文件中。一旦需求被捕获，项目就进入下一阶段。
• 分析：在此阶段，将正确分析早期阶段生成的需求文档，并对客户需求进行可行性研究。进行匹配差距分析，将客户需求与Microsoft Dynamics功能进行比较，并在需要定制和开发的地方确定差距。该阶段还建立了一个变更控制计划，该计划确定了在需要时如何将新需求添加到项目范围中。
• 设计：此阶段用于根据要求准备设计和配置Microsoft Dynamics应用程序。该团队致力于应用程序的功能和技术设计。准备好应用程序的屏幕布局，并获得客户的批准。技术设计文件是在这个阶段准备的，其中包含了所需的任何定制和开发的详细信息。
• 开发：在这个阶段，完成了代码开发，并基于技术设计文档构建了系统。如果系统需要与第三方系统集成，也将在此阶段构建。一旦开发完成，所有的系统模块都将由QA团队成员进行测试。如果当前系统需要任何数据迁移脚本或过程，也会在此阶段进行开发。
• 部署：在此阶段，将根据所有要求执行安装在客户位置QA服务器和UAT上的Microsoft Dynamics解决方案，以确保最终产品符合客户的期望。关键用户在这一阶段接受了使用新系统的培训。准备了一份上线检查表，其中包括生产部署的关键配置。最后，在UAT完成后，根据之前决定的切换时间执行生产切换，为将在日常工作中使用该系统的最终用户发布项目。
• 操作：这一阶段是项目的最后一个阶段，对系统进行最后审查，并决定部署后的支助战略。

Microsoft Sure Step方法体系为客户实施Microsoft Dynamics所需的时间较少，因为它包括一套工具、所需的模板和最佳实践。

Kanban

这是继敏捷项目管理方法之后的另一种流行的项目管理方法。它使用一种可视化的方法来管理整个过程中的项目。在这种方法中，工作项是在看板板的帮助下表示的，如下图所示，它允许团队成员随时查看每项工作的状态：

上图中用数字表示的工作项目使用看板卡显示。在前面的看板中，我们可以看到所有工作项的当前状态。To Do是尚未启动的挂起项目的列表，而In Progress项目是正在开发的项目。已完成队列显示所有已完成的项目。看板使用以下基本原则：

• 项目活动的视觉板
• 一次处理有限的项目活动
• 活动的流程管理
• 实施反馈
• 实施团队之间的协作

该方法中的工作项目可以根据利益相关者的
要求。看板工作项从不绑定到特定的迭代，因此这为开发人员提供了灵活性。团队成员在整个项目中相互协作，以改善看板委员会的工作流程。这种方法最适合小型团队的项目。

功能驱动开发

功能驱动开发是敏捷家族下的另一种项目管理方法，这意味着它也遵循迭代和增量开发过程。在这种方法中，客户需求被表示为成为产品开发基础的特征。我们可以考虑Scrum中的用户故事等功能。

下图解释了功能驱动开发方法的各个阶段：

 

 让我们更详细地讨论这些阶段：

• 制定总体模型：在此阶段，将准备解决方案的总体模型，该模型将解释解决方案的高级功能。它并没有在这个阶段提供所有的项目细节。这个阶段有助于团队理解项目的总体目标。
• 构建功能列表：一旦整个模型准备就绪，团队成员对项目目标有了了解，所有客户需求就被划分为功能。在这个阶段，将准备一个特性列表，作为整个项目的基础。大功能分为可管理的小功能，开发时间不应超过2周。
• 基于功能的计划：在准备好完整的功能列表、功能规划后，开始实施。每个功能都要进行规划，这涉及到不同的活动，例如设置它们的优先级、识别风险、资源分配以及识别依赖关系（如果有）。
• 按功能设计：在这个阶段，团队开始设计分配给他们的功能。设计文档是为要素创建的。一旦设计准备好了这些功能，就会进行性能检查，以避免在开发这些功能时出现任何混乱。
• 按功能建立：一旦设计阶段完成，团队就开始根据设计文档开发代码。之后，对代码进行功能测试。测试完成后，由首席架构师进行验证。在首席架构师批准后，此功能将添加到构建中。

在前面的五个简单阶段之后，特征驱动开发方法可以用于快速的产品开发。最初没有花太多时间讨论需求细节。相反，整个模型是为了理解项目的高层目标而准备的。然而，这种方法不能与小团队一起使用，因为它需要一位专业的首席架构师来领导团队并监控所有的开发和测试过程。

DevOps

DevOps填补了开发团队和运营团队之间的空白。DevOps这个词是“开发”和“运营”的组合。这有助于自动化开发和部署项目的过程，更快、更高效。DevOps基本上使用敏捷来创建一个价值驱动的环境，用于快速部署软件产品和功能。

下图为我们提供了有关DevOps方法论的基本思想：

 让我们讨论一下DevOps的常见阶段：

• 开发：在这个阶段，软件开发是持续进行的。开发过程分为几个小的开发周期。
• 测试：在这个阶段，将对早期阶段开发的代码进行自动化测试。这涉及到编写一个自动化的测试脚本。这些自动化测试脚本由自动化测试工具用于测试团队开发的功能。
• 集成：在此阶段，将新功能与现有功能集成，并执行集成测试。持续开发也支持持续集成。
• 部署：在此阶段，将进行连续部署。部署是这样做不应该影响任何现有功能。

使用DevOps的主要优势是使整个开发和发布过程更快。因此，产品可以以更快的方式发布给用户，因为所有任务都是自动化的，不需要任何手动操作。当我们经常需要项目发布时，这非常有用。自动化工具的使用确保了高质量、高效率的产品。因此，产品可以更快地投放市场。发布自动化还将部署失败的风险降至最低，从而显著减少了错误的数量。

除了上述方法之外，有时，公司还创建自己的混合项目管理方法，其中包括各种项目管理方法的模板、工具和流程。现在，我们讨论了最流行的项目管理方法，并了解到每种方法都有其优缺点。在规划项目实施时，首要任务是选择一种适合您项目的项目管理方法，以使实施更加顺利和高效。现在，在下一节中，我们将讨论前面的哪种方法可以用于实现Dynamics365CE。

为Dynamics 365 CE选择方法

Microsoft Dynamics 365 CE可以使用不同的项目管理方法来实现，如Sure Step、Agile、Scrum、Waterfall和DevOps，我们在项目管理方法论部分对此进行了讨论。项目经理在为您的组织选择正确的实施方法方面发挥着关键作用。项目经理选择哪种方法取决于他们过去的项目经验，有时这是由为您实施Dynamics 365 CE的Microsoft合作伙伴公司决定的。但是，在为您的公司选择正确的方法论之前，让我们首先了解为什么在为组织实施Dynamics 365 CE时使用项目管理方法论非常重要。

使用项目管理方法来实施Dynamics 365 CE的最常见原因包括以下几点：

• 有效管理项目时间表
• 为了更好的项目管理
• 用于使用预定义的工具和模板
• 用于降低项目失败风险
• 用于团队协作和技能发展
• 确保利益相关者获得投资回报

既然我们知道了使用项目管理方法的主要原因，接下来的问题就来了：哪种方法最适合Dynamics 365 CE的实施？在讨论合适的方法之前，我们应该试着回答以下问题：

• 项目目标明确吗？这个问题对于选择方法很重要。例如，如果项目目标明确，我们可以使用瀑布模型；否则，使用敏捷方法将有助于Dynamics365CE的实现。
• 所有的要求都知道吗？需求在方法的选择中发挥着关键作用，因为有些方法要求在开始实施规划之前明确定义所有项目需求。另一方面，一些方法只要求项目的高层目标是已知的，并且一旦项目开始，就可以捕获详细的需求。
• 需求是复杂的还是简单的？这是另一个重要问题。简单的需求将花费更少的时间，并且可以使用开箱即用的Dynamics365CE功能或通过最少的定制来实现。另一方面，如果需求很复杂，则需要大量的开发工作，这可能会增加项目发布时间。
• 要求可以更改吗？某些方法，如瀑布模型，不允许在Dynamics365CE实施启动后更改需求。相比之下，其他方法论，如Spiral、Agile和Scrum，在每次迭代中都接受更改。
• 客户是否可以参加项目会议？在Dynamics365CE期间，客户参与发挥着至关重要的作用。有些方法在实施的初始阶段需要与客户进行最少的互动。然而，有些方法需要与客户持续互动，以便在每次迭代后获得他们的反馈。客户反馈在Dynamics365CE中发挥着至关重要的作用，确保将项目失败的风险降至最低。
• 项目发布时间表是什么？一些客户要求在短时间内完成Dynamics 365 CE实施，具体取决于他们的业务需求。客户希望尽快为其最终用户提供新系统，尤其是当最终用户等待很长时间才能访问新功能时。当他们希望解决现有系统中的问题时，情况也是如此。我们可以使用DevOps等方法来实现快速生产发布，从而高效地实现发布过程的自动化。
• 一个项目可以分为几个模块吗？一些Dynamics365CE项目需求可以划分为多个单独的模块，这些模块可以在没有任何依赖性的情况下独立开发。有时，一个团队可以并行处理模块，而有时不可能将需求分解为多个模块。
• 客户是否希望他们的项目发布一个版本？有时，Dynamics 365 CE客户要求所有部门都发布一个产品版本。他们希望一个新的系统能够一次性应用。但是，有些客户希望逐个部门实现Dynamics365CE，这需要项目的多个版本。瀑布模型最适合单个生产版本，而敏捷家族方法论可以用于多个版本。每个sprint都可以向特定的部门发布特定的功能。