ユーザーストーリーは高レベルで概念的であり、経営陣は開発者が空白を埋めることを期待しています

私は、XPを実行するという真の意図を持つ非常に優れた会社で働いています。コミュニケーションは良好で、経営陣は建設的な議論を受け入れることができますが、差し迫った時間の制約があるため、RUPで議論することができないものもあると見なされています。

現時点では、ストーリーの実装中に必要となる変更の量に少し悩んでいます。これらの発見の多く（もちろん時間と労力がかかります）は、ストーリー作成者（顧客、エンドユーザー、製品所有者）の責任であり、開発者の責任ではないかと思います。簡単に言うと、ユーザーストーリーは概念的すぎて、根本的な意図を伝えているだけですが、十分な詳細（特に、前提条件と事後条件、他のストーリーとの関連性、依存関係など）が不足しています。開発者は、XPの開発者がデザイナーとアナリストを兼ねているため、独自の裁量で空白を埋めることが期待されています。問題は、これらの空白の多くが、最初の予想よりも複雑さが増していることに気付いてから、いくつかの誤った仮定が評価時間とコードに組み込まれた後に発見されることです。それでも適切な項目を見つけるには時間がかかります。これは、さまざまな程度で、初期の見積もりからの逸脱と見なされます。

私は、これらの影響を経営陣に伝える建設的な方法を探しています。不必要に物事を複雑にしようとしている人として私を装うような方法ではありません。私は新しいですが、まだ信頼性を確立していません。

あなたの洞察は大歓迎です。

密接に関連し、どういうわけか答えを与える：開発者はユーザーストーリーの詳細をどのくらい期待できますか？

トリックは空白があることを避けることではありません。秘訣は、開発プロセスのできるだけ早い段階でこれらの空白を埋めることです。

あなたが正しいのは、開発者が仮定を行うと、それらは常に間違っているため、後でソフトウェアを再開発するのに時間がかかるということです。しかし、同様に、ビジネスマンが何を望んでいるのか本当にわからないときに、完全な事前設計を行うことが期待されている場合も、同じことが起こります。

多くの場合、顧客が本当に知らないときに、顧客が何を望んでいるかを理解することは、開発者の仕事の大部分です。

まず、質問します。答えが不十分だと思われる場合は、プロトタイプを作成します。何を求めているのかを顧客に示し、それが本当に望んでいないことを顧客に説明させます。紙のプロトタイプから始めて、背後にコードがないHTMLベースのプロトタイプに移ります。次に、ほぼ機能する製品を作成し、それを示すために必要な最小限の開発を行います。トリッキーな部分は、できる限り遅くプロセスに残してください。

これ自体は時間がかかるように聞こえるかもしれませんが、おそらく完成した製品の再開発と比較すると、そうではありません。

また、ストーリーはできるだけ短くしてください。常に、ビジネスが望んでいるのは叙事詩であり、多くの成果物に分解できるものです。彼らが最終リリース候補を見て、「ああ、それは本当に私たちが探していたものではない」と叫ぶときには、あまり開発していなかったので、これはより良いことです。

それでも適切な項目を見つけるには時間がかかります。これは、さまざまな程度で、初期の見積もりからの逸脱と見なされます。

それは私にとって「XP」っぽく聞こえません。

私は決してXPのエキスパートではありませんが、XPのアイデアは、プロセスからフィードバックを得たときはいつでも、仕様と推定を継続的に適応させることです。そして、そのプロセスは、「少し分析して、少しコードを書いて、少しテストして、少しテストして」、ユーザーのフィードバックを得て、間違った仮定をできるだけ早く修正します。たとえば、ユーザーのフィードバックをさらに早く得ることもできます。たとえば、 、ソフトウェアの一部（UIなど）を一枚の紙またはホワイトボードに設計した後、それについてユーザーまたは顧客と話し合います。「XPの方法」は、「XPの方法」がそのようなアプローチを禁止しているとは思わないユーザーストーリー」。

これは、仕様を使用してより早くフィードバックを取得する方法に関する素晴らしい記事です。このような考え方は「方法論」に依存しないと思います。そこで提示された議論は、経営陣との議論に役立つでしょう。

要約すると、次の状況にあります。

1. あなたは新しいです。
2. プロジェクト（実行中のプロジェクトについて話していると思います）には差し迫った時間の制約があります。
3. 開発者は、独自の裁量で空白を埋めることが期待されています。
4. あなたが働いている会社はXPを練習するつもりです。ただし、ユーザーストーリーはXPの方法論に適合する方法で適用されていないようです。一方、「開発者は独自の裁量で空白を埋めることが期待されています」。

ポイント4について考えてください。私の意見では、アジャイルプラクティスは、企業やチームのニーズや文化に適応する必要があります（その逆ではありません）。会社がXP方法論に固執している場所と逸脱している場所を特定します。これは、懸念に対する建設的なアプローチの基礎です。

1と2のため、現在、会社がXPを妥当な方法で適用しているかどうかを質問するのは適切ではありません。経営陣との話し合いを始めると、「物事を複雑にする」人物になりそうです。ただし、懸念事項について他の開発者と話し始めることができます。たぶんあなたは自分のやり方を考える開発者を見つけるでしょう。おそらくあなたの懸念を経営陣に伝える上級開発者がいるでしょう。しかし、特に現在のプロジェクトでは、状況が急速に変化することを期待しないでください。ただし、このプロジェクトは、より多くのデータを収集する良い機会を与え、建設的なアプローチにより多くの実質を追加します。

ここでポイント3に進みます。優れたユーザーストーリーは、顧客/エンドユーザー/製品の所有者と開発者が共同で作成したものだと思います。イニシアチブを示す：ユーザーストーリーの作成者に直接尋ねる機会を探します。これが不可能な場合は、上級開発者または管理者に、ユーザーストーリーの作成者が回答する必要がある未解決の質問に対処する方法を尋ねます。多分あなたは少なくともいくつかの書面での通信を持つことができます。独自の裁量で空白を埋める必要があるため、顧客/エンドユーザー/製品所有者を積極的に関与させることを選択する必要があります。

ある時点で、会社がXP（またはアジャイルプラクティス全般）をどのように適用するかについて十分な検討と観察を行いました。たぶん、すでに時間が経過していて、もうグリーンホーンとして認識されていません。たぶん、顧客との積極的な関わりがいくつかのプラスの効果を示しているのかもしれません。たぶん、次のプロジェクトはすでに始まっています。たぶん、あなたはすでに他の開発者からのバックアップをすでに持っています。たぶん、あなたはそれがどのように機能するかが全く悪くないことに気付くでしょう。重要なのは、企業内の実際の経験とデータに基づいて、懸念を経営陣に伝えるのに十分なアイデアが得られるということです。

率直に言って、ユーザーストーリーの詳細はあまり必要ありません。「私はYのビジネスニーズを満たすために、ソフトウェアは、Xをやりたい」すべき十分なもので。結局のところ、あなたはビジネスの人々がそれを行う方法を指示することを望んでいません-あなたはソフトウェアとその中のベストプラクティスの専門家です。

これは、開発者にもする必要がある、と述べ頼む「？どのようにあなたが仕事にこれを期待します」、「いつその相互作用の機能Zと何が起こりますか？」：。開発者は要件を作らず、実装を行います。

また、実装と評価のギャップが大きすぎるようにも思えます。利害関係者は、プロトタイプを数日ごとに半完成のコードで見る必要があります。これにより、雑草に入る前にフィードバックを得ることができます。

自分にとって不完全だと思われるストーリーを見積もるように求められた場合は、ストーリーについて質問があり、それらの質問に回答する前に適切な見積りを行うことができないことを知らせてください。

次に、質問をして、答えがストーリーの一部になるようにします。

質問が（すべて）回答されていない場合でも見積もりを強制される場合は、見積もりを拒否するか、見積もりの​​残りの空白（考えられる最悪の結果を想定していることを明確に示す）を選択できます。おそらくあなたの推定は高い外れ値になります）。

あなたがしていることは、アジャイルな開発方法ではありません。代わりに、低品質の要件で作業しています。アジャイルな開発方法が要件を指定しないことは誤りです。

代わりに、最初はできるだけ多くを指定し、必要に応じて後で変更する必要があります。次に、作業をパーツに分割し、繰り返し実装します。各反復の後、何かが終了します。

ウォーターフォール開発との違いは、ウォーターフォール開発にあり、すべてが初期要件で実装され、最後に変更されます。

開発者はユーザーストーリーの作成から完全に削除されているようです。あなたはそれらを詳細な仕様のように読み、それを最初から正しく構築できると期待していますか？それができれば、XPやその他のアジャイル手法は必要ありません。

話が曖昧すぎる場合は誰かが質問するべきです。受け入れテストはどこで行われますか？

ユーザーストーリーは変更されることを意図しています。あなたはそれに対処する必要があります。

開発者はストーリー/詳細な要件を書くことができますが、私はそれが得意である多くの人を見たことはありません。私たちは問題を指摘し、より良いフローを提案するのが得意ですが、すでによく書かれたケースへのインプットとして。

新規および既存の製品に取り組み、両方とも要件が5行で、空白を埋めて「理解」またはより複雑なドキュメントを作成することが期待される場合がありました。

プロジェクトは、これを手助けしてくれる私たち自身の専門サービス担当者（または、他に誰もいないので参加したVP）がいたときよりも、はるかにうまく動いています。どちらにしても、開発に時間の無駄があります（フィードバックが返されず、期限が変更されていない場合を除きます）。だから私の提案：詳細を尋ね、詳細を提供し、あなたの仮定と文書への期限付きのフィードバックを求め、x日までにこの情報を取得しないと再作業と遅延が発生するリスクがあると述べます。

開発方法に関係なく、要件を定義するために使用しているものが開発者に仮定をさせる場合、それをビジネス側に戻す必要があります。私は多くの場合、私がどの答えを好むかについて良い考えを持っているので、次のように物事を振り返ります：

XYZは私には不明確です。ABCを意味しますか？それとも何か不足していますか？（XYZが要件であると想定し、ABCが開発者として作成したい想定であると想定します）

間違った仮定をする前に、やり直すよりも、物事を片付けるのにはるかに短い時間がかかります。自分の推測が正しいことを確認せずに要件を推測する開発者は悪い開発者である傾向があり、会社に多額の費用がかかります。悪いマネージャーがあなたに物事を引き戻すことを許さないならば、それから彼にそれを間違って行うことは時間とお金の点でどれほど高価であるかを彼に説明します。彼がまだ主張している場合は、彼が言ったことを実行し、それがUATに失敗したときに、次に何かをキックしたいときに、彼があなたを許さなかった時間はどれほどコストがかかるかを思い出させます。それでも聞き取れない場合は、より良い上司を見つけましょう。

物事をキックバックする他の価値は、ビジネスが徐々に必要なものを学習し、より良い要件を提供することです。

開発者として、

ユーザーストーリーの詳細を完全に理解する必要があります。

自信を持って見積もり、実装できるようにします。

つまり、ストーリーの詳細を理解するまで質問する必要があります。これは反復計画で行われ、決定ポイントとして機能します。推定できない場合は構築できません。