共同開発ガバナンス

効果的な共同開発ガバナンスの枠組みを確立することは、メーカー定義のプロジェクトや Fusion Teams において一貫性と再現性を確保するために重要な役割を果たします。 この記事では、ガバナンス フロー チャートを定義するためのアプローチについて説明します。

エンド ツー エンド プロセスの定義

以下のプロセスを例として、組織のベスト プラクティスに合わせてカスタマイズすることができます。 必要な結果が得られる限り、すべてのステップを完了する必要はありません。

バックログに機能を追加する

バックログを活用することで、全体的なエクスペリエンスを促進する機能を追加してプロジェクトを計画することができます。 バックログは、チームが提供する予定の全体的なロードマップも提供します。

バックログに新機能を追加する場合、その目的は一般的なスコープを記述することです。 そして、各機能は、ビジネス価値、ドラフト ストーリーのタイトル、スコープ、データモデルの変更を定義し、コード開発作業を推進します。

また、ビジネス クリティカルな機能を追加する場合、重要なシナリオを特定して、テストを自動化することが推奨されます。 機能の追加後は、スコープ調整会議のスケジュールを設定できます。

スコープ調整会議

この会議の焦点は、提案された新機能を一つ一つ確認し、その機能をすでに提供している既存のアプリ、シナリオ、データモデルがないかどうかを確認し、重複を避けることに限定する必要があります。 また、このミーティングでは、他のアプリへの影響についても議論する機会も提供します。 最後に、この機能にはエクスペリエンス レビューが必要かどうかを確認する必要があります。

ストーリーとストーリー ボードをバックログに追加する

スコープ調整会議の後、ユーザー ストーリーのドラフト タイトルを機能の下に追加することができます。 この時点では、詳細は必要なく、ユーザーストーリーのステータスは「新規」となっています。 ストーリーは、バックログ ビューまたはボードビューのいずれかで表示できます。

次の図は、バックログに追加されたユーザーストーリーの例です。

このとき、作業の流れや用途ごとに仕事を整理して、品質を保つことが重要です。 このアプローチにより、関連する作業項目をまとめ、各ワークストリームの専門家が各アプリの機能とデータ使用について深く理解し、維持できるようになります。

エクスペリエンス レビュー

エクスペリエンス レビューでは、エンドユーザー エクスペリエンスに焦点を当て、チームが組織のベストプラクティスに従っていることを確認する必要があります。 この一貫性により、すべてのアプリがエンドユーザーとサポートチームに信頼性と再現性のあるエクスペリエンスを提供できるようになります。

ストーリーの詳細を追加する

一般的なユーザーストーリーを追加すると、次の情報が組み込まれる場合があります:

1. タイトル: <persona> は、<do something> することができ、これによって <impact/priority/value> を達成できます
2. 説明: 説明には、以下のような特定の重要な内容が含まれます (ただし、これらに限定されません):
   • 望ましい結果を要約したシナリオの簡単な説明
   • ナラティブ - シナリオをナビゲートし、達成するためにユーザーが取るべき行動を記述します
   • 代替シナリオ - ユーザーが同じ結果を達成できる他の方法を説明します
   • デザインノート - ユーザーストーリーに関連するエンティティ、フィールド、ビュー、モックアップ画面、ビジネスルールを記録します
   • 影響を受けるセキュリティロール - 影響を受ける、またはユーザー ストーリーに関連するすべてのセキュリティ ロールを一覧表示します。

これらすべての詳細を追加した後、ユーザー ストーリーの状態を「レビューの準備ができました」に変更します。 ほとんどの場合、機能チームとビジネス チーム (該当する場合) がユーザーストーリーをレビューします。

ストーリー レビュー

ストーリー レビューは通常、Fusion Teams 内で行われ、ストーリー内ですべての詳細が呼び出され、あいまいさがないことを確認します。 すべてのレビューの完了後は、ユーザー ストーリーをチームメンバーに割り当てることをお勧めします。 開発プロセス中にチームの連携を維持することは、全体的な目標を達成するために不可欠です。

タスクとテスト ケースを追加する

ストーリーを確認した後、チーム メンバーはでタスクを作成しますAzure DevOps。 タスクとテスト ケースを追加するための全体的なプロセスは次のとおりです:

1. スプリント バックログを開きます。 または、新しいスプリントを作成します。
2. 既存の作業項目をスプリントに追加します。 もし、スプリントに登場しない作業項目を既に追加している場合は、そのエリアと反復パスを確認する必要があります。 親のないタスクは関連する作業項目に必ず割り当ててください。
3. バックログ アイテムにタスクを追加します。 スプリントにバックログ アイテムが割り当てられていない場合は、今すぐ実行してください。 また、スプリントの開始日と終了日を設定します。
4. タスク フォームに入力します。 目安としては、1 日以内に完了するタスクが望ましいです。 このタイムスケールよりも大きなタスクは、分解する必要があります。
5. 親のないタスクを追跡、または統合します。 親のないタスクを他のタスクと同じように追跡したり、既存のバックログアイテムにドラッグして親にすることができます。

タスクとテストケースを追加した後は、スプリントのキャパシティを設定します。

タスクの追加の詳細については、バックログにタスクを追加するの項目を参照して、スプリント計画をサポートします。

ソリューションの準備

共同開発を成功させるための重要な側面は、構造化されたリリース管理プロセスです。 ソリューション は アプリケーション ライフサイクル管理 (ALM) を実装するためのメカニズムです; ソリューションを使用して、エクスポートおよびインポートを通じてコンポーネントを環境全体に配布します。 コンポーネントは、アプリケーションで使用されているアーティファクトとカスタマイズできる可能性のあるものを示します。 ソリューションに含めることができるものはすべて、テーブル、列、キャンバス、モデル駆動型アプリ、Power Automate フロー、チャットボット、チャート、およびプラグインのようなコンポーネントです。

展開

複雑さとチームの速度によっては、コンポーネントが完了するまでに複数のスプリントが必要になる場合があります。 コンポーネントは、タスクが完了すると、開発環境のソリューションにに 追加 される必要があります。 ソリューションは、テスト後に運用環境にインポートされます。 また、1 つのテスト環境を維持してエンド ツー エンドのテストを実行し、運用環境に移行する前にソリューションの展開を試すことをお勧めします。

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 のようなノーコード、ローコード ツールの開発により、ビジネス技術者やメーカーがアプリケーションを作成、開発、展開する際の選択肢が広がりました。 この開発は、プロダクト オーナー、ドメイン エキスパート、プロ開発者、管理者で構成される Fusion Teams 環境で最も効果的に機能します。このチームは、必要に応じて他のリソースを導入します。

アジャイルとスクラムの開発アプローチの Fusion Teams は、より迅速なアプリ開発と、ビジネスに大きな変化をもたらす機能セットの導入の成功確率が高くなります。 これらのベスト プラクティス、ガイドライン、推奨事項を適用することで、Fusion Teams は Power Apps を使用して組織のデジタル変革の課題に取り組むことができるようになります。