何がって"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
4

アジャイル開発の実態
QAから見たアジャイル開発
2016/12/16
5

スクラム
スプリントスプリントスプリント
プロダクトバックログ
スプリント
バックログ
2017/1/14
6

スクラム
スプリント
バックログ
システムテスト
出荷
2017/1/14
7

システムテストをやっているがバグが流出
2017/1/14
8
スプリント
バックログ
実施
出荷
システム
テスト
テスト分析/設計
バグ流出
市場
障害

もし品質が悪いと
スプリント
バックログ
実施
出荷予定
システム
テスト
テスト分析/設計
バグ
デバッグ
9
実施実施
2017/1/14

設計フェーズからシステムテストを実施する
スプリントスプリントスプリントスプリント
スプリント
バックログ
システム
テスト
2017/1/14
10
実施
テスト分析/設計実施実施

2017/1/14
11
もっと早いタイミングで
評価しよう
設計フェーズに飛び込む

2017/1/14
12

組織パターン 4.2.29
James Coplin, Neil Harrison ,2005
2017/1/14
13
 品質保証を巻き込め(Engage Quality Assurance)
 成功するかどうかは、品質の高い作業にかかっている
 本質な品質問題に対処するためには、早期のフィードバックが重要である
 設計者テストは行われるが、それだけでは漏れが生じてしまう。
 だから、QAを中心的なロールにしよう
 テストするべきものが開発できたら、すぐにQAと密接に取り組んで評価をし
ていこう。
 品質管理はプロジェクトの早期から巻き込むべきだ

2017/1/14
14
QAが設計に入ってくる
いろいろ言われるのではないか
あれを出せこれを出せ
あれを測れこれを測れ
あれを直せこれを直せ
設計に余計な負荷がかかる
設計リーダーの憂鬱
固い
ガード
QA

DevQA 黎明期 2013
2017/1/14
15
設計 QA
品質の
見える化
 テスト
 測定
サポート
 Deploy 評価環境
共有
リスク
課題
アクション
信頼関係

2017/1/14
16
チームのその後の話です。

2017/1/14
17
次の挑戦
仕様の無駄をなくしたい

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

2017/1/14
19
スプリント開発プロセス
スプリント
バックログ
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
スプリント
ＵＳ開発

ユーザーストーリー開発プロセス
2017/1/14
20
仕様設計
詳細設計
テスト設計
仕
様
レ
ビ
ュ
ー
PO
QA
開発

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

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

2017/1/14
23
新しいQAの人はドメイン知識を持っていない．
新しいQAの人はドメイン知識を持っていない．
もちろん、DevQA、アジャイルテストも初めて

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

2017/1/14
25
テストの
ペア設計
(ペアプロ）

2017/1/14
26
仕様設計
詳細設計
テスト設計
仕
様
レ
ビ
ュ
ー
PO
QA
開発

2017/1/14
27
テスト設計におけるSMとQAのフィードバックループ
ＳＭＱＡ
テスト観点・テスト条件
ユーザストーリのブレークダウン・ドメイン知識

2017/1/14
28
テスト設計
まず、スクラムマスタ（SM)が主導で、
ユーザーストーリー単位の
テスト設計を実施してみた
（マインドマップ）

ユーザーストーリー単位のテスト設計イメージ
2017/1/14
29
ユーザー
ストーリー
運用手順
運用手順
運用手順
・
・
・
・
・
・
機能要件
機能要件
・
・
・
・
・
・
ユーザー
ストーリー

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

2017/1/14
31
ユーザー
ストーリー
運用手順
運用手順
運用手順
・
・
・
・
・
・
機能要件
非機能要件
・
・
・
・
・
・
テスト観点
テスト観点
テスト観点
・
・
・
・
・
・
ユーザー
ストーリー

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

2017/1/14
33
テスト設計による、QAとPOのフィードバックループ
QA PO
QAが欲しい仕様の提示
質問
SM

2017/1/14
34
仕様設計
詳細設計
テスト設計
仕
様
レ
ビ
ュ
ー
PO
QA
開発

2017/1/14
35
質問・提案
QA
SM
仕様の説明
PO
テスト設計
ユーザーストーリ・仕様
テストケース
仕様の改善
育成

フィードバック獲得の設計
2016/12/16
36
三菱電機細谷泰夫：斥候としてのアジャイルプロセス活用の提案：SPI Japan 2012

アジャイルソフトウェア開発宣言
2016/12/16
37
包括的なドキュメントよりも動くソフトウェア
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
顧客からのフィードバックを早くできるだけ早く得たい
本当に顧客がほしい価値をデリバリしたい
アジャイルソフトウェア開発の本質
本当の価値は顧客のフィードバックからしか得られない

QAの役割
2016/12/16
38
評価してもらうレベルまで上げておかなければならない
まず、顧客の肩代わりとして、
顧客に評価してもらうレベルまで上げていくため
顧客視点での品質のフィードバックを返していく
バグの潜在時間をできるだけ短くする
早くフィードバックして品質を上げていく

2017/1/14
39
SMとQAの関係
さらに、POの仕様レビューにQAも一緒に参加
仕様の理解に徹する

2017/1/14
40
仕様設計
詳細設計
テスト設計
仕
様
レ
ビ
ュ
ー
PO
QA
開発

2017/1/14
41
POはQAと開発からフィードバックを受けるように
開
発
観
点
の
フ
ィ
ー
ド
バ
ッ
ク
QA
PO
開発仕
様
の
レ
ビ
ュ
ー
顧
客
観
点
の
フ
ィ
ー
ド
バ
ッ
ク

2017/1/14
42
仕様設計
詳細設計
テスト設計
仕
様
レ
ビ
ュ
ー
PO
QA
開発

2017/1/14
43
フィードバックが
だんだん洗練されていく
この仕様よりも
こうするともっとシンプルになります
顧客は
本当にこの機能が必要でしょうか

フィードバックループによってQAが得たもの
2017/1/14
44
 ドメイン知識
 ユーザーストーリからのテスト情報の導き方、補い方
 足りない情報を的確に得る方法
 情報ルート＝フィードバックループの確立
 POとのコネクション
 仕様レビュー
 バグの報告に対し、“この振る舞いは仕様で、障害ではない“という
理由で”問題なし”となる件数の割合が半減した．
 設計とQAの仕様の齟齬が削減
テスト設計で
必要な情報

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

フィードバックループによってPOが得たもの
2017/1/14
46
 QAが現場での経験則から、仕様書レビューで改善指摘をしてくれるこ
とが良かった
 仕様に対して、 QA評価視点、例えば“非機能要件の指定はあります
か？”などの仕様の漏れを指摘してくれる

暗黙知：コンテキスト
47 2016/12/16
暗黙知

暗黙知によるコミュニケーション
48 2016/12/16
暗黙知

設計のための情報をチームで共有している
49 2016/12/16
暗黙知
形式知

想定外の暗黙知の齟齬
50 2016/12/16
暗黙知

暗黙知齟齬をふせぐ
51 2016/12/16
スクラム
フレームワーク
デイリー
ミーティング
スプリント計画
スプリントレビュー
振り返り
DevQA
暗黙知

開発メンバーがテスト設計をレビュー
2016/12/16
52
開発メンバー
どんなテストしようとしているのか
無駄なテストをしていないか？

2017/1/14
53
ユーザー
ストーリー
運用手順
運用手順
運用手順
・
・
・
・
・
・
機能要件
非機能要件
・
・
・
・
・
・
テスト観点
テスト観点
テスト観点
・
・
・
・
・
・
ユーザー
ストーリー

2017/1/14
54
開発メンバーが実装前に
テスト設計をレビュー
QA 開発
開発観点から評価して
欲しい点のフィードバック
実装前から
評価内容を把握

2017/1/14
55
仕様設計
詳細設計
テスト設計
実装
テストケース評価
バグ修正
仕
様
レ
ビ
ュ
ー
テ
ス
ト
設
計
レ
ビ
ュ
ー
PO
QA
開発

フィードバックループで開発が得たもの
2017/1/14
56
 ユーザー視点の大切さに気付けた
 評価内容を設計の段階から知ることができ、QA評価前にBugが潰せた
（QA前品質向上）
 開発→QAに対して評価してほしいことを気軽にお願いできる
 近くにいるため、Bugの修正内容をチケット更新だけでなく口頭で伝え
られる．Bug発生時の動作が把握しやすい。記憶の新しいうちに対応が
でき認識間違いが減る．従って、手戻りが減る
 困っていることがあればすぐに相談できるため、悩みの解決スピードが
速い

フィードバックループでQAが得たもの
2017/1/14
57
 テスト設計レビューを通して、開発視点から指摘をもらえることで、テスト設
計の精度が上がって嬉しい
 仕様の認識間違いがQA前に解消できるため、QA前に品質の高いものが開
発から出てくる。
 その結果、基本動作Bugが減り、本当に時間をかけたい異常系や性能評価、ワーク
フローや長期安定性評価に時間をかけることができて嬉しい
 テスト設計レビューで、評価内容を相手に正確に伝えることを意識するため、
仕様の理解がより深まる。

2017/1/14
58
仕様設計
詳細設計
テスト設計
実装
バグ修正
仕
様
レ
ビ
ュ
ー
テ
ス
ト
設
計
レ
ビ
ュ
ー
PO
QA
開発

2017/1/14
59
ユーザーストーリーのDoneの定義
「QA評価のテスト完・Ｂｕｇゼロ」
機能
ワークフロー
性能
長期安定性
負荷
ユーザビリティ

2017/1/14
60
案の定
テストが終わらない問題発生
QAメンバーから泣きのHELPあり

2017/1/14
61
負荷テストや長期安定性などの
テストケースまで
全て実施してみようと試みたが、
現実的ではなかった

2017/1/14
62
スプリント開発プロセス Before
スプリント
バックログ
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
スプリント
ＵＳ開発
機能
ワーク
フロー
性能
ユーザ
ビリティ
長期
安定性
負荷

2017/1/14
63
スプリント開発プロセス After
スプリントスプリントスプリントテストスプリント
スプリント
バックログ
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
ＵＳ開発
システムテスト
機能
USワーク
フロー性能
ユーザ
ビリティ
長期
安定性
負荷
全体ワーク
フロー
QA-in
計画をし
合意

やれるところからテストしていこう
Pattern: Time to Test
The Pattern Almanac, 2000 Linda Rising
2017/1/14
65
いつ何のテストができるのか、
設計と合意を取って行おう
テスト計画は、設計の進捗、状態により
柔軟に見直していかなければならない
関連：機が熟すのを待て : Take Time

バグの発生分布
2017/1/14
66

QA-in以降のバグの分布（基本機能かどうか）
2017/1/14
67
基本機能のバグは、QA-in前の評価で取られている
または、初めから入りこんでいない

バーンアップチャート
2017/1/14
68

コード品質の変化： 2013年のプロジェクトと比較
2017/1/14
69
バグが６５％減少
コード品質が改善
した

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

ユーザーストーリー単位の開発プロセス
2017/1/14
71
Ｐ
Ｏ
デ
モ
仕様設計
詳細設計
テスト設計
実装
バグ修正
仕
様
レ
ビ
ュ
ー
PO
QA
設計
テ
ス
ト
設
計
レ
ビ
ュ
ー

2017/1/14
72
QAのテストケース
製品の詳細な振る舞いの
仕様書となった
開発部隊はそれを
開発のリファレンスにするようになった

ユーザーストーリー単位の開発プロセス
2017/1/14
73
Ｐ
Ｏ
デ
モ
仕様設計
詳細設計
テスト設計
実装
バグ修正
仕
様
レ
ビ
ュ
ー
PO
QA
設計
フィードバックにより仕様変更を常に許容
テ
ス
ト
設
計
レ
ビ
ュ
ー

ATDD（Acceptance Test Driven Development)
2017/1/14
74
Ｐ
Ｏ
デ
モ
仕様設計
詳細設計
テスト設計
実装
バグ修正
仕
様
レ
ビ
ュ
ー
PO
QA
設計
フィードバックにより仕様変更を常に許容
テ
ス
ト
設
計
レ
ビ
ュ
ー

ATDD
2017/1/14
75
 本来Acceptance Testは顧客がやるもの
 QAが顧客顧客の肩代わりとして、
システムの振る舞いを含めた品質＝価値を評価
 開発者は迷わず開発を進められる
 ゴールは、合意されたもの

QAの役割
2016/12/16
76
評価してもらうレベルまで上げておかなければならない
まず、顧客の肩代わりとして、
顧客に評価してもらうレベルまで上げていくため
顧客視点での品質のフィードバックを返していく
バグの潜在時間をできるだけ短くする
早くフィードバックして品質を上げていく

2017/1/14
77
ポイント
一晩でできたことではない！
最初は、不完全なもの
QAも巻き込み、
フィードバック、振り返りを繰り返し
少しづつ変えていった結果

課題
2017/1/14
78
 まだSMへの依存度が高く、自立できていない
 組織変更によるチームメンバーの出入りでベロシティが下がる
 レビューの総時間が増えた
 費用対効果は高いため、問題ではないが、さらなる効率化をという点での課題で
はある
 ベロシティーがなかなかあがらない
 スクラムはどうしても人に依存するため、全体最適の視点で自立的に
動ける人材（PL含む）の育成にかなりの労力を費やしている
 このようなアジャイルチームになるには、Agileの普及活動含め時間が
かかる．

DevQA : アジャイル開発における設計とQAのコラボレーション
2017/1/14
79
設計 QA
品質の
見える化
開発のリファレンス
 テスト
 測定
 テストケース
サポート
Deploy 評価環境
暗黙的共有
リスク
課題
アクション
信頼関係
フィードバックでもたらされた情報＋合意された形式的情報
（開発,PO）

アジャイルにおけるQA
2017/1/14
80
QA
顧客に変わって
品質の状態をフィードバックする
デリバリの判断の情報を説明報告する
品質の目標、構想、計画を立てる

2017/1/14
81
Linda Rising, 2004

早いうちから巻き込め
Pattern: Pattern: Get Involved Early
The Pattern Almanac, 2000 Linda Rising
2017/1/14
82
 早い段階で設計者と関係を構築しておく
 例
 設計者とともに、システムやフィーチャを学ぶ
 要求仕様や設計ドキュメントのレビューに参加する
 テスト計画のレビューに設計者を招待する
 あなたが設計者と関係を持たなければならないと気付いてからでは遅すぎる
 信頼を得るためには時間がかかるから。
設計チームからのサポートを最大限引き出したい

アジャイルにおけるQA
2017/1/14
83
アジャイル開発において
ＱＡはなくてはならない
チームのメンバーです
よろしく

2017/1/14
84
ご清聴ありがとうございました

何がって"DevQA" アジャイル開発とQAの合体が改善を生む

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 何がって"DevQA" アジャイル開発とQAの合体が改善を生む

Semelhante a 何がって"DevQA" アジャイル開発とQAの合体が改善を生む (20)

Mais de atsushi nagata

Mais de atsushi nagata (7)

何がって"DevQA" アジャイル開発とQAの合体が改善を生む