Scrumにおいて欠陥をどのように扱うか

 2012/04/22
このエントリーをはてなブックマークに追加

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

欠陥の定義

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

対処方法

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

 2012/04/22
このエントリーをはてなブックマークに追加

サイト内検索


著作

寄稿

Latest post: