ユーザーストーリーを開発者間で共有する必要がありますか？[閉まっている]

私は一般的に、バックエンドおよびフロントエンドの開発があるストーリーを見ます。たとえば、いくつかのテーブルといくつかの動的コントロールを備えた大きなダイアログを考えてみましょう。複数のストーリーを作成します（各テーブルに1つずつ、動的制御システムに1つずつ）。

その後、開発チームはバックエンドで1人、フロントエンドで1人に分割されます。これにより、バックエンドの人はSQLレイヤーの構造を心配するだけで済み、フロントエンドの人はレイアウトなどに集中できます。バックエンドとフロントエンドの間の最初のインターフェースが合意された後、2人の開発者はスプリントの終わりまでに自分の部分を成し遂げるために注意を集中できます。

それからカオスが来る。誰がどの物語を「所有」していますか？「進行中」とはどういう意味ですか？バックエンドとフロントエンドの2つの別々のストーリーを作成する必要がありますか？もしそうなら、それは機能に基づいたユーザーストーリーのアイデアを壊しませんか？私たちのシステムには「サブタスク」という概念があり、これらの問題のいくつかを緩和します。ただし、サブタスクはさらに複雑になります。もっと良い方法はありますか？これはスクラムを使用する「悪い」方法ですか？

過去数年間、いくつかの場所で何らかの形のアジャイルを使用しています。公式のトレーニングはまだありませんので、間違った用語やイデオロギーはご容赦ください。プロセスを改善する実用的な方法を学ぼうとしています。

「ストーリー」は、顧客の観点から完全なストーリーを表すため、そのように命名されています。フロントエンドまたはバックエンドがなければ、顧客が実行するユースケースパスはありません。

あなたの場合、フロントエンドとバックエンドの両方が単一のストーリーであるべきだと思います。それをタスクに分割します。開発者はさまざまなタスクを所有しています。これらのタスクは、進行中、コーディング完了、モジュールテスト完了などのフェーズを通じて個別に追跡できます。

必ずQAが割り当てたタスクを同じストーリーに含めてください。検証がなければストーリーは役に立たなくなります。QAは、顧客に表示されるエンドツーエンドの統合されたストーリーをテストします。その場合にのみ、ストーリー全体に「完了」のマークを付けます。理想的なアジャイル環境では、実際の顧客または顧客プロキシも実行中のアプリケーションでストーリーを試行し、合意された要件を満たしている場合にストーリーをAcceptedとマークします。

より迅速なフィードバックループが必要な場合は、ユースケースを小さなエンドツーエンド機能に分割してみてください。たとえば、「顧客はショッピングカートを使用して商品を購入できる」などのユースケースではなく、「顧客がショッピングカートに商品を追加できる」などに分割します。上記のようにエンドツーエンド。

編集：私はいくつかのソースで上記のポイントをバックアップしたかった。優れたユーザーストーリーの特徴は、「INVEST」と呼ばれる頭字語で簡潔に表されます。それはビル・ウェイクによって作成され、スクラム運動によって普及しました。特に、ストーリーの項目が独立しており、垂直であることに注意してください。

こことここのいくつかの詳細情報。

誰がどの物語を「所有」していますか？

誰もが物語をつかむ。組織の観点からは、1人が作業に責任を負っています。2人を獲得したら、簡単にお金を渡すことができます。

バックエンドとフロントエンドの2つの別々のストーリーを作成する必要がありますか？もしそうなら、それは機能に基づいたユーザーストーリーのアイデアを壊しませんか？

場合によります。私は両方の方法が機能するのを見てきました。ストーリーが2人の開発者がフルタイムで作業するのに十分な大きさである場合、多分それは分割されるべきです。2人の開発者が2つの異なるチームの一員である場合、分割する必要があるかもしれません。2人の開発者が異なるスプリント中に作業する場合は、分割する必要があります。

これはスクラムを使用する「悪い」方法ですか？

覚えておくべき重要なことは、プロセスはあなたに役立つためのものであり、その逆ではないということです。ユーザーストーリーは、技術者と非技術者がコミュニケーションを容易にする方法です。彼らは彼らが望むものを綴り、誰もが交渉し、そしてあなたはその進歩についてのストーリーでフィードバックを提供します。

プロセスがあなたのために働いている限り、それはそれほど悪いことはできません。

スクラムモデルを実装した場合、複数の開発者が単一のユーザーストーリーに関与する可能性が完全に予想されます。データレイヤー、統合、フロントエンドCSS、インフラストラクチャなどの作業が行われる場合があります。チームは、ストーリーを完成させるためのさまざまなサブタスクで団結できます。

そうは言っても、1人がストーリーを所有し、ストーリーの進行状況を更新し、すべての人が自分の作品を完成させ、一緒に作業していることを確認する責任があります。これは、ストーリーが「完了」したことを報告する私たちにとっての人です。

他の人が提案したように、私のチームもユーザーストーリーをタスクに分割します。ソフトウェア（JIRAやRallyなど）を介してユーザーストーリーを管理している場合、これは一般的に簡単です。そうすれば、ストーリーのどの部分が進んでいるかを簡単に知ることができます。

しかし、タスクの代替手段は、各人がそれぞれの役割を終えたときに所有権を再割り当てすることです。そのため、ストーリーは回覧されます。おそらく、開発者1がバックエンドの作業から始めてから、開発者2に渡してUIを実行します。その後、確認のためにQAテスターに​​渡されます。この方法は、壁で実際のカードを使用している環境や、ソフトウェアがタスクを追跡しない場合にうまく機能するはずです。

しかし、いずれにせよ、チームがテストを含めて完了したことに同意するまで、ストーリーを「完了」と呼ぶことはお勧めしません。そうすれば、誰もが意見を述べる機会を得ることができます。そして、これを集合的なコード所有権とコードレビューに関するアイデアと組み合わせると、とにかくすべてのストーリーは本当にチームによって「所有」されます。途中で別の人に「割り当てられる」かもしれませんが、誰かが外出した場合（病気/休暇/会議が多すぎますか？

私のチームは、朝のスタンドアップ/ SCRUMミーティングの一環として、ユーザーストーリーをよく受け入れます。そうすることで、誰もがそれが本当に「完了」したかどうかを簡単に確認または異議を唱えることができます。また、QAエンジニアにそれを許可する場合もあります。テストと動作に満足し、すべてのタスクが完了した場合は、完了と呼びます。

私が今日いる場所では、この大きなプロジェクトを「エピック」と呼んでいます。エピックは複数のストーリーで構成され、複数のスプリント/反復にまたがることができます。私たちにとってストーリーは常に単一の開発者に与えられ、単一のスプリントに収まる必要があります。次に、1つのストーリーがタスクに細分化されます。各タスクは、そのストーリーの同じ開発者によって完了されます。タスクは、スプリント/イテレーション中のストーリーの進行状況を洞察することを目的としています。各ストーリーが完了すると、各開発者によって、叙事詩は進行状況を示します。

叙事詩のポイントは、単一のスプリント/イテレーションに必ずしも適合しない、より大きな目標を持つことです。時間が経つにつれて、すべてのストーリーが完了し、叙事詩が終了します。エピックはリリースに配置されます。

それからカオスが来る。誰がどの物語を「所有」していますか？「進行中」とはどういう意味ですか？

2週間ごとにコードをデモし、スプリント/イテレーションのストーリーを利害関係者に見せて承認する必要があります。この文脈では、ストーリーの「完了」とは、それが何をするかを示すことができることを意味します。開発者は自分のストーリーを所有し、それを表示する責任があります（この部分は単純化しすぎていますが、この答えには十分です。1人でデモを調整します）。「完了」は、それを正常に実証できることを意味します。「進行中」とは、未処理のタスクがあり、ストーリーが完全ではないことを意味します。叙事詩は、その叙事詩のすべてのストーリーが正常に実証されたときに完了します。

今、これは完璧なケースの進行です。失敗するストーリーやデモ、他の何かを必要とするユーザーなどがあります。上記が目標であり、その大部分が機能します。