アジャイルに関するよくある質問 – GreenHopper の見積時間とサブタスク (前編)

2012-10-05 (Fri)  •  By 伊藤  •  活用のヒント  •  アジャイル開発 翻訳

今回の記事は、アジャイル開発に関するアトラシアン ブログ「Agile Q&A – GreenHopper Time Estimates with Sub-Tasks 」の弊社翻訳版の前編です。原文と差異がある場合は、原文の内容が優先されます。

今回のブログ投稿は、Brad Albrecht 氏が Atlassian Answers 上に投稿した質問 を抜粋し、編集したものです。GreenHopper プロダクト マネージャーの Shaun Clowes が Brad 氏の投稿に詳細に回答しています。

Brad 氏の質問

最近、自分のプロジェクトを最新版 GreenHopper のスクラム ボードに移行しました。見積には時間を使用しています。これにより、スプリントを設計する際に見積もった課題の所要時間を確認できますし、開発ごとに 2 週間以内にとどめておくことができます。

いろいろな理由から、いくつかの課題では見積を持つサブタスクが既に存在しています。これまで JIRA が親タスク上で見積や残り時間を計算できるようにしており、新しい GreenHopper ボードに切り替えるまではうまく行っていました。今では、スプリントをセットアップする際、サブタスクを持つすべての課題は計算した値を表示しなくなりました。これでは親課題が表す作業量を確認できません。

親タスクの見積を手動で変更すると、他のサブタスクを追加する際にそのサブタスクの値が追加され、合計がまったく間違ったものになってしまいます。新しいスクラム ボードは、私に今までどおりに JIRA 課題を使って欲しくないみたいです。それでも、GreenHopper 6 の新しいスクラム ボードを使用しない場合、自動計算されたサブタスクは非常に理にかなっていると思います。

以前読んだところではアトラシアンとしては機能的に問題ないとしているので、ラピッド ボードの使用方法に関して私が勘違いをしているに違いありません。どうすべきか教えてもらえませんか?

Shaun の回答

まず、GreenHopper 6.0.3 の “時間追跡” が設定されているボードでは、ストーリーとサブタスクの残余見積の合計は、ストーリーの “見積” の値の合計の隣にあるスプリントのフッターに表示されます。これであなたが必要としていることを実現できるでしょう。

しかし、差し支えなければ、なぜ “残余見積” ではなく “初期見積時間” を “見積” の値としているか説明させてください。私の考察のいくつかは、皆さんもよくご存知のアジャイルの概念に言及しています。しかし、それを含めた理由はコンテキストが重要だからです。なお、ここでの考察は GreenHopper の主流のやり方として実装したベスト プラクティスに言及したものであり、それが自分の状況にあまり適していないと感じた場合はこのアプローチを採用しないことを選択できます。

見積は追跡とは別物である

スクラムにおいては、見積と追跡は区別されます。見積は通常、プライマリ バックログ アイテム (PBI、通常はストーリーが該当) に対して行われ、そのバックログのどの程度がデリバリーされたのかを算定するために使用されます。追跡とは、スプリントに含まれているストーリーがすべて必ずデリバリーされるよう、そのスプリントの進捗を監視することを表します。たいていの場合、追跡はストーリーをタスクに分割し、プラン作成ミーティングの際にそれらに時間の見積を適用することで実行されます。その後、スプリント中にバーンダウンで残り時間を監視します。

見積はベロシティに他ならない

見積を PBI に適用する主な目的は、バックログの一部がデリバリーされるまでにどのくらいかかるかを算定するためにその情報を使用することです。

従来の開発環境では、チームは項目を “工数” で見積もり、その見積が正確であるとみなされます。その後、チームはプロジェクトのバックログの時間を計算し、チームのメンバー数と週当たりの時間で割って日付を予測します。もちろん、これらの見積は極めて不正確だと判明することが多々あります。なぜなら、チームの本質的な見積特性 (過大評価や過小評価に関して)、予期せぬ中断、もしくは時間の経過に伴うチーム パフォーマンスの向上を考慮していないからです。見積の不正確さに加え、それを正確なものと “無理やりみなす” 過程で消費された相当な費用があります。不可能ではないにしろ、これらが “工数” アプローチの成功を困難なものにしています。

スクラムの世界では、多くのチームは見積の正確さを求める代わりに、信頼できるベロシティの達成を目指します。ベロシティは、チームが 1 スプリントで完了する見積単位数の指標です。最初の数スプリントの後、大部分のチームは割と一貫したベロシティを達成します。バックログの PBI 上でのベロシティと見積を武器に、チームはバックログの一部が完了するのに必要な時間を予測できます。

重要な点は、見積単位が何であれ、スプリントを重ねるごとに合理的に予測可能になるということです。たとえば、チームは “理想の時間” 見積の使用を選択できます。しかし、これらの時間が経過時間と緊密な関係がある必要はなく、またそうであることも期待されません。チームの各スプリントにおける “工数” の容量は 120 時間だがベロシティが 60 時間である場合、60 時間のベロシティを使用してバックログの一部が完了するのに必要な時間のスプリント数 (つまり経過時間) を見積もることができるので同じことです。そうすると、多くの人が “残りの 60 時間” はどこに行ったのか不思議に思うでしょう。そして、チームの生産性がどこかおかしいと思うかもしれません。しかし、通常は何の関連性もありません。チームの見積は、単にそのチームの観点からの項目の難易度を表しているだけであり、それらは大概チームの普段の行動 (たとえば、過大評価や過小評価) や組織のオーバーヘッドなどに害されています 。計画の観点からは、ベロシティだけが重要です。

単位は時間に関連していないため、多くのチームはストーリー ポイント (他と比較した場合のあるストーリーの複雑さを計測する任意の数) をチームの見積単位として使用することを選択しています。ストーリー ポイントは、時間との心理的なつながりを明確に切り離します。

不正確な見積は結構。均等に不正確である限りは

ベロシティが安定した状態に到達するためには、チームが各バックログ項目を同程度の正確さで見積もる必要があります。いやむしろ、各項目をきっかり同じレベルの不正確さで見積もるべきと言った方が良いかもしれません。分かりきったことを繰り返すと、ベロシティの目的はさほどよく理解されていないストーリーのバックログを確認できるようにすること、そして完了までにどれだけのスプリントが必要であるか把握することです。必要なことは、バックログに含まれるすべての見積がすべて同程度に不確かであることです。

直感と相容れない考えのひとつとして、チームは各項目を一度だけ見積もり、見積を変更すべきではないということがあります。その項目に関する新しい情報が見つかり、チームが初期見積が間違っていると感じる場合でもです。もし、チームがあえて見積を更新する場合でも、この “新しい情報の発見” は定期的に生じることになります。その結果として、いくつかの項目は非常に正確であるが、それ以外はそれほど正確でないバックログとなります。これはベロシティを害することになります。なぜなら、非常に正確な見積がかなりの割合を占めるスプリントは、非常に正確な見積の割合が少ないスプリントと比較して異なる数の単位を完了することになるからです。その結果として、ベロシティはバックログ内のよく把握されていないストーリーのセットが完了するまでに要するスプリント数を見積もるという主目的のために使用できなくなります。したがって、最初の見積を使用することが重要な意味を持ちます。これにより、チームのベロシティは、現実的にそのチームがはるか先のよく把握されていない作業の一定単位数を完了できることを表すことになります。

アトラシアン アジャイル シリーズ

本記事は、アトラシアン製品を愛用しているトップ アジャイル エキスパートによる最新のゲスト ブログ記事です。アジャイルに関する資料については、「Do agile right 」を参照してください。また、Nextag、OpenDNS、OfficeDrop、John Muir Health、PBS、Interspire、その他のインタビューもお読みください。


Related Articles

お気軽にお問い合わせください

お問い合わせ