成功したユーザーストーリーの完了数に応じてスクラムメンバーを評価することは正しいですか？

私のマネージャーがチームに「今から成功したユーザーストーリーは評価の対象となるでしょう！」 と言ったとき

私たちはショックを受けてそこに座っていましたが、それは彼が私たちに与えたいくつかのあごを落とす瞬間の1つでした:-)

これはアジャイル開発方法論のすべての概念と目標を台無しにするので、それは愚かな考えだと感じました。

みなさんの考えを教えてください。そして、どうすれば彼を説得できますか？

Sandyさん、残念ながら、あなたのマネージャーの発言は、特にスクラムと一般的にアジャイルについての古典的な誤解です。

提案されたアプローチは、コラボレーションを無効にし、集団的なコード所有権の原則に対抗します。アジャイルのユーザーストーリー（実際のアジャイルの場合）は、複数の人に触れられる前に完成することはめったにありません。また、ユーザーストーリーは、反復内で完了するために群がる必要がある場合があります。個々のインセンティブが反対方向に180度揃っている場合、どのようにしてそれを実現しますか？

あなたのチームの本能は正しいです。上司への対応についてブレインストーミングを行う際に、短期的にどのような情報源を読むことをお勧めしますか？Mike Cohn、Martin Fowler、Elizabeth Hendrickson、Jurgen Appelo、Esther Derbyなどの有名なアジャイル専門家のブログや、アジャイルチーム編成に関する記事をご覧ください。

この評価方法に対する私の主な反対点は、それが開発者間の協力の障害になる可能性があることです。開発チームの生産性の重要な部分は、チームメンバーが互いに助け合う意欲だと思います。提案されたスキームを理解していると、開発者が自分の割り当てられたタスクに固執し、行き詰まり、少しの援助で簡単に行き詰まる可能性がある他のチームメンバーを無視する可能性があります。

私たちは常に、プログラマーがチームとビジネスに貢献していることを探しています。

これは、コードの行やバグの数の測定と同等ですが、少し洗練されています。

一見、測定には何の問題もありませんが、それについて考えるとき、異議を唱え始めます。

• もっと複雑な話はどうですか？

頭に浮かぶ最も明白なものです-他にもあると思います。

あなたの上司は明らかにこれが良い考えだと考えているので、反対意見を提起するときに解決策を提示することもできるように注意する必要があります。このソリューションは、新しいスキームではなく、彼のスキームの変更である可能性があります。

したがって、たとえば、あなただけの多くのもう一つの「難しい」上で動作し、これが誰かよりも完了します「簡単」の物語に取り組んでいる誰かを指摘したいかもしれませんかもしれません開発のあまり重要な側面に集中につながるし。したがって、1つの解決策は、ストーリーの数だけでなく、ストーリーポイントの数を考慮することです。

これはどの測定でも同じ問題に戻ることをChrisFに同意します。あなたが賞賛するものはあなたが得るものです。そのシステムが何であろうと、システムをゲームする人々は常にいるでしょう。

私がプログラマーにやりがいを与えるために私が見つけた唯一の本当の効果的な方法は、3つのステップからなります。

1. リードは、チームのメンバーの能力を理解しています。
2. マネージャーは、自分の体重を減らしていないチームメンバーのリードの推奨事項を聞きます。
3. チームはスプリントが成功したことで全体として賞賛されています。

重要なのは、プログラマーが統計を見て「調整」できるマシンの歯車ではないということです。実在の人々は全体として調査され、改善される必要があり、チームは競争的な方法ではなく、協同組合で互いに信頼できる必要があります。

チームの貧しい人々は、手放されると見なされる前に、改善と充実のあらゆる機会を与えられます。最終的に、優れたプログラマーはこの環境で繁栄し、改善を拒否する貧しいプログラマーは手放されます。

ほとんどの場合、ユーザーストーリーは共同で作成されます。このため、この評価基準に基づいて個別の評価を行うことは事実上不可能です。

計画プロセスもチームの努力であり、システム全体が不正になるので、メトリック自体は簡単に操作できます。それは間違いなく、人に焦点を当てたプロセスでは望ましくないことです。

チームの成功に基づく何らかのボーナスシステムによって良いパフォーマンスが認識される必要があると思いますが、ユーザーストーリーは成功の良い指標ではありません。