ソフトウェアの開発と管理を正式化するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework のオペレーショナル エクセレンス チェックリストの推奨事項に適用されます。

OE:03 ソフトウェアのアイデアと計画プロセスを形式化します。 確立された業界および組織の標準から引き出します。 一般的で優先順位付けされたバックログと十分に詳細な仕様を使用します。 結果に基づいて、計画プロセスの継続的な改善を推進します。

このガイドでは、確立された標準に従ってソフトウェア開発プラクティスを管理するための推奨事項について説明します。 高品質のソフトウェアを作成するチームの能力は、開発計画に対する構造化されたコラボレーションアプローチに依存しています。 製品の所有者とマネージャーは、開発者が開発サイクルでいつでも行っている作業を利害関係者に明確に理解し、明確に示すことができる必要があります。 逆に、開発者は、適切に記述された機能、ユーザー ストーリー、受け入れ基準を使用して、開発サイクルの目標を理解する必要があります。 確立された標準では、開発プラクティスを実行する方法を定義し、ワークロード チームが効果的に共同作業できるようにすることで、目標と期待に混乱を招くリスクを軽減します。

主要な設計戦略

ソフトウェア開発プラクティスを形式化して、製品所有者、プロジェクト マネージャー、開発者が各スプリントの目標を確実に理解し、利害関係者に一貫した品質を提供できるようにします。 開発プラクティスに関するガイダンスを確認するには、 継続的インテグレーション ガイドを参照してください。

開発計画の標準

  • コラボレーション: ワークロードに対して提案された変更を定義するプロセスは、共同作業である必要があります。 ワークロードに対するほとんどの変更は、複数の機能やコンポーネントに影響を与えるので、できるだけ多くのワークロード チーム メンバーが関与すると、重要な考慮事項が見逃されず、すべてのユーザーが特定のドメインへの影響を認識できるようになります。 また、コラボレーションは、変更の範囲と、変更を達成するために必要な必要なタスクを適切に定義された作業項目に分割する方法を明確に定義するのにも役立ちます。ドメイン間の専門知識を持つ大規模なグループは、必要な作業に関する経験に基づく見積もりを提供できます。

  • ツール: アジャイル、 スクラム、 かんばんボードなど、業界で実績のある確立されたツールとプロセスを使用します。 独自のツールとプロセスの開発は、ワークロードに費やされる可能性がある時間と開発サイクルを要する重要な作業です。 ほとんどの経験豊富な DevOps エンジニアと製品所有者は、これらの種類のツールとプロセスに精通しているため、それらを採用する学習曲線は最小限に抑える必要があります。 同様に、新入社員のオンボーディング プロセスは、既に同じツールやプロセスに対する露出度が高い可能性があるため、標準のツールとプロセスを使用するメリットもあります。

トレードオフ: アジャイル手法が過度に規範的な場合、厳格すぎる可能性があります。 明確に定義された標準とイノベーションのバランスを取る。

  • デプロイ: 大規模な頻度の低いデプロイではなく、頻繁に小規模で反復的なデプロイを使用することを計画します。 このアプローチを使用すると、プロジェクト管理の観点からユーザー ストーリーと作業項目を管理しやすくし、デプロイが失敗した場合の大規模な問題のリスクを軽減できます。

  • 用語: 完成した 開発サイクルの定義を標準化して、テスト、ドキュメント、アクセシビリティ機能などのサポート機能が正常に完了するようにします。

  • コミュニケーション: 製品所有者とプロジェクト マネージャーの標準プロトコルを定義して、今後のリリースを内部および外部で促進します。 たとえば、今後のリリースに関する外部関係者への通信に関する標準を確立できます。 標準では、リリースの 2 週間前に通信を送信し、リリースの 24 時間前にリマインダーを送信する必要があると規定されている場合があります。

  • ユーザー ストーリー: ユーザー ストーリーのテンプレートを標準化します。 各ユーザー ストーリーが、エンド ユーザーの観点から記述された個別の作業単位であることを確認します。 適切に記述されたユーザー ストーリーには、次の特性が必要です。

    • 各ユーザー ストーリーは、互いに完全に独立している必要があります。 ユーザー ストーリーを相互に独立させておくと、重複する作業との混乱を回避し、特定のユーザー ストーリーの作業が他のユーザーストーリーの作業に依存しているかどうかをチームが理解するのに役立ちます。これは、スケジュール設定と優先順位付けに役立ちます。

    • 各ユーザー ストーリーは交渉可能です。 エンド ユーザーとワークロード チーム メンバーの視点は、短時間で実現できる現実的なユーザー ストーリーをキャプチャするために不可欠です。

    • ユーザー ストーリーは、エンド ユーザーにとって重要です。 エンド ユーザーの観点からユーザー ストーリーを記述する場合は、表示に関心があり、エクスペリエンスに価値を追加する変更をキャプチャします。 ユーザー ストーリーを作業項目に分割してこのフォーカスを維持すると、各展開でエクスペリエンスが向上します。

    • ユーザー ストーリーに必要な作業は、高い信頼度で評価できます。 特定のユーザー ストーリーに必要な時間を厳密に近似できなければ、計画は困難になり、期限が見つからない可能性が高まり、他の計画作業に連鎖的な影響を与える可能性があります。

    • 適切に記述されたユーザー ストーリーは小さいため、数週間以内に完了できます。 規模の小さいストーリーは、評価可能で管理しやすいものにし、作業項目を達成可能に保つのに役立ちます。

    • ユーザー ストーリーはテスト可能である必要があります。 機能が提供されたことをテストできなければ、エンド ユーザーは目標が達成されたことを確信できません。 特定のユーザー ストーリーに対してテストがまだ記述されていない場合でも、機能の提供を証明するためにテストを開発する方法を明確に理解している必要があります。

  • 受け入れ基準: 受け入れ基準のテンプレートを標準化します。 受け入れ基準がユーザー ストーリーに特に関連し、1 つ以上の受け入れテストを使用して明確に証明できることを確認します。

  • トレース: 開発プロセスがトレース可能であることを確認します。 運用ワークロードの状態と関連するコードを、品質保証テスト、受け入れ基準、ユーザー ストーリー、および機能に明確にトレースする必要があります。 詳細なトレースは、たとえば医療などの場合に規制要件になる場合もあります。

  • レビュー: 開発サイクルの振り返りと事後分析を通じて、開発プラクティスの内部監査を定期的に実行します。 プロセスリフレクションは責任を負わず、改善として適用できる学習に焦点を当てる必要があります。 チームは、ユーザー ストーリーとタスクが必要なタスクを定義する際の効果と、時間の見積もりの精度を反映していることを確認します。

  • レポート: 変更に焦点を当てた有用なメトリックを提供する利害関係者向けのレポートを標準化します。 変更に重点を置くと、製品の加速と減速を追跡できます。 役に立つメトリックには、次の変更を含めることができます。

    • 導入の月次増加率。

    • パフォーマンス。

    • トレーニング時間。

    • インシデントの頻度。

    レポートは個人の作業を評価するツールとして使用しないでください。そのため、各エンジニアのストーリー ポイントやコード行などのメトリックは避けてください。

Azure ファシリテーション

Azure Boardsは、チームが開発プロセス全体で作業を計画、追跡、議論できるようにする Web ベースのサービスです。 これは、アジャイルベースの開発プラクティスに適しています。

GitHub Projects はカスタマイズ可能なプロジェクト管理ツールであり、GitHub で issue と pull request を使用してプロジェクトを整理し、統合できます。

オペレーショナル エクセレンス チェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナル エクセレンス チェックリスト