多くのユーザーストーリーは同じ技術的タスクを共有しています。


8

私のケースの少し紹介:

より大きな製品の一部として、私のチームはDSL用の小さなIDEを実現するように求められます。この製品のユーザーは、コードで関数呼び出しを行うことができます。また、いくつかの便利な関数ライブラリを提供することも求められます。チームは、POと一緒に、IDEユーザーのさまざまなライブラリに関する特定の数のユーザーストーリーを壁に配置しました。それらの最初のストーリーを推定するとき、チームは関数呼び出しメカニズムが魅力的ではあるが完全に明白ではないタスクであると判断したため、そのユーザーストーリーの推定は単純な3からより危険な5に上がりました。

問題に来る:

次に、チームは他のライブラリに関するユーザーストーリー(実際には10のストーリー)に移動し、これらの2つの「関数呼び出しメカニズム」のことを各ユーザーストーリーに追加しました。これですぐに20ポイントの商品の合計ポイントがアップしました!チーム内の誰もが、各ユーザーストーリーはいつでも次のイテレーションのPOによってピックアップされる可能性があることを知っているので、1つのユーザーストーリーでその部分を分離するべきではありませんが、それらの20ポイントは非常に非現実的に感じられます。

私は解決策を提案しましたが、完全に満足していません:

「デザインストーリー」を作成し、面倒な2点を載せました。しかし、私たちがそれを実現して顧客に示すようになったとき、私たちはその話について彼らにとって本当に価値のあるものを示すことができませんでした!

ここでの問題は、孤立したユーザーストーリー(それらの間の依存関係なし)の原則を無視すべきかどうかです。

このような状況で、あなたは何をしますか?


(小さな脚注:提案に従って、この質問をstackoverflowから移動しました)


IDEとは、APIのことですか?そうでなければ、私はあなたが言っていることを理解するのに苦労しています。
Steven Evers、2011年

これは、ユーザーがコードを入力してコンパイルし、デバッグできるIDE(en.wikipedia.org/wiki/Integrated_development_environment)です。言語の重要な特徴は、私たちが提供する関数( "v = sin(x)"など)を呼び出す機能です。
Marco Ciambrone、2011年

回答:


6

いくつかの要素が共通するいくつかのユーザーストーリーを推定する必要があるが、これらのストーリーを実装する順序がまだわからない場合は、各ストーリーを構成するタスクを3つのグループに分けます。

  1. 一般的なタスク、1回のみ必要:複数のストーリーで発生するが、最初のストーリーで実際に1回だけ実行する必要があるタスク。前述の関数呼び出しメカニズムは、おそらくこのカテゴリに分類されます。
  2. 一般的な繰り返しタスク:複数のストーリーで発生し、ストーリーごとに新しく実行する必要があるタスク。
  3. 特定のタスク:特定のストーリーに固有のタスク。

次に、各タスクを推定します。一般的なタスクは1回だけ推定する必要があります。

顧客/ POへのプレゼンテーションでは、各ストーリーに2つの見積もりを与えます。1つはすべての「共通の、一度だけ必要な」タスクが含まれ、もう1つは除外されています。
顧客が見積もり間の違いについてより詳細な情報を必要とする場合は、タスクの詳細な説明、分類、見積もりを手元に置いてください。タスク自体は交渉可能ではありませんが、特に一般的なタスクのセットが各ストーリーで同じでない場合、それらについて知ることで顧客/ POを助けることができます。


1
+1:振り返ってみると、共通のコードがすでに実装されているため、すべてのストーリーを再推定します。
S.Lott、2011年

私はあなたのポイントを理解したと思いますが、この場合、すべてのタスクを抽出せずに、より深い分析を避け、ストーリーのより迅速な推定を支持することにしました。私たちは実際に、「共通のタスク、一度だけ必要な」グループのような「共通のストーリー」をストーリーから抽出することによって、あなたの提案と同様のことをしました。あなたの答えはさらに効果的に進み、非常に役立ちますが、反復分解の計画に任せる、タスク分解の代わりに、可能であれば大まかな見積もりを優先します。- S.Lott @:このアプローチは、これらの「迷惑」20ポイント..去る
マルコCiambrone

@ d3prok:「迷惑な」20ポイントは、選択したアプローチの一時的な成果物です。それらは実際には存在せず、共通のタスクが実装されると消えます。
S.Lott、2011年

4

なぜソフトウェアが難しいのか。

「デザインストーリー」を作成し、面倒な2点を載せました。しかし、私たちがそれを実現して顧客に示すようになったとき、私たちはその話について彼らにとって本当に価値のあるものを示すことができませんでした!

正しい。単純化されたユーザーストーリーSCRUMは単純化されています。場合によっては、実際のソフトウェアが複雑すぎて、単純化したアプローチが機能しないことがあります。これは、驚くべきことではありません。

ここでの問題は、孤立したユーザーストーリー(それらの間の依存関係なし)の原則を無視すべきかどうかです。

あなたの代わりは何ですか?すべてのユーザーストーリーには高額な価格が設定されています。これは、それぞれのユーザーストーリーに一時的なコストが隠されているためです。それもばかげています。

はい。あなたは単純化から離れなければなりません。

このような状況で、あなたは何をしますか?

単純化から離れてください。ストーリーのグループをより安くする1回限りの投資があります。構築するストーリーのリストがあなたの唯一の相互作用であると偽るのではなく、実際にアーキテクチャについて人々と話し合う必要があります。

アジャイルとは、POおよび顧客と実際に話し合う必要があることを意味します。

アジャイルとは、単純化されたプロセスが機能しないことを意味します。


したがって、PO +のお客様に、20のユーザーストーリー(それぞれの実際の価値/金額)のそれぞれの完成に向けて、克服すべき技術的ステップがあることを示す必要がありました。これは、彼らにそのような「デザインストーリー」の重要性を認識させ、その結果、彼らにその仕事を優先させるより良い立場に置くのに役立つでしょう。よくわかりましたか?
Marco Ciambrone、2011年

@ d3prok:「彼らにそのような「デザインストーリー」の重要性を認識させ、その結果、彼らにその作業に優先順位を付けるためのより良い立場に置くことができる」はい。スクラムのようなアジャイル手法では、POや顧客と話し合う必要があります。会話。ディスカッション。相互作用。'story-estimate-prioritize-build'の考えられない正式なプロセスは、実行することを避けるべき正確なものです。
S.Lott、2011年

これは非常に有用な回答でした。ポイントをお伝えしたいと思いますが、残念ながら、プログラマーに対する私の評判は低すぎます... S.Lottに感謝します。
Marco Ciambrone、2011

1

あなたは追加の作業を1回だけ行う必要があることを知っているので、同じ追加の作業を5つのストーリーに入れても意味がありません。ユーザーに表示されないデザインストーリーが必要ない場合は、今すぐ先に進んで、そのデザイン作業に依存するものの1つを選択し、それを最初にする必要があると言います。それらにそれらのポイントを追加します。他のストーリーについては後で説明する必要があることをメモします。何らかの理由で気が変わった場合は、いつでもポイントを移動できます。


1
「最初の」タスクとして(ランダムに、またはランダムに)選択した機能に共有タスクを追加しないように警告します。これにより、PO /顧客は、(より安価な)他の機能を優先して、その(より高価な)機能をドロップ/優先順位付けすることを決定する場合があります。これは、今あなたが生きることができるものではないでしょう。代わりに、上記の@Bart van Ingen SchenauおよびS.Lottの回答に従うことをお勧めします。
Svend Hansen、
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.