ユーザーストーリーを採用する場合、要件の指定が不要であることをチームにどのように説得できますか？

ユーザーストーリーを採用して、重いSRS（ソフトウェア要件の仕様）ではなく、軽量な方法で利害関係者の「意図」を捉えることを計画しています。ただし、彼らはストーリーの価値を理解していますが、すべての属性、優先度、入力、出力、ソース、宛先などを備えたSRSのような言語にストーリーを「変換」したいという要望がまだあるようです。

ユーザーストーリーは、アーティファクトのような正式なSRSの必要性を "排除"するため、SRSを持つことのポイントは何ですか？システムの機能要件を取得するためにユーザーストーリーを採用した場合、SRSは「排除」されることを私のチーム（ちなみに、教育と実践の両方で非常に有能なCSスタッフ）にどのように説得する必要がありますか？（NFRなどもキャプチャできますが、それは質問の意図ではありません）。

だからここに私の「ワークフロー」の引数があります：ユーザーストーリーとして初期要件をキャプチャし、後でユースケースにそれらを詳しく説明します（これは低レベルでドキュメント化する必要がある、つまりUIプロトタイプ/モックアップとの相互作用を説明し、成果物です）展開）。したがって、ユーザーストーリーからユースケースへと移行するのではなく、ユーザーストーリーからSRSへと移行します。

現在、職場でユーザーストーリーをキャプチャしている場合（ある場合）、ユーザーストーリーが存在する場合にSRSが存在しないことを「主張する」ことをどのように提案しますか？

赤ちゃんのステップ。しばらくの間、SRSの作成を続けます。次に、会議を呼び出し、それらがまだ目的を果たしているかどうかを話し合います。まだ誰も読んでいますか？それらに費やされた時間は正当化されますか？より軽量になる別の中間ステップはありますか？

あなたは決して知りません、あなたはあなたが間違っていることに気付くかもしれません。アジャイルマニフェストを思い出してください。「包括的なドキュメントよりもソフトウェアを機能させること」の方がより価値がありますが、後者にはまだ価値があります。

しかし、私は、ユースケースとユーザーストーリーがどの程度密接に関連しているかを見ると、重いドキュメントを書き続けたいという欲求が失われることにすぐに気付くと思います。

エピックはプレースホルダーです

ほぼすべてのアジャイル方法論では、Epicsの概念は要件仕様に必要なものと同じです。プレースホルダーはそのレベルで必要なものです。これらのエントリには常に優先順位が付けられます。要件の優先度が長期間低い場合、または実装されない場合でも、詳細は無駄な作業になります。それを文書化し、その周りの文書を管理することは、時間の無駄です。YAGNIは、要件アクティビティとコーディングアクティビティにまで及びます。

ツールはあなたの友達です！

適切なツールを使用してユーザーストーリーを収集および管理する場合は、それらから要件仕様を生成できます。要件の仕様はとにかく一時的なアーティファクトドキュメントであり、生きたドキュメントではなく、要件のスナップショットです。そして、現実と同期することはありません。

アーティファクトを自動生成

適切なツールからエクスポートできるユーザーストーリーは、静的アーティファクトドキュメントよりもはるかに価値があります。個人的には、Pivotal Trackerがユーザーストーリーを追跡することを好み、さまざまなストーリーとその状態をすべてWikiに公開するために、PythonでMoinMoinプラグインのスイートを作成しました（ストーリーに関する詳細な開発者メモなどが含まれています）、ライブデータは常に静的データよりも優れています。

Wikiは、すべてのストア/要件、およびそれらの完了状態と優先順位の詳細とコメントおよびその他のメタデータを含むライブドキュメントになりました。

Sharepointの巨大なWord文書よりもはるかに優れており、絶えず電子メールで送信され、更新されることはないため、全員が異なるバージョンを使用し、他の全員と同期していないことが保証されます。

ユーザーストーリーはユースケースよりも豊富です

彼らが言うので、使用ストーリーは、はるかに価値のあるユースケースよりもWHY。

ユーザーストーリー形式：（アクションがフローチャートである）のAs a [ROLE] I [ACTIVITY] so that [WHY]ようなユースケースよりもはるかに表現力がありますThe System [shall/shall not/may/must] perform [action]。

ユーザーストーリーで、あなたは持っているWHOあなたが持っている、何かをやりたいWHAT彼らは（複雑なタスクのためのより詳細な図/文書を指すことができた）やりたい、あなたが最も重要な部分を持っているなぜ彼らはこの活動を行いたいです。

あなたが最初のものを持っているなら、2番目のものは完全に冗長で、せいぜいノイズだけです。ウォーターフォールの方法論による従来の正式な要件仕様は、アジャイル環境では機能しません。

最終的には

あなたの経営陣が変化を約束しないと、新しい方法論で成功することはできません。私は年間1,000億ドル以上の会社で働いてきましたが、彼らはアジャイル/スクラムへの移行に踏み出したわけではありませんでした。彼らはただ、会社全体がこれに移行しつつあります。新しい方法のトレーニングが始まるとき、これから私たちが使用する新しいツールがあります。これは私たちがこの方法で作業を開始する日付です。それはそれらのために1年未満で働いた。私は同じ成功を収めてこれをより小さな会社に実装することに取り組んできました。

コミットメント

ベビーステップの実装は、変更内容に関係なく、失敗のレシピです。それは彼らが静かに同意せず、失敗のためにあなたを受動的に積極的に設定していることは管理者のためのコードワードです。彼らは私がこれを約束するほど信じていないと言っているので、失敗/成功しないように十分にやらせます。そうすれば彼らは彼らが試したがうまくいかず、彼らが管理していた方法はうまくいきましたずっと元気です 部分的なコミットメントは最終的に失敗につながります。

あなたの場合、おそらく彼らは静かにユーザーストーリーを信じていません、そして両方をしばらくすると、彼らはそれが役に立たないユーザーストーリーでありSRSではないと主張し始め、ユーザーストーリーの書き込みを停止するようにプッシュします、前方ではなく後方に移動します。

私はユーモアを使ってみます。

http://www.halfarsedagilemanifesto.org/から始めます

これについてしばらく 話し（転換）
、その中での衝突が本当に何を意味するかについて話し（オープンディスカッション）、
しばらくしてから組織（ピボット）
を見て、SRSを調べ、それが新しいプロジェクトのセットアップで意味があるかどうかを調べます。

次に、アプローチre：SRSの変更についてのディスカッションで（またはおそらく別の会議で）結論を出し、コンセンサスがあるかどうかを確認します。

結局のところ、あなたは予算とビジネス人々にサービスを提供しているという制約もあるので、何が使われるかについて少し固くなっているかもしれませんが、これは実際には、業界、会社の規模、組織的要因、および多くに依存します他のそのような要因。

SMTから離れてユーザーストーリーの使用を開始するようにmgmtを説得することは、基本的にmgmtがAgileを採用するよう説得することと同じです。アジャイルの生産性のメリットに関する説得力のある統計があります。1つの例は、2013年の会議でVersionOneが行ったプレゼンテーションです。この業界データを管理することを示し、それらがリスニングタイプである場合は、チャンスがあります。