ソフトウェア開発および管理の形式化に関する推奨事項
Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。
| OE:03 | ソフトウェアのアイディエーションと計画を一定の形式にします。 確立された業界と組織の標準を利用します。 共通の優先順位付けされたバックログと十分に詳細な仕様を使用します。 結果に基づいて、計画プロセスの継続的な改善を推進します。 |
|---|
このガイドでは、確立された標準に従ってソフトウェア開発プラクティスを管理するための推奨事項について説明します。 チームが高品質のソフトウェアを作成できるかどうかは、開発計画に対する構造化されたコラボレーション アプローチにかかっています。 製品所有者とマネージャーは、開発サイクルのどの時点でも開発者が行っている作業を明確に理解し、関係者に明確に説明できる必要があります。 逆に、開発者は、適切に記述された機能、ユーザーストーリー、受け入れ基準を通じて、開発サイクルの目標を理解する必要があります。 確立された標準により、開発プラクティスの実行方法が定義され、ワークロード チームが効果的に連携できるようになり、目標と期待について混乱するリスクが軽減されます。
主要な設計戦略
ソフトウェア開発プラクティスを形式化して、製品所有者、プロジェクト マネージャー、開発者が各スプリントの目標を理解し、関係者に一貫した品質を提供できるようにします。 開発プラクティスに関するガイダンスを確認するには、「継続的インテグレーション ガイド」を参照してください。
コラボレーションとコミュニケーションの標準を確立する
コラボレーション: ワークロードに対して提案された変更を定義するプロセスは、共同作業であるべきです。 ワークロードに対するほとんどの変更は複数の機能やコンポーネントに影響するため、できるだけ多くのワークロード チームのメンバーが関与することで、重要な考慮事項が見逃されず、全員が自分の特定のドメインへの影響を認識できるようになります。 また、コラボレーションは、変更の範囲と変更を達成するために必要なタスクを、適切に定義された作業項目に分割する方法を明確に定義するのにも役立ちます。これは、複数のドメインにわたる専門知識を持つ大規模なグループが、必要な作業について経験に基づいた見積もりを提供できるようになるからです。
コミュニケーション: 製品所有者とプロジェクト マネージャーが、今後のリリースを社内外にプロモーションするための標準プロトコルを定義します。 たとえば、今後のリリースについて外部関係者とコミュニケーションをとるための標準を確立できます。 この標準では、リリースの 2 週間前にコミュニケーションをとり、リリースの 24 時間前にリマインダーを送信する必要があると規定されているかもしれません。
レビュー: 開発サイクルの振り返りと事後分析を通じて、開発プラクティスの内部監査を定期的に実行します。 プロセスの振り返りでは、責任の所在を問われるべきではなく、改善として適用できる学習に注力する必要があります。 必要なタスクを定義する上で、ユーザー ストーリーとタスクがどれだけ効果的であったか、また時間の見積もりの正確さについて、チームが振り返るようにします。
レポート: 変化に焦点を当てた有用なメトリックを提供する、関係者向けのレポートを標準化します。 変化に焦点を当てることで、製品の加速と減速を追跡できるようになります。 有用なメトリックとしては、次のことに関する変化があります。
毎月の導入の増加率。
パフォーマンス。
トレーニング時間。
インシデントの頻度。
レポートは個人の作業を評価するためのツールとして使用すべきではありません。そのため、各エンジニアのストーリー ポイントやコード行などのメトリックは避けてください。
業界標準のツールを選択する
アジャイル、スクラム、かんばんボードなど、業界で実績のある確立されたツールとプロセスを使用します。 独自のツールとプロセスを開発するのは大変な作業であり、本来であればワークロードに費やせるはずの時間と開発サイクルを費やすことになります。 経験豊富な DevOps エンジニアや製品所有者のほとんどは、この種のツールとプロセスに精通しているため、それらを導入する際の学習曲線は最小限に抑えられるはずです。 同様に、新入社員のオンボーディング プロセスでも、新入社員はすでに同じツールとプロセスにある程度慣れている可能性が高いため、標準のツールとプロセスを使用することでメリットが得られます。
トレードオフ: アジャイル方式が規範的すぎると、厳格になりすぎる可能性があります。 明確に定義された標準とイノベーションのバランスをとるように努めてください。
エンド ユーザーのシナリオを把握するための標準を導入する
ユーザー ストーリー: ユーザー ストーリーのテンプレートを標準化します。 各ユーザー ストーリーが、エンド ユーザーの観点から記述された個別の作業単位であることを確認してください。 適切に記述されたユーザー ストーリーには、次のような特徴があります。
各ユーザー ストーリーは互いに完全に独立している必要があります。 ユーザー ストーリーを互いに独立させておくと、重複作業による混乱が回避され、特定のユーザー ストーリーの作業が他のユーザー ストーリーの作業に依存しているかどうかをチームが理解しやすくなります。これは、スケジュール設定と優先順位付けに役立ちます。
各ユーザー ストーリーは交渉可能です。 短期間で達成できる現実的なユーザー ストーリーを捉えるには、エンド ユーザーとワークロード チームのメンバーの両方の視点が不可欠です。
エンド ユーザーにとってユーザー ストーリーは重要なものです。 エンド ユーザーの視点からユーザー ストーリーを記述する際は、エンド ユーザーが知りたいと関心を持ち、エクスペリエンスに価値を加えるような変化を捉えます。 ユーザー ストーリーを作業項目に分割する際にこのフォーカスを維持しておくと、各デプロイにおいてエクスペリエンスが向上します。
ユーザー ストーリーに必要な作業量は、高い信頼性を持って見積もることができます。 特定のユーザー ストーリーに必要な時間を正確に把握できなければ、計画を立てるのが難しくなり、期限に間に合わなくなる可能性が高まり、計画されている他の作業に連鎖的な影響を及ぼす可能性があります。
適切に記述されたユーザー ストーリーは小さいため、数週間以内に完了できます。 スコープを小さくすることで、ストーリーは見積もりと管理がしやすくなります。また、作業項目を達成可能な状態に保つのに役立ちます。
ユーザー ストーリーはテスト可能である必要があります。 機能が提供されたことをテストできなければ、エンド ユーザーは目標が達成されたかどうか確信できません。 特定のユーザー ストーリーに対してテストがまだ作成されていない場合でも、機能が提供されたことを証明するためにテストを開発する方法を明確に理解する必要があります。
受け入れ基準: 受け入れ基準のテンプレートを標準化します。 受け入れ基準が具体的にユーザー ストーリーに関連しており、1 つ以上の受け入れテストを使用して明確に証明できることを確認します。
デプロイ プラクティスを標準化する
デプロイ: 頻度の低い大規模なデプロイではなく、頻度の高い小規模で反復的なデプロイを使用することを計画します。 このアプローチを使用すると、プロジェクト管理の観点からユーザー ストーリーと作業項目が管理しやすくなり、デプロイが失敗した場合の大規模な問題のリスクを軽減できます。
用語: "完了した" 開発サイクルの定義を標準化し、テスト、ドキュメント、アクセシビリティ機能などのサポート機能が正常に完了できるようにします。
トレース: 開発プロセスがトレース可能であることを確認します。 運用ワークロードの状態と関連コードを、品質保証テスト、受け入れ基準、ユーザー ストーリー、および機能にまで遡って明確にトレースする必要があります。 たとえば医療など、場合によっては詳細なトレースが規制要件となる場合もあります。
Azure ファシリテーション
Azure Boards は、チームが開発プロセス全体の作業を計画、追跡、および議論できるようにする Web ベースのサービスです。 これは、アジャイルベースの開発プラクティスに適しています。
GitHub プロジェクトは、GitHub の issue や pull request を使用してプロジェクトを整理し、統合できるカスタマイズ可能なプロジェクト管理ツールです。
関連リンク
コミュニティ リンク
オペレーショナル エクセレンス チェックリスト
レコメンデーションの完全なセットを参照してください。