Sprintの仕組み
私はITのバックグラウンドではありません。アイデアが生成され、現在作業中です。最初はウォーターフォールの方法論から始め、現在はアジャイルを使用しています。このアジャイル方法論がどのように機能するかを正確に理解したい。私の質問を間違った方法で考えないでください。入力のリクエスト。
以前はなかったスプリントの間にバグが見つかりました。これは、現在のスプリントに追加されている機能が原因で発生した可能性があります。今、POは同じストーリーを書き、次のスプリントまで待つ必要がありますか？
すべてのスプリントは、追加された新機能に起因して発生する/発生するバグを処理する能力を想定して作成する必要がありますか？チームはバグを回避するために注意を払う必要があることを理解しますが、ここでの解決策は何ですか？
スプリントで取得されたバックログは完了せず、次のスプリントに繰り越されます。これがアジャイル方法論がどのように機能するかを考えると、POまたは誰も何も言うことができません。それは本当ですか？
まず、方法論を特定していません。アジャイルは、物事を行う一種の方法であり、哲学です。そのため、「これまたはそれを行うべき」というものはありません。
あなたはスプリントで働きたいです。これはあなたがあなたの努力をタイムボックス化していて、あなたはそのタイムボックス内でできることをすることを意味します。スプリント内では、行った作業のバグをテストして修正できるようにするのが賢明です。
さて、スプリントが完了した後、またはさらに古い変更のためにバグが見つかる時が来るでしょう。これらのバグについては、いくつかの選択肢があります。まず第一に、バグの影響を評価したいと思います。許容できる回避策がある場合、または影響が少ない場合は、スプリントでこのバグを修正することを計画できます。
影響が大きく、許容できる回避策を考案できない場合は、おそらくできるだけ早く修正する必要があります。私が行う方法は、必要な容量をスプリントから取得してバグを修正することです。次に、そのスプリントから提供できるものに与える影響を受け入れます。
バグの複雑さと必要な時間に応じて、次のスプリントで適切に修正できる場合は、最初に回避策を構築することを検討してください。
バグのユーザーストーリーを書くことに関しては、バグを報告したか、ユーザーから報告を受け取った人が、その時点で再現パスと予想される動作を報告してくれるので、POが実際に何かを書く必要はないでしょう。
覚えておかなければならないことは、スプリントの目的は、締め切りを設定し、それを達成するのを助けることです。
基本的には、「機能」をどれだけ迅速にプログラムできるかを考えています。次に、機能のリストを取得し、この「速度」を掛けて、「この日付までに完了する必要があるため、ソフトウェアのコストはXです」と言うことができます。
スプリントの開始時に、一連の機能を使用して、「そうですね、1つのスプリントでこれらを実行できることを確認します」と言います。スプリントの最後に、「うーん、見積もりでX％ずれているようです。次回はそれを考慮して、遅れる可能性があることを顧客に伝えてください」と言います。
個々のタスクではなくスプリントに物事をグループ化する理由は、機能をプログラミングするときに機能間に多くの相互作用があるためです。プログラムして推定するときに、それらを一緒にまとめるのが簡単です。
スプリントに何かを追加または削除する場合は、番号を破棄して期限を延期します。時々、何かがあなたが打撃を受けなければならないほど重要になるでしょう。しかし、可能であればそれを避けるべきです。
一部の人々は、計画外のもののためにx％を無料のままにしますが、私の見解では、それは実際には機能しません。見積もり計算にフィドルファクターを追加するだけです。 「ああ、すべてをやり遂げたわけではありませんが、それは予想よりも多くのバグがあったからです。」まあでしたか？あなたは本当に言うことができません。
発生する可能性のある最悪の事態は、進行中のスプリントに常に物事を追加したり削除したりすることです。そのため、見積もりが適切であるかどうかは本当にわかりません。締め切りが近づくと、当初計画されていた機能がまだたくさんあることに気づきます。
それまですべてのバグを残しておく方がはるかに簡単で、既知のバグのセットは限られています。少なくともあなたは既知の量だけオーバーランするでしょう。
バグの発見と修正の間の遅延が心配で、それが長いものになる可能性がある場合。最善のアプローチは、より短いスプリントを行うことです。 2週間のスプリントは、バグ修正がリリースされる4週間前を意味します。 1週間のスプリントは2週間を意味します。順番に大きな違いがあります。