チームは常にスプリントの目標を達成できない
私たちは1つの製品を扱う小さなソフトウェア会社です。
私たちは scrum を使用し、開発者は各スプリントに含めたい機能を選択します。残念ながら、過去18か月間、チームはスプリントのためにコミットした機能を一度も提供していません。
私は、「ソフトウェアが完了すると、すぐに、そして遅くとも...ソフトウェアが完了すると、チームにプレッシャーをかけるのに役立ちません。 ...」私は、スプリントの成功率をどのように向上させることができるかという質問に対して、開発者の1人から同様のフィードバックを受け取りました。ああ、そうです retrospectives を使用します。
私の質問は基本的に：
開発者の質の問題を探すのはいつ公平ですか？
自分の作業/機能を選択しても、各スプリントで失敗する場合は、次のように考えています。-自分のコードの複雑さを監視することはできません。 -または、コードが複雑すぎて誰もその複雑さを監視できない。
何か不足していますか？
あなたはまず「誰が気にするか」を尋ねるべきですか？
スプリントを完了するのは気分が良く、会社によってはスクラムの親からのCookieが発生する場合もあります。しかし、最終的なテストは、会社が目標を達成しているかどうかです。
上記は面倒です。会社が成功していて、スプリントの計画されたコンテンツを決して完了しない場合は、代わりにかんばんを使用することもできます。バックログを並べ替え、最も重要なものに取り組み、定義された反復についてそれほど心配する必要はありません。
定義された反復の価値の1つは、プロセスの改善を推進することです（または一部のメンタリティーでパフォーマンスの劣る者を排除すること）。あなたは今それを取得していません。そのため、プロセスを改善する（そして最終的にはスプリントを完了する）残りのプロセスを採用するか、自分が持っているものを好きだと決めることができます。
何か不足していますか？
はい！
あなたは行きました18か月-または、振り返りを伴う36のスプリントの近くのどこかで、どういうわけかそれを修正できませんでしたか？経営陣はチームに責任を負わせず、その後彼ら経営陣は彼らに責任を負わせませんでしたチームが責任を負わないことに対して責任がありますか？
あなたの会社が広範に無能であることが不足しています。
だから、それを修正する方法。あなた（開発者）はそんなに多くの仕事をするのをやめます。ストーリーが大きくてそれができない場合は、ストーリーを小さなチャンクに分割する必要があります。そして、あなたは人々が彼らが成し遂げると言うことを成し遂げるために人々に責任を負わせるようになります。それが判明した場合、スプリントごとに小さな機能しか実行できない場合は、その理由を理解し、それを改善します（開発者の交換が必要になる場合があります）。彼らが合理的な量の仕事にコミットする方法を理解できないことが判明した場合、あなたは彼らを解雇する。
しかしその前に、私は物事をそれだけ長く続けることができる管理を見て、なぜ彼らが彼らの仕事をしていないのかを理解します。
Scrumの代わりに、少し変更してKanbanを数週間試してみることをお勧めします。それはあなたのチームにとってよりうまくいくかもしれません。
スクラムはスプリントで使用可能な作業時間を制限することで生産性を高めますが、カンバンはアクティブで同時に発生する問題の数を制限することで生産性と速度を高めます。時間の見積もりはプロセスの一部ではなくなりました。 （ ソース ）
一言で言えば、かんばんとは何ですか？
かんばんは、効率を上げるために作業を整理するためのツールでもあります。スクラムと同様に、カンバンは作業を扱いやすいチャンクに分割することを奨励し、カンバンボード（スクラムボードに非常によく似ています）を使用して、ワークフローを通じて作業を視覚化します。スクラムが特定の作業量（スプリントによって）を達成するために許可される時間を制限するのに対して、カンバンは、任意の1つの条件で許可される作業量を制限します（非常に多くのタスクのみが実行可能であり、非常に多くのタスクしか実行できません） -doリスト。）
SCRUMとかんばんはどのように同じですか？
スクラムとカンバンの両方で、大規模で複雑なタスクを分解して効率的に完了することができます。どちらも、継続的な改善、作業とプロセスの最適化に高い価値を置いています。また、両方のチームは、すべてのチームメンバーがWIPと今後の予定を常に把握できるようにする、非常にわかりやすいワークフローに非常によく似ています。
詳細はこちらから link
私の質問は基本的に：開発者の質の問題を探すのはいつ公平か
投稿にその質問に答えるのに十分な情報がありません。彼らが能力がないために失敗しているのか、あるいは合理的ではない多くの仕事をしているために失敗しているのかを知る方法はありません。
私が信じられないほど才能のある開発者であり、信じられないほど才能のある開発者のチームで、Xストーリーを2つのスプリント（または36！）で終えることができない場合、私たちは能力がありませんか？または、私たちは見積もりを吸うだけですか？それは、ストーリーが「ログイン画面を作成する」か「人を安全に火星に送る」かによって異なります。
問題は悪い話や悪い見積もりから始まります
見積もりは難しいです。とても大変。人間はそれを吸うので、スクラムでは、1〜2日以内にブロックに作業を分割し、短時間で完了できると確信しているブロックの小さなグループを組み立てます。 。ブロックが大きいほど、また期間が長いほど、推定の精度は低くなります。
どんなお店ですか？それらは適切に受け入れ基準で書かれていますか？それらはそれぞれ数日で十分なほど小さいですか？よく書かれたストーリーがないと（製品所有者を含む開発チーム全体の責任です）、チームが適切な見積もりを行うことは期待できません。
問題は悪い回顧展によって悪化している
どうやら、あなたが間違っているのは、回顧を利用していないということです。この問題を解決せずに18か月が経過したため、チームが問題に気付いていないか、または振り返って問題に対処できていません。
次のスプリントでより良い結果を得るために、各回顧はチームが取るべき少なくとも1つのアクションアイテムで終わりますか？各回顧展には、前回のスプリントのアクションアイテムについて話し合い、それらが行われたかどうか、および効果的だったかどうかを確認することは含まれていますか？
解決策は非難することではなく、学ぶことです
最初のステップは、非難を探すのをやめ、代わりにチームを改善するための作業を開始することです。あなたのチームはおそらく無能ではなく、見積もりと計画が悪いだけです。チームが1つのストーリーを選んで1週間早く終えることを意味する場合でも、スプリントを完了するように強制します。彼らがそれを行うことができない場合、彼らは無能であるか、物語は単に複雑すぎる。その質問に対する答えは明白であるはずです。
1つのストーリーを完了すると、スプリントでXポイントのストーリーポイントを実行できることが合理的に確実にわかります。簡単な数学は、彼らがより多くの物語を行うことができるかどうかの質問に答えるのに役立ちます。
継続的な改善が解決策です
彼らが1つのスプリントで1つのストーリーを終えたら、2つのストーリーを実行できるかどうかを確認します。泡立て、すすぎ、繰り返します。彼らがスプリントの目標に失敗し始めたとき、あなたは彼らの推定能力の限界を発見しました。前のストーリーのストーリーポイントの数に戻り、しばらくそれを使い続けます。
常に、回顧を真剣に受け止めてください。彼らがスプリントを完了しなかった場合は、その理由を理解して行動します。彼らはあまりにも多くの未知数を持っていましたか？彼らは間違ったスキルの組み合わせを持っていますか？彼らの見積もりはどれほど良かったですか？ストーリーがXポイントであると見積もられた場合、Xポイントの価値がある先験的なストーリーと同じくらいの量の作業が必要でしたか？そうでない場合は、それを使用して、今後のストーリーのポイントを調整します。
あなたは「回顧展を使う」と言います。しかし、チームはこれらの回顧展で実際に何をしますか？プロセスのこの側面に一度も対処せずに18か月が経過したので、答えは次のとおりです。
私にとって、回顧はプロセスの最も重要な部分です。もちろん、スクラムについては何でも投げたり変更したりします（もちろん、振り返りの際にチームが相互に同意することにより）。ただし、定期的に時間をかけて全員がプロセスがどのように機能しているかについて話し合い、何が機能し、何が機能しなかったかを共有することを約束します。機能せず、改善するためのアイデアを提案します。スプリントごとにプロセスを少しずつ改善していきます。遅かれ早かれ、かなりうまくいくものを持つことができます。
あなたの場合、そのプロセスは機能していないようです。スプリントの目標が達成されていないので、なぜこれが当てはまるのかを振り返って焦点を当てることは賢明です。明らかに、チームはスプリントのためにあまりにも多くの仕事を引き受けました。しかし、なぜそれをしたのですか？
- 彼らは仕事の複雑さを過小評価していませんか？
- 経営陣は、チームが処理できると思った以上の仕事を引き受けるよう圧力をかけましたか？
- 計画された作業を完了するためにリソースを奪うような中断/緊急事態が多すぎませんでしたか？
- 作業の完了を遅らせるボトルネックが発生しましたか（たとえば、外部の設計チームからの資産を待っていました）。
- さらに、1人以上のチームメンバーがその仕事をまったく実行できなかったのでしょうか。
これらは、チームが過去18か月間すべてのスプリントに自問していたはずの種類の質問です。次に、回答を用意して、次のスプリントのトライアルに提案されたプロセス改善を提案できます。これらには以下が含まれます。
- 次のスプリントでより少ない仕事を引き受けます（ええ！）
- 見積もりをより保守的にする
- 私たちがすでに達成できる以上のことをすでに行っているので、誰も私たちに芝刈りのためにもっと多くの仕事をするように圧力をかけていることを教えてください
- 中断を適切に管理し、次のスプリントでの作業量を調整して、不可避の緊急事態に対応する
- ボトルネックを修正するか、回避できない問題を回避する
- ストーリーを達成できないチームメンバーに割り当てないでください（個別に、トレーニングとメンターシップから解雇に至るまで、パフォーマンスの低いチームメンバーの状況に対処するための経営陣の対応を理解します）。
これは、過去18か月間、すべてのスプリントで発生するはずの会話でした。チームにプレッシャーをかけることやリソースを追加することではなく、過去を振り返ってプロセスを継続的に改善することです。それは明らかにここでは起こっていません。
目標を逃した15回目のスプリントまでに、チームはこれについて何度も振り返って、1つの目標を達成するために可能な限り最小限のスプリントの目標を達成することを決定するまで、これについて何度も話し合ったと思います。 25回目の未完了のスプリントまでに、1つの文字列を変更するだけで、他には何も行わないでしょう。チームがスプリントでそれを管理できない場合、問題はあなたが許可するよりもさらに深刻です。
明確にするために、ここでいくつか指摘しているように、スプリントの目標は鉄のコミットメントではなく予測であり、欠落している目標自体は、不正確な予測を行うこと以外のものを示すものではありません。優れたチームは予測がよくないため、多くの目標を見逃す可能性がありますが、ひどいチームはすべての目標を達成でき、実際の価値を提供できない可能性があります。しかし、予測が同じ方向に18か月連続で間違っている場合、プロセスのその部分は機能していません。振り返りを使用してプロセスを修正し、予測がチームが各スプリントを提供できる実際の現実にかなり近くなるようにします。
「ソフトウェアは、それが終わったときに、すぐにでも、遅くとも行われません。」
これは本当ですが、開発者が作業を開始する各タスクについて、組織内のeverybodyは各タスクの完了の定義？
最大の問題の1つはEstimationのようですが、開発者は、明確で明確な「完了の定義」がある場合にのみ、現実的な見積もりを提供できます'。 （これには会社のプロセスの問題が含まれます-たとえば、ユーザードキュメント、正式リリースの作業パッケージなど）
ほとんどの開発者は、タスクの完了に必要な時間を見積もることが最も難しいことを理解しているため、過大評価が問題を引き起こしていることは当然のことです。
ただし、ほとんどの開発者は、努力の量を合理的に（ただしoptimistic）処理します与えられた期間、置くことができます。
多くの場合、問題は、開発者がタスクとtotal不完全な情報を扱うときに必要な労力との関係を作成するのに苦労していることです-特に彼らは、本当に大きな仕事に対するすべての答えを事前に思いつくように迫られています。
これは当然、時間の見積もりを現実から切り離してしまい、ビルドプロセスやユーザードキュメントなどを見失います。
切断は、タスクが説明されている最初の部分から始まる傾向があります。そしてそれは通常、技術者ではない人が、必要な労力の手がかりを持たずに要件のリストを作成することによって悪化します。
上級管理職の人々がタスクを指定し、会社のプロセスの問題を完全に無視することがあります。上級管理職が、テストの定義、正式なリリース済みビルドの作成、ユーザードキュメントの更新などを時間や労力をかけずに魔法のように行われると考えることは珍しくありません。必須。
誰かがどこかで作業を正しく行っていないために、開発者がコード行を書く前にプロジェクトが失敗することがあります。
開発チームが要件の合意や受け入れ基準の取得に関与していない場合、それは管理の失敗です。これは、コードと技術的な問題を十分に理解していない人がビジネスを要件の不完全なセットにコミットしたことを意味するため、そして、プロジェクトを誤解、スコープのクリープ、金メッキなどに開放したままにしました。
開発チームが要件の取得と同意に関与している場合、詳細（および承認基準）を明確にする責任があるチームの失敗である可能性があります。つまり、「成果物はどのように見えるのですか？いつdone？ "）。開発チームは、[〜＃〜] no [〜＃〜]と言っても責任があります途中で他のブロッキングの問題がある、または要件が非現実的である場合。
したがって、開発者が要件の取得に関与している場合：
- チームには、製品マネージャーと一緒に座って、完了の要件/定義を明確にする機会がありますか？
- チームは暗黙的/想定される要件を明確にするために十分な質問をしますか？これらの質問はどれくらいの頻度で満足のいく答えが返されますか？
- チームは見積もりを提供する前に受け入れ基準（完了の定義）を要求しますか？
- 通常、各タスクの合格基準はどの程度適切に取得されていますか？それはまばらな詳細のあいまいなドキュメントですか、それとも具体的な機能、および開発者がテストに明確に変換できる表現を記述していますか？
おそらく、チームの生産性は問題ではありません。あなたのチームは開発に関しておそらくチームが投入できるすべての努力を投入しています。実際の問題は、次の1つ以上である可能性があります。
- 不完全で曖昧な要件。
- そもそも大きすぎる要件/タスク。
- 開発チームと上級管理職の間のコミュニケーション不足。
- タスクがチームに渡される前に明確に定義された受け入れ基準の欠如。
- 受け入れテストの不完全またはあいまい/あいまいな仕様。 （つまり、完了の定義）
- 許容基準の定義/同意に割り当てられた時間の不足。
- 開発者は、既存のベースラインコードをテストしたり、既存のバグを修正したりする時間を考慮していませんでした
- 開発者は既存のベースラインコードをテストしましたが、要件の見積もりを提供する前にBlocking Issuesとしてバグを発生させませんでした
- 管理者は問題/バグを確認し、新しいコードを書く前にバグを修正する必要はないと判断しました。
- 開発者は時間の100％を占めるようにプレッシャーを受けていますが、おそらく時間の20％（または同様の数）が会議、気晴らし、電子メールなどで占められています。
- 見積もりは額面どおりに合意され、誰もエラーや不測の事態の余地を調整しません（たとえば、「これには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％と予想されます。
アジャイルとスクラムの背後にあるアイデアは、プロセスを測定できるように、タイトなフィードバックループを構築することです。完全に故障したように見えるので、「どこで故障したのか」と尋ねる必要があります。
- 何をするかを計画し、そのリストを作成します
- これは、完了する必要のあるアイテムのバックログからアイテムを選択することで構成する必要があります。スプリントのTo Doリストに何かが引き込まれる前に、チームは、それを完全に理解し、スプリントが完了するまでにかかる時間はおおまかに見積もることに同意する必要があります。
- 理想的には、バックログは（ビジネスに対する）優先順位で並べられ、優先順位でプルすることができます。
- バックログのアイテムが大きすぎる場合は、それらを小さなチャンクに分割します。その後、チャンクを1日以内に完了することができる個別のタスクに分割します。
- この計画が簡単または迅速であるとは期待しないでください。
- リストのアイテムを定義された期間実行します（スプリント）
- 達成したことを確認します
- どんな物語が終わったの？
- ストーリーが完成しなかった場合、ストーリーを構成するどのタスクが終了しましたか？
- タスクが完了していなかった場合、先週の月曜日に誰が正確に何をしたのでしょうか。先週の火曜日など-この時点で、厳しい内省の時間です...
問題のトラブルシューティング（フィードバックの分析と適応）
- 完成したものはどのくらいかかりましたか？
- タスクが完了しない原因は何ですか？
- チームメンバーは、ストーリー（機能）を1日以内に完了することができるタスクに分解していますか？そうでない場合は、これを実行して、タスクリストの一部にします。
- スプリント中にタスクリストまたはタスクリストのアイテムにどのような変更が加えられましたか？これが終了しない原因でしたか？もしそうなら、リストや機能を変更しないでください。変更された機能が安定するまでバックログに投げます。
- いくつかのアイテムのサイズとスコープを、スプリントで完成できるものにどのように縮小できますか？ロギングの改善、単純なバグ修正、タイプミスなどの小さなものを選択して、チームが何ができるかを判断できるようにするためにいくつかのことを完了します。これを実行できない場合は、スプリントを停止して再計画を実行します。
手順1に戻り、リリースまで繰り返します...
文書化の障害、依存関係を作成する結合の問題、通信の問題、要件に十分な情報がない？...何ですか？開発者は新しいテクノロジーを学ぶために時間を費やしましたか？彼らは設計に膨大な時間を費やしましたか？スプリントタスクリストでは学習などが考慮されましたか？
あなたのチームは、各回顧展で問題を切り分けたと思いましたか？チームは問題を修正するために行動しましたか？チームは応答せず、経営陣は単にソリューションと行動方針を指示しただけでしたか？
長い期間を考えると、単に開発者だけでなく、何かが体系的に間違っています。ある時点（1年が経過する前）で、チームの誰か（スクラムマスターを含む）が、どんなに小さくても、canで何を達成したのか尋ねる必要がありましたか？
スクラムはいくつかのことを行います。
まず、優先順位付けを促進します。仕事の供給者は彼らが最初に何をしたいのかを言わなければなりません、そして「すべてが等しく重要である」とは言いません。
第二に、すべてが終わっていなくても、多少使いやすい製品を生成します。これが、各反復の最後に「出荷可能な製品」があることのポイントです。
第三に、それはより厳しいフィードバックループを提供します。スプリントの最後に物事が「完了」すると主張することで、「90％の機能は完了しているが、半分しか完了していない」という問題を回避できます。締め切りを迫るときは、やらなければならないことをしのぐことができるので、締め切りに近づいているように見えたり、偽造したりできます。完了の定義を持ち、完了を主張することで、何かが後ではなく先に見えるよりも難しいかどうかがわかります。
第4に、詳細な計画を作業に近づけることによって在庫を回避します。遠くのものを計画することは、在庫の一種です。つまり、顧客が販売したり、顧客がすぐに使用したりできないリソースに費やされた資本です。そのような在庫は腐敗し（計画は足元で変化し、新しい情報により陳腐化する）、ニーズとの整合性が失われ（分散ネットワークwhatzitは必要ないことが判明しました。それを使用することには価値がなかったためです）、出荷された商品の価値が低下します。 （昨年にあなたの時間の半分が来年以降の計画に費やされた場合、代わりに現在準備ができているものに取り組んだ場合、2倍の出荷を得ることができたでしょう）。計画を無駄なく実行に近づけることができれば（トリッキーです！）、在庫を減らすことができます。
これらの問題を解決する唯一の方法ではありません。あなたはスクラムを使用しているようですが、スクラムを使用して、開発者に一定期間ごとに取り組む作業の流れを提供し、定期的に新しい作業を追加して、進行状況を確認します。
これはスクラム風のパターンを使用する便利な方法です。作業の流れを維持し、本番環境に近い計画を維持し、フィードバックループを提供します。システムに一致するように開発とテストを歪めないという利点もあります（作業でテストを行うのが最善の場合、基本的には完了です） 、同じスプリント内で物事を完成させてテストしようとすると、スプリントのバックエンドが新しい開発に関与しなくなります！）
彼らがやろうとしていることを正確にスプリントに入れられなかったとしても、開発者が素晴らしい仕事をしていないという証拠にはなりません。これは、フレームワークの一部を使用する代わりに、SCRUMを高いレベルからフォローしていないことを意味します。
彼らが各スプリントにどれだけコミットしたかを半分にした（または4分の1にした）が、他のすべてを同じに保った場合、彼らは各スプリントにコミットしたよりも多くを終えたでしょう！同じ量のコードが生成されます。明らかに「スプリントの失敗」は重要な部分ではありません。これは内部プロセスの詳細にすぎないためです。会社の目標は、たわごとを成し遂げることであり、そのたわごとは良いことです。あなたの目標が特定の種類のISOプロセス認証でない限り、特定のプロセスに従わないこと。
プロセスは、実行された処理の目標に沿って存在します。
一方、それらはSCRUMのルールに従っていないため、同じkindのフィードバックを得ることはできません。生成された欠陥の種類が、SCRUMが対処するように設計された欠陥であるかどうかを確認するために、結果の内容を調べる必要があります。ゾンビのように永遠に生き続け、途中で殺されるだけの話はありますか？簡単に見える、爆発する、そして総作業に値しない回顧的な物語はありますか？商品は実際に発送する必要がある/発送したいときに発送できますか？
あなたの状況では、回顧は遅すぎます。
あなたは、毎日のスタンドアップミーティングを開催し、過去24時間に彼らがしたことについて人々から本当にステータスを得ていますか？
スクラムマスターは、これらの会議を使用して、各開発者の目標に対する進捗状況を測定していますか？
その進行状況を監視するには、スクラム方法論のその部分を使用する必要があります。それは人々が何をしているのかについてあなたに良い洞察を与えるはずです。
彼らは注意散漫ですか？コーヒーに費やしたり、SE/SOで他の人を手伝ったり、ニュースを読んだり、説明されていない検査を行ったりするのに時間をかけすぎていませんか？それとも、彼らは本当に頭を下げて、完全にスチームで完全にコミットされていますか？毎日のビューはあなたに良い考えを与えるはずです。また、開発者が目の前のタスクに集中できるようにするのにも役立つため、昨日何もしなかったと認める必要はありません。
そしてもちろん、彼らがスプリント全体を通じて着実な進歩を報告し、それでも最後に配信しない場合、彼らは嘘をついており、新しい開発者の時間になるかもしれません。
プログラミングコードなどの複雑なタスクを完了するために必要な労力と時間を見積もることは困難です。 Joel Spolsky は次のように記述します。
ソフトウェア開発者は、スケジュールを作成することをあまり好みません。通常、彼らはそれなしで逃げようとします。 「完了したら完了します！」彼らは、そのような勇敢でおもしろいジンジャーが上司をクスクス笑いに陥らせることを期待しており、その後の陽気さの中で、スケジュールは忘れられるでしょう。
ただし、企業が事業を行うには期限が必要です。 Joelが示唆したように、 Evidence Based Scheduling を使用してみてください。これにより、関連する確率で時間の見積もりが得られます。この管理は、あらゆるタイプのリスクとして関連付けることができます。
ああ、そうですね、私たちは遡及的なものを使っています。
ああ、それであなたは知っていますなぜあなたのチームは正しく失敗していますか？何が機能し、何が機能しなかったかについて話す機会が36回あったので、スクラムマスターは問題を解決する方法を完全に理解する必要がありますよね？
貴方の説明によると、貴方の会社は「スクラムが私達を生産的にする」という考え方に陥っているという予感があります。 実はSCRUMはあなたの生産性を高めません。むしろ、それはあなたがあなた自身を現実を識別する方法で生産性を高めるのを助けるツールです管理者と開発者の両方から見過ごされがちな開発の例です。
スクラムマスターはチームの潜在的な問題として何を識別していますか？彼らは常に、処理できる量の2倍の作業を割り当てていますか？もしそうなら、スクラムマスターはチームの速度を見ることができるので、スクラムマスターは彼らがより少ない仕事を引き受けることを優しく提案するべきです。
開発者の質の問題を探すのはいつ公平ですか？
開発者の質の問題を探すべき時は、問題であると確信している瞬間です。これはSCRUMが作成した新しい問題ではありません。これがビジネスの現実です。 SCRUMは、従来のアプローチよりもチームメンバーの機能についてvastlyより多くの情報を提供するはずです。 問題が「ソフトウェア開発者は十分ではない」か「管理の期待は非現実的」であるか、従来のアプローチで理解するよりもはるかに優れているかどうかを知る必要があります。これは経営陣が最も得意とすることを行うための経営陣：会社がお金を稼ぐことができるように、仕事に適した人を見つけます。問題がどこにあるのかわからない場合は、これらすべての回顧なしに語るのがどれほど難しいか想像してみてください。
人々が十分かもしれないと思うなら（彼らの雇用が経営陣の側の間違いではなかったことを意味します）、私のアドバイスは枠の外で考え始めることです。作業が完了していない場合は、開発者の作業の形を変更することを検討してください。スプリントの完了期限を設定するために私が見つけた最も簡単な方法の1つは、DONE基準を調整して、どのように実行されても結果に満足できるようにすることです。したがって、完了することはトートロジーになります。
これにより、管理、特にSCRUMマスターに負担がかかります。 トリックは、完了した場合に非常に貴重なタスクを記述することですが、未完成のままでも、給与に見合うだけの十分な付加価値を会社に提供します。 18か月後、私はあなたに期待します何かを教えてくれた回顧展。そうでない場合は、失敗したストーリーが会社の問題を発掘し、それを明らかにするという明確な意図を持ってストーリーを書く必要があります。これは、会社が開発チームに対してどれほど苛立ちを感じているかを考えると、会社に計り知れない価値のあるデータを提供するでしょう。あなたが尋ねるように、問題は実際に開発者であるかもしれません。または、問題はあなたが今まで知らなかった会社の考え方の病理かもしれません！
実際に問題が開発者ではなく会社にある場合、これらの不完全なストーリーから収集した情報は、実際に成功したものから収集した製品よりも価値があるかもしれません！それは会社全体を救う情報かもしれません！これは私にとって非常に貴重な情報のようです。SCRUMを収集に役立つツールとして使用できます。
「ソフトウェアが完了すると、すぐにでも、遅くても」は、「完了」がどのように見えるかを定義していない場合の失敗のレシピです。
ほとんどのエンジニアは可能な限り最高のソリューションを作成しようとしますが、これは特に経験の浅いエンジニアの場合、簡単に金メッキにつながる可能性があります。管理のonly責任は、目標がどこにあるかを正確に定義し、エンジニアがその方向に向かっていることを維持することです。エンジニアは機能を改善するために副旋削を頻繁に試みます。その副旋削が長期的に物事をスピードアップするか、それとも単に改善と同じように改善するかを決定するのは経営者次第です。
アジャイル開発のポイントは、新しい作業のそれぞれが、そのスプリントに対応するために必要なだけ優れていることですAND NO BETTER !!!!!!はい、それはStackOverflowで追加できる最も重要な点です。それでもまだ十分ではありません。人々が不要なものを追加していることがわかった場合right this second次に、アジャイル開発を正しく行う方法に関するトレーニングが必要です。
すでにいくつかの優れた答えがあります。特に、不適切な見積もり、過剰なコミットメント、および/または予定外の作業は、スリッページの頻繁な原因です。
しかし、「[あなたの]開発者が各スプリントに組み込みたい機能を選択する理由」に興味があります。通常、開発者は優先度が最も高い機能に最初に取り組んでいる必要があります。優先度はビジネス上の決定です。つまり、製品の所有者がビジネスの利害関係者の代理として機能する必要があります。
（これには例外があります。特に、リスクの高い機能は通常、以前に機能します。また、場合によっては、ユーザー向けの機能が他の機能に依存することもあります。たとえば、「実際にデータベースを追加する前に、 X "を実装できます。）
一方、見積もりは技術的な決定であり、ビジネスマンがnotを行う（または2番目に推測する）必要があります。あなたはこれについて何も言わない-私の経験では、開発者が何をすべきかを選択しているとき、ビジネスマンがそれがかかるべき時間を指示しようとすることはかなり一般的だからです。
かなり機能不全のプロセスがあるようです。少なくとも当面は開発者コンサルタントを招くことはお勧めしません。それはおそらく士気にマイナスの影響を与えるからです。しかし、あなたの組織はプロジェクト管理の面でいくつかの助けを使うことができるように思えます。中長期のエンゲージメントではなくても、少なくとも評価または「ヘルスチェック」のために、経験豊富なアジャイルコーチを連れてくることから始めます。優れたコーチは、パフォーマンスの悪い開発者がいるかどうかを教えてくれますが、少なくともこの方法では、監視されているのはチーム全体（開発者だけでなく）です。
もう1つの観察：私の経験では、優れた開発プロセスに従っていない場合、プロジェクト管理方法論としてスクラムを成功させることは非常に困難です。自動ユニットテストを行っていますか？またはさらに良い、自動受け入れテスト？あなたの開発者はペアリングしていますか、それとも少なくとも頻繁なコードレビューやウォークスルーを実行していますか？何らかの形で継続的な統合を実践していますか？
「開発者の質を見ることはいつ公平ですか？」
いつも。明らかに一部の人々は他よりも生産的であり、あなたは彼らのパフォーマンスを測定するために彼らの雇用主としての言い訳を必要としません。
トリッキーなビットは、それをどのように行うかです。私のアドバイスは、いくつかの経験豊富な請負業者を雇って、パーマ担当者が見積もった同じタスクセットでパーマスタッフと一緒に働き、彼らがより高い速度を持っているかどうかを確認することです。
これにより、長期的な雇用に縛られることなく、現在の市場との優れた比較が可能になります。
それはまた、パーマの人にちょっとしたキックを与えるかもしれません。
さらに、請負業者が速度を上げるために品質などをスキップしていると文句を言うと、ビジネス価値がどこにあるかについての話し合いが促進されます。長期保守性または短期製品が出荷された。
それが長期的なものである場合は、それを定量化し、要件としてスプリントに置く必要があります！