agile - スクラムの1つの機能の設計と実装のストーリー？

Question

特定の機能の開発を複数のストーリーに分割すると、次のようになります。

• 機能の高レベルの設計のための最初のもの、
• 最初のストーリーに基づいて、機能を構成するさまざまなスタンドアロンピースを開発するために、他のストーリーを作成します。

滝をやっているということですか？

さらに、以前に特定したスタンドアロン部分の開発を設計と実装に分割するとします。

それは私が滝をやっているという意味ですか？

注：私はスクラム初心者です。

Answer 1

設計や実装のストーリーなどはありません。ユーザーストーリーは、ユーザーにある程度のエンドツーエンドの機能を提供する必要があります（つまり、顧客の価値を提供する）。

ストーリーと機能という用語を混ぜ合わせているという事実は コミュニケーションに役立ちませんが、説明している内容は、ユーザーストーリー（製品バックログレベル）ではなく、実際にはタスク（スプリントバックログレベル）のように聞こえます。

そして、それらがタスクでない場合、それらは非常に悪い話です。たぶん「機能性」が大きすぎるので、話をダイエットする必要がありますが、ここで私が見ているのは典型的な話の匂いです。

ユーザーストーリーを初めて使用する場合は、通常のテンプレートを使用することを強くお勧めします（<ユーザーのタイプ>として、<何らかの理由>になるように<何らかの目標>が必要です）。また、 INVESTモデルに従うことを強くお勧めします。これは、あなたの質問のような落とし穴を避けるのに本当に役立ちます。

本当の質問に戻りましょう（私はウォーターフォールをやっていますか？）：スプリント内でデザインすることには何の問題もありません（ストーリーのタスクとして）。しかし、ストーリー全体がデザインに関するものである場合、実際にはスクラムを実行していません。スプリントの最後に、実証可能なエンドツーエンドの増分を提供することになっています。

Answer 2

スクラムストーリーは「ビジネス価値」に関するものになる傾向があります。

ビジネス価値は、ビジネスに対する開発努力の相対的な価値を表す概念です。多くの場合、ビジネス価値は定量化できませんが、多くの場合、お金に関連しています。

ビジネス価値は、プロジェクトが中止された場合でも販売できるものと考えることができます。

「機能の高レベルのデザイン」を作成するためにストーリーを作成する場合、そのストーリーを実装することによって作成するものは、企業が販売できるものではありません。これは、顧客が試したり、購入したり、使用したりできるものではありません。事実上、そのストーリーのビジネス価値はゼロです。

あなたは「垂直に」物語について考えるほうが幸運かもしれません。「垂直スライス」は、テクノロジースタック全体をカバーする最小限の機能です。例：「ユーザーは、テキストボックスに名前を入力し、ボタンをクリックして、データベースに自分のレコードを表示できる必要があります。」それ自体は特に便利ではありませんが、機能の設計よりも価値があります。

Answer 3

いいえ、違います。サブタスクをバックログに追加することができ（おそらくほぼ同じ優先度で、ほぼ同時に出てくる）、スーパータスクは個別のコンポーネントを統合/テストなどすることです。

大きなコンポーネントを分解する有効な方法のように思えます。さまざまなチャンクのサイズを適切に設定してください。4〜16時間のチャンクが最適であることがわかりました。タスクに40時間を与えるということは、金曜日に残りの32を詰め込むまで（多くのバグとともに）2時間の作業を行うことを意味します。