アジャイル入門

アジャイル開発方法がほかの方法論と異なる点

アジャイル プロジェクトではソフトウェアを段階的に作成します。変化するビジネス要件に開発を合わせるために、通常では 1 ~ 4 週間の短いイテレーションが適用されます。

単一パスではなく、すべての要件とリスクを事前に予測する 6 ~ 18 か月のリリース

アジャイルでは、1 ~ 4 週間のイテレーションごとに実用的なテスト済みコードを納入して、頻繁なフィードバックに順応します。

アジャイル チームのさまざまなロール

スクラム マスタは、チームがコミットしてそれを達成できるようにアジャイル開発方法に忠実であり続けることを支援する世話役の奉仕型リーダーです。次のような職責があります。

  • すべての役割と職務が緊密に連携できるようにする
  • 障害を取り除き、チームを混乱させない
  • 組織と協力して、進捗状況を追跡し、組織の構造とプロセスをリファクタリングする
  • デイリー スタンドアップ、計画ミーティング、デモ、レビュー、振り返りなど、アジャイルの検査と順応プロセスの活用を促進する
  • チーム ミーティングと意思決定セッションを進行する

プロダクト オーナーは、ビジネスの観点からの製品を推進します。次のような職責があります。

  • 要件の定義して、その価値の優先順位を決める
  • リリース日とコンテンツを決定する
  • イテレーションとリリースの計画ミーティングで積極的な役割を担う
  • チームが常に最も重要な要件に取り組むようにする
  • 顧客の意見を伝える
  • 「完了」のチーム定義および定義された承認基準を満たしているストーリーを承認する

アジャイル チーム

アジャイル チームによる作業計画の方法

アジャイル チームは、イテレーションで作業を実施して、ユーザ ストーリーを実現させます。

チームは、各ストーリーのバックログ優先順位付けとサイズに基づいて、ストーリーをイテレーションに計画します。

チームはキャパシティ(タスクの実行に費やすことができる理想的な時間数)を使用して、どのくらいのスコープをイテレーションに計画するのかを決定します。

ストーリー ポイントを考慮する必要がある理由

  • ポイント: チームがコミットできる作業量を定義します
  • キャパシティ: 個人がコミットできる作業量を定義します

ユーザ ストーリーとは何か

ユーザ ストーリーは、ユーザが必要としている機能を定義する要件です。これは以下の 2 つの形式を取ります。

  • <ユーザ ロール> は <ビジネス価値> のために <機能> を必要としています
  • <ビジネス価値> のために <ユーザロール> は <機能> を必要としています

リリースの計画では、ポイントなどの相対的なスケールを使用して、ユーザ ストーリーのおおよそのサイズが見積もられます。

イテレーションの計画では、ストーリーがタスクに分割されます。

アジャイルでは、実用的で現実的な見積もりを作成することが厳格に求められます。

ユーザ ストーリーとタスクの関係

ユーザ ストーリーは、ユーザの要望を定義する what–it の説明です。

タスクは、機能を実装する方法です。ストーリーはタスクによって実現されます。実際の作業は、ストーリーよりも詳細になります。各ストーリーは実質的にはタスクの集合体です。

ストーリーをタスクに分割するのは、ストーリーが現在のイテレーションに計画されるまで待ちます。イテレーションの直前に詳細を検討することで、知見とフィードバックを活用できるからです。

タスクは時間数で見積もられます。通常の規模は 2 ~ 12 時間です。

ストーリーは受け入れテストで検証されます。

ストーリーの完了の定義

チームは何をもって「完了」とするのかを決定します。次のような基準を適用できます。

  • すべてのタスクが完了した(開発、テスト、文書化)
  • すべての受け入れテストを実行して成功した
  • オープンなディフェクトの数がゼロである
  • プロダクト オーナーによって承認された
  • ユーザに提供できる

チームは「完了」を定義して、それぞれのイテレーションでその定義がすべてのストーリーによって満たされるようにすることをコミットします。

承認基準とは何か

機能がプロダクト オーナーまたは顧客によって承認されるために必要な機能、動作、およびパフォーマンスを定義する基準。

承認基準の役目は、ストーリーが完了したときに開発チームがそのことを認識できるように、「完了」とは何であるのかを定義することです。定義を開発チームに任せたくないストーリー領域がある場合は、承認基準を記述します。たとえば、エラー メッセージの文言についてこだわりがある場合は、エラー メッセージの形式と文言を説明するための設計ドキュメントを提示したり、エラー メッセージを生成する可能性がある各ストーリーの承認基準を作成してメッセージの文言を指定したりすることができます。

アジャイルで要件を定義する方法

ユーザ ストーリー、承認基準、およびストーリーを実現するタスクとして定義されます。

フィードバック

ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。