私は友人のビジネス用に小さなアプリを書いています。この機会に、今年の初めに行ったアジャイル プロジェクト管理トレーニングを復習しようと思いました。
私 (そして私の現在の組織だと思います!) は、次のような形をとるユーザー ストーリーの形式で要件を収集することに常に苦労してきました。
[ユーザータイプ] として [機能] が欲しい [なんらかのメリット]
私はいつも最初と最後を見逃して、機能をそのままにしておくように誘惑されます-しかし、これは古い方法で収集する要件になります!
しかし、「私はアジャイルをやっている」と言えるように、単に適合させたいわけではありません....たとえば、ユーザーにアイテムのリストを提示する必要があることがわかっている場合、その理由は自明ですね。
例えば
【店長】として【在庫一覧が見たい】のですが・・・？
[so that] 句を省略するのは通常の慣例ですか?
私たちもそれを見逃していました。そして、それを放置することで、私たちは多くを逃しました。機能を適切に理解し、正しいことを行うだけでなく、正しいことを行うには、その機能の理由を知ることが重要です。そのための次の鍵は、DDD 用語で言えば、利害関係者である WHO (役割) です。利害関係者は、関心のあるすべての人が異なる可能性があります。プログラマーやデータベース管理者からあらゆるタイプのユーザーまで。
したがって、まず利害関係者が誰であるかを理解します。次に、利害関係者が関心を持っている理由の 50% を把握し、次に利益を把握します。そして、実装すべきことはほぼ明らかです。
「ユーザーとして」とだけ書かないようにしてください。特定。「店長として」、あるいは「その日の締めを担当するシフトのリーダーとして」、私は必要です....だから....
おそらく、同じ利害関係者にさらに良い利益をもたらす別の何かを実装することができます!!!
[ユーザー] としての [ビジネス価値] を実現するには [機能] が必要です。
目標は、機能が提供する価値に焦点を当てることです。垂直方向のスライスで考えるのに役立ち、目に見えない純粋な「技術的なタスク」を減らします。簡単な移行ではありませんが、垂直的に考え始めると、プロセスの無駄を本当に減らすことができるようになります。
もう 1 つの方法は、機能が機能することを確認するために顧客が作成できる受け入れテストを考えることです。それらのテストを自動化するために、 FitNesseのようなものを使用するのは簡単なことではありません。
いいえ、実際には明らかではありません - リストを見たいと思う理由はたくさんあります。リストを使って見たいと思うことはたくさんあります - 情報をスキャンし、概要を取得し、印刷し、コピーして、ワード文書など。そして、それが正確に何であるかは、合理的な実装の詳細に関する貴重なヒントを提供します-リストのフォーマット、正確なコンテンツ。または、そのニーズを満たすには別の機能がより良いアイデアかもしれないというヒントさえあります。その理由が実は「エントリー数をカウントできるようにするため」であることに驚かないでください...
もちろん、これは実際にはあなたには当てはまらないかもしれません。私が実際に言いたいのは、人々がこのテンプレートを思いついたのには理由があり、多くの経験豊富な人々が実際にそれを使用していない理由もあるということです. そして、あなたが練習に慣れていないときは、練習に従うことの長所と短所をすべて評価するのに適した立場にあるわけではないので、しばらくの間、それを注意深くフォローすることを強くお勧めします. あなたはそれの有用性に驚くかもしれません.
ユーザーストーリーは、ユーザーにインタビューして、ユーザーが何を望んでいて、どのような問題を解決しようとしているのかを知る必要があることを示す別の方法です。これがアジャイル開発の核心です。フォームがうまく機能しない場合は、一歩下がって、自分にとってより自然であるか、ライターとしての能力に適していると感じる別のアプローチを試してください。
要するに、ストレート ジャケットを着る必要はありません。重要なことは、方法論の精神に従うことです。
この特定のケースでは、ユーザーがどのような問題を抱えているか、なぜそれが問題なのか、何が役立つと考えているかのリストを取得する必要があります。
私は主に関連するユーザー/ペルソナによってストーリーを分類することが多いため、ストーリーのタイトルにユーザーのアイデンティティを入れません。また、私のストーリーは、いくつかのアジャイル方法論が示唆するものよりも大きくなっています。通常、私はタイトルから始めます。企画用に使用させていただきます。そのストーリーの実際の作業に近づくと、基本的なアイデア、制約、仮定、関連するストーリーなど、いくつかの詳細を加えて肉付けします。また、メモ カードではなく wiki にストーリーを保存しています。私はトレードオフを理解しています。つまり、詳細が必要になる前に詳細に時間を費やしすぎるかもしれませんが、それをキャプチャして、通常はオフサイトの顧客と簡単に共有できます。
私にとっての結論は、アジャイルは仕様ではなく哲学であるということです。特定の方法で物事を行うことを (強く) 示唆する特定の実装があり、一部の項目については交渉の余地がない可能性があります。たとえば、プログラムをペアリングしないと、XP を実行しているとは言えません。ただし、一般的には、ほとんどのアジャリストは、自分に役立つ方法で、自分に役立つことを行うべきだと言うでしょう。一般原則と一致している限り、呼び出してもかまいません。自分が機敏に。一般的な原則には、早期リリース/頻繁なリリース、単体テスト、短い反復、変更が発生することの認識、実装の準備が整うまで詳細な計画の延期などが含まれます...
要するに、ストーリーがユーザーや理論的根拠がなくても機能する場合は、ユーザーが誰で、なぜ彼らが何かを望んでいるのかを理解している限り、好きなようにやってください。実装を開始する前に完全な仕様を必要としないでください。
たとえそれが明白に思えるかもしれませんが、あなたは本当に明確な理由を得ようとするべきだと思います. 理由が思いつかない場合、そもそもなぜ機能を構築するのでしょうか? また、その理由は、他の領域の改善を引き起こす可能性のある設計の他の欠陥を指摘する場合があります。