アジャイルの使用開始

学習の目的

この単元を完了すると、次のことができるようになります。

  • 従来のウォーターフォール型計画手法と比べたアジャイルプロジェクト管理の利点を要約する。
  • プロダクトオーナー (製品所有者) と開発チームが作業項目の優先順位付けと選択で果たす役割について説明する。
  • アジャイルプログラムが反復型の作業の整理、実行、構造化に使用するメカニズムについて説明する。

Salesforce と Atlassian は、このアジャイル開発トレイルでコラボレーションすることにワクワクしています。Salesforce と Atlassian は共に、企業の成功に対する確固たるコミットメントを掲げており、そうした成功を確実にするうえでアジャイル開発手法が果たす重要な役割を認識しています。

メモ

メモ

このモジュールは Atlassian との提携のもとに制作されています。ここに記載されている Atlassian の製品、サービス、機能は Atlassian が所有、サポート、管理します。Atlassian の製品、サービス、機能の使用は、Atlassian が管理するプライバシーポリシーやサービス契約に従うものとします。

アジャイルとは?

アジャイルプロジェクト管理は、ソフトウェア開発プロジェクト管理のための反復型アプローチで、イテレーション (反復) 単位での継続的リリースと顧客からのフィードバック収集に重点を置きます。

アジャイル開発のアーリーアダプター (初期採用層) は、小規模な自己完結型プロジェクトに取り組む小規模な自己完結型チームでした。彼らによってアジャイルモデルに効果があることが証明されると、世界中のソフトウェアメーカーは歓喜し、改善に利用しました。最近では、大規模な組織が、単一のチームやプロジェクトから規模を拡大してプログラム全体に適用する方法を模索しています。

ウォーターフォールとアジャイルの比較

まず、アジャイルの特長など、基本的な情報を確認しましょう。

ウォーターフォールのような従来のプロジェクト管理スタイルは、複数フェーズで構成されます。標準的なウォーターフォール型プロジェクトを示すグラフィック。このスタイルの製品開発では、すべてが 1 回の大規模なハイリスクリリースに含まれます。チームは常に次のフェーズへと進んでいるため、プロジェクトがあるフェーズを通過すると、そのフェーズを再検討するのは難しくなります。

ウォーターフォール型プロジェクト計画の図

従来のプロジェクト管理スタイルには多くの場合、クリティカルパスがあり、そこで障害となる問題が解決されるまでプロジェクトは先に進めなくなります。さらに困ったことに、エンドカスタマーは製品が完成するまで触れることができません。このため、製品の設計やコードの重要な問題がリリースして初めて発覚することがあります。

これに対し、アジャイルパターンは、一定間隔で開発を行い、フィードバックを収集する反復型アプローチです。イテレーション単位に進むため、障害となる問題が解決される間、チームをプロジェクトの別の領域に回して (生産性を維持することが) できます。

アジャイルプロジェクト計画の図そのため、チームには常に開発、デリバリ、学習、調整の機会があります。チームはいつでも新しい要件にすばやく適応できる準備ができており、市場の変化にも動転することがありません。

さらに素晴らしい点は、ソフトウェアチーム内でスキルセットが共有されることです。チーム内でスキルセットが重複していたら、より柔軟にチームのコードベースのあらゆる部分で作業ができます。こうすることで、プロジェクトの方向性が変わっても労力と時間が無駄になりません。

アジャイルプログラムの構築方法

プログラムを従来のプロジェクト管理からアジャイルに移行する場合、チームと関係者は 2 つの重要な考え方を受け入れる必要があります。

  • プロダクトオーナーが作業に優先順位を付ける: プロダクトオーナーは、開発チームのアウトプットの価値を最適化することに重点を置きます。開発チームは、作業の重要度による優先順位付けをプロダクトオーナーに任せます。
  • 開発チームが作業を選択する: 開発チームは、能力で対応できる作業のみを受け入れることができます。プロダクトオーナーが、チームに作業を強要したり、恣意的な期日にコミットさせたりすることはありません。開発チームは、新しい作業を受け入れられるようになったら、プログラムのバックログから作業を取り出します。

次は、アジャイルプログラムが反復型で作業を整理、実行、構造化するために使用するメカニズムを見てみましょう。

ロードマップ

ロードマップには、製品またはソリューションが時間と共にどう発展するか、概要を記述します。ロードマップはイニシアチブで構成されます。イニシアチブは大まかな機能領域で、いつ機能がリリースされるかを伝えるタイムラインが含まれます。プログラムの進展に伴い、ロードマップは変化するということが受け入れられます。その変化は軽微な場合も広範囲な場合もあります。重要なのは、ロードマップが常に現在の市場の状況と長期的な目標に焦点を合わせていることです。

アジャイルロードマップについての詳細は、JIRA Software や Confluence のようなツールを使用したアジャイルロードマップの作成に関する Atlassian の記事を参照してください。

要件

ロードマップの各イニシアチブは、要件のセットに分解されます。アジャイル要件は、必要な機能についての簡単な記述です。従来のプロジェクトのような 100 ページのドキュメントではありません。要件は時間と共に発展し、顧客や望ましいプロジェクトに関してチームが共有する理解が反映されます。チームの全員が継続的な会話とコラボレーションを通じて共有する理解を深めていく間も、アジャイル要件は簡潔なままです。実装が開始間近になって初めて、全詳細で肉付けされます。

バックログ

バックログでアジャイルプログラムの各優先順位が設定されます。チームは、新機能、バグ、機能強化、技術的またはアーキテクチャ的なタスクなど、すべての作業項目をバックログに追加します。プロダクトオーナーが、エンジニアリングチームのバックログにある作業に優先順位を付けます。開発チームは、優先順位付けされたバックログのみを情報源として、どの作業を行う必要があるかを確認します。

アジャイルのデリバリ手段

アジャイルは、ソフトウェアをデリバリするためのさまざまなフレームワーク (スクラムや Kanban など) を使用して実装できます。スクラムチームは、スプリントを使用して開発を進め、Kanban チームは多くの場合、一定の作業期間は使用せずに作業します。ただし、どちらのフレームワークでも、エピックやバージョンなどの広範なデリバリ手段を使用して開発を構造化し、本番環境へのリリース間隔を同期します。

エピック、ストーリー、バージョン、スプリントは何が違うのでしょうか? 詳細は、JIRA Software のようなツールを使用して作業を構造化する方法に関する、Atlassian のチュートリアルを参照してください。

アジャイル指標

指標によって、アジャイルチームの作業が促進されます。WIP (進行中の作業) の制限によって、チームと企業は、常に最も優先順位の高い作業のデリバリに集中できます。バーンダウンチャートやコントロールチャートのようなグラフは、チームがデリバリ間隔を予測するのに役立ち、継続的なフローダイアグラムでボトルネックを特定しやすくなります。こうした指標とアーティファクトは、全員が常に大きな目標に集中し、今後の作業をデリバリできるというチームの自信を高めます。

続けて「プログラムのためのアジャイル」セクションを読み、これらのトピックのそれぞれに関する知識を深めてください。

アジャイルは信頼が基本

アジャイルプログラムは、チームメンバー間に高いレベルの信頼がなければ機能しません。プログラムと製品について何が正しいか、難しい会話をするには率直さが必要です。会話は一定間隔で行われるため、アイデアや懸念は一定間隔で伝えられます。つまり、そうした会話で下された決断に基づいて実行する能力 (と意欲) が互いにあるとチームメンバーが確信していることも必要です。

まとめましょう。アジャイル開発とは構造化された反復型のソフトウェア開発アプローチです。作業を中断せずに変更に対応できます。これはどのプログラムにとっても大きな利点です。

次の単元では、アジャイルチームビルディングの方法と、チームで協力して継続的に高品質の製品を作成する方法について説明します。

リソース

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる