アジャイル-ユーザーストーリーの定義[終了]

Question

友人のビジネス用の小さなアプリを書いているので、この年の初めに行ったアジャイルプロジェクト管理のトレーニングをブラッシュアップする機会を得たいと思いました。

私（そして私の現在の組織だと思います！）は常に、ユーザーストーリーの形式で要件を収集することに苦労しています。

[ユーザーの種類]として[機能]が欲しいので、[いくらかの利点]

私は常に常に最初と最後を逃してしまい、機能をそのまま残したいのですが、これは古い方法を集める要件になります！

しかし、「アジャイルをやっています」と言うことができるように、単にフィットさせたくありません。たとえば、ユーザーにアイテムのリストが表示されることがわかっている場合、理由は自明ですよね？

e.g。

[ストアマネージャー]として、[ストックアイテムのリストを表示]するには... ...

[so that]句を省くことは通常の習慣ですか？

Answer 1

以前も見逃していました。そして、それを除外することで、多くを逃しました。 機能を適切に理解し、正しいことを行うだけでなく、正しいことを行うには、機能を使用する理由を知ることが重要です。そのために、次のキーはWHO（役割）です。 DDDの用語では、利害関係者。利害関係者は、気にする人ごとに異なります。プログラマーとデータベース管理者からすべてのタイプのユーザーまで。

だから、最初に誰が利害関係者であるかを理解し、次に彼が気にする理由の50％を知っていて、それから利益を知っていて、それからすでにほとんど明らかに何を実装するかです。

「ユーザーとして」とだけ書かないでください。指定してください。 「ストアマネージャーとして」、または「終業の責任者であるシフトのリーダーとして」も必要です。

おそらく、同じ利害関係者にさらに良い利益をもたらす異なるものを実装できます!!!

Answer 2

[ユーザー]として[ビジネス価値]を達成するには、[機能]が必要です。

目標は、機能が提供する価値に焦点を当てることです。垂直スライスで考えるのに役立ち、純粋な「技術的なタスク」を減らします。それは見えません。簡単な移行ではありませんが、垂直に考え始めると、プロセスの無駄を本当に減らすことができるようになります。

別の方法は、機能が機能することを確認するために顧客が作成できる受け入れテストを考えることです。これらのテストを自動化するために FitNesse のようなものを使用することへの短いジャンプです。

Answer 3

いいえ、それは実際には明らかではありません-リストを表示したい理由はたくさんありますし、リストで必要なものがたくさんあります-情報をスキャンして概要を取得し、印刷して、コピーして貼り付けてくださいそして、それが正確に何であるかは、合理的な実装の詳細-リストのフォーマット、正確なコンテンツに関する貴重なヒントを提供します。または、別の機能がそのニーズを満たすためのより良いアイデアかもしれないというヒントですらあります。理由が実際に「エントリの数をカウントできるようにするため」だということに驚かないでください...

もちろん、これは実際にはあなたには当てはまらないかもしれません。実際に私の実際のポイントは、人々がこのテンプレートを思いついた理由があるということです-そして、多くの経験豊富な人々が実際にそれを使用しない理由もあります。また、練習に慣れていない場合、練習に従うことのすべての長所と短所を評価するのに適した立場にないので、しばらくの間それを厳密に追うことを強くお勧めします。あなたはその有用性に驚くかもしれません-その場合でも、あなたはまだ何かを学び、明確で簡潔にそれを落とすことができます...：）

Answer 4

ユーザーストーリーは、ユーザーにインタビューして、ユーザーが何を望み、どのような問題を解決しようとしているのかを調べる必要があることを示す別の方法です。これがアジャイル開発の中心です。フォームが機能していない場合は、一歩下がって、より自然に感じるか、ライターとしての能力に適した別のアプローチを試してください。

要するに、あなたはまっすぐなジャケットを着なければならない気がしないでください。重要なことは、方法論の精神に従うことです。

この特定のケースでは、ユーザーがどのような問題を抱えているのか、なぜ問題なのか、そして何が彼らを助けてくれると思うのかをリストしたい。

Answer 5

明白なように見える場合でも、本当に定義された理由を取得しようとすべきだと思います。理由がわからない場合、最初に機能を構築する理由は何ですか？また、理由は、他の領域の改善を引き起こす可能性のある設計の他の欠陥を指摘する場合があります。

Answer 6

多くの場合、主に関係するユーザー/ペルソナでストーリーを分類します。そのため、ストーリーのタイトルにユーザーの身元を入れません。私の話はまた、いくつかのアジャイル方法論が示唆するよりも大きい。通常、タイトルから始めます。計画の目的で使用します。実際にそのストーリーの作業に近づいたら、基本的なアイデア、制約、仮定、関連するストーリーなどの詳細を具体化して、それについて知っている情報をより多く収集します。また、ノートカードではなく、Wikiにストーリーを保存します。トレードオフは理解しています-つまり、必要になる前に詳細に時間をかけすぎる可能性がありますが、通常はオフサイトの顧客と簡単にキャプチャして共有することができます。

私にとって一番重要なことは、アジャイルは仕様ではなく哲学であるということです。特定の方法で何かを行うことを（強く）示唆する特定の実装があり、一部のアイテムでは交渉できない場合があります。たとえば、プログラムをペアにしないとXPを実行していると言うのは困難です。しかし、一般的には、ほとんどのアギリストは、あなたがあなたのために働く方法で、あなたのために働くそれらのことをするべきだと言うでしょう-彼らが一般的な原則と一致している限り、あなたはまだ呼び出すことができます自分でアジャイル。一般原則には、早期リリース/頻繁なリリース、単体テスト、短い反復、変更が発生することの承認、実装の準備が整うまで詳細な計画の遅延などが含まれます。

一番下の行：ユーザーと理論的根拠がなくてもストーリーが機能する場合-ユーザーが誰であり、なぜ彼らが何かを望んでいるのかを理解している限り-好きなようにやりましょう。実装を開始する前に完全な仕様を要求しないでください。