スクラムの見積もりに対する交渉と打撃の試みは、プロセスの正当な部分ですか？
私はスクラムミーティングで、開発者がストーリーについて現実的な見積もりをすることが多いことに気付きました。ただし、かなり単純なストーリーでも、構成、サードパーティコンポーネントのセットアップ、テスト、最終ビルドには多大な労力が必要であり、システムにはかなりの技術的負債が蓄積されているため、製品の所有者や管理者にとって見積もりが高すぎるように見えることがよくあります。
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を巣から追い出し、次に戻ってくる母鳥に餌を与えようとしています。
経営陣がこのように腕をひねることができると思いますすべきお客様が「速度が20ポイント/週の場合、このタスクを完了するために50ストーリーポイントの余裕はありません。30ストーリーポイントでそれを達成する必要があります」とお客様が言うのは妥当なはずです。それらのストーリーの内容を再交渉して、スコープを40％削減します。 SCRUMは、開発者が好きなことをするための無料の食事券ではありません。SCRUMは、開発者と管理者が何をすべきかについてオープンに話し合うのに役立つコミュニケーションツールです。また、顧客が開発者に圧迫し、作業が時間内に完了しないという固有のリスクを受け入れたい場合は、「30ポイントでタスクを実行してください」と言うこともできます。締め切りに間に合わなかった場合、開発者が「作業を間に合わせることができなかったという最高の見積もりを提供し、調整せずに現在のパスを続行することを選択した」と言える場合は、管理者が理由を説明します。締め切りに間に合いませんでした。私はこのアプローチが開発プロセスの無駄を省くために使用されているのを見てきました。マネージャーはできる以上のことを要求し、チームをできるだけ生産的にするようにプッシュし、実際に行われたすべてを受け入れます。チームの生産性を測定するより良い方法があると思いますが、それが機能するプロセスであることを認めざるを得ません。
1つは、POが管理者にタスク情報を提供してはならないということです。タスクの見積もりは、チームの利益のために厳密に行われます。チーム外の誰もが知る必要がある唯一のことは、彼らが取り組んでいるストーリー、彼らのポイント値は何か、そしてチームの平均速度は何であるかです。 T
第二に、POがソフトウェアの深い知識を持つ上級レベルの開発者でない限り、タスクの見積もりに関する彼らの意見はそれほど重要ではありません。開発者は、システムについての知識を持つ人と、作業を行っている人です。推定スキルがゼロで学校を卒業したばかりでない限り、推定は除外する必要があります。
だからといって、見積もりを疑問視できないことはありません。もしそうなら、これは前向きな方法で行われる必要があります。たとえば、「 "x"の半分の作業は既に完了していると考えましたか？」または「Yを行う時間を含めることを覚えていますか？」などです。
結論：開発者は、正確であることを誠意をもって試みている限り、必要な見積もりを安全に行う必要があります。彼らが何かが4時間かかると言うなら、あなたはそれを受け入れなければなりません。
スクラムガイドラインはこのトピックについて何を言っているか、または彼らはそれに何かを言っていますか？
彼らは何も言わない。タスクの見積もりはスクラムの一部ではありません。スクラムでは、ストーリーポイントで推定が停止します。タスクの見積もりは、チームがストーリーを完成させるために必要なすべての作業を確実に検討することで、ストーリーポイントの見積もりを改善するためのツールにすぎません。
スクラムプロセスが確実に実行されるようにするのは、Scum Masterのタスクです。これには、チームがスプリントで実行できる作業量を（一貫して）オーバーコミットしないようにすることも含まれます。
一方では、過度に熱狂的なチームを支配することを意味しますが、一方で、チームにプレッシャーをかけている場合は、プロダクトオーナーにプッシュバックすることも意味します。
コミットメント/予測を現実的に保つための1つの良い方法は、最後の数回のスプリントで実際に実現されたストーリーを確認することです。これはチームが達成できることを証明したものであり、完了しないため、スプリントに大幅に多くの作業を投入しても意味がありません。
他の回答でも示されているように、チームによって与えられた見積もりの交渉は、スクラムプロセスの一部ではありません。チームはソフトウェアに最も精通しているため、何かがどれだけの作業であるかを最もよく知る必要があります。
交渉できるものは、ストーリーのスコープです。プロダクトオーナーが、ストーリーが予想よりもかなり大きいまたは小さいと推定されていると考えた場合は、チームに説明を求めて、実行する必要のある作業のビューがパーティー間で一致しているかどうかを確認できます。
ストーリーが実際に多くの作業である場合、プロダクトオーナーはそれをいくつかの小さなストーリーに分割し、機能をそれらの小さなストーリーに分散することを決定できます。
チームは品質を提供する責任があり、決して交渉の余地はありません。
はいといいえ。
はい、スプリントチームはwhatがスプリントに参加することについて、製品の所有者と交渉する必要があります。
いいえ、製品の所有者はnoを取得します。あなたは彼らではなく専門家です。
ほら、あなたはその種のゴミに対処する必要はないはずです-あなたのマネージャーやチームリーダーがあなたを成功へと導くためにそこにいます。これは、PM（またはその上司）とやり取りして成功することを意味します。
"番号。"
彼らは何をする予定ですか？自分でコードを書きますか？
この動作を許可することは、スクラムマスターの失敗です。彼女の仕事は何よりもまず、チームを守ることです。上記の理由により、POは近視眼的です。スクラムマスターは介入し、前向きな方法で、ディスカッションのコンテキストを再構成する必要があります。
もちろん、そのような圧力は速度に下向きの圧力をもたらしますが、これはOPがすでに言及したものです。チームが一貫してスプリントを終了していない場合は、スクラムマスターが再び介入して、なぜそうなのかを尋ねる必要があります。本当に有毒な環境では、チームメンバーは回顧展で正直にいることを気軽にできないかもしれません。しかし、そのような状況では、スクラムマスターは悪い行動を呼び起こしてチームを保護する責任があります。
スクラムマスターがこれらのことを実行できない、または実行しない状況に陥った場合は、おそらく別のスクラムマスターが必要です。 POは一般的な圧力に対応しています。チームは洞窟で、人間がよくするように反応しています。これが何であるかを見て、それをやめるのはスクラムマスターの仕事です。ここでのOPの責任は、これを回顧展で取り上げ、必要に応じてリーダーとマネージャーに伝えることです。それでも問題が解決しない場合は、LinkedInプロフィールを更新して、より適切なユーザーを見つけてください。
ここでのモチベーションに大きく依存すると思います。見積もりの最も重要な目標は、特定のスプリント中にチームがどれだけ達成できるかを把握することです。これにより、その速度に基づいて将来の作業を予測できます。たとえば、チームがスプリントごとに30ストーリーポイントを完了し、バックログでアイテムXの前に約60ストーリーポイントがある場合、プロダクトオーナーはアイテムXが6週間程度で完了すると合理的に言うことができます（標準の2週間のスプリント）。
この見積もりをできるだけ正確にするために、特定のアイテムがいくつのストーリーポイントであるかについて意見の相違があることは前例のないことではありません。スクラムは実際にそれを奨励しています。その不一致は、時にはさらに熱くなります。ただし、最終的な最終目標は、PBIの複雑さを正確に推定することであり、特定の速度でより多くのPBIを詰め込もうとするために、努力を人為的に収縮させることではありません。
これは、原則としてポーカーの計画の仕組みです。誰もが彼らの見積もりをレイアウトします。スクラムマスターは、高低の見積もりを取り、チームメンバーがそれが高低であると考える理由を尋ねます。これにより、チームは関連する作業の別の見方を聞くことができ、タスクが実際にどれほど複雑であるかについてより良いアイデアを得ることができます。話し合いの後、全員が再び見積もりを出します。このプロセスはすすぎ、複雑さに関する一般的な合意が得られるまで繰り返されます。
言い換えれば、挑戦者が彼らが単にそれを低くしたいだけでなく、彼らが同意しない理由の根拠があるならば、あなたの見積もりに挑戦することは間違いではありません。推定が正しいと感じた場合、推定が正しいことをチームに納得させるのはあなたの責任です。
製品開発チーム（つまり、製品の所有者から開発者、テスターまで）は、アジャイルプロセスに従い、適度に有能な人々と現実的な期待に基づいて良い結果を得ることができます。
あるいは、表面的にはアジャイルプロセスに似たプロセスに従うこともできます。
そのPOはおそらく、タスクの推定時間を短縮することで、より良い結果が得られると考えています。もちろん動作しません。何かが3日かかるとしたら、たくさんの現金をくれて、1時間でできると推定します。それでも3日かかります。約束通り1時間で終わらないので来て叫んだら5日かかります。
彼が達成するすべてはアジャイルプロセスを壊し、彼が得ることができるすべての肯定的な結果をあきらめることです。スクラムマスターはこれを防ぐための経験、力、勇気を持っている必要があります。管理者が経験のない誰かにスクラムマスターを作ったり、スクラムマスターにこれを防ぐ力を与えなかったりすると、アジャイルが壊れるのは彼らの責任です。スクラムマスターに勇気がない場合は、PMと責任を共有します。