プロジェクト開始時に複雑なストーリーを分解する

アジャイルプロジェクト管理（Pivotal Trackerを使用）について理解しようとしていますが、プロジェクトの最初のいくつかのストーリーを定義しようとすると、壁にぶつかってしまいます。たとえば、次の非常に単純な話を見てください。

「ユーザーは製品にタグを付けることができるはずです」

私がすでに「製品」を別の場所で定義していると仮定すると、このストーリーには、多態性タグシステムを内部で記述し、そのシステムIDが完了すると、最終的に製品にタグを付ける機能を追加できるようになります。

私の問題は、このストーリーに隠されている作業量にあります。ストーリーを完成させるためのタスクを定義することはできますが、ストーリー全体は1〜2日間の作業になるはずです。私は氷山の一角を明らかにするだけの話では正しくないと思いますが、それはユーザーに関連する唯一の部分です。

このようなことをどのように克服しますか？ベストプラクティスは何ですか？

更新25/08皆様のご指導に感謝し、ストーリーを定義する方法について、私はすべてのアドバイスを船内に取り入れました。私は今、ストーリー内のタスク（割り当て、見積もりなど）と、スプリントが始まったら開発タスクの追跡をサポートするJira Grasshopperに切り替えています。

あなたの物語が開発者の仕事の1〜2日ごとにする必要がある場合、おそらくあなたは、特定のユーザーのタスクにそれぞれの物語を壊すべきである開発者の仕事の1〜2日。

次の「ユーザーストーリー」について考えてみます。

ユーザーは、購入した製品から請求書を受け取ることができる必要があります。

ユーザーにこの機能を提供する際に、データベース設計に何が関係しているかを考えてください。顧客テーブル、請求書ヘッダーテーブル、および請求書明細テーブルが必要ですが、支払いの受け取りについてはまだ話していません。

実際には、ユーザーストーリーはそれほど単純ではありません。完全なユーザーストーリーには、関連するユーザーステップのウォークスルーが含まれます。

• ユーザーが商品をカートに入れました
• ユーザーが数量を指定
• ユーザーが配送タイプを指定します

等々。つまり、ユーザーストーリーをより詳細に分解する必要があります。

ストーリーは「1〜2日の仕事」ではありません。スクラムでは、ストーリーは通常、相対的なサイジングシステムであるストーリーポイントを使用して推定されます。ポーカープランを使用する場合、ストーリーにはポイント値が与えられます-ストーリーの実装にかかる時間は、チームが確立した速度によって異なります。

ストーリーが複雑さを隠していると感じた場合（エピックストーリーと呼ぶこともできます）、それを小さなストーリーに分割する必要があります。新しい物語が続くことを確認してくださいINVESTの基準を。

しかし、あなたはこれを過剰設計しているかもしれません。ここではYAGNIのXP原則が適用されます。明確にするために、本当に必要な場合を除いて、「内部でのポリモーフィックなタグ付けシステム」を実装しないでください。それでも、既存のシステムを改善して、優れたテストスイートで開発したものを設計する必要があります。

この複雑なタグ付けシステムが必要であると確信している場合は、別々のストーリーで複雑さを指摘する必要があります。マイク・コーンはデザインへのアプローチを「意図的でありながら創発的」と表現しています

ストーリーとタスクを混乱させているようです。

ユーザーストーリー

ユーザーストーリーは完全な「機能」であり、製品に追加されると、製品により多くの価値を提供します。

ユーザーストーリーは、スプリント中に実装できるものよりも大きくしないでください。スプリント計画の最初の部分では、スプリント中に作業するユーザーストーリーを決定します。スプリントの目標は、これらのユーザーストーリーを完成させ、製品にさらに価値を付加することです。

仕事

スプリントの計画フェーズの後半では、開発者はストーリーをタスクに分割します。タスクは開発タスクです。それらは、「データベースに列を追加」、「サービスxの拡張」などのようなものである可能性があります。タスクは、1日で完了することができるものより大きくてはなりません。

毎日のスクラム中に、これらのタスクの進行状況を評価します。タスクが毎日複数のスクラムで進行中の場合、時間がかかりすぎており、チームとしてその状況を解決する責任があります。

ユーザーストーリーは、利害関係者のビジネス価値を表すことを忘れないでください。利害関係者は、タスクではなく、ユーザーストーリーの完了に関心を持つ必要があります。

タスク分割は、開発チームがスプリントを管理し、スプリント中にユーザーストーリーの進行状況を監視し、潜在的な問題を視覚化するためのツールです。

利害関係者は、これらの開発タスクに関与するべきではありません。残念ながら、特にアジャイル開発が初めての組織にとっては、彼らがよく経験するのは私の経験です。ただし、この状況への対処は別の問題です。

大作

ユーザーストーリーが1つのスプリントで完了することができると思うよりも大きい場合、それは叙事詩と呼ばれます。チームで作業を開始する前に、いくつかの小さなユーザーストーリーに分割する必要があります。

ユーザーストーリーはエンドユーザーに付加価値を与えるため、エピックを「フロントエンド」と「バックエンド」のストーリーに分割することは適切な方法ではないことに注意してください。新しい機能のバックエンドを追加すること自体は、エンドユーザーに価値を提供しません。

エピックをスプリントの時間枠内で管理可能なユーザーストーリーに分割することは、そうした経験がない場合は必ずしも容易ではありません。

Pivotal Trackerの使用

Pivotal Trackerは、ユーザーストーリーを追跡するための優れたツールだと思います。しかし、それ自体はスクラムツールではなく、ストーリーをタスクに分割することをスクラムが教える方法は、ピボットトラッカーでは簡単に処理できません。ユーザーストーリーにタスクを追加する機能を有効にできます。しかし、スクラムを使用してプロジェクトを実行している場合は、ホワイトボードと付箋を使用して、スプリント中のタスクの進行状況を追跡することをお勧めします。

多態性タグ付けシステムを実装するという設計目標を持つことは問題ありませんが、それでも顧客が望む機能の実装に集中する必要があります。これは、きめの細かいユーザーストーリーによってきめの細かいユーザーストーリーによって、システムが時間の経過とともに多態性タグ付けシステムを持つように進化することを意味するかもしれません。ただし、その過程のどの時点でも、実装したユーザーストーリーのコレクションによって記述された、多数の小さなテスト可能な機能で構成されるシステムが必要です。

この場合、システム内の「製品のタグ付け」がエピックであるように聞こえます。つまり、単一のユーザーストーリーよりもはるかに大きく、少しの労力でいくつかの小さなストーリーに分解できます。かなりの量の芸術的ライセンスを取得すると、次のユーザーストーリーがあなたの要件にほぼ当てはまると考えられます。

• システム管理者として、システムにいくつかの有効なタグをシードして、ユーザーが最初にタグ付け機能を使用するときにいくつかの値を選択できるようにしたいと考えています。
• システムのユーザーとして、後でタグ付けできるように、名前で製品を検索できるようにしたいと考えています。
• システムのユーザーとして、製品の説明を読んで、どのタグが必要かを判断できるようにしたいと考えています。
• システムのユーザーとして、製品の写真を見て、必要なタグを決定できるようにしたいと考えています。
• システムのユーザーとして、単一のタグを単一の製品に添付できるようにしたいと考えています。
• システムのユーザーとして、1つの製品から1つのタグを削除できるようにしたいと考えています。
• システムのユーザーとして、1つのタグを複数の製品に添付できるようにしたいと考えています。
• システムのユーザーとして、1つの製品に複数のタグを付けることができるようにしたいと考えています。
• システム管理者として、システムで使用されているタグの明確なリストを確認して、重複していないかどうかを判断できるようにします。
• システム管理者として、重複したタグを統合したいと考えています。

...そして私は続けることができました。

これらのどれも実物そっくりで使用できるとは思えませんが、うまくいけば、ユーザーストーリーを使用してどのような詳細を確認できるかがわかります。

ユーザーストーリーを実際には小さなストーリーに分割できなくても、一度に実装するには大きすぎると思われる場合は、垂直方向のスライスに分割できます。これは、各ユーザーストーリーの機能の一部のみを配信する手法ですが、各部分はテクノロジーの関連するすべてのレイヤーを介してテスト可能なスライスです。たとえば、Webサイトの場合、これはデータベース、アプリケーション、UIレイヤーを変更することを意味します。データベース作業用、アプリケーション用、UI用のユーザーストーリーを個別にテストすることはできないため、これらは避けてください。

さらに芸術的なライセンスを取得すると、「システムのユーザーとして、単一のタグを単一の製品に添付できるようにしたい」と分割するかもしれません。次の垂直スライスに：

• 単一の製品を見るシステムのユーザーとして、適用するタグを決定できるようにタグのリストを検索できるようにしたいと考えています。
• 1つの商品を見るシステムのユーザーとして、その商品に適用するタグを決定したので、それを適用できるようにしたいと考えています。
• システムのユーザーが単一の製品を見て、その製品にタグを付けたので、正常に保存されたことを知らせる確認メッセージを画面に表示したい。

それらのそれぞれはテスト可能です-それ自体は特に価値があるわけではありません。

要件を説明し、分解する正しい方法を見つけることを唯一の目的として書かれた本があります。したがって、それは簡単な作業ではありません。

多くの場合、最も単純なソリューションではなく、複雑なソリューションを求めて開発チームが努力しています。これは、ストーリー自体が原因であるか、チームがこのストーリーを解決するだけでなく、ストーリーx、y、zの基礎を築く非常に複雑なソリューションを求めているためです。これは善意ですが、同じ作業をより少ない作業で実行できる範囲が膨れ上がります。デザインをめちゃくちゃにして将来のストーリーを台無しにしないために、どのくらいのデザインがストーリーに入らなければならないかを判断することは常に困難です。この決定は、チームが行うことです。

製品所有者は、ストーリーをより小さな部分に分解することによってのみ、これに影響を与えることができます。あなたは自分自身に問いかける必要があります。この話は、現時点で考えられる最小の解決策ですか？それを、「いつかずっと欲しかった大きな柔軟なタグ付けシステム」になるような機能セットに分解できますか？単一のタグのタグシステムから始めて、事前に選択されたタグのリストを含めるようにタグシステムを拡張し、ユーザーにタグを定義させることができます。

開発チームにとっての結論は次のとおりです。ストーリーを実現するためのよりシンプルなアプローチを見つけながら、将来の機能を損なうことなく今日の仕事を達成する確かなアーキテクチャを維持できますか？

中間的なソリューションを受け入れる用意があり、開発チームが最もシンプルでありながら優れたソリューションも提供しようとする場合、おそらく、やりたいストーリーのサイズが適切である（小さいほど良い）スイートスポットを見つけるでしょう。 。これはあなたが小さな物語しかないということではありません。いくつかは他よりも大きいです、これはあなたが受け入れる必要がある事実です、またはそれらが大きすぎる場合は、ストーリーをより小さな断片に分解します。