システム内部要件のユーザーストーリーを作成するにはどうすればよいですか？
システムのいくつかの要件は、システム自体または開発者向けですが、これについてユーザーストーリーをどのように記述すればよいですか？
たとえば、システムには次の要件があります。
- パートナーアプリがAPIと対話できるようにAPIを提供します。
- aPIは、さまざまなアプリに対応できる柔軟性と豊富さを備えている必要があります。
最初のユーザーストーリーを以下のように記述できます。
パートナーとして、システムが提供するAPIを呼び出して、システムに追加機能を構築できるようにしたいと考えています。
しかし、2つ目は、書き方がわかりません。新しいパートナーのために新しいAPIを開発する必要がないように、開発者にはより多くのメリットがあるようです。
編集：
私が提供した例は、良いユーザーストーリーではありません。多くの人が指摘するように、彼らは広すぎるか曖昧です。ただし、システム内部の要件に合わせてストーリーを作成する方法という私のポイントに注意してください。
私が回答からこれまで見た2つの意見：
- ユーザーに面していない人は、ユーザーストーリーを必要としません。ユーザーストーリーはユーザーについてです。
- 非機能要件またはシステム制約をユーザーストーリーとしてキャプチャできます。ユーザーは、システム開発者のような関係者です。
どう思いますか？
あなたの例はあいまいです 非機能要件 相互運用性に関連しています：
- 相互運用性とその方法（API）を提供する必要があると漠然と述べています。
- この相互運用性がいかに優れているかを漠然と述べています。
しかし、それは現実です。プロジェクトの開始時、人々は自分たちが何を必要としているのかを正確に知ることはほとんどなく、この問題について彼らを助けることが私たちの仕事です。
ユーザーストーリーとしてのバックログで非機能要件を採用するかどうかについては、いくつかの論争があります。
Mike Cohn 、ユーザーストーリーのリファレンスである このアプローチを擁護する そして、そのような要件は可能な設計に制約を作成し、考慮に入れる必要があることを説明します。彼は、「ユーザー」がもはやエンドユーザーではなく、関連する利害関係者になることを推奨しています。あなたはそれらを特定しました：1）のパートナーと2）のパートナーの開発者。
もちろん、あなたの要件は当面のあいまいな願いだけです。それらで何も作ることはできません！それは、ユーザーが「従業員として、ソフトウェアを簡単に使用できるようにGUIが欲しい」と言っているようなものです。
実際には、これはストーリーがまだ準備されていないことを意味します。幸い、私たちは機敏であり、これによってバックログでのグルーミングが妨げられることはありません。
ユーザーストーリーは単なる 会話のプレースホルダー
したがって、最初のストーリーをバックログにプレースホルダーとして入れ、これらの会話をできるだけ早く保持して、APIを開発してテストするのに十分なレベルの正確さで、本当に必要なものをより明確に把握します。
あなたの特定の例では、良い要件も良いユーザーストーリーもありません。 traditional または agile の観点から見ると、単に「パートナーアプリにAPIを提供する」または「APIを柔軟で十分にリッチにする」と言うのは適切な要件ではありません。
私の提案は、ユーザーが直面していないものに対してユーザーストーリーを記述しないことです。ユーザーストーリー形式は、システムのニーズ、欲求、期待を捉える唯一の方法ではありません。ユーザーストーリーを分割および分解する方法はいくつかありますが、ユーザーストーリーはユーザーに関するものでなければなりません。 1つのアプローチは、ユーザーストーリーを小さなタスクに分割し、ユーザーストーリー全体を提供することです。別のアプローチとしては、ビルド可能、テスト可能、成果物、および配置可能な作業単位を識別し、それらがユーザーから見えなくても、有効化作業として扱うことが考えられます。
あなたは俳優が誰であるかを特定する必要があります。この場合、APIと対話するのは外部システムです。まず、外部システム（パートナーアプリ）で実行できるようにすること、つまり、クエリや読み取り、更新、削除、および作成を可能にすることをキャプチャすることから始めます。必要に応じて、これらをユーザーストーリーとして表現できますが、別の形式も検討できます。
APIの背後で公開したいものを理解したら、改良と分解を開始できます。おそらく、公開されたもののいくつかは、リアルタイムで完了することができない長期実行タスクであり、キューイングおよび処理ワーカーを構築する必要があります。おそらく、認証と承認を処理する必要があります。これらのいくつかは、個別にビルドおよびテスト可能であり、ユーザーが定義およびキャプチャする作業である必要がありますが、その他は新しいAPIエンドポイントの公開の一部として行われます。
ここでの主な問題は、サードパーティの開発者をシステムのユーザーとして扱っていないことです。
場合によっては、ユーザーがエンドユーザーではないことがあります。時々彼らは開発者です。 「ユーザー」をサードパーティの開発者として再定義すると、実際に動作をより小さく管理しやすいチャンクに分解することができます。
動作は、ユーザー向けのメインアプリケーションが必要とするものに沿う可能性がありますが、それらはseparateエンドユーザーに焦点を合わせたユーザーストーリーであり、その前提条件は開発中のAPIです。
最後に、そして最も重要なこととして、差し迫ったニーズがある以上にビルドしないでください。拡張可能な何かを構築することには何の問題もありませんが、顧客がその拡張を必要とするまで、拡張しないでください。 APIストーリーを厳密に絞り、質問で述べたような一般的なストーリーは避けてください。