アジャイルMVP（最も価値のあるプレーヤー/プログラマー）

最近、私は（スクラムを使用した）アジャイルプロジェクトに関与していて、各スプリントの最後にチームが開発者「MVP」とQA「MVP」を指名し、チーム。次にMVPは、小さな金銭的報酬と無料のランチ、およびトロフィーを彼の机に表示するために受け取ります。これまでのところ、この報酬システムを使用して2つのスプリントを達成しました。

これから私が見る良いことは次のとおりです：

• より多くのバグが修正されました（これは上級管理職が見たいものであり、彼らが望む方向への数の変化です）
• 各「チーム」のMVPが認識され、自尊心が高まります（または自我の高まりですか？）

（少なくとも開発者の観点から）そのようなことをするのに悪い面をいくつか考えていることに気づきました。

• バグ修正の品質が低下するほど、その数に非常に関心がある開発者が数人います。ある領域の修正により、別の領域で回帰が発生しています。
• バグ数を増やすために、「より簡単でより速い」バグを厳選している開発者が数人います。私はここで悪いのは良いことだと思います。
• より高い優先度（多くの場合、「修正するのがより困難/より長い」に関連する）の​​欠陥は、実際にはより低い優先度になります。
• ブロッキングの欠陥は、通常より時間がかかり、QAとのより多くの調整を必要とするため、適時に対処されません。
• 開発チーム内のチームの側面が失われました。開発とQAが一体となって機能するチームの側面も改善されていませんが、以前と比べてあまり変わっていません。
• バグ修正を超えて作業したり、その数に向けて作業したりすることは、簡単に認識/追跡することはできません。

私は、チームがそれぞれをどのように処理するかに応じて、上記の「悪い」のそれぞれにある程度対処できると信じています。

私の質問は、スプリントごとにMVPを認識しているこのようなものをうまく成功させた人はいますか？もしそうなら、あなたはその成功に何が貢献したと思いますか？

アジャイルは、個人の努力ではなく、チームの努力を強調します。したがって、このアプローチは明らかに俊敏ではありません。

これにより、チームのコラボレーションを促進するのではなく、各チームメンバーが自分の結果に集中することができます。それは、メンバーがお互いに助け合うのを回避すること（またはさらに悪いこと）につながることさえあり、長期的にはチームが良くなるのを妨げます。

彼らが良い仕事をしたなら、チーム全体に報酬を与えることを勧めます。

これは-bad- ゲーミフィケーションが適用された良い例だと思います。問題は、プログラマーが潜在的に問題を解決し、課題を克服する（ハードバグを見つけて修正する）ことに本質的な動機があり、そして、スクラムを実装してからTEAMとして働くことです。言い換えれば、彼らは潜在的に良い仕事をしたかったのです。

現在、少なくとも一部の人にとって、この固有の動機またはその一部は、ゲームメカニズムの一部であるタイトル（「MVP of the week」）と報酬（金額、および無料ランチ）で構成されるextrinsincの動機に置き換えられています。ゲーミフィケーションされたプロセスの。

ゲーミフィケーションは職場でうまく適用できますが、内発的/外発的動機を利用する際には非常に注意する必要があります。外因性の動機付けは、動機付けが本質的になるために、自己決定を促進する力を持たなければなりません。しかし、ここで起こったことはその逆であり、プログラマーは勝つために「ゲームをしている」。

これを修正するためにできることは、管理者にルールを少し変更するように依頼することです：

• チケットの難易度と優先度に一致するポイントを与えます。見つけにくいバグを修正することがポイントごとにはるかに興味深いものになるようにします。
• 協力して問題を解決するためのポイントを与える（ここでも、チーム）。これにより、より多くのプログラマーがQAを操作できるようになります。たとえば、プログラマーとQAが協力して解決している問題にポイントを与えます。
• ポイントが最も多いタイトルとチケットが最も多いタイトルを付けます。これは、プログラマーの競争力を満足させるはずです。
• チームのすべてのメンバーのポイントを合計することにより、DevとQAの間の友好的な競争を確立することができます

ただし、回帰バグが発生する可能性を減らすことは別の問題です。たとえば、否定的な点を適用することもできますが、それは一種の罰となるため、それは良い考えではないと確信しています。おそらく、過去1週間にリグレッションバグが検出されなかった場合は、いくつかのポイントから自動的にスプリントを開始する方が良いでしょう。回帰バグが検出された場合、プログラマーは0から始めます。

また、「ゲーミフィケーション」には「ゲーム」があります。また、ゲームの基本的な側面は、自発的にプレイ/参加することです。仕事の文脈では、それはここでそうである管理によって課されるかもしれませんが、通常誰もこれに強制されるべきではありません。

結論として、このMVPは必ずしも悪い考えではありませんが、アプローチを少し変更して、ビジネス（重要なバグの解決）を最初に行い、個人ではなくチームワークを強調することができます。

チームメンバーの取り組みに対するある種のグループ認識は、価値のある動機になる可能性がありますが、この場合、それは誤って適用されているようです。あなたはMVPが投票によって選ばれたと述べていますが、スプリントごとに修正されたバグの数についての多くの言及があります。あなたの時間はMVPの面白い定義を持っているようです。「最も価値のある」という称号に値する人物は、そのスプリントでソフトウェアに最も価値を加えた人物だと思います。チームメンバーがすばやく修正できるバグを選び、可能な限り迅速にそれらをブラストし、後退バグやその他の問題を引き起こしている場合、彼らは価値を追加せず、誰でもより多くの仕事を生み出しています。それらを追跡し、それらの問題を特定して修正します。

私の提案は、次にあなたのチームがこれらの票の1つを獲得したときに適切な議論を始めることを試みることです。単なる手本にしないでください。最初にそれを話します。誰かが行った「修正」の数に基づいて投票しているように見える場合は、それらの修正がどこで回帰を引き起こしたかを（巧みに）指摘し、おそらくそれらの回帰を修正した人が他の人のクリーンアップに指名されるべきだと示唆します。混乱。誰かが1つの厄介な問題にスプリント全体を費やしていた場合は、チームにそれを指摘し、この人の修正数は1つですが、ソフトウェアの主要な問題を一人で解決したという事実を強調します。とても嫌なので、他の誰もそれに触れたくありませんでした。

簡単な修正を見つけて、急いでまたは無計画に実行することは価値がないので、それを行うだけの開発者は、おそらくMVP候補としての資格を得るべきではありません。新しいMVPを選択するときは、チームとそのMVPのことをすべて忘れて、ソフトウェアを見てください。前回からのそのソフトウェアの単一の最も重要な変更を選択してください。ここではシングルを意味します。「それほど多くの小さなバグ」は大きな変更ではありません。特に目立つバグは修正されましたか？素晴らしい新機能が追加されましたか？この1つの大きな変更が何であるかを特定したら、誰がそれを担当したのか尋ねます。それらの人々の1人はおそらくあなたの実際のMVPです。「それほど多くの小さなバグではない」が唯一の違いである場合、そして唯一次に、バグカウントはMVPの有効な指標です。それでも、発生した回帰バグに対する修正されたバグの比率を調べます。誰かが引き起こすすべてのバグは、その数から少なくとも1を差し引きます。実際、私は1よりも大きいと言います。なぜなら、悪い修正は未知のバグを引き起こし、それを見つけなければならないからです。これは、すでに発見されている既知のバグよりも悪いものです。既知のバグを修正するには、開発者の努力が必要です。未知のバグを見つけるのはQAの努力、受け取りおよび修正に開発者の努力をした後、QAがそれを欠場するというリスクがあります。

理論的には、開発者が賞品への道がより少ない、より大きな問題を修正することであることに気付いた場合、彼らは難しい問題、複雑な問題、ブロッキング欠陥を目指します。これは、周りを移動するのに十分な肉の問題がないか、問題がより多くの目を必要とするほどトリッキーであるために、時々一緒に結束する必要があります。おそらく、このようなケースでは、バグの修正に向けてさらに多くの作業を行った人々がすぐにわからなければ、賞が共有される可能性があることを示唆しています。開発者はおそらくそれを知っているでしょうが、あなたは経営陣が関与していると言っていましたし、経営陣は常にその点を理解しているわけではありません。

他のすべてが失敗した場合は、MVPプロ​​グラムを忘れてください。スクラムの外にいる他の開発者と話し、MVPアワードがソフトウェアに与える悪影響を指摘します。あなたが彼らにそれを無視するようにさせることができるか、それをそんなに大事にしないかどうか見てください。トロフィーを引き出しに置いておき、仕事の後にチームのために飲み物の賞金を使い、無料のランチを使って、カップケーキの束のような共有できるものを手に入れます。アジャイルはチームシステムです。個々のパフォーマンスリスクを強調し、チームを互いに対戦させます。期限が過ぎた後、予算超過のソフトウェアを出荷し、バグに満ちたソフトウェアを分けて発送します。

これは、特定の慣行（MVPとしての公認）がチームの振る舞いに重大かつ間接的な影響を与える可能性があることの典型的な例です。これは、インセンティブ、動機、および報酬を超えて、実際に環境/行動心理学および意思決定アーキテクチャーのアイデアに触れます。クール。

問題は、厳格なポリシーを設定したり、人々に何かを強制したりすることなく、チームがすべての正しいことを自然に行えるようにプロセスを設計するにはどうすればよいですか？

チームで機能するプロセスを設計するためのメカニズムとして、プロセスのアフォーダンス（Donald NormanのDesign of Everyday Thingsの伝統に従って）を使用することについて書きました。基本的な考え方は、プロセスの実践が個人の行動に直接影響するということです。そのため、プロセスのアフォーダンスがチームの価値と完全に一致していない場合に問題が発生します。

私はこのトピックについていくつかのワークショップを行ってきましたが、この特定の問題は例としてグループで時々出てきます。質問で共有したケースにアフォーダンスの理論を適用すると、次のようになります。

チームが一貫性、予測可能性、高品質のコードを重視していると想定します。

観察したネガティブな振る舞いのランドリーリストがあり、それらはすべて、欠陥メトリックを使用してチームのMVPを選択することに由来しているようです。たとえば、チームメイトは当然ながら、バグを無計画に選択して修正することを望んでおり、3つの値すべてに悪影響を及ぼします。（私は以前にも問題があったと思います、そしてこれがMVPのアイデアにつながったものです）。

欠陥メトリックに基づいて単一のMVPを持つのではなく、いくつかの小さな、しかし重要な変更を行うことにより、チームの動作を変更しようとします。

• チームの価値観を明白に抱いているすべての（1人だけでなく、すべての）個人に「チームの称賛」を与えましょう。これにより、予測可能性が促進され、例を通じてチームの価値体系が民主化されます。（私たちは実際に私たちのチームでこれを行います。）
• すべてのバグ修正のためにペアプログラミングを開始（または「バグバディ」を割り当て）。バディが不規則な行動を和らげるので、これは、急いで、または中途半端なプログラミング決定を落胆させることによって品質を促進し、一貫性を促進します。（このアイデアは、ワークショップ中に一般的に提案され、直感的に思えます。）

そして、これらはアプローチを実証し、あなたを始めるためのほんの一例です...

このアプローチの優れている点は、プロセスの変更を積極的に設計していて、プロセスの変更に正当な理由があることです。オブジェクトやUIデザインと同様に、結果を測定して、機能しているかどうかを理解することもできます。

MVPプロ​​グラムのようなものが機能することを保証するために行う最も簡単な調整の1つは、最も困難な労働者ではなく、チームの成功にとって最も価値があることに対してチームメンバーに報酬を与えることです。

私たちは、バグや機能に取り組んでいない人々を認識することでこれを成功させましたが、チームの全員がより成功するように素晴らしいことをしました。たとえば、私たちには1人の開発者がいて、チームに新しいメンバーの束をメンターして、彼らがアーキテクチャと私たちがどのように働いたかを学ぶことができるようにしました。一人の開発者がチームの他のメンバーの支援により多くの時間を費やしていたために個々の開発者の速度が低下したとしても、迅速かつ効率的に結果を提供できるこれらの新入社員がいたため、私たちの速度は急上昇しました。

チームワークに報酬を与えると、チームは自分の個人的な成功ではなく、チームが重要であることに気づくでしょう。