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

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

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