スクラム方法論におけるスプリントに関するいくつかの質問
質問の一般的なタイトルですが、スクラム手法でのスプリントについていくつか質問があります。
ホットフィックスがスプリントの途中で発生した場合はどうなりますか。例-ウェブサイトがクラッシュするか、かなり長い間作業されていないサイトの一部がクラッシュします（クレジットカードの承認やウェブサービスなど）。それを現在のスプリントにどのように組み込んでいますか？
スプリントの最後にバグに取り組む方法。欠陥追跡スプリントを使用できることはわかっていますが、最初に計画する必要がありますか？または、そのスプリントを製品バックログに戻し、次のスプリント計画から計画を開始しますか？.
必要なスプリントの数を決定するにはどうすればよいですか？
ご協力ありがとうございました
ダーク、
1）すべてのスプリントは、あなたが言及した重大な操作上の欠陥などに対応して、いつでも停止できます。現実は、ソフトウェア開発方法論では、運用上の欠陥などの重大な問題を無視する必要はありません。もしそうなら、それは決して実装されないでしょう。
2）これはいくつかの方法で行うことができます。あなたが言ったように、欠陥追跡スプリントは物事を行う一つの方法です。現実には、SCRUMの下では、常にテスターをチームに組み込む必要があります。彼らの責任は、作業バックログの各項目のテストを作成することです。アイテムが完成したら、すぐにテスターがテストする必要があります。
現在、現代のアジャイル環境では、これは通常、継続的インテグレーション環境によって行われます。しかし、通常、これらの環境では統合テストがうまく機能しません。そこでテスターが登場します。AGain、覚えておいてください。SCRUMチームは機能横断的であるため、開発者だけでなく、テスター、CM、要件マネージャーなども含める必要があります。 。したがって、テストと欠陥の追跡/修正は通常の開発スプリント全体で行われます。
開発の最後のテストスプリントは、開発されたシステムが適切に機能することを検証し、運用受け入れテストの準備をし、運用テスト環境に展開し、システムを実行してから運用環境に展開することです。
3）製品の所有者がそれを決定し、顧客が製品のバックログを優先するときに顧客と協力してこれを決定します。実際には、一部のビジネスワンクは、流動的な日付範囲で何らかの機能を提供するためにチームにサインアップします。プロダクトオーナーはお客様と協力して、その機能を実装する程度と、各スプリントに何を含めるべきかを正確に決定します。
もちろん、スクラムマスターと開発チームは、各スプリント中に実際に何を開発できるかを決定し、これをプロダクトオーナーに伝えます。チームがプロダクトオーナーにフィードバックを提供し、その結果、課せられたタイムラインからずれてしまう場合、これを考慮してプロダクトバックログの優先順位を変更するために顧客と協力するのはプロダクトオーナーの仕事です 。
例外的な状況では、大きな生産問題のような大きな変化を処理するために、または会社が以前はバックログになかったASAPの機能を本当に必要としている場合、スプリントを変更することができます。これを処理するには、少なくとも2つの方法があります。まず、修正を取り入れて、スプリントにある最も優先度の低いコミットされたアイテムを移動する代わりに、これを行う余地がなくなったためです。もう1つのオプションは、残りのスプリントをキャンセルし、この時点で新しいスプリントを計画し、それに応じて将来の計画を調整することです。
プロダクトオーナーにとってバグはどれほど重大ですか？プロダクトオーナーは、バックログ内のアイテムの優先順位を設定するものであり、チームが次のスプリントを計画するときにバックログが最新であることを確認する義務があります。スプリントの発生中に見つかったバグについて話している場合、機能のデモンストレーションが行われたときに見つかった新しい問題と比較して、ストーリーの一部としてバグが処理される場合もあります。これは、最後にバグと見なされることもあります。スプリント。
何のためにいくつ？現実的には、新しい機能やバグが見つかるなど、チームをその領域に永続的に割り当てることができるようにするために、プロジェクトが終了することはありません。同時に、スプリントの数に関する最初の見積もりは、最初に求められたものを完了するためにどれだけの追加作業が必要であるかが明らかになる可能性がある場合、将来的に正確になる可能性は低くなります。
- 緊急修正プログラムは、スプリントの他の予期しない中断と同じように扱う必要があります。誰かが病気になっている。修正してから、通常どおりスプリントを続行します。そのスプリントでは速度が遅くなりますが、長期的に平均すると消えるはずなので問題ありません。もちろん、通常、「ホットフィックス」を行うすべてのスプリントの1日が失われるため、平均速度が低下することが判明する場合がありますが、マイルストーンをより正確に見積もることができるため、これも問題ありません。
1）消火活動またはゼロポイントバグ。
消火活動は、何かが非常に重要であるため、何があっても今やらなければならない場所です。
ゼロポイントバグは、このスプリントまたは最後のスプリントで実装されたもののために予約されており、完了したと主張されていますが、その後正しくないことが判明しました。
2）ゼロポイントのバグ。あなたがそれを完了したと主張し、そうではない場合...あなたはそれを完了させる必要があります。緊急の場合は、バグを見つけたらすぐにボードにカードを置いてください。それが大きくて延期できる場合は、他のすべての優れたストーリーと一緒に優先されるバックログの新しいストーリーになります。
3）反復の大きさを決定します。反復で実行できる作業量を計算します。製品全体のバックログを何回配信しますか？
これは継続的なことです。安定した予測可能な速度が得られ、製品のバックログを完了するために必要な反復回数を予測できるようになるまで、同じ種類の作業でチームと協力し、同じプロセスとツールをしばらく使用する必要があります。