有关正式化软件开发和管理的建议
适用于此 Power Platform Well-Architected 卓越运营清单建议：
| OE：03 | 利用既定的行业和组织标准，将软件构思和规划过程正式化。 使用通用的、按优先级排列的积压工作和足够详细的规范。 根据结果，推动规划过程中的持续改进。 |
|---|
本指南介绍根据既定标准管理软件开发实践的建议。 您的团队生产高质量软件的能力取决于结构化的协作式开发规划方法。 工作负载团队应了解并清楚地向利益相关者传达正在完成的工作。 更准确地说，工作负载团队应该清楚地了解开发周期中要完成的工作，并确保所有利益相关者都就该工作的“原因”达成一致。 既定标准定义了应如何执行开发实践，并允许工作负载团队进行有效协作，从而降低目标和预期混淆的风险。
关键设计策略
将软件开发实践规范化，以帮助确保对目标和期望达成共识。
不要将低代码工作负载视为低复杂性工作负载。 您仍然可以从正式化低代码工作负载的开发和管理中受益。 向其他软件开发团队学习。 制定一个决策矩阵，根据工作负载的复杂性和关键性规定所需的正式化级别。
开发规划标准
以下标准可帮助您设计全面的开发规划策略。
优先级：规划工作的顺序和范围涉及了解工作负载功能对业务的真正影响和价值。 还包括针对其他工作请求和您的产品或计划的整体路线图，对这些影响进行评估。 确定工作负载优先级的一种方法是评估整个工作负载的业务价值。 您可能还会发现评估单个工作负载特性的业务价值很有用。
分类：建立流程，确保关键应用程序具有必要的护栏来支持它们。 同时，确保生产力方案不会因过多的严格流程而减慢或扼杀。
协作：定义对工作负载的拟议更改的过程应是一项协作工作。 对工作负载的大多数更改都会影响多个功能和组件，因此让尽可能多的工作负载团队成员参与有助于确保不会错过重要的注意事项，并且每个人都知道对其特定域的影响。 协作还有助于明确定义更改的范围以及如何将必要的任务划分为定义明确的工作项。 具有跨领域专业知识的更大团队能够为所需的工作提供经验支持的估算。
权衡：如果敏捷方法过于规范，它可能会变得过于严格。 努力在定义明确的标准和创新之间取得平衡。
部署：计划使用频繁的小型迭代部署，而不是使用大型、不频繁的部署。
术语：标准化已完成 开发周期的 定义，以帮助确保成功完成支持功能，包括测试、文档和辅助功能。
沟通：为产品所有者和项目经理定义标准协议，以提升即将发布的版本。
用户情景：标准化用户情景的模板。 编写良好的用户情景应遵循 INVEST 方法：
- I–Independent（独立）：每个用户情景应该独立于其他用户情景，允许团队按照小幅渐进式步骤交付。
- N–Negotiable（可协商）：用户情景都是可协商的，可以讨论和更改。
- V–有价值：用户故事应该为客户提供价值。
- E–Estimable（可估计）：用户情景应该是可估计的，并且有一个清晰的完成定义。
- S–Small（小）：用户情景应该很小，并且集中在一个功能上。
- T–Testable（可测试）：用户情景应该是可测试的，并且有明确的验收标准。
验收标准：标准化验收标准的模板。 确保验收标准与用户情景特别相关，并且可以使用一个或多个验收测试明确证明。
追溯：确保开发过程可追溯。 应清楚地跟踪生产工作负荷的状态和相关代码，并将其追溯到质量保证测试、验收标准、用户情景和功能。 在某些情况下，详细跟踪也可能是一项法规要求，例如 healthcare。
审查：通过开发周期回顾和事后分析，定期对您的开发实践进行内部审计。 过程反思应该无责备，并应专注于可以作为改进应用的学习。 确保团队反映用户情景和任务在定义必要任务方面的有效性以及时间估计的准确性。
报告：为利益相关者标准化报告，这些报告提供专注于变更的有用指标。 通过专注于更改，可以跟踪产品加速和减速。 有用的指标可以包括以下内容中的更改：
- 采用的每月增长率
- 绩效
- 训练时间
- 事件的频率
报告不应用作评估个人工作的工具，因此请避免为每个工程师使用故事点或代码行等指标。
Power Platform 简化
Although 没有 Power Platform 直接促进此推荐的产品，您可以使用堆栈中的其他 Microsoft 工具。 Azure Boards 是一项基于 Web 的服务，使团队能够在整个开发过程中规划、跟踪和讨论工作。
GitHub Projects 是一个可自定义的项目管理工具，用于组织项目，并与 GitHub 中的问题和拉取请求集成。