「塹壕よりScrumとXP」その後とテスト自動化順序の決め方

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

「塹壕よりScrumとXP」はHenrik Kniberg氏が書いた無料書籍で、日本語を含めて13ヶ国語で読まれている最も有名なScrumとXPに関する導入事例の1つである。 日本語訳はInfoQの以下のページからダウンロード可能だ。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches

そのHenrik氏が、Agile Israele 2011で行ったキーノートが、非常に良いものなのでご紹介。 なお、資料は氏のサイトからダウンロードできる。

このスライドでは、Henrik氏がもし記事を書いた2006年に戻ったら今度は違うやり方をするであろう項目について説明している。 項目は以下の15個だ

  1. キューを制限する
  2. チーフプロダクトオーナーのロールを設ける
  3. バックログの項目はユーザーストーリー形式で記述する
  4. スプリント計画ミーティングの前にストーリーを見積もる
  5. タスクは見積もらない
  6. フォーカスファクターはスキップする
  7. スプリントに詰め込みすぎない
  8. スプリント以外のことも可視化する
  9. もしスプリントがうまくいかないようならKanbanを使う
  10. シンプルなメトリクスを計画と改善に利用する
  11. 上位3つの妨害・障害事項を可視化する
  12. 従業員の満足度を継続的に測定する
  13. 継続的なデリバリを可能にするために”King and Servant”のパターンを利用する
  14. 品質ツールとして「Doneの定義」を利用する
  15. テスト自動化のバックログを用意する

ここでは最後の1つのテスト自動化バックログについて解説しておく。(スライド60ページから)

まずテスト対象のフィーチャーに以下のようなものがあるとする。

  • Change skin (スキンを変更する)
  • Security alert  (セキュリティの警告を出す)
  • Transaction history (トランザクションの履歴を扱う)
  • Block account (アカウントをブロックする)
  • Add new user  (新規ユーザーを追加する)
  • Sort query results (クエリーの結果をソートする)
  • Deposit cash (お金を預ける)
  • Validate transfer (送金を確認する)

次にそれぞれについてリスク、手動テストコスト、自動テスト作成の際の規模を明らかにする。 以下がその表になる。

ついでその表を手動実行のコストが高い順に並べ替える。

上図の手動実行の時間が長い物でテスト自動化のコストが小さいものから順に自動化に取り組めば良い。

※この資料中では記述はないが、リスク度合いに係数を掛けて順位を算出する、というのも必要だと思う。また手動テスト実行回数が全機能で均一の前提になっているが、実際の案件では異なるケースもあるので、その場合は実行回数比率も表に入れると良いだろう。 また例えば一旦低リスクは全て除外して高リスクのものから自動化するというアプローチも必要かもしれない。このあたりの順序決めはコンテキスト依存だが、リスクとROIを常に意識しなければいけないことだけは確かだ。

どこでテストの自動化に取り組むかについてはHenrikの例では、下図の通りスプリント計画の時点で20%テスト自動化への投資時間を予め確保しておくやり方をしている。

昨日マイクロソフトの長沢さんからお聞きしたが、Visual Studio2008の開発に際しては4ヶ月間新機能の開発を停止して、既存の技術的負債を返済したりテストの自動化に取り組んだとのことだ。 4ヶ月は無理かもしれないが、技術的負債の早期返済のROIが高い、もしくは今技術的負債の返済をしないと将来大きなリスクが顕在化してしまう可能性が高い、ということであれば、スプリント全体をテスト自動化に取り組むというアプローチもあるだろう。(その場合は、テスト自動化が”ステークホルダーやプロダクトオーナーにとって”投資する価値がある、と判断してもらう必要がある。)

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

サイト内検索


著作

寄稿

Latest post: