Regional Scrum Gathering Tokyo 2022の登壇資料です。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16155/qa
開発とQAが分かれたスクラムチームを解消する第一歩Regional Scrum Gathering℠ Tokyo 20222022.1.5
View Slide
AGENDA◼ 自己紹介◼ One Teamな状態◼ 開発とQAが分かれる理由◼ One Teamとなるための準備◼ One Teamがもたらす恩恵1
2自己紹介◼ 名前:船橋 篤史◼ 所属:株式会社SHIFT◼ 経歴:◼ アジャイル開発体制構築、テスト自動化◼ Windowsネイティブアプリケーションのクラウドリフト◼ Webアプリケーションのクラウドシフト◼ 基幹システム構築◼ etc…
3ソフトウェアの「品質保証」を手がける会社【会社説明】株式会社SHIFTとは
4「ONE-SHIFT」サービス【会社説明】関連会社についてSHIFTグループ全体で連携し、サービス開始から運用まで全てをサポートできる 「ONE-SHIFT」サービスを目指している。
5One Teamな状態
6「スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。」(Scrum Guide 2020年11月版より引用)担当問わずチームとして知識向上が見込め、共通のプロダクトゴール、スプリントゴールへ向かってるとOne Teamな集団と言えるはずですScrum Guideをもとにhttps://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdfPOSM 開発者スクラムチームDesignerProgrammerTester問わず開発者ですOne Teamな状態
7って済むならこのセッションはやってません当社へ相談される方々の多くは「開発者」が「プログラマー」に閉じている傾向にありますFin?One Teamな状態
8開発とQAが分かれる理由
9ウォーターフォール型のときこんなイメージありませんか?V字モデルから考える要求要件定義基本設計詳細設計コーディング結合テスト単体テスト総合テスト受入テスト開発とQAが分かれる理由開発が担当 品証が担当
10開発とQAには障壁がある◼ 開発担当 vs 品質保証担当➢ 物理的な壁➢ 担当部署や担当企業の違い➢ 関係性の壁➢ 成果物を作成する側と指摘する側の違い➢ 作る側と利用する側(実際は利用しているつもり)➢ よく知らない相手から指摘がくる➢ そもそも品質保証担当がゲートキーパだったりする➢ 後だしじゃんけん感がある➢ etc...開発とQAが分かれる理由
11従来の開発チーム部分だけでScrumを組んでしまう障壁を解体せずにScrumを組んでしまう要求要件定義基本設計詳細設計コーディング結合テスト単体テスト総合テスト受入テスト開発とQAが分かれる理由ここだけScurmチーム化なぜか取り残される従来の開発チームだけで挑戦する
12実際に存在するパターン開発とQAが分かれる理由スプリントN スプリントN+1 スプリントN+2 スプリントN+3No開発1QA開発2開発3結局最後にテスト1
13One Teamとなるための準備
14当たり前ですが、全体でScrumを組むつまり要求要件定義基本設計詳細設計コーディング結合テスト単体テスト総合テスト受入テストOne Teamとなるための準備Scurmチーム化
15全体でScrumを組むことでスプリントゴール、プロダクトゴールに向き合えるつまりOne Teamとなるための準備開発1 QA1開発2 QA2開発3 QA3スプリントN スプリントN+1 スプリントN+2 スプリントN+3スプリントを輪唱開発とQAが協力して活動する開発1QA1開発2QA2開発323NoQA3開発1QA開発2開発3結局最後にテスト1これだけがScrumだけど、妥協してここからスタートも可
16QAが上流から入ることで~ってよく言いますが、異物混入でしかないため壁はそう簡単に破壊できないチームビルディングのときから一緒になる必要があるチームビルディング時にどう検討すべきかが解決の鍵開発と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となるための準備
21PBIのテスト方針検討バックログリファインメントにおいて◼ 実現した際の価値◼ 対応内容◼ 受入基準◼ etc...色々決めていくなかでINVESTという特性を考慮すると思いますが、Testableを意識するつまり、それぞれのバックログで実施が必要なテストタイプまでチームで認識を合わせるOne Teamとなるための準備
22いざリファインメントしてみたら考慮不足などあると思います見ないふりせずしっかり向き合いましょうPBIのテスト方針検討後振り出しに戻ることもあるOne Teamとなるための準備テスト戦略 スプリントStartテストタイプ・レベル整理テストアプローチ検討完成の定義検討PBIのテスト方針検討テスト計画テスト分析・設計テスト実装・実行テストレビュー
23スプリントスプリントでは◼ QAもスプリントイベントに参加する◼ レトロスペクティブなどでテスト戦略を見直すときは全員で考える◼ テストのレビューはスプリントレビューではないといったことに注意して活動しましょうOne Teamとなるための準備
24One Teamがもたらす恩恵
25◼ Whole Team➢ プロセス全体に品質が組み込まれる➢ チーム全体の品質に関する知識が向上➢ プロダクトの成長とともにテストも成長高品質なプロダクトをつくる活動へつながるプロダクトの価値や品質がわかるだけ?One Teamがもたらす恩恵
26最後に
27◼ あくまでスターターキット◼ チームが自律していくにつれプロセスは変化し昇華していく最後に
28宣伝スクラムマスター認知度向上のためのマンガです。アジャイル開発のあるあるを異世界で展開しています。スクラムマスターを知ってる人も知らない人も楽しめるストーリーです。スクラムマスターのマンガ、つくりました。https://isekai-scrum.com/内容はこちらから👇
29We are Hiring!!!スクラムマスター募集スクラムマスターとしてSHIFTで成長できる4つの理由【カジュアル面談実施中】スクラムマスターのキャリアにご興味があるかた、ご連絡お待ちしております!詳細はこちらから👉124エンタープライズから中小企業までお客様は2,000社以上。いろんな案件にチャレンジできる。アジャイル開発の注目トレンドは品質。最先端のノウハウをみにつけられる。外部への情報発信の場が多数。3 経験豊富なスクラムマスターが活躍中。実践的なアドバイスがもらえる。https://topics.shiftinc.jp/recruit-scrum/