継続的改善

継続的改善は、「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」というアジャイル マニフェストの原則の 1 つに強く結びついています。達成すべき改善点は、次の 2 つの領域に分けられます。

• 開発中のソフトウェアの改善。

  次の情報源は、ソフトウェアの改善にフォーカスするために役立ちます。

  • テストの失敗。コードの特定の部分が定期的にテストの失敗を引き起こす場合、コードのその部分を再設計する余地があるかもしれません。テストの失敗は、モダン アプリケーション開発プロセスの継続的インテグレーションと継続的配信プロセス、および継続的配信プロセスで行われた受け入れテストによって行われた単体テストおよび統合テストによって示されます。
  • コード カバレッジ。Enterprise Developer のコード カバレッジ機能は、テストの一部として実行されていないすべてのコード領域を強調表示し、テストを更新してすべてのコード行が完全にテストされるようにします。
  • 顧客フィートバック。ソフトウェアに関する顧客からのフィードバックは、アジャイル開発プロセスの要件収集手順に取り込み、評価した上で、必要に応じて迅速に変更を加えることができます。アジャイル開発の、プロセスを素早く反復させる性質により、加えた変更を迅速に顧客に提供できます。
• ソフトウェア開発プロセスの改善。

  アジャイル開発プロセスの一部であるスプリントの振り返りは、チームがこの議論をするための便利な機会の 1 つです。スプリントの振り返りで何を議論するかを決める既定フォーマットはありませんが、一般的に次の質問のバリエーションがあります。

  • うまくいった点は何か?
  • うまくいかなかった点は何か?

  これらの質問の範囲はコーディング作業に限定されず、要件収集からリリースまでの開発プロセス全体が対象となります。オペレーションでうまくいかなかったと思われる点については、解決策を議論して、今後のスプリント用に変更を実装できます。大幅な変更が必要な場合は、Micro Focus Atlas などのツールを使用して、他の要件と同じ方法で対応できます。

  スプリントは非常に短く、通常は 2 週間程度であるため、プロセスに加える変更は迅速に実行されます。その後のスプリントの振り返りでは、加えた変更により期待した効果が得られたかどうか、またはさらに変更が必要かどうかを議論できます。