バグ情報も使い方によっては、チームの効果的なコラボレーションツールになるんですよ
Agile2013、2日目の9:00-10:15に行われたClaire Mossさんのセッション “Big Visible Testing” に参加しました。
Claireさんは、Oracle社のQAエンジニアで、テスターの立場から現場改善を主導している方です。
Experience Report(事例紹介)ジャンルのセッションで、同じ現場改善の実践者として興味があったこと、「テストの見える化」がどういうものかに非常に興味があったことから参加しました。さらに、渡米中の飛行機内でHenrik Knibergさんの『Lean from the Trenches』を読んでいて、ちょうどバグの見える化が課題だという記述(9.4 Visualizing Bugs)を見つけたところだったので、非常にタイムリーだなとも感じての参加でした。
彼女はかなり熱い実践者でした。
■テスターとしての悩み:課題認識
Claireさんのチームでは当初、バグが見つかった場合にどれを優先的に解決すべきか、チーム内でうまく合意をとれずに苦労したそうです。そのため、コミュニケーション方法の工夫が必要になるのですが、Claireさんは2種類の「見える化」によって実現しました。
■見える化その1:チームメンバーのペルソナ
Claireさんのチームは、Product Manager(ビジネスサイドのメンバー)、UX Designer、Developerで構成されるスクラムチームです。テスターであるClaireさんにとって、彼らはチームメイトであると同時に、テストユーザまたはステークホルダーと見ることもできます。
プロダクト開発では、ステークホルダー分析を行ってニーズ・要望を把握します。Claireさんは、チームメンバーをテストのステークホルダーと捉え、チームメンバーのペルソナを作成することで、テスト・バグに対するニーズ・要望を見える化したそうです。
ペルソナを作成した結果、チームメンバーが次のようなニーズ・要望を持っていることが分かりました。
Product Manager
- バグの重大性(Severity)は?
- テストのROIはどれくらいか?
- (そもそも)プロダクトをリリースできるか?
- どうやって早く価値を提供できるか?
UX Designer
- バグがどの機能に多いか?
- バグを再現できるか?試せるか?
- 見た目の要望を満たしているか?
- 機能の正確性を満たしているか?
Developer
- 原因は何か?
- 次に何をすればよいか?
- 動作するか?
この時点で、ステークホルダー毎にテスト・バグに対する要望・ニーズに差異があることが分かります。
■見える化その2:ステークホルダーに応じたバグボード
Claireさんは、ペルソナに続いてステークホルダー毎にバグボード(バグを書いた付箋を貼ったタスクボード)を作成しました。ステークホルダー毎の関心事に応じてバグの見せ方を変え、バグのDoD(Definition of Done:完了の定義)を明確化することで、バグ解決をスムーズにしたのです。
具体的には、次のようなバグボードを用意しました。
Product Manager
バグを重大性(Severity)の順に整理し、どのバグから解決すべきかを判断。
UX Designer
バグのサイトマップを作成し、どの機能のバグ群を重点的に解決すべきかを判断。
Developer
スプリントボードにバグタスクを組み入れ、どのタイミングでバグを解決するかを判断。
- スプリントボード上にバグのレーンを用意し、Timebox化して1つずつ解決していく。
- ストーリーにバグタスクを振り分け、1つずつ解決していく。
バグボードを作り分けたことで、各ステークホルダー内外のコミュニケーションが増え、結果としてチーム全体のマインドがポジティブに変わってきたそうです。
■現場の改善ストーリーにこそリアルがある
- テストのステークホルダーのペルソナを作成する。
- バグ情報をペルソナ毎に再構成・提供することで、迅速な開発と修正を実現する。
- これらをテスター主導で実現。
チームメンバーのペルソナを明確化し、それをもとにバグ情報の見せ方を工夫していくストーリー展開が、現場の課題解決を生き生きと伝えていて、非常に参考になりました。
有名な方の理論ももちろん有効です。それ以上に現場での試行錯誤のレポートは、その学習過程が明確なことと、同じように試行錯誤している自分と重ね合わせやすいことから、より身になることが多いと感じました。
■QAの新しいロールモデル
もうひとつ私が注目したのは、一連のバグの見える化を通じて、Claireさんがチームメンバーをコーチングしながら、テストを円滑化していったという点です。Claireさん自身も、一連の活動を通じてチームメンバーをクロスファンクショナルなチームへ育てていったということを話していました。
私がよく耳にするQAエンジニア像は、開発チームから「降りてきた」プロダクトのテストを「押し付けられる」というものです。開発チームと切り離され、どちらかというと無理を押し付けられて難儀しているQAエンジニアたち。
ですがClaireさんのやり方は、QAエンジニア側から開発チームに働きかけて、テストのしやすいプロダクトやチーム構成にしていくものです。これはスタート地点は違うものの、私が取り組んでいるアジャイルコーチの仕事と同じです。
こうしたアプローチは、QAエンジニアの新しいロールモデルとしてもよいのではないかなと思います。
※注:レポート内のスライド画像は、Claireさんの許可を得て掲載しています。
- Blog:How do you like xxx?
- Twitter:@hageyahhoo
- Facebook:http://www.facebook.com/hageyahhoo
- これまでのレポート:http://www.manaslink.com/hiroyuki-ito
3 Comments
The Hiro (Hiro Ito) (@hageyahhoo) · 2013年8月25日 at 13:39
#Agile2013 の新しいレポートできました。QA エンジニアの視点から、バグの見える化によってチームを改善していった @aclairefication さんのセッションのお話です。 http://t.co/17mc6MLuXR
@aclairefication · 2013年8月25日 at 14:19
I’m totally relying on Google Translate here, but “She was pretty hot practitioners.” http://t.co/WcLu6gXRs8 #Agile2013 #BVT
EM Zeroのナカノヒト (@em_staff) · 2013年8月26日 at 10:10
Agile2013現地レポート(5)は、レポーター伊藤さんイチオシのセッション![8/6] バグの見える化によるコラボレーションが熱い!:Agile2013 レポート(5) http://t.co/KEj2f2ZLCS #agile2013
Comments are closed.