ソフトウェア開発管理慣行を形式化するための推奨事項
この Power Platform Well-Architected オペレーショナル エクセレンス チェックリストの推奨事項に適用されます:
| OE:03 | 確立された業界および組織の標準を参考にして、ソフトウェアのアイデア創出と計画のプロセスを正式化します。 共通の優先順位付けされたバックログと十分に詳細な仕様を使用します。 結果に基づいて、計画プロセスの継続的な改善を推進します。 |
|---|
このガイドでは、確立された標準に従ってワークロード開発プラクティスを管理するための推奨事項について説明します。 チームが高品質のソフトウェアを生み出す能力は、開発計画に対する構造化された共同アプローチに依存します。 ワークロード チームは、完了 で実行されている作業を理解し、関係者に明確に伝える必要があります。 より正確に言えば、ワークロード チームは、開発サイクルで 完了 する作業を明確に把握し、すべての関係者がその作業の「理由」について一致していることを確認する必要があります。 確立された標準により、開発プラクティスの実行方法が定義され、ワークロード チームが効果的に共同作業できるようになり、目標と期待に関する混乱のリスクが軽減されます。
主要な設計戦略
ワークロード開発のプラクティスを形式化して、目標と期待についての共通理解を確保します。
ローコード ワークロードを低複雑度として扱わないでください。 ローコード ワークロードの開発と管理を形式化することで、依然としてメリットが得られます。 他のソフトウェア開発チームから学びましょう。 ワークロードの複雑さと重要度に基づいて必要な形式化のレベルを指示する意思決定マトリックスを用意します。
開発計画の標準
次の標準は、包括的な開発計画戦略を設計するのに役立ちます。
優先順位付け: 作業の順序と範囲を計画するには、ワークロード機能がビジネスに与える真の影響と価値を理解する必要があります。 また、他の作業要求や製品またはプログラムの全体的なロードマップに対する影響の評価も含まれます。 ワークロードに優先順位を付ける 1 つの方法は、ワークロード全体の ビジネス価値を評価 することです。 また、ビジネス価値のために個々のワークロード機能を評価することも役立つ場合があります。
分類: 重要なアプリケーションをサポートするために必要なガードレールが確実に備えられるようにするプロセスを確立します。 同時に、厳密なプロセスが多すぎるために生産性のシナリオが遅くなったり阻害されたりしないようにします。
コラボレーション: ワークロードに対する提案された変更を定義するプロセスは、共同作業である必要があります。 ワークロードに対するほとんどの変更は複数の機能とコンポーネントに影響するため、できるだけ多くのワークロード チーム メンバーを関与させることで、重要な考慮事項が見落とされることがなくなり、全員が自分のドメインへの影響を認識できるようになります。 コラボレーションは、変更の範囲を明確に定義し、必要なタスクを明確に定義された作業項目に分割する方法を定義するのにも役立ちます。 さまざまな分野の専門知識を持つ大規模なグループであれば、必要な作業について経験に基づいた見積もりを提供できます。
トレードオフ: アジャイルな方法論は、規範的すぎると、厳しすぎになりがちです。 明確に定義された標準と革新のバランスをとるように努めてください。
デプロイメント: 大規模で頻度の低いデプロイメントではなく、小規模で反復的なデプロイメントを頻繁に使用するように計画します。
条件: テスト、ドキュメント、アクセシビリティ機能などのサポート機能が確実に完了するように、完了 開発サイクルの定義を標準化します。
通信: 製品所有者とプロジェクト マネージャーが今後のリリースを宣伝するための標準プロトコルを定義します。
ユーザーストーリー: ユーザーストーリーのテンプレートを標準化します。 適切に書かれたユーザー ストーリーは、INVEST アプローチに従う必要があります。
- I – 独立性: 各ユーザー ストーリーは他のユーザー ストーリーから独立している必要があり、チームが小さな段階的なステップで提供できるようにします。
- N – 交渉可能: ユーザー ストーリーは交渉可能で、議論や変更に対してオープンである必要があります。
- V – 価値: ユーザーストーリーは顧客に価値を提供する必要があります。
- E – 見積可能: ユーザー ストーリーは見積可能であり、完了の定義が明確である必要があります。
- S–小さい: ユーザー ストーリーは小規模であり、単一の機能に焦点を当てている必要があります。
- T – テスト可能: ユーザー ストーリーはテスト可能で、明確な受け入れ基準を持つ必要があります。
受け入れ基準: 受け入れ基準のテンプレートを標準化します。 受け入れ基準が特にユーザー ストーリーに関連しており、1つ以上の受け入れテストを使用して明確に証明できることを確認します。
トレース: 開発プロセスが追跡可能であることを確認します。 運用ワークロードの状態と関連コードを、品質保証テスト、承認基準、ユーザー ストーリー、機能にまで明確に追跡する必要があります。 医療などの場合には、詳細な追跡が規制上の要件となる場合もあります。
レビュー: 開発サイクルの振り返りと事後検証を通じて、開発プラクティスの内部監査を定期的に実行します。 プロセスの振り返りは非難されるべきではなく、改善として適用できる学習に焦点を当てる必要があります。 必要なタスクを定義する際にユーザー ストーリーとタスクがどれだけ効果的であったか、また時間見積りの正確さについてチームが確実に反映されるようにします。
レポート: 変更に焦点を当てた有用な指標を提供する関係者向けのレポートを標準化します。 変化に焦点を当てることで、製品の加速と減速を追跡できます。 役立つ指標には、次のような変化が含まれます。
- 採用の月間成長率
- 実績
- トレーニング時間
- インシデントの頻度
レポートは個人の仕事を評価するツールとして使用すべきではないため、各エンジニアのストーリー ポイントやコード行などの指標は避けてください。
Power Platform の促進
この推奨事項を直接実現する Power Platform 製品はありませんが、Microsoft Stack 内の他のツールを使用できます。 Azure Boards は、チームが開発プロセス全体にわたって作業を計画、追跡、および議論できるようにする Web ベースのサービスです。
GitHub プロジェクト は、プロジェクトを整理するためのカスタマイズ可能なプロジェクト管理ツールであり、GitHub の問題やプル リクエストと統合されます。