ユーザーストーリーに子ユーザーストーリーを含めることはできますか？
私は既存の医療ソフトウェアの更新に取り組んでおり、一部のエンドユーザーと一緒にユーザーストーリーを定義しました。医療環境に慣れていない場合：通常、医師には複数の患者がいます。各患者には複数のケースがあります（足の骨折、皮膚病など）。医学的には、患者が治療されるとケースはクローズされます。これは、数日後に発生する可能性があり（病気）、場合によっては数週間または数か月（たとえば、理学療法が関与している場合）。ただし、ほとんどの医療ソフトウェアでは、ほとんどの医療保険はクローズされたケースに対してのみ支払うため、請求のために事前定義された期間（数日または1か月後）が経過した後、ケースをクローズする必要があります。
ここのほとんどの病院やクリニックの医師は、患者と相談するときに標準化されたフォーム、APEフォーム（年次身体検査）を使用します。
ソフトウェアのUIはあまりユーザーフレンドリーではないため、私の仕事の大部分はユーザーエクスペリエンスを向上させることです。現在のバージョンのケースのUIは、APEフォームとは非常に異なって見え、特に新しい医師は、そのためUIに問題があります。したがって、UIを変更して、APEフォームのように見せたいと思います。現在、次の2つのユーザーストーリーがあり、2番目のユーザーストーリーは1番目のユーザーストーリーの子のようです。
最初のユーザーストーリー：
医師として、私はソフトウェアのケースがAPEフォームのように見えることを期待しています。
2番目のユーザーストーリー：
医師として、患者の病歴全体を確認し、医療データの概要をすばやく確認したい（添付資料を参照）
これは正しいです？これまでに取り組んだすべてのプロジェクトで、ユーザーストーリーは常に完全に独立している（親を意味しない）か、機能の子でした。そのため、ユーザーストーリーが別のユーザーストーリーを子として持つことができるかどうかはわかりません。
あなたはこれを考えすぎていると思います。
最終的な目的は何ですか？あなたはビジネスに質の高い成果を届けようとしているのですか、それとも手紙の方法論に従っているのですか？
さて、正気な世界では、答えは明白であり、問題を明確かつ明確に説明する方法で要件を指定することをお勧めします。したがって、サブストーリーは問題ありません。私が開発者だったとき、あなたの意図を理解してそれを提供することに問題はなかったでしょう。
それほど一般的ではない世界では、パッシブアグレッシブな開発者に抜け穴を探して悪用させ、欠陥追跡システムが開発者よりも分析に起因する多くの欠陥を示すようにすることができます。または、必要なものではないにも関わらず、指定したものを巧みに巧みに配信し、運賃を請求してギャップを埋めることで、より多くのお金を稼ぐ外部ベンダー。この世界に住んでいる場合は、開発チームが受け取ることを期待している方法論に仕様が準拠していることを完全に確認する必要があります。
したがって、正しい答えは、政治的背景と合意された方法論の2つに依存します。疑問がある場合は、半日かけてfewネストされたユーザーストーリーを作成し、レビューのために開発チームに提出してください。彼らはあなたが30分以内にあなたが立っている場所をあなたに知らせることができるはずです。
さて、これがアジャイルの問題です。2日間の証明書を販売している人は誰も教えてくれません。
私のチームではうまくいくかもしれませんが、あなたのチームではうまくいかないかもしれません。アジャイルソフトウェア開発の全体的なポイントは、実験を通して、チームに何がうまくいくかを理解することです。
そのため、できるだけ安価に実験を行ってください。この方法で1つのストーリーを作成します。完了したら、チームに何が良かったか、何が悪かったか、実験を続行すべきかどうかについて話し合います。
個人的にはあなたがサブストーリーをできないことができない理由はわかりませんが、ストーリーが個別に配信するのに十分なほど独立しています。それを念頭に置いて、実際に試してみて、戻って結果をここで回答として共有してください。
あなたのシナリオは親子関係のように聞こえませんが、単純な依存関係です。 2番目のストーリーは、最初のストーリーが完了するまで完了できません。実際には、書かれているように依存していません。 APEフォームがなくても、「すべての病歴を見る」というストーリーを確実に完成させることができます（APEフォームが「病歴全体」でない限り） 。
おそらくこれを見るより良い方法は、関係を逆にすることです。次のように表現できる叙事詩が1つあるようです。
エピック：医師として、患者データの全病歴を確認し、医療データの概要をすばやく確認したい（添付資料を参照）
次に、その叙事詩を複数の独立したストーリーに分解します。
- ストーリー：医者として、私は病歴の各部分を見ることができるツールが必要です
- ストーリー：医師として、病歴ビューアにXを含めたい
- ストーリー：医師として、病歴ビューアにYを含めてほしい
- ストーリー：医師として、病歴ビューアにAPEフォームを含めてほしい
- 物語： ...
リリースとスプリントの計画の一環として、依存関係に基づいてストーリーを注文できます。何も表示せずにビューアを作成してから、ビューアに何かを追加できます。または、ビューアに取り組む前に、履歴の個々の部分を書き込むことができます。それはあなたのチームです。依存関係を処理するための最良の方法を彼らに決定させてください。
それは常にアジャイルで起こります。実際、これは正常なケースであると主張することができます。ストーリーは孤立して存在することはできません。レポートを作成するストーリーを完了するまで、レポートを印刷するためのストーリーを作成することはできません。レポートを保持するデータベースを構築するまで、レポートを作成することはできません。等々。
したがって、全体像をまず「すべての病歴を確認する必要がある」と考えてから、それを一口サイズに分解します。 「APEを含めるには病歴が必要です」など。これらのストーリーが相互に依存するのは自然なことであり、その事実を変えることはできません。ストーリーを書く目的の一部は、それらの依存関係を可視化することです。
これは非機能要件です。 2番目のユーザーストーリーは、機能要件を表しています。それらは実際には関連しているとしても、2つの別個の要件です。より明確な例：
- （機能的）ユーザーはXを要求できます。
- （機能しない）システムは1分あたり1,000リクエストを処理できます。
これがあなたがやりたいことなら、これをユーザーストーリーとして表現できます（これを行う方法に関するアドバイスの最初のGoogle結果： https://www.mountaingoatsoftware.com/blog/non-functional-requirements- as-user-stories ）。