project-management - 機能要件のユーザー ストーリー

Question

私たちは小さな会社なので、プロジェクトマネージャーと開発者の両方の仕事をしています。私がクライアント向けに作成する仕様には、プロジェクトを説明および定義するために使用される多くの要素が含まれています。これには、クライアントに対してプロジェクトを定義するために含める必要があると思われる他の要素 (ワイヤーフレーム、ユーザーフロー、サイトマップなど) とともに、ユーザー ストーリーが含まれます。

機能仕様が「ユーザーの視点から製品がどのように機能するかを完全に説明している。物事がどのように実装されているかは気にしません。特徴について語っています。では、ユーザー ストーリーを使用して Web サイトの機能仕様を定義することに問題があると考える人はいますか? 誰かが実際にこのように機能仕様を作成していますか?

本当に私は自分のゲームを少し上げようとしています.このアプローチが、機能仕様に含まれるべきものについてより厳密な考えを持っている可能性がある大規模なクライアントに適しているかどうか疑問に思っています。確かに現時点では、私たちのクライアントは私たちの文書作成方法によく反応しています。

プロジェクト管理を専門的に行っている人がこれについてどう思うか興味があります。

Answer 1

私は他の何人かの人々が言っ​​たことと対立しています。

最初に私が同意するビット-ストーリーは機能要件を述べるための素晴らしい方法です。私のお金では、エンドユーザーが実際に受け入れる方法で要件を実際に伝達するための最良の方法の1つです。私は、読まれることなく承認される仕様が多すぎるのを見てきました。

それらに追加したいと思うかもしれない1つのことは、パフォーマンス、セキュリティ、データボリューム、監査、アーカイブなどをカバーする非機能要件です。それらはストーリーでカバーすることができますが、すべてのストーリーを横断する方法でカバーする方がよい場合もあります。

大企業に適しているかどうかという点では、これは私が同意しないところです。私の経験では（そして私はShell、American Express、いくつかの多国籍銀行などのプロジェクトを行ってきました）、彼らは多くの場合、中小企業ほど正式ではないので、ストーリーに問題はありません。現実には、大企業のユーザーは、他の場所よりもクラス図やシーケンス図を読むことに慣れている（または興味を持っている）わけではありません。

プロジェクトのサイズと複雑さには、より詳細な要件が必要になる場合がありますが、要件を文書化する方法を決定するときに重要なのは、プロジェクトのサイズであり、会社のサイズではありません。

私にとって最良の要件ドキュメントは、その対象者に適したドキュメントです。私にとって、ユーザーストーリーは、ほとんどの場合、頭に釘付けになります。十分に短く、十分に明確であるため、サインオフすると、何かを意味します。それらを読んで理解しました（100ページの仕様のサインオフとは対照的に、常に実際に読んでいないことを意味します）が、開発者も十分に作業できます。

Answer 2

はい、機能的なニーズに合わせてユーザー ストーリーを使用できます。私はいつもそれをしています、そして何年もそうです。私の意見では、これは非常にうまく機能し、私が使用した他のシステムよりも優れています。

このアプローチは大規模なクライアントにも有効ですか? 全体的な一般化を行うには、いいえ。彼らは、要件を定義するために使用する何らかのシステムを持つ予定であり、おそらくユーザー ストーリーではありません。ユーザーストーリーを持ってくると、現在の慣行との断絶が生じ、それを解決する必要があります。

私は大規模な組織でユーザー ストーリーを使用して成功していますが、それには協調的な努力が必要であり、両者がコミットする必要があります。

Answer 3

あなたが説明しているのは、機能を定義するユースケースのシナリオです。これは、ユーザビリティの観点から必要なものであり、まさにクライアントが理解し、同意するものです。画面のモックアップとフロー ダイアグラムは、クライアントと開発者の両方に確実に役立ちます。

次に、実際の建設に何を含める必要があるかを開発者に指示するために、実装仕様が必要になる場合があります。これの深さは、家のアーキテクチャ/フレームワークおよび方法論/慣習に関する知識を含む開発者の能力によって決定され、詳細が含まれる場合があります。アプリケーションのさまざまな部分に影響を与えるものについて。

また、小規模なチーム (1 人または 2 人の開発者もいます) で作業しており、この場合に必要なのは上記のすべてであると考えています。

はるかに大規模なチームを持つ大企業は、モデリング ソフトウェア、UML ダイアグラム、およびその他のより詳細な仕様を使用する場合があります。あなたが主要な開発者である場合でも、アプリケーションの設計に時間を費やす必要がありますが、設計をレビューしてすべての手続きを要求する人がいない場合は、ソフトウェアの実装に時間を費やしたほうがよいでしょう。