スクラムの見積もりに対する交渉と打撃の試みは、プロセスの正当な部分ですか？

私はスクラムミーティングで、開発者がストーリーについて現実的な見積もりを行うことが多いことに気付きました。ただし、かなり単純なストーリーであっても、構成、サードパーティコンポーネントのセットアップ、テスト、最終ビルドに多大な労力が必要であり、システムにはかなりの技術的負債が蓄積されているため、製品の所有者や管理者にとって見積もりが高すぎることがよくあります。

POは次のような見積もりを頻繁に打ち消そうとします。たとえば、「このストーリーには13ストーリーポイント[4日間]が必要です。これは不可能です。これを経営者に説明することはできません。誰かがこれをコーディングできるはずです。 3 SP [4時間以内]で！」その結果、開発者は5または8ストーリーポイント（1.5〜2日）の見積もり（スクラムの見積もりは、単なる予測ではなく、コミットメントと見なされます）にコミットするために腕をひねります。

もちろん、（主にテストと品質に関する）期待を排除する計画がなければ、これらのスプリントは頻繁に失敗します。開発者の見積もりは正直で現実的なものであり、見積もりを打ち負かしても実際に行われる作業に影響が及ぶことはありません。

「誰かがあなたにそうするように強いたからといって、あなたは不可能な約束をするべきではありません！」しかし私の意見では、開発者の仕事はソフトウェアの設計とコーディングであり、交渉や圧力に対抗することではありません！すべての取引のジャックが存在する可能性がありますが、通常は外部の顧客と直接取引しますが、これはオフィス開発者の大多数ではありません！

私にとって、この実践は、プログラマーをぎくしゃくさせ、絶え間ないスプリントの失敗を引き起こし、現実的な見積もりを妨げるだけでなく、実際の改善点も探します。

スクラムガイドラインはこのトピックについて何を言っていますか、または彼らはそれに何を言っていますか？

編集：時間をストーリーポイントに置き換えました。私は、タスクの詳細計画ではなく、Planning Pokerとストーリーポイントを使用して最初の見積もりフェーズを参照していました。日/時をそこに置いたのは、このような典型的な対話であり、ポイントではなく時間も含まれていたためです。混乱してすみません！ストーリーポイントの例は、時間の例よりも長い期間を表しています。

編集2現在、専用のスクラムマスターはなく、POは見積もり会議に関してその役割を果たします。したがって、中立的なまたは開発者のスクラムマスターではなく、権威として表示されるため、おそらくロールコンフリクトがこの不適切な交渉を悪化させています。おそらく、これが何もない限り、彼を「マスター」ではなく偏った参加者とすることで修正できます。

あなたが説明する状況は有毒です。この種の交渉は、チームの現実と専門知識を無視し、チームおよび組織全体から情報を意図的に隠蔽し、チームが時間の経過とともに改善するのを妨げます。

当局としてhttp://www.scrumguides.org/scrum-guide.htmlを市にしたい場合、私は強調します：

今後のスプリントで達成できることを評価できるのは開発チームだけです。

そして

スクラムは透明性に依存しています。価値を最適化してリスクを制御する決定は、アーチファクトの知覚された状態に基づいて行われます。透明性が完全である限り、これらの決定には根拠があります。アーティファクトが完全に透過的でない限り、これらの決定に欠陥があり、価値が低下し、リスクが増大する可能性があります。

製品の所有者は、たった4時間でタスクを実行できることを望んでいる場合があります。それは合理的な目標かもしれません。健全な反応は、チームの見積もりを受け入れ、それが正確かどうかを測定し、「この種のタスクをより迅速に完了するために何を変更する必要があるか」と尋ねることです。タスクに関連する作業の範囲を交渉することも合理的であり、開発者と製品所有者がその作業を理解する方法の重要な違いを強調する場合もあります。新しい情報なしでチームが見積もりを変更することを要求しても、見積もりは不正確になります。

このパターンを変更するために開発チームが使用する可能性のある戦略はたくさんありますが、「これを経営者に説明することはできません」という応答の例を挙げると、非常に緊張します。あなたの製品の所有者は管理者の信頼を持たないようで（彼らが作成している不正確な見積もりはおそらく役に立たないでしょう）、現在のプロセスの障害について透過的にすることを望んでいないかもしれません。

私の意見では、SCRUMの最大の成果の1つはストーリーポイントの開発であり、ここで言及されている交渉の問題を回避するという明確な意図が表明されています。ストーリーポイントの全体のポイントは、タスクと何日かかるかとの間の直接的なつながりを避けることです。代わりに、これら2つの概念は速度の概念によって関連付けられています。

私が開発者であり、13ポイントストーリーを8ポイントストーリーと呼ぶように腕をひねられていたら、私は喜んで義務付けます。彼らが影響を与えているその推定能力。私はすべての難しさを合わせるために単純にスケーリングします。結局、チームの速度は、ストーリーポイントを "廃止"するという経営者の意欲と一致するように、1週間あたりのストーリーポイントの観点から減少します。経営陣に提供される数値は一致している必要があります。「マイルストーンを達成するために必要な作業のストーリーポイントの数を50％削減できました。しかし、それに対応して速度が50％減少したため、正味の効果は私たちが達成しようとしていた時間を正確に達成しようとしています。」ベロシティの概念は、上級管理職の希望的思考に対抗するために存在します。

今、私が見る価値があると思う2つの極端があります。1つは管理の完全な失敗であり、もう1つは管理が気にする非常に有効な懸念事項です。最初のケースはSCRUMの死刑判決であり、開発者は「あなたは十分な生産性がありません。ストーリーポイントの価値のある仕事を生み出す必要がある」と言われます。それが起こった場合、あなたは実際にはSCRUMを使用していません。あなたはCookooであり、SCRUMを巣から追い出し、次に戻ってくる母鳥に餌を与えようとしています。

経営陣がすべきだと思うケースが1つありますこのように腕をねじることができます。お客様が「20点/週の速度の場合、50ストーリーポイントでこのタスクを完了する余裕はありません。30ストーリーポイントでそれを達成する必要があります」とお客様が言うのは妥当なはずです。それらのストーリーの内容を再交渉して、スコープを40％削減します。SCRUMは、開発者が好きなことをするための無料の食事券ではありません。SCRUMは、開発者と管理者が何をすべきかについてオープンに話し合うのに役立つコミュニケーションツールです。また、顧客が開発者に圧力をかけて、作業が時間内に完了しないという固有のリスクを受け入れようとする場合は、「30ポイントでタスクを実行してください」と言っても有効です。期限を過ぎた場合、開発者は「そして、実際に行われたことをすべて受け入れます。チームの生産性を測定するより良い方法があると思いますが、それが機能するプロセスであることを認めざるを得ません。そして、実際に行われたことをすべて受け入れます。チームの生産性を測定するより良い方法があると思いますが、それが機能するプロセスであることを認めざるを得ません。

1つは、POが管理者にタスク情報を提供するべきではないことです。タスクの見積もりは、厳密にはチームの利益のためです。チーム外の誰もが知る必要がある唯一のことは、彼らが取り組んでいるストーリー、彼らのポイント値は何か、そしてチームの平均速度は何であるかです。T

第2に、POがソフトウェアの深い知識を持つ上級レベルの開発者でない限り、タスクの見積もりに関する彼らの意見はそれほど重要ではありません。開発者は、システムについての知識を持つ人であり、作業を行っている人です。推定スキルがゼロで学校を卒業したばかりの場合を除き、推定は除外する必要があります。

とはいえ、見積もりを疑問視できないことはありません。もしそうなら、これは前向きな方法で行われる必要があります。たとえば、「 "x"の半分の作業を既に完了していると考えましたか？」または「Yを実行する時間を含めることを覚えていますか？」

結論：開発者は、正確を期すために誠意を尽くす限り、必要な見積もりを安全に行う必要があります。彼らが何かが4時間かかると言うなら、あなたはそれを受け入れなければなりません。

スクラムガイドラインはこのトピックについて何を言っていますか、または彼らはそれに何を言っていますか？

彼らは何も言わない。タスクの見積もりはスクラムの一部ではありません。スクラムでは、ストーリーポイントで推定が停止します。タスクの見積もりは、チームがストーリーを完了するために必要なすべての作業を確実に検討することで、ストーリーポイントの見積もりを改善するためのツールにすぎません。

スクラムプロセスが確実に実行されるようにするのは、Scum Masterのタスクです。これには、チームがスプリントで実行できる作業量を（一貫して）オーバーコミットしないようにすることも含まれます。
一方で、これは過度に熱狂的なチームを統治することを意味しますが、一方でチームがプレッシャーをかけている場合は、プロダクトオーナーにプッシュバックすることも意味します。

コミットメント/予測を現実的に保つための1つの良い方法は、過去数回のスプリントで実際に実現されたストーリーを確認することです。これがチームが達成できることを証明したものであり、完了しないため、スプリントに大幅に多くの作業を投入しても意味がありません。

他の回答でも示されているように、チームによって与えられた見積もりの​​交渉はスクラムプロセスの一部ではありません。チームはソフトウェアに最も精通しているので、何かがどれだけの作業であるかを最もよく知る必要があります。

何ができに関する駆け引きすることはある範囲の物語の。プロダクトオーナーは、ストーリーが合理的に予想されるよりも大きいまたは小さいと推定されていると考えた場合、チームに説明を求めて、実行する必要のある作業のビューが当事者間で一致するかどうかを確認できます。
ストーリーが本当にそれだけの作業である場合、プロダクトオーナーはそれをいくつかの小さなストーリーに分割し、機能をそれらの小さなストーリーに分散することを決定できます。

チームは品質を提供する責任があり、決して交渉の余地はありません。

はいといいえ。

はい、スプリントチームは、何がスプリントに入るのかについて製品の所有者と交渉する必要があります。

いいえ、製品の所有者は物事にかかる時間について何の発言もしません。あなたは専門家であり、彼らではありません。

ほら、そのようなごみに対処する必要はないはずです。マネージャーやチームのリーダーがあなたを成功へと導きます。それはあなたが成功するように首相（または彼らの上司）と取引することを意味します。とはいえ、それほど難しくはありません。

"番号。"

彼らは何をする予定ですか？コード自体を書きますか？

この動作を許可することは、スクラムマスターの失敗です。彼女の仕事は何よりもまず、チームを守ることです。上記の理由により、POは近視眼的です。スクラムマスターは介入し、前向きな方法で、ディスカッションのコンテキストを再構成する必要があります。

もちろん、そのような圧力は速度に下向きの圧力をもたらしますが、これはOPがすでに言及したものです。チームが一貫してスプリントを完了していない場合、スクラムマスターは再度介入して、なぜそうなのかを尋ねる必要があります。本当に有毒な環境では、チームメンバーは回顧展で正直にいることを気軽にできないかもしれません。しかし、そのような状況では、スクラムマスターは悪い行動を呼び起こしてチームを保護する責任があります。

スクラムマスターがこれらのことを実行できない、または実行しない状況に陥った場合は、おそらく別のスクラムマスターが必要です。POは一般的な圧力に対応しています。チームは洞窟で、人間がよくするように反応しています。これが何であるかを見て、それをやめるのはスクラムマスターの仕事です。ここでのOPの責任は、これを回顧展で取り上げ、必要に応じてリーダーとマネージャーに伝えることです。それでも問題が解決しない場合は、LinkedInプロフィールを更新して、より適切なユーザーを見つけてください。

製品開発チーム（つまり、製品の所有者から開発者、テスターまで）は、アジャイルプロセスに従って、適度に有能な人々と現実的な期待に基づいて良い結果を得ることができます。

あるいは、表面的にはアジャイルプロセスに似たプロセスに従うこともできます。

そのPOはおそらく、タスクの推定時間を短縮することで、より良い結果が得られると考えています。もちろん動作しません。何かが3日かかるとしたら、たくさんの現金をくれて、1時間でできると推定します。それでも3日かかります。約束通り1時間で終わらないので来て叫んだら5日かかります。

彼が達成するすべてはアジャイルプロセスを壊し、彼が得ることができるすべての肯定的な結果をあきらめることです。スクラムマスターは、これを防ぐための経験、力、勇気を持っている必要があります。経営陣が経験のない誰かにスクラムマスターを作ったり、スクラムマスターにこれを防ぐ力を与えなかったりすると、アジャイルが壊れるのは彼らの責任です。スクラムマスターに勇気がない場合は、PMと責任を共有します。

ここでの動機に大きく依存すると思います。推定の最も重要な目標は、特定のスプリント中にチームがどれだけ達成できるかを把握することです。これにより、その速度に基づいて将来の作業を予測できます。たとえば、チームがスプリントごとに30ストーリーポイントを完了し、バックログでアイテムXの前に約60ストーリーポイントがある場合、プロダクトオーナーは、アイテムXが6週間程度で完了すると合理的に言うことができます（標準の2週間のスプリント）。

この見積もりをできるだけ正確にするために、特定のアイテムがいくつのストーリーポイントであるかについて意見の相違があることは前例のないことではありません。スクラムは実際にそれを奨励しています。その不一致は、時としてさらに熱くなります。ただし、最終的な最終目標は、PBIの複雑さを正確に推定することであり、人為的に労力を減らして、特定の速度でより多くのPBIを詰め込もうとすることができます。

これが、実際にはポーカーの計画の仕組みです。誰もが彼らの見積もりをレイアウトします。スクラムマスターは、高低の見積もりを取り、チームメンバーがそれが高低であると考える理由を尋ねます。これにより、チームは関連する作業の別の視点を聞く機会が得られ、タスクが実際にどれほど複雑であるかについてより良いアイデアを得ることができます。話し合いの後、全員が再び見積もりを出します。このプロセスはすすぎ、複雑さに関する一般的な合意が得られるまで繰り返されます。

言い換えれば、チャレンジャーが単に低くしたいだけでなく、なぜ反対するのかについての根拠があるため、見積もりに挑戦することは間違いありません。したがって、推定が正しいと感じた場合、推定が正しいことをチームに納得させるのはあなたの責任です。