私はシステムの所有者と私自身の両方が開発者であるシステムを書いています。現在、システムへの「要求」またはシステムの要件の唯一の情報源であり、機能に関連付けられたユーザーストーリーにそれを記録したいと考えています{1}。私の緊急の優先事項は、現在、管理可能なバックログを取得することです。ユーザーストーリーでの作業に慣れている技術仕様のレベルをキャプチャするにはどうすればよいですか。
{1}アジャイルプロジェクト管理サービスTargetProcessを評価しています。各ユーザーストーリーは親機能に関連付ける必要があります。システムは適切だと思われるので、この小さな制約は、回避するよりも私が作業したいものです。
回答:
As a [ROLE] I need to [WHAT] so that/because [WHY].
興味深いのは、コンポーネントの重要性が逆転していることです。
WHYはWHATよりも重要であり、それはROLEよりも重要です
ソフトウェア開発者として、ユーザーストーリーの書き方を学ぶ必要があります。これにより、バックログにドラフトを入力して、機能のディスカッションを開始し、機能にポイントを割り当てることができます。
それ以上のことは、ユーザーストーリーの意図と実装を複雑にしています。
ツールを使用して、ポイント/推定を割り当てるためにそれらについて話し合うときにキャプチャされるストーリーに関する追加の詳細情報をキャプチャできますが、その詳細はストーリー自体の一部であってはなりません。ディスカッションの詳細/筆記録を載せる、ストーリーごとに1ページのWikiのような単純なもので十分です。Excelスプレッドシートはひどいソリューションです。
焦点を当てるものだと理由のと避ける方法の書き込みをユーザーストーリーを。
あなたが直面していることは、実際にはすべての開発者にとって非常に良い練習です。要件を単純なビジネス用語で表現できることは重要なスキルです。
コンボボックスやリストボックス、または特定のルーチンをトリガーするものを使用して指定するのではなく、「オブジェクトのドロップダウンリストから単一の選択を行ってユーザーがFooアクションを有効にできるようにする必要がある」などの一般的な要件に焦点を当てる必要があります。
これに取り組む別の方法は、基礎となるコードベース/フレームワークがほぼ完全なブラックボックスであるかのように見せかけることです。「オブジェクトXYZを使用する」と言ったときはいつでも、ブラックボックスシステムでそれを知っているかどうかを尋ねることで、セルフチェックできます。
更新：
IMO、情報に必要な詳細のレベルを示す詳細をユースケースに入れても問題ありません。たとえば、登録システムでは、
姓を指定するのは公正なゲームです。必須フィールド
-名; 必須フィールド
-アカウントID; システムは入力を生成する必要はありません
-占星術の兆候; オプションのフィールド-（提案）生年月日を入力してからルックアップを提供しますか？
-など...。
重要なのは、その情報の技術的な方法を指定していないことです。姓に「Stringクラス/文字配列/またはvarcharフィールドを使用する」と言っている場合は、指定しすぎていることがわかります。
多言語を使用している場合は、リトマステストとして2つの異なる言語を使用します。たとえば、Cの文字列は通常char（acter）配列ですが、C ++、Java、およびC＃（大丈夫、そして他のほとんどすべての人）は実際のStringのようなオブジェクトを持っています。これらの言語の1つを使用して仕様が無効になっていることがわかった場合は、仕様が多すぎることがわかります。
ユーザーストーリーではなく、ユースケースという用語を具体的に使用していることは注目に値しますが、私が使用するバリアントは両方のハイブリッドです。ユースケースの私の目標は、何が起こっているのか（厳密な意味でのユーザーストーリー）の概要を説明することですが、必要なアクター、システム、および一般的な機能に取り組みます。私のアプローチは、コックバーンのアプローチとは対照的に、ウィキペディアの記事でファウラーが提案しているものに近いです。
したがって、登録シナリオまたはワークアイテムのユースケースを1つ（またはその程度）にします。本当に複雑な場合は、それを複数に分割しますが、それは大した問題ではありません。ユースケースは、必要に応じて個々のタスクに分割できます。特定のスクラムに何が投入されるかは多くの変数に依存しますが、このアプローチには、スクラムの最後に実証可能なコンポーネントを配置することを妨げるものはありません。