Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 「開発がスクラム導入するんだって！試験どーしよ！？」 -サイボウズQAスクラム奮闘記-
Similar to 「開発がスクラム導入するんだって！試験どーしよ！？」 -サイボウズQAスクラム奮闘記- (20)
Recently uploaded
Recently uploaded (10)
「開発がスクラム導入するんだって！試験どーしよ！？」 -サイボウズQAスクラム奮闘記-
- 1. Agile Japan × JaSSTコラボ企画 「開発がスクラム導入するん だって！試験どーしよ！？」 -サイボウズQAスクラム奮闘記- 2018/03/07 JaSST’18 Tokyo
- 2. 登壇者 • 矢引 達教（サイボウズ） • 岡崎 一洋（サイボウズ） • 天野 祐介（サイボウズ、Agile Japan 実行委員） • 今村 博明（Agile Japan 実行委員長） • 和田 憲明（Agile Japan 実行委員）
- 3. タイムテーブル • 導入(5分) • 事例1: 2万社のユーザーを支える共通基盤 チームでスクラムをやってみて(40分) • 事例2: 複数拠点での大規模スクラムへの挑戦 (40分) • 質疑応答(5分)
- 6. 自己紹介 • 矢引達教 @yabbysan • サイボウズ株式会社 グローバル開発本部 東京品質保証部 • 2012年 新卒でサイボウズに入社、QA • 趣味：ヨガ
- 9. 大企業向けグループウェア メール共有システム 業務アプリ構築クラウド 中小企業向けグループウェア クラウドサービス cybozu.com • 2011年 サービス開始 • 導入社数 20,000社以上 • 契約ユーザーライセンス数 80万人以上 ※2017.12.30時点 ボウズマン
- 10. チームの開発体制 • cybozu.comの管理者機能の開発を担当 • ユーザー管理、セキュリティ設定など • 開発は日本、試験は日本+上海の2拠点 • 開発 5名 / QA 5名 / PO 1名
- 12. スクラム導入前
- 13. スクラム導入前の開発プロセス • ウォーターフォール • 開発期間が終わってから試験を開始 • 開発6週間、試験6週間 リ リ ー ス 6週間6週間 設計＆実装要件定義 テスト設計 テスト実行 （ リ リ ー ス に 向 け た 作 業 ）
- 14. 😢スクラム導入前の問題点 • バグの検出が遅い • 類似バグが複数箇所に埋め込まれてしまう • 実装担当者の記憶が薄れており調査に時間がかかる • 要件が曖昧なまま開発がスタート • 手戻りが発生しやすい • 開発とQAの隔たり感 • 実装期間が終わると開発者は次期版に着手 • 重要な情報がQAに伝わっていないことがある • 結合試験のタイミングについて連絡が漏れる
- 15. スクラムトレーニングを 受講
- 18. スクラム開始までの準備(1/4) • 『カンバン仕事術』の輪講 • 見える化 • WIP制限 • 同時に進める仕事の数を制限する • 仕事一つ一つが早く終る 👉スクラム関係なくおすすめ
- 20. スクラム開始までの準備(2/4) • Readyの定義の策定 • 開発チームが着手できるバックログの基準 • 「開発チームが納得できる ユーザーストーリーがある」 • 「受け入れ条件が定義されている」etc
- 21. スクラム開始までの準備(3/4) • スプリント単位での完了の定義の策定 • 何を持って「完了」とするかを定義したリスト • スプリント単位でどこまでやるか、の基準 • テストに関することをどこまで含めるか • 「テスト設計が完了する」？？ • 「(性能テストを含め)全てのテストが完了」？？
- 22. スクラム開始までの準備(3/4) • 開発チームの実力に合わせることが大事 • 完了の定義に含めなかったこと • 「テスト実行を完了する」 • 次のスプリントで完了することをチームの目標にした • 「脆弱性検証・性能検証を完了する」 • 社内の脆弱性検証チーム・性能検証チームが行う検証。 2,3スプリントまとめて実施するようにした • 完了の定義に含めたこと • 「テスト設計が完了している」etc
- 23. スクラム開始までの準備(4/4) • アジャイルQAの実践者の講演を聞く • 社内勉強会にお招きして講演して頂く • 株式会社日新システムズ 永田 敦 さん • QAから開発への 素早いフィードバック の重要性を認識 • 覚悟を決めた 社内勉強会の様子
- 24. スクラム導入後
- 25. スクラム導入後の開発プロセス • 1スプリント=2週間 • リリース単位は6スプリント+リリーススプリント …スプリント1 スプリント2 スプリント3 設計＆実装 テスト設計 テスト実行 設計＆実装 テスト設計 テスト実行 設計＆実装 テスト設計
- 26. スクラム導入の メリット
- 28. • 作り込まれたバグを早く検出できる • 実装完了からバグ検出までの期間が短縮 移行前: 28日 → 移行後: 7日 • 類似バグが量産されることを防ぐことができる • 開発者の記憶が新しいため問い合わせの返答が早い • 完了の定義に「テスト設計が完了する」を含めた • テスト実行は次のスプリントまでに完了することを目標にした バグの早期検出
- 29. • 認識の齟齬による手戻りの減少 • 非機能要件の漏れを早期に指摘できる • 脆弱性検証の担当者(社内)が要件検討会に参加 • セキュリティの観点を上流でチェックできる Readyの定義に受け入れ条件の明確化を含めた 要件の明確化
- 30. 開発チームの一体感 QA 開発 早めに動作確認しておきますね 試験しやすい機能を 追加するね 結合試験のタイミングに 注意した方がいいかも • QAは開発のリクエストに応えられるようになった • 開発はQAのことをより気にかけてくれるようになった
- 33. スクラム移行時に 直面した問題
- 34. • 実際に遭遇した問題を紹介します • グループワークの題材とします • 「自分だったらどう対応するか？」を 考えてみてください
- 35. グループ作成&自己紹介
- 37. 背景 • スクラム移行前のテスト設計プロセス • テスト設計レビューを2段階で実施 • テスト設計は上海QAが担当 • レビュー①は上海QAで担当（クロスチェック） • レビュー②は東京QAが担当 • 完了の定義に「テスト設計が完了すること」を含めた • レビュー②でボトルネックが深刻化 テスト 設計 テスト設計 レビュー① テスト設計 レビュー② テスト 実行 😊 😊 😊 😊上海QA(4名) 😓東京QA(1名) ボトルネック深刻化 私
- 38. 問題 「試験設計のボトルネックを解消するには？」 • 東京QAは1名のみ • 東京QAの増員は難しい • レビュー②でのレビュー観点 • テスト観点に不足は無いか（漏れがないか） • 東京QAに属人化している • 省略できる組み合わせは無いか（無駄は無いか） • 省略できそうな組合せがあれば開発者に質問する
- 39. • スクラム移行前のテスト設計プロセス • テスト設計レビューを2段階で実施 • レビュー①は上海QAで担当（クロスチェック） • レビュー②は東京QAが担当 • テスト観点に不足は無いか（漏れがないか） • 省略できる組み合わせは無いか（無駄は無いか） • 完了の定義に「テスト設計が完了すること」を含めた テスト 設計 テスト設計 レビュー① テスト設計 レビュー② テスト 実行 😊 😊 😊 😊上海QA(4名) 😓東京QA(1名) ボトルネック深刻化 問題 「試験設計のボトルネックを解消するには？」 ボトルネックを解消する案を考えて付箋に書き出してください （いくつ挙げてもOKです）
- 41. 開発(4名) 解決策：レビュー②の属人化を解消した • 漏れのチェックを前倒しで確認する • チェック観点をリストにしてレビュー①で確認する • 無駄のチェックを開発者に依頼する • 開発者にテスト設計レビューに参加してもらう テスト 設計 テスト設計 レビュー① テスト設計 レビュー② テスト設計 レビュー② テスト 実行 😊 😊 😊 😊上海QA(4名) 😓東京QA(1名) 😏 😏 😏 😏 無駄の チェック 漏れの チェック 漏れのチェック 無駄のチェック 廃止 NEW! 👉 👉
- 42. チームの問題はチームで解決する • チーム内で問題に対する共通認識を持つ • カンバンでチームの進捗を見える化 • チームで共通の理想を持つ • 完了の定義にテストに関することを含めて合意する • 職能間のスキルの障壁を下げる • 「QAしかできない」作業をできるだけ減らす • 開発者が見やすいように試験仕様書の形式をExcelからマインドマップに移行 QAのみで解決しようとせずに チーム全体で解決に取り組む
- 43. 課題 • リリースサイクルの短縮 • リリースに必要な試験の実施タイミングの調整 • 1スプリント内でテスト実行まで完了する • スプリント開始前のテスト工数の見積もり • 職能間のスキルの障壁を下げる • QAによるテスト自動化の推進 • 拠点間コミュニケーションのさらなる促進
- 44. まとめ • スクラム移行のためにやったこと • スクラム移行によるメリット • バグの早期検出 • 要件の明確化 • チームの一体感 • スクラムは問題発見のフレームワーク • チームの問題はチームで解決する イラスト提供：8suke/人物イラスト館 http://jinbutuillust.businesscatalyst.com
- 46. Agile Japan x JaSST JaSST’18 Tokyo 複数拠点での 大規模スクラムへの挑戦
- 47. 岡崎 一洋 サイボウズ株式会社 グローバル開発本部 東京品質保証部 副部長 いわゆるプレイングマネージャー ・サイボウズ Garoon QA責任者 ・スクラムマスター 長年QAをやっていたが、昨年からスクラムマスターも開始。 最近の楽しみは子どもを連れてウサギの散歩。 About me
- 48. Garoon とは？
- 51. Garoon の開発体制
- 53. ・開発モデルは一般的なウォーターフォール。 ・テストは海外がメインで日本QAはマネジメント中心。 ・リリースサイクルは6ヶ月ごと。 PM 日本 PG 日本 越南 中国 QA 日本 越南 中国 要件 実装 テスト SRE 日本 リリース 1ヶ月 2ヶ月 2ヶ月 1ヶ月 Garoon 開発チーム スクラム導入前
- 54. スクラム導入後 東京 (3チーム) 中国 (1チーム) 越南 (4チーム) ・(Nexus Integration Team) ・Jupiter Team ・Moon Team ・Mars Team ・Vela Team ・Draco Team ・Cetus Team ・Leo Team※Nexus Integration Teamは全体の統括を行っている 3拠点 8チーム ・各拠点ごとにスクラムチームを形成。 ・星をモチーフにしたチーム名を付けている。
- 55. 開発プロセス ・スプリントのタイムボックスは3週間。 ・リリースサイクルは3ヶ月ごと。 ・大規模スクラムのフレームワーク｢Nexus｣を採用。 ・リリース前のスプリントでは機能実装しない。 ・回帰テストや技術的負債の対応、次バージョンの準備など。 ※1スプリント=3week SP1 SP2 SP3 SP4 SP5 SP6 ･･･ リリース
- 58. 複数拠点大規模スクラムへの道のり
- 59. スクラム導入を決めたが… 導入
- 62. まずは日本のみスタート！ 導入
- 63. いきなり問題発生！
- 65. チームで話し合った結果… 導入
- 66. スクラムの基本に則るのは諦める ・スプリント完了時に出荷可能な状態。 ▶スプリント内では実装完了までとし、 次のスプリントでテスト設計/テスト実施。 ・チームメンバーが物理的に同じ場所にいる。 ▶テスト設計/テスト実施は海外拠点で行う。 導入 SP1 SP2 SP3 SP4 SP5 SP6 SP1で実装したものをSP2でテスト SP2で実装したものをSP3でテスト
- 67. 数スプリント回した結果
- 72. 海外展開時にやったこと 海外展開
- 77. QAはどうだったか？ 海外展開
- 80. SP4 SP5 SP7 SP9 SP3から 海外展開 探索的テスト 取り入れ SP内で テスト設計 PGテスト参加 カンバン統一 同一SPで 開発/テスト テスト設計 手法見直し テスト自動化 SP? QAからの 品質フィード バック モブ/ペア テスト 性能テスト CI対応 拠点横断 でのテスト DEVQAOps 海外展開
- 81. グループワーク
- 85. Solution 1 ギルドを結成してAgile Testingを学ぶ ・ PG/QAの有志メンバーでギルドとして活動。 ・｢実践アジャイルテスト｣をActive Book Dialogue 手法で勉強会。 ・参加メンバーを通じてPGメンバーに品質意識が芽生える。 Solution 1
- 86. ABDの様子
- 88. Before PBI
- 89. After PBI
- 91. Solution 1 職能間の障壁を下げる ・チームのクロスファンクショナル化。 ・できる作業は職能に関係なく着手。 ・QAが機能仕様書の作成や、テスト自動化など。 PGメンバーがテストの実施や、テスト仕様書のレビューなど。 ・これにより、作業の手待ちのムダが軽減された。 Solution 4 PG QA PG QA ※重なる領域を増やして職能間の障壁を下げる！
- 92. 課題
- 94. ご清聴ありがとうございました
- 95. Q&A
Editor's Notes
- このセッションはAJとJaSSTのコラボ企画です。和田さん経由でAJにコラボ企画の相談があり、QAとアジャイルという観点でコンテンツを検討しました。その中で私がサイボウズのQAプロセスがスクラム導入とあわせてすごく変わったという話をして、それを事例として提供させていただくことになりました。 登壇者はこちらの5名です。サイボウズの2名にはQAの現場メンバーとしてアジャイルなQAに取り組んだ事例を発表していただきます。私はモデレータとして全体の進行をお手伝いします。AJ実行委員の2名はグループワークなどのお手伝いをさせていただく予定です。
- 全体の進行はこのように進めます。各事例の中で、実際に遭遇した問題や現在直面している問題についてグループワーク形式で議論してみましょう。イメージは「世界ふしぎ発見!」です笑 サイボウズでの事例を通して、アジャイルなQAについてみなさんで議論を深めていければと思います。
- サイボウズ株式会社 グローバル開発本部 東京品質保証部の矢引達教と申します。 2012年に新卒でサイボウズに入社して以来、 主にクラウドサービスのアプリケーションのQAを担当しています。 趣味はヨガと書きましたが、2週間前にヨガ教室に通い始めてまだ3回しか行っていないので、 これから趣味になってほしいなという気持ちを込めてここに記載しています。
- まずは弊社について簡単にご紹介します。 サイボウズ株式会社は、 「チームワークあふれる社会を創る」というミッションのもと、 グループウェアの開発・販売・運用をしています。
- 主な製品は企業向けグループウェアのサイボウズOffice,ガルーン、 業務アプリ構築クラウドのkintone、メール共有システムメールワイズといった製品があります。
- 2011年に提供を開始したクラウドサービスcybozu.comでは、 これらのアプリケーションをクラウドサービスとして提供し、 導入者数2万社以上、契約ユーザーライセンス数80万人以上のお客様にご利用いただいています。
- まずは私達のチームの開発体制についてお話しします。 クラウドサービスcybozu.comの管理機能の開発を行なっています。 こちらは画面の例なのですが、 kintoneやガルーンといったアプリケーションを利用するユーザーやその組織の情報をシステム管理者が管理をするための機能です。 こういった機能を開発しています。 開発は日本で行い、試験は日本と上海の2拠点体制です。 メンバー構成は、プログラマは4〜5名、QAは5名、プロダクトオーナーは1名です。
- ユーザー管理機能とは、こういった、組織やユーザーの情報を管理するためのシステム管理者向けの機能のことです。
- スクラム導入前の開発プロセスについて説明します。
- スクラム導入前は、ウォーターフォール型を採用していました。 テスト設計の一部は開発期間と並行して進めていましたが、 開発期間が終わってからテスト実行を開始していました。 開発期間と試験期間はどちらも1.5ヶ月くらいずつでした。
- スクラム導入前に感じていた問題点は、次のようなものがありました。 実装から試験開始までにラグがあるため、どうしてもバグの検出が遅くなってしまいます。 それによって、原因が似たようなバグが複数箇所に埋め込まれてしまったり、 テスト対象に関する質問をしても、実装担当者が記憶が薄れているため調査に時間がかかることがありました。 また、先ほどウォーターフォール型と言ったのですが、 設計に着手する前に要件のチェックを行うプロセスが明確には存在していなかったので、 要件が曖昧な状態で開発を開始してしまい、 要件の考慮漏れに気づくのが遅くなり手戻りが発生してしまうことが何度かありました。 さらに、試験期間は開発者はもう次のバージョンの開発に着手しているため、 開発チームとして同じものを開発しているという感覚が薄く、チームとしての一体感が薄いという状態でした。 また、共通管理機能という製品の都合上、社内の他のチームが開発する製品との結合試験が度々必要となるのですが、 開発者間では共有されていた情報がQAには伝わっていないことが何度かありました。
- そんな中、去年の1月に部署でスクラムトレーニングを受講する機会があり、 私達のチームメンバーは全員研修を受けました。
- ただ、スクラムトレーニングでは主に考え方を学ぶというところがメインの目的であり、 特に試験をどのように進めるかという具体的な説明はあまりなかったので、 「試験プロセスはほんとうにスクラムに対応できるのかな・・・？」という不安を抱えていました。
- とはいえ、既に社内の他のチームでスクラムを採用しているチームがあり、 その雰囲気が良さそうだったということもあり、 不安はあるけど私達のチームでもまずはスクラムをやってみよう！ということになりました。
- スクラム開始までは少し時間があったので、スクラム開始までにいくつか準備作業を行いました。 やったことを4つ紹介します。 まず1つ目は、開発チームのチームメンバー全員で「カンバン仕事術」の輪講をしました。 この輪講をしたことで、各自の作業を見える化することの大切さや、 WIP制限と呼ばれる同時に進める仕事の数を制限することで、 仕事一つ一つが早く終るという、スクラムにも役立つ知識を付けることができました。 これはとても大事な考え方だと思いますので、 スクラムをやらない会社でもカンバンはおすすめです。
- 実際の私達のチームのカンバンの様子です。 ToDo, Doing, Review, Doneといった列があります。
- 二つ目は、Readyの定義をチームで話し合いました。 Readyの定義とは開発チームが着手できるバックログの基準で、 これを満たさないと開発チームは設計や実装に取り掛かることができないというルールです。 テストに関係するところでは、 「開発チームが納得できるユーザーストーリーがある」 「受け入れ条件が定義されている」 といった内容をReadyの定義とすることにしました。
- 3つ目は、スプリント単位での完了の定義について話し合いました。 完了の定義とは、何を持って「完了」とするかを定義したリストであり、 スプリントでどこまでやるか、の基準です。 カンバン仕事術を読んでいたこともあり、 開発チーム内では、実装だけではなくテストに関する項目を含めることまではみんなが合意していましたが、 どこまで含めるかは議論の余地がありました。 例えば、テスト設計が完了するところまででよしとするのか、 機能試験から性能検証に至るまで全てのテストをスプリト内で完了するところまでを含めるか、ということです。
- ここで大切なのは、 達成できない理想を掲げるのではなく、現在の開発チームの実力に合わせることが大事だと考えています。。 具体的には、私たちの実力に合わせて、次の2つは完了の定義に含めないことにしました。 テスト実行完了については、次のスプリントで完了することをチームの目標にしました。 また、脆弱性検証と性能検証については、社内の脆弱性検証チームと性能検証チームが行うのですが、 1スプリントごとの実施が難しいということだったので2,3スプリントまとめて実施するようにしました。 完了の定義に含めたことは、 「テスト設計を完了させる」ことです。これをチームで合意しました。
- さらに、アジャイルQAをすでに実施されている方の講演を聞きました。 弊社の天野の紹介でアジャイルQAの実践者である日新システムズの永田さんに社内勉強会に来て頂き、 DevQAについての講演をしていただきました。 この講演の中で、QAから開発への素早いフィードバックの重要性を再認識しました。 正直なところ、それまでスクラムに対する不安の方が大きかったのですが、 この講演を聞いて大変そうだけどスクラムやってみようという覚悟ができました。
- それでは、スクラム導入によってどのような変化があったということについて説明します。
- スクラム導入後は、1スプリントを2週間とし、リリース単位は6スプリント+リリーススプリントとしました。 リリース頻度は3ヶ月で、これはスクラム導入前後で変化していません。 先ほど説明しましたが、テスト設計はそのスプリントで完了し、 テスト実行はその次のスプリントで完了できるように進められるようになりました。 最近はすべてのタスクというわけではないですが、 1 Sprintで開発からテスト実行完了までを終えられるようになって来ています。
- スクラム導入によって得たメリットを紹介します。
- スクラムのフレームワークを取り入れたことによって、 主にQAの活動に対して与えた大きな効果は以下の3つだと思っています。 バグの早期検出、要件の明確化、そしてチームの一体感の向上です。
- まず、次のスプリントでテスト実行まで完了するようにしたことで、 実装からテスト実行開始までの期間が短縮されました。 これによって、作り込まれてしまったバグを早く検出できるようになりました。 バグが作り込まれてから検出するまでの期間を調べてみると、 スクラム移行前は平均28日だったのが、約7日に短縮しました。 また、類似バグが量産されてしまうことを防ぐことができたり、 開発者の記憶が新しいので、調査を依頼してもすぐに返答が返ってくるようになりました。
- 二つ目のメリットは、。 Readyの定義として「開発チームが納得できるユーザーストーリーがある」を含めたため、 要件が曖昧なまま実装に入ることを避けることができ、 認識の齟齬による手戻りが減少しました。 また、サイボウズでは社内に脆弱性検証を行うチームがいるのですが、 最近では、要件検討のミーティングにその担当者も同席してもらえるようになり、 要件定義の段階でセキュリティの観点を含めることができるようになりました。
- 3つ目のメリットは、開発チームとしての一体感が高まったことです。 デイリーミーティングやカンバンによって開発チーム内のコミュニケーションがより深まったことで、 QAは開発者のリクエストをより柔軟に聞くことができるようになりました。 例えば、「この機能の実装が終わったので、ちょっと早めに動作確認してほしい」といった要望があれば、本格的な試験の前にさっとQAが動作確認したりすることができるようになりました。 逆に、開発者もQAのことをより気にかけてくれるようになりました。 「次のスプリントで試験が終わる」ことをチームが目指していて、かつカンバンで進捗が逐一わかる状態担っているので、 開発者も自然と試験の進捗が気になるようになります。 そうなると、例えば、試験容易性を高める機能を追加する提案をしてくれたり、 「この部分は確認しづらいので次のスプリントで実装する機能と一緒に試験した方が確認しやすいかもしれない」 といった提案をしてくれるようになりました。
- ここまでスクラムのメリットを紹介してきましたが、 それではスクラムを採用すれば必ず 生産性が向上し、メンバーが成長し、プロダクトが改善するようになるのでしょうか？ 自分もスクラムを取り入れる前はそのような理解をしていた面があったのですが、
- 実際にスクラムをやって見ると、スクラムは問題を発見しやすいフレームワークであると実感するようになりました。 どういうことかというと、 どこがうまくいっていないかを特定しやすく、 それを解消する機会が与えられている、ということです。 発見した問題を解決することで、結果的に生産性の向上につながる場合があるということです。
- そこで、ここからは、私のチームがスクラム移行時に直面した問題と、それをどう解消したかを紹介します。
- これから紹介する問題をこの後のグループワークの題材とします。 もしかするとみなさんのチームとは状況が異なるかもしれませんが、 「自分だったらどう対応するか？」を考えてみてください。
- 遭遇した問題は、「試験設計のレビューが間に合わない！？」という問題です。
- 背景を説明します。 スクラム導入以前は、テスト設計レビューを2段階で実施していました。 テスト設計は上海のQAが担当し、レビューの1回目はクロスチェックという形で上海のQAメンバー内で行なっていました。 その後、2回目のレビューを東京QAが担当し、それを通過すればテスト実行の工程に進むというプロセスでした。 スクラム導入以前から、このレビュー2にタスクが溜まりがちになるという状況は発生していましたが、 スクラム以前は試験期間が1.5ヶ月あり、その長い期間内でなんとか都合をつけて行っていました。 ただ、スクラムを導入したことより2週間以内にテスト設計を完了する必要が出てきたため、 このボトルネックが深刻化しました。
- 東京QAは1名のみで、直近での増員は難しいという状況でした。 レビュー２でのレビュー観点は主に以下の２つです。 一つ目はテスト観点に不足はないかという「漏れがないか」の確認で、 レビュー観点は東京QAに属人化していました。 二つ目は、省略できるテストケースの組み合わせが無いかという「無駄がないか」の確認で、 テストケースの組み合わせが爆発する場合、東京QAが開発担当者に相談しつつ、 開発の視点で省略できるテストケースがあれば省略するといったレビューを行っていました。 ということで、グループワークの題材は、 「スクラム導入により深刻化した試験設計プロセスのボトルネックをどう解消するか？」です。
- グループワークでの議論ありがとうございました。 唯一の解決策は無く、皆さんが挙げていただいたいろんな方法で解決できると思いますが、 ここでは私たちのチームが実際にどうやって解決したかを紹介します。
- まず、レビュー２でチェックしているレビュー観点のうち、「漏れが無いか」については観点をチェックリスト化し、 試験設計とレビュー１でチェックしてもらうようにしました。 次に、無駄のチェックについては、 開発者にも試験設計レビューに参加してもらい、直接チェックしてもらうようにしました。 このような対策を行うことにより、試験設計レビュー２のレビュー観点を他のフェーズに移管することができました。 これによって、スクラムのタイムスケジュールに合わせて試験設計を行うことが可能になりました。
- ここで、なぜ解決できたかを振り返ってみると、 試験設計という問題をQAのみで解決しようとせずに、 チームの問題としてチーム全体で取り組めたことが解決につながったと思っています。 ではチーム全体で解決に取り組むために何をしたか？を考えてみると 次の3つが大きかったと考えています。 1つ目はカンバンによって試験の進捗についても見える化したことで、 どこにどれだけのボトルネックが発生しているかが分かりやすくなり、 チーム内で問題に対する共通認識を持つことができたことです。 2つめは、完了の定義にテストに関する事項を含めてチームで合意したことで、 チームで共通の理想を持てたことです。 そして3つめは、なるべく職能間のスキルの障壁を無くすことです。 それまでは試験仕様書の形式をExcelにしていましたが、 試験仕様書を初めて見る開発者にとってはテストケースの意図を汲み取るのは難しいものがありました。 そこで形式をマインドマップに変えて、開発者がレビューしやすいようにしました。 テストに関する問題はどうしてもQA内で解決しようとしてしまいがちなのですが、 チームの問題としてチーム全体で取り組むことが重要で、 スクラムはそれをやりやすくしてくれるツールであると考えています。
- 今日は私のチームのスクラム移行の話をしましたが、まだまだ課題が残っています。 リリースサイクルはスクラム移行前後で変わっておらず、今でも6スプリント＝3ヶ月単位となっているので これを1ヶ月単位にしたいです。 また、1スプリント内でテスト実行まで完了するようにしたいです。 そのためにはスプリント開始前のテスト工数の見積もりをどうするかといった問題も解決する必要があります。 また、それとも関連するのですが、開発チーム外が行っている、性能検証や脆弱性検証も高速に実施できるように 関係部署と調整を進めていく必要があります。 また、拠点間でコミュニケーション不足が発生してしまいがちなのでそれも改善したいです。 テスト自動化は現在開発者が行っていますが、今後はQAがテストコードを書けるようにしたいです。
- ここまでの発表をまとめます。 私たちのチームがウォーターフォールからスクラム移行した際に 行った準備作業を紹介し、 スクラム移行によって得たメリットを紹介しました。 また、スクラムは問題発見のフレームワークであり、 チームに問題はチームで解決することが大事であるということを紹介しました。 ご静聴ありがとうございました。
- ・チーム名は実際に使われているチーム名です 星座や惑星をモチーフにしたチーム名になっています
- 現在の複数拠点大規模スクラムへどのように移行していったかを紹介しようと思います
- 去年、スクラムトレーニングをキッカケにスクラム導入を決めたのですが・・・
- ただでさえ分からないことだらけの状態で複数拠点同時導入はハイリスク！失敗が目に見えています。 ・導入時の鉄則、スモールスタート ・失敗したときのリスクを小さく ・プロセス改善の意思決定/反映を素早く
- はじめのほうでもお伝えしたように日本のQAはマネジメント中心だったため、もともとQAの人数が少ない状態でした
- ・日本ですぐにQAリソースを増やすのは困難。 ・このときはまだ職能に対する壁があり、チームでバックログをdoneにするという意識が低かった・・・
- ・紫ラインが実績、緑ラインが理想線 ・バーンダウンなのに途中で上がってるのは、バックログを追加したため
- 一方でこんな声も・・・ ・コミュニケーション増えた！（PG/QA/PO） ・カンバン好評。（見える化） ・問題点を共有しやすい。（デイリースクラム） ・気持ちを切り替えやすい。（スプリントによるタイムボックス） ・ワイワイやるのが楽しい！
- これにより日本チームも含めて各チームにQAが配置されて自分のチームで完結できる体制になった
- ・日本ですぐにQAリソースを増やすのは困難。 ・このときはまだ職能に対する壁があり、チームでバックログをdoneにするという意識が低かった・・・
- ・現地企業によるスクラム研修
- ・約3週間ほど現地に出張してOJTを実施 ・出張者のうち2名は開発チームの一員として活動 ・帰国後も同スクラムチームに所属して日本/越南混合チームを形成
- ・テスト設計、テスト実施のやり方、タイミングなど
- 一度に変更するのではなく徐々に適用させていった
- 前のスライドでもあったように今まではテストは開発した次のスプリントで実施していました。 それは、このような問題・課題があったためです。
- ・ギルド：興味のあるコミュニティの集まり ・ABD：1冊の本を裁断し、担当パートごとに読み、要約文を作ってリレープレゼンを行う その後感想や疑問について話し合う