開発者はユーザーストーリーの詳細をどの程度期待できますか？
私が経験したアジャイル開発の最大の欠点は、開発に関与していない人々は、ユーザーストーリー（理想的な3〜10日）に次のような1〜3を超える文を含めないというマントラに焦点を当てることです。
顧客として、フリーテキスト検索を使用して、探している製品を見つけることができます。
この文章を与えると、プロジェクトマネージャーは、開発者としての私に見積もりに取り組み、ストーリーを展開することを期待しています。彼らは、アジャイル開発は、このような文が開発者に提供しなければならないすべてであることを意味すると想定しています。
アジャイル開発に関する有名な文献は、これが実際に機能するだろうという印象を生み出しているので、私はそれらを非難しません。 『Planning XP』では、ストーリーごとに2ページを自然言語で読んだことがありますが、それだけです。 「実用的なソフトウェア」は「包括的なドキュメント」よりも好まれているため、このトピックは一般に回避されているようです。
もちろん、現実には、開発者にそうする機会が与えられた場合、顧客とのインタビューにより、顧客がストーリーについて持っている要件の長いリストが表示されます。
- ANDやORなどのブール演算子が必要です。
- すべての用語のあいまい検索が必要です。
- 単語だけでなく、フレーズでも検索する必要があります。
- 基準X、Y、Zを満たす製品を見つけたくありません。
- 結果を並べ替えたい。ああ、ところで、ユーザーはオプションa、b、cを含むコンボボックスで並べ替え条件を選択できます。
つまり、私が技術的な詳細やソフトウェアの設計、さらには実装の詳細について話しているのではないことがわかります。それは純粋な要件です。私たちが話す時間が長くなるほど、顧客は自分が何を望んでいるかについて実際に言うべきことがたくさんあることに気づきます。
しかし、多くの場合、そのような情報が提供されていない、または非常に粗末な方法で自分を見つけます。私が面接を行うことも、面接を行う立場にある人が結果を提供することもできません。
マネージャーは、「Lucene検索が必要」などの技術的な詳細を思い付くこともありますが、製品名のみ、または製品の説明のみを検索するかどうかについては考えたくありません。時々私は彼らがただ怠惰だと思う;）
私にとって、これは私が携わっているプロジェクト（e-business Webアプリケーション、プロジェクトあたり500〜2000人日）の最大の問題です。私はこの問題に何度も対処してきましたが、マネージャはほとんどの開発者が状況に問題を抱えていることを認識しています。しかし、彼らは開発者があまりにも「完璧主義者」であると信じています。彼らは、開発者が「常にすべてを指定してもらいたい」とイライラしているようです。
一般的に認められている数字がないため、議論するのは難しい。誰もがイテレーションの期間を知っています。しかし、ストーリーを見積もり、展開するために必要な要件は誰にもわかりません。
参考資料はありますか？
アジャイルのポイントが少し不足しています。あなたが呼ぶものaユーザーストーリー、私は少なくとも6つと考えています。必ず、十分な計画を立てて、脱出するのに費用がかかるコーナーに身を投じないようにしてください。ただし、全体的なアイデアは、何らかの価値を提供するために必要な最小限のものを提供し、迅速なフィードバックを得るために十分迅速にそれを行うことです。
このようにストーリーを分割すると、推定が容易になるだけでなく、製品の所有者がよりきめ細かく優先順位を付けることができます。確かに彼らは検索結果を並べ替える機能を気に入っていますが、検索とはまったく関係のないバックログの別の項目ほど重要ではないかもしれません。
また、プログラマーはすべてを指定する必要があるという考えで、顧客の視点から見てみてください。多くの場合、それはあなたが車を購入しようとしているようなもので、セールスマンはフロントガラスのワイパーノブに何色が欲しいか尋ねています。重要だと思われる詳細の多くは、顧客の観点からはまったく無関係です。私は要件が非常に過剰に指定されている場所で働いており、私を信じて、それはとても楽しいものではありません。あなたが不平を言っている種類の寛容さ、多くのプログラマーはそうしたいと思うでしょう。
最初の問題のように聞こえるのは、ユーザーストーリーに時間の見積もりを適用するべきではないということです。ストーリーを取り上げ、「ストーリーポイント」を適用することになっています。これは、1からINFINITYまでの複雑さの一般的な見積もりです。ストーリーポイントは、1、2、3、5、8、13、20のように実行されることがよくあります（各組織には独自のルールがあります）。
1-あなたはあなたの睡眠中にそれを行うことができ、それを実装する価値はほとんどありません。 2-あなたはこれを理解し、オーバーランのリスクがほとんどなく、すぐにそれを成し遂げることができます。 3-あなたはこれを理解していますが、驚きがあるかもしれません。 5-これは少しの調査になり、少しリスクがあります。 8-これは大きなタスクであり、多くの調査が必要であり、スプリントに適合しない場合があります。 13-これは巨大で、間違いなくスプリントに適合しません。大きなリスクがあります。等.
一般に、8以上のユーザーストーリーは、小さなストーリーに分割する必要があります。
これを行うための情報がない場合は、プロジェクトマネージャーに返却し、さらに情報が必要であると伝えてください。
ストーリーをスプリントに受け入れたら、時間を見積もるだけで十分ですが、それでも、これに重点が置かれることはあまりありません。チームがポインティングプロセスに慣れると、ストーリーポイントでスプリントごとの大まかな出力を測定し、そのように計画できるという考え方です。スプリントよりも短いタイムスケールで計画したくない場合。ここでの考え方は、複数のストーリーが1つのスプリントに収まるようにタスクを正しく分解し、1〜5ストーリーポイントの範囲にある場合、それらは十分に定義されているということです。
また、会社のPMは「ストーリー」とは何かを理解していないようです。 「ユーザーストーリー」の重要な部分は終了基準です。終了基準は、このストレージが完了したことをどのように示すことができるかを明確に説明する短い文または2つの文です。理想的には、これはあなたのQA担当者が「はい、私たちはそれをテストできます」と言ったものである必要があります。重要な点は、ソフトウェアが「終了基準」を満たしたときにユーザーストーリーが完了することをPMが理解する必要があることです。 「しかし、私たちはそれを望んでいませんでした」はそれを切りません。彼らが提供されたものを望まなかったが、それが終了基準に一致した場合、彼らは新しいストーリーを入力する必要があります。
ここには確かに「PMのトレーニング」の要素があります。あいまいなストーリーはストーリーポイントが大きくなること、およびストーリーをあいまいに定義して必要なものを取得する場合は、もう一度実行する必要があることを学習する必要があります。
明らかに、利害関係者が十分な情報を収集していない場合は、収集する必要があります。収集しなければならない場合は、作業量が増えるのではないでしょうか。私のアジャイル時代のずっと前に、私は非常に大きな見積もりを出し、情報の欠如によって引き起こされるリスクを考慮に入れるには見積もりが大きすぎると明確に言って成功しました。すべての質問で最悪のケースを想定し、この最悪のケースに基づいて推定しなければなりませんでした。私は、マネージャーがそれを見て、見積もりが下がる結果となったときに、詳細を提供することに意欲的であることがわかりました。
これはシステムのゲームではありません...これは完全に有効です。 「A」と「B」のどちらであるかわからない場合は、お尻をカバーするための最大の見積もりを提供するものに基づいて見積もります。
お客様
商品を検索したい
プロダクトマネージャーお客様のストーリーを分析し、次の要件を考案しました。各要件は、個別のユーザーストーリーとして記録されています。
- 製品を探す
- 結果を並べ替え
- 検索結果をフィルタリングする
開発者プロダクトマネージャーからユーザーストーリーを受け取りました。各ユーザーストーリーを分析し、各ユーザーストーリーのタスクのリストを作成しました。
- 製品を検索
- タスク1：データベースの変更
- タスク2：サーバー側の変更
- タスク3：フロントエンドの変更
顧客、製品マネージャー、開発者はすべて、このプロセスの利害関係者です。彼らはすべて、作業を開始する前に分析プロセスに貢献する必要があります。これは非常に単純化された例であることに注意してください。
ユーザーストーリーは次の順序で分析および洗練されます（もちろん、いくつかのバリエーションがあります）。
ヘルプデスク->プロダクトオーナー->プロダクトマネージャー->部門のリーダー（上級開発者、QAリードなど）->開発者
関連するすべての利害関係者が分析プロセスに貢献したら、ストーリーの提供にかかる時間を見積もることができます。私たちが従う推定プロセスは、個々の開発者の速度と専門知識に基づいています。
これが正しい方法だと言っているわけではありませんが、私たちの組織内では非常にうまく機能しています。
私の経験では、私が取り組んでいる変更やプロジェクトの多くは、まさにこれに対処しています。カスタムXは何かを望んでおり、彼らは彼らが何を望んでいるのかという考えを持っていますが、それらはあなたに小さな電子メール価値のある要件を与えるだけです。それは主にクライアントが何を望んでいるかを「正確に」知らないためです。そのため、クライアントサービス部門の仕事のほとんどは、顧客の要求を具体化し、必要な情報をフィルタリングしながら、クライアントが本当に何を望んでいるか、または本当に必要なものを予測しています。
クライアント（私にとって）が、すべての電話番号のリストを返すWebアプリケーションのセクションを必要としているとします。それらが物理的なもの、論理的なもの、人や場所などに割り当てられたものを意味するかどうかを特定することは決してありません。彼らは単にすべての電話番号を必要としています。開発者として、私はそこに座って、クライアントと同じように、クライアントに尋ねる必要がある12以上の質問について考えることができます。しかし、あなたが言うように、それは不可能です。そのため、製品とクライアントを知っている優れたクライアントサービス部門を持つことは非常に重要です。
この種の電話がクライアントの担当者に届くと、クライアントと一緒に詳しく説明し、適切な質問に回答するために何を尋ねればよいかを理解できます。彼らはまた、クライアントが過去に求めたものを知るための先見性を持っており、クライアントに尋ねることさえせずに何かに「はい」または「いいえ」と言うことができる私たちが開発するシステムについて十分に知っています。
もちろん、あなたとクライアントのサービスの両方が見逃した何かがクライアントに必要な場合はたくさんありますが、それは常に起こります。あなたの目標とクライアントサービスの目標は、何かを開発してから、必要な変更を加えてクライアントから何かを取得するまでの遅延時間を最小限に抑えることです。これは、クライアントサービスとのコミュニケーションとトレーニングにかかっています。
多分それは私がいるところほどはあなたにとって実現可能ではないかもしれませんが、クライアントの担当者との良好なコミュニケーションと信頼があることは、ほとんどの場合、ある程度まであなたを助け、それはあなたの不満を減らし、クライアントの満足度を高めます。また、肩をすくめて「プロジェクトの全範囲がわからないので、どのくらい時間がかかるかわからない」と言うよりも、プロジェクトの時間枠を簡単に与えることができます。ここでも同じ問題が発生しており、コミュニケーションとトレーニングを改善することで、合理的な期限を設定し、一貫して対応することができます。