プロジェクトの最初のユーザーストーリーをタスクに分割する
私はゼロから新しいプロジェクトを開始し、特定のユーザーがシステムと対話する方法を説明するユーザーストアを作成しました。しかし、最初のユーザーストーリーを叙事詩にせずに、最初のユーザーストーリーをタスクに分割する方法を理解するのに苦労しています。
たとえば、私が車を作っているときに、最初のユーザーストーリーが「ドライバーとして、物をぶつけないように動きの方向を変えたい」と言った場合、それはユーザーを暗示します。インターフェース（ステアリングホイール）だけでなく、モーション（ホイール）およびそれらをリンクするために必要なすべてのもの（車軸、フレーム、リンケージなど）。最終的に、その最初のユーザーストーリーは常にプロジェクトの約40％を占めるように思われます。これは、基礎となるアーキテクチャについて多くのことを暗示しているからです。
最初のプロジェクトが基礎となるアーキテクチャ全体を表す叙事詩にならないように、新しいプロジェクトのユーザーストーリーをどのように分類しますか？
ストーリーをシステムの垂直スライスと考えてください。ストーリーは、システムのすべてのアーキテクチャレイヤーのコンポーネントに触れる可能性があります（多くの場合、触れます）。したがって、タスクをストーリーが触れる各コンポーネントで実行する必要のある作業と考えることができます。
たとえば、のようなストーリーがあるとします。登録ユーザーとして友達のツイートを簡単にフォローできるように、Twitterアカウントを持つすべてのGmail連絡先を自動的にフォローします。
これを実現するには、UIレイヤー、サービスレイヤーを通過し、データレイヤーにいくつかのデータを保持し、TwitterとgmailにAPI呼び出しを行う必要があります。
あなたのタスクは次のとおりです。
- メニューにオプションを追加します
- 新しいGmail認証画面を追加する
- Twitter認証画面を追加する
- 連絡先選択画面を追加する
- サービス層に呼び出すコントローラーを追加します
- 仕事をする新しいサービスを書く
- 連絡先をデータベースに保存する
- 既存のGmail API呼び出しサービスを変更して連絡先を取得する
- Twitter API呼び出しサービスを追加して、選択した連絡先をフォローする
そこ：9つの可能なタスクがあります。ここで、原則として、1日にバイアスをかけながら（サイズ設定のためのベストプラクティス）、タスクに1日約1/2〜2日かかるようにします。難易度に応じて、これらのタスクをさらに細分化するか、2つの簡単なタスクを組み合わせる場合があります（おそらく、2つのAPI呼び出しサービスは非常に単純なので、modify external API services）。
とにかく、これはストーリーをどのように分解するかの生のスケッチです。
EDIT：
ストーリーをタスクに分割するというテーマに関するより多くの質問に答えて、それについてのブログ投稿を書いたので、ここで共有したいと思います。ストーリーを打ち破るのに必要な手順について詳しく説明しました。リンクは here です。
スクラム管理スタイルでプロジェクトを開始したとき、最初の一連のタスクは常に広範でした。それは避けられないことであり、通常、プロジェクトのフレームワークは最も重要で、最も大きく、時間のかかる部分ですが、プロジェクトの残りの部分をサポートします。 MOSTの重要な部分をリストできるかどうかを確認するために、どれだけの圧倒的な強さでスケールを削減するか。次に、これらのタスクを開始点として定義する作業を行います。したがって、広範な開始の出発点としていくつかのタスクがあります。それが理にかなっていることを願っています！
最初に実装するストーリーは、時間の経過とともに洗練されていきます。すべてのストーリーは、ユーザーが使用する最終バージョンである必要があると考える必要はありません。
たとえば、最近のプロジェクトでは、さまざまなWebサイトのインデックスを作成し、ユーザーが作成したフィルターと照合して、最終的にユーザーに一致（ステロイドに関するgoogleアラート）を通知するアプリケーションを開発する必要がありました。
1つの観点から見ると、「ユーザーとして、一致するページからアラートを取得したい」というストーリーが1つだけあります。しかし、「軽減したいリスクは何か」という別の観点から見てください。最初のリスクは、ユーザーがGoogleアラートに比べて関連性の高いヒットを獲得できないことです。 2番目のリスクは、これを構築するための技術を学ぶことでした。
したがって、最初のユーザーストーリーは単に「ユーザーとして関連するヒットが必要」というものでした。次に、一部の初期ユーザー向けにハードコーディングされたページセットとハードコーディングフィルターにヒットマッチングアルゴリズムを構築し、フィードバックを得ました。
実際には、「ユーザーとしてURLの一致に優先度を上げたい」などの学習をキャプチャするために、複数の小さなストーリーが存在する場合があります。これらのストーリーは、何を反復するかによるフィードバックから得られます初期のユーザーは「関連するヒット」を考慮します。
次に、「特定のWebサイトからのヒットが必要なユーザー」に拡張し、ユーザーが指定したサイトをクロールしてヒットマッチングを行うインデックスアーキテクチャを構築しました。
3番目のストーリーは「ユーザーとして自分のフィルターを定義したい」で、システムのこの部分を構築しました。
このようにして、アーキテクチャを少しずつ構築することができました。初期部分のほとんどを通して、初期のユーザーのみがシステムを使用でき、多くのデータがハードコードされていました。
しばらくすると、初期のユーザーはシステムを完全に使用できるようになりました。次に、新しいユーザーが登録できるようにするためのストーリーを追加し、公開しました。
長いストーリーを短くするために、最初に実装するストーリーは最終ストーリーのごく一部のみを実装し、他のすべてをハードコーディングして足場にすることができます。そして、あなたが実際に一般に公開するかもしれない物語を得るまで、時間をかけてそれを繰り返すことができます。
ユーザーストーリーはwhatを説明しますが、タスクはhowについての詳細です。
- 完全な公式はありません。ユーザーストーリーを実装、文書化、またはテストする
howを記述するタスクを追加するだけです。 - タスクは数時間で見積もる必要があるため、それに応じてタスクをスケーリングおよび詳細化するようにしてください。
ストーリーに対してタスクが多すぎると感じる場合（1〜8時間のタスクがある場合でも）、多分複雑すぎるため、最初にユーザーストーリーを書き直すことを検討する必要があります。
幸運を
私は過去にこの問題の岐路に立ってきました。ユーザーストーリーは分離されているため、他のストーリーなしで、どのような順序でも実行できます。しかし、それを実現すると、すべてが複雑になります。私にとっては、これはアジャイルマニフェストの「プロセスとツールに対する個人と相互作用」の部分、または少なくともそれに関する私の解釈に該当しました。
最終的な目標は船です。そして、出荷するには、構築する必要があります。構築するには、スクラムを使ってむちゃくちゃにするのをやめて、作業を完了させて追跡する必要があります。
そこで私たちがしたことは、ストーリーの基本的なルールを破ることであり、「予備的なスキーマを作成する」などの技術的なストーリーを作成しました。また、一部のストーリーは他のストーリーに依存していることを宣言し、ストーリーカードの裏面に記載しました。
結局、私はこの種の物語はほとんどなく、その間にあるものだと感じ、代替案の難しさは例外を正当化した。