私のケースの少し紹介:
より大きな製品の一部として、私のチームは、DSLの小さなIDEを実現するように求められます。この製品のユーザーは、コードで関数呼び出しを行うことができます。また、いくつかの便利な関数ライブラリを提供します。チームは、POと共に、IDEユーザーのさまざまなライブラリに関する特定の数のユーザーストーリーを壁に配置します。これらのストーリーの最初を推定するとき、チームは関数呼び出しメカニズムは魅力的ではあるが完全に明らかではないタスクであると判断したため、そのユーザーストーリーの推定は単純な3より危険に5。
問題の発生:
その後、チームは他のライブラリに関するユーザーストーリー、実際には10のストーリーに移動し、それぞれに「関数呼び出しメカニズム」の2つのポイントを追加しました。それらのユーザーストーリー。これですぐに20ポイントの商品の合計ポイントがアップしました!チーム内の誰もが、各ユーザーストーリーはいつでも次のイテレーションのPOによってピックアップされる可能性があることを知っているので、1つのユーザーストーリーでその部分を分離するべきではありませんが、それらの20ポイントは非常に非現実的に感じられます。
解決策を提案しましたが、完全に満足していません:
「デザインストーリー」を作成し、面倒な2点を載せました。しかし、私たちがそれを実現して顧客に示すようになったとき、私たちはその話について本当に価値のあるものを示すことができませんでした!
ここで問題は、孤立したユーザーストーリー(それらの間の依存関係なし)の原則を無視する必要があるかどうかです
このような状況で、あなたは何をしますか?
(小さな脚注:提案に従って、この質問をstackoverflowから移動しました)
いくつかの要素が共通するいくつかのユーザーストーリーを推定する必要があるが、これらのストーリーを実装する順序がまだわからない場合は、各ストーリーを構成するタスクを3つのグループに分けます。
次に、各タスクを見積もりますが、一般的なタスクは1回だけ見積もります。
顧客/ POへのプレゼンテーションでは、各ストーリーに2つの見積もりを与えます。1つはすべての「一般的な、一度だけ必要な」タスクが含まれ、もう1つは除外されています。
顧客が見積もりの違いに関するより詳細な情報を必要とする場合は、タスクの詳細な説明、分類、見積もりを手元に置いておく必要があります。タスク自体は交渉可能ではありませんが、特に一般的なタスクのセットが各ストーリーで同じでない場合、それらについて知ることで顧客/ POを助けることができます。
なぜソフトウェアが難しいのか。
「デザインストーリー」を作成し、面倒な2点を載せました。しかし、私たちがそれを実現して顧客に示すようになったとき、私たちはその話について本当に価値のあるものを示すことができませんでした!
正しい。単純化されたユーザーストーリーSCRUMは単純化されています。場合によっては、実際のソフトウェアが複雑すぎて、単純化したアプローチが機能しないことがあります。これは、驚くべきことではありません。
ここでの問題は、孤立したユーザーストーリー(それらの間の依存関係なし)の原則を無視すべきかどうかです。
あなたの代わりは何ですか?すべてのユーザーストーリーには高額な価格が設定されています。これは、ユーザーストーリーごとに一時的なコストが隠されているためです。それもばかげています。
はい。あなたは単純化から離れなければなりません。
このような状況で、あなたは何をしますか?
単純化から離れてください。ストーリーのグループをより安くする1回限りの投資があります。構築するストーリーのリストがあなたの唯一の相互作用であると偽るのではなく、実際にアーキテクチャについて人々と話し合う必要があります。
アジャイルとは、POおよび顧客と実際に話し合う必要があることを意味します。
アジャイルとは、単純化されたプロセスが機能しないことを意味します。
あなたは追加の作業を1回だけ行う必要があることを知っているので、同じ追加の作業を5つのストーリーに入れても意味がありません。ユーザーに表示されないデザインストーリーが必要ない場合は、今すぐ先に進んで、そのデザイン作業に依存するものの1つを選択し、それを最初にする必要があると言います。それらにそれらのポイントを追加します。他のストーリーについては後で説明する必要があることをメモします。何らかの理由で気が変わった場合は、いつでもポイントを移動できます。