スクラムスプリントは、可能な限り速いペースで機能することを意味しますか？
私は最近、より正確にアジャイル、スクラムを行ういくつかの企業にインタビューしましたが、私にはアジャイルのように思えないものがあります。今私が特に興味を持っているのは、スクラムスプリントの場合です。
私が話し合った特定のプロジェクトマネージャー（そう、私はプロジェクトマネージャーと言いました）は、彼女のチームの人々は、勤務時間が終わったときに家に帰らないことを理解している（ "伝えられた"は私がコンテキストからピックアップしたものです）と誇らしげに述べました、仕事が終わったら、いくらかかっても家に帰ります。行間で読んだのは、できるだけ多くの機能をスプリントにパックし、それを実現するために残業することです。
今、私は今までアジャイルを行っていません（ほとんどの場合滝を好む金融機関や政府機関で働いていました）が、私の理解は次のとおりです。
- スクラムのスプリントは、アジャイルの一般的なイテレーションの名前です。
- チームは持続可能なペースで作業し、長時間の残業を回避するよう努める必要があります。これは短時間にのみ影響を及ぼし、その影響は、長時間に渡って発生する問題によって小さくなります。
私の発言は正しいですか？そして、私はマネージャーのプレゼンテーションを危険信号として扱うべきですか？
これらのプラクティスがアジャイルの背後にある原則に反していることを確認するために、遠くを探す必要はありません。アジャイル宣言の背後にある 原則 の1つは次のように述べています。
アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、無制限に一定のペースを維持できる必要があります。
数年前、スクラムは微妙ですが重要な change を作成しました。チームの代わりにcommitting達成可能な作業にforecast彼らが達成できると思うこと。
変更は虐待が原因で発生します。虐待は、あなたが説明するまで、家に帰らないでくださいという態度とよく似ています。開発では、チームが制御できない、コミットできない要因がたくさんあります。天気の例えを使うと、明日は雨になると「約束」することはできません。
質問に直接回答するには：
- はい、スプリントはスクラムのイテレーションの名前です。違いはこちら answer を参照してください
- はい、チームは持続可能なペースで作業する必要があります。残業の唯一の確実性は、それがwillチームの生産性を長期的に低下させることです。
- はい、それは赤い旗です！
はい、そうです、そしてあなたが言われたことを私に言われたら、私はそこからできるだけ早く逃げるでしょう。彼らは単に言い訳としてアジャイルを使用しています。古典的な死の行進のように聞こえます。
これを許容できるようにする重要な点が1つあります。それは、チームがスプリントの範囲を受け入れることです。
スクラムでは、チームは仕事を割り当てられるだけではありません。製品所有者はチームと交渉して、製品作業と技術（負債）作業の優先順位を決定します。次に、プロジェクトマネージャー、製品の所有者、およびチームは、スプリントに引き込まれるものとその作業の範囲について交渉を行います。
この世界では、チームは本質的に「Xの作業を完了させ、テストし、このイテレーションを出荷できる」と言っています。したがって、私はチームがこれらのコミットメントを満たすために時々残業することを期待します。
とは言っても、アジャイルを無茶苦茶にする場所はたくさんあります-そして、チームのリーダーが少数であり、通常は彼らのボスである人々と効果的に交渉することができます。
スクラムはスプリントに分割され、そのスプリントの期間（通常は2週間ですが、1日から4週間の範囲で見られます）で完了する一連のタスクを推定します。これはタスクを誤解するインセンティブを生み出すと思います。 PO（製品所有者）は、スプリントごとに大きなコミットメントを得るために低い見積もりを求めます。チームは、PMが確認できるニースバーンダウンチャートを生成するために大きな見積もりを出します。もちろん、これらは安っぽい組織を示しています。あなたは本当に正確な見積もりを取得し、足りずにストーリーを次のスプリントに持ち越したり、早期に終了して追加のタスクをバックログから取り除いたりすることを恐れないでください。 「スプリント」という言葉は、より速く働く人々のイメージを生み出すと思います。
いいえ：スクラムスプリントはタイムボックスであり、それ以上でもそれ以下でもありません。スプリント/反復の開始時に、teamは、以前のパフォーマンス、可用性、予定されているイベント、未解決の障害などに基づいて、彼らが達成できると信じているストーリーポイントの推定量を示します。次に、どのユーザーストーリーがスプリントに組み込まれるかについて、製品の所有者と交渉します。それは（またはそうでしたか？他の回答を参照してください）commitmentチームが製品所有者に提供します。
開発中に、物事が本当に予測どおりではなく（結局、ソフトウェア開発である）ことが判明し、チームがコミットメントを満たさないリスクがある場合、1つ以上のストーリーがリスクを伴うことを製品所有者に通知します完了していません。
そして、それは結構です。確かに、スプリントの最後にスプリントが失敗したことを認めなければならないのは気分が悪いですが、敗北ではなく、改善の機会です。スプリントの最後/新しいスプリントの開始時にスプリントを振り返ることができ、誰もが最初に尋ねるのは、「なぜこのスプリントに失敗したのか、そして再び失敗しないようにするために何をする必要があるのか」です。 ？ '。 1つのオプションは、コミットメントを減らすことです（=ストーリーポイントを少なくする）。
tl; dr：持続可能なペース。スクラムとはケイデンスのことであり、チームがスプリントごとに無期限に継続できるものです。残業はしません。チームは過労になり、仕事はずさんになり、メンバーは病気にかかったり、完全にやめたりして、失敗したスプリントよりも大きな問題を抱えることになります。
アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、無制限に一定のペースを維持できる必要があります。
いつも残業することは、私にとって持続可能なことには思えません。
とは言っても、春のコミットメントが強力なものであることに問題はないと思います（それがチームが働きたい方法である場合）。見積もりをオーバーコミットまたは台無しにしたときに残業しなければならないことは、見積もりまたはコミュニケーションを向上させるための良いインセンティブですPOへの期待。
私が話し合った特定のプロジェクトマネージャー（そう、私はプロジェクトマネージャーと言いました）は、彼女のチームの人々は、勤務時間が終わったときに家に帰らないことを理解している（ "伝えられた"は私がコンテキストからピックアップしたものです）と誇らしげに述べました、仕事が終わったら、いくらかかっても家に帰ります。行間で読んだのは、できるだけ多くの機能をスプリントにパックし、それを実現するために残業することです。
それはスクラムではありません。タイムボックスに提案されるワークロードはチームの速度に基づくであり、マネージャーのウィッシュリストにはありません。彼らは単にあなたをだまして無限の残業をすることは「アジャイル」であると信じ込ませようとしていますが、そうではありません。チームは邪魔されずに集中して作業している間、より効率的になりますが、スクラムはendless効率向上のための魔法の杖ではありません。
マネージャがアジャイルを少し誤解している、または（可能性が高い）開発者は愚かだと彼は考えています。一方で、チームが何度も何度もスプリントを受け入れると、残業が必要になることを知って、多分彼らは本当に愚かであり、それに値するものではないでしょうか？
たぶん、あなたは答えを知っています... ;-)