共同開發治理

建立有效的共同開發治理框架是確保創客定義專案和融合團隊的一致性和可重複性的重要一環。 本文說明定義治理流程圖的方法。

定義端對端程序

您可以使用下列程序作為範例，並根據組織的最佳實務進行自訂。 沒有必要完成每個步驟，只要您達到所需的結果即可。

將功能新增至待辦專案

待處理項目可讓您透過新增推動整體體驗的功能，來規劃您的專案。 待辦清單也提供團隊計劃交付的整體路線圖。

將新功能新增至待辦專案時，目標是描述一般範圍。 然後，每個功能都會定義商業價值、草稿故事標題、範圍和資料模型變更，以推動程式碼開發工作。

此外，新增業務關鍵功能時，建議您識別任何關鍵案例以自動化測試。 新增功能之後，您可以安排範圍協調會議。

範圍對齊會議

此會議的重點應該限於檢閱每個建議的新功能，然後檢查任何已提供此功能的現有應用程式、案例或資料模型，以避免重複工作。 這次會議也提供了討論對其他應用程式的影響的機會。 最後，您應該檢查此功能是否需要體驗檢閱。

將劇本和腳本新增至待處理項目

在範圍對齊會議之後，可以在功能下新增任何使用者故事草稿標題。 此時，不需要詳細數據，而且使用者劇本的狀態為「新增」。 您可以在待處理項目或主板檢視中查看劇本。

下圖顯示新增至待辦清單的範例使用者故事。

此時，透過按工作流程和應用程式組織工作來維持品質至關重要。 此方法有助於將相關的工作專案保持在一起，並使每個工作流中的專家能夠開發並保持對每個應用程式內功能和資料使用情況的深入瞭解。

體驗回顧

體驗檢閱應著重於使用者體驗，並確保您的團隊遵循組織最佳實務。 這種一致性可確保您的所有應用程式都能為最終使用者和支援團隊提供可靠且可重複的體驗。

新增故事詳細資料

新增典型使用者劇本可能會包含下列資訊：

1. 標題：作為一個 <角色>，我可以 <做一些事情> 來產生 <影響/優先級/價值>
2. 描述：描述包括 （儘管不限於） 某些關鍵詳細資料，例如：
   • 總結預期結果的案例簡要描述
   • 敘述 - 描述使用者瀏覽和完成情境所需執行的動作
   • 替代敘述 - 描述使用者可以完成相同結果的其他方式
   • 設計註釋 – 記錄與使用者劇本相關聯的實體、欄位、檢視、模型畫面和商務規則
   • 受影響的安全性角色 - 列出所有受影響或與使用者劇本相關的安全性角色。

新增所有這些詳細資料之後，您會將使用者劇本的狀態變更為「準備審查」。 在大多數情況下，功能團隊和業務團隊（如果適用）會檢閱使用者劇本。

故事回顧

故事評論通常在融合團隊內進行，以確保故事中的所有細節都被調出並且沒有歧義。 完成所有檢閱之後，建議將使用者劇本指派給小組成員。 確保您的團隊在開發過程中保持一致對於實現您的整體目標至關重要。

新增任務和測試案例

在審閱故事後，團隊成員會在 Azure DevOps 中建立工作項目。 新增任務和測試案例的整體流程如下：

1. 打開短期衝刺待處理項目。 或者，建立新的短期衝刺。
2. 將現有的工作項目新增至短期衝刺。 如果您已新增未出現在短衝中的工作專案，則應該檢查其區域和反覆路徑。 請務必將所有非上層工作指派至相關工作項目。
3. 將工作新增至待辦專案。 如果您沒有指派給短期衝刺的待辦專案，請立即執行此動作。 此外，請設定衝刺開始和結束日期。
4. 填寫任務表單。 根據經驗，任務完成時間不應超過一天。 應細分大於此時間範圍的工作。
5. 追蹤或整合任何非上層工作。 您可以像其他工作一樣追蹤非上層工作，或者將它們拖曳至現有的待處理項目中，以將其設為上層工作。

新增任務和測試案例後，您即可設定短跑容量。

如需新增工作的詳細資訊，請參閱 將工作新增至待辦專案 以支援短期衝刺規劃。

準備解決方案

成功共同開發的一個重要方面是結構化的發布管理流程。 解決方案是實作 應用程式生命週期管理 （ALM） 的機制;您可以使用解決方案，透過匯出和匯入活動在環境中散佈元件。 元件表示在您的應用程式中使用的成品和您可以自訂的項目。 解決方案中可以包含的任何內容都是元件，例如資料表、資料行、畫布和模型導向應用程式、Power Automate 流程、聊天機器人、圖表和外掛程式。

部署

元件的完成可能需要多個衝刺週期，這取決於其複雜性和團隊的工作速度。 隨著工作完成，元件應該新增到開發環境中的解決方案中。 然後，解決方案在測試後匯入生產環境。 建議您也維護一個測試環境，以執行端對端測試，並在進入生產環境之前試用解決方案部署。

Power Platform 環境

環境 是儲存、管理和共用組織商務資料、應用程式和商務程式的空間。 它們也充當不同應用程式的容器，這些應用程式可能有不同角色、安全性需求或目標對象。

如果您的組織具有多小組融合設定，其中每個小組都在開發自己的解決方案，則協調衝刺和發行的持續時間非常重要。 短期衝刺的長度不必與專案時間表維持一致的長度，並且可以根據每個團隊的偏好在團隊之間改變期間。 不過，發行節奏不能小於所有團隊的最短衝刺期間。

源碼管理

請考慮採用原始程式碼控制系統，例如 Azure DevOps。 Azure DevOps 提供開發人員服務，協助支援團隊規劃工作、協作程式開發，以及建立與部署應用程式。

從您的開發環境匯出解決方案，其中包含您的應用程式和自訂、打開您的解決方案，並將元件儲存在原始控制系統中。

進階主題：提取要求 (PR) 檢閱

您應該只為處於使用中狀態且功能已通過檢閱和核准的情景建立 PR。 您應該確保解決方案版本設定準確，並遵循在 Azure Boards 中實作小組的 Scrum 做法中所載的衝刺和開發指南。 PR 的測試結果可以是描述所建置功能的螢幕擷取畫面或影片。

自動化 PR 治理流程有助於確保程式碼質量，而無需手動審查基本檢查，例如解決方案版本。

範本和標準化

範本和標準化有助於促進團隊內部的一致性，從而提高效率。 小組作業的所有層面，無論是上線工作、劇本檢閱簡報，或是 工作專案範本 ，可協助節省時間，並在定義使用者劇本、功能、錯誤或工作時為小組提供指引，都受益於標準化和簡化。

實施有效的支援模式

有效的支援模型對於應用程式在部署後的長期成功至關重要，如先前有關產生支援矩陣的一節中強調的那樣。 錯誤和中斷是不可避免的，因此團隊必須採用結構化的方法來處理這些事件，並且支援矩陣提供了必要的框架。

建立服務等級協定

任何支援模型的關鍵因素是服務等級協定 （SLA） 的定義。 SLA 應該是團隊起草的正式文件，其中包含涵蓋以下項目的部分：

• 中斷 — 可接受的服務中斷層級、通知誰、採取哪些動作、確認服務恢復，以及防止重複的動作。 團隊使用的任何自動化測試程序都需要與預期的中斷容錯和適用的 SLA 保持一致。
• Bugs – 誰可以通知、嚴重性層級的指派、分類、偵測後的處理，以及誰負責解決與簽核。
• 升級處理 – 升級層級、將人員分派至不同層級、每個層級的職責、每個層級的分發清單等等。

SLA 應儲存在團隊的文件入口網站中，並視需要進行更新。

提供應用程式支援

提供 SLA 中指定的應用程式支援的最佳方法是讓建立解決方案的小組也負責支援它。 該系統的優點是：

1. 它鼓勵更好的開發質量，因為創建該應用程序的人知道他們必須支持它。
2. 創建者將能夠比第三方團隊更快地發現和修復錯誤，僅僅是因為他們更了解該應用程序。
3. 將潛在關鍵任務軟體的修復委託給另一個群體可能會讓該群體士氣低落且耗時。 與應用程式建立、開發和部署的其他階段一樣，融合團隊應在需要時與 IT 合作尋求協助。

監控應用程式滿意度和可用性

支援工作的最後一部分是監控和評估已部署應用程式的滿意度和可用性。 指標以及更傳統的方法（例如民意調查和問卷調查）在這裡都很有用。 如需有關監控應用程式使用情況的詳細資訊，請參閱 Power Apps 的管理員分析。

最終，如果客戶沒有使用已發佈的應用程式，則該應用程式無法實現其目的。 定期審查會議可以檢查這些滿意度和可用性指標，以創建一個積極的反饋循環，可以更改或將故事添加到待辦事項中，以生成並部署應用程序的更新版本。

總結

Power Apps 等無程式碼和低程式碼工具的開發，為商務技術人員或製作者提供了建立、開發和部署應用程式的選項。 此開發在融合團隊環境中效果最佳，該環境由產品負責人、領域專家、專業開發人員和管理員組成，該團隊會根據需要引入其他資源。

在融合團隊中整合敏捷和 Scrum 開發方法可以實現更快速的應用程式開發，並透過對業務產生重大影響的功能集實現更高的成功部署機率。 透過套用這些最佳做法、指導方針和建議，您的融合團隊將能夠使用 Power Apps 來解決組織的數位轉型挑戰。