象はキリンではなく、ユーザーストーリーは必須ではありません。それらは共通の機能と共通のコンテキストを持っていますが、これはそれらを同一視しません。しかし、多くの人は、ユーザーストーリーは、伝統的にソフトウェア要件と呼ばれるものの一種の新しい読み物であると信じています-結局のところ、プロジェクトには要件が必要ですよね？だから、私は答えます-いいえ、そして再びいいえ。第一に、これらは要件ではありません。第二に、要件は私たちが本当に必要としているものではありません。ユーザーストーリーは、まず第一に、さまざまな実装オプションを確認する機会であるため、後で開かれた機会を利用できます。そして要件...それは事前にすべてを解決することです、それで後であなたはそれに行き詰まります。
そのような記事を書くことに何か意味はありますか？上記は明白ではないですか？いいえ、「バックログの要件」のような頻繁な発言は、思考のパラダイムが同じままであり、兆候が変わっただけであることを示していると思います。要件ドキュメントはバックログ、要件自体、つまりユーザーストーリーと呼ばれるようになり、現在は「機敏」です...
誤解の可能性のある別の兆候は、一意のIDを割り当ててユーザーストーリーをデータベースに保存するという広範な慣行です。これは単に便宜上行われる可能性がありますが、これは要件の観点から考える傾向が根強い結果である可能性があります。
しかし、契約にユーザーストーリーを含める慣行は、ユーザーストーリーが要件と見なされていることを100％示しています。ここでの問題は、定義上、ユーザーストーリーは要件ほど明確にすることはできず、これにより契約の価値が下がることです。もちろん、要件をかなり自由に解釈できる場合もありますが、要件を作成する手法そのものが、最初は、ユーザーストーリーについては言えない曖昧さの排除を意味します。さらに、要件はプロジェクト契約に含まれているため、変更に対して回復力があります。新しい要件を変更または追加するには、それらをCCBに渡す必要があります。言い換えれば、利害関係者は最初に同意して承認する必要があります。契約の詳細については、以下を参照してください。
では、ユーザーストーリーとは何ですか？それらを計画ツールと見なしてください。ユーザーストーリーの助けを借りて、対応する機能を実装するスプリントに優先順位を付け、評価し、決定します。これらはすべて計画ツールの典型的な機能であるため、他のものに変換しようとしないでください。
ユーザーストーリーの力は、対話を生み出すことです。最初に開発者が解釈し、次にテスターが解釈する仕様を同僚に渡して渡すのではなく、ディスカッションを開始します。コミュニケーションのスキルが異なる従業員が含まれます。そして、それぞれの新機能について。
ユーザーストーリー自体はあまり意味がないため、対応する機能の実装後に単純に破棄できます。必要に応じて、実現されたストーリーの数に関する統計を注意深く保持できますが、これはかなり制限される可能性があります。
要件は必要ないことがわかりましたか？実際、これは真実ではありません。結局のところ、何らかの方法で制限があります。たとえば、医療機器はFDA規制に準拠する必要があります。それでは、それらを制約と呼びましょう！
それでも、要件はシステムを詳細に説明しています。おそらく、そのような説明には何らかの価値がありますか？たとえば、正式な要件が何らかの形で提示されていない場合、システムの一部の動作がバグであるかどうかをどのように判断できますか？ここでは、「例による仕様」という手法が役立ちます。そのため、いくつかの機能を実装する必要があることが決定されました。ビジネスルールと一連の例を次のように記述します。a）読みやすい。 b）実現可能。この説明から、システムが何をすべきかが明確になっているはずです。また、変更の結果として問題が発生した場合、どのビジネスルールの違反がこの機能不全の原因でしたか。
前に書いたように、バグの説明は単純で明確でなければなりません。バグは情報を破壊するものであり、特定のケースをカバーする要件の説明があるかどうかに関係なく、バグは悪いものです。
契約する
（Matthias Skarinによる）
では、要件仕様の代わりに何を使用するのでしょうか。結局のところ、必要なものを正確に実装したかどうかを理解する必要がありますか？アジャイル契約を使用します。アジャイル-契約は木の森を見る機会であり、プロジェクトの本質と目標の共同達成に集中することができ、その実装はユーザーのニーズを満たします。
パートナーが何かに違反していないかどうかを確認するためにプロジェクト中に契約について考えるとき、これはすでに何かがうまくいかないことを意味していることを覚えておいてください。契約は、詳細を超えて、当事者に行き詰まらないようにするために、当事者間の信頼を構築する必要があります。
概要
- 象とキリンの両方が4本の足を持っているという事実にもかかわらず、それらは異なる動物です。
- ユーザーストーリーは要件ではなく、計画ツールです。
- 要件に最も近いのは、例による仕様です。