私のプロジェクトマネージャーはスクラムのキャリーオーバーを受け入れません-それは正常ですか？
私はAndroidおよび大きなバックエンドコンポーネントを備えたiOS向けの新しいモバイルアプリを開発しています。このプロジェクトの3つのスプリントに参加しており、すべての式典でスクラムを使用しています（詳細、計画、日刊紙、回顧展など）。
スプリントのうちの2つでは、チームは時間外と週末に（無給で）働かなければなりませんでした。経営陣はスプリントのコミットメントを時間どおりに完了できないと非常に心配していたからです。全員が懸命に働きましたが、いくつかの外部依存関係と楽観的な見積もりにより、すべてのスプリントストーリーを達成するのに苦労しました。
私の経験では、一部のスプリント中に完了しなかったストーリーのパーセンテージがいくらか正常であることはある程度正常であり、それらは次のストーリーで取り組むことができます。しかし、私たちのプロジェクトマネージャーは、私たち自身が見積もりを行ったのは私たちのせいだと言っているので、スプリントのすべての項目を完了する必要があります。
これは私が知らないスクラムの許容可能な/一般的なバリエーションですか？
私はこれに基づいて行動すべきだとどのように提案しますか？
いくつかのことが私には際立っています。
チームが一連の作業に取り組むという経営陣の考えは、スクラムガイドの最新バージョンと一致していません。 「コミット」または「コミットメント」という言葉は、スクラムガイドの最新（2017年11月）バージョンで2回のみ使用されます。 」.
目標の考え方はスクラムにとって重要です。組織やチームには幅広い目標があるだけでなく、スクラムでは、各スプリントにはプロダクトオーナーと開発チーム間のコラボレーションとしてスプリント計画で定義されたスプリント目標があります。スプリントの目標は、プロダクトバックログの項目を実装することで達成されますが、単に「この一連の作業を完了する」だけではなく、完全なスプリントバックログを表すものではない場合がよくあります。つまり、スプリント用に選択されたすべての製品バックログ項目またはスプリントバックログ内のすべての項目を完了することなく、スプリント目標を達成できるはずです。私の現在の考えでは、スプリントの目標を達成するために必要な作業は、チームのキャパシティの約60〜70％になるはずですが、キャパシティを考慮します。ただし、組織が異なれば異なりますが、それは良い出発点となるでしょう。
残業や週末の作業も、反アジャイルソフトウェア開発のプラクティスです。基本的な原則の1つは、取り組みのすべての利害関係者が持続可能なペースで作業できることです。長い日と週末は、たとえ支払われたとしても、チームにとって持続可能ではありません。
この時点で、次のステップがいくつかあります。チームのスクラムマスターは、スクラムとアジャイルソフトウェア開発の価値と原則（「コミットメント」や「持続可能なペース」など）について管理を教育する必要があります。チームは、作業を予測し、製品所有者と範囲を交渉する能力に取り組みます。チームはまた、この状況の原因となった障害を特定または解決する（外部の依存関係の影響を排除または軽減する）ように努める必要があります。
経営陣がチームが計画されたすべてのストーリーを完了するために残業することを要求する、あなたが説明する状況は、スクラム文学が「コミットメント」という用語の使用をやめた理由の1つです。真のコミットメントは、サードパーティの依存関係に関する不確実性、各項目の作業量、病気を考慮に入れて誰もが利用できる時間など、すべての不確実性が排除された場合にのみ与えることができます。
スクラムの基本的な考え方の1つは、チームが持続可能なペースで作業するということです。つまり、基本的には、時間外労働（有給または無給）なしで通常の時間を作業することを意味します。これは、あなたがnotがスクラムの許容可能なバリエーションを経験していることを直接意味します。
それに対して何ができるかは、役割によって異なります。
あなたが開発者なら、あなたができる最善のことは
- （まとめて開発チームとして）スプリント内で配信できると確信している以上の作業に「コミット」することを拒否します。これはおそらく、経営陣があなたにしてほしいことよりはるかに少ないでしょう。
- 新しい仕事から始めるのではなく、仕事を終えることに集中してください。一部の作業を完了できない場合は、計画を調整できるように、できるだけ早くこれを示してください。
あなたがスクラムマスターであるなら、あなたはスクラムについてマネジメントを教育することによってあなたの価値を本当に証明することができます。私に際立っているいくつかのポイント：
- 最初の段落で述べたように、チームはスプリントの計画中にコミットメントを与えませんが、彼らは彼らが完了すると予想する作業の予測を与えます。
- チームはスプリントの終わりに未完成の作業を避けるべきですが、この状況はプロジェクトの開始時（またはチームの構成の変更後）にはほぼ避けられません。チームがスプリントで現実的に達成できる仕事量は、この構成におけるチームの最後の数回のスプリントの履歴数値に基づいてのみ決定できます。プロジェクトの初期には、このような歴史上の人物は存在しないため、最初の3つのスプリントで達成したチームは、各スプリントの計画が適切な計画よりも偶然であることに正確に対応します。持続可能なペースで約5回のスプリントを行った後、チームがスプリント内で実際にどれだけの作業を完了できるかについての合理的なアイデアを得るための十分なデータがあります。
あなたのPMはあなたのスクラムに関与しているビジネスはありません。
あなたのPMはあなたに無給の残業を求めるビジネスはありません。
当然のことですが、すべてのタスクを見積もることで、タスクが時間内に完了することを保証できます。次に、2番目の方法でパブに移動できるようにする必要があります。明らかに、タスクを過小評価すると無料で終了することを意味し、過大評価を行うと仕事がない時間があることを意味します。
これにはいくつかの側面がありますが、ハイレベルでは、はい-PMは、計画された作業が完了していない理由を明確に理解する必要があります。しかし、これは（そして解決済み）振り返ってみると、開発者側から見ると、スプリントの失敗につながる可能性のある要因がたくさんあります。
あなたが考慮したいかもしれないいくつかの事柄：
スプリントが多すぎる
あまりにも多くの仕事に定期的にコミットしている場合、スプリントは失敗します。スプリント速度を経時的に追跡して、ポイント（または日）の最適な数を見つける必要があります。
リソース割り当て
スプリント計画が、式典、休日、トレーニング、管理、サポート、その他のプロジェクトなどの非開発活動を適切に考慮していることを確認します。最初から後ろ足であなたを置きます。
推定変動
あなたは洗練を行っていますが、常にオーバーランする特定の種類のタスクはありますか？一般に、これらは欠落またはあいまいな要件にまで及びます。要件が羊毛である場合、十分に洗練されていないか、または急増が計画されていない限り、ストーリーはスプリントに入れるべきではありません。
速度
速度が適切に追跡されている場合、実際のストーリー数は明確になります。それはそれらが常に時間内に行われると言っているわけではありませんが、それは物事をはるかに簡単にするはずです。
善意
どのプロジェクトでも、善意は限られています。あなたが常に提供するために時間外に働いている場合、士気は低下し、開発者は燃え尽きます-これはプロジェクト管理の失敗です =。すでに概説したように、スプリント計画では、速度とスパイクを使用して現実的な数のストーリーのみをスケジュールし、途中で役立つようにしてください。
スパイク
アイテムがひどく洗練されているか、単なる羊毛である場合、後のスプリントのより良い見積もりを提供するためにスパイクを入れることを恐れないでください。はい、一部の人々は推定が悪いだけですが、ほとんどの場合、完全な事実は現時点では知られていないだけです。理想的には、これは詳細化でカバーされるか、POによって早期に取得される必要がありますが、時にはスプリントにすり抜けることができます。これらは、他の点ではうまくいっているスプリントを簡単に魚雷することができるため、開発者はこれらを強く押し返す必要があります。
いいえ、これはアジャイルの認識された形式ではありません、非常に重要な理由の1つ：配信することを約束している場合すべて、アジャイルを実行していない、あなたはウォーターフォールを再実行します。代わりにアジャイルを実行していると思われる場合は、ウォーターフォールを実行していると思いますpoorly。昔のこぎりが「良い、速く、安い、2つ選んで」というのを聞いたことがあると思いますよね？ソフトウェア開発では、「すべての機能が時間通りに予算通りに提供され、最初の2つまたは他の2つを選択する」に似ています。ウォーターフォールは最初の2つを選択し、アジャイルは2つ目を選択します。
あなたがアジャイルになるつもりなら、あなたはneed時間通りに完了することができないストーリーをスプリントからドロップする柔軟性。これを行う1つの可能な方法は、MoSCoWの優先順位付けを使用してストーリーを評価するようにプロダクトオーナーに依頼することです。これには、ストーリーの60％（ストーリーポイントの合計による）が完了しなければならない必須項目として選択され、20％がプロジェクトによって完了する必要があるべきであるとして選択され、最小実行可能製品がリリースされ、20％が選択されます。時間があれば完了するかもしれませんが、Wo n't Havesのように現在のリリースの範囲外のものはありますか？また、組み合わせた場合、他のカテゴリのアイテムを含める必要がなく、最小生存可能製品を作成するのに十分な肉が骨に必要であることに注意することも重要です。
チームから要求された後、スプリントバックログからアイテムをドロップするかどうかの決定は、プロダクトオーナーの責任であり、スプリントバックログからドロップされたアイテムはプロダクトオーナーによって評価され、その後、プロジェクトから完全に削除された、または適切にランク付けされたプロジェクトバックログに配置された。
この場合、私はあなたのプロダクトオーナーがあなたのプロジェクトマネージャーだと思いますよね？どのタスクを削除するかを決定するのは彼の仕事なので、それを補うためにタスクを削除するのが彼の仕事であり、そうしていないように見えるので、彼はオーバーコミットについてあなたを責めるべきではありません。
彼は正解です。スプリント間で持ち越しはありません。スプリント間のキャリーオーバーがあるスクラムチームはアンチパターンであり、正規のスクラムが有効な結果として受け入れるものではありません。
しかし、彼のアプローチは良いものではありません。
スプリント中、チームは実行中の作業を常に監視し、選択したストーリーの仕上げに関するスプリント計画のコミットメントを維持できるかどうかを確認する必要があります。チームがすべてのストーリーを完了できないことを確認した場合、POと会って、スプリントから削除するストーリーを選択する必要があります。そうすることで、誰もがストーリーの作業をやめ、残りのストーリーを完成させることに集中します。覚えておいてください：2つのストーリーを半分完成させるよりも、1つのストーリーを完全に完成させる方が常に良いです。
外部依存と不正確な推定の問題が、レトロスペクティブが存在する理由です。 Retroでは、チームはこれらの問題を反映し、特定する必要があります。そして、チームはこれらの問題の解決策を見つけて実装する必要があります。システムとわかりやすい経験をよく理解することで、見積もりをより正確に行うことができます。外部依存関係はより困難ですが、修正することは不可能ではありません。
あなたのPM（ 偶数PMスクラムチームで何をしているのですか?? ）は、スクラムマスターがあなたに強制することを許可されるべきではありません代わりに、彼が不満を持っている場合、彼はそれらをRetrospectiveのために保管する必要があります。さらに良いことに、ストーリーが予定どおりに完了できなかった問題を解決するための一部である必要があります。
これは私が知らないスクラムの許容可能な/一般的なバリエーションですか？
いいえ。それは完全に間違っています。 POがスプリント終了前にファクトとして見積もりを出すというミスを犯した場合、私は多分残業支払い済みに同情できます、しかしnpaid残業は完全にばかげており、できるだけ早く別の仕事を探すようになります。
私はこれについて行動するべきだとどのように提案しますか？
私の経験では、レールの大部分を占める人々は論理的な議論に耳を傾けません。それがどれほど壊れているかを彼らが見る唯一の方法はshowであり、教えない。したがって、次に見積もりおよびコミットするときは、可能な限り少ない量にコミットしてください。スプリント終了までに小さなチケットを完成させることを約束します。 1日にできること。 PMがどのように反応するかを確認します。次に、システムの用途とシステムの用途についての議論を開始します）使用されます。
通常、プロジェクトの開始時にチームの速度を決定するとき、新しいチームであることを考慮して、保守的な（通常よりも低い）数値を使用します。チームが落ち着くまでに少し時間がかかります、お互いを理解し、機能とNFRの要件などを理解します。基本的に、最初の数回のスプリントの後、チームの速度を最適化します。明らかに速度はその時点からのみ向上します。
最初からより高い速度をコミットし、それを達成するためにチームを引き延ばしても意味がありません。
もう1つは、1回限りのシナリオで、見逃せない配信のコミットメントがある場合、プロジェクトマネージャーはチームにストレッチ、夜遅くまで働き、週末に働くように圧力をかける可能性があるということです。しかし、それは例外として見なされなければならず、作業の規範ではありません。このように作業すると、短期間で速度が上がる可能性がありますが、コードの品質の問題、チームのバーンアウトの問題、モチベーションの低い不幸なチームなどにつながる可能性があるため、長期的には逆効果になります。
コミットメントFAQ
この動作は正常ですか？
よく分かりません。
意外ですか？
いいえ。一部の人々は常に"commitment"を理解し、コミットメントのすべてを意味しますmust完了する必要があります。
それは良い考えですか？
いいえ。アジャイル開発には、中心的なトピックとしてsustainabilityがあります。無期限にできるかぎり/長く/ハードにのみ作業してください。ほとんどの場合、それは賢明なアイデアです。 （経営陣がこれを受け入れない場合、彼らは組織をアジャイルと呼ぶべきではありません。）
私たちは何をすべき？
- スプリントのコンテンツは推定に基づいていることを説明します。 「見積もり」とは、それがたまにしか正しくなく、通常は間違っていることを意味します。それが間違っている場合、それは時々低すぎたり高すぎたりします。
- 推定動作を変更する方が作業速度よりもはるかに簡単であることを説明します。
- チームが高すぎる見積もりで罰せられた場合、見積もりが低くなり、管理者は、一部のコンテンツを1つのスプリントから次のスプリントに時々プッシュするよりもはるかに多くの進捗を失うことを説明します。
良い点は次のとおりです。プロジェクトマネージャーは、これらすべてのことをすでに知っており、それらが正しいと認識します。 短期的にはそれらを無視することを好むかもしれません。
私はあなたの経営陣に同意しません。彼らはあなたにスプリントを完了するために残業をさせてはいけません。
ただし、コミットメントは不可能であるという考えは、ソフトウェア開発の誤解から生じます。多くのチームが、以前のスプリントで完了したストーリーポイントの数によって、スプリントで完了できるストーリーを予測しようとするのを見てきました。それが可能であれば、ソフトウェア開発は直線的であると言えます。つまり、2時間働いた場合、1時間の2倍の仕事ができます。
ソフトウェア開発は創造的であり、したがって線形ではありません。チームがスプリントで何ができるかを経営陣に伝えて、それらのストーリーを配信することは、チームにとってより良い実践です。コミットメントが一貫して欠落している場合は、ストーリーの範囲がわからないか、製品の所有者からさらに引き継ぐように圧力を受けています。
前者の場合、ストーリーに同意する前に、ストーリーの範囲を理解していることを確認する必要があります。後者の場合、文化的な問題があり、できることはほとんどありません。