なんたって”devqa” アジャイル開発とqaの合体が改善を生む - 永田敦氏...

なんたって”DevQA” アジャイル開発とQAの合体が改善を生む

アジャイルの特性を生かしたチーム作りと品質の改善

スクラム冬の陣2017 copyright © A.Nagata, 1

www.vandalsrugby.ca

2017/1/14

自己紹介ソニー株式会社

IP&S 品質保証・サービスオペレーション部門

PS-システムクオリティ部SQM課

永田敦

アジャイルソフトウェア開発

改善サポート、コーチング

JSTQB

Advanced Level Test Manager

第32年度ソフトウェア品質管理研究会 copyright © A.Nagata

2

2016/12/16

自己紹介

アジャイルの流儀：EVO

現場モード：Stealth

copyright © A.Nagata 3 2015 /1/30

Agile RCA

Agile Inspection Maestro

ソニープロフェッショナルプロダクツ

2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 4

アジャイル開発の実態

QAから見たアジャイル開発

2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 5

スクラム

スプリントスプリントスプリント

プロダクトバックログ

スプリントバックログ


スクラム




システムテスト

出荷


システムテストをやっているがバグが流出




実施

出荷


テスト分析/設計

バグ流出

市場

障害

もし品質が悪いとプロダクトバックログ


実施

出荷予定


テスト分析/設計

バグ

デバッグ

9

実施実施

2017/1/14 スクラム冬の陣2017 copyright © A.Nagata,

設計フェーズからシステムテストを実施する

スプリントスプリントスプリントスプリント



スプリントスプリントスプリントスプリントシステムテスト


実施テスト分析/設計実施実施


もっと早いタイミングで評価しよう

設計フェーズに飛び込む

組織パターン 4.2.29 James Coplin, Neil Harrison ,2005


品質保証を巻き込め(Engage Quality Assurance)

成功するかどうかは、品質の高い作業にかかっている

本質な品質問題に対処するためには、早期のフィードバックが重要である

設計者テストは行われるが、それだけでは漏れが生じてしまう。

だから、QAを中心的なロールにしよう

テストするべきものが開発できたら、すぐにQAと密接に取り組んで評価をしていこう。

品質管理はプロジェクトの早期から巻き込むべきだ


QAが設計に入ってくる

いろいろ言われるのではないか

あれを出せこれを出せあれを測れこれを測れあれを直せこれを直せ

設計に余計な負荷がかかる

設計リーダーの憂鬱

固い

ガード

QA

DevQA 黎明期 2013


設計 QA

品質の見える化

テスト測定

サポート

Deploy 評価環境共有リスク課題

アクション

信頼関係


チームのその後の話です。


次の挑戦

仕様の無駄をなくしたい


皆が自然と助け合えるプロセスを考えてみました。


スプリント開発プロセス




ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

スプリント

ＵＳ開発

ユーザーストーリー開発プロセス


仕様設計

詳細設計

テスト設計

仕様レビュー

PO

QA

開発


しかし、そんな矢先に組織が変わってしまいました orz


今のQAが去り、別の人がチームに参入することに。


新しいQAの人はドメイン知識を持っていない．新しいQAの人はドメイン知識を持っていない．

もちろん、DevQA、アジャイルテストも初めて


スクラムマスタ（SM)が QAの人と一緒にQAをしてみた。


テストのペア設計

(ペアプロ）



仕様設計

詳細設計

テスト設計

仕様レビュー

PO

QA

開発


テスト設計におけるSMとQAのフィードバックループ

ＳＭＱＡ

テスト観点・テスト条件

ユーザストーリのブレークダウン・ドメイン知識


テスト設計

まず、スクラムマスタ（SM)が主導で、ユーザーストーリー単位のテスト設計を実施してみた

（マインドマップ）

ユーザーストーリー単位のテスト設計イメージ


ユーザーストーリー

運用手順

運用手順

運用手順

・・・・・・

機能要件

機能要件

・・・・・・



次にそのテスト設計に QAが主導で、評価観点を肉付けした




運用手順

運用手順

運用手順

・・・・・・

機能要件

非機能要件

・・・・・・

テスト観点

テスト観点

テスト観点

・・・・・・



テスト設計で足りないインプットが見つかり QA→プロダクトオーナ（PO）にフィードバックするようSMが促す


テスト設計による、QAとPOのフィードバックループ

QA PO

QAが欲しい仕様の提示

質問

SM



仕様設計

詳細設計

テスト設計

仕様レビュー

PO

QA

開発


質問・提案

QA SM

仕様の説明

PO

テスト設計

ユーザーストーリ・仕様

テストケース

仕様の改善

育成

フィードバック獲得の設計


三菱電機細谷泰夫：斥候としてのアジャイルプロセス活用の提案：SPI Japan 2012

アジャイルソフトウェア開発宣言


包括的なドキュメントよりも動くソフトウェア

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

顧客からのフィードバックを早くできるだけ早く得たい

本当に顧客がほしい価値をデリバリしたい

アジャイルソフトウェア開発の本質

本当の価値は顧客のフィードバックからしか得られない

QAの役割



評価してもらうレベルまで上げておかなければならない

まず、顧客の肩代わりとして、顧客に評価してもらうレベルまで上げていくため顧客視点での品質のフィードバックを返していく

バグの潜在時間をできるだけ短くする早くフィードバックして品質を上げていく


SMとQAの関係

さらに、POの仕様レビューにQAも一緒に参加

仕様の理解に徹する



仕様設計

詳細設計

テスト設計

仕様レビュー

PO

QA

開発


POはQAと開発からフィードバックを受けるように

開発観点のフィードバック QA

PO

開発

仕様のレビュー

顧客観点のフィードバック



仕様設計

詳細設計

テスト設計

仕様レビュー

PO

QA

開発


フィードバックがだんだん洗練されていく

この仕様よりもこうするともっとシンプルになります

顧客は本当にこの機能が必要でしょうか

フィードバックループによってQAが得たもの


ドメイン知識

ユーザーストーリからのテスト情報の導き方、補い方

足りない情報を的確に得る方法

情報ルート＝フィードバックループの確立

POとのコネクション

仕様レビュー

バグの報告に対し、“この振る舞いは仕様で、障害ではない“という理由で”問題なし”となる件数の割合が半減した．

設計とQAの仕様の齟齬が削減

テスト設計で必要な情報

“仕様通り”という理由で開発から返されるバグ報告の量の比較


フィードバックループによってPOが得たもの


QAが現場での経験則から、仕様書レビューで改善指摘をしてくれることが良かった

仕様に対して、 QA評価視点、例えば“非機能要件の指定はありますか？”などの仕様の漏れを指摘してくれる

暗黙知：コンテキスト

47 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata

暗黙知

暗黙知によるコミュニケーション


暗黙知

設計のための情報をチームで共有している


暗黙知

形式知

想定外の暗黙知の齟齬


暗黙知

暗黙知齟齬をふせぐ


スクラムフレームワーク

デイリーミーティング

スプリント計画

スプリントレビュー

振り返り

DevQA 暗黙知

開発メンバーがテスト設計をレビュー


開発メンバー

どんなテストしようとしているのか

無駄なテストをしていないか？




運用手順

運用手順

運用手順

・・・・・・

機能要件

非機能要件

・・・・・・

テスト観点

テスト観点

テスト観点

・・・・・・



開発メンバーが実装前にテスト設計をレビュー

QA 開発

開発観点から評価して欲しい点のフィードバック

実装前から評価内容を把握



仕様設計

詳細設計

テスト設計

実装

テストケース評価

バグ修正

仕様レビュー

テスト設計レビュー

PO

QA

開発

フィードバックループで開発が得たもの


ユーザー視点の大切さに気付けた

評価内容を設計の段階から知ることができ、QA評価前にBugが潰せた（QA前品質向上）

開発→QAに対して評価してほしいことを気軽にお願いできる

近くにいるため、Bugの修正内容をチケット更新だけでなく口頭で伝えられる．Bug発生時の動作が把握しやすい。記憶の新しいうちに対応ができ認識間違いが減る．従って、手戻りが減る

困っていることがあればすぐに相談できるため、悩みの解決スピードが速い

フィードバックループでQAが得たもの


テスト設計レビューを通して、開発視点から指摘をもらえることで、テスト設計の精度が上がって嬉しい

仕様の認識間違いがQA前に解消できるため、QA前に品質の高いものが開発から出てくる。

その結果、基本動作Bugが減り、本当に時間をかけたい異常系や性能評価、ワークフローや長期安定性評価に時間をかけることができて嬉しい

テスト設計レビューで、評価内容を相手に正確に伝えることを意識するため、仕様の理解がより深まる。



仕様設計

詳細設計

テスト設計

実装


バグ修正

仕様レビュー


PO

QA

開発


ユーザーストーリーのDoneの定義「QA評価のテスト完・Ｂｕｇゼロ」

機能

ワークフロー

性能

長期安定性

負荷

ユーザビリティ


案の定テストが終わらない問題発生

QAメンバーから泣きのHELPあり


負荷テストや長期安定性などのテストケースまで

全て実施してみようと試みたが、現実的ではなかった


スプリント開発プロセス Before




ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

スプリント

ＵＳ開発機能

ワークフロー

性能


長期安定性

負荷


スプリント開発プロセス After

スプリントスプリントスプリントテストスプリント



ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

ＵＳ開発

システムテスト機能

USワークフロー性能


長期安定性負荷

全体ワークフロー QA-in

計画をし合意

やれるところからテストしていこう Pattern: Time to Test The Pattern Almanac, 2000 Linda Rising


いつ何のテストができるのか、設計と合意を取って行おう

テスト計画は、設計の進捗、状態により柔軟に見直していかなければならない

関連：機が熟すのを待て : Take Time

バグの発生分布


QA-in以降のバグの分布（基本機能かどうか）


基本機能のバグは、QA-in前の評価で取られているまたは、初めから入りこんでいない

バーンアップチャート


コード品質の変化： 2013年のプロジェクトと比較


バグが６５％減少コード品質が改善した


こうしてｌフィードバックと振り返りを繰り返していった結果。

ユーザーストーリー単位の開発プロセス


ＰＯデモ仕様設計

詳細設計

テスト設計

実装


バグ修正

仕様レビュー

PO

QA

設計



QAのテストケース

製品の詳細な振る舞いの仕様書となった

開発部隊はそれを開発のリファレンスにするようになった

ユーザーストーリー単位の開発プロセス



詳細設計

テスト設計

実装


バグ修正

仕様レビュー

PO

QA

設計

フィードバックにより仕様変更を常に許容


ATDD（Acceptance Test Driven Development)



詳細設計

テスト設計

実装


バグ修正

仕様レビュー

PO

QA

設計

フィードバックにより仕様変更を常に許容


ATDD


本来Acceptance Testは顧客がやるもの QAが顧客顧客の肩代わりとして、システムの振る舞いを含めた品質＝価値を評価

開発者は迷わず開発を進められる

ゴールは、合意されたもの

QAの役割



評価してもらうレベルまで上げておかなければならない

まず、顧客の肩代わりとして、顧客に評価してもらうレベルまで上げていくため顧客視点での品質のフィードバックを返していく

バグの潜在時間をできるだけ短くする早くフィードバックして品質を上げていく


ポイント

一晩でできたことではない！

最初は、不完全なもの

QAも巻き込み、フィードバック、振り返りを繰り返し

少しづつ変えていった結果

課題


まだSMへの依存度が高く、自立できていない

組織変更によるチームメンバーの出入りでベロシティが下がる

レビューの総時間が増えた

費用対効果は高いため、問題ではないが、さらなる効率化をという点での課題ではある

ベロシティーがなかなかあがらない

スクラムはどうしても人に依存するため、全体最適の視点で自立的に動ける人材（PL含む）の育成にかなりの労力を費やしている

このようなアジャイルチームになるには、Agileの普及活動含め時間がかかる．

DevQA : アジャイル開発における設計とQAのコラボレーション


設計 QA

品質の見える化

開発のリファレンス

テスト測定テストケース

サポート

Deploy 評価環境

暗黙的共有リスク課題

アクション

信頼関係

フィードバックでもたらされた情報＋合意された形式的情報

（開発,PO）

アジャイルにおけるQA


QA 顧客に変わって品質の状態をフィードバックするデリバリの判断の情報を説明報告する品質の目標、構想、計画を立てる


Linda Rising, 2004

早いうちから巻き込め Pattern: Pattern: Get Involved Early The Pattern Almanac, 2000 Linda Rising


早い段階で設計者と関係を構築しておく

例

設計者とともに、システムやフィーチャを学ぶ

要求仕様や設計ドキュメントのレビューに参加する

テスト計画のレビューに設計者を招待する

あなたが設計者と関係を持たなければならないと気付いてからでは遅すぎる

信頼を得るためには時間がかかるから。

設計チームからのサポートを最大限引き出したい

アジャイルにおけるQA


アジャイル開発においてＱＡはなくてはならないチームのメンバーですよろしく


ご清聴ありがとうございました

なんたって”devqa” アジャイル開発とqaの合体が改善を生む - 永田 敦 氏...

Technology

なんたって”devqa” アジャイル開発とqaの合体が改善を生む - 永田敦氏...