inomata@QAです。
webで勉強会をてきとーに探してたら面白そうなモノがあったので参加してみました。
第6回Ques アジャイルと品質
Ques
http://quesqa.com/
増席したうえ、キャンセル待ちも多数発生するほど人の気で、スピーカー、参加者ともにやる気に満ち溢れていたイベントであったことを肌で感じてきました。
ということで、聴いてきた内容を意訳を含めてまとめました。
KDDI 鈴木さん アジャイルプロセスの改善について
受け入れテストに問題があるので何とかしてほしいというミッションを受けた。
開発チームはアジャイルのスクラムでやっていた。そこで受け入れテストはスプリントのタスクの一つと捕らえ、スプリント全体の改善に着手した。
・役割を分けて本来やるべき仕事に集中させた
プロダクトオーナーとテスターの両方が受け入れテストをやっていたりしていて、主にプロダクトオーナーが本来やるべき仕事ができていなかった。また、テスターもチームを横断する組織だったので、工数を確保するようにした。これにより、プロダクトオーナー、開発、テスターが自分たちの仕事に専任できるようにした。
・仕様の理解を同じタイミングでアップデートするようにした。
テストの担当者に仕様変更が伝わっていない！という状況をなくすために、仕様等の共有は朝のミーティング等を活用してプロダクトオーナ、開発、テスターの3者に同じタイミングで共有するようにした。
スクラムは2週間を1スプリントとしてやっている。
朝ミーティングで振り返りのKPTを見ている。
テスターは最初の1日と7日目以降で参加する。初日は振り返りや計画で情報共有。7日目以降はテストの設計と実施といったテストの活動。
課題としては、バグが見つかると次のスプリントに食い込むのでベロシティが下がる。なのでもっと前倒ししてテストをはじめる施策を考え中（企業秘密とのこと）
ソニー 永田さん アジャイルプロセスにおけるQAについて
アジャイルをやり始めてQAが開発チームに入ると、QAが開発に嫌がられる。（仕様をよこせだの、メトリックスを取れだの・・・）なので、QAは開発をサポートするような立場でチームに貢献しようという考えが良い。（CDD:Contribution Driven Developmentと名づけた）
例えば、QAがテストをするにあたって仕様がほしいということであれば、"仕様を作成すればQAは開発にとって有益な情報を出してくれる"ということを認識してもらう必要がある。
また、開発される機能は仕様だけで表現されることがなく、開発者どうしの暗黙値が存在する。QAが早期にチームに入り込み、密にコミュニケーションを取る事でこの暗黙値を共有することができ、結果としてドキュメントがいらなくなる。
QAが早い段階で仕様を理解し、テストケースを起こし、それを開発に共有することで設計の段階からテストの観点を共有でき、設計の品質を向上させることが出来る。
ベロシティをあげるにはバグを減らすことと、無駄をなくすこと。前述のアプローチはベロシティの向上に期待できる。
アジャイルのポイントは全て計画にある。現状を正しく把握し、それにあわせた計画を立てるというのが正しい。例えばベロシティが低いのにプロダクトバックログを積むのはまったくの無意味。1スプリント内でバグをつぶしきれないという現状があるなら、それを計画に入れるべき。
ストーリーの消化を計測するにはバーンアップを使う。これは途中でストーリの追加が発生するのでバーンダウンより管理しやすい。
3分悩んだら聞く。そして聞く人はそれを受け入れる。というルールを作った。
これは考える時間を減らす。コミュニケーション量を増やすことで暗黙値を増やす→ドキュメント要らなくする→ムダを減らしてベロシティあげるということ。
QAはスクラム（プロセス）をヘルシーに出来る立場にある。
アジャイルプロセスはQAが品質向上に貢献できる最適なプロセスである。
QAはアジャイルを利用しよう。
LT 鈴木さん 永田さん
Q.アジャイルチームに歓迎されるテスターとは？
・コミュニケーションに苦痛を感じない人
・得意なところ（プロフェショナルな部分）をアピールできる人
・やる気ある人（スタープレイヤーはいらない）
Q.結局ドキュメントってどれくらいいるの？
・細かいのはいらない。ポリシーくらい抽象的なモノがあると良い。
・製品によって変わるから一概に言えない。必要なものはチームが決めていく。
いかがでしょうか。QAから見たアジャイルプロセスというありそうでなかった話に大変刺激を受け、早速何かアクションが出来ないかと考えたくなる良い勉強会でした。
アジャイルQAは攻めるQAです。アジャイルに積極的に参加してチーム内で誰よりも品質に貢献していきましょう！！
それでは！
