見積もりよりもスクラムタスク
私の現在の会社では、2週間の反復と定期的な計画セッションでスクラムを使用しています。私たちの会社で通常計画が機能する方法は、ユーザーストーリー/ PBIの事前定義された（計画の前にPOによって）製品バックログを取り、PBIを上から1つずつ取り出し、タスクに分解して時間単位で見積もることです（ポーカープランニングとフィボナッチを使用して）特定のチームのキャパシティに到達するまで。
これはほとんどのチームで機能しますが、私がSMである2人のチームが1つあり、体系的にタスクをはるかに過大評価する傾向があります（これらの開発者はこのプロジェクトで1時間支払われ、記録から別のプロジェクトで彼らと一緒に仕事をすることで、私は彼らがはるかに良い速度を持っているという事実を知っています。開発者としてこのチームの一員ではなく、スクラムを遵守しようとしています。これらの見積もりに影響を与えることは絶対に避けていますが、プロジェクトの期限に近づくにつれて、この状況はますます厄介なものになっています。
私の質問は-そのような状況でチームを速度のエッジに保ち、彼らの推定に影響を与えない方法または良い方法はありますか、あるいは私たちはプロセスで間違っているのでしょうか？
過大評価の罪はおそらく過小評価の罪よりも深刻ではありません。なぜなら、チームは少なくともその責任を果たしており、コミットメントが失われたときに発生する可能性のある混乱に貢献していないからです（特に、他の人が自分の仕事のためにチームの出力に依存している場合）。多くの場合）。
彼らが過大評価/過小評価していることをどのようにして知っていますか？彼らはロビーのスターバックスで何時間も過ごしていますか？それとも、スプリントごとの出力の範囲と複雑さに対する理解に基づいて、単に「感知」するものですか？後者の場合、個人はおそらく技術的債務の排除（またはより良いのは予防）においてより徹底的でしょうか？彼らは他のチームよりも優れたテストカバレッジを持っていますか？彼らのソフトウェアはよりよく設計されていますか？必要に応じてリファクタリングしますか？
私はすべての「遅い」チームの防衛のために立っているわけではありません-私はいくつかを管理しました。演技の前に知っておくべきことは、なぜ彼らが遅いのか、そして生産される仕事の質を犠牲にすることなく、速度を上げるために合理的に取ることができるステップです。
私はスプリントが常に完了するすべてのチームに質問します。これは本当に目標ではありません。それはいくつかを逃すことを意味する場合でも、自分をプッシュするのは大丈夫です。いつでも調整できます。彼らがプロジェクトの終わりに向かって時間通りにすべてを達成できれば、おそらくそれを理解したでしょう。
開発者は次の理由で過小評価します。
- すべてを完了させないことには深刻な影響があります。
- 彼らはプロジェクトがより長く続くことを望んでいる、より少ない仕事をする、など。
- 彼らは全体の計画に巻き込まれており、完璧でなければならないと思います。たぶん彼らは全部を真剣にあるいは文字通りに受け止めすぎているのかもしれません。
まだまだあると思います。
チームがどのように自分自身を管理するかに関係なく、実行するビジネスはまだあるので、どれだけの作業が行われるかが予想されます。クライアントは期待を持っています。人々は最終的に給料を受け取りたいと思っています。法案を支払う誰かがプロジェクトを見て、それが妥当な時間内に完了するかどうかを判断する必要があります。そうでない場合は、要件を調整するか、チームを調整します。
ビルドにかかる時間について何か知っている人（これを発見したようです）は、チームに対処する必要があります。おそらく、会社のリーダーだと思います。ここでジェフシュルトの答えが出てきます。なぜ彼らがこれ以上試みないのかを特定できますか？それは計画の仕方を知っているか、スプリントを終わらせないか、あまり熟練していないか、ただのんびりするかについて心配しすぎていますか？スクラムの一部として、1日や1つのスプリントを見ることはありません。いくつかを見て、傾向に注意してください。
たぶん、時間給の人々は別れる必要があるのですか？より完成度の高いチームに所属することで、チームを前進させることができます。
@JeffOもう1つ、詳しく説明します。
論文1
これらの2人のプログラマーは正しく見積もっていますが、知識は不完全です（私もそうです）。
これは2人のプログラマーチームで、2人のプログラマーです
- 他のチームから非常に切り離されています。
- 見積もりが難しい多くの外国の仕事に彼らの仕事を基づいています
彼らは2人しかいないので、大きなチームと通信しないように強制することができます。
- 彼らは彼らの所有者にもっと多くを持っている（50％）ので、彼らはどこかに行ってチャットすることはできない
- 彼らはより完全なフィニッシャー（ベルビン）であり、非常にタスク指向であり、問題解決のためでなければ、他のチームと交換する必要がないと考えている場合は、あまりにも接続的ではありません。単独でも非常に効果的で効率的です。
解決：
- 彼らは職場を変えて、もっとコミュニケーションをとるべきチームの大使として働きます。
- 両方ともそのアイデアが好きではなく、非常に完全主義的である場合、そのような変更を嫌う場合、おそらくあなたがそれらに渡す間違ったタスクですか？たぶん、ユーザーストーリーで発生する、これらの不完全なハッキングなどのタスクに本当に苦しんでいるのでしょう。たぶん、別の品質のコードを持つユーザーストーリーの方がいいですか？
論文2
タスクを反映していないか、タスクのセットにあまり共通点がありません。
論文
通信に問題があります。 （人々は常に持っています）。プログラマーと話をする前に、programmers.stackexchangeに目を向けると、指標になる可能性があります。 （私は知らない）
論文4
彼らはなぜ過大評価するのですか？ストーリーポイントは時間単位ではありません。つまり、過大評価するために毎回ストーリーポイントを増やす必要があります。前のイテレーションからストーリーポイントを時間にマッピングし、これを時間計算の基礎として使用できます。
xxxこれは推測に過ぎませんが、私はそれを書くのを楽しんでいました。
方法論が何であれ、参加者がやる気がない場合、製品は失敗します。
スクラムマスターとして、あなたはチームの一員です。良いニュースは、少なくとも1人のやる気のあるチームメンバーになることです:)
「なぜwe失敗するのか？」と尋ねる必要があります。「they "。
それを行うのに最適な時期は、振り返り中です。チームの速度がXスプリントよりも改善されていないという点を挙げて、「どうすれば改善できるでしょうか？」と尋ねます。あなたが直面している障害を分析します。あなたがスクラムマスターとしてそれらの一部を削除するためにできることを提案し、開発者に彼らが最後に何ができると思うかを尋ねます。
特に障害はなく、インセンティブもない場合は、各スプリントに刺激としてボーナスストーリーを追加するなどの課題を提案するか、予期しない小さな機能で顧客を喜ばせるようにしてください。
言うことは言うより簡単に思えるかもしれませんが、それを怠慢、罪悪感、非難、または管理の圧力の問題にしないでください。アジャイルチームが調査し、適応し、改善し、自身に課題を設定し、徐々に複雑な目標を設定し、それを行うことに楽しみと誇りを持っていることについて説明します。
編集：また、ここに一人ではないことも覚えておいてください。プロダクトオーナーは、チームを前進させるための最良の味方です。
デモ中に小さな "アイシングオンケーキ"機能やUIの仕掛けを常に期待していたPOを喜ばせない人を思い出し、パフォーマンスが不十分だと思ったらチームにかなり率直に知らせました。結局、私たちは驚きと彼女を喜ばせることができるものについて自動的に考え始め、スプリント中に製品に追加して、レビューがうまくいくようにしました。その結果、チームのモチベーションと同様に、認識される製品品質が大幅に向上しました。
特に、専門家ではないようにしたくない公開会議中に承認が行われる場合、顧客満足度は強力なインセンティブになります。
私はスクラムを練習している初心者です。このトピックについて私の考えを共有したいと思います。私が理解しているように、エフォートの見積もりは、ポーカーやフィボナッチシリーズの計画、またはその両方を組み合わせた全体的なチームアクティビティです。私は通常、最小および最大のエフォート見積もりの見積もりについて簡単な説明を得て計画ポーカーを再生することにより、エフォートを収束しようとし、最後にベータ分布を適用します（つまり、オプティミスティック+ 4 *モストライキー+ペシミスティックエフォートを6で割ったもの）。これにより、1人または少数の個人の影響を受けない努力の見積もりが維持されます。
したがって、私が提案するのは、これらの2人の男性を別のスクラムチームに参加させて、知識の共有とより良い努力の見積もりを可能にすることです。もう1つの方法は、POまたはSMEもスプリント計画中に努力の見積もりを提供し、個々の見積もりの動機/理由を議論する努力を収束させることです。
スクラムマスターはチームの一部であり、質問する権利があります。なぜそのように見積もったのですか？
やる気がなくても熟練したチームは、時間の経過とともに滑り始めます。人工速度以外の指標を探して議論することは、この問題を明らかにするのに役立ちます。
彼らのコードカバレッジはずれていますか？どうして？自動テストは頻繁に失敗しますか？ビルドはしばしば壊れていますか？欠陥荷重は管理されていますか？欠陥文書の品質はどのくらいですか？機能はイテレーション内で継続的に提供されていますか？ チームメンバーは、目標を設定し、遡及中に改善を提案し続けていますか？
彼らが仕事をして時間を見積もり、ストーリーを見積もる場合、彼らの努力の見積もりについて話し合うことも役立ちます。何日も続くスパイク/調査タスクを探し、それらがこれらのタスクの必要性と期間をどのように決定したかを理解するように依頼します。
最後に、同じようなサイズのストーリーを完成させるのにかかる時間のバリエーションを確認します。ストーリーポイントの見積もりを管理しているチームは、通常、ストーリーの完了にかかる時間に大きなばらつきがあります。 3日間のスプリントの最後に突然ピックアップして終了するまでに5〜10日かかると考えていた8ポイントのストーリーでしたか？彼らがどのようにしてこのような成功を収め、ギリギリの勝利を手に入れたのかを尋ねても問題はありません。