アジャイル開発とは
アジャイル開発は、反復的なソフトウェア開発を説明するために使用される用語です。 反復的なソフトウェア開発では、通常スプリントと呼ばれる短い増分で作業を完了することで、DevOps ライフ サイクルを短縮します。 スプリントの長さは通常 1 ～ 4 週間です。 アジャイル開発は、大規模なプロジェクトを前もって計画し、計画に従って完了する従来の開発やウォーターフォール開発と対比されることがよくあります。
スプリントごとに本番品質のコードを提供するには、アジャイル開発チームがペースの加速を考慮する必要があります。 すべてのコード、テスト、および品質の検証は、スプリントごとに実行する必要があります。 チームが適切にセットアップされていない場合、結果は期待を下回る可能性があります。 こうした失望は素晴らしい学習の機会を提供しますが、始める前にいくつかの重要な教訓を学ぶことが役に立ちます。
この記事では、アジャイル開発チームの重要な成功要因をいくつか説明します。
- バックログの入念な改善
- 早期かつ頻繁に統合する
- 技術的負債を最小限に抑える
バックログの入念な改善
アジャイル開発チームは、ユーザー ストーリー と呼ばれることが多い要件のバックログに取り組んでいます。 バックログには優先順位が付けられ、最も重要なユーザー ストーリーが一番上に表示されます。 製品所有者はバックログを所有し、顧客のニーズに基づいてユーザー ストーリーを追加、変更、優先順位変更します。
アジャイル チームの生産性にとって足かせとなる最大の要因は、定義が不十分なバックログです。 要件が明確に定義されていない限り、チームがスプリントごとに高品質のソフトウェアを一貫して提供することは期待できません。
プロダクトオーナーの仕事は、すべてのスプリントで、エンジニアが作業するユーザー ストーリーを明確に定義していることを確認することです。 バックログの先頭にあるユーザー ストーリーは、チームがいつでも作業を開始できるように準備されている必要があります。 この概念はバックログのリファインメントと呼ばれます。 アジャイル開発チームがバックログを準備できるようにするには、努力と規律が必要です。 幸いなことに、投資する価値は十分にあります。
バックログを調整するときは、次の重要な考慮事項に留意してください。
ユーザー ストーリーの洗練は、多くの場合、長期間にわたる作業です。 エレガントなユーザー インターフェイス、美しい画面デザイン、顧客を満足させるソリューションはすべて、作成するのに時間とエネルギーがかかります。 勤勉なプロダクトオーナーは、2 ～ 3 スプリント前にユーザー ストーリーを洗練します。 これらには、設計の反復と顧客のレビューが考慮されます。 彼らは、すべてのユーザー ストーリーがアジャイル チームが誇りを持って顧客に提供できるものであることを保証するために取り組んでいます。
ユーザーストーリーは、チームがそう言わない限り洗練されません。 チームはユーザー ストーリーをレビューし、作業の準備が整っていることに同意する必要があります。 チームがスプリントの初日までユーザー ストーリーを確認しないと、問題が発生する可能性があります。
バックログのさらに下にあるユーザー ストーリーは曖昧なままになる可能性があります。 優先度の低い項目を洗練することに時間を無駄にしないでください。 バックログの一番上に注目してください。
早期かつ頻繁に統合
継続的インテグレーション と継続的デリバリー (CI/CD) は、アジャイル開発の速いペースに合わせてチームをセットアップします。 できるだけ早く、ビルド、テスト、デプロイメントのパイプラインを自動化します。 新しいプロジェクトを開始するときに、チームが最初に取り組むタスクの 1 つとして自動化を設定します。
自動化により、チームは時間がかかり、エラーが発生しやすく、時間のかかる手動の導入プロセスを回避できます。 チームはスプリントごとにリリースするため、これらのタスクを手動で行う時間はありません。
CI/CD はソフトウェア アーキテクチャにも影響します。 これにより、構築可能で展開可能なソフトウェアを確実に提供できます。 チームがデプロイが難しい機能を実装すると、ビルドとデプロイが失敗するとすぐに気づきます。 CI/CD では、チームは展開上の問題が発生したときに修正する必要があります。 これにより、製品はいつでも出荷できる状態になります。
効果的なアジャイル開発にとって非常に重要な主要な CI/CD アクティビティがいくつかあります。
単体テスト。 単体テストは人的エラーに対する最初の防御です。 単体テストはコーディングの一部であると考えてください。 コードを使用してテストをチェックインします。 単体テストをすべてのビルドの一部にします。 単体テストの失敗は、ビルドの失敗を意味します。
ビルドの自動化。 ビルド システムは、ビルドの実行時にソース管理から直接コードとテストを自動的にプルする必要があります。
ポリシーを分岐して構築します。 チームがコードを特定のブランチにチェックインするときに自動的にビルドするようにブランチとビルド ポリシーを構成します。
環境にデプロイする。 ビルドされたプロジェクトを運用環境を模倣した環境に自動的にデプロイするリリース パイプラインを設定します。
技術的負債を最小限に
個人の財務状況では、借金を掘り返すよりも借金をしないほうが簡単です。 同じルールが技術的負債にも当てはまります。 技術的負債には、以前に行ったショートカットのためにチームが対処しなければならないあらゆるものが含まれます。 たとえば、スケジュールが厳しい場合、期限を守るために品質を犠牲にする可能性があります。 技術的負債は、品質の不足を補うためにコードをリファクタリングする必要があるときに後で支払う代償です。 例には、不適切な設計、バグ、パフォーマンスの問題、運用上の問題、アクセシビリティの問題、その他の問題に対処するための修正が含まれます。
技術的負債を抱え続けるには勇気が必要です。 コードの手直しを遅らせるには多くのプレッシャーがあります。 借金を無視して機能に取り組むのは気分が良いです。 残念ながら、遅かれ早かれ誰かが技術的負債を返済しなければなりません。 金融負債と同様に、技術負債も存続期間が長くなるほど返済が難しくなります。 賢明なプロダクトオーナーはチームと協力して、スプリントごとに技術的負債を返済する時間を確保します。 技術的負債の削減と機能開発のバランスを取るのは難しい課題です。 幸いなことに、生産性が高く顧客重視のチームを作成するための簡単なテクニックがいくつかあります。
常にアジャイルであること
アジャイルであることは、経験から学び、継続的に改善することを意味します。 アジャイル開発では、プロセス ループが緊密であるため、従来のプロジェクト計画よりも多くの学習サイクルが提供されます。 各スプリントは、チームに何か新しいことを学ばせます。
次に例を示します。
- チームは顧客に価値を提供し、フィードバックを取得し、そのフィードバックに基づいてバックログを変更します。
- 彼らは、自動化されたビルドに重要なテストが欠けていることを知りました。 次のスプリントには、この問題に対処するための作業が含まれています。
- 特定の機能が実稼働環境でパフォーマンスが悪いことが判明したため、パフォーマンスを向上させる計画を立てます。
- チームの誰かが新しい練習方法について聞きました。 チームはそれを数回のスプリントで試してみることにしました。
アジャイル開発を始めたばかりのチームは、より多くの学習機会を期待する必要があります。 これらは成長と改善につながるため、プロセスの非常に貴重な部分です。
次のステップ
チームに適したアジャイル開発プロセスを決定するには、さまざまな方法があります。 Azure DevOps では、さまざまなプロセス テンプレートが提供されます。 計画に対して異なるベースライン構造を探しているチームは、これらのテンプレートを出発点として使用できます。 チームの文化と目標に最適なプロセス テンプレートの選択の詳細については、「Azure Boards で作業するプロセス フローまたはプロセス テンプレートを選択する」を参照してください。
組織が成長するにつれて、規律を保つことが困難になる場合があります。 アジャイルを大規模なチームに拡張するについて詳しくご覧ください。