開発とQAが分かれたスクラム チームを解消する第一歩 Regional Scrum Gathering℠ Tokyo 2022 2022.1.5

AGENDA ◼ 自己紹介 ◼ One Teamな状態 ◼ 開発とQAが分かれる理由 ◼ One Teamとなるための準備 ◼ One Teamがもたらす恩恵 1

2 自己紹介 ◼ 名前：船橋 篤史 ◼ 所属：株式会社SHIFT ◼ 経歴： ◼ アジャイル開発体制構築、テスト自動化 ◼ Windowsネイティブアプリケーションのクラウドリフト ◼ Webアプリケーションのクラウドシフト ◼ 基幹システム構築 ◼ etc…

3 ソフトウェアの「品質保証」を手がける会社 【会社説明】株式会社SHIFTとは

4 「ONE-SHIFT」サービス 【会社説明】関連会社について SHIFTグループ全体で連携し、サービス開始から運用まで 全てをサポートできる 「ONE-SHIFT」サービスを目指している。

5 One Teamな状態

6 「スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者 で構成される。」(Scrum Guide 2020年11月版より引用) 担当問わずチームとして知識向上が見込め、共通のプロダクトゴール、スプリントゴー ルへ向かってるとOne Teamな集団と言えるはずです Scrum Guideをもとに https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf PO SM 開発者 スクラムチーム Designer Programmer Tester 問わず開発者です One Teamな状態

7 って済むならこのセッションはやってません 当社へ相談される方々の多くは「開発者」が「プログラマー」に閉じている傾向にあり ます Fin？ One Teamな状態

8 開発とQAが分かれる理由

9 ウォーターフォール型のときこんなイメージありませんか？ V字モデルから考える 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト 開発とQAが分かれる理由 開発が担当 品証が担当

10 開発とQAには障壁がある ◼ 開発担当 vs 品質保証担当 ➢ 物理的な壁 ➢ 担当部署や担当企業の違い ➢ 関係性の壁 ➢ 成果物を作成する側と指摘する側の違い ➢ 作る側と利用する側(実際は利用しているつもり) ➢ よく知らない相手から指摘がくる ➢ そもそも品質保証担当がゲートキーパだったりする ➢ 後だしじゃんけん感がある ➢ etc... 開発とQAが分かれる理由

11 従来の開発チーム部分だけでScrumを組んでしまう 障壁を解体せずにScrumを組んでしまう 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト 開発とQAが分かれる理由 ここだけ Scurmチーム化 なぜか取り残 される 従来の 開発チームだけで 挑戦する

12 実際に存在するパターン 開発とQAが分かれる理由 スプリントＮ スプリントＮ+1 スプリントＮ+2 スプリントＮ+3 No 開発１ ＱＡ 開発２ 開発３ 結局最後にテスト 1

13 One Teamとなるための準備

14 当たり前ですが、全体でScrumを組む つまり 要求 要件定義 基本設計 詳細設計 コーディング 結合テスト 単体テスト 総合テスト 受入テスト One Teamとなるための準備 Scurmチーム化

15 全体でScrumを組むことでスプリントゴール、プロダクトゴールに向き合える つまり One Teamとなるための準備 開発１ ＱＡ１ 開発２ ＱＡ２ 開発３ ＱＡ３ スプリントＮ スプリントＮ+1 スプリントＮ+2 スプリントＮ+3 スプリントを輪唱 開発とQAが 協力して活動する 開発１ ＱＡ１ 開発２ ＱＡ２ 開発３ 2 3 No ＱＡ３ 開発１ ＱＡ 開発２ 開発３ 結局最後にテスト 1 これだけが Scrum だけど、妥協して ここからスタートも可

16 QAが上流から入ることで～ってよく言いますが、異物混入でしかないため 壁はそう簡単に破壊できない チームビルディングのときから一緒になる必要がある チームビルディング時にどう検討すべきかが解決の鍵 開発とQA分かれていたのにどうやって一緒になるの？ One Teamとなるための準備

17 チームビルディングでしっかりとテスト戦略を考える 振り返りやバックログリファインメントでテスト戦略を考慮する 戦略、スプリント活動両方を考える One Teamとなるための準備 テスト戦略 スプリント Start テストタイプ・レベル 整理 テストアプローチ 検討 完成の定義 検討 PBIのテスト方針 検討 テスト計画 テスト分析・設計 テスト実装・実行 テストレビュー

18 チームビルディング時 or 適宜 スキルマップ作りますよね？ システム構成を検討しますよね？ これらの情報から必要なテストタイプを洗い出す テストレベルを整理する ※アジャイルだとテストレベルはテストタイプに溶け込みそう テストタイプ、レベルの整理 One Teamとなるための準備

19 テストアプローチの検討 ◼ テストアプローチとは 特定のプロジェクト、リリース用にテスト戦略をテーラリングしたもの (JSTQBより) ➢ 分析的アプローチ ➢ モデルベースドアプローチ ➢ プロセス準拠アプローチ ➢ etc... このタイミングのテストアプローチは↑↑↑ではなく↓↓↓ ◼ テストアプローチとは テストの方法です (A new model for test strategies より) 各テストタイプどういった方法で実施するか検討する ➢ Scripted Approach（手動テスト） ➢ Automation Approach（自動テスト） ➢ Exploratory Approach（探索的テスト） One Teamとなるための準備 https://danashby.co.uk/2017/12/13/a-new-model-for-test-strategies/ http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

20 チームビルディングの過程で ◼ 構成管理（ブランチ戦略など） ◼ 不具合管理 ◼ etc... 色々決めていくと思います。 検討したテストタイプをどのタイミングで実施するのかも完成の定義に含めて しまう 完成の定義に含めなかったテストタイプは品質バックログとしてリストアップ し、どこかのスプリントで解決させる 完成の定義の検討 One Teamとなるための準備

21 PBIのテスト方針検討 バックログリファインメントにおいて ◼ 実現した際の価値 ◼ 対応内容 ◼ 受入基準 ◼ etc... 色々決めていくなかでINVESTという特性を考慮すると思いますが、Testableを意 識する つまり、それぞれのバックログで実施が必要なテストタイプまでチームで認識 を合わせる One Teamとなるための準備

22 いざリファインメントしてみたら考慮不足などあると思います 見ないふりせずしっかり向き合いましょう PBIのテスト方針検討後振り出しに戻ることもある One Teamとなるための準備 テスト戦略 スプリント Start テストタイプ・レベル 整理 テストアプローチ 検討 完成の定義 検討 PBIのテスト方針 検討 テスト計画 テスト分析・設計 テスト実装・実行 テストレビュー

23 スプリント スプリントでは ◼ QAもスプリントイベントに参加する ◼ レトロスペクティブなどでテスト戦略を見直すときは全員で考える ◼ テストのレビューはスプリントレビューではない といったことに注意して活動しましょう One Teamとなるための準備

24 One Teamがもたらす恩恵

25 ◼ Whole Team ➢ プロセス全体に品質が組み込まれる ➢ チーム全体の品質に関する知識が向上 ➢ プロダクトの成長とともにテストも成長 高品質なプロダクトをつくる活動へつながる プロダクトの価値や品質がわかるだけ？ One Teamがもたらす恩恵

26 最後に

27 ◼ あくまでスターターキット ◼ チームが自律していくにつれプロセスは変化し 昇華していく 最後に

28 宣伝 スクラムマスター認知度向上のためのマンガです。 アジャイル開発のあるあるを異世界で展開しています。 スクラムマスターを知ってる人も知らない人も楽しめるストーリーです。 スクラムマスターのマンガ、つくりました。 https://isekai-scrum.com/ 内容はこちらから👇

29 We are Hiring!!! スクラムマスター募集 スクラムマスターとしてSHIFTで成長できる4つの理由 【カジュアル面談実施中】 スクラムマスターのキャリアにご興味が あるかた、ご連絡お待ちしております！ 詳細はこちらから👉 1 2 4 エンタープライズから中小企業までお客様は 2,000社以上。いろんな案件にチャレンジできる。 アジャイル開発の注目トレンドは品質。 最先端のノウハウをみにつけられる。 外部への情報発信の場が多数。 3 経験豊富なスクラムマスターが活躍中。 実践的なアドバイスがもらえる。 https://topics.shiftinc.jp/recruit-scrum/

No content