私は非常に複雑な統合ニーズを持つプロジェクトに取り組んでいます。具体的には、EDI データとその間に発生するすべての「楽しい」ものを送受信します。確かに、データ処理 (検証、必須フィールド、変換) に集中することはできますが、問題は、作業を計画および追跡するために、バックログでストーリーと叙事詩を組み立てる方法です。
「マネージャーとして、自分の約束を果たすのに十分な従業員をスタッフに確保できるように、休暇申請を拒否することができます」と言うのは非常に簡単です。実際、私はこれが非常に得意ですが、この種の統合作業は初めてです。
大規模な統合プロジェクトの場合、ユーザーが誰で、どのような価値があるかを示すのはより困難です。EDI 統合はインターフェース (非機能) 要件にすぎませんが、実装には多大な労力がかかります。
私が作成している製品バックログでこれらの種類の要件を構造化/フレーム化する方法について、誰かがガイダンスを提供できますか?
マイク・コーンはこれについて何か言いたいことがあります。この最後の段落は非常に関連性があると思います
ただし、そのテンプレートに夢中にならないように注意する必要があります。あくまでも思考ツールです。このテンプレートに制約を加えることは、誰が何をなぜ望んでいるのかを理解するのに役立つため、良い練習になります。紛らわしい文言になってしまった場合は、テンプレートを削除してください。制約を表現する方法が見つからない場合は、自然に感じられる方法で制約を記述してください。
スクラムは、要件をユーザーストーリーとして記述する必要があることを指定しておらず、自分に最適な手法を使用する必要があります。「ASA」タイプのストーリーと戦っている場合は、「IN ORDER TOASAIWANT」を試してください。それが使用されない場合は、ユースケースモデリングを使用してください。
要求は契約ではなく、コミュニケーションのためのプレースホルダーです。ここで重要なのは、計画の目的に十分な情報を用意して、チームに何をしなければならないかを知っているという感覚を与えることです。詳細はスプリントで議論することができます。
このような状況で私が行うことは次のとおりです。
1) 統合のために実装できる最も単純なエンドツーエンド機能を考えてみてください。
2) その統合のユースケースを考えてみてください
3) それをストーリーに変換します (オプションのステップ: ストーリーは物理法則ではありません。役に立つ場合はストーリーを使用します)。
例えば：
1) わかりました - 認証は、実装するのが最も簡単なことのように見えます。
2) ちょっと - 認証自体は便利です。これを使用して、このユーザー グループがデータにアクセスできるかどうかを知ることができます。
3) 「サイト管理者として、貴重な情報が一般に公開されるのを防ぐために、許可されたものだけが Foo にアクセスできるようにしたい」
このようにして、機能のサブセットをカバーするだけで、EDI システムを常に機能させることができます。時間の経過とともに拡張できるサブセット - うまくいけば、ビジネスにとっての機能の重要度の順に並べられます。
しかし、私の本当の好みは、EDI が行われている理由をもう少し掘り下げることです。一般的には、「EDI」は人々が望む機能であるため、そうではありません。これは、システム内の他の機能にEDI が必要なためです。
その場合、個別の EDI プロジェクトを作成するよりも、EDI 層の開発を促進するために必要な EDI を使用したいと考えています。上記の (3) のストーリーは、実際のプロジェクトからのものになります。必要なものを構築し、無駄を省く可能性が高くなります。