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

アジャイルチームにQAがどうかかわるのか
それは、DevとQAがフィードバックをしあいながら学び
コラボするDevQAモデルになる

Transcript

1. なんたって”DevQA” アジャイル開発とQAの合体が改善を生む アジャイルの特性を生かしたチーム作りと品質の改善 スクラム冬の陣2017 copyright © A.Nagata, 1 www.vandalsrugby.ca 2017/1/14
2. 自己紹介 ソニー株式会社 IP&S 品質保証・サービスオペレーション部門 PS-システムクオリティ部SQM課 永田 敦 アジャイルソフトウェア開発 改善サポート、コーチング JSTQB Advanced Level Test Manager 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 2 2016/12/16
3. 自己紹介 アジャイルの流儀：EVO 現場モード：Stealth copyright © A.Nagata 3 2015 /1/30 Agile RCA Agile Inspection Maestro
4. ソニープロフェッショナルプロダクツ 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 4
5. アジャイル開発の実態 QAから見たアジャイル開発 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 5
6. スクラム スプリント スプリント スプリント プロダクトバックログ スプリント バックログ 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 6
7. スクラム スプリント スプリント スプリント プロダクトバックログ スプリント バックログ システムテスト 出荷 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 7
8. システムテストをやっているがバグが流出 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 8 プロダクトバックログ スプリント バックログ 実施 出荷 システム テスト テスト分析/設計 バグ流出 市場 障害
9. もし品質が悪いと プロダクトバックログ スプリント バックログ 実施 出荷予定 システム テスト テスト分析/設計 バグ デバッグ 9 実施 実施 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata,
10. 設計フェーズからシステムテストを実施する スプリント スプリント スプリント スプリント プロダクトバックログ スプリント バックログ スプリント スプリント スプリント スプリント システム テスト 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 10 実施 テスト分析/設計 実施 実施
11. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 11 もっと早いタイミングで 評価しよう 設計フェーズに飛び込む
12. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 12
13. 組織パターン 4.2.29 James Coplin, Neil Harrison ,2005 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 13  品質保証を巻き込め(Engage Quality Assurance)  成功するかどうかは、品質の高い作業にかかっている  本質な品質問題に対処するためには、早期のフィードバックが重要である  設計者テストは行われるが、それだけでは漏れが生じてしまう。  だから、QAを中心的なロールにしよう  テストするべきものが開発できたら、すぐにQAと密接に取り組んで評価をし ていこう。  品質管理はプロジェクトの早期から巻き込むべきだ
14. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 14 QAが設計に入ってくる いろいろ言われるのではないか あれを出せこれを出せ あれを測れこれを測れ あれを直せこれを直せ 設計に余計な負荷がかかる 設計リーダーの憂鬱 固い ガード QA
15. DevQA 黎明期 2013 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 15 設計 QA 品質の 見える化  テスト  測定 サポート  Deploy 評価環境 共有 リスク 課題 アクション 信頼関係
16. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 16 チームのその後の話です。
17. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 17 次の挑戦 仕様の無駄をなくしたい
18. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 18 皆が自然と助け合える プロセスを考えてみました。
19. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 19 スプリント開発プロセス スプリント スプリント スプリント プロダクトバックログ スプリント バックログ ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 スプリント ＵＳ開発
20. ユーザーストーリー開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 20 仕様設計 詳細設計 テスト設計 仕 様 レ ビ ュ ー PO QA 開発
21. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 21 しかし、そんな矢先に 組織が変わってしまいました orz
22. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 22 今のQAが去り、 別の人がチームに参入することに。
23. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 23 新しいQAの人はドメイン知識を持っていない． 新しいQAの人はドメイン知識を持っていない． もちろん、DevQA、アジャイルテストも初めて
24. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 24 スクラムマスタ（SM)が QAの人と一緒にQAをしてみた。
25. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 25 テストの ペア設計 (ペアプロ）
26. ユーザーストーリー開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 26 仕様設計 詳細設計 テスト設計 仕 様 レ ビ ュ ー PO QA 開発
27. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 27 テスト設計におけるSMとQAのフィードバックループ ＳＭ ＱＡ テスト観点・テスト条件 ユーザストーリのブレークダウン・ドメイン知識
28. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 28 テスト設計 まず、スクラムマスタ（SM)が主導で、 ユーザーストーリー単位の テスト設計を実施してみた （マインドマップ）
29. ユーザーストーリー単位のテスト設計イメージ 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 29 ユーザー ストーリー 運用手順 運用手順 運用手順 ・ ・ ・ ・ ・ ・ 機能要件 機能要件 ・ ・ ・ ・ ・ ・ ユーザー ストーリー
30. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 30 次にそのテスト設計に QAが主導で、評価観点を肉付けした
31. ユーザーストーリー単位のテスト設計イメージ 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 31 ユーザー ストーリー 運用手順 運用手順 運用手順 ・ ・ ・ ・ ・ ・ 機能要件 非機能要件 ・ ・ ・ ・ ・ ・ テスト観点 テスト観点 テスト観点 ・ ・ ・ ・ ・ ・ ユーザー ストーリー
32. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 32 テスト設計で足りないインプットが見つかり QA→プロダクトオーナ（PO）にフィードバック するようSMが促す
33. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 33 テスト設計による、QAとPOのフィードバックループ QA PO QAが欲しい仕様の提示 質問 SM
34. ユーザーストーリー開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 34 仕様設計 詳細設計 テスト設計 仕 様 レ ビ ュ ー PO QA 開発
35. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 35 質問・提案 QA SM 仕様の説明 PO テスト設計 ユーザーストーリ・仕様 テストケース 仕様の改善 育成
36. フィードバック獲得の設計 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 36 三菱電機 細谷泰夫：斥候としてのアジャイルプロセス活用の提案 ：SPI Japan 2012
37. アジャイルソフトウェア開発宣言 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 37 包括的なドキュメントよりも動くソフトウェア 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 顧客からのフィードバックを早くできるだけ早く得たい 本当に顧客がほしい価値をデリバリしたい アジャイルソフトウェア開発の本質 本当の価値は顧客のフィードバックからしか得られない
38. QAの役割 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 38 顧客からのフィードバックを早くできるだけ早く得たい 評価してもらうレベルまで上げておかなければならない まず、顧客の肩代わりとして、 顧客に評価してもらうレベルまで上げていくため 顧客視点での品質のフィードバックを返していく バグの潜在時間をできるだけ短くする 早くフィードバックして品質を上げていく
39. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 39 SMとQAの関係 さらに、POの仕様レビューにQAも一緒に参加 仕様の理解に徹する
40. ユーザーストーリー開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 40 仕様設計 詳細設計 テスト設計 仕 様 レ ビ ュ ー PO QA 開発
41. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 41 POはQAと開発からフィードバックを受けるように 開 発 観 点 の フ ィ ー ド バ ッ ク QA PO 開発 仕 様 の レ ビ ュ ー 顧 客 観 点 の フ ィ ー ド バ ッ ク
42. ユーザーストーリー開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 42 仕様設計 詳細設計 テスト設計 仕 様 レ ビ ュ ー PO QA 開発
43. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 43 フィードバックが だんだん洗練されていく この仕様よりも こうするともっとシンプルになります 顧客は 本当にこの機能が必要でしょうか
44. フィードバックループによってQAが得たもの 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 44  ドメイン知識  ユーザーストーリからのテスト情報の導き方、補い方  足りない情報を的確に得る方法  情報ルート＝フィードバックループの確立  POとのコネクション  仕様レビュー  バグの報告に対し、“この振る舞いは仕様で、障害ではない“という 理由で”問題なし”となる件数の割合が半減した．  設計とQAの仕様の齟齬が削減 テスト設計で 必要な情報
45. “仕様通り”という理由で開発から返されるバグ報告の量の比較 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 45
46. フィードバックループによってPOが得たもの 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 46  QAが現場での経験則から、仕様書レビューで改善指摘をしてくれるこ とが良かった  仕様に対して、 QA評価視点、例えば“非機能要件の指定はあります か？”などの仕様の漏れを指摘してくれる
47. 暗黙知 ： コンテキスト 47 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 暗黙知
48. 暗黙知によるコミュニケーション 48 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 暗黙知
49. 設計のための情報をチームで共有している 49 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 暗黙知 形式知
50. 想定外の暗黙知の齟齬 50 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 暗黙知
51. 暗黙知齟齬をふせぐ 51 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata スクラム フレームワーク デイリー ミーティング スプリント計画 スプリントレビュー 振り返り DevQA 暗黙知
52. 開発メンバーがテスト設計をレビュー 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 52 開発メンバー どんなテストしようとしているのか 無駄なテストをしていないか？
53. ユーザーストーリー単位のテスト設計イメージ 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 53 ユーザー ストーリー 運用手順 運用手順 運用手順 ・ ・ ・ ・ ・ ・ 機能要件 非機能要件 ・ ・ ・ ・ ・ ・ テスト観点 テスト観点 テスト観点 ・ ・ ・ ・ ・ ・ ユーザー ストーリー
54. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 54 開発メンバーが実装前に テスト設計をレビュー QA 開発 開発観点から評価して 欲しい点のフィードバック 実装前から 評価内容を把握
55. ユーザーストーリー開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 55 仕様設計 詳細設計 テスト設計 実装 テストケース 評価 バグ修正 仕 様 レ ビ ュ ー テ ス ト 設 計 レ ビ ュ ー PO QA 開発
56. フィードバックループで開発が得たもの 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 56  ユーザー視点の大切さに気付けた  評価内容を設計の段階から知ることができ、QA評価前にBugが潰せた （QA前品質向上）  開発→QAに対して評価してほしいことを気軽にお願いできる  近くにいるため、Bugの修正内容をチケット更新だけでなく口頭で伝え られる．Bug発生時の動作が把握しやすい。記憶の新しいうちに対応が でき認識間違いが減る．従って、手戻りが減る  困っていることがあればすぐに相談できるため、悩みの解決スピードが 速い
57. フィードバックループでQAが得たもの 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 57  テスト設計レビューを通して、開発視点から指摘をもらえることで、テスト設 計の精度が上がって嬉しい  仕様の認識間違いがQA前に解消できるため、QA前に品質の高いものが開 発から出てくる。  その結果、基本動作Bugが減り、本当に時間をかけたい異常系や性能評価、ワーク フローや長期安定性評価に時間をかけることができて嬉しい  テスト設計レビューで、評価内容を相手に正確に伝えることを意識するため、 仕様の理解がより深まる。
58. ユーザーストーリー開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 58 仕様設計 詳細設計 テスト設計 実装 テストケース 評価 バグ修正 仕 様 レ ビ ュ ー テ ス ト 設 計 レ ビ ュ ー PO QA 開発
59. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 59 ユーザーストーリーのDoneの定義 「QA評価のテスト完・Ｂｕｇゼロ」 機能 ワークフロー 性能 長期安定性 負荷 ユーザビリティ
60. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 60 案の定 テストが終わらない問題発生 QAメンバーから泣きのHELPあり
61. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 61 負荷テストや長期安定性などの テストケースまで 全て実施してみようと試みたが、 現実的ではなかった
62. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 62 スプリント開発プロセス Before スプリント スプリント スプリント プロダクトバックログ スプリント バックログ ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 スプリント ＵＳ開発 機能 ワーク フロー 性能 ユーザ ビリティ 長期 安定性 負荷
63. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 63 スプリント開発プロセス After スプリント スプリント スプリント テストスプリント プロダクトバックログ スプリント バックログ ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 ＵＳ開発 システムテスト 機能 USワーク フロー 性能 ユーザ ビリティ 長期 安定性 負荷 全体ワーク フロー QA-in 計画をし 合意
64. テストスプリントバックログ スプリント スプリント スプリント スプリント スプリント スプリント スプリント スプリント プロダクトバックログ スプリント バックログ システム テスト テストスプリント バックログ 2014/1/30 東芝SPIシンポジウム2014 copyright © A.Nagata 64
65. やれるところからテストしていこう Pattern: Time to Test The Pattern Almanac, 2000 Linda Rising 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 65 いつ何のテストができるのか、 設計と合意を取って行おう テスト計画は、設計の進捗、状態により 柔軟に見直していかなければならない 関連：機が熟すのを待て : Take Time
66. バグの発生分布 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 66
67. QA-in以降のバグの分布（基本機能かどうか） 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 67 基本機能のバグは、QA-in前の評価で取られている または、初めから入りこんでいない
68. バーンアップチャート 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 68
69. コード品質の変化： 2013年のプロジェクトと比較 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 69 バグが６５％減少 コード品質が改善 した
70. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 70 こうしてｌフィードバックと振り返りを 繰り返していった結果。
71. ユーザーストーリー単位の開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 71 Ｐ Ｏ デ モ 仕様設計 詳細設計 テスト設計 実装 テストケース 評価 バグ修正 仕 様 レ ビ ュ ー PO QA 設計 テ ス ト 設 計 レ ビ ュ ー
72. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 72 QAのテストケース 製品の詳細な振る舞いの 仕様書となった 開発部隊はそれを 開発のリファレンスにするようになった
73. ユーザーストーリー単位の開発プロセス 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 73 Ｐ Ｏ デ モ 仕様設計 詳細設計 テスト設計 実装 テストケース 評価 バグ修正 仕 様 レ ビ ュ ー PO QA 設計 フィードバックにより仕様変更を常に許容 テ ス ト 設 計 レ ビ ュ ー
74. ATDD（Acceptance Test Driven Development) 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 74 Ｐ Ｏ デ モ 仕様設計 詳細設計 テスト設計 実装 テストケース 評価 バグ修正 仕 様 レ ビ ュ ー PO QA 設計 フィードバックにより仕様変更を常に許容 テ ス ト 設 計 レ ビ ュ ー
75. ATDD 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 75  本来Acceptance Testは顧客がやるもの  QAが顧客顧客の肩代わりとして、 システムの振る舞いを含めた品質＝価値を評価  開発者は迷わず開発を進められる  ゴールは、合意されたもの
76. QAの役割 2016/12/16 第32年度ソフトウェア品質管理研究会 copyright © A.Nagata 76 顧客からのフィードバックを早くできるだけ早く得たい 評価してもらうレベルまで上げておかなければならない まず、顧客の肩代わりとして、 顧客に評価してもらうレベルまで上げていくため 顧客視点での品質のフィードバックを返していく バグの潜在時間をできるだけ短くする 早くフィードバックして品質を上げていく
77. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 77 ポイント 一晩でできたことではない！ 最初は、不完全なもの QAも巻き込み、 フィードバック、振り返りを繰り返し 少しづつ変えていった結果
78. 課題 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 78  まだSMへの依存度が高く、自立できていない  組織変更によるチームメンバーの出入りでベロシティが下がる  レビューの総時間が増えた  費用対効果は高いため、問題ではないが、さらなる効率化をという点での課題で はある  ベロシティーがなかなかあがらない  スクラムはどうしても人に依存するため、全体最適の視点で自立的に 動ける人材（PL含む）の育成にかなりの労力を費やしている  このようなアジャイルチームになるには、Agileの普及活動含め時間が かかる．
79. DevQA : アジャイル開発における設計とQAのコラボレーション 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 79 設計 QA 品質の 見える化 開発のリファレンス  テスト  測定  テストケース サポート Deploy 評価環境 暗黙的共有 リスク 課題 アクション 信頼関係 フィードバックでもたらされた情報 ＋ 合意された形式的情報 （開発,PO）
80. アジャイルにおけるQA 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 80 QA 顧客に変わって 品質の状態をフィードバックする デリバリの判断の情報を説明報告する 品質の目標、構想、計画を立てる
81. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 81 Linda Rising, 2004
82. 早いうちから巻き込め Pattern: Pattern: Get Involved Early The Pattern Almanac, 2000 Linda Rising 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 82  早い段階で設計者と関係を構築しておく  例  設計者とともに、システムやフィーチャを学ぶ  要求仕様や設計ドキュメントのレビューに参加する  テスト計画のレビューに設計者を招待する  あなたが設計者と関係を持たなければならないと気付いてからでは遅すぎる  信頼を得るためには時間がかかるから。 設計チームからのサポートを最大限引き出したい
83. アジャイルにおけるQA 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 83 アジャイル開発において ＱＡはなくてはならない チームのメンバーです よろしく
84. 2017/1/14 スクラム冬の陣2017 copyright © A.Nagata, 84 ご清聴ありがとうございました