Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ここからはじめるスクラムQA(増補改訂版) / Getting started with QA in Scrum (revised)

77fa3ebbf229a884c74c905034b1f4c2?s=47 akihisa1210
October 09, 2019
410

ここからはじめるスクラムQA(増補改訂版) / Getting started with QA in Scrum (revised)

Cybozu QA Meetup #01 in Osaka で使った資料です。
https://cybozu.connpass.com/event/145042/
https://speakerdeck.com/ak1210/getting-started-with-qa-in-scrum に少し内容を追加しています。

77fa3ebbf229a884c74c905034b1f4c2?s=128

akihisa1210

October 09, 2019
Tweet

Transcript

  1. ここから始めるスクラム QA (増補改定版) 2019-10-09 Cybozu QA Meetup #01 in Osaka

    小山 晃久 @akihisa1210
  2. 自己紹介 • 小山 晃久 @akihisa1210 • Garoon チーム / 生産性向上チーム(New!)

    • Garoon 開発チームで、品質に関わることを色々やっています • テスト(管理~設計~実行) • CI/CD 改善 • 勉強会 • など…… • 趣味は読書 • 人文書も技術書も読む • 読書会の運営サポートもやってます!
  3. 話すこと • QA チームを含むスクラムチームで開発を行う上で、やってよ かったこと • そこから考える QA のキャリアの一例 •

    次なる課題
  4. None
  5. None
  6. None
  7. 前提: ウォーターフォールからスクラムへ • 約2年前にスクラムを導入 • 背景 • パッケージビジネスからクラウド・サブスクリプションビジ ネスへの重点の変化 •

    スクラム導入前の体制 • 長い開発フェーズの後に長いテストフェーズが控えていた • 組織上でも開発担当者と QA 担当者は別々の部署に属してい た
  8. 前提: ウォーターフォールからスクラムへ • スクラム導入後の体制 • スクラムチームは日本3チーム、ベトナム5チーム • 1スプリントは1週間 • QA

    も各スクラムチームに所属 • ご注意 • ウォーターフォール型の開発体制をもつ組織にスクラムを導入した、というのが以下 の話の前提です。そのため、スクラムのプラクティスになじまない(そして上手く 行ったり上手く行っていなかったりする)既存の諸プロセスとの格闘が以下の話にも 反映されています。最初からスクラムを導入していた組織の方から見ると違和感のあ る箇所があるかもしれません。
  9. QA はどうするか • 「テスティング、アーキテクチャ、運用、ビジネス分析のような 専門領域であっても、スクラムは開発チームのサブチームを認め ていない。」(「スクラムガイド」(2017年11月版)https://www.scrumguides.org/docs/scrumguide/v2017/2017- Scrum-Guide-Japanese.pdf) • ではどうするか •

    スクラムガイドは答えを教えてくれない
  10. QA を含めたスクラムチームで開発を行う上で、 やってよかったこと

  11. 開発チームに所属する • チーム間の情報の受け渡しのコストは大きい • 物理的・心理的距離を近くできる • 問題が発生したときに、素早く動くことができる

  12. 完了の定義にテストも含める • テストまで終わって初めて PBI が完了になる、という共通認識を 作る • 「実装完了」を「PBI 完了」とみなし、テストをその外に出して しまうと、フィードバックが遅くなる

    • 「テストに時間がかかって PBI がなかなか完了しない」という問 題に、チームとして立ち向かえるようにする
  13. スプリントプランニングでテスト分析・テスト設計を始める • スプリントプランニングは、PBI を完了させるために必要な情報 が集まるスクラムイベント • テスト分析・テスト設計をその場で行いながら、疑問点を解消す る • QA

    が気になることは何かがチーム全体に伝わる
  14. チーム内の問題はチーム内で相談できる環境を作る • 問題を抱え込むとつらい • テストや品質の話題もふりかえりに上げてしまう • 副産物として、必要だと思っていたが不要なタスク、不要だと 思っていたが必要なタスクに気づける

  15. テストについての情報を共有する • スクラムを採用すると、テストや品質について説明をする機会が (望むと望まざるとにかかわらず)増える • 先にこちらから情報を共有してしまう • 情報を提供すると、情報を得られる

  16. スクラムによる問題の顕在化

  17. これらは全て、スクラムによって問題が顕在化しただけ • 新しい問題が発生したというよりは、これまで隠されていた問題 が顕在化された • 情報の受け渡しにコストがかかっている • PBI の完了条件にテストが含まれていない •

    PG は QA の業務を、QA は PG の業務を知らない
  18. 次なる問題の顕在化 • 開発 vs. QA という構図から、プロダクト開発を妨げるもの vs. 開 発チームという構図に移行しつつある •

    プロダクト開発を妨げるもの • 技術的負債 • リリース前に必要なタスクの山 • 自分は今はこれらの問題を解消するために、CI/CD の改善に取り 組んでいます。生産性向上!
  19. QA のキャリア(一例)

  20. 参考資料 • QA・テストエンジニアのキャリアに関する包括的な話は、以下 の資料がわかりやすい • 植月啓次「新時代で活躍するためのテストエンジニアのキャ リアのつくりかた」(JaSST’19 Kansai) • https://speakerdeck.com/keijiuetsuki/xin-shi-dai-dehuo-yue-

    surutamefalsetesutoenziniafalse-kiyariafalsetukurikata
  21. QA の自分のキャリア観 • 大切にしていること • 品質のためにできることは、テストだけではない • とはいえもちろんテストも重要 • 良さ/悪さの情報を適切なタイミングでフィードバックする

    or フィードバックする仕組みを作ることを仕事にしていきたい、と 思うようになった
  22. 次なる課題

  23. スプリント内/外のテストと開発チーム内/外のテスト • リリースに必要なテストは、できるだけスプリント内に含めるようにしたい • リグレッションテスト、セキュリティテスト、パフォーマンステスト、 …… • しかし、今は開発チームがこれらのテストをすべて自分たちだけでできるよ うにはなっていない •

    例えばセキュリティテストは、PSIRT(セキュリティ検証を行う横断 チーム)によって行われている • どうすればスプリント外/開発チーム外のテストをスプリント内/開発チーム 内に持ち込めるか考える必要がある • どのような体制がふさわしいのか • あるいは、本当に持ち込むべきなのか?
  24. 最後に

  25. 今日話したこと • QA チームを含むスクラムチームで開発を行う上で、やってよかった こと • 開発チームに所属する • 完了の定義にテストも含める •

    スプリントプランニングでテスト分析・テスト設計を始める • チーム内の問題はチーム内で相談できる環境を作る • テストについての情報を共有する • そこから考える QA のキャリアの一例 • スプリントとスクラムチームの外にあるテストという課題
  26. We are hiring! • スクラム開発をやってみたい方 • 開発者と(心理的にも物理的にも)近い距離で品質保証活動を やってみたい方 • テスト分析力・テスト設計力を発揮する場所を求めている方

    • モブワークに興味がある方 • 全体最適を考えて改善するのが好きな方 • お待ちしております!