共同開發治理

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

定義端對端流程

您可以使用下列流程做為範例，並將其自訂為組織的最佳做法。 只要能達到所需的結果，不需要完成每一個步驟。

將功能新增至待處理項目

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

將新功能新增至待處理項目時，目標是描述一般範圍。 每個功能隨後會定義業務價值、草稿情景標題、範圍和資料模型變更，來推動程式碼開發工作。

此外，在新增業務關鍵型功能時，建議您找出可讓測試自動化的任何重要情境。 新增功能之後，您可以排程「範圍協調會議」。

範圍協調會議

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

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

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

下圖顯示新增至待處理項目的使用者劇本範例。

此時，依工作流程和應用程式組織工作來維護品質至關重要。 這種方法可協助將相關工作項目集中在一起，並讓每個工作流程的專家可以開發和維護每個應用程式中的功能和資料使用方式。

體驗檢閱

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

新增劇本詳細資料

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

1. 標題：身為<persona>，我可以<do something>來<impact/priority/value>
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 保持一致。
• 錯誤 – 誰可以通知、指派嚴重性等級、分類、偵測後執行動作，以及負責解決和簽核的人員。
• 升級 – 升級等級、員工指派等級、每個等級的職責、每個等級的通訊群組清單等。

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

提供應用程式支援

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

1. 鼓勵更優質的開發，因為建立應用程式的人員知道他們必須支援它。
2. 建立者能夠比第三方團隊更快地發現和修復錯誤，這只是因為他們更了解應用程式。
3. 將潛在工作關鍵轉體的修復工作委派給另一個團隊可能會使該團隊士氣低落且耗時。 與其他的應用程式建立、開發和部署階段一樣，融合團隊應在需要時與 IT 合作尋求幫助。

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

支援工作的最後一部分是監視和評估部署應用程式的滿意度和可用性。 在此使用計量會很有用，還有更傳統的方法，如民意調查和問卷調查。 如需監視應用程式使用方式的詳細資訊，請參閱 Power Apps 的管理員分析。

最後，如果使用者沒有使用發行的應用程式，則該應用程式就沒有達到它的目標。 定期檢閱會議可檢查這些滿意度和可用性指標，以建立積極的意見反應迴圈，來變更劇本或將劇本新增至待處理項目，以產生並部署更新的應用程式版本。

總結

無程式碼和低程式碼工具 (例如 Power Apps) 的開發擴大了業務技術人員或製作者建立、開發和部署應用程式的選擇。 這種開發在融合團隊環境中效果最好，包含產品負責人、網域專家、專業開發人員和管理員，此團隊可以根據需要引入其他資源。

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