アジャイルMVP（最も価値のあるプレーヤー/プログラマー）
最近、私は（スクラムを使用した）アジャイルプロジェクトに関与していて、各スプリントの最後に、チームが開発者「MVP」とQA「MVP」を指名し、チーム。次にMVPは、小さな金銭的報酬と無料のランチ、およびトロフィーを彼の机に表示するために受け取ります。これまでのところ、この報酬システムを使用して2つのスプリントを達成しています。
これから私が見る良いことは次のとおりです：
- より多くのバグが修正されました（これは、上級管理職が見たいものであり、彼らが望む方向への数の変化です）
- 各「チーム」のMVPが認識され、自尊心が高まります（または自我の高まりですか？）
（少なくとも開発者の観点から）そのようなことをするのに悪い面をいくつか考えていることに気づきました。
- バグ修正の品質が低下するほど、その数に非常に関心がある開発者が数人います。ある領域の修正により、別の領域で回帰が発生しています。
- バグ数を増やすために、「より簡単でより速い」バグを厳選している開発者が数人います。私はここで悪いと思うかもしれません。
- より高い優先度（多くの場合、これは「修正するのがより困難/より長い」に関連しています）の欠陥は、実際にはより低い優先度になります。
- ブロッキングの欠陥は、通常より時間がかかり、QAとのより多くの調整を必要とするため、適時に対処されません。
- 開発チーム内のチームの側面が失われました。開発とQAが一体となって機能するチームの側面も改善されていませんが、以前とあまり変わっていません。
- バグ修正を超えて作業したり、その数に向かって作業したりすることは、簡単に認識/追跡することはできません。
私は、チームがそれぞれをどのように処理するかに応じて、上記の「悪い」のそれぞれにある程度対処できると信じています。
私の質問は、スプリントごとにMVPを認識している誰かが、このようなものをうまく成功させることですか？もしそうなら、あなたはその成功に何が貢献したと思いますか？
アジャイルはチームの努力を強調し、個人の努力ではありません。したがって、このアプローチは明らかに俊敏ではありません。
これにより、チームのコラボレーションを促進するのではなく、各チームメンバーが自分の結果に集中することができます。それは、メンバーがお互いに助け合うことを回避すること（またはさらに悪いこと）につながる可能性さえあり、長期的にはチームが良くなるのを妨げます。
彼らが良い仕事をしたなら、チーム全体に報酬を与えることを勧めます。
これは-bad- gamification が適用された良い例だと思います。問題は、プログラマーが潜在的に問題を解決し、課題を克服する（ハードバグを見つけて修正する）ことに本質的な動機があり、さらに、スクラムを実装してからTEAMとして働くことです。言い換えれば、彼らは潜在的に良い仕事をしたかったのです。
現在、少なくとも一部の人にとって、この固有の動機またはその一部は、ゲームメカニズムの一部であるタイトル（「MVP of the week」）と報酬（金額、無料ランチ）で構成されるextrinsincの動機に置き換えられています。ゲーミフィケーションされたプロセスの。
ゲーミフィケーションは職場でうまく適用できますが、本質的/非本質的な動機を利用する際には非常に注意する必要があります。外因性の動機付けは、動機付けが本質的になるために、燃料を供給する力 自己決定 でなければなりません。しかし、ここで起こったことはその逆であり、プログラマーは勝つために「ゲームをしている」。
これを修正するためにできることは、管理者にルールを少し変更するように依頼することです：
- チケットの難易度と優先度に一致するポイントを与えます。見つけにくいバグを修正することがポイントごとにはるかに興味深いものになるようにします。
- 問題を解決するためのポイントを与える協力的（これもチーム）。これにより、より多くのプログラマーがQAを操作できるようになります。たとえば、プログラマーとQAが協力して解決している問題にポイントを与えます。
- ポイントが最も多いタイトルとチケットが最も多いタイトルを付けます。これは、プログラマーの競争力を満足させるはずです。
- チームのすべてのメンバーのポイントを合計することにより、DevとQAの間の友好的な競争を確立することができます
ただし、回帰バグが表示される可能性を減らすことは別の問題です。たとえば、否定的な点を適用することもできますが、それは一種の罰となるため、それは良い考えではないと確信しています。過去1週間にリグレッションバグが検出されなかった場合は、数ポイントで自動的にスプリントを開始する方がよいでしょう。回帰バグが検出された場合、プログラマーは0から始めます。
また、「ゲーミフィケーション」には「ゲーム」があります。そして、ゲームの基本的な側面は、あなたが自発的にプレイ/参加することです。仕事の文脈では、それはここでそうであるように管理によって課されるかもしれませんが、通常誰もこれに強制されるべきではありません。
結論として、このMVPのことは必ずしも悪い考えではありませんが、アプローチを少し変更して、ビジネス（重要なバグの解決）を最初に行い、個人ではなくチームワークを強調することができます。
チームメンバーの取り組みに対するある種のグループの認識は価値のある動機になる可能性がありますが、この場合、それは誤って適用されているように思えます。あなたはMVPが投票によって選ばれたと述べていますが、スプリントごとに修正されたバグの数についての多くの言及があります。あなたの時間はMVPの面白い定義を持っているようです。「最も価値のある」という称号に値する人物は、そのスプリントでソフトウェアに最も価値を加えた人物だと思います。チームメンバーが迅速に修正できるバグを選び、可能な限り迅速にそれらをブラストし、後退バグやその他の問題を引き起こしている場合、彼らは価値を追加せず、誰でもより多くの仕事を生み出しています。それらの問題を特定して修正するためにそれらをフォローする。
私の提案は、あなたのチームが次にこれらの票の1つを獲得したときに適切な議論を始めることを試みることです。単なる手本にしないでください。最初にそれを話します。誰かが行った「修正」の数に基づいて投票を獲得しているように見える場合は、それらの修正がどこで回帰を引き起こしたかを（巧みに）指摘し、おそらくそれらの回帰を修正した人が他の人々のクリーンアップに指名されるべきだと示唆します。混乱。誰かがスプリント全体を1つの厄介な問題に費やしてしまった場合は、チームにそれを指摘し、この人の修正カウントは1つですが、ソフトウェアの主要な問題を一人で解決したという事実を強調します。とても嫌なので、他の誰もそれに触れたくありませんでした。
簡単な修正を選択して、急いでまたは無計画に実行することは価値がないので、それを行うだけの開発者は、おそらくMVP候補としての資格を得るべきではありません。新しいMVPを選択するときは、チームとその関係者のことをすべて忘れて、ソフトウェアを見てください。前回からのそのソフトウェアの単一の最も重要な変更を選択してください。ここではsingleを意味します。 「それほど多くない小さなバグ」は大きな変更ではありません。特に目立ったバグは修正されましたか？素晴らしい新機能が追加されましたか？この1つの大きな変更が何であるかを特定したら、誰がそれを担当したのか尋ねます。それらの人々の1人はおそらくあなたの実際のMVPです。 「それほど多くの小さなバグではない」がonlyの違いである場合、そしてonly次に、バグカウントはMVPの有効な指標です。それでも、発生した回帰バグに対する修正されたバグの比率を調べます。誰かが引き起こすすべてのバグは、カウントから少なくとも1を差し引きます。実際、私は1よりも大きいと思います。なぜなら、悪い修正はunknownバグを引き起こし、それを見つけなければならないからです。 既知のバグはすでに発見されています。既知のバグを修正するには、開発者の努力が必要です。不明なバグは、QAが見つけ、および開発者が修正する必要があり、QAが見逃してしまうリスクがあります。
理論的には、開発者が賞品への道がより少なく、より大きな問題を修正することであることに気付いた場合、彼らは難しいもの、複雑なもの、ブロッキング欠陥を目指します。これは、周りを移動するのに十分な肉の問題がないか、問題が より多くの目 を必要とするほどトリッキーであるため、それらを時々一緒に束ねる必要があります。おそらく、このような場合、バグの修正に向けてより多くの作業を行った人々がすぐに明確でない場合、賞が共有される可能性があることを示唆しています。開発者はおそらくそれを知っているでしょうが、経営陣が関与しているとあなたは言った、そして経営陣は常にその点を理解しているわけではない。
他のすべてが失敗した場合は、MVPプログラムを忘れてください。スクラムの外にいる他の開発者と話し、MVPアワードがソフトウェアに与える悪影響を指摘します。あなたが彼らにそれを無視するようにさせることができるか、それをそんなに大事にしないかどうか見てください。トロフィーを引き出しに置いておき、仕事の後にチームのために飲み物のラウンドに賞金を費やし、無料のランチを使って、カップケーキの束のような共有できるものを手に入れます。アジャイルはチームシステムです。個々のパフォーマンスリスクを強調し、チームをお互いに引き離します。期限付きの予算超過で、バグに満ちたソフトウェアを出荷し、分割してあなたは立ちます。
これは、特定の慣行（MVPとしての公認）がチームの振る舞いに重要かつ間接的な影響を与える可能性があることの典型的な例です。これは、インセンティブ、動機、および報酬を超えており、実際に環境/行動心理学および意思決定アーキテクチャーのアイデアに触れています。クール。
問題は、厳格なポリシーを設定したり、人々に何かを強制したりすることなく、チームがすべての正しいことを自然に実行できるようにプロセスを設計するにはどうすればよいですか？
アフォーダンスの使用について書きました （伝統的に ドナルドノーマンの日常のデザイン ）は、チームで機能するプロセスを設計するためのメカニズムとしてのプロセスです。基本的な考え方は、プロセスの実践が個人の行動に直接影響するということです。そのため、プロセスのアフォーダンスがチームの価値と完全に一致していない場合に問題が発生します。
私はいくつかの このトピックに関するワークショップ を実行してきましたが、この特定の問題は例としてグループで時々出てきます。質問で共有したケースにアフォーダンスの理論を適用すると、次のようになります。
チームが一貫性、予測可能性、高品質のコードを重視していると想定します。
観察したネガティブな振る舞いのランドリーリストがあり、それらはすべて、欠陥メトリックを使用してチームのMVPを選択することに由来しているようです。たとえば、チームメイトは当然、バグを無計画に選択して修正することを望んでおり、3つの値すべてに悪影響を及ぼします。 （私は以前にも問題があったと思います、そしてこれがMVPのアイデアにつながったものです）。
欠陥の測定基準に基づいて単一のMVPを持つのではなく、いくつかの小さな、しかし重要な変更を加えることにより、チームの行動を変更しようとします。
- チームの価値観を明白に抱いているすべての（1人だけでなく、すべての）個人に「チームの称賛」を与えましょう。これにより、予測可能性が促進され、例を通じてチームの価値体系が民主化されます。 （実際、私たちはチームでこれを行います。）
- すべてのバグ修正のためにペアプログラミングを開始（または「バグバディ」を割り当て）。バディは不規則な行動を和らげるので、これは、せっかちなまたは中途半端なプログラミングの決定を思いとどまらせることによって品質を促進し、一貫性を促進します。 （このアイデアは、ワークショップ中に一般的に提案され、直感的に思えます。）
そして、これらはアプローチを実証し、あなたを始めるためのほんの一例です...
このアプローチの優れている点は、プロセスの変更を積極的に設計していて、プロセスの変更に正当な理由があることです。オブジェクトやUIの設計と同様に、結果を測定して、機能しているかどうかを理解することもできます。
MVPプログラムのようなものが機能することを保証するために行う最も簡単な調整の1つは、最も困難な労働者ではなく、チームの成功にとって最も価値があることに対してチームメンバーに報酬を与えることです。
バグや機能に取り組んでいない人々を認識することでこれを成功させましたが、チームの全員がより成功するように素晴らしいことをしました。たとえば、私たちは1人の開発者がチームに新しいメンバーの束をメンタリングするタスクを引き受けて、彼らがアーキテクチャと私たちの働き方を学ぶことができるようにしました。一人の開発者がチームの他のメンバーの支援により多くの時間を費やしていたために個々の開発者の速度が低下したとしても、迅速かつ効率的に結果を提供できるこれらの新入社員がいたため、私たちの速度は急上昇しました。
チームワークに報酬を与えると、チームは自分の個人的な成功ではなく、チームが重要であることを認識します。