スクラムが優れた開発者を平均的な開発者に変えないようにするにはどうすればよいですか？
私は this が私のチームでも起こったことを発見しましたが、彼は状況を少し誇張しているかもしれません。
スクラムは、平均以下または貧しい開発者を平均的な開発者に変える方法です。また、優れた開発者を平均的な開発者に変えるのにも優れています。
誰もが、1日でできる簡単なものをボードから取り出して、明日のデイリースクラムでレポートするものを用意したいと思っています。ぶら下がっている果物を選ぼうとしているのは皆です。あなたが何をしていても何も動いていなければ、賢く、解決策について考える時間を割く動機はありませんか？あなたはチームを失望させています！速度が落ちています！
私はあなたが解決するのに難しい問題を抱えているなら、賢い人にそれらを与えて、それらを放っておくことによってそれらを解決すると思います。あなたは彼らが昨日何をしたか、そして彼らが今日何をするつもりかを知ることを要求して毎日彼らに常に嫌がらせをするのではありません。毎日の更新で、賢い人々が困難な問題に取り組むインセンティブはどこにありますか？彼らは今、ジュニア開発者と同じインセンティブを持っています。全体を移動する最も簡単なチケットを見つけます。
時々私は一人でいるだけで数日間の解決策を考えたいと思うでしょう。私がそれをすれば、私はスクラムで言うことは何もないでしょう。そこで代わりに、フロントエンドの色が間違った緑の色合いまたはスペルミスだったユーザーストーリーを選びます。ほら、昼食前に一日で二話ノックアウト！行け！
...
私は彼の言葉に完全に同意しません。たとえば、彼ら（マネージャー）が彼らを信頼していないということではなく、絶え間ない監督なしでは物事を成し遂げられないということです。
優れた開発者が平均的な開発者になるとき、常に複数の理由がありますが、私は毎日のスクラムが理由の1つである可能性があることを知っています。それでは、スクラムミーティングのこのような副作用を防ぐにはどうすればよいですか？
言うのは言うより簡単だということにも気づきましたが、他の人がこの問題をどのように見ているのかを見たいです。
-----更新-----
これまでに得たすべての回答を読んだ後、質問の関連性を高めるためにいくつかの情報を追加する必要があることに気付きました。
しかし、それに入る前に、彼の回答で述べた Martin Maat の言葉を繰り返したいと思います。スクラムが引き起こす欲求不満の指標。」
全くもって同じ意見です！私が最初に質問したとき、私はすでにいくつかの答えが「ああ、あなたはスクラムを正しく行わない！」だと予想していた。
元の質問に加えたいいくつかの修正は、
- 私は「 great developer 」という言葉を使用しましたが、たぶん decent/good developer と言ったほうがいいでしょう。その上、私のキャリアを通して、私は素晴らしい開発者と一緒に仕事をしたことがないので、そもそもそれを使うべきではありません。私が意味したことは、スクラムによって優れた開発者のパフォーマンスが低下することがときどきありました。
- 一部の回答は「絶え間ない監督なしでは物事を成し遂げられない」という文に焦点を当てており、それはミクロ管理の問題であると信じていました。しかし、これは私のケースではありませんでした。私は細かく管理しません。私が（時々）経験した問題は、優れた技術に精通した開発者が必ずしもビジネスに精通した開発者であるとは限りません。最終的に納品する製品があることに気づかずに、技術ソリューションの完成に集中する場合があります。また、調整が必要な機能間機能である場合もあります。特に、各チームには独自の優先度/スケジュールがある場合があります。そのため、監督が必要です。ただし、元の投稿から「 constant supervision 」という単語をコピーするだけでなく、最初に constant を使用しないでください。 。しかし、繰り返しになりますが、「素晴らしい開発者」と「素晴らしいチーム」がそれをしないと誰かが主張するならば、私はその時反論することができません。
- 1つの答えは、「毎日のスクラムがどういうわけか、最も多くのチケットを完了したコンテストに変わった」と述べました。私は決してそれを経験しませんでした。成熟したチームはそれを行いません（成熟したチームが優れたチームであるとは限りません）。誰か経験したことがありますか？
- アジャイルマニフェストを読むことを勧められた方のために、私の反論は次のとおりです 長い書評 2008年（12年前）に、「エンタープライズとスクラム（開発者のベストプラクティス）」という本について書いたスクラム共同設立者のケン・シュヴァーバー。私は自分のレビューをここにリストアップしました。見せるのではなく、見せるためです（1）私は、スクラムを長所と短所を見るのに十分な長さで行ってきたと思います。 （2）アジャイルとは何かを知っています。
引用された引用は、健全なチームでスクラムがどのように機能するかについての根本的な誤解を反映しています。スクラムの要点は、「チームとして最もよく機能するにはどうすればよいか」です。それは間違いなくnot「最高の見た目になるために、どうすれば互いに競争できるでしょうか？」見栄えを競うことは、チームの一員として機能しているわけではありません-それは正反対です。
スタンドアップの主なポイントは、毎日何かを動かさなければならないということである場合、何かが深刻に間違っています。主なことは、あなたがスプリントで約束した仕事を予定通りに完了する予定であるかどうか、そしてそれを行うための障害があるかどうかです。私は人々が毎日スタンドアップである種の進歩を報告することを期待しますが、唯一の焦点が「私たちの速度を良くするために多くのものを閉じる」ことであるなら、それは間違ったアプローチです。言い換えれば、実際に何を気にしているのですか-looking goodまたは実際にはbeing good？
これが起こっているという事実はまた、スプリント計画がうまくいっていないことを示唆しています。人々がつまずいて、ぶら下がっている果物を得て、複雑な仕事を避けようとするなら、それは深刻な問題です。プロダクトオーナーがストーリーを適切に優先しないのはなぜですか？確かに、あなたのぶら下がっている果物はすべて、複雑な仕事よりも優先順位が高いわけではありません。
それで、そもそもなぜ「ぶら下がっている果物」の話を書くのか。ストーリーは、エンドカスタマーに付加価値をもたらす成果物を反映する必要がありますnot開発者が毎日締めくくる手間がかからないものを提供するものだけです。繰り返しますが、どちらがより重要ですか-見栄えが良いですか、実際に良いですか？
最後に、なぜ人々は自分の能力に基づいて仕事をしていませんか？より経験豊富で熟練したエンジニアは、よりジュニアのエンジニアよりも多くの作業を行い、より複雑な作業を行う必要があります。そうでない場合、スクラムマスターはそれをプッシュバックする必要があります。
私が実践しているアジャイルでは、毎日の会議は、特にタスクがブロックされている場合に、助けが必要かどうかを知らせる時間です。誰も何も言うことのない興味深い会議を毎日開催することはまったく問題ありません（そしてそれを認識して会議を停止します...）。翌日に何を終えたかを報告する時ではありません。率直に言って、あなたがしたことを誰も気にする必要はありません。この情報はすでに掲示板にあり、新しいタスクを実行したい人にのみ関係があります。議論の結果としてマネージャーが関与する行動項目を提起することは一般的ですが、それは階層が存在する会議ではありません。
ベロシティに関する質問は、長期にわたる回顧会議で話し合う必要があります。
タスクが処理される正式な方法のポイントは、労力が必要な場所に労力を割り当てることです。 demand製品の所有者が作業に明確に優先順位を付けること、および優先順位をできるだけ変更しないこと。途中でやったことは何の価値もないので、大きな仕事をするのもまったく普通のことです。大きなタスクをスプリントサイズの小さなビット（またはさらに悪い場合は日サイズ）に分割すると、特にタスクを分割する方法がそれを分割することを含む場合、途中で何かを実行するリスクが非常に高くなります。従来の開発プロセスのステップ（通常、開発とテスト）。
スクラムがすべての開発者に複雑なタスクを回避するように要求している場合、それはおそらく製品の所有者がそれらのタスクに値する優先度を割り当てていないことを意味します。スプリントの目標は、機能とバグ修正の明確に定義されたポイントに到達することであり、無差別に「ポイントのために何かをする」ことではありません。実際には、タスクのバックログがあり、スプリントの開始時に、製品の所有者とチームはnegotiateそのバックログからのタスクのサブセットを意味しますこれはスプリントの終わりまでに行われます。サブセット内に残っているタスクがあるときにそのサブセットに含まれていないタスクで作業することは、機能不全です。チームがスプリントで処理できるよりも多くのタスクを一貫して選択することも機能不全です。