共同开发治理
建立有效的共同开发治理框架是确保制作者定义的项目和融合团队的一致性和可重复性的重要部分。 本文介绍了一种定义治理流程图的方法。
定义端到端流程
您可以使用以下流程作为示例，将其自定义为您组织的最佳实践。 只要您达到所需的结果，不需要完成每个步骤。
将功能添加到积压
积压使您能够通过添加推动整体体验的功能来计划您的项目。 积压还提供团队打算交付的总体路线图。
将新功能添加到积压时，目标是描述一般范围。 然后，每项功能定义推动代码开发工作的业务价值、草稿故事标题、范围和数据模型更改。
此外，在添加业务关键功能时，建议您发现可以自动化测试的任何关键场景。 添加功能后，您可以安排范围对齐会议。
范围对齐会议
此会议的重点应限于审查每项提议的新功能，然后检查是否有任何现有应用、场景或数据模型已经提供此功能，以避免重复工作。 此会议还提供讨论对其他应用的影响的机会。 最后，您应该检查此功能是否需要体验审查。
将故事和情节提要添加到积压
在范围对齐会议之后，可以在功能下添加任何草稿用户故事标题。 此时，不需要详细信息，用户故事的状态为“新”。 您可以在积压或板视图中查看故事。
下图显示了添加到积压的示例用户故事。
此时，通过按工作流和应用程序组织工作来保持质量至关重要。 这种方法帮助将相关工作项放在一起，使每个工作流的专家能够开发和持续深入了解每个应用中的功能和数据使用情况。
体验审查
体验审查应关注最终用户体验，并确保您的团队遵从组织的最佳实践。 这种一致性可确保您的所有应用为最终用户和支持团队提供可靠且可重复的体验。
添加故事详细信息
添加典型的用户故事可能包含以下信息：
- 标题：作为一名 <persona>，我可以 <do something> 来 <impact/priority/value>
- 说明：说明包括（但不限于）某些关键详细信息，如：
- 总结期望结果的场景的简要描述
- 叙述 - 描述用户为导航和完成场景将采取的操作
- 替代叙述 - 描述用户可以实现相同结果的其他方式
- 设计说明 – 记录与用户故事相关的实体、字段、视图、模型屏幕和业务规则
- 受影响的安全角色 - 列出所有受影响或与用户故事相关的安全角色。
添加所有这些详细信息后，您将用户故事的状态更改为“准备审查”。 在大多数情况下，由功能团队和业务团队（如果适用）审查用户故事。
故事审查
故事审查通常发生在融合团队中，确保所有细节都在故事中提及并且没有歧义。 完成所有审查后，建议将用户故事分配给团队成员。 确保您的团队在开发过程中保持一致对于实现您的总体目标至关重要。
添加任务和测试案例
审查故事后，团队成员在 Azure DevOps 中创建任务。 添加任务和测试案例的整个过程如下所示：
- 打开一个冲刺积压。 或者，创建一个新冲刺。
- 将现有工作项添加到冲刺中。 如果您已经添加了未出现在冲刺中的工作项，您应该检查它们的区域和迭代路径。 记住将任何非父级任务分配到相关工作项。
- 将任务添加到积压工作项。 如果您没有为您的冲刺分配积压工作项，现在来分配。 同时设置冲刺的开始和结束日期。
- 填写任务窗体。 根据经验，完成任务的时间应该不超过一天。 大于这个时间范围的任务应会中断。
- 跟踪或整合任何非父级任务。 您可以像其他任务一样跟踪非父级任务，或者将它们拖到现有积压工作项以将它们设为父任务。
添加任务和测试案例后，您可以继续设置冲刺产能。
有关添加任务的详细信息，请参阅将任务添加到积压工作项来支持冲刺计划。
准备解决方案
实现成功的共同开发的一个重要方面是结构化的发布管理流程。 解决方案是实现应用程序生命周期管理 (ALM) 的机制；您将使用解决方案通过导出和导入活动跨环境分发组件。 组件代表您的应用程序中使用的项目以及您可以自定义的内容。 可以包含在解决方案中的任何内容都是一个组件，如表、列、画布和模型驱动应用、Power Automate 流、聊天机器人、图表和插件。
重要
在发布计划期间，确定管理项目中的解决方案的策略。 使用解决方案管理您的项目并轻松找到您创建的组件，然后分发到其他环境。
部署
根据复杂程度和团队速度，组件可能需要多个冲刺才能完成。 随着任务的完成，组件应被添加到开发环境中的解决方案中。 完成测试后将解决方案导入到生产环境中。 我们建议您同时维护一个测试环境来执行端到端测试，并在投入生产之前对解决方案部署进行试验。
Power Platform 环境
环境是存储、管理和共享您组织的业务数据、应用程序和业务流程的空间。 还充当容器来隔离可能具有不同角色、安全要求或目标受众的应用。
如果您的组织有一个多团队融合设置，其中每个团队都在开发自己的解决方案，那么协调冲刺和发布的持续时间非常重要。 冲刺不必跟随项目时间线，与其长度一致，可以根据每个团队的偏好在团队之间调整持续时间。 但是，发布节奏不能短于所有团队的最短冲刺持续时间。
源代码管理
考虑采用源代码管理系统，如 Azure DevOps。 Azure DevOps 为开发人员提供支持团队计划工作、进行代码开发协作以及构建和部署应用程序的服务。
从包含您的应用和自定义项的开发环境中导出解决方案，解压缩解决方案，并将组件存储在源代码控制系统中。
高级主题：拉取请求 (PR) 审查
您应该只为活动的案例创建 PR，并且已经对功能进行了审查并批准。 您应确保解决方案版本控制准确，遵从在 Azure Boards 中为团队实施 Scrum 实践中规定的冲刺和开发指南。 PR 的测试结果可以是描述正在构建的功能的屏幕截图或视频。
自动化 PR 治理过程可以帮助确保代码质量，而无需手动审查解决方案版本等基本检查。
备注
使用 PR 检查器工具自动执行拉取请求检查过程。
模板和标准化
模板和标准化通过帮助促进团队内部的一致性来提高效率。 团队运营— 的所有方面，无论是载入任务、故事评审演示文稿，还是在 定义用户故事、功能、bug 或任务 时帮助节省时间为团队提供指导的工作项模板—，都受益于标准化和简化。
实施有效的支持模型
正如前面关于生成支持矩阵的章节所强调的那样，有效的支持模型对于应用程序在部署后的长期成功至关重要。 Bug 和中断是不可避免的，因此团队必须有一个结构化的方法来处理这些情况，支持矩阵将提供必要的框架。
创建服务级别协议
任何支持模型中的一个关键因素是服务级别协议 (SLA) 的定义。 SLA 应该是团队起草的正式文档，其中包含涵盖以下各项的章节：
- 中断 – 什么级别的服务中断是可接受的，通知谁，采取哪些行动，如何进行服务恢复确认，以及采取哪些行动防止重复发生。 团队使用的任何自动化测试过程都需要与预期的中断容限和适用的 SLA 保持一致。
- Bug – 谁可以通知、分配严重性级别、分类、检测后执行操作、谁负责解决和签核。
- 升级 – 升级级别、员工分配级别、每个级别的职责、每个级别的通讯组列表，等等。
SLA 应存储在团队的文档门户中，并根据需要进行更新。
提供应用程序支持
提供 SLA 中指定的应用程序支持的最佳方法是让创建解决方案的团队也负责支持它。 此系统的优点是：
- 鼓励更高质量的开发，因为那些创建应用的人知道他们将不得不为应用提供支持。
- 创作者能够比第三方团队更快地发现和修复 bug，这只是因为他们更了解应用。
- 将潜在的任务关键软件的修复工作委派给另一个团队可能会使该团队士气低落且耗时。 与应用程序创建、开发和部署的其他阶段一样，融合团队应在需要时与 IT 合作寻求帮助。
监视应用程序满意度和可用性
支持工作的最后一部分是监视和评估已部署应用的满意度和可用性。 指标在这里很有用，还有更传统的方法，如民意调查和问卷调查。 有关监视应用使用情况的详细信息，请参阅 Power Apps 的管理员分析。
最终，如果客户没有使用发布的应用，那么该应用就没有达到它的目的。 定期审查会议可以检查这些满意度和可用性指标，来创建一个积极的反馈循环来更改故事或将故事添加到积压，进而生成然后部署应用的更新版本。
总结
诸如 Power Apps 之类的无代码和低代码工具的开发扩大了业务技术人员或制作者创建、开发和部署应用的选择。 这种开发在融合团队环境中效果最好，包括产品负责人、领域专家、专业开发人员和管理员，此团队可以根据需要引入其他资源。
在融合团队中集成敏捷和混合的开发方法，可以使用对业务产生重大影响的功能集加快应用的开发速度，并提高成功部署的可能性。 通过应用这些最佳实践、指南和建议，您的融合团队将能够使用 Power Apps 来应对您组织的数字化转型挑战。