タスクを完了するために必要な時間を過小評価する傾向があるチームにどのように対処しますか？
タスクを完了するために必要な時間を過小評価する傾向があり、見積もりの精度を改善していないチームにどのように対処しますか？
詳細：私はFANG社のスクラムチーム（7人のエンジニア）で働いています。すべてのスプリントの最後に、次のスプリントのために各ユーザーストーリーに費やす必要がある時間を見積もるために投票します。次に、利用可能な容量に応じて、これらのストーリーを私たち一人一人に割り当てます。
私は1年間ここにいますが、私たちは非常に永続的な問題を抱えています。ほとんどすべての人がほとんどすべてのスプリントで計画された作業を完了できません。すべてのスプリントで大きなキャリーオーバーがあります。
私はより大きな見積もりに投票する傾向がありますが、私のチームメイトはほとんど過去の過ちから学ぶことはなく、これらの見積もりに低い票を付け続けます。
私は、週40時間仕事をしたい、冷え、燃え尽き症候群を避けたい人です。私は「過小評価と過剰配信」を信じています。チームメートの何人かがいつも長時間働いていることを知っています。私たちのスクラムマスターは、ほぼ毎日余分な時間を働いていますが、それでも彼女は常に非常に低い投票をしています。彼女はかなり前から出ているので、私たちは彼女の意見を尊重します。
彼らはそれぞれ、経営陣に印象を与えたり、他の人に準拠したりするなど、異なるインセンティブを持っている可能性がありますか？多分彼らは速い昇進を望んでいるか。私は知りませんし、気にしません。私は自分のプロジェクトを強力にリードし、会議の計画で懸念を表明することで、それに対処しようとします。しかし、チームによって推定されたユーザーストーリーに割り当てられることもあります。そして、彼らは通常、1週間でゼロから新しい小規模なプロダクションサービスを開始するなど、とんでもない期待を抱いています。それは多くの内部プロセスを持つ大企業であり、チームメイトがベアボーンサービスを開始するのに少なくとも3週間かかると私に言ったことを思い出してください。この推定が起こったとき、私は休暇中でした。
また、キャリーオーバーポイントが多すぎると、見栄えが悪くなります。
私のマネージャーは人を喜ばせるような人で、他のチームや上層部からのばかげた締め切りを受け入れる傾向があります。ありがたいことに私のマネージャーは私に耳を傾けます。
長い怒りでごめんなさい。私は実際には私のチームとマネージャーが好きなので、休暇をとりたくありません。私たちはアジャイルをすべて間違っていることを知っていますが、それらは変更されず、長時間の作業を気にしないようです。
あなたはスプリント回顧展を持っていますよね？それは質問する時です：「私達が多くを燃やさなかったとどう説明するのですか？もう一度？」あなたにはあまり意味がない言い訳があるかもしれません。注意してください。各スプリント後にこれを行います。あなたが明白であると考える説明でもはや誰も議論することができない時が来るでしょう。
どんな計画セッションでも、「今何が違うのか、今回はこの低い見積もりを満たすと私たちが信じるのはなぜですか？それとも私たちは本当にそれを自分で信じていないのですか？今回は誰を冗談だと思いますか？」あなたは本当の人気になるでしょう。
実際的な面では、他の人たちは、自分たちが対処しなければならないこと、または最も確実に対処しなければならないことを予測できないかもしれません。これらのことを指摘できるかもしれません。
次に、利用可能な容量に応じて、これらのストーリーを私たち一人一人に割り当てます
これはあまりスクラムのようではありません。チームメンバーは通常、スプリント用に選択されたセットから自分の問題を選択します。
何よりもまず、これはチームの問題であり、個人的な問題ではありません。チームは毎回信頼できなくなります。つまり、技術的にはチームとの関係ではなく、チームの一員です。それがそのように感じられないなら、おそらくそれはあなたの時間の価値がありません。
アグリー開発の「公式」の答えは、時間ではなく「ポイント」で見積もり、「速度」または最後のスプリントで達成されたポイントに基づいて予想される進捗を調整することです。
しかしながら。あまり変更する必要はありません。あなたは、最後のスプリントで達成した「推定時間」と、実際の人の時間数を比較しました。
だから、あなたはあなたがどれだけ過小評価しているかを知っています。補正するために、スプリントに含まれるタスクの時間数を減らすだけです。
ポイントアプローチは、最適な条件下では決して正確ではない見積もりを重視せずに、次のスプリントに入力したものを完了するという目標を達成するように設計されています。各タスクが実際にかかる時間を心配するのではなく。
見積もりを改善するために、1週間のスプリントもお勧めします。
これがまさにあなたが追跡する理由です 時間速度 。
時間速度は
estimated hours of completed tasks in sprint
-----------------------------------------------
actual hours spent on completed tasks in sprint
確かに、完了したストーリーポイントを追加する人もいますが、それは別の指標です。どちらも とにかく公式にはスクラムの一部 ではありません。このようにして、推定スプリントとスプリントの比較に集中できます。そうしないと、タスクに費やされない時間に気を取られてしまいます。これは一定ではありません。
時間速度は、チームが作業をどれだけうまく見積もるかの尺度です。プログラマーは悪名高く楽観的です。新しいチームが3分の1ほどオフになることも珍しくありません。つまり、彼らが見積もった値の3倍必要です。このメトリックを追跡および報告することにより、チームはその推定を調整し、時間の経過とともに改善することを学びます。これにより、スプリントの途中で削除する必要のある機能が少なくなります。
ところで、あなたのスクラムマスターが開発者でもない限り、彼女は見積もりやポイントに投票すべきではありません。
仕事を引き受けることに関しては、他の人々が推定しています...それをねじ込みます。割り当てられた作業を取得したらすぐに、独自の見積もりを出します。異なる場合は、今すぐ報告してください。何も言わずにすりおろして時間切れになったとしても駄目ではありません。スプリントよりも長くなる場合は、それを小さなタスクに分割する方法を考えてください。スプリントの最後には、常に見栄えの良いものを実行してください。
1週間のスプリントもおすすめです。しかし、それは主に雑草で失われた多くの時間を費やすことができないことを保証するためです。
この永続的な動作は、ソフトウェアが専門的基準に関して維持するのが非常に難しいことの表れでもあると考えます。一般的な感覚は、物事はより速く進むべきだということです。
スクラムポイントに関する意見の違いについて説明するなど、すべての手続き型テクニックに加えて、いくつかの問題が発生する可能性があります。
- 問題のさまざまな側面は詳細に詳しく説明されていません;またはピアが議論されました。可能であれば、より優れたピアプログラミング、設計の記述などが役立つ場合があります。
- ソフトウェアシステムには技術的負債が含まれています。リファクタリングが必要です。並列継承が多すぎると、ビジネスデータとロジックに、ビジュアルコンポーネントの処理が散在します。したがって、変更は困難になります。
- ソフトウェアシステムには技術的負債が含まれています。コードは、文書化されていないビジネス行動に関連しています。回帰エラーが発生します。次に、ビジネスコードをビジネス要件に関するドキュメントと完全に統合する必要があります。そのドキュメントは読みやすいビジネス言語である必要があり、コードはドキュメントを参照し、コード設計にコメントする必要があります。
一般に、大きなコンセンサスや組織力がなければ、既存の組織を改革することは困難です。
ただし、書面のデザイン、ピアコミュニケーション、特に技術的な詳細における過去の作業の評価など、独自の測定を追加することもできます。
状況について何をすべきかを理解する前に、なぜが起こっているのかを判断する必要があると思います。プログラマーが推定するのがひどいという問題は本当にありますか？ （それは確かにもっともらしいです。見積もりは難しいです。）または、タスクが十分に指定されていないか、不十分に指定されているという問題がありますか？それとも、絶え間ない中断や、スケジュールどおりではなく、すぐに対処する必要があるタスクなど、他の問題がありますか？
理由がわかったら、問題の内容について考えることができます。
問題の一部のように聞こえますが、チームはポイントやストーリーは個人のものであると考えています。あなたが言ったので私はそれを言う：
次に、利用可能な容量に応じて、これらのストーリーを私たち一人一人に割り当てます。
そして
キャリーオーバーポイントが多すぎると、見栄えが悪くなります。
ストーリーとポイントは個人ではなくチームに属します。
スクラムでは、yoにキャリーオーバーポイントはありませんが、teamにはあります。また、個人にストーリーを割り当てるべきではありません。少なくとも、すべてのストーリーを割り当てるべきではありません。最初に取り組むストーリーを決定しますが、完成できると確信しているストーリーのみを選択します。それらが完了したときにのみ、スプリントバックログの次のストーリーをピックアップする必要があります。
個人の貢献者という観点から考えるのをやめて、チーム全体として考えるようにしてください。ストーリーが開始されたが完了していない場合、チーム全体の責任です。個人がストーリーを完成させない危険にさらされている場合、チームの残りのメンバーは手助けをする必要があります。
基本的に、スクラムは非常に単純です。スプリントを実行し、あなたが何点ストーリーポイントを見つけ出すか完了。それが次のスプリントに引き込むポイント数です。あなたは投票する必要はありません、あなたはその数を選ぶか、より少ない数を選びます。とても簡単です。次のスプリントでは、前の2つの平均を計算し、それに応じて調整します。結局、あなたのチームは数に落ち着くでしょう、そしてあなたはいつもその多くのポイントを引き込むでしょう。