規範軟體開發管理做法的建議
適用於此 Power Platform Well-Architected 卓越運營清單建議：
| OE：03 | 根據既定的產業和組織標準，將軟體構思和規劃流程規範化。 使用通用、按優先順序排列的積壓工作和足夠詳細的規範。 根據結果推動規劃流程的持續改進。 |
|---|
本指南描述了根據既定標準管理工作負載開發實務的建議。 您的團隊生產高品質軟體的能力取決於結構化的協作式開發規劃方法。 工作負載團隊應瞭解並向利益相關者清楚地傳達正在完成的工作。 更準確地說，工作負載團隊應該清楚地了解開發週期中要完成的工作，並確保所有利益相關者都對該工作的「原因」達成一致。 既定標準定義如何執行開發實踐，並允許工作負載團隊有效協作，從而減少目標和期望混淆的風險。
關鍵設計原則
規範化您的工作負載開發實踐，以幫助確保對目標和期望達成共識。
不要將低程式碼工作負載視為低複雜性工作負載。 您仍然可以從正式化低程式碼工作負載的開發和管理中受益。 向其他軟體開發團隊學習。 制定一個決策矩陣，根據工作負載的複雜性和關鍵性規定所需的正式化級別。
發展規劃標準
以下標準可以幫助您設計全面的發展規劃策略。
優先順序：規劃工作的順序和範圍涉及瞭解工作負載功能對業務的真正影響和價值。 它還包括評估這些對其他工作要求的影響以及產品或計劃的整體路線圖。 一種確定工作負載優先順序的方法是評估整個工作負載的商務價值。 您可能還會發現評估各個工作負載功能的商務價值很有用。
分類：建立流程，確保關鍵應用程式具有必要的護欄來支持它們。 同時，確保生產力方案不會因過多的嚴格流程而減慢或扼殺。
協作：定義對工作負載的擬議更改的過程應是一項協作工作。 對工作負載的大多數更改都會影響多個功能和元件，因此讓盡可能多的工作負載團隊成員參與有助於確保不會錯過重要的注意事項，並且每個人都知道對其特定域的影響。 協作還有助於明確定義更改的範圍以及如何將必要的任務劃分為定義明確的工作項。 具有跨領域專業知識的更大團隊能夠為所需的工作提供經驗支援的估算。
權衡：如果敏捷方法過於規範，它可能會變得過於嚴格。 努力在明確定義的標準和創新之間取得平衡。
部署：計劃使用頻繁的小型反覆運算部署，而不是使用大型、不頻繁的部署。
術語：標準化已完成 開發週期的 定義，以幫助確保成功完成支援功能，包括測試、文檔和輔助功能。
通信：為產品擁有者和專案經理定義標準協定，以升階即將發佈的版本。
使用者情景：標準化使用者情景的範本。 寫得好的使用者故事應該遵循 INVEST 方法：
- I–獨立 (Independent)：每個使用者故事都應該獨立於其他故事，允許團隊以小的增量步驟交付。
- N-可協商 (Negotiable)：使用者故事應該是可協商的，並且可以討論和更改。
- V–有價值：使用者故事應該為客戶提供價值。
- E-可估計 (Estimable)：使用者故事應該是可估計的，並且對完成有一個明確的定義。
- S–小 (Small)：使用者故事應該很小，並且專注於單一功能。
- T-可測試 (Testable)：使用者故事應該是可測試的，並具有明確的驗收標準。
驗收標準：標準化驗收標準的範本。 確保驗收標準與使用者故事具體相關，並且可以使用一個或多個驗收測試明確證明。
追溯：確保開發過程可追溯。 您應該清楚地追蹤生產工作負載的狀態以及相關程式碼，直到品質保證測試、驗收標準、使用者故事和功能。 在某些情況下，詳細跟蹤也可能是一項法規要求，例如醫療保健。
審查：通過開發週期回顧和事後分析，定期對您的開發實踐進行內部審計。 過程反思的重點不在於究責，而是著重於學習如何改善。 確保團隊反思使用者故事和工作在定義必要工作方面的效果，以及時間估計的準確性。
報告：為利益相關者標準化報告，這些報告提供專注於變更的有用指標。 專注於變化可以讓您追蹤產品的加速和減速表現。 有用的指標包括以下方面的變化：
- 採用率的月增長率
- 績效
- 訓練時間
- 事件發生頻率
報告不應用作評估個人工作的工具，因此請避免使用每個工程師的故事點或程式碼行等指標。
Power Platform 簡易化
雖然沒有 Power Platform 直接促進此建議的產品，但您可以使用堆疊中的其他 Microsoft 工具。 Azure Boards 是一項基於 Web 的服務，使團隊能夠在整個開發過程中規劃、跟蹤和討論工作。
GitHub Projects 是一個可自定義的專案管理工具，用於組織專案，並與 GitHub 中的問題和拉取請求集成。