agile - あなた（開発者）は、不明確な要件や複数の行動をとるPOにどのように対処しますか？

Question

スクラムが実際の生活でどのように機能するか、または機能する必要があるかを理解しようとする別の質問があります。これが私が遭遇する典型的なシナリオです：

注：「プロダクトオーナー」という用語は、以下では使用されていません。これは、真の「プロダクトオーナー」（この場合はプロダクトマネージャー）が最終決定を下さないためです。DBリードは、アプリがDBとどのように相互作用するかを決定する際に、多くのことについて最終決定権を持っています。QAには、物事がどのように見えるか/機能するかについて独自のアイデアがあります。それらのアイデアはバグとして入力され、一般に（すべての人が）そのように扱われることが期待されます。

プロダクトマネージャーは、「XユーザーはYを実行するためにページが必要です」のようなストーリーを書きます。
スプリント計画会議で、ストーリーはスプリントバックログに追加されます。
一部の貧しい開発者はストーリーをつかみます（または割り当てられます）。
開発者は、プロダクトマネージャーに「ページをどのようにしたいか」と尋ねます。
プロダクトマネージャー（利用可能な場合）は、「うーん、A、B、Cを収集する必要があります」と述べています。
開発者は、それがどうあるべきかについての彼の最善の推測に取り組み始めます。
開発者はページをストアドプロシージャに接続しようとし、DBリーダーにいくつかの質問をします。DBリードは、「ページにもDとEが必要です。Bは必要ありません」と述べています。
開発者は変更を加えてコミットします。
QAは「Eは混乱していると思います」と言っています。
開発者は、QA、DBリード、およびプロダクトマネージャーに、最終ページがどうあるべきかについて合意してもらうために苦労する必要があります。

私の理解（スクラムの教え方によると）は、ページの要件を具体化するのは開発者の責任であるということです。私たちの環境では、上記のように、これは開発者にとって苛立たしい経験と、要件が何であるかについて統一された決定に至るすべての力を得るのを待つ間、開発者にとって多くの無駄な時間をもたらします。

2時間のタスクの要件を確定するのに、数日以上かかる場合があります。1人で十分な時間を過ごすのは難しいです-3人でさらに難しいです！

アンチスクラムであることは知っていますが、プロダクトマネージャー、DBリード、およびQAチームは、計画会議の前に会議を行い、スプリントに追加するタスクの詳細をハッシュ化する必要があるようです。（開発者が考慮される入力を持っていることはめったにありません。会議でこれを実行しようとすると、バックログ内のすべてのアイテムのすべての詳細をハッシュ化するのに、冗談ではなく1日かかる可能性があります。）

誰かがこれに対処しましたか？助言がありますか？あまり長く歩き回りたくないので、さらに詳細が必要な場合はお知らせください。

ありがとうございました！

score 10 · Accepted Answer

これは、真の「プロダクトオーナー」 (この場合はプロダクトマネージャー) が最終決定を下さないためです。

そして、それはまさにあなたの問題です。スクラム言う

プロダクトオーナーは人ではなく、役割です。誰もがプロダクトオーナーになることができます。

プロダクトマネージャーがこれらの決定を下すことができない場合、彼はプロダクトオーナーではありません。その場合、これらの決定を行うことができる人を見つけてください。これがあなたの本当の製品所有者だからです。

私は、開発者 (スクラムでの「チーム」の役割) として、プロダクトオーナーがこの機能をどのように期待しているかを知るだけで済みます。彼は所有者であり、ページがどのように見えるべきかを私に説明し、私は彼の説明に従ってページを作成します. DB リードはプロダクトオーナーではありません。QA は製品所有者ではありません。プロダクトオーナーが望んでいたようなページを作成しました。DB リードまたは QA に問題がある場合は、プロダクトオーナーに相談する必要があります。または、実際には、製品の所有者は事前に彼らと話しておくべきでした.

また、DB リードと QA が何らかの形で製品所有者にもサービスを提供している場合、スプリント計画会議に参加していないのはなぜですか? その場合、製品マネージャーが A、B、C と言ったとき、彼らはすぐに「異議あり」と叫ぶことができたはずです。そして、QA は、E が紛らわしいと考えていると言うことができたでしょう。スプリントの後、最終的に私の実装を承認しなければならない人々が、彼らが何を望んでいるのかについてさえ同意しない限り、私はこのことにまったく触れません.

score 2 · Accepted Answer

気になった点をいくつか…

1) あなたは開発者がユーザーストーリーをプルすると言いました

実際には、計画中にタスクに分割する必要があります。

2) あなたは物事をハッシュ化するのに丸一日かかるだろうとおっしゃいました。

スプリント計画には丸 1 日かかる場合があります。再ハッシュに多くの時間を費やすよりも、その時間を一度に費やして、正しい方向に進むための十分な情報を取得する方がよいでしょう.

score 2 · Accepted Answer

いくつかの提案:

コンテキスト: 「X ユーザーは Y を行うにはページが必要です」にはコンテキストがありません。私は、「XI が Z を実行できるように、Y を実行したい」というフレーミングが好きです。少し異なりますが、Z 部分は、ユーザーが達成しようとしていることにコンテキストを追加します。

受け入れ基準：あなたは受け入れ基準について言及していませんでした。ストーリーには、いつストーリーが完成したかを示す承認基準のリストを含める必要があります。私は、「与えられた X、いつ Y、次に Z」という言い回しが好きです (たとえば、「 X ユーザーがログインしていて、銀行残高がプラスの場合、Y ページに移動すると、残高の横にスマイリーフェイスが表示されます。通常、これらの受け入れ基準のリストがあります。

受け入れ基準を定義することを余儀なくされた場合、プロダクトマネージャーは、ストーリーで何を達成しようとしているのかについてより良い視点を開発し、それをより詳細に伝えることができることに気付くと思います。余談ですが、テスターがテスト可能性の問題の受け入れ基準を確認することも役立つと思います。

What vs. How : イテレーション中、何をする必要があるかについてまだ論争しているようです。INVEST* ストーリー基準の交渉可能性の概念は、ストーリーがどのように実装されるかをより重視しています。ストーリーがイテレーションに追加される前に、すでに定義されている必要があるもの。

*INVEST - 独立、交渉可能、価値あり、評価可能、小規模、テスト可能

score 1 · Accepted Answer

私の提案は、期待される動作を決定するという点で、PO がタスクの所有者になることです。これは、Z がダウンした場合や W が時間内に応答しない場合などに、Y を許可するように構築されているシステムが何かをしなければならないという、10 以上の奇妙なケースを経験することを意味する場合があります。

詳細を具体化するのは開発者の仕事かもしれませんが、これは適切な人に質問をしているだけです。プロセスの一部は要件の変更を処理することであるため、101 の手順ではなく結果が鍵となります。スプリントの終わりに向けて製品の新しいバージョンを準備するために行われました。

もう 1 つのオプションは、チームリーダーまたはグループマネージャーを配置することです。これは、大企業の場合はプロジェクトとは別の開発者のマネージャーであり、「D を実行したいが、より詳細な情報が必要です」と言うことができるリソースになります。 PO とのミーティングをスケジュールできないようです」と、この人の幸運を祈ります。

score 1 · Accepted Answer

Scrum と XP のPlanning Gameを混同しているようです。もちろん、組織のニーズに応じて方法論を調整することはできますが、XP プランニングゲームとしても、要点が欠けていると思います。

プランニングゲームまたはスプリントプランニングの基本的な前提は、開発者または「ブタ」(DB リードおよび QA を含む) が、製品の「何を」いつ「いつ」を利害関係者または「ニワトリ」(製品マネジャー）。したがって、「何」を指定する立場にある人が事前に集まり、詳細や優先順位を議論することは、確かに「反スクラム」ではありません。

ここで回答したように、詳細は Sprint backlog に記入されています。これはユーザーストーリーの形でもかまいませんが、Sprint Backlog はデザインとタスクに切り込みます。

score 1 · Accepted Answer

問題は「現実世界と対立するスクラム」ではありません。問題は、「他の問題にもかかわらず、スクラムに良いことを期待している」ということです。

問題の根本的な原因は、誰かが利害関係者を待ちたくないということです。他のすべては、この問題の回避策です。開発者が不完全なストーリーを早い段階で開始すると、開発者、DBA、および QA の間で不快なダンスが発生します。そして、早く始めることは、まあ、助けにはなりません。

堅実で一貫したユーザーストーリーがあれば、DBA と QA は決定を下すことができません。詳細を知っていれば、彼らの意見を打ち負かすことができます。

利害関係者からの確固たるユーザーストーリーがないからといって、現在のプロセス (またはスクラム全般) を責めることはできません。

場合によっては、2 時間のタスクの要件を突き止めるのに数日かかることもあります。1 人で十分な時間を確保するのは十分に難しく、3 人ではさらに困難です。

あなたはこれを悪いことのように聞こえます。要件を明確にするための 2 日間の会話と、それに続く 2 時間の技術的な作業が適切な比率です。それは、ケアと思考を示しています。それはあなたが正しいことをしていることを示しています。

開発者がハサミで実行を開始しないように、開発者を忙しく保つように設計されたメイクワークタスクを課すことには注意してください。

ストーリーを正しく理解するのに何日もかかる場合、まあ、私は何を言うことができますか? 何日もかかります。日々を過ごす。それが必要です。

彼らはコーディングしていないからといって、開発者を罵倒しないでください。コーディングを最初に開始した人が負けます。

解決

PO がソフトウェアによって強化された将来の状態を思い描くことができない場合、テクノロジーの先見の明のある誰かをプロセスに導入する必要があります。この役割を「ビジネスアナリスト」と呼ぶこともあります。一部のビジネスアナリストはクローゼットデザイナーやアーキテクトです。それらを発射します。一部のビジネスアナリストは、PO が新しいソフトウェアによって強化された新しい働き方のビジョンを具体化するのを支援できます。それらに報酬を与えます。

score 0 · Accepted Answer

私はまだスクラムを行っていません（私はそれを研究して気に入っていますが）が、ユーザーストーリーが本当にあなたが示すように必要最低限のものである場合、PMは彼らの仕事をしていないようです。1日を過ごすことの実用性については、3者全員で1つの会議を呼び出し、仲介を試みるのではなく、一緒にハッシュします。

score 0 · Accepted Answer

私はそれがアンチスクラムであることを知っています、

私はあなた（そしてあなたのチームメイト）が「スクラム」、「アンチスクラム」、「XP」などに集中しすぎないことをお勧めします。

あなたはソフトウェアクリエーターです。そのため、アジャイル（またはその他の方法論）に関する本やコンサルタントが何であれ、作成するために支払われるソフトウェアを作成するのに最適な人物および専門家であると信頼することをお勧めします。

しかし、プロダクトマネージャー、DBリード、およびQAチームは、計画会議の前に会議を行い、スプリントに追加するタスクの詳細をハッシュ化する必要があるように思われます。

あなたに同意。

それは私が参加している多くの（アジャイル）チームで成功したことです。この方法は、実行する作業をより適切に把握し、複雑さを見積もるのに役立ちます。それは、数週間の間に仕様書を書くことではなく、機能面と技術面の両方で、ストーリーの背後にあるものについてより良い考えを持っていることです。多くの場合、この種の情報を収集するにはWikiページ（または同様のツール）で十分です。

会議でこれを実行しようとすると、バックログ内のすべてのアイテムのすべての詳細をハッシュ化するのに、冗談ではなく1日かかる可能性があります。

はい、すべての詳細をハッシュするのに多くの時間がかかる可能性があり、これはほとんどの場合必要ありません。これは、情報を取得しないことと情報を取得しすぎることのバランスの問題です。多くの場合、Wikiページ（画面のサイズ）を埋めるだけで十分です。この情報の取得は、10分から2時間の範囲である可能性があります。

これにもっと時間が必要な場合、これはおそらくストーリーが非常に大きいか不確実であるためであり、それを分割する方法を検討することをお勧めします。

この助けを願っています。

score 0 · Accepted Answer

おそらく、すべての計画会議の前に会議を行う必要はありませんが、競合が見つかった場合に限ります。おそらく、すべての利害関係者と簡単に会い、誰もが同意できる決定を下すのが最も簡単です。

スクラムをしているからといって、後でもっと小規模でターゲットを絞った会議を開くべきではないという意味ではありません。

score 0 · Accepted Answer

与えられたタスクで何をする必要があるかを完全に理解することは、開発者の責任です。いくつかの要件が不明確な場合は、開発者とその同僚/マネージャーの両方が何をする必要があるかを完全に理解するまで、明確化を求める必要があります。

「このタスクの成功した実行をどのように定義するか」や「顧客はこれをどのように期待するか」などの質問をする必要があります。

開発者は、反復計画会議が終了する前に、次のサイクルで何をする必要があるかを完全に理解していることを確認する必要があります。いくつかの要件がまだ不明な場合は、SCRUMミーティングで、目的を達成するのを妨げるものとして対処する必要があります。

score 0 · Accepted Answer

私の理解では (スクラムについて教えられた方法によると)、ページの要件を具体化するのは開発者の責任であるということです。

はいといいえ。

はい、タスクを最初から最後まで自分で実装できる場合。

いいえ、あなたのコードが他の誰かのコードやユーザーの I/O と直接やり取りする場合は、コード/ユーザーインターフェイスの仕様に関する合意が必要です。最も重要なことは、実行できないことと、必要に応じてそれを回避する方法です。

私たちの環境では、上に示したように、要件が何であるかについて統一された決定に至るすべての権限を取得するのを待っている間、開発者にとってイライラする経験になるだけでなく、開発者にとって多くの時間が浪費されます。

私はそれがどのようなものかを完全に知っています！あなたはたまたま私の場所で働いていませんか？:)

これは、私が経験しなければならなかった実際の例です。

デザイナーは、事前に UI ページを設計します。これは階層的な HTML ページを表示するもので、上部と右側にボタンがあります。タブ付きダイアログのようなものですが、両側にタブがあります。モックアップは見栄えがよく、合理的に見えます。大した問題はありません。このダイアログで何ができるかなどの詳細な説明が添えられています。
デザイナーは実際に、このためのデータ構造をデータベースに実装するタスクを私に与えます。これは珍しいことですが、スクラムマスターは通知を受けています。それでも、人間の言葉での言語の壁と、彼がデザイナーであり、私は別のポッドのプログラマーであるという事実のために、コミュニケーションは私たち二人にとって少し困難でした.
データベースにテーブルを実装し、そのための UI を DB フロントエンドアプリケーションに追加する作業を行っています。私が得るほとんどのタスクで通常そうであるように、私はマイナーな問題についていくつかの仮定を立てます。また、与えられたデータを適応 (できる限り正規化) し、それがダイアログでどのように使用されるかを伝えて、DB フロントエンドアプリケーションの設計に最適になるようにします。通常の非正規化を行った場合、設計要件の1つが指数関数的に爆発するか（データベース）、フロントエンドで使用できなくなるため、解決しようとするいくつかの質問が出てきます。それで、私はこれに賛同を得ることを選択しましたが、残念ながら、これは後で私たちを噛む大きな誤解であることが判明しました.
次に、データベースをエクスポートするプログラマーがいくつか質問をします。私はそれらに答えます。彼がより簡単にエクスポートできるように、いくつかの作業をやり直しました。それぞれ、彼の作業環境の制限のいくつかを回避しています。その他の問題については、デザイナーが使用した「珍しく紛らわしい用語」を明確にする必要があります。
3 人目のプログラマーが、デザイナーの UI モックアップの実装に取り掛かります。すぐにいくつかの質問が提起されます。データベーステーブルでさらに調整が行われています。突然、DB フロントエンドアプリケーションで実装するのに苦労したことをコミットしましたが、それを回避することができました。ただし、DB エクスポーターのプログラマーはコードの一部も書き直す必要があり、新しいデータレイアウトに満足していません。
ここで、パート 1 で大きな誤解があったことがわかりました。作業の 50% をやり直すという別のやり直しタスクを取得しました。幸いなことに、まだ誰も実稼働データをデータベースに入力していないので、そのほとんどを廃棄することができました。それでも、当初考えていた作業の 3 倍の時間がかかりました。
繰り返しになりますが、これはエクスポーターと UI プログラマーがさらに時間を追加することになります。
最後に、誰かが実稼働データを DB フロントエンドに入力し始めましたが、これをどのように処理すればよいかわかりません。彼は、UI プログラマーと DB フロントエンドプログラマー (私) の 2 人のプログラマーの間でコミュニケーションをとっていることに気づきました。より多くの手直しが行われていますが、ほとんどの時間は物事がどのように機能するかを説明するために費やされています.

これは、ストーリーの非常に凝縮された小さな部分にすぎません。興味深い読み物ではないと思いますが、詳細を説明することはできませんし、起こったことすべてを思い出したくもありません. この例の主な問題は何でしたか?

DBやフロントエンドに不慣れなデザイナー
UIデザインに不慣れなDBプログラマー
デザイナーとDBプログラマーは誤解を持っており、それぞれの経験に基づいて独自の仮定を立てています
DB フロントエンドと DB エクスポーターの制限に対応するために、技術設計で譲歩が行われます。
DB フロントエンドとエクスポーターに costum コードを書くことを避ける。
絶え間ない要件と実装の変更により、ずっと混乱がありました。これは、同時に一緒に作業したのではなく、数日または数週間の間隔をあけて 1 つずつ作業したという事実によって増幅されます。

しかし、最大の問題はポッド間通信です。誰もがポッド内で作業することに慣れていました。人々はお互いを知っていて、何をしているのかを知っていたので、すべてを説明したり、耐え難いほど詳細に書き留めたりする必要はありません。しかし、他のポッドメンバーとの会話が始まると、コミュニケーションがこれほど難しいとは誰も予想していませんでした。人々は、一見当たり前のことを詳細に知りたがっていました。いくつかの問題は単に「定着」せず、何度も何度も発生しました。関係者全員がイライラし、コミュニケーションの有効性がさらに制限されました。

私が理解していること: 通信が重要であり、通常は連携しない他のポッドが関与すると、通信のオーバーヘッドが 4 倍になる可能性があります。これに対する準備ができていないと、フラストレーション、やる気の低下、実装の不振などにつながる可能性があります。

お互いに仕事をすることに慣れている人ほど、コミュニケーションの必要性は少なくなります。その逆は二重に真です。それを承知の上で計画を立ててください。

score 0 · Accepted Answer

私のチームは常にこの問題に直面しています。非常に広範なユーザーストーリーを受け取り、2 週間のイテレーションでそのうちのいくつかを提供するよう求められます。PO と 1 週間かけて話し合い (複数のサイトで作業しています)、1 つのユーザーストーリーの詳細を具体化し (運が良ければ 2 つできます)、独自のユーザーストーリーを作成して、機能/受け入れテストを記述できるようにします。彼ら。次に、それぞれの複雑さの見積もりを開始し、残りの 1 週間以内に完了することを現実的に期待できる数を決定します。

通常、1 つの大まかなユーザーストーリーは、少なくとも 6 つまたは 7 つの細かいユーザーストーリーに分割されます。これにより、より広範なユーザーストーリーが実際にどれほど複雑であるかを把握できます。これを繰り返し行うことで、より細かいユーザーストーリーを提供する必要があることを PO に伝えたいと考えていますが、これまでのところあまり成功していません。

S.Lott が回答で述べたように、ユーザーストーリーが不明確または高すぎる場合は、ビジネスアナリストの役割を果たして、PO と開発チームの間のギャップを埋める必要があります。

score 0 · Accepted Answer

最初にすべての利害関係者と話をしてから、ストーリーを設計/実装する方が簡単ではないでしょうか?

編集:コメントと元の質問をより注意深く読んだことに基づいて、おそらくプロセスを「アジャイル」または「スクラム」と呼んでいると思いますが、実際にはそうではありません。あなたの最初のポイントに基づいて、ここに私が間違っていると思うものがあります[警告：私はスクラムに精通していませんが、XPを数年間使用しています]：

プロダクトマネージャーは、「X ユーザーが Y を行うにはページが必要」というような話を書きます。
- プロダクトマネージャーは顧客ではなく、開発者でもありません。ユーザーストーリーは、顧客と開発者が作成する必要があります。したがって、このステップは XP/Agile ではなく、ウォーターフォールです。「ユーザー X」が「Y」を行うページが必要な場合、あなたとユーザー Xは Y に関するストーリーを書かなければなりません。そうして初めて、開発者とユーザーの両方がストーリーについて共通の理解を持つようになります。これがユーザーの全体的なポイントです。物語。「ユーザー X が Y を行うためのページを書きに行く」という PM は、ストーリーではなく、タスクです。つまり、あなたのチームは最初からワゴンから落ちたようです。
スプリント計画会議で、ストーリーがスプリントバックログに追加されます。
- そのため、スプリントバックログは実際には PM によって作成されたタスクのリストにすぎません。これはアジャイル手法ではなく、アジャイル手法を装った伝統的なプロジェクト管理です。
一部の貧弱な開発者は、ストーリーをつかみます (または割り当てられます)。
- ストーリーは会話のプレースホルダーであるため、開発者と顧客が一緒にストーリーを作成する目的は、会話の基礎となる相互理解を提供することであり、ストーリーをランダムに割り当てます (実際には PM です)。同様に、この会話をしたことのない開発者にとって、これはアジャイルではありません。これは単なるタスクの割り当てであり、すべてのプログラマーは交換可能であり、機械の歯車であるという仮定の下では、もちろんばかげています。
開発者はプロダクトマネージャーに「ページをどのようにしたいですか」と尋ねます。
プロダクトマネージャー (利用可能な場合) は、「うーん、A、B、および C を収集する必要があります」と言います。
- 繰り返しになりますが、PM は顧客ではありません。PMがページについてどう思うか誰が気にしますか？重要なのは、ユーザー X がそのページについてどう思うかです。
開発者は、それがどのようなものであるべきかについて、最善の推測に取り組み始めます。

鬱になったのでもうやめます。これはアジャイルではありません。ばかげています。

顧客はストーリーに関与していない
開発者はストーリーに関与していません
開発者と顧客の会話は発生しません
PMは物事をでっち上げている
無作為の開発者は、PM によって作成されたタスクを引き継がれています。

これはどのようにアジャイル手法であると考えられますか? それをアジャイルと呼んでも、そうはなりません。用語ではなく、メソッドの原則がすべてです。プロセスが失敗するのも不思議ではありません!

agile - あなた（開発者）は、不明確な要件や複数の行動をとるPOにどのように対処しますか？

13 に答える 13

Related

Reference