アジャイルユーザーストーリーの共有開発タスク

私のチームは、次のプロジェクトでVisual Studio Team Servicesを使用します。アジャイルツールを使用すると、次のようにユーザーストーリーとタスクを階層的に整理できます。

エピック>機能>ユーザーストーリー>タスク/バグ

高校生とアドバイザーのためのStudent Org（クラブ）管理システムを設計しているとしましょう。学生とアドバイザーはクラブに参加したり、役員になったり、イベントを企画したり、お知らせを送信したりできます。

アナウンス機能を例に見てみましょう：

ユーザーストーリー：

• 学生として、自分が所属しているクラブのお知らせを読んで、スケジュールの変更を認識したいと思っています。
• アドバイザーとして、自分が所属しているクラブの告知を読んで、スケジュールの変更を認識したいと思っています。
• アドバイザーとして、所属するクラブに通知を送信して、生徒がスケジュールの変更を認識できるようにしたい
• 管理者として、すべての学校のクラブにアナウンスを送信して、スケジュールの矛盾を認識させることができます。
• 等

これらが適切に記述されたユーザーストーリー（そうではない可能性があります）であると想定すると、開発チームとこれらの項目を開発タスクに分割するために座るときに混乱します。複数のユーザーストーリーの一部を単一の開発タスクでカバーできます。たとえば、お知らせのプロパティを定義するだけで、UIからDBまでのすべてのレイヤーのCRUDアクションを生成するツールがあります。したがって、いくつかの「送信」および「読み取り」ユーザーストーリーの部分は、単一の開発ステップで完了します。

私が読んだことから、各ユーザーストーリーは他のユーザーストーリーから独立している必要があり、それは理にかなっています。ただし、ユーザーストーリーのそれぞれが「UIとDBを生成する」タスクを共有しています。これは、この方法で（カスタマイズする前に）ベ​​ースレベルのUIを作成するためです。ユーザーストーリーごとに「UIとDBを生成する」タスクを書くべきではありません。冗長性が高すぎます。しかし、ユーザーストーリーを開始する前に完了する必要がある「UIとDBを生成する」タスクの記述方法がわかりません。

私の許可システムにも同様の混乱があります。Student、Adviser、Adminなどのさまざまなアカウントタイプがあり、すべて[お知らせ]ページにアクセスできますが、ページ内の機能は異なります（このアイデアは上記のユーザーストーリーでキャプチャしました）。アクセス許可システムを他の機能で使用できるようにモジュール化することもできますが、「モジュール化されたアクセス許可システム」を作成するタスクをどこに書き込むかわかりません。

このユーザーストーリー全体が混乱しているようです。はい、それはシステムの機能をキャプチャするのに最適ですが、開発タスクを通して考えるとなると、私はそれに頭を抱えているようには見えません。どんなアドバイスでもいいでしょう。

TL; DR：あるユーザーストーリーで行うプログラミングの一部は、他のユーザーストーリー（アクセス許可システムなど）のプロジェクトの他の場所で使用できます。この可能性を説明するために、ユーザーストーリーのタスクを作成/整理するにはどうすればよいですか？

ユーザーストーリーごとに「UIとDBを生成する」タスクを書くべきではありません。冗長性が多すぎます。しかし、ユーザーストーリーを開始する前に完了する必要がある「UIおよびDBの生成」タスクの記述方法がわかりません。

あなたはしません。

ユーザーストーリーは、高レベルのユーザーニーズとして記述します-ここまでです。

次に、最初に取り組むユーザーストーリー（機能）を選択します。この時点で-製品の現在の状態を考慮して-この機能を実装する最善の方法を決定します。次に、機能の実装に必要な最小限の技術的作業を行います。次に、次のユーザーストーリーに進みます。

これは次のようにうまくいくかもしれません：

• ユーザーストーリー1を行い、データベースが必要であることを確認します。データベースを実装してから機能を実装します。
• ユーザーストーリー2を行うために座って、それを特定します-ちょっと-データベースが既にあるので、UIを拡張する必要があるだけです。

または、あなたの例では次のようにうまくいくかもしれません：

• アナウンスの送信を実装するために座っています。テキストボックスと、フォームを投稿する送信ボタンを備えたUIを作成します。バックエンド、何も起こりません。涼しい。ユーザーストーリーが完了しました。
• 今度は、アナウンスの受信を実装するために座っています...送信されたときに、彼らと何かを始める時が来たと思います。

このプロセスの全体的な目的は、すべてを事前に設計しようとするのを防ぎ、ソフトウェアの現在の状態を考慮して、次のことを実装する方法について十分な情報に基づいて決定できるようにすることです。これは、ストーリーを開始する前にすべてのストーリーを技術的なタスクに分解しようとすることと直接互換性がありません。

したがって、ストーリーをピックアップして一度に機能の設計を進化させて初めて、ソリューションを設計します。ストーリーの作業を開始した後、技術設計をどのように文書化するかは、あなた次第です。

2人の開発者が同時に2つのストーリーを取り上げ、両者が技術要件を共有している場合、それらの作業を並行して行うことはできないため、1つを選んで他の開発者に別のことをしてもらいます。

ここでの目的は、単純なソリューションを実装し、新しい要件が発生したときに設計を修正することです。

そして、最も重要なこととして、これは科学ではありません。

優先順位の付いたストーリーのリストで各スプリントを入力し、各ストーリーが個別の技術タスクに分割されている場合、すべての開発者は、2番目に優先度の高いストーリーの作業を開始する前に、最も優先度の高いストーリーのタスクに取り組む必要があります。このため、2番目の優先ストーリーの作業を開始するまでに、「UIとDBの生成」タスクは最初のストーリーの一部としてすでに完了しているはずです。したがって、スプリントの計画中に、1つの技術的なタスクが複数のストーリーに重複していることがわかった場合は、そのタスクを最も優先度の高いストーリーに割り当てて、最初に完了するようにします。

スプリントが開始された後、チームがストーリーの優先順位を再調整する習慣を持っている場合、各ストーリーに重複する技術タスクを含め、他のストーリーがそれを使用するタスクについてメモをとることにメリットがあるかもしれません。

ストーリーのリストではなく、技術的なタスクのリストから作業するという考え方に入るのに役立つ場合があります。