「典型的な」SCRUMチームがあり、スプリントで働き、バックログを維持することを約束します。最近、帯域外作業（通常の労働時間/スプリント以外で作業することを選択）を行っている、過剰に達成している開発者の作業を統合/処理しようとする問題に遭遇しました。

例として、チームが50ポイントの仕事を引き受ける場合、スプリントの終了までにSCRUMフレームワーク内ですべての仕事を完了し、彼らと会社は満足しているとしましょう。チームメンバーの1人が、自分で、バックログアイテムで、自分の自由時間に取り組むことにしました。彼らはこの作業をチェックインせず、代わりに保存します（TFSを使用し、シェルフセットにあります）。

これを処理する方法は？問題のいくつか..

• 次のスプリント中に、このチームメンバーは、プログラミング作業が99％完了し、コードのレビューとテストのみが必要であると言います。SCRUMおよびアジャイル方法論でこれをどのように扱いますか？
• 他の開発者は、作業が帯域外で行われたため、これらのストーリーに関連する設計決定に関与していないことに不満を述べています。
• 私たちの製品所有者はこの「無料」の仕事を引き寄せようとしますが、チームがスプリントで達成できないような機能を製品に追加するために、過剰達成メンバーが意図的にこれを行っている可能性があります。これが「プロセス」を壊しているという見方があります。明らかに、QA、UI、およびドキュメントの作業をこの作業で行う必要があります。

SCRUMチームに時間外労働を強制しないことについて多くの議論がありますが、スプリントの計画と実行中に出された期待以上の仕事をしているチームメンバーはどうでしょうか。私はこの人物を統治することをheし、あなたが余分に働くことはできないと言います（もちろん燃え尽きないように注意してください）が、同時にそれはチームの特定のメンバー（しかしすべてではない）でいくつかの問題を引き起こしているようです。

達成度の高いメンバーが行った作業を、ソフトウェア開発のSCRUMおよびアジャイルプロセスに統合する方法

申し分なく、だれかが熱心にすばらしいコードを書いています。すべての正当な重点を置いて：

それらをしましょう

スクラムスプリントにいくつかの問題を引き起こしています。物事の壮大な計画では本当に重要ですか？彼が彼がすることを成し遂げているなら、彼を続けてあなたのために素晴らしいものを作らせてください。

スクラムのような人工システムの制約からプログラマーを解放させなかったため、会社を辞めた素晴らしいプログラマーをいくつか知っています（QAを称賛するような扱いを受けた後、私自身は最後の仕事を辞めました）。入力に関して他の開発者から苦情がある場合（完全に有効な苦情、私は追加するかもしれません）、「20％時間」プログラムを導入して、彼（および他の人）が最小限の干渉で最善を尽くせるようにするのが最善かもしれません。

将来のストーリー（他者からの入力が必要な場合があります）の代わりに、開発者に新しい技術や機能を試してみましょう。そうでなければ探検されなかったであろう素晴らしい新しい機会を見つけるかもしれません。この開発者には、単に許可しただけで試してみたいことがいくつかあります。

ここで考慮すべき2つの点があります。

1. 誰かの創造的な流れを妨げないでください。
   • 開発者が時間外の仕事をしたい場合は、彼らに任せてください。
2. 他人のために作品を作らないでください。
   • 開発者が時間外の仕事をしたい場合は、他の人のためにもっと仕事を作らない方がいいでしょう。

ポイント2は、他の開発者が心配していることです。

あなたが言ったように、彼らはコードがチーム全体の入力なしに書かれているという事実を嫌います。これは、デザインの観点からすると、結果的に劣っているからかもしれません。また、設計が劣っているコードには、周囲の他のコードに感染する方法があります。

だから、あなたは何ができますか？

野心的な開発コードを心ゆくまで聞かせてください。ただし、課外コードが使用されると想定する理由がないことを明確にしてください。

結局のところ、彼はチームの一員なので、チームはすべてのコードの開発方法に関与する必要があります。

しかし、彼の作品が健全で、チームが合意した設計に適合する場合、彼はすでに書いたものの多くを使用することができます（ボーナス！）。そうでなければ、彼が次に有利なスタートを切ることにしたとき、彼は彼のデザインについてもっと考えることを強いられます。

この方法では、誰にもNOが通知されることはなく、そのために追加の作業が作成されることもありません。

彼をチームに戻してください

自問してみてください（または、チームを上回り、オーバーアチーバーを含む）：

この動作が問題になるのはなぜですか？

あなたは開発者をオーバーアチバーとラベル付けしているので、彼の作品は良質だと思うので、これは問題ではないと思います。

しかし、他の問題があるようです：

• 余分な作業は適切にテストされていません
• 文書化されていません
• チームの他のメンバーはそれを知りません
• 開発者は、POではなく、次に実装するものを決定します
• 開発者は、さまざまな利害関係者からフィードバックを受け取って自分の仕事に組み込むことはありません。

私がそうする次の理由：

開発者がそれを行うのはなぜですか？

• スプリントの終わりに十分な仕事が残っていない場合、次に取り組むべきことについてチームの決定（POを含む）が必要です。開発者がこの決定を避けるのはなぜですか？

これらの質問に答えたら、自分の質問に答え始めることができます。

• それが問題でなければ、彼に自分のことをさせてください。SCRUMを宗教として扱う人もいますが、そうではありません。
• 多くの場合、チームに2つの問題があります。1つは不正な開発者によって引き起こされ、もう1つは不正な開発者の動作をトリガーします。後者を解決する方法を見つけると、最初のものはなくなります。

私は無料の作品をミックスに追加することは良いことだという考えが好きですが、これは無料の仕事ではありません。彼の作品が何の影響もなしに次のスプリントに投入できるなら、それでいい。しかし、私はそうではないと思います。少なくとも他の誰もが、彼が何をしたか、そしてそれが彼らにどのような影響を与えるかを理解する必要があります。彼らは彼の変更が入っていることを理解しなければならないので、彼の努力を繰り返さないようにしなければなりません。

ただし、アジャイル環境で作業しているので、アジャイルについて知っていることの1つは、アジャイルではなく、あなたのために機能するように設計されていることです。そのため、この種の課外活動が行えるように、作業方法を変更する必要があります。つまり、すべての人の意見と同意を得ることです。彼らの賛同がなければ、これを行うことはできません。その重要な。チームがそれを好まない場合、悪党はそれをやめます。の終わり。彼の仕事がどれほど良いものであっても、チームの努力を尽くして、好きなことをやる人ではありません。チームが最初に来ます。

そのため、次の計画会議で全員を座らせて議論する必要があります。すべてのチームメンバーは、それを許可するか、この種のアクティビティをより適切に管理するためにプロセスを変更する必要があります。

たぶん、あなたは誰もが彼らの好むプロジェクトで働いて、彼らをテーブルに連れて行く解決策を得るでしょう（最初にそれで問題を強調するあなたの配達への混乱を想像することができます）またはあなたは命令することができます各開発者が自分の好きなソリューションを開発するための自治権を持っている領域は、多くのオープンソースプロジェクトが機能するのと同様に「貢献」されます。

この開発者はテストを作成し、コードをクリーン/ソリッドにしますか？それとも、彼はすぐにできることをすべて押し出しますか？私は個人的に、定義された時間外に仕事をすることを許可しません。それはあなたの見積もりを台無しにし、あなたが他の問題が発生することを指摘したからです。

ただし、プロセスを厳しくしないでください。スクラムは単なるフレームワークであるため、いつでもプロセスを調整して余分な時間を含めることができます（ただし、誰かが何をするかを計画するのは困難です）。

また、彼にプロジェクト以外の仕事を依頼することもできます。新しい技術を見たり、異なる方法でトレーニングを作成したりします。結論としては、計画されたスケジュールの外で行われたものは何でもあなたの見積もりを破壊するでしょう、そして私はそれを起こさせません。

私たちも同じことに直面しました。基本的に20ポイントのようなものをコミットしましたが、先週またはスプリントの途中でコーディングタスクを使い果たしましたが、テストと残りのプロセスのために別のPBIを選ぶリスクはありませんでしたプログラマーは、バックログを調べて、将来のPBIの開発を開始し（黙って！）、PBIがコードのレビューとテストの準備ができていることを計画する際に他のチームに通知することでした！あなたが言ったように。

実際、POからはもっと能力があるように見えるという懸念が生じましたが、チームの潜在能力を十分に活用できていません。スプリントに失敗するリスクがありました。この問題について考えた後、スクラムに関する考え方を変える必要があることがわかりました。主な問題は、PBI をコミットするため、人々がそのリスクを負いたくないということです。無料のプログラマーがいる場合の新しいPBI。

単にコミットメントを行うのではなく、PBIの予測を開始しました。予測とは基本的に、スプリントの計画と開始時に25ポイントを選択することを意味しますその上で、PBIが同じスプリント内のすべてのプロセス（テスト、マージなど）に合格できる場合、そのPBIのためにスプリントに失敗せず、残りの作業を繰り越さない場合、チームのボーナスポイントです（次のスプリントに進み、残りの仕事のためにポーカーをやり直します。したがって、最悪のシナリオでは2つの異なるスプリントで実行できます。Scrumbutのように聞こえるかもしれませんが、実際には作業方法が改善されました。以下にその利点を要約します。

• より多くのPBIを服用するリスクを負うため、スプリント失敗の恐怖症を打ち負かす
• プログラマーとチームの余分な作業が見えるようになります
• チームの速度を向上させます

ただし、経験の少ないチームの場合は、チームがPBIを完了するためにコミットメントが与えるプッシュを減らす可能性があります。

他の回答のいくつかは、「達成しすぎている」開発者が「不正」または「スクラムの原則に違反している」ことを示唆しています。これは誤りであり、この開発者を奨励する必要があります（ただし、この余分な時間に特定の作業を行うように人々に依頼するべきではありませんが、提案を行い、アイデアを育てることができます）。

スクラムには、人々がどのように働くかを規定するものはなく、彼がしたことはチームの速度に自然に組み込まれます。

彼の仕事は製品のバックログに取り込まれ、次の計画会議で見積もられるべきです。残りの労力がすぐに何であるかを予測できない場合は、スプリントの時間をボックス化して、それを把握する必要があります（つまり、スパイク）。

あなたが開発者を「過剰達成」と表現するのは興味深いことですが、これは彼が他のチームメンバーよりもはるかに多くの価値を追加していることを意味すると思います。

余分な作業を行うのが困難なことは、チームに次善（または場合によっては機能不全）の何かがあることを意味します。

この場合、おそらくほんの少しの余分な努力で、なぜ彼はそれほど多くを達成しているのかを自問する必要がありますか？

チームの他のメンバーがより多くを達成できるようにすることは可能ですか？

チームがマイクロ管理され、規範的なユーザーストーリー、完了の定義、潜在的に開発者に息苦しさをもたらす可能性があるという状況を見てきました。この開発者は彼がしたい仕事をしていますか？彼は良い決断をしていると思います。作業週にこの方法で作業することは、チームの他のメンバーにも役立ちますか？

先生にもなってもらう

グループで最高かつ最も高度なスキルを持つスター開発者がいることは素晴らしいことです。私はこれを称賛し、compめます。多くの場合、そのような人々は組織を結びつける「接着剤」です。

私はこの課題を「経験の浅い開発者を最も先進的な開発者の生産性に近づける方法」と考えています。

これを行うための優れた方法の1つは、スター開発者がより経験の浅いチームメンバーの指導、トレーニング、および指導により多くの時間を費やすことに集中することです。私は最初にこれをスター開発者と1対1で話し合うので、彼らはあなたが何をしているのか、そしてその理由を知っています。それ以外の場合、それは隠された議題/貧弱な管理として疑いを持って見られるかもしれません

あなたが1日1回または2回スタンドアップをするとき、この人が仕事を使い果たし、他の人がまだ仕事をしている場合は、ジュニアメンバーとペアリングし、彼女の素晴らしい知識と経験を伝えることができるようにペアプログラミングを検討してください。「誰か助けが必要ですか？ペアを探していますか？」という質問を必ずしてください。

また、すべての人が使用しているツールセットの強化、テクニカルブッククラブディスカッショングループの実行、他の組織プロジェクトへの参加など、最高の開発者向けの「サイド」ワークを見つけることもできます。

別の質問に答えます。スクラムでこの状況に対処する方法は本当に重要ではないと思います。スクラムはとにかくガイドラインのようなものです。これを実現したい場合は、作業が既に完了していると単純に仮定するなど、プロセスを適応させる簡単な方法を見つけてください。

本当の問題は、この開発者に彼がしていることをしてほしいかどうかです。その質問への答えには、いくつかの側面が重要な役割を果たすと思います。

1. プログラマーは良い仕事をしていますか。
2. 誰もが彼が自分で仕事をすることで大丈夫ですか（それが良いか悪いかに関係なく）。結局のところ、彼は設計プロセスを回避しています！
3. 余分な時間が支払われるかどうか。

これらすべては、彼がやっていることをあなたの製品にとって意味があるかどうかに影響します。繰り返しますが、設計プロセスに決定を組み込むことは、実際には問題ではありません。柔軟に対応してください。

チームがスプリントで作業を決定していないため、これはスクラムのテナントに違反します。これはスクラムチームです。規律が配られる場合、チームはこのプログラマを規律する必要があります。

これが引き起こすもう1つの問題は、チームの速度に合わせてねじ込むことです。帯域外作業は速度に影響せず、燃え尽きません。したがって、この帯域外作業は完了し、チームは平均で50ポイントの速度を達成しますが、50ポイント以上が完了します。製品所有者はこれを見て、次のスプリントでより速い速度を要求します。不可能な速度。

チーム（POまたはScrumMasterではない）は、不正なプログラマーでこれに対処する必要があります。