一部のチームメンバーは、スプリント計画に積極的に参加していません


15

一部のチームメンバーは、作業する可能性が最も高いストーリーが議論されるまで待ってから参加します。それ以外の場合、彼らは自分の携帯電話で遊ぶだけで、耳を傾けません。

どういうわけか私はこの立場を理解しています。Sprintでの開発に役立つとは思われない機能に関する議論を聞くのはなぜですか?

何をすべきだと思いますか?


9
このチームの大きさは?
ジェフ14

8
@JeffOは頭に釘を打ちました-これは、特大チームの古典的な問題です。特大チーム=過小な個人の権限/責任=過小な個人の関与。適切な規模のチームとは、皆さんが話し合うすべてが部​​屋の全員に影響を与えるということです。あるいは、責任を取りすぎています-役に立たないと思われる機能についての議論を聞いてください。サイロの責任を負わない適切な規模のチームには、すべての機能で作業する全員がいるはずです。
ジミーホファ14

7
例外なく、電話を切ります。簡単な会議の常識。
user1019696 14

5
@ user1019696公平に言えば、私の子供がいつでも彼の足をつぶしたという妻からの電話を受けることができました。「電話を切る」と「会議の途中で電話を使用しないでください」とは大きな違いがあります。
ジミーホッファ14

4
会社の秘書がいた時代について話すと、私が長年働いてきた会社にはそのような人はいませんでした-彼らは何の関係もないでしょう。いや、待つことはできません。特に仕事ではなく、ごめんなさい。しかし、家族>仕事です。そうは言っても、30回または40回に1回の会議(おそらく??)の途中で電話を受ける可能性がありますが、そのうち30回または40回に1回答えると思います。人々がジャークにならないように無効にしたり、人から外したりする必要がある場合、その人はただのジャークかもしれません。
ジミーホファ14

回答:


32

コードの所有権を停止します。チームの誰もが特定のタスクに取り組む可能性を平等にします。

開発者はコードの特定の領域や他の人が肩越しに見ていることに慣れるので、ほぼ確実にキックバックがあります。また、学習曲線が常に存在するため、管理者は作業に通常よりも時間がかかるという問題に直面します。

しかし、それは本当に誰にとっても最高の利益です。不可欠であることは両刃の剣です。夕方、週末、休日、休暇を取るのが難しくなり始めています。また、コードの所有権は企業にとって悪いものです。なぜなら、誰かが退職すると、知識のわずかな移転で節約した時間よりも時間がかかるからです。


4
+1絶対に。コーダーは組立ラインの別の一部にすぎないと考え、それからコグの1つを交換する必要があるためにプロジェクトが滞るのではないかと考えると、効率性に誤った印象があります。
ジェフ14

3
ほとんど私の経験ではソフトウェア開発会社の経営の中で標準である@JeffO、開発者はすぐに別の炭素単位のためにスワップアウトすることができ、機械で同一の部品であることを考えると...
jwenting

3
@jwentingを使用すると、外部委託にも完全に適しています。開発者がこの態度を支援する理由がわかりません。
GrandmasterB 14

1
@jwentingそれがアジャイルのポイントです。物事に関するこの種の見方を変えるため。
陶酔14

1
私の経験では、@ Euphoricは最終的な結果であり、マネージャーは、要件のように、その場で交換できる資産として人々をさらに見ています...
jwenting

15

適切な人を会議に招待しますか?システムをサブチームの責任分野に分割した場合、すべてのサブチームをすべての会議に招待するのはなぜですか?
たとえば、フロントエンドチームとバックエンドチームがある場合、フロントエンドチームのメンバーに対してフロントエンド作業の計画セッションを保持します。タスクがチームの境界を越える場合に、バックエンドチームの誰かをリエゾンとして招待することもできます(ただし、頻繁に発生する場合は、チーム間の責任の分割を再評価することをお勧めします)。
理想的には、誰もがすべてに取り組むべきですが、実際には、システムが本当に小さくシンプルでない限り、実際には実用的ではないことが多く、その結果、誰もがそのすべての部分を熟知しています。もちろん、実際には多くのシステムが十分に大きいため、組織のすべてのメンバーが計画されたタスクについて十分な知識を持ち、計画セッション中に有効な入力を行うことができます(システムのすべての部分で等しく生産的に作業することはできません)現実的ではありません。


12

彼らの無関心は単なる症状です。問題は、チームメンバー全員に作業を均等に分配していないことです。理想的には、すべてのチームメンバーが特定のプロジェクトエリアに限定されない新しいチケットをピックアップする必要があります。


3
理論的には素晴らしいことです。実際には、特に大規模なプロジェクトでは、システムが十分に大きくなる可能性があるため、すべてのチームメンバが作業中に生産性を高めるためにすべての部分について十分な知識を持つことは実用的ではありません。
jwenting

@jwenting-このチームは他の部分で作業する必要がないことを非常に確信しているようです。一人がすべてを知ることはできませんが、それは彼らが可能な限り少なく学ぶべきであることを意味しません。
ジェフ14

@JeffOは本当ですが、彼らは知識のない分野の計画に積極的に参加することは期待できません。聞いて学びますが、口を閉じてください。そして、多分あなたの携帯電話を使って計画委員会の写真を撮ってください:)
14

1
@jwentingの大規模プロジェクトでは、より多くの作業を分散する必要があります!すべての人が同じ知識を持っているわけではありませんが、特定の分野で働く可能性は等しくあります。言い訳を許可すると、チームメンバーは新しい領域を採用しない可能性が高くなります。
デイブヒリアー14

5

動機付けの問題のように聞こえます-なぜ一部の人々は彼らが取り組んでいるプロジェクトを気にしないのですか?チームが「主催者」と「除外」に分かれているためかもしれません。

したがって、計画セッションを担当する1人または2人ではなく、すべての人を関与させます。すべての人を関与させます-各セッションを別の人に、好ましくはセッション中に別の人を担当させます。周りを回転させます。誰もが大騒ぎしたり、整理したい人が常にいるので、これは難しいように思えますが、彼らはここで問題になっています。

アイデアは次のとおりです。計画するときは、各ストーリーを担当する人をランダムに選択します。無作為に。計画の責任者も記録するので、次のスプリントでは、見積もりとタスク分割のコンセンサスが得られたかどうかを確認できます。それは彼らに注意を払わせ、プロジェクトに携わる理由を与えるでしょう。

問題はそれらではなく、あなた自身とあなたの計画セッションが行われる方法ではないことを忘れないでください。だから誰かがストーリープランを引き継ぐとき、彼らはそれをどのように進めるかを選択するようになります。そこには公式の進行方法があるはずです。(つまり、プロキシを使用して組織にそれらを強制し続けないでください)


良いアイデア。うまくいけば、人々はこれを時間の無駄だとは思わないでしょう。
ユージン14

1

スプリントの継続時間は?

スプリントの継続時間が長くなると

  • スプリントで計画するより多くの作業
  • より長い計画会議
  • チームメンバーが集中力を保つのが難しい
  • チームメンバーは退屈する

したがって、スプリント期間が2週間を超える場合は、短いスプリントで作業してみてください。

利害関係者に短いスプリントを約束させるのが難しい場合は、正式な会議の一部をスキップすることができます。たとえば、スプリントごとではなく、2スプリントごとにスプリントレビューのみを行います。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.