スクラムチームでオーバータイムを停止/回避する方法は？

実際、私は彼らのスクラムの実装に関する小さなソフトウェアショップを手伝っています。最近、スクラムマスターから、チームがスコープ（コミットバックログ）を達成するために時間をかけて作業しているため、問題があると報告されました。そのため、Unreal Velocityがあります。

私の正式な質問は/です：

1. レトロスペクティブ会議について話すこととは別に、オーバータイムを避けるためにいくつかのハードブロックを実装するのは良い考えだと思いますか？

2. もしそうなら、どのようなテクニック/ツールを提案しますか？

   • リビジョン管理システム（SVN、GIT、HGなど）、時間単位（8〜5）のブロック
   • ワークステーションは、時間単位（8〜5）または累積時間（最大8時間/日）でブロックしますか？
   • その他...

3. または、多分、この種のものをハードブロックしないでください。しかし、不当な余分な時間に「ペナルティシステム」を実装しますか？

@Baqueta（および同様の質問を持つ他の人）：いいえ、彼らは余分な時間に対して支払われていません。彼らへの私の最初のアドバイスは、おそらく彼らが過小評価していたので、彼らの見積もりをレビューすることでした。これは私のお気に入りのアドバイスでした：

残業に興味がある場合は削除してください。開発は週に60時間行うことができ、生産性を維持できるものではありません。これを証明する多くの研究があります。残業代が問題になる場合は、それを取り除き、基本給を改善して、彼らが価値のあるものを手に入れるようにします。

また、（このチームの）根本的な問題は、次の組み合わせであると思います。

1. 開発者は、スプリントで何を達成しなければならないかを伝えられている/達成可能なことについて相談されていない/作業が多すぎると言われたときに無視されている。
2. 開発者は、タスクにかかる時間/各タスクに含まれる作業単位の数を常に過小評価しています。

要約：チームと話し合い、見積もりを確認します。POについても、あなたが述べたように、範囲について相談されていないように感じます。

率直に言って、＃2で言及した「ハードブロック」は、私が長年聞いた中で最悪のアイデアです。最優先のバグが午後4時45分に発見され、ブロックを無効にする能力を持つ人が病気になった場合はどうなりますか？＃3-あなたは自分の仕事をしたことに対して人々を罰することを提案しています。

チームがスプリントを完了するために継続的に残業している場合、彼らは残業に興味があります-例えば、残業手当や休日としての残業の取得-彼らはスプリントであまりにも多くの仕事をすることにコミットしています。

残業に興味がある場合は削除します。開発は週に60時間行うことができ、生産性を維持できるものではありません。これを証明する多くの研究があります。残業代が問題になる場合は、それを取り除き、基本給を改善して、彼らが価値のあるものを手に入れるようにします。

スプリントに入る作業が多すぎる場合、これは通常3つの理由のいずれかです。

1. 開発者は、スプリントで何を達成しなければならないかを伝えられている/達成可能なことについて相談されていない/作業が多すぎると言われたときに無視されている。
2. 開発者は、タスクにかかる時間/各タスクに含まれる作業単位の数を常に過小評価しています。
3. 開発者は、スクラムの一部ではないタスクに引き寄せられ続けます。

＃1の場合は、間違っています。それについて2つの方法はありません！

＃2の場合、通常の原因は経験不足です。時間の見積もりを行っているか、開発中のシステムのいずれかです。これを回避する良い方法は、時間の見積もりをやめて「作業単位」の見積もりを開始することです。抽象単位を使用し、それがリアルタイムの時間ではないことを確認してください（最終的にはまだ時間間隔を表しているが、抽象は重要です！）。その後、1週間に実際に何作業単位が完了するかを計算し、そのデータを使用してスプリントを設定できます。

＃3の場合は、何らかの方法で他のタスクを考慮に入れる必要があります。一貫性がある場合は、簡単に説明できるはずです（上記の＃2を参照）。頻繁であるが予測できない場合は、対処するのがはるかに難しくなります。なぜそれが起こっているのかを見てみたいと思うでしょう（たとえば、「ライブ」コードの深刻なバグ=>テストは十分に徹底されていますか？）、それを修正できない場合、最終的にスクラムは適切なアプローチではないかもしれません。私のチームはこのまさに理由で最近カンバンに切り替えました...

編集：質問で提示されたアイデアに対する私の批判を明確にしました。

まず第一に、彼らがそれを成し遂げるために残業しなければならない場合、彼らはスプリントで多くの仕事を得たように聞こえます。すべての時間が記録されていますか？その場合、実際の作業がストーリーポイントであるかをカウントし、その数値を使用して次のスプリントの作業を計算できます。

また、チームが多くの仕事をすることによって自分自身を傷つけているだけであることを理解することも重要です。アジャイルマニフェストでさえ、持続可能なペースについて語っています：「アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、ユーザーは、一定のペースを無期限に維持できるはずです。」常に残業することは持続可能ではありません。

全体として、力と罰の代わりにコミュニケーションをお勧めします。それはチームの士気低下につながるだけだと思います。

残業中の開発者は、実際のまたは知覚されたインセンティブに反応している可能性があります。これは、実際のインセンティブを削除するか、認識されたインセンティブが機能していないことを通知することです。

推奨されるハード制限には、いくつかの回避策または他の問題があります。ソース管理ブロックは、ウィンドウが再び開くまで、開発者がコミットを保持するようにするだけです。ワークステーションブロックは、何らかのサポート上の問題があるか、開発者の1人が何らかの理由で勤務時間を変更する必要があるとすぐに行かなければなりません。ペナルティシステムは、残業時間を隠したり埋めたりするだけです。

問題はより根本的なものだと思います-チームには残業するインセンティブがあります（またはインセンティブがあると信じています）。

これに対処する必要があります。彼らのパフォーマンス評価は彼らのベロシティ数に結びついていますか？管理は残業しますか？長時間働いている人に昇進や賞は与えられますか？彼らは残業代を支払われている請負業者ですか？

チームに残業しないように伝えてください。限目。

これにより、一部の作業を完了できなくなる場合があります。それは問題ではなく、データポイントです。その後、そのデータポイントを使用して次のスプリントを計画できます。繰り返しますが、彼らに残業をさせないでください。終了するかどうかに関係なく、別のデータポイントがあります。泡立て、すすぎ、繰り返します。

トリックや制限の量は必要ありません。ただ残業しないでください。達成できる作業量を学習し、それに応じてスプリント計画を調整します。

たぶん、彼らがどれだけ「多く」働いているかではなく、いつかという問題があります。これは、予定された勤務日がある場合に問題になる可能性がありますが、通常の時間の多くは会議やその他の社会的および個人的な気晴らしで構成されています。彼らは生産性を高めていると感じているため、時間外に働いていますか

スプリントの作業量を削減し、フレックスタイムで作業を開始します。それらが後で入ることを許可します。担当者は、家に帰るように人々に伝える必要があります。大丈夫。早退することで眉をひそめる環境を作り出す企業文化がいくつかあります。

最初にスクラムに切り替えたとき、これに苦労しました。締め切り近くに余分な労力を費やすのは自然なことですが、スクラムには2週間ごとに締め切りがあるため、調整です。反復ごとにコミットされたストーリーポイントを削減するために他の人が行った提案に加えて、各開発者が反復で少なくとも2つまたは3つ終了できるように、ストーリーを十分に分解することもお勧めします。

これにより、各開発者が各反復で何かを達成したように感じられるだけでなく、スコープに余裕が生まれます。バーンダウンでストーリーを完成できないことが示されたら、それを引き出して、完成できるストーリーに人々を再配置できます。範囲を調整できると人々が思うとき、彼らは非現実的な期限について強調する可能性が低くなります。進行中のすべてのストーリーで反復を開始する場合、調整の余地はありません。

反復ごとに全員が2つのストーリーを終えている場合、理想的な累積フローチャートは次のようになります。

現実には、すべてのストーリーを最終日に終わらせるのは非常に難しいので、誰もが忙しくしているので、そのようには見えませんが、それは良い経験則です。オーバーコミットすると、赤い領域が大きくなり、ストーリーを削除できます。コミットされていない場合、青い領域が大きくなり、ストーリーを追加できます。ストーリーが大きすぎる場合、緑の領域が大きくなり、ストーリーを分割する必要があります。

残業を避けるために、プロジェクトの範囲を削減する必要があります。

次のグラフは、プロジェクトのどこに不確実性があるかを示しています。

製品の定義と要件の段階で気付くと、労力の見積もりに大きなばらつきがあります。この機能の実装に1か月かかるか1日かかるかはわかりません。

単純に大きすぎて不特定であり、あまりにも多くのタスクがあるため、どのタスクも完了していないことに賭けています。

チームが5日間で10枚のチケットを処理でき、20枚のチケットが割り当てられている場合、その数を減らし、製品所有者/プロジェクトマネージャー/マネージャー/クライアントにキックアップして、優先順位を付けるよう伝えます。

この時点で、それがチームを残業から救う唯一の方法です。すべてを配信することはできませんが、配信するものにバグが含まれる可能性は低くなります。

また、新しい仕事を探して、チームメイトが同じことをして、履歴書とプロのポートフォリオを修正するのを助けることもお勧めします。残業を期待している会社は誰も働かないはずであり、生産されるソフトウェアは地獄のようにバグが多いでしょう。

「ハードブロック」に強くお勧めします。そのようなコントロールは、ミクロ管理として認識される可能性があり、根本的な問題に対処できない場合があります。

プログラマーが残業している理由を見つけることをお勧めします。答えはあなたを驚かせるかもしれません。あなたは「アウトサイダー」（会社の従業員ではない）のように聞こえます。プログラマーは、個人的に（1対1で）会うなら、あなたと率直になることをいとわないかもしれません。

残業する理由は本当に仕事量なのでしょうか、それとも文化や期待にもっと関係があるのでしょうか？

ワークロードの理由は

• コミットされたバックログが大きすぎます
• プログラマーまたは製品所有者のいずれかが「金メッキ」です（必要以上に機能を複雑にします）

期待は

• 残業のための何らかの金銭的または表彰
• 失敗の恐怖。プログラマーは、期限を守らないと見た目が悪くなったり、罰せられたりすることを恐れています
• プログラマーは、残業の有害な長期的影響を過小評価しています。