以前のスプリントでタスクが実行されていない場合のスプリント計画の支援が必要
私たちのチームには専用のスクラムマスターがいないため、開発者の1人がSMの役割を果たしています。これは間違いですが、変更することはできません。
このシステムでは、グルーミング時にすべてのストーリーにストーリーポイントを割り当てます。制作の問題にはストーリーポイントはありませんが、3ストーリーポイントであると仮定します。私たちにとって、1ストーリーポイントは1日です（これも変更できません）。
スプリントの計画方法は次のとおりです。最初のスプリント中に、チームメンバーの個々の能力（75％など）に基づいて、ストーリーと制作の問題を配布します。
次のスプリントの計画中に、最初のスプリントのアイテムが残っている場合は、いくつかの調整を行います。 8ストーリーポイントのストーリーがあり、開発者が最初のスプリントですでに5日間費やしている場合、3日分の作業しか残っていないため、開発者の能力から3日を削減します。
これが正しいかどうか、またこれがバーンダウンチャートやベロシティチャートにどのように影響するかはわかりません。生産の問題にはストーリーポイントがないためです。また、内部の問題が前述のチャートにどのように影響するかわかりません。
また、スプリントのレビューはいつ行うべきですか？その目的は何ですか？
私たちの実践についてのコメントや、それをどのように改善できるかについての提案はありますか？
私の最初の提案は、社内外のコミュニケーションを改善するために用語を修正することです。 「スクラムマスター」、「スプリント」、「スプリントレビュー」などの用語を使用しています。これらはスクラムからの用語です。スクラムは特定の役割、責任、イベントを備えた明確に定義されたプロセスフレームワークです-ルールがあり、それらのルールは スクラムガイド で定義されています。スクラムを使用していない場合は、自分が何をしているのかをスクラムと呼んではならず、人々を混乱させるだけなので、スクラム用語を使用しないでください。注意してください-スクラムを使用しないこと、またはスクラム（または他のプロセスフレームワークや方法論）から良いアイデアを取り入れて独自のプロセスを構築することは完全に問題ありません。
次に、あなたの見積もり方法を見てみましょう。専門用語に戻りますが、「ストーリーポイント」と呼んでいることをやめることをお勧めします。スクラムと同様に、 「ストーリーポイント」の一般的に受け入れられている定義です であり、一定の時間ではありません。とはいえ、時間の見積もりがうまくいっている場合、またはそれらを使用する必要がある理由がある場合は、引き続き使用する必要があります。
イテレーションを計画するとき、3つのことを考慮します。最初に、チームの総容量を検討します。専門家がいる場合は、クロストレーニングに取り組み、チーム全体のキャパシティー見積もりを有効にするために1人で行う必要のある作業はほとんどないようにします。見積もるときは、専門家ではなくチームの平均的なメンバーが作業を行うことを考慮しないでください。専門家がそれを理解すれば、おそらくそれはより早く完了するでしょう。他の誰かがそれを取得した場合、あなたはあなたの見積もりに近づく可能性が高くなります。最後に、100％の容量で計画を立てないでください。常にオーバーヘッドがあります-休暇、予期しない休暇、会議。私は情報源を見つける必要がありますが、最も生産性の高い組織は約80％に達し（推定スキームを使用します。つまり、計画された休暇や休日がないと仮定して、1人あたり1週間に4つの「ストーリーポイント」です）、多くの組織はより近いです60〜70％（1人あたり1週間の反復で3 "ポイント"）。一般的な経験則では、すべての作業は1回の反復で完了できるはずなので、1作業単位は2週間のスプリントで6「ポイント」を超えないようにする必要があります（これは、約65％の容量を占めます）人-かなり平均的な組織）。計画するときは、生産の問題のために容量の一部を残すことを検討してください。履歴データを使用してこれを把握できます。
追跡指標の場合、一貫している限り、何をしてもかまいません。本番の問題を見積もらない場合、1人以上の人が見積もりの計画された問題に取り組み、本番の問題に取り組むときに、バーンダウンが一時停止する可能性があります。生産の問題を見積もると、残りの作業が増加し、作業が進むにつれてバーンダウンします。どちらの場合も、計画されたバーンダウンラインを更新しません。私の個人的な好みは、ほぼすべての作業（新機能、変更された機能、製品に対するバグ）を見積もることです。見積もらない唯一のことは、作業をやり直す必要があるかどうかです（例-作業は開発中に終了しましたが、独立したテスターによってバグが見つかりました-それらのバグが追跡システムに記録されていても、見積もることはしませんバグが本番環境にリリースされない限り）。また、本番環境の問題にデフォルト値を指定せずに、チームに各自の妥当な見積もりを出すように依頼することもお勧めします。
再推定についても、一貫性があれば問題ありません。私の推奨は決して再推定しないことです。作業が1回の反復で完了しなかった場合は、次の反復を計画するために、元の見積もりが保持されます。プロジェクト管理では、完了したタスクの完了に対してのみ「クレジット」を授与するのが一般的です。場合によっては、スターティッドタスクにわずかな割合が与えられます。多くの場合、実際の進捗状況を確認することは非常に困難です。修正があると思われる場合は、テストによって別の問題が発生したことが明らかになる可能性があります。
すべての反復の最後に、2つのタイプのイベントを保持する必要があります。 1つ目は、スクラムが「スプリントレビュー」と呼ぶものは、製品またはサービスに焦点を当てたものです。主要な利害関係者との成果を確認し、イテレーションで達成したことだけでなく、次のイテレーションの次の目標を説明します。 2つ目は、チームと関係者間、チームのメンバー間の相互作用を改善する方法、または作業方法を改善する方法（チームが使用するプロセス、方法、ツール）を見つけるためにチームがどのように働いているかについての内省です。 ）。
また、開発者の1人にファシリテーターとコーチの役割を演じさせるなど、なぜ変更できないのか、または他のユニットではなく時間内に見積もる必要がある理由についても調べます。ほとんどの組織には、エンジニアリングチームのプロセス、方法、および実践の理解と改善に専念する人がいることを強くお勧めします。この人は、チームと組織が動作する環境とさまざまな方法を理解し、継続的なプロセス改善の道のりで組織とチームの両方を指導することができます。
私たちのチームには専用のスクラムマスターがいないため、開発者の1人がSMの役割を果たしています。私はこれが間違っていることを知っています
これはスクラムに反対するものではありません。それは誤解です。一部のアジャイル創設者は、SMの義務をチームのメンバー間で交代させることさえ提唱しています。
ただし、変更することはできません。
これはスクラムに反対です。振り返りの全体的なポイントは、プロセスを再評価して、チームに役立つ何かにプロセスを変更することです。チームの誰もが「まあ、それはこの方法でなければならない」と考えるべきではありません。いいえ、機能しますか、機能しません。機能しないものは受け入れないでください。
アウトシステムでは、グルーミング時にすべてのストーリーにストーリーポイントを割り当てます。プロダクションの問題にはストーリーポイントはありませんが、3ストーリーポイントであると想定します。私たちにとって、1ストーリーポイントは1日です（これも変更できません）。
私の以前の応答を見てください。ポイントと時間は、速度測定を通じてのみ関連しています。これは、データが収集されてチームが過負荷にならないスケジュールを予測するときにドリフトすることを意味します。プッシュ開発者がより多くの作業を行うために使用されることはありません。開発者に1ポイント= 1日とさえ考えさせると、システムは無効になります。ポイントは、あなたが子供だったときに先生があなたに与えた金の星に近いです。
チームメンバーの個々の能力（つまり75％のみ）に基づく最初のスプリントでスプリントをどのように計画するかについて、ストーリーと制作の問題を配布します。前のスプリントのアイテムが完了していない場合、次のスプリント計画で問題が発生します。次に、8つのストーリーポイントのストーリーがあり、開発者が以前のスプリントで5日間費やしているとします。次に、次のスプリントの計画では、残りの作業が3日間しかないため、開発者の能力から3日間を削減します。
ストーリーはスプリントの内側に収まるようになっています。エピックだけがスプリントにまたがることになっています。これはさらに分解されているはずです。これが起こっている場合、何かがすでに間違っています。
もちろん、それで不完全なストーリーが発生するのを防ぐことはできません。スケジュールがずれることがあります。健康的なことは、スプリントの開始時に作業を再評価することです。あなたは敵に会いました、そしてあなたの計画は死にました。古い計画を支持しようとする開発者の空き時間をいじらないでください。あなたが今知っていることを知っている新しい計画を立ててください。
トーマスが正しく述べたように、あなたのプロセスはスクラムに少しも関係していません。
私はあなたのプロセスを改善するために2つのアプローチを提供できます：
- 既存の方法（スクラムなど）を取り入れて、実装を試みます。実際にそれを実装することによってのみ、どのような方法論が特定の方法で物事を行うのかを実際に学ぶことができます。既存の方法論を実装するには、非常に経験豊富な管理者が必要か、専門のトレーナーを雇う必要があります。
または、代わりに：
- あなたが知っている方法論を基本に分解し、手作りの方法論がこれらの基本をカバーしていることを確認してください。これらの基本は、見積もり、目標、プロセス改善、可視性、計画、コミュニケーションなどです。
おそらくおわかりのように、2）多くの方法を学ぶ必要があるため、1）必要なのは1つだけなので、難しいです。 2）会社が非常に小さく、多くの従業員がすでに多くの方法論に精通している場合、これはより簡単になる可能性があります。これは、非常に経験豊富なスタッフがいる一部の新興企業に当てはまります。
私があなたの問題を解決すると思う主なことが一つあります。
- ストーリーをタスクに分割し、開発者にタスクを事前に割り当てないでください
- タスクは1日以内にする必要があります
アジャイルは、小さな単純なジョブの非常に明確な要件で最もよく機能します。スプリントを多くのよく定義されたジョブで構成できる場合は、それらをズームして、最後に完了したジョブを1日以上影響を与えずに次のスプリントに移動できます。
複数のスプリントをロールオーバーする長いタスクはありません
もちろん言うのは言うよりはるかに簡単です。スプリントの計画にもっと時間をかけ、ストーリーの実装について話し合うことができます。仕様を100％正確にすることについてあまり心配する必要はありません。うまくいくと思うことを実装し、正しくない場合は次のスプリントにストーリーを追加して変更してください。
本番環境にバグがある場合、原因が何であるか、または調査するまでそれを修正する方法は誰にもわかりません。しかし、修正にアジャイルなアプローチを適用できるようにする、ライブの問題への標準的なアプローチの恩恵を受けるでしょう
- 製品版を最後の既知の適切なバージョンにロールバックします
- 開発者のバグの再現可能な自動テストを作成する
- 可能な修正ストーリーを計画する
- スプリント中にストーリーからタスクを開発する
- 自動テストを使用して開発者でテストする
- 修正バージョンをリリースします。
これらの各タスクは明確に定義されており、短いか、小さなタスクに分割できます。それらは明確に定義されているため、どの開発者も任意のタスクを選択できます。つまり、多くの人が同じ問題に飛びついて貢献することができます。
-編集
8つのストーリーポイントのストーリーがあり、開発者が以前のスプリントですでに5日間費やしているとします。
ストーリーが1日8タスクに分割されている場合、この状況は発生しません。あなたが得ることができる最悪のことは、あるスプリントから次のスプリントに半分完了したタスクを引っ張ったときに、半日の仕事の誤った記録です
生産の問題にはストーリーポイントがないため、これがバーンダウンチャートとベロシティチャートにどのように影響するかわかりません
生産の問題にはポイントが必要であり、私の提案に従って対処する場合、他のタスクと同様に計画と見積もりを行うことができます