0

チームでワークフローを再編成しています。重要な決定の1つは、JiraとGreenhopperの助けを借りて提供されるスクラムプロセスを使用することでした。

さまざまなスクラムガイド、Greenhopperのドキュメントを読み、チームでスクラムプロセスの実装を開始しました。いくつかの修正と変更の後、それはほとんど良いですが、1つのことが私をよく眠らせません：バグ。

開発者によってさまざまな解決策が提案されていますが、それでもここで自分の道を見つけることができません。

私たちのワークフローでは、問題は4つの状態にあります：オープン->テスト中->解決済み->クローズ

開発者が自分のコードに満足すると、問題をテスト中の状態にし、QAリードに自動的に割り当てられます。QAで問題を確認し、問題がなければ問題は解決済みになります。そうでない場合-再度開きます。解決済みの状態でコードレビューが実行され、コードが安全で最適であり、開発された構造に適合している場合、問題はクローズになります。開発者が何か間違ったことをした場合-もう一度開きます。

ここで注意が必要なのは、問題（ストーリー）を再開することです。同時にバグが発生し、スプリントバックログではなく、製品バックログに到達します。スクラムウェイの開発者は、問題に取り組むことができません。スプリントバックログにありますが、コードにバグがあるか、記述が不適切であるため、同時にストーリーを閉じることはできません。

したがって、問題は、ストーリーに関連するバグがいくつかある場合でも、ストーリーを閉じる必要があり、これらのバグは今後のスプリントで修正される予定ですか？

または、関連するすべてのバグが修正されるまでストーリーを閉じることはできません。つまり、スプリントが終了しても、ストーリーのすべてのバグが修正されていない場合、ストーリーは開いたままになり、終了したスプリントから除外されて次のスプリントに移動します。ストーリーポイントは完成したスプリントで燃やされていませんか？

4

1 に答える 1

2

同様の状況にあったことで、私たちのストーリーから欠落している（または不足している）重要なことの1つは、明確に定義された（そして合意された）「完了の定義」（DoD）でした。「完了」基準を明確に定義している場合、ストーリーが完了すると（国防総省に適合）、完了します。もちろん、曖昧すぎず、品質を保証する、完了の適切な定義を定義する方法がコツになります。全員が同意し、実際に実行可能です。私にとっても、これは1回限りの演習ではありません。各回顧展で継続的に見直して、関連性があり、必要に応じて変更を加えていることを確認します。優れたDoDを設定するためのアイデアについては、 Googleを試してみてください。これを定義するために、チームが実行できる優れた演習がたくさんあります（この例のように）。

抜け落ちたバグがいつ完了するかについては、製品バックログにフィードバックし、通常どおり優先順位を付ける必要があると思います。スプリント作業に関連するスプリント中に発生するバグは、スプリントで修正する必要があります（管理者/事務処理は避けてください！）。また、多くのバグ（またはバグの数の増加）は、一般に品質に問題があることを意味し、おそらく対処すべきより大きな問題があることを覚えておいてください（おそらく終了するのにあまりにも多くのプレッシャーがありますか？）。

要約すると、堅実なDoD（量より質を促進する）を取得し、継続的に改善し、速度を落とし、「バグあり」の代わりに改善を減らし、バグが発生した場合は、製品のバックログにフィードバックして関与します。 POはできるだけ早くそれを優先します。

補足として、多くのバグを処理する場合、かんばんのようなより無駄のないアプローチは、スクラムプロセスの2週間の反復アプローチよりもはるかにうまく機能することがわかりました。

お役に立てれば？

于 2013-03-14T03:17:54.213 に答える