スクラムにおいて欠陥をどのように扱うか

みなさんこんにちは。@ryuzeeです。

スクラムにおける欠陥の扱い方について考えてみました。スクラムでは欠陥の扱い方には特に規定はないので、以下はあくまで経験を踏まえた個人的なアプローチであることに注意してください。

欠陥の定義

欠陥とは、プロダクトバックログアイテムが「完成」した後に見つかった欠陥のみを指す
ここでいう欠陥とはソースコードのバグと要求実装の欠落の双方を指す
双方の具体的な定義や判断基準はプロジェクトによって異なる（欠陥の定義を作ると良い）
バグと技術的負債は異なる
スプリントで実装中のプロダクトバックログアイテムにおける動作不良や問題は、その時点では欠陥とみなさない
なぜなら完成の定義や受け入れ基準に従ったものを開発チームは作る必要があること、プロダクトオーナーは受け入れ確認の際に、欠陥がある場合にプロダクトバックログアイテムを受け入れるか受け入れないかを決めることができるため

対処方法

簡単に直るならプロダクトオーナーと話してすぐ直す（Jim Coplien曰く、BTSに入れている間に直るなら、とっとと直せ！）
そうでないならプロダクトバックログアイテムの１つとして扱い優先順位をつけて対応する
そして修正のサイズを見積もる
本番環境においてその欠陥によって失われる価値が大きい場合は対応のROIが高い。このROIは開発チームよりもプロダクトオーナーが判断し、それによって緊急度が決まる。緊急度が高い場合はすぐに行う
上記のような場合にプロダクトオーナーはスプリントを中止することもある
またプロダクトオーナーは開発チームに対応が可能かを確認することがある。対応が可能な場合、優先順位の低いプロダクトバックログアイテムとの入れ替えを合意することがある
欠陥の発生とその対処に備えて、予め開発チームのキャパシティから対応時間を差し引くこともある
頻繁なリリースとセットの場合、新規フィーチャー開発を行うスクラムチームと運用や軽微な改修を行いデイリーでリリースするようなオペレーションチーム（カンバンを使ったりする）に分離するケースもある
バグ修正スプリントを作ることは推奨されない。一般的にそれを元から考慮すると、スプリント単位で完成させる力の作用が弱くなる。内部品質は常に作りこみをするのが原則
付け焼刃で直さない。欠陥が発生した箇所の重要度やリスクが高い場合は自動化されたテストを追加することを考える