ストーリーカードを書くための良いプロセスは何ですか？ [閉まっている]

StackOverflow https://stackoverflow.com/questions/235299

質問

次のプロジェクトのためにストーリーカードを定義しているところです。

  • ワークショップを通じて顧客が何を望んでいるのかをよく知っています
  • ビジネス要件ドキュメントがあり、それらはサインオフされます。

ストーリーを定義するプロセスは次のとおりです

  1. 顧客が望む機能を取り入れてストーリーを作成します
  2. チームに関する簡単な設計ディスカッション
  3. 次に、カードの推定値を決定します
  4. カードが3日より長い場合、さらにカードを分解し、ステップ2から繰り返します

残念ながら、顧客はプロジェクト全体にかかる時間の見積もりを望んでいるため、すべてのストーリーを事前に定義する必要があります。

これには時間がかかり、かなり消耗する可能性があります

ストーリーカードの定義に使用できる他の方法は何ですか？ これには、ストーリーカードに要件を収集する他の方法がありますか？

編集：

  1. これは初めてのことではなく、通常のプロセスです
  2. 顧客は内部顧客です
  3. 最終的にコーディングの対象となるカードの書き方に興味があります
役に立ちましたか？

解決

<！> quot;リリース計画ゲーム<！> quot;と呼ばれるものを提案します。これは、反復で行うことと非常に似ていますが、より高いレベルで行いました。つまり、ユーザーが特定のリリースに必要な機能または機能ポイントのセットを取得し、 way がオフになることを知って推定します。その後、これらの推定値をすべて加算して、現在の情報に基づいて製品を提供できると思う時期を大まかに把握できます。

これにより、いつリリースするのかを顧客に理解してもらう必要がありますが、顧客のように未来を予測できないため（または少なくとも私はできません） t）。

他のヒント

すべてがいつ完了するかを知ることはできず、それでもアジャイルプロセスに従います。すべてを推定するために非常に一生懸命働いたとしても、作業が大きいほどエラー率が大きくなります。中規模のプロジェクトのほとんどの見積もりは2倍オフになり、より大きなプロジェクトの見積もりは10倍オフになります。

代わりに、機能的な目標日を顧客に尋ねます。会話は次のようになります。

あなた：これらの機能が必要になるのはいつですか

（C）ustomer：いつ配信できますか？

あなた：最初に境界線を組み立てましょう。これらすべての機能を10年で提供した場合、手遅れになりますか？

C：もちろんです。

あなた：これらのすべての機能を明日配信したら、それで十分ですか？

C：もちろんです。

あなた：今から1年後はどうですか？

C：まだ手遅れです。

あなた：3か月？

C：それは少し遅すぎて、2か月ほどです。 1月に管理チームでこれを使用する準備ができている必要があります。

あなた（考えて）：あはは！

あなた：これらのすべての機能を2か月で提供することはできません。私たちはこれらの4つのストーリーを1か月で配信し、これら3つのストアを翌月に配信できると思います。

C：1月には機能Xが本当に必要になります。

あなた：OK、機能Xを追加する場合、機能を削除する必要があります。必要ないのはどれですか

C：機能Yの一部のみで実行できます。

あなた：OK。このリストを使用して、より詳細な見積もりを作成します。

C（考える）：ハ！欲しいものが手に入りました！

見積もりと計画の根本的な理由は何度も何度も見つけました<！> quot; everything <！> quot;彼らは日付までに何かを配達する約束を望んでいるということです。目標日までの作業は、次の理由によりはるかにうまく機能します。

  1. 顧客にトレードオフの支援を強制する

  2. 推定の本当の理由を明らかにする

  3. 推定するものの数を減らします。

  4. どの機能がどのスプリントにとって重要かを識別するのに役立ちます。

私は、リリース計画のためにこれほど小さな話をしません（あなたがしたいことのようです）。とにかく（時間の経過とともに変化するため）リリース計画の精度は低くなります。そのため、推定に精度の低いユニットを使用することは理にかなっています。

通常、Planning Pokerを使用します。ストーリーを分割する前に、最大許容値は13または21です。リリース計画については、<！> quot; 理想的な日 <！> quot ;, <！> quot; ideal hours <！> quot;の反復計画用。私たちにとってはうまくいきます。

クライアントへのアプリケーションのリリースをどのように計画していますか？増分配信を行っていますか？または、これは最初の成果物の計画ですか？

開発を2週間または3週間のスプリントに分割し、各スプリントごとに1週間を配信予算に追加することをお勧めします。彼らは）。これにより、最終配送日を簡単に見積もることができます...

クライアントに段階的に配信する必要があると納得させることができれば、仕様の変更に伴って作成される冗長なストーリーが少なくなることがわかります。さらに、前もって多くの作業を行う必要はありません。また、開発が進行するにつれて、開発の進行中に次のバッチのストーリーを書くことができます。

これが役立つことを願っています。

私は通常、ストーリータイトルのみを前もって尋ねます。少なくとも1桁以内にトリアージできるかどうかを確認します。タイトルの数と推定速度/タイトルに基づいて、非常に大まかな推定値を示します。通常、顧客にタイトルを（1）必要なもの、（2）必要なものの、待つことができるもの、（3）これらのタイトルに分割するように指示します。

グループ（1）に取り組み、それらを一連のリリースに分割するのに十分な情報を考え出すことから始めます。この時点で、タイトルごとの見積もりを提供するためにより詳細な情報を使用することにより、通常、より良い見積もりを提供できます。グループ（1）のストーリーのみを計画します。グループ（1）のストーリーが多すぎてリリースに収まらない場合は、複数の一貫したリリース/イテレーションに分割します。

グループ（2）のストーリーを開始してから約1か月以内になったとき、私は顧客と再び座ります（より集中的な計画セッションで、通常は常に彼らと話します）。グループ（2）のストーリー。

プロジェクトの進行に伴って追加されるストーリーは、適切なグループに入れられ、そのグループに適切に処理されます-現在のリリースの場合、後でタイトルをプレースホルダーとして使用するのに十分な詳細p>

私がやる他のことは、それが協力的なプロセスであることを顧客が理解していることを確認することです。ボードにストーリーが残っていても、いつ停止するかを選択できます。私が彼らが気にする価値を提供している限り、私たちは発展し続けます。彼らは私が彼らのために何をしていて、熱心に働いていると信じる必要があります。彼らができる限り早く彼らが望むものについてできる限り最高の情報を提供してくれると信じる必要があります。

XPに忠実な場合は、こちらに行くことをお勧めしますリリース計画と反復計画の違いについて読んでください。実際にコーディングを開始する準備ができるまで、個々のタスクの見積もりを行うべきではありません。

ストーリー！=タスク。ストーリーはタスクに分割され、次に<！> lt;を実行します。 3日間の見積もり。ストーリーの推定はよりオープンであり、しばらくしてからあなたとあなたのチームにとって最適なストーリー推定のしきい値を決定できるはずです。 （IE <！> lt; 1週間、2週間、<！> gt; 2週間など）

推定の最も重要な部分は、実際に費やした時間を追跡し、推定プロセスを調整することです。 XPはフィードバックのすべてです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top