システム開発(アジャイル・スクラム)とか色々

スクラムについてのアウトプットだったり、時々お気に入りのものなど。

開発者とQAチームを分けるということ

はじめに

本日は開発者とQAのチームの在り方についてのメモです。

理想はQAの能力も兼ね備えた1つのチームで開発するのが望ましいとは思っていますが、 プロダクト巨大・複雑化してくると俯瞰して品質に目を向けてくれる人が欲しくなることがあります。

そうなったときどうすれば良いのか考えてみたいと思います。


シェリフの泥棒洞窟実験

1954年、アメリカの社会心理学者であるM・シェリフらが『泥棒洞窟実験』というものを行いました。

3行でまとめるとこうなります。

  • チームを分割させることによって敵対心を持つようになる
  • チーム分割後に一緒に食事したり行動しても関係解消には至らなかった
  • ただ、協力して共同作業されることによって改善が見られた

高い仲間意識の危険性とその解決法についての社会心理学実験~泥棒洞窟実験~

チームが分かれることによってこういった経験は無いでしょうか? 個人的には別れているチームが見えないところにいればいるほど、やっていることがわからないほど敵対度の高さは顕著な気がします。

開発者とQAを分けるということ

上記からもチームは分けるべきではない!と言いたいところですが、 冒頭にもあるようにQAチームが欲しい場合はどうすればいいのだろう。 スクラムにおいてのやり方は以下の3つがあると考えています。(単純に同時にやるのか、あとでやるのか、最後にまとめてやるのか)

※ 便宜的に開発チームスプリントとQAチームスプリントと表現します
※ 前提として開発とQAのスプリントは同じ期間で実施します

① 開発チームスプリントとQAチームスプリントを同時に回す

1スプリントのなかで、開発しつつテスト(計画/)設計〜テスト実行までするもの。

スプリント毎にリリース判断可能な成果物、Undoneを残さないという意味ではこれが理想なのかもしれません。 ただ、QAとして磐石じゃないと厳しいかもってことで当社チームでは採用せず。

② 開発チームスプリントから1スプリント遅れでQAチームスプリントを回す

開発チームスプリントが開発をしている間にQAチームスプリントではテスト設計などの上流工程を実施。 開発と1スプリント遅れでQAチームがテスト実行を行うもの。

このあたりはブロッコリーさんが紹介していたりするので比較的一般的になっていたりするのですかね。

当社チームでもこの方法を採用しており、リズムとしていい感じです。 また、テスト設計段階で開発者と積極的に関わり、1つのゴールへ目が向かうので、チーム分割的な意識が薄くなるように思います。

③ テストスプリントとしてやる

これは個人的にはアンチパターンだと思っているやつですが、 別途テストスプリントとしてQAがテストします。

デメリットしかないなって思うので是非やって体感していただけると良いかと。

まとめと最後に

コンテキストによるので何かベストプラクティスとは言えないですが、 QAチームとして存在させたい場合は①か②になるかとは考えています。 別のこんな方法でやっているよ!って方がいたらコメント等いただけると嬉しいです。

それと前から考えているのは、ウォーターフォール文脈におけるQAチーム、 要はゲートキーパー的なイメージが先行してしまうのがとても悪だなって思います。 同じプロダクトを作っているので1つのビジョンやゴールに向けて協力してやっていきたいですね。