19

こんにちは、私はスクラムの方法論に慣れていないので、環境に慣れるための助けを探しており、展開とバグ修正と再テストに費やした開発者と QA 時間を追跡するためのバケットが必要かどうか疑問に思っています。グラフに大きな影響を与える可能性があるようです。

4

5 に答える 5

35

私のチームは多くのレガシー アプリをサポートしているため、各スプリント中に計画外のバグ修正がかなり発生します。次の方法を採用しています。

  • バグが簡単に修正できる場合 (1 つのライナーなど)、修正するだけです。
  • バグが些細なものではなく、ブロッカーでもない場合は、バックログに追加します。
  • バグがブロッカーである場合は、(現在のスプリントに) タスクを追加して、修正に必要な作業をキャプチャし、作業を開始します。これには、使用可能な合計時間は変更されていないため、新しい時間を考慮して (現在のスプリントから) バックログに他の何かを移動する必要があります。

新しいバグ タスクを追加すると、計画されたタスクとは異なるマークを付けて、スプリント レビュー中に簡単に確認できるようにします。計画外の作業がスプリントの 50% を超えることもありますが、計画されたアイテムをバックログにプッシュしているため、計画していたこのスプリントを提供していないものは非常に早い段階でわかります。

これは、私たちのチームがレガシー アプリを扱う際に非常に役立つことが証明されており、私たちの誰もシステムに慣れていないか、システムに自信を持っているとは言えません。

于 2008-10-06T20:48:10.180 に答える
10

スプリント中に発見された、そのスプリントに属するバグは、タスク/ストーリーが最初から完了していないかのように、自動的に修正される必要があります。以前のスプリントから発生したバグは、バグ バックログに入力され、通常のバックログと同様に優先順位付けされる可能性があります。

編集：「バグバックログ」に言及することで、「複数のバックログ」が開かれることに気付きましたが、これは悪い考えです。より良い方法は、バックログのエントリにバグ フラグを付けるか、バックログの他のストーリーとして受け入れることです。

スプリントの最後に受け入れられ、プロジェクト オーナーに引き渡される前に、すべてがすでにテストされているため、スプリントで発生する深刻なバグの数は最小限に抑える必要があります。

実際には、一定量のバグを修正することをコミットするため (PO の選択により - 一部のバグは新しい機能よりも優先度が低い)、バグがスプリント自体から発生した場合は、グラフに影響を与えるべきではありません。行われていなかったので、それを認識して修正に時間を費やしても問題ありません。

編集：別のことに気づきました-スクラムチームで作業しても、他のアプリケーションやサポートなどを維持しなければならないという現実から常に保護されるとは限りません。とフォーカスは実際には機能しません。現実には、サポート/メンテナンスのために週に一定の時間を予約する必要があることがよくあります。これを奨励しないでください。しかし、これが現実である場合は、サポートの役割に専念する一定の時間を毎週 1 人の担当者に割り当てるようにしてください (ローテーションで、彼が悲しくならないようにします)。このように、速度は相対的であるため、何が期待できるかがわかります。スプリントへの影響が小さいように見えます。

于 2008-10-06T18:00:18.397 に答える
1

問題を診断する前にバグ修正の労力を見積もるのは難しいと思います。診断は、多くの場合、費やされた時間の大部分を占めています。

バグの量がかなり一貫している場合は、速度に対して「ウォッシュで出てくる」ようにします。これは、チームの反復目標に影響を与える生産上の欠陥に対して私が通常行うことです。

バグの問題が原因で、反復の途中で遅れていることに気付いた場合（たとえば、反復の終わりまでにスコープの線と交差するように見えないバーンアップチャートが表示された場合）、スコープを適応させることができます（余分な作業に対応するために、最も優先度の低いストーリーを削除します。

于 2008-10-07T15:31:55.760 に答える
1

私がこれを処理する方法は、バグ修正をスプリントの外に移動することです。したがって、3 週間のスプリントの後に、デモ/リリースの前に 1 週​​間のバグ修正が続く場合があります。

ただし、バグ修正フェーズで修正されるバグの数を推定する試みは行われないため、これは理想的なソリューションではありません。ですから、他の人が私よりも優れた解決策を提供してくれることを楽しみにしています。

于 2008-10-06T17:45:08.490 に答える
0

各スプリントには 2 つの「タスク」があります。1 つは現在のスプリント (未出荷のコード) で見つかったバグ、もう 1 つはその他 (出荷されたリリース) で見つかった問題です。これにより、(開発者ごとに) バグ修正にどれだけの時間が失われたかを追跡できます。

後者のカテゴリーに記録された時間はすべて無駄と見なされ、削減の重要な目標です。前者に記録された時間は、それを引き起こした機能と変更にどのように密接にリンクできるかについてレビューされます。

バグに対して見積もりをするのではなく、作業中の機能に対する単体/機能テストの見積もりにその時間を追加するようにしてください。

チームの働き方に合わせて任意のモデルを自由に適応させてください。どのスクラム チームにも継続的な改善の文化が存在する必要があり、開発者はスクラムを学ぶときに改善を提案し、試すことができる必要があります。

于 2008-10-06T18:52:14.093 に答える