scrum - 予測不可能なタスクをスクラム スプリントに組み込むには?

Question

私は 4 人の開発者からなる小さなチームのスクラム マスターです。私たちが取り組んでいるプロジェクトには、これまでに行ったことのない多くのタスクがあり、スプリント計画会議では簡単に見積もることができません。この不確実性でスプリントを実行するための最良の方法は何ですか? リリース可能な製品でスプリントを完了するのは非常に難しいと感じています。また、長さが不明なタスクがたくさんある場合、スプリントを計画するのも難しいと感じています。

Answer 1

スクラムでこの用語が何を意味するのかはわかりませんが、ユーザー ストーリーの用語では「スパイク」を行います。これは、基本的に、チームがタスクを見積もることができるように、トピックに関する非常に短い期間の調査です。スパイクの終わり。

例：

話：

アナリストは、円グラフで財務データを確認できるようにしたいと考えています。

あなたのチームはグラフ作成ツールを使用していないため、このようなものを構築するのにどれくらいの時間がかかるかを知る必要があります. あるいは、代わりに、サードパーティのツールに投資して、ツール セットをアプリケーションに統合することもできます。

これらの会場を調査するためにスパイクを実行し、それらの見積もりを作成してから、どのルートを取るかを決定します。

Answer 2

世界中の誰かが以前に行った「タスク」か、それともチームにとって初めての「タスク」か。後者と仮定します。この場合、あなたのチームには問題を解決するために必要な経験がありません。したがって、あなたは、あなたが行くにつれて、その経験を発展させるでしょう. これはすべて、ストーリーの複雑さがより高いことを意味します。最初の数回のスプリントでは、一部のストーリーで 13 点を獲得し、その後、必要な知識が得られて 8 点になることがあります。

ストーリーを評価するために、ストーリーの進め方を知る必要はありません。経験のギャップのために、それらの数を減らす必要があるだけです.

私は「スパイク」(はい、スクラムで使用される用語です) を、既知の解決策がないビジネス ドメインの問題を解決しようとするために取っておくのが好きです。チームがトレーニングを行うためではありません。

Answer 3

適切な見積もりを得るために本当に調査を行う必要がある場合は、調査自体をタスクとして行うか、それを脇に置いて、スプリント計画の前に (誰かに) 行わせることができます。

一般的に、適切な見積もりが得られない場合は、悪い見積もり (つまり、大げさな推測) を使用するか、タスクをタイムボックス化して、一定の時間を確保する必要があると思います。スプリント。その後、解決策が完成するか、それをよりよく理解して、次のスプリント (または後のスプリント) のためにそれを見積もったり、サブタスクに分割したりできるようになります。

Answer 4

本当にタスクのことですか、それともプロダクト バックログ アイテム (PBI) のことですか? 実際、タスクが評価できないとは信じがたいです。そうでない場合は、大きすぎる可能性が非常に高くなります (タスクは 16 時間を超えてはなりませんが、これはすでに巨大です)。

PBI について話している場合、説明している状況は非常に驚くべきものであり、理論的には発生しないはずです。最悪の場合、彼らに多数のストーリー ポイントを割り当てるだけです。これはまさに、彼らに多くの不確実性があることを意味します。しかし、スプリントの準備ができている PBI はベロシティの半分を超えてはならないため (さもなければ、スプリントに大きなリスクを負わせることになります)、この状況を解決する明白な方法は、そのようなアイテムをより小さなチャンクに分割することです。探索を含みます。しかし、重要な部分は、R&D でさえ (または特に) タイムボックス化することです。スクラムでは、すべてがタイムボックス化されていることに注意してください。

言い換えれば、不確実性を減らすには、物事をより小さなもの (アイテムまたはタスク) に分解します!

Answer 5

精度と精度を混同していませんか？

アジャイル見積もりの​​背後にある考え方は、正確な数値ではなく、十分な数値を考え出すことです。そのため、バックログ項目の見積もりにストーリー ポイントを使用することがベスト プラクティスです。期間ではなく、労力/複雑さを強調します。

スプリントでバックログ項目を実装するために必要な各タスクにかかる時間を知る必要はありません。知っておく必要があるのは、このスプリントで以前にコミットした作業を考慮して、このバックログ項目にコミットできるかということです。各バックログ項目にかかる時間を正確に知ることはできないため、知識に基づいて推測する必要があります。

さらに重要なことは、スクラムで失敗するということは何を意味するのでしょうか? すべてのスプリント バックログ項目が失敗に終わっていませんか? いいえ... 5 つの項目のうち 4 つを完了し、5 つ目の項目がほぼ完了している場合、4 つの完了した項目 (スプリントの速度の観点から) の功績が認められ、残りのタスクを完了すると、そのためのクレジットが与えられます。将来のスプリントで 5 番目のアイテムを取得すると、そのアイテムの完全なクレジットが得られます。しかし、スクラムを使用していなかったら、もっと多くのことを成し遂げられたでしょうか? スクラムの唯一の失敗は、自分の過ちから学ばず、同じ機能不全のことを繰り返し続けながら、異なる結果を期待することです。

そのため、スプリント計画ミーティングでは、知らないことについて心配することに多くの時間を費やさないでください。チームに作業について考えさせてから、スプリント中に完了できる快適な作業量にサインアップしてもらいます。彼らがコミットしていない場合は、いつでも何かをバックログにドラッグするか、スプリントを早期に終了できます。彼らがオーバーコミットしている場合は、優先順位に従ってバックログ項目を完了し、未完了の項目がスプリントのふりかえりで完了できなかった理由と、将来のスプリントで未完了の項目が発生しないようにする方法について話し合います。

ところで、これはおそらくあなたの言葉の選択が不適切だったことは承知していますが、効果的なスクラム マスターはスプリントを実行しません。チームはスプリントを実行し、スクラム マスターは生産性を低下させ、コミットメントを果たす能力を妨げる障害を積極的に探します。スクラム マスターはマネージャーではなく、審判、コーチ、スコアキーパーの組み合わせです。彼らはプロセスの番人であり、チームがプロセスに従うのを助け、プロセスを迂回しようとする外部エージェントからチームを保護し、スプリント バックログが更新され、スプリント バーンダウン チャートが更新されるようにすることで、スプリント中の進捗を追跡します。日々、現実を反映しています。あなたが説明したような状況で、チームがサインアップする必要がある作業量がわからない場合、スクラム マスターは、コミットメントに対するチームの所有権を尊重することを反映して、チームに決定させる必要があります。どのような決定であっても、それは間違いではありません。

Answer 6

予測不可能なタスクを、不確実性を取り除くタスクと「残り」に分割します。概念実証テストまたはスパイク ソリューションで不確実性を取り除きます。このスプリントにスパイクをスケジュールし、残りの作業を次のスプリントにスケジュールするか、スプリントの開始を 1 週間のスパイクのために遅らせるかのいずれかです。

Answer 7

スパイクはタイムボックス化する必要があります。チームには、範囲を制限し、研究に伴う費用対効果についてより良いアイデアを得るというプレッシャーがかかります。つまり、数ドルかかるタスクのために 3 日間の調査を実行しても意味がありません。

これは、特にこの問題に取り組んでいる目標設定理論に関するレイサムの研究によっても裏付けられています。

Answer 8

タスクが見積もれないと思われる場合は、それらのタスクを見積もり可能な小さなタスクに分割するのが最善の方法だと思います。数回の反復が必要になる場合がありますが、その過程でおそらく疑似設計が思いつくでしょう。Joel は、彼の記事の 1 つでこれについて言及しています。

Answer 9

そのようなタスクには、「偶発」または特定のバックログを使用します。スクラム ツールのAgiloは、この作業方法をサポートしており、バーンダウンなどでこれらの問題も計算します。このようにして、「計画不可能な」項目を適切に制御できます。

Answer 10

多くの場合、ストーリーをタスクに分解するのに十分な知識がありません。タスクがどうなるかを知る前に、発見の期間があります。「スパイク」は管理が難しいようです。1 つには、発見期間をタイムボックス化できない場合があります。第 2 に、ストーリーにかかる時間を知らずに効果的にスプリントを計画することはできません。

別のオプションは、スプリント 1 でスパイクを実行し、スプリント 2 でタスクを実行することです。欠点は、プロセスが作業の不自然な内訳を強制しているように見えることです。なぜ今週発見し、作業を開始する前にしばらく待ってください。