アジャイルのバージョンが機能していません。チップ？

私は4人の開発者から成る小さなチームで働いています。私たちは、毎週同じ問題を継続的に提供していると思われるアジャイルのバージョンを実装しています。プロセスの改善に役立つ提案を探しています。

背景：

通常、2週間のスプリントを行いますが、各スプリントは作業を過小評価する傾向があり、スケジュールが遅れているため、マネージャーとトラブルを起こします。

私たちは、マネージャーが私たちのために作成したストーリーをタスクアウトすることで、各スプリントを開始します。時々彼もタスクを投入し、それらを推定します。ストーリーポイントは使用しません。ソフトウェアUrban Turtleを使用して、「スプリントを管理」します。これは、基本的に単なるストーリーとタスクであり、関連するバーンダウンです。スプリントの終わりにリリースする予定はありません。

発生する最も一般的な問題は、スプリントの開始時にタスクを計画することです。これは、スコープがはるかに大きいが優先度が高いことを発見するためだけであるため、さらに時間をかける必要があります。2番目に一般的な問題は、私たちの1人が技術的な問題に遭遇し、それが燃焼時間を遅らせ、障害を引き起こすことです。

私たちに提供された唯一の提案は、午前中のスタンドアップ中に予測を調整し、更新を提供することにより積極的になり、必要な余分な時間に調整できるようにすることです。

しかし、私たちが物事をしている方法には根本的に間違った何かがあるようです。おそらく、プロジェクトレベルでのマネージャーの期待とスプリントレベルでの期待との間には断絶があるでしょう。プロジェクト計画に従ってこれらのスプリントの反復を行っているため、スプリントを延長したりアイテムを延期したりすると、プロジェクト計画が台無しになります。そのため、開発者として、必要に応じて見積もりを延長することでアジャイルを実行することをお勧めしますが、スプリントを時間通りに完了させることは混乱を招きます。

これはめったにない問題ではないので、スプリントごとにこの同じ問題にぶつかるのをやめる方法について、提案が1つまたは2つあるよりも賢明なことを望んでいます。イライラします。

予定より遅れているから

この種の思考はあなたの問題です。あなたはスケジュールに遅れていません、スケジュールがきつすぎます。数時間ではなく抽象的なポイントでストーリーの推定を開始し、2〜3回の反復で速度を把握する必要があります。ベロシティは、反復ごとに通常行うポイント数であり、マネージャーが適合させたいポイント数ではありません。

この後、タスクを一貫して過小評価しているかどうかは関係ありません-速度はすでにそれを考慮しています。

明らかに、ポイントではなく時間を使用する場合、これは不可能です。

問題は、チームが正確な見積もりを行うことができないこと、および必然性が生じる問題を予測できないことのようです。

小さなタスクは、大きなタスクよりも正確に推定するのがはるかに簡単なので、タスクをはるかに小さなチャンクに分割してみてください。

誰がどのようにそれをしようとしているかを正確に知っていない限り、誰にもどんなタスクの見積もりもさせないでください。開発者が何を完了するべきかわからないタスクについては、このスプリントのスケジュールに時間をかけて開発者が調査と設計を行い、正確な見積もりを出します。半日以上になることはありません。しかし、タスクを次のスプリントに移してください。それから、次のスプリントの計画を立てると、適切な見積もりが得られます。この余分な時間は無駄ではないことに注意してください。それは、開発者がいずれにせよ最終的に支出する時間だからです。

また、プロジェクトマネージャーに戻って、タスクのリストを取得するにはスプリントがさらに必要になることを伝えることを恐れないでください。不可能なターゲットにコミットするよりも、それを行う方が良いです。

時間の100％を割り当てようとしていますか？もしそうなら、それをやめる。スプリント中にチームが貢献しなければならないすべての時間を合計することから始めます。これを行うには、各作業者がせいぜい1日6時間をプロジェクトに費やすと想定します。これは「理想的な日」と見なされます。他の2時間？会議、休憩、管理タスク、午前中にメールを読んで1日を計画している時間などに夢中になります。これは「賭けのヘッジ」や「サンドバッグ」ではなく、現実的です。

次に、1日6時間に80％を掛けます。どうして？なぜなら、人間はタスクにかかる時間を予測するのが面倒だからです。これは、判断の誤りを説明しています。繰り返しますが、サンドバッギングではなく、現実的です。

これで、タスクに直接適用すると思われる現実的な時間数を表す数値が得られました。見積もりをするときは、次のストーリーがあなたを圧倒するとき、ストーリーの追加を停止します。

最後に、製品の所有者にタスクを追加させないでください。スクラム計画はチームのためのものであり、POはチームが作業を行う部分ではありません。もちろん、現実の世界では、POがチームの誰よりも知識が豊富であれば、彼女の入力は非常に役立ちます。それでも、チームが遅れをとるために熱を帯びている場合、チームは彼らが行うタスクを正確に所有する必要があります。あなたの目標は、受け入れ基準を満たすことです。タスクがそれに直接つながっていない場合、それをしないでください。

スクラムは生産性を高めることではないことを忘れないでください。それは、よりオープンでコミュニケーションがとれることです。仕事には、成し遂げるために必要なものは何でもかかります。スクラムは、見積り、利害関係者とのコミュニケーション、チームのコミットメントを容易にするためのものです。

スプリントの開始時に受け入れ基準が不十分に定義されていますか？

ストーリーカードは、見積もられた場合に受け入れ基準（ある場合）が低いため、最初の見積りが低すぎることがよくあります。チームがカードとは何かを明確にするために、受け入れテスト駆動開発（ATDD）別名ストーリーテストに移行するのはどうですか？

ストーリーが大きすぎる？

ストーリーが予想よりも長くかかることをスプリント中に発見するもう1つの理由は、ストーリーが大きすぎることです。フラッシュフラッシュカードデッキでアジャイルを見たことがありますか？「Shrink XL stories to Fit」というフラッシュカードがあります。エッジケースの延期、副作用、機能的でない側面、エラー処理などのストーリーを分割する戦略を後のストーリーに提供します。

十分な情報がないため推定できませんか？

@sleskeはスパイクについて良い提案をします。推定時に技術的な未知のものを特定してください。ある場合は、ストーリーを後のスプリントに延期できるかどうかを確認し、代わりにこのスプリントをタイムボックス化された調査（スパイク）して、推定に必要なものを試してみてください。夢中になって元のストーリーを解決しないでください-スパイクは、ストーリーを推定するのに十分知っているときに行われます。

より速く失敗する

そして、@ Patrick Hughesに同意します。問題をより迅速に確認できるように、1週間のスプリントに移行することを検討してください。

@Kevinと@Patrickによる良い提案に加えて...

アジャイルのアプローチは「1つのサイズですべてに適合する」わけではありませんが、このコメントは私の注目を集めました。

アジャイルのバージョンを実装しており、同じ困難を継続的に提供しているようです

「本による」方法論から始めた方が良いでしょう（最近ではスクラムが支配的と思われます）-そして、他の成功したチームがやったことを正確に実行してください...ローカル条件に最適化するために必要な変更。

経験豊富なスクラムコーチを（数回繰り返して）借りることは、本当の違いを生み出す可能性があります。アジャイルを正しく行うには微妙さがあります。

最初に、本scrum-xp-from-the-trenchesに従うことをお勧めします。26ページの速度計算に関するポイントをご覧ください。アイデアは、フォーカスファクターを定義し、次のスプリントでそれを言うことです。

利用可能な工数*焦点係数=推定速度

推定速度は、次のスプリントで実装する予定のストーリーの推定値の合計です。

そして、1つのスプリントの後、最後のスプリントフォーカスファクターを次のように計算します。

フォーカスファクター=実際の速度/利用可能な工数

ここで、実際の速度は、スプリント中に実装したストーリーの推定値の合計です。

次に、この実際のフォーカスファクターを次のスプリントに再利用します。数回のスプリントの後、スプリント中に実際に達成できる量をより正確にできるようになります...

スプリントを1週間に短縮するための見積もりを取得するまで、この方法で超過をより早く認識し、より小さな増分で反応できるようになります。

タスクを設計する際に、より多くの時間を費やして、おそらく余計な出血を引き起こしている可能性のある副作用を認識するための呼吸室を確保してください。また、タスク自体が長すぎて適切なアジャイル推定ができない可能性があります。タスクをより飲み込みやすい短いステップに分解できるかどうかを確認してください。

数時間問題に悩まされるのではなく、思わぬ障害にぶつかるとすぐに、誰もが赤い旗を送ることに安心してください。このプロセスからエゴと非難を切り離してみてください。他の人よりも簡単な人もいます=）

また、@ Kevinが提起したように、実際に100％直接タスクにスケジュールすることはありません。会議などのオーバーヘッドが常にあり、タイムイーターとして認識されない可能性があるためです。

スケジュールの面ですべてがクールになり、2週間に戻ると、再び少ない会議から少し時間を取り戻すことができます。