スクラムスプリントは、可能な限り速いペースで機能するということですか？

私は最近、より正確にアジャイル、スクラムを行ういくつかの企業にインタビューしましたが、私にはアジャイルとは思えないものがいくつかあります。私が特に興味を持っているのは、スクラムスプリントのケースです。

私が話した特定のプロジェクトマネージャー（はい、私はプロジェクトマネージャーと言いました）は、彼女のチームの人々が、勤務時間を過ぎても家に帰らないことを理解していることを誇らしげに述べました、仕事がどれだけかかっても家に帰ります。行間で読んだことは、できる限り多くの機能をスプリントにまとめ、それを実現するために残業することです。

今、私は今までにアジャイルをやっていません（ほとんどの場合、ウォーターフォールを好む金融機関や政府機関と協力しました）が、私の理解は次のとおりです：

• スクラムのスプリントは、アジャイルの一般的な反復の名前です。
• チームは持続可能なペースで作業し、長期的な残業を避けるように努める必要があります。これは、短時間にしか影響を与えず、その影響は長期間に発生する問題によってd小化されるためです。

私の声明は正しいですか？そして、マネージャーのプレゼンテーションを危険信号とみなすべきですか？

これらのプラクティスがアジャイルの背後にある原則に反することを確認するために、遠くを検索する必要はありません。アジャイル宣言の背後にある原則の 1つ：

アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。

数年前、スクラムは微妙ではあるが重要な変更を行いました。チームは達成できる作業にコミットする代わりに、自分たちが成し遂げられると思うことを予測します。

この変化は虐待が原因で発生します。これは、あなたが説明する「やるな」という態度によく似ています。開発では、チームが制御できない多くの要因があり、コミットすることはできません。天気のアナロジーを使用すると、明日雨になることを「コミット」できません。

質問に直接回答するには：

• はい、スプリントはスクラムの反復の名前です。違いについてはこの回答を参照してください
• はい、チームは持続可能なペースで作業する必要があります。残業の唯一の確実性は、チームの生産性を長期的に低下させることです。
• はい、それは赤い旗です！

はい、あなたは正しいです、そしてあなたが言われたことを言われたら、私はそこからできるだけ早く逃げるでしょう。彼らは言い訳としてアジャイルを使用しています。古典的な死の行進のようですね。

これを受け入れられる可能性がある重要な点が1つあります。チームはスプリントの範囲を受け入れます。

スクラムでは、チームは割り当てられた作業を取得するだけではありません。製品所有者はチームと交渉して、製品作業と技術（債務）作業の優先順位を決定します。次に、プロジェクトマネージャー、製品所有者、およびチームは、スプリントに引き込まれるものとその作業の範囲について交渉します。

この世界では、チームは基本的に「この作業をXで完了させ、テストし、出荷できる」と言っています。したがって、これらのコミットメントを満たすためにチームが時折残業することを期待します。

そうは言っても、非常に多くの場所がアジャイルを卑劣にします-そして、ほとんどのチームリーダーは通常上司である人々と効果的に交渉することができません...私はこれを巨大な赤い旗と考えます。

スクラムはスプリントに分割され、そのスプリントの期間（通常は2週間ですが、私は1日から4週間まで見たことがあります）に完了するタスクのセットを推定します。これは、タスクを誤解するインセンティブを生み出すと思います。PO（製品所有者）は、スプリントごとに大きなコミットメントを得るために、低い見積もりを求めます。チームは、PMが確認できる優れたバーンダウンチャートを生成するために大きな見積もりを出します。もちろん、これらは安っぽい組織を示しています。正確な見積もりを取得し、不足して次のスプリントにストーリーを引き継ぐことや、早期に完了して余分なタスクをバックログから引き出すことを恐れないでください。「スプリント」という言葉は、人々がより速く働くというイメージを作り出すと思います。

いいえ：スクラムスプリントはタイムボックスであり、それ以上でもそれ以下でもありません。スプリント/イテレーションの開始時に、チームは、以前のパフォーマンス、可用性、今後のイベント、未解決の障害などに基づいて、達成できると考えるストーリーポイントの量の推定値を提供します。その後、プロダクトオーナーと交渉しますどのユーザーストーリーがスプリントに入れられるかについて。それは（または他の回答を参照してください）チームが製品所有者に与えるコミットメントです。

開発中に、物事が実際に予測どおりではないことが判明し（結局ソフトウェア開発である場合）、チームがコミットメントを満たさないリスクがある場合、製品所有者に1つ以上のストーリーがリスクをもたらすことを通知します完了していません。

そしてそれは大丈夫です。確かに、それは気分が悪く、スプリントの最後にスプリントが失敗したことを認めなければならないが、それは敗北ではなく、改善の機会です。スプリントの終わり/新しいスプリントの開始時に、スプリントの回顧展を行うことができ、誰もが最初に尋ねるのは「なぜこのスプリントに失敗したのか、そして再び失敗しないために何をする必要があるのか​​」 ？ '。1つの選択肢は、コミットメントを少なくすることです（=ストーリーポイントを少なくします）。

tl; dr：持続可能なペース。スクラムはケイデンスに関するもので、チームはスプリントごとに無期限に続けることができます。残業はそうではありません。チームが過労になり、仕事がずさんになり、メンバーが病気になったり、完全に辞めたりすると、失敗したスプリントよりも大きな問題が発生します。

アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。

アジャイルマニフェストの人々から

いつも残業をしているのは、私にとって持続可能とは思えません。

とはいえ、春のコミットメントが強力なものであることに問題はないと思います（それがチームの働き方である場合）。見積もりをオーバーコミットまたは台無しにするときに残業しなければならないことは、見積もりやコミュニケーションを改善するための良いインセンティブですPOへの期待。

私が話した特定のプロジェクトマネージャー（はい、私はプロジェクトマネージャーと言いました）は、彼女のチームの人々が、勤務時間を過ぎても家に帰らないことを理解していることを誇らしげに述べました、仕事がどれだけかかっても家に帰ります。行間で読んだことは、できる限り多くの機能をスプリントにまとめ、それを実現するために残業することです。

それはスクラムではありません。タイムボックスに提案されるワークロードは、マネージャーのウィッシュリストではなく、チームの速度に基づいています。彼らは単にあなたをだまして、果てしない残業は「アジャイル」であると信じさせようとしているが、そうではない。チームは邪魔されずに集中して作業する間、より効率的になりますが、スクラムは無限の効率向上のための魔法の杖ではありません。

マネージャーがアジャイルについて若干の誤解を持っているか、（おそらく）開発者はその愚か者だと考えています。一方、チームが残業をする必要があることを知って、チームがスプリントを何度も受け入れた場合、彼らは本当に愚かであり、それ以上に値しないでしょうか？

私はあなたが答えを知っていると思う... ;-)