開発標準を確立する
 開発プラクティスを標準化し、品質ゲートを適用し、体系的な変更管理を通じて進行状況と成功を追跡することで、生産性を最適化します。 |
|---|
開発チームには、リリース前のワークロードの問題に、摩擦を最小限に抑えて対処する責任があります。 開発者の効率性に留意して、コーディングからテスト結果までのターンアラウンド サイクルを速くするように最適化してください。 技術面の活動の計画を立てて標準化するとともにチーム内および利害関係者との合意を推進するために、効果的で適切なサイズのプロセスを実施します。
サンプル シナリオ
Contoso Ticketing は小さなスタートアップ企業であり、チケッティング基幹業務 (LOB) SAAS ソリューションを中規模企業向けに提供しています。 新しい顧客のオンボードは複雑なプロセスであり、顧客の環境と統合するために製品のカスタマイズとカスタム開発が必要になります。 実装チームは、Azure DevOps をコラボレーションとデリバリーのプラットフォームとして使用していますが、チームが従っている正式な開発方法論というものはありません。
開発の業界標準を採用する
業界標準のソフトウェア開発方法論のうち、自社のワークロードのニーズとチーム サイズに合わせて適切に調整されているものを使用します。 すべてのロール間で共有されるバックログを保守します。
よく知られている方法論を採用することによって、プロジェクトのリズムが作られます。 期待されていることと説明責任が明確にチーム メンバーに伝えられるので、プロセスのあいまいさがなくなります。
共通のリストに対して追跡することで、標準のプラクティスを使用してタスクの絞り込みと優先度付けを行うことができます。 プロジェクトを時間どおりに完了できる見込みが高くなります。
標準的な方法論は、リスク管理に役立ちます。 粒度の高いマイルストーン レビューによって、開発者は潜在的な問題がプロジェクトの進行を止めてしまう前に対処することができます。
Contoso の課題
- 同社の主力製品は人気を集めており、統合チームは現在、これまで以上に多くの実装プロジェクトの作業を同時に行っています。 ワークロードの増加に対応するために、チームは増員を必要としていました。
- このチームの拡大と、正式なプロセスの欠如が相まって、いくつかの課題が生じました。たとえば、チーム メンバー間のコミュニケーションが不明確である、会議が不定期で非生産的である、開発サイクルの頻度が低くスケジュールが設定されていないといったことです。 オンボード プロジェクトの多くが今では予定より遅れており、同社の上層部はチームに、この状況の修正に必要な変更を実施するよう要求しました。
アプローチの適用と結果
- これらの課題を克服するために、チームはソフトウェア開発によく利用されているアジャイル フレームワークの 1 つであるスクラム方法論を採用することにしました。
- スクラムは、このチームが直面している問題のいくつかへの対処に役立ちます。 スクラムの特徴の筆頭は、開発プロセスのための明確で一貫性のある構造であり、ロール、イベント、成果物、およびルールが事前定義されています。 1 つのバックログを共有することと、一連の短い開発スプリントから成るケイデンスを作ることは、チームが共通のビジョンに基づいて仕事を進めて顧客への価値を定期的かつ確実に届けるのに役立ちます。
テストのためにシフト レフトする
テストを重視する品質保証プロセスを、開発ライフサイクルの早い段階から用意します。 計画されたテスト手順のすべての成果物を含めます。これには、機能のリリースまたは更新の一部であるアプリケーション コンポーネント、インフラストラクチャ、データ プレーン操作が含まれます。
成果物は、ある環境から別の環境へと昇格されるときに不変として扱います。これで、品質ゲートを通過するたびに信頼が得られます。
可能であれば、定型的チェックを自動化します。
品質保証によって、機能要件と非機能要件が確実に満たされているという確信を持つことができ、このことは顧客へのプラスのインパクトにつながります。
Contoso の課題
- ワークロード チームの機能テスト戦略では、自動テストと手動テストの組み合わせが使用されます。 このチームのテスト アプローチでは、システムのすべての側面 (パフォーマンス、セキュリティ、使いやすさなど) がカバーされるわけではありません。 また、一貫した方法でコードをさまざまな環境に、完全自動化してデプロイするための手段がないため、変動性と不確実性が生じています。
- 顧客オンボード作業の量と複雑さが増した結果、チームのテスト戦略の課題がさらに大きくなり、頻繁なバグ、手直し、顧客の不満につながっています。
アプローチの適用と結果
- ワークロード チームは、テスト戦略を改善するため、およびデプロイ パイプラインの一貫性と予測可能性を高めるための取り組みに着手します。
- まず、開発中の機能またはカスタマイズのそれぞれについてテスト計画を作成し、機能要件と非機能要件の両方をこれでカバーします。 テスト ケース、テスト データ、テスト結果の管理には Azure DevOps を使用します。 デプロイ パイプラインの中に品質ゲートを設定します。これでコード、構成、デプロイの品質を検証してから、成果物を次の環境に昇格させます。
- チームがこれらの改善を実施した後は、デプロイ失敗の数が減少し、さらに実稼働でのバグやインシデントの数も減少しています。 その結果、品質、デリバリーのスピード、顧客満足度が大幅に向上しました。
開発効率を測定する
効率を測定するために、進捗状況と傾向を報告します。 開発プラクティスの改善を促進するために、バグ、失敗した更新、デプロイ所要時間、フィードバック ループの傾向を追跡して報告します。
Contoso の課題
- ワークロード チームは最近、顧客オンボード プロセスの品質と予測可能性を高めるために、さまざまな変更を実施しました。 しかし、同社はこれらの変更の影響を測定して報告するにあたって、ある課題に直面しています。 残念ながら、同社には品質と予測可能性がどれだけ向上したか、またはどの変更が他の変更よりも改善に貢献したかを示す、信頼性の高いデータやメトリックはありません。
- 同社のプロセス投資から得られた利益を定量化して伝達する方法が必要です。これで将来のリソースと取り組みの優先度付けができるようになるからです。
アプローチの適用と結果
- チームは、経時的な改善を定量化して将来の投資のためのリソース割り当ての優先度付けができるようにするために、既に使用している AzDO のレポート機能を活用することを決定します。
- 手始めとして、あらかじめ用意されている次のようなレポートを活用します。
- ベロシティ レポート
- 累積フロー図
- バグの傾向: 時間の経過とともにバグがどれだけ作成、解決、クローズされたか、およびこれらが品質メトリックにどのように影響しているか。
- デプロイ統計: コードから実稼働までのソフトウェアのデリバリーに要する時間と、これを目標値やベンチマークと比較した結果。
- チームは、ダッシュボードと Power BI Analytics レポートを使用してカスタマイズされたレポートの開発を近い将来に行うことも計画しています。