スクラム：モチベーションの欠如の処理

よると、この、「スクラムは非常に意欲的、密接に協力し、クロスファンクショナルと自己組織化チームに依存しています。」それでは、コードの所有権を取得する意欲がない同僚をどのように処理しますか？所有権の取得に興味がある人をどのように獲得しますか？

これがあなたのチームの問題であるかどうかはわかりませんが、スクラムを最初に導入したときは間違いなく私たちのためでした。私たちの経営陣はある日私たちのところに来て、これからはあなたが個々のサイロで働くことはないと言った。代わりに、スクラムとして作業します。ここに、あなたがすべて従わなければならない新しいプロセスの束があります。

重要なのは、彼らが開発者である私たちに一度も来たことはなく、皆さんはどのように働きたいのかと尋ねたことです。何があなたを幸せにしますか？もっと効率的？。だから私が聞いたのは、「あなたはもはやコードを所有していません。あなたが書いたものは何でも踏みにじられます（ご存知のように、チームの所有権です）。ああ、今は毎日15分の退屈なスタンドアップがあります。そこでは人々が気にしないことについて話し合い、通常は30分かかり、その後2週間ごとに4時間の非常に退屈な計画会議が行われます。あなたのすべての人生。

現実には、これはアジャイルやスクラムではありません。これはあるスタイルの管理から、すべてが依然として一元管理される別のスタイルに移行しているだけでなく、すべての命を奪ってしまっただけでなく、私の履歴書を更新する時間。

過去12か月間、チームマネージャーに別のことを試すよう何度も働きかけた後、彼は私の提案を実際に取り上げてくれました。1年は非常に成功したと思います。

私たちにとって重要な変更は、開発者に私たちが働きたい方法を選択する際により多くの声と自由を与えることだったと思います。私たちがやったことはほとんどありません：

1. 大規模な「アジャイル」開発チームを3つの小さなチームに分割して、各チームに3〜4人の開発者のみがいるようにします。これにより、誰もが夢中になり、個人がdrれなくなります。
2. 同じチームの全員が同じ機能領域で作業していることを確認して、スタンドアップやイテレーションの計画で他の人が話していることを人々が気にするようにします。
3. 経営陣が単に誰が何に取り組んでいるのかを選択してストーリー/タスクを割り当てるのではなく、バックログを思いつき、チーム自体が仕事の分割方法について多くの意見を持ちました。
4. 私たちには多くの新しいメンバーがいたので、私たちはそれぞれの人が主要な責任領域を所有しているサイロシステムから始めました。これにより、新しい人々は未知の製品のより小さな領域に集中することができ、他の人のサンドボックスで遊んでいないというより速い感覚を得ることができました。しかし、プログラムが開始されてから6〜8か月後、境界がより灰色になるにつれて、これらの領域は変化し始めました。現在、私が所属しているチームの人たちは、他のコードに足を踏み入れたり、他の開発者を自分のチームで働かせたりするのにかなり満足しています。
5. すべての提出物のコードレビューが重要でした（そして、これが最初にスクラムを行ったときに最初に省略されたものでした）。
   • プログラミング技術/方法に関する知識の伝達
   • 他の人にとっては他の方法では見られなかったコードを学ぶことができた
   • チームはコミュニケーションと社交の機会を得て、チームのダイナミクスを向上させます
   • また、コードレビューではバグが1つまたは2つキャッチされると思いますが、主に上記の側面に価値があると思います。
6. 経営陣はチームの声に耳を傾けなければなりません。チームが何かが機能しない、または変更する必要があると言って、それを単に無視する場合、チームメンバーは単にチェックアウトし、管理者にプロジェクトを処理させます。人々にやる気を起こさせたいなら、彼らは権利を与えられる必要があり、彼らは彼らが正しいと信じていることをしている場合にのみ権利が与えられ、上から行うように言われたものではありません。

モチベーションの欠如には多くの理由がありますが、おそらく最も一般的なのはあなたが発言権を持っているように感じないことです。私たちのチームがスクラムを始めたとき、レトロスペクティブからの提案が実装されたのを見た後、スクラムについて最もやる気のない人々が振り向いたことに気付きました。

たくさんの小さな問題が重なって、やる気をなくさせます。たとえば、先週登場したものの1つは、4：00の会議が嫌いなチームメンバーです。これは簡単に修正できます。

言い換えれば、あなたのチームの動機付けとなっているものを見つける最良の方法は、彼らに尋ねることです。

コードに対する個々の所有権を与えることにより。

多くのショップは、「チームオーナーシップ」モデルに取り組んでいます。これは、相互コラボレーションとリスクの低減には優れていますが、個人が個人的な責任を負うように動機付けるのにはそれほど優れていません。チームの所有権は、個々の所有権のインセンティブがないため、平均的なコードになります。

解決策：コードの各部分を担当するようにコードの各セクションに個人を割り当てますが、チーム全体がコードベース全体にアクセスできるようにします。

参照：https : //softwareengineering.stackexchange.com/a/33464/1204