けっこう前に買って積んでいたのを読みました。
自分は現状、QAエンジニアとしてアジャイル開発にごりごり関わっているわけではありません。とはいえ、品質向上や開発プロセスの現状把握と改善のためにはメトリクス収集に関することも知っておいたほうがいいと思い、本棚から手に取りました。
概要
はじめに、に印象的なことが書いてあります。
長年アジャイルチームで仕事をしてきて、チームが直観や、誰かが読んだ最新のブログ記事に基づいて確認と調整を行なっていることが多いことに気づきました。
これは自分にも心当たりがあったので、良くないなと改めて思いました・・・。
本書は、そういったところではなくてちゃんとデータに基づいて判断・評価をしましょう、というのがベースになっています。
全体を通じて、開発中に用いられるシステムとその機能の対応に基づき、どこからどんなデータを取り、どう見せ・活用するのかが説明されています。
- プロジェクト管理ツール：タスクとバグの管理
- ソースコード管理ツール：コードと共同作業の管理
- 継続的インテグレーションツール：ビルドとテストの実行
- デプロイメントツール：本番環境へのコードの移動
- アプリケーションモニタリングツール：正常動作の確認
これらのシステムや機能からデータを取得することで、チームでなんらかの取り組みをした際の効果が定量的に測定できるようになる、のがメリットの1つです。
良かったポイント
個人的に良かったというか、なんとなくふわっと普段考えていたことが言語化されていて「これだ」と思ったところが
7.2 データを使って「良い」を定義する
の部分です。
- 良いソフトウェア
- 良いチーム
- 良いメトリクス
という考え方が出てきます。
良いメトリクスを持つことで、チームの良し悪しが測定できるようになり、良いチームは良いソフトウェアを作れる、という順です。
本書ではチームの状況を計測するために、スプリント毎に上で挙げた各種ツールからどんなデータを取るかや、こんな結果が出たらこう読み取れる、等も書いてあるのでイメージがしやすかったです。（まだ実践には至っていませんが）
QAエンジニアとしては「品質が良い」とか「改善されている」とかをチーム皆と共有・合意するのが大事になってくるので、この章・節が一番刺さりました。
全体通じてアジャイル開発をしている/いないに関わらず有用なことが書かれているように感じました。
特定のツールに閉じてはいないものの、具体例として名前も出てくるので、これから始めるにもよさそうです。