アジャイル・プランニングの実際

アジャイル・プランニングによるリリース開発のための実践的アドバイス

皆さんはアジャイル・プランニングの時流に乗ろうとしているチームの一員ですか?反復型開発を行っているというのに、まだ変更を重ねざるを得ない状況ですか?この記事では、IBM 製品チームを支援および教育してきた著者がその経験を生かし、「アジャイル・プランニングによるリリース開発を始めるにはどうすればよいか」という質問の答となるロードマップを紹介します。アジャイル・プランニングの基本を概説し、何が有効で何が有効でないかについての著者の見解を説明します。編集者からの注記: 著者の要望により、図 1 と図 4 を更新した他、いくつかの修正を追加しています。

Steffan Surdek, User Experience Lead, IBM

Steffan Surdek は、WebSphere® Business Services Fabric チームの User Experience Lead で、自ら「アジャイル・チャンピオン」を名乗っています。彼は 2 日間にわたる Software Group Agile Workshops を促進した経験を生かし、チームがアジャイル・プロセスを改善できるように支援しています。



2009年 4月 15日 (初版 2009年 3月 31日)

「我々はアジャイル開発チームで、反復型開発を行っている」。この言葉は、アジャイル開発を実践していることを主張するチームからよく聞かされます。しかし真のアジャイル開発を実践するためには、反復型の開発を行うだけでは足りません。

従来、開発チームが行っているリリースでは、リリースの内容もリリース日もそれぞれのリリースで事前に決められています。各リリースの開発を開始する時点で、管理チームは開発チームに対し、リリース日とリリース内容の両方を順守するよう恒例の強い圧力をかけます。

このシナリオでの難問は、管理チームはリリース日とリリース内容の両方を指図しようとする一方で、開発チームは両方を同時には実現できないと確信していることです。実際、リリース内容は開発チームが当初見込んでいるよりも柔軟性に富んでいることがありますが、残念なことに、常に開発チームがリリース期限までにそのリリース内容を実現できるとは限らず、その結果、人々はどうにか製品をリリースしようと何時間も残業することになります。

アジャイル・ソフトウェア開発の要約

アジャイル・ソフトウェア開発とは、同じような原則に基づく一連のソフトウェア開発手法の集合です。これらの手法は通常、頻繁な調査および変化への適応を奨励するプロジェクト管理プロセスを推進するもので、この頻繁な調査と適応プロセスによって、高品質のソフトウェアを短期間で提供できるようにするためのベスト・プラクティス、そしてチーム・ワークと自己組織性、責任説明、顧客のニーズと企業の目標に沿った開発を包含した指導体制/ビジネス方針を実現していきます。

以下は、同様の概念的基礎を持つ最近の業務管理および分析手法です。

  • リーン製造/生産方式: 最終的な顧客に価値をもたらすことのない無駄なリソースの経費を考慮した生産プラクティスです。
  • ソフト・システム方式: 問題の定義に関してさまざまな見方がある複雑な状況を分析するのに最適な手法です (つまり、「災害をどのように管理するか」といった「ソフト」な問題)。
  • シックス・シグマ: 一連の品質管理手法を適用し、組織内にこれらの品質管理手法のエキスパートである人々 (「ブラック・ベルト」など) を集めた特殊なインフラストラクチャーを作成することで、プロセスでの欠陥やエラーの原因を識別し、取り除こうとする手法です。

この記事は、このような困難を克服し、チームが単純な反復型開発からアジャイル開発へと移行できるようにするロードマップとしての役割を果たします。このロードマップには、以下の内容が含まれます。

  • チームをアジャイル・プランニングに移行しやすくするための提案。
  • 反復に関するガイダンス。反復の期間をどれだけの長さにするべきか、チームは特定のリリース開発期間中に反復にだけ取り組むべきか、各リリースの間でチームが何をするべきか、という疑問に答えます。
  • ユーザー・ストーリーの作成に関するヒント、そして製品所有者の役割を理解する上でのヒント。ユーザー・ストーリーとは何か、誰がユーザー・ストーリーを作成するべきか、エピックとストーリーとでは何が違うのか、どれだけの期間の作業をストーリーに含めるべきか、そして製品所有者の定義と、プロセスにおける製品所有者の役割とは何かについて説明します。
  • 生産、リリース、反復それぞれのバックログの計画および管理方法に関するアドバイス。それぞれの計画レベルには固有のバックログがあります。これらの異なるバックログに何を含めるべきか、各計画レベルでどの程度の見積もりが必要なのかについて助言します。
  • チームの開発速度を測定し、そのデータを解釈するための手法。チームの開発速度からどのような種類の情報を推定できるのかを説明します。

アジャイル・プランニングへの移行を容易にする

移行を開始する前には、以下の点を考慮する必要があります。

  • プロセスからどのような結果を得たいのか、その目標を理解すること。変化が苦手な人もいます。目標とする結果を得るためには、プロセスの早い段階で妥協しても構わない目標のレベルを認識することが必要です。結果が達成されつつあることを明らかに示しさえすれば、さらに追加したい変更を、プロセスが進化する過程での次のステップに過ぎないものとして表現することで、いつでも目標のレベルを引き上げることができます。
  • 思い付きで移行に着手しないこと。プロセスをチームに押し付けても、チームが十分に訓練されていなければ、チークに大きな反感だけでなく、新しいプロセスに対する全般的な不信を招きかねません。
  • 知識は友であると認識すること。学ばなければならないことを学び、学んだことに慣れてください。アジャイル手法をまずは小規模なプロジェクトに適用してみて、その問題点を解決します。そこから得た知識をチームの残りのメンバーに教えます。プロセスを開始する前には、全員が同じ用語を使用し、プロセスについて共通の理解を持っていることを確実にします。この教育プロセスが、自分自身に足りない知識を発見する上でも役立ちます。
  • プロセスを最後までやり遂げること。いったん開始したら、後ろを振り向かないでください。スターウォーズのヨーダも、「やるか、やらないかだけだ。やってみるという選択肢はない。(Do or do not ... There is no try.)」と言ったときに、これと同じ考えだったはずです。何かが上手くいかなくなってきたら、昔の方法に戻るのではなく、新しいプロセスに調整を加えてください。

成功するためには、皆さんのチームのメンバーがプロセスに深く関与する必要があります。メンバーに深く関与させるには、まずは皆さん自身がそのプロセスを信じていなければなりません。アジャイル・プランニングは、皆さんがプロセスを正しくやり遂げることに専心してこそ、皆さんのチームに効果をもたらします。


反復をスケジューリングする

まずはよくある質問として、「反復はどれだけの期間にするべきか」という点から考えてみましょう。反復を行う目的は、チームが早い段階から頻繁に利害関係者 (顧客、製品所有者など) のフィードバックを受けられるようにすることです。

一般的な反復期間は、2 週間または 4 週間 (場合によっては、6 週間) です。反復期間がこれよりも短いと、短時間でサイクルが繰り返されることによって切迫感が伝わるため、反復計画をしやすくなる傾向があります。一方、反復期間が長くなると、人々は作業する時間がたっぷりあるという誤った印象を受け、それによって致命的な事態になりかねません。

反復は、チームの生命を支える鼓動です。そのため、リリース開発に取り組んでいる最中ではないとしても、反復は常に続いていなければなりません。反復が継続されることにより、チームは早期調査 (アーキテクチャー・スパイクとも呼ばれます) やプロトタイプの作成、あるいは次回リリースのためのユーザー・ストーリーの作成をスケジューリングすることが可能になります。リリースの「正式」な反復に実際に取り掛かる前にこれらのアクティビティーを行っておくことで、リスクを早期に発見し、必要に応じてリスク軽減計画を考案するのに役立ちます。

特定のリリース日に間に合わせるためだけに、リリース開発の途中で反復期間を変更しないようにしてください。チームで変更に対する抵抗感が生まれる可能性があるだけでなく、反復期間の度重なる変更は、チーム・リーダーが新しいプロセスに確信を持っているという証にはなりません。また、チームの開発速度の計算 (「開発速度を測定する」のセクションで説明) も難しくなります。測定基準として一定の期間を使用できなくなるためです。

例外的に、最後の反復では反復期間を短く変更した方が適切な場合があります。最後の反復に含まれるアクティビティーが、国際化対応やバグの修正といった最終段階のアクティビティーが主だとしたら、この時点では反復期間を短くしたほうがチームにとって混乱が少なくなります。

最終反復を短い反復期間にする代わりに、すべての反復を短い反復期間 (例えば 2 週間) になるようにスケジューリングするという方法もあります。リリース日が反復の最後に設定されていないとすれば、この手法を使うことで、リリースのための作業を 1 週間前に完了することができます。

反復の最終日には、その反復で行った成果のデモンストレーションおよび見直しのための時間をとり、開発者、管理チーム、利害関係者を参加させてください。機能を実演して見せることによって、チームの成果を全員が確認できるだけなく、リリース過程での貴重な調整につながるかもしれない早期のフィードバックを得られる可能性も生まれてきます。


ユーザー・ストーリーを作成する

ユーザー・ストーリーとは、顧客の要件を簡潔にまとめた箇条書きのことです。これはいわば、顧客に対して自分がどんな作業を行っているかを説明する内容だと考えてください。ユーザー・ストーリーが焦点とするのは顧客のニーズです。実装の詳細を記述することはありません。

製品所有者は顧客と話し合ってその要件を理解し、大まかなユーザー・ストーリーのたたき台を作成します。そこからより詳細なユーザー・ストーリーを作成するために、製品マネージャー、テスター、実際のユーザー、そして反復設計者からなる顧客チームを編成する必要が出てくる場合もあります。ユーザー・ストーリーを作成するには、以下のテンプレートが役立ちます。

私は <役割> として、<目標> のために <ビジネス価値> を達成する。

ユーザー・ストーリーには階層を持たせることもできます。エピックとは、さらに大まかに機能や機能性について説明したユーザー・ストーリーのことです。エピックに対して繰り返し処理を行ってその内容をブレークダウンすることで、新しいユーザー・ストーリーとエピックを作成することができます。例えば図 1 に示す 1 つのエピックは、複数のユーザー・ストーリーに分解されています。

図 1. 複数のユーザー・ストーリーにブレークダウンされたエピック
複数のユーザー・ストーリーにブレークダウンされたエピック

ユーザー・ストーリーは、製品の要件を満たすためにチームが達成しなければならない作業を表します。それでは、ユーザー・ストーリーはどれだけの規模にすればよいのでしょうか。エピックについては、規模は問題になりません。エピックは後からブレークダウンされるからです。しかし、反復期間中にチームが取り組むことになるストーリーについては、達成するまでの期間が 2、3 日で、できる限り機能性を焦点とした作業にしなければなりません。

ユーザー・ストーリーの規模は、反復期間に合わせるべきではありません。例えば、期間が 4 週間の反復があるとします。この期間を基準として 1 つのユーザー・ストーリーを作成すると、4 週間の反復期間内には収まりきらないほどの大きなストーリーになり、その結果、反復が終了する時点でチームが確約した作業を完了できない可能性があります。

リリース・バックログに多数のユーザー・ストーリーがあるのは一般的なことです。リリース・バックログを調べて、現実性のチェックを行ってください。ストーリーの数は少なくても、ストーリーを実装するまでに時間がかかるようであれば、達成すべき作業を適切に表現していないことになります。

ユーザー・ストーリーを構築するときには、ビルディング・ブロック手法を適用するようにしてください。実現可能な最小の機能動作は何かを考えるところから始め、それから次の機能動作について別のストーリーを作成します。このように順にストーリーを作成して、最終的には作成したこれらのストーリーが機能全体をカバーするようにするという手法です。

ストーリーが製品を構成するさまざまなコンポーネントに関わってくる場合もありますが、その場合には反復計画の段階で、チームがコンポーネントごとのタスクを作成すればよいだけの話です。


製品所有者を特定する

次に行うことは、製品所有者を特定することです。製品所有者とは、顧客と連絡を取り、顧客のニーズを理解している人のことです。製品所有者は、製品が市場で成功して顧客のニーズを満たすためには、どんな機能が製品に必要であるかを明らかにします。

製品所有者と開発チームとの関係は、顧客とプロバイダーの関係によく似ています。アジャイル・プランニングで覚えておかなければならない重要な点は、開発チームは常に、製品所有者が重要だと考える項目に取り組む必要があるということです。このことから、製品バックログとリリース・バックログが優先されるリストとなります。

製品所有者が優先順位に関して最終的な決定を下す役割を持っているとしても、開発チームと製品所有者との間に健全な関係が必要であることには変わりありません。開発チームは、リリース・バックログに提供する必要があるアーキテクチャー作業に関して、確実に、製品所有者にその必要性を理解させ、正しい優先順位が設定されるようにする必要があります。

製品所有者には、製品バックログとリリース・バックログに適切な優先順位が付けられた状態にすることで、チームが常に最も重要な作業項目に取り組んでいることを確実にする責任があります。

製品バックログ

製品所有者は製品バックログ、つまり製品に優先して実装する必要のあるユーザー・ストーリーのセットに責任を持ちます。

チームに既に要件 (項目別) データベースがある場合もあります。その場合には、そのデータベースを出発点として製品バックログを構築することができます。既存のデータベースを変換するには、製品所有者が要件データベースをひと通り調べ、それぞれの要件に関連する大まかなユーザー・ストーリーを特定する必要があります。

製品バックログは優先しなければなりません。製品バックログによって、製品所有者は要件のなかで、実装する必要のある特に重要な部分を選択することが可能になるからです。例えば 1 つの要件が 10 のユーザー・ストーリーにブレークダウンされるとしても、顧客要件を満たすためには、開発チームがそのうち 5 つの重要なストーリーを完了すれば十分であることもあります。

図 2. 製品バックログがその他のバックログを提供する仕組み
製品バックログがその他のバックログを提供する仕組み

製品バックログの大まかなストーリーは、チームがストーリー・ポイントを使用して見積もりを行う必要があります。この見積もりプロセスには、機能の実現に関与するすべてのグループ (開発、品質保証、文書化) が参加します。この見積もりによって、製品所有者はそれぞれの機能の大まかな相対コストがわかります。

製品バックログは、項目の追加、削除、そして優先順位の変更に動的に応じるようになっています。それと同時に、保守が可能でなければなりません。そのため、製品バックログが表す作業は 18 ヶ月を超えないようにしてください。このしきい値を超える場合には、優先順位が低い項目をリストから除外します。

バックログを短期間にしておくべきだという提案は、リーン原則 (「アジャイル・ソフトウェア開発の要約」を参照) に基づきます。妥当な期間で現実的に行える量よりも多くの作業を待ち行列に入れたままにしておいても、何の得もありません。得策となる作業がバックログから外されたとしても、それが本当に優れた考えで、顧客のニーズに合うものであれば、またバックログに戻ってくるはずです。したがってリストはスリムにして、表面には出てこない奥の手である秘密のバックログ・リストにはタスクをため込まないようにしてください。

リリース・バックログ

リリースの開始時には、製品所有者が製品バックログを見て、次のリリースに組み込むユーザー・ストーリーを特定します。そうして特定された項目が、リリース・バックログに移されます。

恒例の強い圧力がかけられてくるのは通常、この時点からです。ここからは、開発チームは製品所有者と密に連携して、特定された作業がリリースの規模と期間に対して適当なものであることを確実にする必要があります。リリース開発期間中にチームの開発速度を追跡することが、期間の終わりまでに作業のどれだけの部分が達成できるかをより明確に示す方法となります。

リリース・バックログの作成中には、大まかなユーザー・ストーリーを細かいユーザー・ストーリーにブレークダウンします。このタスクのために、製品マネージャー、テスター、実際のユーザー、そして反復設計者からなるカスタマー・チームを編成することを検討してください。

カスタマー・チームは製品所有者と協力して、新しいストーリーに優先順位を付けた上でストーリーをリリース・バックログに追加します。続いて開発チームがこれらの新しいストーリーを見積もり、ストーリー・ポイントを割り当てます。この段階での目標は、見積もる必要がある小さなチャンクに対して、このリリースで何が要求されているのかを開発チームが十分に把握できるようにすることです。

反復期間中、開発チームがユーザー・ストーリーの作業を進めるにつれ、製品所有者と開発チームは知識を得てきます。この知識から新しいユーザー・ストーリーが生まれる場合もあれば、一部のストーリーはそれほど重要ではないことが明らかになる場合もあります。新しいストーリーについては、製品所有者と開発チームが見積もりを調べ、もう一度優先順位付けのプロセスを繰り返す必要があります。ストーリーがそれほど重要でない場合には、製品所有者がリリース・バックログからそのストーリーを削除するか、リリース・バックログでその優先順位を下げることになります。また、チームはこの新たな知識を利用して、リリース・バックログに含まれる既存のストーリーの見積もりを変更することもできます。

リリース・バックログは動的なものですが、反復がいったん開始されると、製品所有者が反復で行う作業として選ばれた作業を変更することはできなくなります。作業が開始されてからチームが得た知識によって、特定の項目がリリースまたは反復に適合しないことがわかった場合、それは難しい状況になります (次のセクションで説明します)。反復期間中は、開発チームがその成果物に専念できるようでなければなりません。

反復バックログ

製品所有者は反復の開始時に、リリース・バックログの優先順位を変更することができます。すると開発チームは次に対処すべき項目を認識します。製品所有者と開発チームは、反復の初日には半日ぐらいかけて反復計画会議を行う必要があります。この会議中に、チームはリリース・バックログから可能な限り多くの優先順位が高い項目を選択して、反復バックログに追加します。

この作業を半日で済ませるための秘訣は、リリース・バックログをあらかじめ完成させておくことです。チームが(できるだけ早い段階に作成するのではなく) 反復ごとにユーザー・ストーリーを作成していたのでは 、貴重な時間を無駄にすることになり、計画を立てるにも時間がかかります。また、リリースにどれだけの作業が予定されているのかも把握することができません。

計画会議の間、反復バックログに含まれるユーザー・ストーリーごとに、チームはそのストーリーのために完了する必要があると考えられるすべてのタスクを分析する必要があります。ストーリーに関わる全員 (開発、品質保証、文書化) のタスクを特定してください。そしてチームが、識別されたタスクのそれぞれについて時間数を見積もり、その見積もりを計画に追加します。

ここでの最大の懸念は、過剰なコミットメントです。最初の反復で見積もりの時間数を調べ、作業がその反復に割り当てられた期間内に確実に完了するようにしなければなりません。チームが予定より前に作業を終わらせたとしても、いつでもリリース・バックログに戻って、反復期間内に完了可能な追加の作業項目を選ぶことができます。

もう 1 つの懸念事項は、ストーリーを完了するために必要なすべてのタスクを特定していないことです。残念ながら、最初の反復ではこのような事態が起こりがちです。これらの忘れられた項目が積み重なると、それが原因で反復期間内にストーリーを完了できない場合があります。以下に、このよくある失敗の例を 2 つ挙げます。

  • テスト・ケースを作成するための時間を含んでいない「テスト中」というタスク枠を用意してしまう。
  • 開発チームが自動ユニット・テストを作成するためのタスクを含めていない。

チームはリリース・バックログに戻る前に、反復に含まれるストーリーが実際に完了していることを確認してください (この確認はさらに 2 回行ってください)。つまり、すべてのタスクが完了していることを確実にするということです。ユーザー・ストーリーのテストが完了していない場合は、開発者にテスターを手伝わせてテストを完了させます。その反復内で開発されたユーザー・ストーリーに欠陥が残っている場合には、次のユーザー・ストーリーに進む前に、欠陥を修正します。品質は不可欠な要素です。肝心なことは、反復内でどれだけの作業をこなすかではなく、いかにバグのない成果物にするかです。

反復には終了基準を設ける必要があります。例えば、高優先順位 (重大度 1 および 2) のすべての欠陥が解決されていなければ、ストーリーが完了したことにはならないといった基準です。また、未解決の低優先順位 (重大度 3 および 4) の欠陥は、次の反復で解決するために反復バックログの先頭に追加します。重要な点は、欠陥を長々と持ち越さないことです。そうすれば、リリース開発の最終段階にはかなり良い状況にいられることになります。

チームが反復の過程で、ユーザー・ストーリーが当初期待していたよりも複雑で、現行の反復には含められない、あるいは今回のリリースに組み込むことすらできないということを認識した場合には、できるだけ早い段階でこの問題を提起しなければなりません。その際に重要なのは、自分の意見を明確にすることです。ストーリーを縮小しても、現行リリースで顧客に何らかの価値をもたらす方法があるのかどうかを考えてください。そのような方法があるとしたら、適切なユーザー・ストーリーを作成して、そのストーリーについて製品所有者と討議します。縮小バージョンは、単なる暫定措置にすることもできます。その場合には、暫定措置から完全なものにするためには、どのような措置を行うかを考え、その措置に合わせたユーザー・ストーリーを割り出して製品所有者と話し合います。そうすれば、以降の製品リリースにそのストーリーを組み込むことができます。

チームは、反復計画にあらゆる種類の作業を追加することができます。機能にアーキテクチャー・スパイクが必要な場合には、そのためのユーザー・ストーリーをリリース・バックログに追加して、「設計」、「プトロタイプ作成」、または「調査」などのタスクを設定します。スパイクのためにユーザー・ストーリーをリリース・バックログに追加することの利点は、それによって製品所有者がそのユーザー・ストーリーに優先順位を設定できることです。製品所有者が調査を行うにはコストがかかり過ぎると思った場合には、アーキテクチャー・スパイク・ストーリーはリストの終わりの方に置かれるか、該当する機能がリリースから除外されることになります。


ユーザー・ストーリーにストーリー・ポイントを割り当てる

製品バックログとリリース・バックログでは、開発チームがユーザー・ストーリーを見積もり、各ユーザー・ストーリーにストーリー・ポイントを割り当てます。時間数などの時間単位ではなく、なぜストーリー・ポイントを割り当てるのかと言うと、その主な理由は、開発の初期段階ではストーリーの実際の作業量がわからないからです。すべての分析と設計を先行して行ったとすると、機能に関する知識が増えても、それに合わせて設計を進化させることができなくなってしまいます。

時間単位ではなくストーリー・ポイントを使用するもう 1 つの理由として、作業に要する標準的な時間が個人によって異なるという点も挙げられます。実際に作業を行う人間ではない者が見積もりを行った場合、誤った見積もりになる可能性があります。

ストーリー・ポイントを使用するもう 1 つの理由は、元々は標準的な時間の見積もりであったものが、経過時間の見積もりとして誤解される可能性があるからです。経過時間とは、従業員が通常の就業日に行う雑事をすべて考慮した上で、実際に作業に費やされた時間です。したがって、例えば 5 日間として見積もられたタスクでも、会議、E メール、電話、レビューなどの日々の作業を考慮に入れると、実際には完了するまでの所要時間は 8 日間から 9 日間になる場合があります。

ストーリー・ポイントを使用するときに実際に行う作業は、機能間の相対的な複雑さを比較することです。ストーリー・ポイント 1 に相当するストーリーを取り上げ、それをストーリー・ポイント 5 に相当するストーリーと比較すれば、必然的に後者の規模は前者の 5 倍であると言っていることになります。これは必ずしも 5 倍の時間がかかると言っているわけではないことに注意してください。

あまりにも未知の点が多過ぎるために、チームがユーザー・ストーリーを見積もることができないという場合も考えられます。そのような場合にチームが取れる方法は、ユーザー・ストーリーをバックログに追加して、さらに調査を行うことです。調査が終わった時点で、チームはストーリーを再検討してポイントを割り当てます。

最初のうちは、基準とするポイントがないことから、チームにとってストーリー・ポイントの見積もりは難しいと思います。しかしチームが見積もりを繰り返すにつれ、見積もりの精度は改善されていくはずです。ストーリー・ポイントの見積もりを行うには、プランニング・ポーカーの手法を適用することができます。

プランニング・ポーカーとは、コンセンサスに基づいて、ソフトウェア開発におけるタスクの作業量または相対規模を見積もる手法のことです。この手法は、固定化 (初期の段階でチームのメンバーがタスクに要する時間を強く主張することにより、その時間に固定されてしまうこと) が行われるのを最小限にしようとします。プランニング・ポーカー手法では、チームの各メンバーが互いに自分のカードを見られないようにして見積もりカードを出します (このカードには 0、0.5、1、2、3、5、8、13、20、40、100 の値が記されていますが、単位はありません。単位はモデレーターによって決定されます)。各メンバーがカードを出し終わった後、すべてのカードを一斉に公開するというわけです。


開発速度を測定する

開発速度とは、反復ごとにチームが完了した作業量を長期間にわたって追跡した結果です。これは、リリース・バックログと同じ単位、つまりストーリー・ポイントで測定されます。

チームは初めに、リリース・バックログの各ユーザー・ストーリーに対してストーリー・ポイントを割り当てます。各反復の開始時に、チームはその反復期間中に取り掛かるストーリーを選択します。ストーリーに割り当てられたポイントを獲得するには、チームはそのストーリーのすべてのタスクを反復内に完了しなければなりません。

チームがユーザー・ストーリーのタスクを 1 つでも完了しなかった場合、その反復の終了時にチームがストーリーで獲得したポイントはゼロということになり、ストーリーは次の反復に持ち越されます。その場合、チームは残りのタスクを完了した時点の反復で、そのストーリーのポイントを獲得します。

チームが反復を次々に完了してストーリー・ポイントを増やし、前の反復のデータを調べてみると、図 3 のような実態が見えてくるはずです。各反復でチームが獲得したポイント数が同じでないことに注意してください。

図 3. 複数の反復にわたる開発速度
複数の反復にわたる開発速度

開発速度の素晴らしいところは、何度かの反復が終わった後に、追跡グラフの数値から、リリース・バックログの残りの項目について完了できそうな量を推定できるようになることです。

表 1. 反復ごとのストーリー・ポイント数
反復ポイント数
128
232
336
434
533
637
731
835

表 1 に記載されているのは、反復ごとのストーリー・ポイント数です。この表のデータから、以下の情報を引き出すことができます。

  • 反復ごとの平均ストーリー・ポイント数が 33 であること。
  • チームの現在の開発速度が 35 ストーリー・ポイントであること。
  • 最も遅い 3 つの反復では、平均ストーリー・ポイント数が 30 であること。

したがって、リリースで残っている反復があと 6 回だとすると、以下のように推定することができます。

  • 平均開発速度では、チームはさらに 198 ストーリー・ポイント (6 x 33) を完了することになります。
  • 現行の平均開発速度では、チームはさらに 210 ストーリー・ポイント (6 x 35) を完了することになります。
  • 最も遅い開発速度では、チームはさらに 180 ストーリー・ポイント (6 x 30) を完了することになります。

図 4 では、リリース・バックログが 3 つのセクションに分割されています。中央のセクションは、上記の前提を基として最後の 6 回の反復に組み込むことのできる作業を表します。

図 4. 作業終了時の推定
作業終了時の推定

図 4 はまた、開発チームがリリース・バックログのすべてのユーザー・ストーリーを完了できないことも伝えています。だたし、チームが常にリストの上から下の順で作業しているのであれば、チームがいつでもそのリリースで最も重要な項目に取り組んでいた確率は高くなります。


まとめ

アジャイル・プランニングの第一の目標は、「既知」の作業をできる限り多く取り上げ、全員に認識させることです。この記事では「既知」という点を強調していますが、これは作業対象に関する知識が増えるにつれ、新しいストーリーをバックログに追加することになるからです。こうすることにより、製品所有者が継続的にリリース・バックログに優先順位を付け、開発が常に最も重要な内容に取り組んでいることが確実になります。

製品所有者は一般に、すべてのストーリーがリリースに含まれていないとしても何とかやっていけます。けれどもチームが重要でない項目に時間を費やしすぎたために、その結果時間がなくなって重要なストーリーをリリースに収められなかったとしたら、製品所有者は憤慨するものです。ですから、製品所有者に対しては自分の顧客のように扱い、常に製品所有者が望むことをまず始めに片付けるようにしてください。

この記事で紹介した意見はすべて私個人のもので、必ずしも IBM の意見であるとは限りません。

参考文献

学ぶために

製品や技術を入手するために

  • developerWorks から直接ダウンロードできる IBM 試用版ソフトウェアを使用して、Linux で次の開発プロジェクトを構築してください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=391688
ArticleTitle=アジャイル・プランニングの実際
publish-date=04152009