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

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

Transcript

1. なんたって”DevQA”
   アジャイル開発とQAの合体が改善を生む
   アジャイルの特性を生かしたチーム作りと品質の改善
   スクラム冬の陣2017 copyright © A.Nagata,
   1
   www.vandalsrugby.ca
   2017/1/14
   

   View Slide

2. 自己紹介
   ソニー株式会社
   IP&S 品質保証・サービスオペレーション部門
   PS-システムクオリティ部SQM課
   永田 敦
   アジャイルソフトウェア開発
   改善サポート、コーチング
   JSTQB
   Advanced Level Test Manager
   第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
   2
   2016/12/16
   

   View Slide

3. 自己紹介
   アジャイルの流儀：EVO
   現場モード：Stealth
   copyright © A.Nagata
   3 2015 /1/30
   Agile RCA
   Agile Inspection Maestro
   

   View Slide

4. ソニープロフェッショナルプロダクツ
   2017/1/14
   スクラム冬の陣2017 copyright © A.Nagata,
   4
   

   View Slide

5. アジャイル開発の実態
   QAから見たアジャイル開発
   2016/12/16
   第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
   5
   

   View Slide

6. スクラム
   スプリント スプリント スプリント
   プロダクトバックログ
   スプリント
   バックログ
   2017/1/14
   スクラム冬の陣2017 copyright © A.Nagata,
   6
   

   View Slide

7. スクラム
   スプリント スプリント スプリント
   プロダクトバックログ
   スプリント
   バックログ
   システムテスト
   出荷
   2017/1/14
   スクラム冬の陣2017 copyright © A.Nagata,
   7
   

   View Slide

8. システムテストをやっているがバグが流出
   2017/1/14
   スクラム冬の陣2017 copyright © A.Nagata,
   8
   プロダクトバックログ
   スプリント
   バックログ
   実施
   出荷
   システム
   テスト テスト分析/設計
   バグ流出
   市場
   障害
   

   View Slide

9. もし品質が悪いと
   プロダクトバックログ
   スプリント
   バックログ
   実施
   出荷予定
   システム
   テスト テスト分析/設計
   バグ
   デバッグ
   9
   実施 実施
   2017/1/14
   スクラム冬の陣2017 copyright © A.Nagata,
   

   View Slide

10. 設計フェーズからシステムテストを実施する
    スプリント スプリント スプリント スプリント
    プロダクトバックログ
    スプリント
    バックログ
    スプリント スプリント スプリント スプリント
    システム
    テスト
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    10
    実施
    テスト分析/設計 実施 実施
    

    View Slide

11. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    11
    もっと早いタイミングで
    評価しよう
    設計フェーズに飛び込む
    

    View Slide

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

    View Slide

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

    View Slide

14. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    14
    QAが設計に入ってくる
    いろいろ言われるのではないか
    あれを出せこれを出せ
    あれを測れこれを測れ
    あれを直せこれを直せ
    設計に余計な負荷がかかる
    設計リーダーの憂鬱
    固い
    ガード
    QA
    

    View Slide

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

    View Slide

16. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    16
    チームのその後の話です。
    

    View Slide

17. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    17
    次の挑戦
    仕様の無駄をなくしたい
    

    View Slide

18. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    18
    皆が自然と助け合える
    プロセスを考えてみました。
    

    View Slide

19. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    19
    スプリント開発プロセス
    スプリント スプリント スプリント
    プロダクトバックログ
    スプリント
    バックログ
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    スプリント
    ＵＳ開発
    

    View Slide

20. ユーザーストーリー開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    20
    仕様設計
    詳細設計
    テスト設計
    仕
    様
    レ
    ビ
    ュ
    ー
    PO
    QA
    開発
    

    View Slide

21. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    21
    しかし、そんな矢先に
    組織が変わってしまいました
    orz
    

    View Slide

22. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    22
    今のQAが去り、
    別の人がチームに参入することに。
    

    View Slide

23. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    23
    新しいQAの人はドメイン知識を持っていない．
    新しいQAの人はドメイン知識を持っていない．
    もちろん、DevQA、アジャイルテストも初めて
    

    View Slide

24. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    24
    スクラムマスタ（SM)が
    QAの人と一緒にQAをしてみた。
    

    View Slide

25. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    25
    テストの
    ペア設計
    (ペアプロ）
    

    View Slide

26. ユーザーストーリー開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    26
    仕様設計
    詳細設計
    テスト設計
    仕
    様
    レ
    ビ
    ュ
    ー
    PO
    QA
    開発
    

    View Slide

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

    View Slide

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

    View Slide

29. ユーザーストーリー単位のテスト設計イメージ
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    29
    ユーザー
    ストーリー
    運用手順
    運用手順
    運用手順
    ・
    ・
    ・
    ・
    ・
    ・
    機能要件
    機能要件
    ・
    ・
    ・
    ・
    ・
    ・
    ユーザー
    ストーリー
    

    View Slide

30. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    30
    次にそのテスト設計に
    QAが主導で、評価観点を肉付けした
    

    View Slide

31. ユーザーストーリー単位のテスト設計イメージ
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    31
    ユーザー
    ストーリー
    運用手順
    運用手順
    運用手順
    ・
    ・
    ・
    ・
    ・
    ・
    機能要件
    非機能要件
    ・
    ・
    ・
    ・
    ・
    ・
    テスト観点
    テスト観点
    テスト観点
    ・
    ・
    ・
    ・
    ・
    ・
    ユーザー
    ストーリー
    

    View Slide

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

    View Slide

33. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    33
    テスト設計による、QAとPOのフィードバックループ
    QA PO
    QAが欲しい仕様の提示
    質問
    SM
    

    View Slide

34. ユーザーストーリー開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    34
    仕様設計
    詳細設計
    テスト設計
    仕
    様
    レ
    ビ
    ュ
    ー
    PO
    QA
    開発
    

    View Slide

35. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    35
    質問・提案
    QA
    SM
    仕様の説明
    PO
    テスト設計
    ユーザーストーリ・仕様
    テストケース
    仕様の改善
    育成
    

    View Slide

36. フィードバック獲得の設計
    2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    36
    三菱電機 細谷泰夫：斥候としてのアジャイルプロセス活用の提案 ：SPI Japan 2012
    

    View Slide

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

    View Slide

38. QAの役割
    2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    38
    顧客からのフィードバックを早くできるだけ早く得たい
    評価してもらうレベルまで上げておかなければならない
    まず、顧客の肩代わりとして、
    顧客に評価してもらうレベルまで上げていくため
    顧客視点での品質のフィードバックを返していく
    バグの潜在時間をできるだけ短くする
    早くフィードバックして品質を上げていく
    

    View Slide

39. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    39
    SMとQAの関係
    さらに、POの仕様レビューにQAも一緒に参加
    仕様の理解に徹する
    

    View Slide

40. ユーザーストーリー開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    40
    仕様設計
    詳細設計
    テスト設計
    仕
    様
    レ
    ビ
    ュ
    ー
    PO
    QA
    開発
    

    View Slide

41. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    41
    POはQAと開発からフィードバックを受けるように
    開
    発
    観
    点
    の
    フ
    ィ
    ー
    ド
    バ
    ッ
    ク QA
    PO
    開発
    仕
    様
    の
    レ
    ビ
    ュ
    ー
    顧
    客
    観
    点
    の
    フ
    ィ
    ー
    ド
    バ
    ッ
    ク
    

    View Slide

42. ユーザーストーリー開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    42
    仕様設計
    詳細設計
    テスト設計
    仕
    様
    レ
    ビ
    ュ
    ー
    PO
    QA
    開発
    

    View Slide

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

    View Slide

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

    View Slide

45. “仕様通り”という理由で開発から返されるバグ報告の量の比較
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    45
    

    View Slide

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

    View Slide

47. 暗黙知 ： コンテキスト
    47 2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    暗黙知
    

    View Slide

48. 暗黙知によるコミュニケーション
    48 2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    暗黙知
    

    View Slide

49. 設計のための情報をチームで共有している
    49 2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    暗黙知
    形式知
    

    View Slide

50. 想定外の暗黙知の齟齬
    50 2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    暗黙知
    

    View Slide

51. 暗黙知齟齬をふせぐ
    51 2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    スクラム
    フレームワーク
    デイリー
    ミーティング
    スプリント計画
    スプリントレビュー
    振り返り
    DevQA
    暗黙知
    

    View Slide

52. 開発メンバーがテスト設計をレビュー
    2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    52
    開発メンバー
    どんなテストしようとしているのか
    無駄なテストをしていないか？
    

    View Slide

53. ユーザーストーリー単位のテスト設計イメージ
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    53
    ユーザー
    ストーリー
    運用手順
    運用手順
    運用手順
    ・
    ・
    ・
    ・
    ・
    ・
    機能要件
    非機能要件
    ・
    ・
    ・
    ・
    ・
    ・
    テスト観点
    テスト観点
    テスト観点
    ・
    ・
    ・
    ・
    ・
    ・
    ユーザー
    ストーリー
    

    View Slide

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

    View Slide

55. ユーザーストーリー開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    55
    仕様設計
    詳細設計
    テスト設計
    実装
    テストケース 評価
    バグ修正
    仕
    様
    レ
    ビ
    ュ
    ー
    テ
    ス
    ト
    設
    計
    レ
    ビ
    ュ
    ー
    PO
    QA
    開発
    

    View Slide

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

    View Slide

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

    View Slide

58. ユーザーストーリー開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    58
    仕様設計
    詳細設計
    テスト設計
    実装
    テストケース 評価
    バグ修正
    仕
    様
    レ
    ビ
    ュ
    ー
    テ
    ス
    ト
    設
    計
    レ
    ビ
    ュ
    ー
    PO
    QA
    開発
    

    View Slide

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

    View Slide

60. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    60
    案の定
    テストが終わらない問題発生
    QAメンバーから泣きのHELPあり
    

    View Slide

61. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    61
    負荷テストや長期安定性などの
    テストケースまで
    全て実施してみようと試みたが、
    現実的ではなかった
    

    View Slide

62. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    62
    スプリント開発プロセス Before
    スプリント スプリント スプリント
    プロダクトバックログ
    スプリント
    バックログ
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    ＵＳ開発
    スプリント
    ＵＳ開発
    機能
    ワーク
    フロー
    性能
    ユーザ
    ビリティ
    長期
    安定性
    負荷
    

    View Slide

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

    View Slide

64. テストスプリントバックログ
    スプリント スプリント スプリント スプリント
    スプリント スプリント スプリント スプリント
    プロダクトバックログ
    スプリント
    バックログ
    システム
    テスト
    テストスプリント
    バックログ
    2014/1/30
    東芝SPIシンポジウム2014 copyright © A.Nagata
    64
    

    View Slide

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

    View Slide

66. バグの発生分布
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    66
    

    View Slide

67. QA-in以降のバグの分布（基本機能かどうか）
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    67
    基本機能のバグは、QA-in前の評価で取られている
    または、初めから入りこんでいない
    

    View Slide

68. バーンアップチャート
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    68
    

    View Slide

69. コード品質の変化： 2013年のプロジェクトと比較
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    69
    バグが６５％減少
    コード品質が改善
    した
    

    View Slide

70. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    70
    こうしてｌフィードバックと振り返りを
    繰り返していった結果。
    

    View Slide

71. ユーザーストーリー単位の開発プロセス
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    71
    Ｐ
    Ｏ
    デ
    モ
    仕様設計
    詳細設計
    テスト設計
    実装
    テストケース 評価
    バグ修正
    仕
    様
    レ
    ビ
    ュ
    ー
    PO
    QA
    設計
    テ
    ス
    ト
    設
    計
    レ
    ビ
    ュ
    ー
    

    View Slide

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

    View Slide

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

    View Slide

74. ATDD（Acceptance Test Driven Development)
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    74
    Ｐ
    Ｏ
    デ
    モ
    仕様設計
    詳細設計
    テスト設計
    実装
    テストケース 評価
    バグ修正
    仕
    様
    レ
    ビ
    ュ
    ー
    PO
    QA
    設計
    フィードバックにより仕様変更を常に許容
    テ
    ス
    ト
    設
    計
    レ
    ビ
    ュ
    ー
    

    View Slide

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

    View Slide

76. QAの役割
    2016/12/16
    第32年度ソフトウェア品質管理研究会 copyright © A.Nagata
    76
    顧客からのフィードバックを早くできるだけ早く得たい
    評価してもらうレベルまで上げておかなければならない
    まず、顧客の肩代わりとして、
    顧客に評価してもらうレベルまで上げていくため
    顧客視点での品質のフィードバックを返していく
    バグの潜在時間をできるだけ短くする
    早くフィードバックして品質を上げていく
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

83. アジャイルにおけるQA
    2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    83
    アジャイル開発において
    ＱＡはなくてはならない
    チームのメンバーです
    よろしく
    

    View Slide

84. 2017/1/14
    スクラム冬の陣2017 copyright © A.Nagata,
    84
    ご清聴ありがとうございました
    

    View Slide