Scrum, Test, Metrics@kyon_mm Scrum Gathering Tokyo 2016 2016.01.18

Self Introduction

• kyon_mm

• 株式会社オンザロード テストアーキテクト

• F#, Groovy, C#

• Software Engineering, Testing, Science, Economics, Psychology

Agenda

• Background, Team, Project

• Case(Scrum, Test, Metrics)

• Now Challenge

• QA

Caution !

• 私はスクラムガイドとソフトウェア開発の原則に忠実に従うことを重要視しました。

• ですが、トレードオフとしてどうしても諦めざるを得ない部分も存在しました。

• ゆえに、みなさんが思い描くスクラム、テスト、受託開発とは異なるかもしれません。

• また、私はこのプロジェクトで初めてスクラムを真面目に主導し続ける立場になりました。

• スクラムマスター1年生が本気で悩んで取り組んだ結果に過ぎません。

Background, Team, Project

Background, Team, Project• 保守4年目の受託開発。2015.02 以降を紹介。

• このチームを「基盤チーム」と呼びます。フレームワーク、ライブラリを開発しています。

• @kyon_mm(PO兼SM), @bleis, @otf,

@zakky_dev

• 2012-2014はうまくはやってこれなかった

• @zakky_dev は2015からこのチームに参加

Background, Team, Project• 基本的にはうまくいっていませんでした。

• 残業多い、再計画が不正確すぎる

Background, Team, Project

• 1スプリント1週間

• スクラムイベントは出来る限り定刻に行う

• 多能工に挑戦

• PBIは出来るだけユーザーストーリー

• 全ての活動はスプリントバックログにのせる

Case(Scrum, Test, Metrics)

Case(Scrum, Test, Metrics)

• Case Overview

• Test

• Metrics

• Conclusion

Case Overview

Background, Team, Project

• 私は最高のチームの一員であるだろうか？

• 最高のスクラムをできているのか？

• 最高の開発をできているのか？

• つまり、最高のスクラム、最高の開発とは何であるのか？を常に問い続けるチームになる必要がある。

Case Overview

• 全ての自分たちの活動を疑う。

• スクラムイベントも例外ではない。

スプリントレビュー自体の 質を計測していますか？

あなたが最高のSMやPOであるかどうかはどうやって 計測されていますか？

Case Overview• Test

• テストケースを考えてから実行するまで2日以上かかるテストは800

件あったものを0件にした。それが起因でバグになったものはない。

• スプリントレビューではその場でコードレビューも探索的テストも行うようにした。素早くバグ発見や知識共有をできるようになった。

• Metrics

• 見積もりと実績の工数はメンバーが自主的に15分単位で行い、自分たちでムダを見つけるようになった。

• レビュー自体の品質を定量化しており、時間の使い方や指摘内容からレビューの質が向上した。

Test

Test ?

• みなさんはどのようにテストをしていますか？

• テストケースを考えたり、テストを実施するという「PBI」もしくは「スプリント」として存在する？

• テストだけをする別のチームが存在する？

• 他？

最初にやったこと

• アジャイルにテストをやるのだから、テストが別チームでとか、スプリントバックログに「結合テスト」みたいなものはあがるはずがない。ストーリー内で完結するはずである。

• でも、1スプリント1週間でやっているときに、テスト設計に時間をかけようとするとそもそも全てのストーリーをうまくテストできない。

わかったこと

• 1スプリント1週間が最も良い開発ができるというチームにおいて、例えばテスト設計に2日費やしていると、スプリントレビュー前に全てのテストは終わらない。システムテストのようなものも終わらない。

• スクラムチームはSpecification By Example、探索的テスト、レビューのような高効率なテストを実践する必要がある。

Sprint期間中のテスト

• 徹底してユーザーストーリーでPBIを書き連ねる。

• リスクの高いストーリーはプロトタイプとSbEなテストをつくって、POがレビューして、ストーリーをすすめる。

• 誰の要求を表現したチェックであるかを徹底し、なんとなく必要だと思うチェックというのは撤廃する。

Sprint Review

• スプリントレビューはレビュイーを1人で交代制で行い、他のメンバーは全員顧客としてレビュアーになる。

• 自分が関わっていない、苦手なPBIがあっても全て説明できる必要がある。

• 説明できないものが存在するとか、スクラムチームとはいえないですよね。

Skill Level

• 対象に対するスキルをどうやって高めるかがチームが多能工に挑戦するという意味になる。

• 多くの人は下のように捉えていて、Level 0 の人をどうやってLevel 1にもっていくか、チームとして意味のあるコミットをするかが重要

• Level 0 まるでできない

• Level 1 サポートがあればできる

• Level 2 自信をもってできる

Skill Level

• そもそもLevel 0の人がいるときに、スプリント計画の見積もりは意味をなしているのか？どうやったらその人はLevel 1になるのか？

• Level 0のPBIは自分に関係ないと思っていないか？それはスクラムではない！

Skill Level

• 対象が何かを知らないと興味を持つのは難しい感覚がある。

• 多能工になることでチームでバックログを共有する価値が高まる。

• いきなりLevel 1になるのは難しいけど、まずは知っているという状態があるはずだ。（作れないけど、どんな状態にあるのか、何を作りたいのかをPMが説明できるのと似ている状態にするのがまず重要だと考えた）

Skill Level

• Level 0 まるでできない

• Level 1 対象について説明できる

• Level 2 サポートがあればできる

• Level 3 自信をもってできる

Sprint Review

• スプリントレビューはレビュイーを1人で交代制で行い、他のメンバーは全員顧客としてレビュアーになる。

• 自分が関わっていない、苦手なPBIがあっても全て説明できる必要がある。

• 説明できないものが存在するとか、スクラムチームとはいえないですよね。

Sprint Review

• タイムボックスの中で最も効果的にレビューできるように、レビュイーが工夫をするようにしむける。

• レビュイーが準備不足だとしても、原則としてタイムボックスは守る。（レビューできないリスクとトレードオフできる範囲で）

• 次回からよいレビューにしようと何か挑戦する

Metrics

Metrics ?

• みなさんはどのようなメトリクスをとっていますか？

• バグ数、チケットのステータスや期間、コードカバレッジ？

• スプリントバックログのdone率？

• 他？

最初のキッカケは みんなの不満からだった

基盤チーム = 社内の最強メンバー

基盤チーム = 社内の最強メンバー

= 社内で最もお願いされる

基盤チーム = 社内の最強メンバー

= 社内で最もお願いされる = 仕事が回らねぇ！！！！

ダメだ。 基盤をリリースできない。

「周りにグゥの音も出ない形で説得させてみせる」 by kyon_mmの心の声

割込作業を分単位で記録 1週間試してみた

週の40%が別PJの割込作業

作業依頼用プロトコルを作成 社内で統一

割込作業が10%以下に低減！

お仕事依頼プロトコル

• 依頼者は タスクお願いテンプレート を埋められるようにしておく。

• 依頼者は請負者に タスクの内容を説明する

• 請負者はタスクの内容を整理、見積もりする

• 1時間以内で終わるものであれば、請負者と依頼者でタスクの各項目について合意する

• 請負者はチームにタスク依頼の旨を共有し、タスクを開始する

• 1時間以内で終わらないものであれば、依頼者を含めてチームで議論をして、タスクの受け取り可否を決定する

お仕事依頼プロトコル

• 依頼者 :

• 請負者 :

• 要求元 :

• 期限 :

• 規模(時間) :

• 要求(スコープ) :

メトリクス重要だと全員が 合意できるようになる

最初にやったこと

• デイリースクラムやスプリントプランニングをしていると、言葉につまったり、見積もりとずれても影響をうまく表現しないまま仕事をして、うまくdoneできないときがある

• 計画の精度をあげても、実績をトレースできていないと意味が無い。

• デイリースクラムでの「やったこと」報告は工数入力結果画面で報告する。

わかったこと

• 時間をつけたほうがいいとは思うけど、つけるのが面倒なのはフィードバックが遅いからで、次の日に簡単に報告できるようになるならやりやすくなる。

• 実績と比較できるようになると、考えるキッカケが増える。

Kanban(Redmine Backlogs)

• ストーリーに紐づくタスクは原則2時間以内にし、チーム全員がその時間でできると合意できるようにする。

• 実績は「スプリント計画内」か「スプリント計画外」かをわけて日々記録する。

• 「スプリント計画外」の実績が大きい時には、メンバーがきっと困っているもしくは何か情報共有が必要なタイミングのはずだと気づける。

Kanban(Redmine Backlogs)

• 1つのストーリーにタスクが13個以上になったら赤くなる。

• スプリント計画時の大まかな見積もり時間から、スプリント期間中に見積もり時間が大きく増えたら赤くなる。

Sprint Review

• レビュー中の時間は全て次の5つに分類して計測する。

• デモや説明、指摘、指摘明文化、情報共有、デモや説明自体に対する指摘

• レビュイーとレビュアーがどのように時間を使うのがいいかわかりやすくなる。

• 指摘が狩野モデルのどの品質で、どれくらいの修正規模なのかをあてはめる。

• チームへの要求（品質）に即している指摘をしているかがわかる。

Metrics Example Sprint Planning• スプリント期間中の時間の使い方の計画

• スクラムイベント 20%

• スプリント計画の見積もり 60%

• スプリント計画後に発生する作業 20%

Metrics Example Sprint Review• レビューは次の時間で行うのが良い

• デモ : 70%

• 指摘 : 10%

• 指摘明文化 : 5%

• 情報共有 15%

• デモ自体に対する指摘 : 0%

Metrics Example Sprint Review• 無関心品質が0であること、チームで意見がまとまることが重要。

• 合意するために必要な時間を計測する。

• 指摘の明文化が済んだあとに、品質を合意するのは1分から2分で終わらせる。

Excelで分類例

狩野モデルを簡単に可視化するExcel• Kano Analysis SpreadSheet - Agile Logic

Metrics Example Sprint Review• ストーリーのDone率 : 80%以上

• スプリントゴールの達成 : 達成する

Metrics Example New Try• 特に「新しいTryをしたときに注意力がどのように変化するか」を計測する。

• 目的の確認漏れで失敗してしまう率

• 視野が狭くなって失敗してしまう率

• レビュー指摘件数

Conclusion

わかったこと

• チームで変化させてきたものは、納得しながら（目的や影響を理解しながら）取り入れてきました。

• 活動に対して出来るだけ早いタイミングでその活動を評価すると、どんどんよくなりたいとみんなが思える。

わかったこと

• フィードバックループを良くすることが重要

• 方向

• 頻度

• 量

• 質

わかったこと

• 感覚という曖昧なものだけで、チームを導けるほど私は優秀ではない。

• 数字と金がわかりやすい。

• 数字にして考察すると「自分たちがどのようにものごとを捉えているか」がわかりやすくなるし、新しいゴールを考えやすくなる。

大切だと思うこと

• これらを根気よく真摯に行い続けることが最も重要。

• 最初だけやる、聞いたことはあるからこれだけやってみるとかはだいたい効果がでない。

• チームとプロダクトとお客さんをどうしたいのか考えながら、必要なメトリクスを考える。

大切だと思うこと

• これらを根気よく真摯に行い続けることが最も重要。

• 最初だけやる、聞いたことはあるからこれだけやってみるとかはだいたい効果がでない。

• チームとプロダクトとお客さんをどうしたいのか考えながら、必要なメトリクスを考える。

インプット、アウトプット

• スクラムイベント以外はユーザーストーリーで記述する

• 毎週ユビキタス言語を書く

• ユーザーガイドを積極的につくる

• 完成の定義は探索的テスト済み

インプット、アウトプット

• スクラムイベント以外はユーザーストーリーで記述する

• 毎週ユビキタス言語を書く

• ユーザーガイドを積極的につくる

• 完成の定義は探索的テスト済み

インプット、アウトプット• ストーリーは次のようにカテゴライズ

• フィーチャ

• ドキュメント

• 調査

• イベント

• 環境構築

• レビュー

スクラムイベント

• スクラムイベントのファシリテーターは交代制

• スプリントレビューの品質を定量化

• 工数は分単位で日次で定量化

活動

• 1週間のうち2日以上かかるものを大量にもつようなプロセスはやめる

Now Challenge

New Challenge

• スプリントレトロスペクティブ自体の振り返りとして、数週間解決しようとして解決できていない問題を対象にする。

• 問題を、原因、増幅原因、制約に分解してグラフ化する。

• グラフがどれくらい変化しているかで振り返りがうまくいっているかわかる。

QA