開発者が期待できるユーザーストーリーの詳細

私が経験したアジャイル開発の最大の欠点は、開発に携わらない人が、ユーザーストーリー（3〜10人の理想的な人の日）が次のような1〜3文を超えてはならないというマントラに集中することです。

顧客として、フリーテキスト検索を使用して、探している製品を見つけることができます。

この文を与えて、プロジェクトマネージャーは私が開発者として見積もりにコミットし、ストーリーを開発することを期待しています。彼らは、アジャイル開発とは、開発者に提供する必要があるのはこのような文だけであると想定していることです。

アジャイル開発に関する有名な文献が、これが実際に機能するという印象を与えるので、私はそれらを責めません。「Planning XP」の記事ごとに自然言語で2ページのようなものを読みましたが、それだけです。「包括的なソフトウェア」よりも「動くソフトウェア」が好まれるため、このトピックは一般的には避けられているようです。

もちろん、現実には、開発者にそうする機会が与えられた場合、顧客とのインタビューによって、顧客がストーリーに関して持っている要件の長いリストが表示されます。

• ANDやORなどのブール演算子が必要です。
• すべての用語でファジー検索が必要です。
• フレーズだけでなく単一の単語でも検索する必要があります。
• 基準X、Y、およびZを満たす製品を検索する必要はありません。
• 結果をソートします。ああ、ところで、ユーザーはオプションa、b、cのコンボボックスで並べ替え条件を選択できます。

技術的な詳細やソフトウェアの設計、実装の詳細についても話しているのではないことがわかります。それは純粋な要件です。話す時間が長ければ長いほど、顧客は実際に彼らが望むものについて多くのことを言うことに気付きます。

しかし、多くの場合、そのような情報が提供されていない状況や、非常に見苦しいやり方で自分自身を見つけます。私がインタビューを行うことも、インタビューを行う立場にある人がその結果を提供することもできません。

マネージャーは、「Lucene検索が必要」などの技術的な詳細を思い付く場合もありますが、製品名だけでなく製品の説明も検索するかどうかを考えたくない場合があります。時々私は彼らがただ怠け者だと思う;）

私にとって、これは私が働いているプロジェクトの最大の問題です（e-business Webアプリケーション、プロジェクトごとに500〜2000人日）。私はこの問題に十分な頻度で対処してきましたが、マネージャーはほとんどの開発者が状況に問題があることを認識しています。しかし、彼らは開発者があまりにも「完璧主義者」であると信じています。彼らは開発者が「常にすべてを指定したい」と悩んでいるようです。

一般的に認められている数字がないため、議論するのは難しいです。反復の長さは誰でも知っています。しかし、ストーリーを見積もり、開発するために必要な要件を誰も知ることができません。

参考資料はありますか？

アジャイルのポイントが少し欠けています。あなたがユーザーストーリーと呼んでいるもの、私は少なくとも6つと見ています：1つは必要最低限​​の検索であり、もう1つはあなたの弾丸ポイントごとです。必ず、逃げるのに費用がかかるコーナーに自分を描くことを避けるために十分な計画を立ててください。しかし、全体的なアイデアは、価値を提供するために必要な最小限のものを提供し、迅速なフィードバックを得るために十分に迅速に行うことです。

ストーリーをそのように分割すると、見積もりが簡単になるだけでなく、製品所有者がよりきめ細かい方法で優先順位を付けることができます。確かに彼らは検索結果を並べ替える機能を気に入っていますが、検索とはまったく関係のないバックログの別のアイテムほど重要ではないかもしれません。

また、プログラマは指定されたすべてのものを必要とするという考えで、顧客の観点から見てみてください。多くの場合、あなたは車を買うつもりで、セールスマンはフロントガラスのワイパーのノブにどんな色が欲しいのか尋ねています。私たちが重要だと感じるかもしれない多くの詳細は、顧客の観点からは完全に無関係です。要件が非常に過剰に指定されている場所で作業しましたが、私を信頼しています。それはあまり面白くありません。あなたが不平を言っている寛容の種類、多くのプログラマーが望んでいます。

最初の問題のように聞こえますが、ユーザーのストーリーに時間の見積もりを適用することは想定されていません。ストーリーを取り、「ストーリーポイント」を適用することになっています。これは、1からINFINITYまでの複雑さの一般的な推定値です。ストーリーポイントは、1、2、3、5、8、13、20などのように実行されることがよくあります（すべての組織には独自のルールがあります）。

1-あなたは睡眠中にそれを行うことができ、それを実装する価値はほとんどありません。2-あなたはこれを理解しており、オーバーランのリスクをほとんど伴わずにすぐに実行できます。3-あなたはこれを理解していますが、驚きがあるかもしれません。5-これは少し研究を行っていますが、多少のリスクがあります。8-これは大きなタスクであり、多くの調査が必要であり、スプリントに収まらない場合があります。13-これは巨大で、間違いなくスプリントに収まりません。大きなリスクがあります。等

通常、8以上のユーザーストーリーは、より小さなストーリーに分割する必要があります。

これを行うための情報を持っていない場合は、プロジェクトマネージャーに間違いを投げ返して、さらに情報が必要であると言う必要があります。

ストーリーをスプリントに受け入れてから初めて時間を見積もる必要がありますが、その場合でも、これを重視することはあまりありません。チームがポインティングプロセスに慣れたら、ストーリーポイントでスプリントごとの大まかな出力を測定し、そのように計画することができます。スプリントよりも短いタイムスケールで計画することは望ましくありません。ここでのアイデアは、複数のストーリーがスプリントに収まり、1〜5ストーリーポイントの範囲に収まるようにタスクを正しく分割している場合、十分に定義されていることを意味します。

また、会社のPMは「ストーリー」が何であるかを理解していないようです。「ユーザーストーリー」の重要な部分は終了基準です。終了基準は、このストレージが完了したことをどのように示すことができるかを明確に説明する短い文または2つです。理想的には、これはQA担当者が「はい、そのためにテストできます」と言ったものである必要があります。重要な点は、ソフトウェアが「終了基準」を満たしたときにユーザーストーリーが完了することをPMが理解する必要があることです。「しかし、私たちはそれを望んでいませんでした」それをカットしません。配信されたものを望んでいないが、終了条件に一致した場合、新しいストーリーを入力する必要があります。

ここには確かに「PMのトレーニング」の要素があります。あいまいなストーリーは大きなストーリーポイントをもたらし、欲しいものを手に入れるために曖昧にストーリーを定義した場合、再びやり直さなければならないことを学ばなければなりません。

利害関係者が十分な情報を収集していない場合は、明らかにする必要があります。必要な場合は、さらに多くの作業が必要です。アジャイルな時代のずっと前に、私は非常に大きな見積もりを出し、見積もりが情報の不足に起因するリスクを考慮できるほど大きいと明示的に言って成功しました。すべての質問について最悪のケースを想定し、この最悪のケースに基づいて推定しなければなりませんでした。私は、マネージャーがそれを見てより多くの詳細を喜んで提供し、結果として見積もりが下がったことを発見しました。

これはシステムのゲームではありません...これは完全に有効です。「A」か「B」かわからない場合は、お尻をカバーする最大の推定値に基づいて推定します。

私の経験では、私が取り組んでいる多くの変更やプロジェクトがまさにこのことに対処しています。カスタムXは何かを望んでおり、彼らが何を望んでいるのかを知っていますが、彼らはあなたに小さなメールに値する要件しか与えません。これは主に、クライアントが何を望んでいるかを「正確に」知らないためです。そのため、クライアントサービス部門の仕事のほとんどは、顧客の要求を具体化し、必要な情報をフィルタリングしながら、クライアントが本当に必要としているもの、または本当に必要なものを予測することです。

クライアント（私にとって）が、Webアプリケーションのセクションにすべての電話番号のリストを返すことを望んでいるとします。物理的なもの、論理的なもの、人や場所に割り当てられたものなどを意味するのではありません。彼らは単にすべての電話番号が必要です。開発者として、私はそこに座って、あなたが持っているのと同じように、クライアントに尋ねる必要がある12個以上の質問を考えることができます。しかし、あなたが言うように、それは不可能です。それが、製品とクライアントを知っている優れたクライアントサービス部門を持つことが非常に貴重な理由です。

この種の電話がクライアント担当者に届くと、彼らはクライアントと詳細に話し合い、適切な質問に答えるために何を尋ねる必要があるかを知ることができます。彼らはまた、クライアントが過去に何を求めているのかを事前に把握しており、クライアントに尋ねることなく何かに「はい」または「いいえ」と言うことができるように開発したシステムについて十分に知っています

確かに、あなたとクライアントサービスの両方が見逃した何か他の何かがクライアントに必要になるケースがたくさんありますが、それは常に起こります。あなたの目標、およびクライアントサービスの目標は、何かを開発してから、変更が必要なクライアントからそれを取り戻すまでの遅延時間を最小限にすることです。そして、これは単にクライアントサービスとのコミュニケーションとトレーニングに帰着します。

私がいる場所ほどあなたにとって実現可能ではないかもしれませんが、クライアントの担当者との良好なコミュニケーションと信頼を持つことは、ほとんど常にあなたを助け、不満を減らし、クライアントの満足度を高めます。また、肩をすくめて「プロジェクトの全範囲がわからないので、どれくらいかかるかわからない」と言うよりも、プロジェクトの時間枠を簡単に指定できます。ここでも同じ問題があります。コミュニケーションとトレーニングの改善は、合理的な期限を設定し、一貫してそれらを達成するのに役立ちます。

お客様

製品を検索したい

プロダクトマネージャー 顧客のストーリーを分析し、次の要件を思い付きました。各要件は、個別のユーザーストーリーとして記録されています。

• 製品を検索する
• 結果を並べ替える
• 検索結果をフィルタリングする

開発者 製品マネージャーからユーザーストーリーを受け取りました。各ユーザーストーリーを分析し、各ユーザーストーリーのタスクのリストを作成しました。

• 製品を検索する
  1. タスク1：データベースの変更
  2. タスク2：サーバー側の変更
  3. タスク3：フロントエンドの変更

顧客、製品マネージャー、開発者はすべてこのプロセスの利害関係者です。作業を開始する前に、全員が分析プロセスに貢献する必要があります。これは非常に単純化された例であることに注意してください。

ユーザーストーリーは、次の順序で分析および改良されます（もちろん、いくつかのバリエーションがあります）。

ヘルプデスク->プロダクトオーナー->プロダクトマネージャー->部門責任者（上級開発者、品質保証責任者など）->開発者

関連するすべての利害関係者が分析プロセスに貢献すると、ストーリーの配信にかかる時間を見積もることができます。私たちが従う推定プロセスは、個々の開発者の速度と専門知識に基づいています。

これが正しいやり方だと言っているわけではありませんが、組織内では非常にうまく機能しています。