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