チームは常にスプリントの目標を達成できない

私たちは1つの製品を持つ小さなソフトウェア会社です。

私たちはscrumを使用し、開発者は各スプリントに含める機能を選択します。残念ながら、過去18か月の間に、チームはスプリントのためにコミットした機能を一度も提供していません。

「ソフトウェアは、完了したらすぐに、すぐに、もうすぐに...完了します。チームにプレッシャーをかけたり、より多くの人を投入したりするのには役立ちません。 ...」スプリントの成功率をどのように改善できるかという質問に対して、開発者の1人から同様のフィードバックを受け取りました。ああ、そうです、私たちは回顧展を使用しています。

私の質問は基本的に：

開発者の質の問題を探すのはいつですか？

独自の作業/機能を選択しても、各スプリントに失敗する場合は、次のように考え始めています。-独自のコードの複雑さを監督することはできません。-または、コードが非常に複雑であるため、誰もその複雑さを監視できません。

何か不足していますか？

あなたは最初に「誰が気にしますか」と尋ねるべきですか

スプリントを完了することは良い感じであり、一部の企業では、スクラムの親からのCookieになります。しかし、最終的なテストは、会社が目標を達成しているかどうかです。

上記はファセットです。会社がスプリントの計画されたコンテンツを完了せずに成功している場合は、代わりにかんばんを使用することもできます。

定義された反復の値の1つは、プロセスの改善を推進することです（または、一部のメンタリティでパフォーマンスの低い人を追い出すことです）。あなたは今それを得ていません。そのため、プロセスを改善する（そして最終的にはスプリントを完了する）残りのプロセスを採用するか、自分の持っているものが好きであると決めることができます。

何か不足していますか？

はい！

18か月間、または回顧展で36のスプリントの近くに行きましたが、どういうわけか修正できませんでしたか？経営陣は、チームの責任を保有していなかったし、その後その管理が保有していなかった彼らはチームの責任を保持していないために責任？

あなたはあなたの会社が広範に無能であることを忘れています。

だから、それを修正する方法。あなた（開発者）は、そんなに多くの仕事をするのをやめます。ストーリーが大きすぎてできない場合は、ストーリーを小さなチャンクに分割する必要があります。そして、あなたは、彼らが彼らが成し遂げると言うことを成し遂げることに対して人々に説明責任を持たせることができます。各スプリントで小さな機能しか実行できないことが判明した場合は、その理由を見つけて改善します（開発者の交代が必要になる場合があります）。合理的な量の作業にコミットする方法がわからない場合は、それらを解雇します。

しかし、その前に、私は物事をそれほど長く続けさせ、なぜ彼らが仕事をしていないのかを理解する管理を検討しました。

小さな変更を加えて、スクラムの代わりに数週間かんばんを試してみることをお勧めします。あなたのチームにとってはうまくいくかもしれません。

スクラムはスプリントで使用できる作業時間を制限することで生産性を向上させますが、かんばんはアクティブな同時問題の数を制限することで生産性と速度を向上させます。時間の見積もりは、プロセスの一部ではなくなりました。（ソース）

一言で言えば、かんばんとは何ですか？

かんばんは、効率化のために作業を整理するためのツールでもあります。スクラムと同様に、カンバンは作業を管理可能なチャンクに分割することを推奨し、カンバンボード（スクラムボードに非常によく似ています）を使用して、ワークフローを通じて進行する作業を視覚化します。スクラムは、特定の作業量を達成するために許可される時間を（スプリントによって）制限しますが、かんばんは、1つの条件で許可される作業量を制限します（非常に多くのタスクのみを実行できます。 -doリスト。）

SCRUMとかんばんはどのように同じですか？

スクラムとかんばんはどちらも、大規模で複雑なタスクを分解して効率的に完了することを可能にします。両方とも、継続的な改善、作業とプロセスの最適化に高い価値を置きます。そして、両方とも、WIPと今後の予定に関するすべてのチームメンバーをループ内に維持する、非常に目に見えるワークフローに非常によく似た焦点を共有しています。

このリンクから詳細の残りを参照してください

私の質問は基本的には次のとおりです。開発者の質の問題を探すのはいつですか？

投稿にその質問に答えるのに十分な情報がありません。能力がないために失敗するのか、それとも合理的な以上の仕事をすることにコミットするために失敗するのかを知る方法はありません。

私が信じられないほど才能のある開発者で、信じられないほど才能のある開発者のチームで、2つのスプリント（または36！）でXストーリーを完了できない場合、私たちは無能ですか？それとも、私たちは推定値を吸うだけですか？それは、ストーリーが「ログイン画面を作成する」か「火星に安全に男を送る」かによって異なります。

問題は悪い話や悪い推定から始まります

見積もりは難しいです。とても大変。人間はそれを吸うので、スクラムは私たちに仕事を1日か2日以上かかるべきではないブロックに分解し、短い期間で完了できると確信しているブロックの小さなグループを組み立てる理由です。ブロックが大きく、期間が長いほど、推定の精度が低くなります。

あなたの店はどんな感じですか？彼らは良い受け入れ基準でよく書かれていますか？それぞれわずか数日で実行できるほど小さいですか？よく書かれたストーリー（製品所有者を含む開発チーム全体の責任）がなければ、チームは良い見積もりをすることは期待できません。

問題は悪い回顧により悪化します

あなたが間違っていることは、一見、振り返りを利用していないということです。この問題を解決せずに18か月間行ったため、チームが問題に気付いていないか、振り返って問題に対処していません。

次のスプリントでより良い結果を出すために、各回顧展はチームがとるべき少なくとも1つのアクション項目で終了していますか？それぞれの回顧展には、前のスプリントのアクションアイテムについて話し、それらが実行されたかどうか、効果的かどうかを確認することが含まれていますか？

解決策は非難することではなく、学ぶことです

最初のステップは、非難を探すのをやめ、代わりにチームを改善するために働き始めることです。あなたのチームはおそらく無能ではなく、見積もりと計画が下手です。チームが1つのストーリーを選んで1週間早く終了することを意味する場合でも、チームにスプリントを強制的に終了させます。それができない場合、彼らは無能であるか、物語が単純に複雑すぎます。その質問に対する答えは明白なはずです。

1つのストーリーを完了すると、スプリントでXポイントのストーリーポイントを実行できることが合理的な確実性でわかります。単純な数学は、彼らがより多くの物語をすることができるかどうかの質問に答えるのに役立ちます。

継続的な改善が解決策です

スプリントで1つのストーリーを終えたら、2つできるかどうかを確認します。泡立て、すすぎ、繰り返します。彼らがスプリントの目標に失敗し始めたとき、あなたは彼らの推定能力の限界を見つけました。前のストーリーのストーリーポイントの数に戻り、しばらくの間それを守ります。

常に、回顧を真剣に受け止めてください。彼らがスプリントを完了しなかった場合は、理由を見つけて行動してください。彼らはあまりにも多くの未知のものを持っていましたか？スキルの組み合わせが間違っていますか？彼らの見積もりはどれくらい良かったですか？ストーリーをXポイントと推定した場合、Xポイントに相当する優先ストーリーと同じくらいの作業量が必要でしたか？そうでない場合は、それを使用して、今後のストーリーのポイントを調整します。

あなたは「回顧展を使う」と言います。しかし、チームはこれらの回顧展で実際に何をしますか？プロセスのこの側面に一度も対処せずに18か月間行ったので、答えは次のように推測します。

私にとって、回顧展はプロセスの最も重要な部分です。スクラムに関する他の何かを捨てたり変更したりします（もちろん、回顧会でのチームの合意により）が、定期的に時間をかけてプロセスがどのように機能しているか、何が機能し、何が機能したかを共有することを約束しますうまくいかず、改善するアイデアを提案する。すべてのスプリントを少しずつプロセスの改善に努めてください。遅かれ早かれ、かなりうまく機能するものを手に入れることができます。

あなたの場合、そのプロセスは機能していないようです。スプリントの目標は達成されていないので、なぜそうなのかを振り返ってみるのが賢明です。明らかに、チームはスプリントにはあまりにも多くの仕事をしました。しかし、なぜ彼らはそれをしたのですか？

• 彼らは仕事の複雑さを過小評価していましたか？
• 経営陣は、チームが処理できると考えていたよりも多くの作業を行うように圧力をかけましたか？
• 計画された作業の完了からリソースを奪うほど多くの中断/緊急事態が発生しましたか？
• 彼らは仕事の完了を遅らせるボトルネックを経験しましたか（例えば、外部の設計チームからの資産を待つ）？
• さらに：1人または複数のチームメンバーが仕事をすることができませんでしたか？

これらは、過去18か月間、チームがあらゆるスプリントを自問していたはずの種類の質問です。次に、答えを準備して、提案されたプロセス改善を次のスプリントのトライアルに提案できます。これらには以下が含まれます。

• 次のスプリントでの作業量を減らす
• 見積もりを控えめにする
• 私たちは今すぐに達成できる以上のことをすでに引き受けているので、誰が私たちを吹き飛ばすためにもっと多くの仕事をするように圧力をかけている人に教えてください
• 中断をより適切に管理し、次のスプリントの作業量を調整して、避けられない緊急事態に対応する
• ボトルネックを修正するか、回避できないものを回避する
• ストーリーを達成できないチームメンバーにはストーリーを割り当てないでください（また、トレーニングやメンターシップから解雇まで、パフォーマンスの低いチームメンバーの状況に対処するために、経営陣の対応を別途考えてください）

これは、過去18か月間すべてのスプリントで起こったはずの会話です。チームにプレッシャーをかけることやリソースを追加することではなく、回顧を使用してプロセスを継続的に改善することです。ここでは明らかにそうではありません。

ゴールを逃した15回目のスプリントまでに、チームはこれを何度もレトロスペクティブで議論し、1つのゴールを達成するために可能な限り最小のスプリントゴールをとることにしたと思うでしょう。25番目の未完成のスプリントまでに、ストリングを1回変更するだけでスプリントを実行します。チームがスプリントでそれを管理できない場合、問題はあなたが任せるよりもさらに深刻です。

明確にするために、ここでいくつかがすでに指摘したように、スプリントの目標は予測であり、鉄のコミットメントではなく、目標の欠落はそれ自体が不正確な予測を行うことを示すものではありません。優れたチームは、予測力が低​​いために多くの目標を逃す可能性がありますが、ひどいチームはすべての目標を達成でき、実際の価値を提供できません。しかし、18か月連続して同じ方向の予測が間違っている場合、プロセスのその部分は機能していません。振り返りを使用してプロセスを修正し、予測がチームが各スプリントを提供できる実際の現実にかなり近いようにします。

「ソフトウェアは完了したときに、すぐに、すぐに完了します。」

これは事実ですが、開発者が作業を開始する各タスクについて、組織内の全員が各タスクの完了の定義を理解していますか？

最大の問題の1つは見積もりであるように見えますが、開発者は明確で明確に指定された「完了の定義」がある場合にのみ現実的な見積もりを提供できます。（これには企業プロセスの問題が含まれます-ユーザー文書、正式リリースの作業パッケージなど）

ほとんどの開発者が、タスクの完了に必要な時間を見積もることが最も難しいと考えていることを考えると、過大評価が問題を引き起こしていることは驚くことではありません。

ただし、ほとんどの開発者は、一定の期間、合理的な（楽観的ではあるが）投入できる労力を処理する傾向があります。

問題は、多くの場合、開発者が不完全な情報を処理するときに必要な作業と総作業量との関係を作成するのに苦労することです。 。

これにより、当然、時間の見積もりが現実から切り離され、ビルドプロセスやユーザードキュメントなどが見えなくなります。

切断は、タスクが記述されている最初から始まる傾向があります。また、通常は、技術に詳しくない人が必要な労力の手がかりを持たずに要件のリストを作成することで悪化します。

上級管理職の人がタスクを指定し、会社のプロセスの問題を完全に無視する場合があります。上級管理職が、テストの定義、正式なリリースビルドの作成、ユーザードキュメントの更新などの作業が時間と労力をかけずに魔法のように行われると考えることは珍しくありません。必須。

誰かがどこかで正しく仕事をしていないために、開発者がコード行を書く前にプロジェクトが失敗することもあります。

開発チームが要件の同意や受け入れ基準の取得に関与していない場合、それは管理の失敗です。これは、コードと技術的な問題を十分に理解していない人が、ビジネスを不完全な要件セットにコミットしていることを意味するため、プロジェクトを誤解、スコープクリープ、金メッキなどにさらされたままにしました。

開発チームは、要件をキャプチャし、同意に関与している場合、それはチームの失敗可能性があり、詳細（および許容基準を明確にする責任がある者-すなわち「？成果物の外観は次のようにするとき、それが何をしているん行って？」 ）。また、開発チームは、他のブロッキングの問題がある場合、または要件が非現実的である場合、NOと言う責任があります。

したがって、開発者が要件のキャプチャに関与している場合：

• チームは、プロダクトマネージャーと協力して、完了した要件/定義を明確にする機会がありますか？
• チームは、暗黙的/想定される要件を明確にするために十分な質問をしますか？これらの質問はどれくらいの頻度で満足に答えられますか？
• チームは、見積りを提供する前に、受け入れ基準（完了の定義）を要求していますか？
• 通常、各タスクの合格基準はどれくらい適切にキャプチャされますか？それはまばらな詳細のあいまいなドキュメントですか、それとも具体的な機能、および開発者が明確にテストに変換できるという表現を記述していますか？

チャンスは、チームの生産性が問題にならないことです。あなたのチームはおそらく、開発に関してできる限りの努力をしています。実際の問題は、次の1つ以上の可能性があります。

• 不完全であいまいな要件。
• そもそも大きすぎる要件/タスク。
• 開発チームと経営陣の間のコミュニケーションが不十分です。
• タスクがチームに渡される前の明確に定義された受け入れ基準の欠如。
• 受け入れテストの仕様が不完全またはあいまい/あいまいです。（すなわち、完了の定義）
• 受け入れ基準の定義/同意に割り当てられた時間が不十分です。
• 開発者は、既存のベースラインコードをテストしたり、既存のバグを修正したりする時間を考慮しませんでした
• 開発者は既存のベースラインコードをテストしましたが、要件の推定値を提供する前に、バグをブロッキングの問題として提起しませんでした
• 管理者は問題/バグを見つけ、新しいコードを書く前にバグを修正する必要がないと判断しました。
• 開発者は、おそらく時間の20％（または同様の数）が会議、気晴らし、電子メールなどによって占められているにもかかわらず、時間の100％を占めるように圧力を受けています。
• 見積額は額面で合意されており、エラーや不測の事態に対応する余地を調整する人はいません（たとえば、「これには5日かかると判断したため、8で完了すると予想されます」）。
• 見積もりは、現実的な「範囲」の数字ではなく、単一の数字としてすべての人（開発者と管理者）によって扱われます。
  • ベストケースの見積もり
  • 現実的な見積もり
  • 最悪の場合の見積もり

...リストはそれよりもずっと長く続く可能性があります。

いくつかの「事実発見」を行い、推定値が一貫して現実から切り離されている理由を正確に把握する必要があります。既存のベースラインソフトウェアは不良ですか？単体テストのカバレッジが不足していますか？開発者は経営陣とのコミュニケーションを避けていますか？管理者は開発者とのコミュニケーションを避けていますか？「Definition of Done」に関して、管理者の期待と開発者の期待の間に断絶はありますか？

チームを再起動するための私のアドバイスは、チームごと、スプリントごとに可能な限り最小のストーリーを選択し、その1つのストーリーを完了し、その1つのストーリーのみにすることです！

私は他のポスターに同意します、チームが無能であるか、彼らがあまりにも多くのことをしようとしています。

最小のもの、最も簡潔なストーリーから始め、単一のスプリントを完了します。チームがスプリントを完了して成功するようにすれば、時間と仕事のコミットメントを優先する方法を理解するのに役立ちます。時間の経過とともに、チームは生産性が最大になるまで、より多くの仕事を引き受けることができるようになります。

データを収集し、過去のパフォーマンスに基づいて信頼レベルを構築する必要があります。

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

最も簡単な例は、2週間ごとなどの一定時間のスプリントです。チームが2週間以内に完了するストーリーポイントの数を見積もります。次に、2週間のスプリントが終了したら、実際に完了したストーリーポイントの数を確認します。時間が経つにつれて、15ポイントを見積もるのに10しか終わらないことがあります。この単純なケースでは、スプリントごとに10ポイントしか計画しないように、速度調整で前進を開始できます。または、推定作業の66％を完了する予定です。

標準偏差を使用して信頼レベルを構築することにより、経営陣に伝えることができます。現在のプロジェクトの目標によると、3週間で完了できるのは50％の信頼だけですが、5週間で完了することができるのは95％の信頼です。

アジャイルとスクラムの背後にある考え方は、プロセスを評価できるようにタイトなフィードバックループを構築することです。「どこで壊れたのか」と尋ねる必要があります。完全に壊れたようです。

1. あなたがやろうとしていることを計画し、それのリストを作ります
   • これは、完了する必要があるアイテムのバックログからアイテムを選択することで構成する必要があります。スプリントのTo Doリストに何かを追加する前に、チームはそれを完全に理解し、大まかに見積もってスプリントよりも少ない時間で完了することに同意する必要があります。
   • 理想的には、バックログは（ビジネスに対して）優先度順に並べられ、優先度順にプルできます。
   • バックログのアイテムが大きすぎる場合、それらを小さなチャンクに分割します。次に、チャンクを1日以内に完了することができる個々のタスクに分割します。
   • この計画が簡単または迅速であることを期待しないでください。
2. 定義された期間（スプリント）の間、リストのアイテムを実行します
3. 達成したことを確認する
   • どのストーリーが完成しましたか？
   • ストーリーが完成していない場合、ストーリーを構成するどのタスクが終了しましたか？
   • タスクが完了しなかった場合、先週の月曜日に全員が正確に何をしましたか？先週の火曜日？など-この時点で、厳しい内省の時間です...

4. 問題のトラブルシューティング（フィードバックの分析と適応）

   • 完成したものはどれくらいかかりましたか？
   • 何がタスクの完了を妨げましたか？
   • チームメンバーは、ストーリー（機能）を1日以内に完了することができるタスクに分解していますか？そうでない場合は、これを実行し、実行リストの一部にします。
   • スプリント中にタスクリストまたはタスクリストの項目にどのような変更が加えられましたか？これが終了しなかった原因ですか？その場合は、リストまたは機能を変更しないでください。安定するまで、変更された機能をバックログにスローします。
   • いくつかのアイテムのサイズと範囲をスプリントで完成できるものにするにはどうすればよいですか？ロギングの改善、単純なバグ修正、タイプミスのような小さなものを選んで、チームが何ができるかをチームが把握できるようにするために、いくつかのものを完成させます。これができない場合は、スプリントを停止して再計画します。

5. ステップ1に戻り、リリースまで繰り返します...

文書化の障害、依存関係を作成する結合の問題、通信の問題、要件に十分な情報がありませんか？...何ですか？開発者は新しいテクノロジーを習得しようとして時間を費やしましたか？彼らは設計に膨大な時間を費やしましたか？学習のようなものは、スプリントタスクリストで説明されましたか？

あなたのチームは、それぞれの回顧展で問題を切り分けたと思うと思いましたか？チームは問題を修正するために行動しましたか。チームは対応せず、経営陣は単にソリューションと行動方針を指示しただけですか？

長い期間を考えると、開発者だけでなく、体系的に何かが間違っています。ある時点（1年が経過する前）で、チームの誰か（スクラムマスターを含む）が、どんなに小さなことでも達成できるかと尋ねるべきでしたか？

あなたの状況では、回顧は遅すぎます。
毎日スタンドアップミーティングを開催し、過去24時間に何をしたかについて真にステータスを取得していますか？
スクラムマスターはそれらの会議を使用して、各開発者の目標に対する進捗を測定していますか？
スクラム方法論の一部を使用して、進行状況を監視する必要があります。人々が何をしているのかについての良い洞察を与えるはずです。
彼らは気を散らしていますか？コーヒーに時間をかけすぎたり、SE / SOで他の人を助けたり、ニュースを読んだり、説明されていない検査をしたりしますか？それとも彼らは本当に頭を下げて、全力で前進し、徹底的にオーバーコミットしていますか？毎日のビューはあなたに良いアイデアを与えるはずです。また、開発者が目前のタスクに集中できるようにするので、昨日何もしなかったことを認める必要がありません。
そしてもちろん、彼らがスプリント全体で着実な進歩を報告し、それでも最後に配信されない場合、彼らは嘘をついていたので、新しい開発者の時間かもしれません。

プログラミングコードなどの複雑なタスクを完了するために必要な労力と時間を見積もることは困難です。ジョエル・スポルスキはそれを置きます：

ソフトウェア開発者は、スケジュールを作成することを本当に好みません。通常、彼らはそれなしで逃げようとします。「やったらやるよ！」と彼らは言います、そのような勇敢で面白いジンジャーは上司を笑いのようなものに減らすと期待し、その後の陽気な中でスケジュールは忘れられます。

ただし、企業が運営するには期限が必要です。Joelが示唆したように、エビデンスに基づいたスケジューリングを使用してみてください。これにより、関連する確率で時間の推定値が得られます。

スクラムはいくつかのことを行います。

まず、優先順位付けを奨励します。仕事の供給者は、「すべてが等しく重要である」と言うのではなく、最初にやりたいことを言わなければなりません。

第二に、すべてが終了していなくても、ある程度使いやすい製品を生成します。それが、各イテレーションの最後に「潜在的に出荷可能な製品」を持つポイントです。

第三に、フィードバックループがより厳密になります。スプリントの最後に物事を「完了」することを主張することで、「90％の機能は完了しましたが、半分しか完了していません」という問題を回避できます。締め切りを迫るとき、締め切りに間に合うように見えるように脇にやらなければならないことを押し出すことができます。完了の定義を持ち、実行されていることを主張することにより、何かが後ではなく前よりも難しいかどうかを知ることができます。

第4に、詳細計画を作業の実行に近づけることにより、在庫を回避します。物事の計画は、在庫の形式です。つまり、顧客に販売したり、すぐに使用したりできないリソースに費やした資本です。このような在庫は腐敗する可能性があり（計画が変更され、新しい情報が時代遅れになります）、ニーズと不整合になります（分散ネットワークwhatzitを使用することは価値がないため、必要ないことが判明します）。 （去年、あなたの時間の半分が来年以降の計画に費やされていた場合、代わりに今すぐ準備するものに取り組んだなら、2倍の出荷を得ることができたでしょう）。損失なしで計画を実行に近づけることができる場合（厄介です！）、在庫を減らすことができます。

これらの問題を解決する唯一の方法ではありません。定期的に新しい作業を追加し、進行状況を確認しながら、開発者に作業の流れを各期間に提供するスクラムを使用しているようです。

これは、スクラム風のパターンを使用する便利な方法です。作業の流れを維持し、本番に近い計画を立て続け、フィードバックループなどを提供します。システムに合わせて開発とテストをゆがめないという利点もあります（作業が基本的に終了した状態でテストを行うのが最適な場合） 、同じスプリント内で物事を完了してテストしようとすると、スプリントのバックエンドは新しい開発を伴わないように強制されます！）

彼らがやろうとしていることを正確にスプリントに入れられなかったことは、開発者が素晴らしい仕事をしていないという証拠ではありません。それは、彼らがフレームワークの一部を使用する代わりに、SCRUMを高いところから追っていないことを意味します。

彼らが各スプリントにどれだけコミットしたかを半分にした（または4分の1にした）が、他のすべてを同じに保った場合、彼らは各スプリントにコミットしたよりも多くを終えたでしょう！同じ量のコードが生成されます。「スプリントの失敗」は重要な部分ではないことは明らかです。これは単なる内部プロセスの詳細だからです。会社の目標は、たわごとを成し遂げることであり、そのたわごとは良いことです。目標が特定のISOプロセス認証である場合を除き、特定のプロセスに従わないこと。

このプロセスは、行われた作業の目標に従属しています。

一方、SCRUMのルールに従っていないため、同じ種類のフィードバックは得られません。作成された欠陥の種類が、SCRUMが対処するように設計された欠陥であるかどうかを確認するには、結果のものを調べる必要があります。ゾンビのように永遠に生き、そして遅くまでしか殺されない物語はありますか？簡単に思えるストーリーがありますが、爆発し、回顧展では全体の作業に値しません。製品は実際に出荷する必要がある/出荷したいときに出荷可能ですか？

「ソフトウェアが完了したらすぐに、すぐに完了します」というのは、「完了」がどのように見えるかを定義していない場合の失敗のレシピです。

ほとんどのエンジニアは可能な限り最高のソリューションを作成しようとしますが、これは特に経験の浅いエンジニアにとっては簡単に金メッキにつながる可能性があります。管理の唯一の責任は、目標がどこにあるかを正確に定義し、エンジニアをその方向に向け続けることです。エンジニアは機能を改善するためにサイドターニングを試みることがよくありますが、そのサイドターニングが物事を長期的にスピードアップするか、それとも改善のためだけに改善するかを決定するのは管理者次第です。

アジャイル開発のポイントは、それぞれの新しい作品がそのスプリントを満たすために必要なだけ良いものでなければならず、良いことではないことです!!!!!! はい、それは私がStackOverflowで追加できる最も重要なことです-そして、それはまだ十分な強調ではありません。すぐに必要ではないものを人々が追加していることに気付いたら、アジャイル開発を正しく行う方法についてのトレーニングが必要です。

ああ、そうです、私たちは回顧展を使います。

ああ、チームの失敗の理由を知っていますか？何が機能し、何が機能しなかったかについて話す機会が36回あるので、スクラムマスターは問題を解決する方法を完全に理解する必要があります。

あなたの説明によると、あなたの会社は「SCRUMが私たちの生産性を高めます」という考え方に陥っていると思います。 真実は、SCRUMがあなたの生産性を高めないということです。むしろ、あなたが作るのを助けるためのツールである自分がしばしば問わず管理と開発者が見落としている開発の現実を特定する方法で生産。

スクラムマスターは、チームの潜在的な問題として何を特定しましたか？彼らは絶えず彼らが扱うことができる2倍の仕事を割り当てていますか？もしそうなら、スクラムマスターはチームの速度を見ることができるので、スクラムマスターはより少ない作業で行うことを穏やかに提案するべきです。

開発者の質の問題を探すのはいつですか？

開発者の質の問題を探すべき時は、それが問題だと確信した瞬間です。これは、SCRUMによって作成された新しい問題ではありません。これがビジネスの現実です。SCRUMを使用すると、チームメンバーの能力に関する従来のアプローチよりもはるかに多くの情報を得ることができます。 問題が「ソフトウェア開発者は十分ではない」か「管理の期待は非現実的」かどうかを、従来のアプローチで理解するよりもはるかによく知っておく必要があります。 これは、経営陣が経営陣が最も得意とすることを行うときです。つまり、会社がお金を稼ぐことができるように、仕事に適した人材を見つけます。問題がどこにあるのかわからない場合は、それらすべてを振り返らずに伝えるのがどれほど難しいか想像してみてください！

人々が十分に良いと思うなら（彼らの雇用は経営者側の間違いではないことを意味します）、私のアドバイスは枠の外で考え始めることです。作業が完了していない場合は、開発者向けに作業の形状を変更することを検討してください。スプリントの完了期限を設定するために見つけた最も簡単な方法の1つは、DONE基準を調整して、どのように実行しても結果に満足できるようにすることです。したがって、完了することはトートロジーになります。

これにより、管理、特にSCRUMマスターに責任が生じます。 秘Theは、完了した場合、非常に価値のあるタスクを作成することですが、不完全なままにした場合でも、給料に見合うだけの十分な付加価値を企業に提供します。 18か月後、あなたの回顧展が何かを教えてくれたことを期待しています。そうでない場合は、失敗したストーリーがあなたの会社で間違っている何かを発掘し、それを明らかにするという明確な意図を持ってストーリーを書く必要があります。企業が開発チームにどれほど不満を感じているかを考えると、それは企業に膨大な価値のあるデータを提供するでしょう。あなたが尋ねるように、問題は確かに開発者かもしれません。または問題は、あなたが今まで知らなかった会社の考え方の病理かもしれません！

実際に問題が開発者ではなく会社にある場合、これらの不完全なストーリーから収集した情報は、成功したものから収集した製品よりも価値があるかもしれません！会社全体を救う情報かもしれません！ それは私にとって本当に貴重な情報のように思えます、そしてあなたはあなたがそれを集めるのを助けるツールとしてSCRUMを使うことができます。

「開発者の品質を見るのはいつですか？」

ずっと。明らかに、一部の人々は他の人々より生産的です。パフォーマンスを測定するための雇用者としての言い訳は必要ありません。

トリッキーなビットは、あなたがそれを行う方法です。私のアドバイスは、経験豊富な請負業者を雇って、パーマのスタッフと一緒に、パーマ担当者が見積もったタスクの同じセットで作業し、彼らがより速いかどうかを確認することです。

これにより、長期雇用に縛られることなく、現在の市場との良好な比較が可能になります。

それはまた、パーマの男たちにちょっとした刺激を与えるかもしれません。

さらに、請負業者が品質などをスキップして速度を上げることに不満を抱いている場合、ビジネス価値がどこにあるのかについての会話を促進します。長期保守または短期製品の出荷。

それが長期的なものである場合、それはあなたにそれを定量化し、要求としてスプリントにそれを置くことを強制します！

すでにいくつかの優れた答えがあります。特に、悪い評価、過剰なコミットメント、および/または予定外の作業は、滑りの頻繁な原因です。

しかし、「[あなたの]開発者が各スプリントに含める機能を選択する理由」については興味があります。開発者は通常、優先度が最も高い機能に最初に取り組んでいる必要があります。優先度はビジネス上の意思決定です。つまり、ビジネスの利害関係者の代理として機能する製品所有者が決定します。
（これには例外があります。特に、リスクの高い機能は一般に以前に機能します。また、ユーザー向けの機能は他の機能に依存する場合があります。 ）

一方、見積もりは技術的な決定であり、ビジネスマンが行う（または推測する）べきではありません。これについては何も言わない-私の経験では、開発者が作業するものを選択しているときに、ビジネスマンがそれがどれくらいの時間を取るべきかを指示しようとするのはかなり一般的だからです。

かなり機能不全のプロセスがあるようですね。少なくとも当分の間は、開発者コンサルタントを連れてこないことをお勧めします。それはおそらく士気に悪影響を与えるからです。しかし、あなたの組織はプロジェクト管理側で何らかの助けを借りることができるようです。それは、経験豊富なアジャイルコーチを導入することから始めます-中長期のエンゲージメントでない場合は、少なくとも評価または「ヘルスチェック」のために。優れたコーチは、パフォーマンスの低い開発者がいるかどうかを教えてくれますが、少なくともこの方法では、（開発者だけでなく）チーム全体が精査されています。

もう1つの観察：私の経験では、優れた開発プロセスに従っていない場合、プロジェクト管理方法論としてスクラムを成功させることは非常に困難です。自動化された単体テストを行っていますか？またはさらに良い自動受け入れテスト？開発者はペアになっていますか、少なくともコードレビューやウォークスルーを頻繁に実行していますか？何らかの形で継続的な統合を実践していますか？