スクラム：過剰達成の開発者が行った作業を帯域外に統合する方法？
「典型的な」SCRUMチームがあり、スプリントのために働くことを約束し、バックログも維持します。最近、バンド外の仕事（通常の労働時間/スプリントの外で仕事をすることを選んでいる）をしている、達成し過ぎている開発者の仕事を統合/処理しようとする問題に遭遇しました。
例として、チームが50点の作業を取り入れた場合、スプリントの終わりまでにSCRUMフレームワーク内ですべての作業を完了し、彼らと会社は幸せだとしましょう。チームメンバーの1人が、自分自身、バックログアイテム、自分の空き時間に取り組むことにしました。彼らはこの作業をチェックインせずに保存します（TFSを使用し、シェルフセットにあります）。
これをどのように処理しますか？問題のいくつか..
- 次のスプリント中に、このチームメンバーはプログラミング作業が99％完了し、コードのレビューとテストが必要であると述べています。 SCRUMとアジャイル方法論でこれにどのように対処しますか？
- 他の開発者は、作業が帯域外で行われたため、これらのストーリーに関連する設計決定に関与していないことに不満を述べています。
- 当社の製品所有者は、この「無料」の作業を引き込もうとしていますが、過剰に達成しているメンバーは、そうでなければチームがスプリントで達成できない機能を製品に追加するために、意図的にこれを行う可能性があります。これが「プロセス」を壊しているという見方があります。明らかに、QA、UI、およびドキュメントの作業は、この作業で実行する必要があります。
SCRUMチームに時間外勤務を強制しないことについて多くの議論が見られますが、スプリントの計画と実行中に出された期待を超えて、チームのメンバーが上に働いてどうですか？私はこの人を統治し、あなたが余分に働くことができないと言うのをためらいます（もちろん燃え尽きに注意します）が、同時にそれはチームの特定のメンバー（すべてではない）にいくつかの問題を引き起こしているようです。
過剰達成メンバーが行った作業をSCRUMとソフトウェア開発のアジャイルプロセスに統合するにはどうすればよいですか？
さて、誰かが熱心に素晴らしいコードを書く必要があります。すべての重点を置いて：
LET THEM
スクラムスプリントでいくつかの問題が発生しています。物事の壮大な計画では本当に重要ですか？もし彼が予定通りのことを成し遂げているなら、彼に続けてあなたのために素晴らしいものを作らせてください。
私は、スクラムのような人工システムの制約の外でプログラマーを許可しなかったために会社を辞めた素晴らしいプログラマーを何人か知っています（私自身は、栄光のQAのように扱われた後、最後の仕事を辞めました）。入力に関する他の開発者からの苦情（完全に有効な苦情、私が追加する場合があります）がある場合は、「20％時間」プログラムを導入して、彼（および他の人）が最小限の干渉で最善を尽くせるようにするのが最善です。
将来のストーリー（他の人からの入力が必要になる可能性がある）の代わりに、開発者に新しい技術や機能を試してもらいます。あなたは他の方法では探求されなかったであろう素晴らしい新しい機会を見つけるかもしれません。この開発者には、あなたがそれらを許可しただけで試してみたいことがいくつかあると私は確信しています。
ここで検討すべき2つの点があります。
- 誰かの創造的な流れを妨げないでください。
- 開発者が時間外の仕事をしたい場合は、彼らに任せてください。
- 他人のために仕事を作成しないでください。
- 開発者が時間外の仕事をしたいのであれば、確かに他の人のためにより多くの仕事を作らない方がいいです。
ポイント2は、他の開発者が心配しているものと思われます。
あなたが言ったように、彼らはコードがチーム全体の入力なしで書かれているという事実を好きではありません。デザイン的には劣っているからかもしれません。また、デザインが劣っているコードには、その周りの他のコードに感染する方法があります。
それで、あなたは何ができますか？
意欲的な開発コードを心ゆくまでお届けしますが、彼の課外コードが使用されると想定する理由はありませんであることを明確にしてください。
結局のところ、彼はチームの一部なので、チームはすべてのコードの開発方法に関与する必要があります。
しかし、彼の作品が健全で、チームの合意した設計に適合する場合、彼はすでに書いたものの多くを使用することができます（ボーナス！）。そうでない場合、彼は次に彼が有利なスタートを切ることを決定したときに彼のデザインについてもっと考えることを強いるでしょう。
このように、誰にも言われない[〜＃〜] no [〜＃〜]だれも彼らのために作成された余分な作業を持ちません。
彼をチームに戻す
あなたは自分自身に尋ねる必要があります（または過剰達成者を含むより良いチーム）：
この動作に問題があるのはなぜですか？
あなたは開発者を過剰達成者としてラベル付けしているので、彼の作品は質が良いと思いますので、これは問題ではないと思います。
しかし、他の問題があるようです：
- 余分な作業は適切にテストされていません
- 文書化されていません
- チームの他のメンバーはそれを知りません
- 開発者はPOではなく、次に実装することを決定します
- 開発者は、さまざまな利害関係者からフィードバックを得ず、自分の作業に組み込んでいません。
次の理由は次のとおりです。
なぜ開発者はそれをするのですか？
- スプリントの最後に十分な作業が残っていない場合は、次に取り組むべきことについてチームの決定（POを含む）があるはずです。開発者はなぜこの決定を回避するのですか？
これらの質問に答えたら、自分の質問に答え始めることができます。
- それが問題ではないなら、彼に任せてください。一部の人々はスクラムを宗教として扱いますが、それはこのようなものであってはなりません。
- チームで2つの問題が発生している可能性が高くなります。不正な開発者によって引き起こされた問題と、不正な開発者の動作をトリガーした問題です。後者を解決する方法を見つけると、最初の方法はなくなります。
ミックスに無料の作業を追加するのは良いことだという考えが好きですが、これは無料の作業ではありません-その単一の開発者がテスターであり、QAとビルドの担当者とデザイナー、そしてその他すべてでもない限り。彼の作品が次のスプリントに影響を与えることなく投入できる場合は、それを試してください。しかし、私はそうではないと思います。他の誰もが、少なくとも、彼が何をしたのか、それが彼らにどのような影響を与えているのかを理解する必要があります。彼らは彼の変更が行われていることを理解し、彼の努力を繰り返さないようにする必要があります-先週、不正な人がそれを行ったことを見つけるためだけに彼らが仕事に熱心に取り組んだことを誰かに伝えるのは難しいです。
あなたはアジャイル環境で働いていますが、私がアジャイルについて知っていることの1つは、それがあなたのために働くように設計されており、あなたに対してではないということです。したがって、このような課外活動が行われるようにするには、作業方法を変更する必要があります。つまり、全員の意見と同意を得ることです。彼らの賛同がなければこれを行うことはできません。その重要。チームが気に入らない場合、悪党はそれをやめます。の終わり。彼の仕事がどれほど優れていても、彼が好きなことをしているのは1人の男ではありません。チームが最初に来ます。
したがって、次の計画会議で全員に座り、これについて話し合う必要があります。すべてのチームメンバーは、許可するか、この種の活動をより適切に管理するためにプロセスを変更するかを決定する必要があります。
多分あなたは誰もが彼らの好むプロジェクトに取り組み、それらをテーブルに持ってくるソリューションを得るでしょう（あなたは最初にそれの問題を浮き彫りにする、あなたの配達への混乱を想像することができます）またはあなたは命令することができます各開発者が好きなソリューションを開発するためのオートモミーを持っている領域です。オープンソースプロジェクトがいくつ機能するかと同様に、「貢献」されます。または、誰もが自由に試してみることができます（古い20％の時間）。
私たちは同じことにも直面しました。基本的に20ポイントのようなものをコミットしましたが、先週またはスプリントの途中でさえコーディングタスクが不足しましたが、テストと残りのプロセスのため、別のPBIを選択するリスクはありませんでしたプログラマは、バックログを調べて、将来のPBIの開発を開始し（サイレントに！）、PBIがコードのレビューとテストの準備ができていることを計画する際にチームの他のメンバーに通知することでした！あなたが言ったように。
私たちのPOから実際にいくつかの懸念が生じましたが、私たちにはもっと能力があるようですが、チームの潜在能力を十分に活用していません。スプリントに失敗するリスクがありました。この問題について考えた後、私たちはスクラムについての見方を変える必要があることがわかりました。主な問題は、人々がそのリスクを冒したくないということですコミット PBIなのでチームは感じていません無料のプログラマーがいる場合に備えて、新しいPBIを選択するリスクを冒すのは良いことです。
単に約束をするのではなく予測 PBIを開始しました。予測とは基本的に、スプリントの計画と開始時に25ポイントを選択することを意味します。また、スプリントの途中でプログラマーが自由になったときは、コーディングタスクがないため、将来のPBIの1つを選択して現在のスプリントに配置し、作業を開始します。その上で、PBIが同じスプリント内のすべてのプロセス（テスト、マージなど）を通過できた場合、そのPBIのためにスプリントに失敗せず、残りの作業をそのまま進めることができなければ、チームにとってボーナスポイントです（テストまたはメージングなど）を次のスプリントに移動し、残りの仕事をポーカーでやり直します。したがって、最悪のシナリオでは2つの異なるスプリントで実行できます。スクラムバットのように聞こえるかもしれませんが、実際には作業方法が改善されました。私はその利点を以下のように要約できます：
- より多くのPBIを取るリスクを取ることで、スプリント失敗の恐怖症を克服します
- プログラマーとチームの余分な作業を可視化します
- チームの速度を向上させます
ただし、経験の少ないチームの場合、PBIを完了するためにチームにコミットメントが与えるプッシュが削減される可能性があります。
この開発者はテストとクリーン/ソリッドコードを記述していますか？それとも、彼/彼女は彼がすぐに成し遂げることができるものは何でもプッシュしていますか？私は個人的に、あなたの見積もりを台無しにしたり、他の問題が発生したことを指摘したりするため、定義された時間外に誰も作業することを許可しません。
ただし、プロセスに厳格であってはなりません。スクラムは単なるフレームワークなので、いつでもプロセスを調整して追加の時間を含めることができます（ただし、誰かが何をするかを計画するのは困難です）。
彼にプロジェクト以外の作業を依頼することもできます。新しい技術を見たり、彼が別のやり方でトレーニングを作成したりする。結論としては、あなたの計画したスケジュールの外で何が行われたとしても、あなたの見積もりは破棄され、私はそれを起こさせません。
他の回答のいくつかは、「過剰達成」開発者が「不正」または「スクラムの原則に違反している」ことを示唆しています。これは誤りであり、この開発者を奨励する必要があります（この時間内に特定の作業を行うように人々に依頼するべきではありませんが、提案を行い、アイデアを育てるのに役立ちます）。
人々がどのように働くかを規定するスクラムには何もありません、そして彼が行った余分なことは当然チームの速度に組み込まれます。
彼の仕事は製品のバックログに持ち込まれ、次の計画会議で見積もられます。残りの努力がすぐに何であるかを予測できない場合は、それを把握するためにスプリントの時間枠をタイムボックスに設定する必要があります（つまり、スパイク）。
興味深いことに、開発者を「過剰達成」と表現しています。これは、彼が他のチームメンバーよりもはるかに多くの価値を追加していることを意味していると思います。
余分な作業を行うことの困難さは、チームに最適ではない（または機能不全でさえある）何かがあることを意味します。
これが事実である場合、おそらく少しだけ余分な努力をするだけで、なぜ彼がそれほど多くを達成しているのかを自問する必要があります。
チームの他のメンバーがより多くを達成できるようにすることは可能ですか？
私は、チームがマイクロマネージメントされ、場合によっては規範的なユーザーストーリーを超え、完了の定義が開発者に窒息してしまう状況を見てきました。この開発者はheが望んでいる仕事をしていますか？私は彼が良い決断をしていると思います。平日でこのように働くことは、チームの他のメンバーにも役立つでしょうか？
彼らも教師になる
グループで最高かつ最も高度なスキルを持つスターデベロッパーがいることは素晴らしいことです。私はこれを称賛し、褒めます。多くの場合、そのような人々は組織をまとめる「接着剤」です。
私は挑戦を「経験の浅い開発者を最先端の開発者の生産性により近づける方法」と考えます。
これを行う優れた方法の1つは、スターの開発者が経験の少ない、遅いチームメンバーの指導、トレーニング、指導に多くの時間を費やすことに集中することです。まずスターデベロッパーと1対1でこれについて話し合うので、彼らはあなたが何をしているか、そしてその理由を知っています。それ以外の場合は、隠された議題/貧弱な管理として疑いをもって見られる可能性があります
1日1回または2回、スタンドアップを行うとき、この人が仕事を使い果たし、他の人がまだ仕事をしている場合は、ペアリングプログラミングを検討して、ジュニアメンバーとペアになり、彼女の優れた知識と経験を伝えられるようにします。 「誰か助けが必要ですか？誰かペアを探していますか？」という質問を必ずしてください。
また、全員が使用しているツールセットの拡張、テクニカルブッククラブのディスカッショングループの運営、他の組織プロジェクトへの関与など、仕事が終わったときに最適な開発者のための「副業」を見つけることもできます。