Scrum,Test,Metrics #sgt2016

Scrum,Test,Metrics #sgt2016

1. 1. Scrum, Test, Metrics @kyon_mm Scrum Gathering Tokyo 2016 2016.01.18
2. 2. Self Introduction • kyon_mm • 株式会社オンザロード テストアーキテクト • F#, Groovy, C# • Software Engineering, Testing, Science, Economics, Psychology
3. 3. Agenda • Background, Team, Project • Case(Scrum, Test, Metrics) • Now Challenge • QA
4. 4. Caution ! • 私はスクラムガイドとソフトウェア開発の原則に忠実に従うことを重要視 しました。 • ですが、トレードオフとしてどうしても諦めざるを得ない部分も存在しま した。 • ゆえに、みなさんが思い描くスクラム、テスト、受託開発とは異なるかも しれません。 • また、私はこのプロジェクトで初めてスクラムを真面目に主導し続ける立 場になりました。 • スクラムマスター1年生が本気で悩んで取り組んだ結果に過ぎません。
5. 5. Background, Team, Project
6. 6. Background, Team, Project • 保守4年目の受託開発。2015.02 以降を紹介。 • このチームを「基盤チーム」と呼びます。フレー ムワーク、ライブラリを開発しています。 • @kyon_mm(PO兼SM), @bleis, @otf, @zakky_dev • 2012-2014はうまくはやってこれなかった • @zakky_dev は2015からこのチームに参加
7. 7. Background, Team, Project • 基本的にはうまくいっていませんでした。 • 残業多い、再計画が不正確すぎる
8. 8. Background, Team, Project • 1スプリント1週間 • スクラムイベントは出来る限り定刻に行う • 多能工に挑戦 • PBIは出来るだけユーザーストーリー • 全ての活動はスプリントバックログにのせる
9. 9. Case(Scrum, Test, Metrics)
10. 10. Case(Scrum, Test, Metrics) • Case Overview • Test • Metrics • Conclusion
11. 11. Case Overview
12. 12. Background, Team, Project • 私は最高のチームの一員であるだろうか？ • 最高のスクラムをできているのか？ • 最高の開発をできているのか？ • つまり、最高のスクラム、最高の開発とは何で あるのか？を常に問い続けるチームになる必要 がある。
13. 13. Case Overview • 全ての自分たちの活動を疑う。 • スクラムイベントも例外ではない。
14. 14. スプリントレビュー自体の 質を計測していますか？
15. 15. あなたが最高のSMやPOであ るかどうかはどうやって 計測されていますか？
16. 16. Case Overview • Test • テストケースを考えてから実行するまで2日以上かかるテストは800 件あったものを0件にした。それが起因でバグになったものはない。 • スプリントレビューではその場でコードレビューも探索的テストも 行うようにした。素早くバグ発見や知識共有をできるようになった。 • Metrics • 見積もりと実績の工数はメンバーが自主的に15分単位で行い、自分 たちでムダを見つけるようになった。 • レビュー自体の品質を定量化しており、時間の使い方や指摘内容か らレビューの質が向上した。
17. 17. Test
18. 18. Test ? • みなさんはどのようにテストをしていますか？ • テストケースを考えたり、テストを実施すると いう「PBI」もしくは「スプリント」として存 在する？ • テストだけをする別のチームが存在する？ • 他？
19. 19. 最初にやったこと • アジャイルにテストをやるのだから、テストが 別チームでとか、スプリントバックログに「結 合テスト」みたいなものはあがるはずがない。 ストーリー内で完結するはずである。 • でも、1スプリント1週間でやっているとき に、テスト設計に時間をかけようとするとそも そも全てのストーリーをうまくテストできない。
20. 20. わかったこと • 1スプリント1週間が最も良い開発ができるという チームにおいて、例えばテスト設計に2日費やしてい ると、スプリントレビュー前に全てのテストは終わら ない。システムテストのようなものも終わらない。 • スクラムチームはSpecification By Example、探索的 テスト、レビューのような高効率なテストを実践する 必要がある。
21. 21. Sprint期間中のテスト • 徹底してユーザーストーリーでPBIを書き連ねる。 • リスクの高いストーリーはプロトタイプとSbEなテ ストをつくって、POがレビューして、ストーリーを すすめる。 • 誰の要求を表現したチェックであるかを徹底し、な んとなく必要だと思うチェックというのは撤廃する。
22. 22. Sprint Review • スプリントレビューはレビュイーを1人で交代制で行 い、他のメンバーは全員顧客としてレビュアーにな る。 • 自分が関わっていない、苦手なPBIがあっても全て 説明できる必要がある。 • 説明できないものが存在するとか、スクラムチー ムとはいえないですよね。
23. 23. Skill Level • 対象に対するスキルをどうやって高めるかがチームが多能工に挑戦 するという意味になる。 • 多くの人は下のように捉えていて、Level 0 の人をどうやってLevel 1 にもっていくか、チームとして意味のあるコミットをするかが重要 • Level 0 まるでできない • Level 1 サポートがあればできる • Level 2 自信をもってできる
24. 24. Skill Level • そもそもLevel 0の人がいるときに、スプリン ト計画の見積もりは意味をなしているのか？ どうやったらその人はLevel 1になるのか？ • Level 0のPBIは自分に関係ないと思っていない か？それはスクラムではない！
25. 25. Skill Level • 対象が何かを知らないと興味を持つのは難しい感覚がある。 • 多能工になることでチームでバックログを共有する価値が 高まる。 • いきなりLevel 1になるのは難しいけど、まずは知っている という状態があるはずだ。（作れないけど、どんな状態に あるのか、何を作りたいのかをPMが説明できるのと似て いる状態にするのがまず重要だと考えた）
26. 26. Skill Level • Level 0 まるでできない • Level 1 対象について説明できる • Level 2 サポートがあればできる • Level 3 自信をもってできる
27. 27. Sprint Review • スプリントレビューはレビュイーを1人で交代制で行 い、他のメンバーは全員顧客としてレビュアーにな る。 • 自分が関わっていない、苦手なPBIがあっても全て 説明できる必要がある。 • 説明できないものが存在するとか、スクラムチー ムとはいえないですよね。
28. 28. Sprint Review • タイムボックスの中で最も効果的にレビューでき るように、レビュイーが工夫をするようにしむけ る。 • レビュイーが準備不足だとしても、原則として タイムボックスは守る。（レビューできないリ スクとトレードオフできる範囲で） • 次回からよいレビューにしようと何か挑戦する
29. 29. Metrics
30. 30. Metrics ? • みなさんはどのようなメトリクスをとっていま すか？ • バグ数、チケットのステータスや期間、コード カバレッジ？ • スプリントバックログのdone率？ • 他？
31. 31. 最初のキッカケは みんなの不満からだった
32. 32. 基盤チーム 
 = 社内の最強メンバー
33. 33. 基盤チーム 
 = 社内の最強メンバー = 社内で最もお願いされる
34. 34. 基盤チーム 
 = 社内の最強メンバー = 社内で最もお願いされる = 仕事が回らねぇ！！！！
35. 35. ダメだ。 基盤をリリースできない。
36. 36. 「周りにグゥの音も出ない形 で説得させてみせる」 by kyon_mmの心の声
37. 37. 割込作業を分単位で記録 1週間試してみた 週の40%が別PJの割込作業
38. 38. 作業依頼用プロトコルを作成 社内で統一 割込作業が10%以下に低減！
39. 39. お仕事依頼プロトコル • 依頼者は タスクお願いテンプレート を埋められるようにしておく。 • 依頼者は請負者に タスクの内容を説明する • 請負者はタスクの内容を整理、見積もりする • 1時間以内で終わるものであれば、請負者と依頼者でタスクの各項目につい て合意する • 請負者はチームにタスク依頼の旨を共有し、タスクを開始する • 1時間以内で終わらないものであれば、依頼者を含めてチームで議論をして、 タスクの受け取り可否を決定する
40. 40. お仕事依頼プロトコル • 依頼者 : • 請負者 : • 要求元 : • 期限 : • 規模(時間) : • 要求(スコープ) :
41. 41. メトリクス重要だと全員が 合意できるようになる
42. 42. 最初にやったこと • デイリースクラムやスプリントプランニングをしている と、言葉につまったり、見積もりとずれても影響をうま く表現しないまま仕事をして、うまくdoneできないとき がある • 計画の精度をあげても、実績をトレースできていないと 意味が無い。 • デイリースクラムでの「やったこと」報告は工数入力結 果画面で報告する。
43. 43. わかったこと • 時間をつけたほうがいいとは思うけど、つけ るのが面倒なのはフィードバックが遅いから で、次の日に簡単に報告できるようになるな らやりやすくなる。 • 実績と比較できるようになると、考えるキッ カケが増える。
44. 44. Kanban(Redmine Backlogs) • ストーリーに紐づくタスクは原則2時間以内にし、チー ム全員がその時間でできると合意できるようにする。 • 実績は「スプリント計画内」か「スプリント計画外」 かをわけて日々記録する。 • 「スプリント計画外」の実績が大きい時には、メン バーがきっと困っているもしくは何か情報共有が必 要なタイミングのはずだと気づける。
45. 45. Kanban(Redmine Backlogs) • 1つのストーリーにタスクが13個以上になっ たら赤くなる。 • スプリント計画時の大まかな見積もり時間か ら、スプリント期間中に見積もり時間が大き く増えたら赤くなる。
46. 46. Sprint Review • レビュー中の時間は全て次の5つに分類して計測する。 • デモや説明、指摘、指摘明文化、情報共有、デモや説明自体に対 する指摘 • レビュイーとレビュアーがどのように時間を使うのがいいかわか りやすくなる。 • 指摘が狩野モデルのどの品質で、どれくらいの修正規模なのかをあ てはめる。 • チームへの要求（品質）に即している指摘をしているかがわかる。
47. 47. Metrics Example Sprint Planning • スプリント期間中の時間の使い方の計画 • スクラムイベント 20% • スプリント計画の見積もり 60% • スプリント計画後に発生する作業 20%
48. 48. Metrics Example Sprint Review • レビューは次の時間で行うのが良い • デモ : 70% • 指摘 : 10% • 指摘明文化 : 5% • 情報共有 15% • デモ自体に対する指摘 : 0%
49. 49. Metrics Example Sprint Review • 無関心品質が0であること、チームで意見がま とまることが重要。 • 合意するために必要な時間を計測する。 • 指摘の明文化が済んだあとに、品質を合意す るのは1分から2分で終わらせる。
50. 50. Excelで分類例
51. 51. 狩野モデルを簡単に可視化する Excel • Kano Analysis SpreadSheet - Agile Logic
52. 52. Metrics Example Sprint Review • ストーリーのDone率 : 80%以上 • スプリントゴールの達成 : 達成する
53. 53. Metrics Example New Try • 特に「新しいTryをしたときに注意力がどのよ うに変化するか」を計測する。 • 目的の確認漏れで失敗してしまう率 • 視野が狭くなって失敗してしまう率 • レビュー指摘件数
54. 54. Conclusion
55. 55. わかったこと • チームで変化させてきたものは、納得しなが ら（目的や影響を理解しながら）取り入れて きました。 • 活動に対して出来るだけ早いタイミングでそ の活動を評価すると、どんどんよくなりたい とみんなが思える。
56. 56. わかったこと • フィードバックループを良くすることが重要 • 方向 • 頻度 • 量 • 質
57. 57. わかったこと • 感覚という曖昧なものだけで、チームを導け るほど私は優秀ではない。 • 数字と金がわかりやすい。 • 数字にして考察すると「自分たちがどのよう にものごとを捉えているか」がわかりやすく なるし、新しいゴールを考えやすくなる。
58. 58. 大切だと思うこと • これらを根気よく真 に行い続けることが最 も重要。 • 最初だけやる、聞いたことはあるからこれだ けやってみるとかはだいたい効果がでない。 • チームとプロダクトとお客さんをどうしたい のか考えながら、必要なメトリクスを考える。
59. 59. 大切だと思うこと • これらを根気よく真 に行い続けることが最 も重要。 • 最初だけやる、聞いたことはあるからこれだ けやってみるとかはだいたい効果がでない。 • チームとプロダクトとお客さんをどうしたい のか考えながら、必要なメトリクスを考える。
60. 60. インプット、アウトプット • スクラムイベント以外はユーザーストーリーで 記述する • 毎週ユビキタス言語を書く • ユーザーガイドを積極的につくる • 完成の定義は探索的テスト済み
61. 61. インプット、アウトプット • スクラムイベント以外はユーザーストーリーで 記述する • 毎週ユビキタス言語を書く • ユーザーガイドを積極的につくる • 完成の定義は探索的テスト済み
62. 62. インプット、アウトプット • ストーリーは次のようにカテゴライズ • フィーチャ • ドキュメント • 調査 • イベント • 環境構築 • レビュー
63. 63. スクラムイベント • スクラムイベントのファシリテーターは交代 制 • スプリントレビューの品質を定量化 • 工数は分単位で日次で定量化
64. 64. 活動 • 1週間のうち2日以上かかるものを大量にもつ ようなプロセスはやめる
65. 65. Now Challenge
66. 66. New Challenge • スプリントレトロスペクティブ自体の振り返りと して、数週間解決しようとして解決できていない 問題を対象にする。 • 問題を、原因、増幅原因、制約に分解してグラフ 化する。 • グラフがどれくらい変化しているかで振り返りが うまくいっているかわかる。
67. 67. QA