Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

JaSST2018 Tokyo参加記、という名目のもとスクラムのQAについての話題

はじめに

品質マネジメント部の伊藤です。

 

品質マネジメント部のリーダーでありつつ、アプレッソの主力プロダクトであるDataSpider Servista の スクラム開発におけるプロダクトオーナーを担当しています。

 

JaSST ソフトウェアテストシンポジウム内ではアジャイルやスクラム関連の話題も扱っていました。

 

発表内容をアップするのは基本NGっぽいので、アプレッソのスクラム開発と比較して感じたことを述べたいと思います。

 

ちなみに、以下でも紹介しているのであわせてお読みいただければと思います。

appresso.hatenablog.com

アプレッソにおけるスクラム開発のスタイル

感じたことを述べる前に、アプレッソの開発スタイルを紹介します。

 

 スクラムのチーム構成は、開発チーム 5 名、SM、PO の計 7 名で、スプリント期間は 1 週間となっています。

 

デイリースクラムは、朝に実施しており、スプリントレビュー、スプリントレトロスペクティブ、スプリントプランニングの各セレモニーは水曜日に実施しています。

 

なお、一部スクラムのルールにのっとっていない部分があります。

それは、Done 定義にテストを含んでいない点です。

 

本来、PBI を完了させるためにはリリース可能な状態にする必要があり、当然テストを行う必要があります。

 

ただし、ここで言っているテストとは、ユニットテストなどの自動テストではなく、QA が行う手動テストのことです。

 ※なぜこのようにしているのかは後述します。

 

では、どのように行っているかというと、テストはスプリントとは非同期で行っています。

 

↓こんなイメージ

f:id:chipitics:20180315112552p:plain

QA が行う手動テストはそのスプリント内には収めず、次スプリント以降に完了させています。

 

もともとの開発プロセスは、開発フェーズとQAフェーズというように開発プロセスがわかれており、ウォーターフォールチックでした。

 

また、アプレッソは開発部とQA部のように部署が独立して存在しています。

独立していることによるメリットも当然ありますが、スクラムを導入する上で課題も出てきます。

 

例えば「スプリント開始直後では、触れるものがないのでQA何するの?」といった課題です。

 

このような課題も、QA が前のスプリントのテストを行うことで解消されます。

 

※ただ現在は、QAによるテストもそのスプリント内でほぼ完了できるようになっています。

JaSSTソフトウェアテストシンポジウムを通して思ったこと

前フリが長かったですが、ここからが本題です。

といいつつ、感想しかかけないので前フリより短いですが ^^;

 

で、参加してみた感想を一言でいうと

 

「われわれのやってきたことは決して間違っていない」

 

です!

 

発表内容では、アプレッソと似たようにスクラムの開発スタイルをとっている事例もありました。

スクラムのフレームワークを無理して適用するのではなく、現実的な落としどころを見つけて、適用しやすい形で運用されていました。

 

大切なのはスクラムをやることじゃなく、スクラムで何を実現したいかです。

 

スクラムに縛られすぎるのを scrum slave (スクラムの奴隷)といいますが、

そのようなことがないように、大切なことは何かを忘れないでいたいと思います。

 

これからも日々のカイゼンを積み重ねて、さらに高いレベルのチームを目指していきたい。

そんなことを改めて思い返せたイベントでした。