実践アジャイルテスト読書会にけなかったのでひとり読書会メモを書いてみる

先週予定されていた実践アジャイルテストの読書会なんだけど、風邪でダウン。このままズルズルと・・・って事にはしたくないので、ひとりで読んでみた感想を書いてみる。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

今回の対象は4章と5章。

第4章「チームの運営」

4章は「チームの運営」について。特に、軽視されがちなテスターさんをどうやってチームの中に取り込もうかという話。自分が関わっているプロジェクトの経験から言うと、ここでいうテスターさんは、テストエビデンスに対する検査さんな感じがするなぁ。ということで、テスター＝検査さんという意味で書いてみる。

従来のようにプログラムを書く人とテストを検査する人が独立した形で構成されていたら、そこから作り直す必要がある。ただ、これは時間がかかる話。本文中では六ヶ月っていう話もあったけど、継続して取り組まないといけない。

検査する人が「独立した形で」という話はよく聞くけど、ゴールを勘違いしている気がする。結局、「いいものをリリースしたい」という気持ちは一緒なんだから、後出しジャンケンのように後で難癖つけるようなことはやめて、一緒に作ったほうが楽じゃね？ってことかな。

概ね同意なんだけど、独立した組織として検査さんのアイデンティティを確立しているようなところは結構道は険しいだろうなぁ。って、うちの組織なんだろうけど。

第5章「典型的なプロセスの移行」

5章は「典型的なプロセスの移行」。特に印象に残ったのは「指標」と「欠陥の追跡」。

先日、自分が関わっているプロジェクトでHudsonで動かしていたテスト2,000件が全件成功しました。僕的には大ニュースだということで

「感動すら覚えます」

というメールまで全員に送り、

「やったよ！全テストがパスしたよ！おめでとう！！」

って大声で叫んだのに、周りがぽか〜ん。まだまだHudsonでの自動実行に対するうれしさとか、全件成功したということに対する喜びとかが共有できないのかなぁとちょっぴり凹んだんだけど、本書を読んで、このことは間違ってなかったと確信。やっぱり喜ぼうよ。みんな！

「指標でやってはいけないコト」として「なぜあなたはそんなに低く見積もったのですか？」ということが上げらていたんだけど、結局指標を「You」に対する批判の根拠として使ってはだめだよねってこと。問題は共有することが重要なので、「We」として話をしないと。。。これはなんにでも言えることだろうけど。

「欠陥の追跡」はTracとかRedmineとかが有名だけど、Webインタフェースってそれを入力するのが手間だったりするし、情報を一目で見れるかというとそうでもない。ということで、示されているのが付箋を使った課題管理。これだと一目で分かるし入力する手間もあんまりないし、コミュニケーションも取りやすいよねぇ。

こういうアナログチックなものが、実は一番システム開発には適しているっていうところがちょっと笑えたりする。

今回の感想

今回の4章と5章はより具体的で、より納得出来る部分が増えた。ただ、それ以上のことがほしいような気がする。具体的な言葉で表現できないのがあれなんだけど。

あと、やっぱり意見が交換できないと厳しいなぁ。しかも、自社以外の人たちと。次回は行きたい！