devlove-kansai-sre-scrum

Transcript

1. DevLove関西 FearlessChange実践編 SREチームにおけるスクラムの実践 株式会社はてな SRE id:hokkai7go
3. はてなSREチームか ら来ました
4. 突撃！隣のDevOps で紹介されました https://dev.classmethod.jp/devops/dev-ops-hatena/
6. 今日話すことは既にブ ログ記事化済み SREチームにおけるスクラムの実践 https://blog.hokkai7go.jp/entry/devlove-kansai-sre-scrum
7. 概要 我々SREは日々割り込みを処理しつつ、技術的負債の返済や新し い仕組みの導入といった予定されたエンジニアリングタスクにも取 り組んでいます。プロダクトオーナー兼スクラムマスターの上長か らスクラムマスターを引き継いだときから現在に至るまでに取り組 んだこととチームの変化についてお話します。
8. チーム • 人数数えるのに片手以上必要な大きなチーム • インフラ構築から、SREのいないチームの運用までを担 当し、SREのいないチームでこぼれたものを拾う役割も ある。基盤となるソフトウェアやミドルウェアの面倒を見 ているチーム
9. チーム • 機能横断的かと言われると、SREに寄りすぎている組織 ではある
10. チームでのスクラム • スプリントは2週間、スプリントレビューはできていない • チームが見ているスプリントバックログと、POとチーム で見ているプロダクトバックログがある。
11. チームでのスクラム • 昼にデイリースクラムをやっている • 東京と京都両方にメンバーがいるので、コミュニケー ションは基本的にオンライン（Slack, GitHub projects, Hangout meet) • 振り返りもオンラインでKPT→YWT→KPTと変化
12. チームでのスクラム • プロダクトを持っているチームと違って、横断的に全 チームが使うソフトウェア/インフラを提供するためのリ ポジトリがたくさんある状態
13. チームでのスクラム • インクリメンタルな仕事以外、つまり割り込みについては見積もりを付けず に管理している。計画可能なインクリメンタルな仕事についてはプロダクト オーナーがプロダクトバックログに登録し、チームがタスクの分解、見積も り、といったプロセスを関係者で経てからタスク着手としている。 • ストーリーポイントにはフィボナッチ数を使っている
14. スクラムマスターを引 き継ぐ
15. スクラムマスターを引き継ぐ • プロダクトオーナー兼スクラムマスターの上長からスク ラムマスターを引き継ぐ • 前職で開発チームの一員(インフラ担当)として働いてい たときにスクラムを初めて体験した • スクラムマスターについてはPOとの対話という点にお いて大変そうだなとしか思っていなかった
16. スクラムマスターを引き継ぐ • エンジニアリングに集中するものの、マネジメントにも興 味があるということで入社した。スクラムマスターやりま せんかという打診を上長からされて、2019/2にスクラム マスターになった • 正式な推進担当者(29)
17. (昔話)スクラム導入時の話 • id:hokkai7go入社前(入社後にはすでにスクラム始まってた • プロダクトオーナー曰く、スクラム始める前には、割り込みが多すぎてまじ で何もできんって状況だった • 少しでも前進したということを確認しようという意味でスクラムを導入した
18. ここからはスクラムマ スターになってから取 り組んだこと
19. チームのスクラムの知識ベースを揃えた • メンバーによってスクラムについての知識、経験がバラバラだったので、ス クラムブートキャンプ本を読んでもらい全員が読み終わるのを見届けた • 外部のお墨付き(12)
20. スクラムマスターになってすぐ直面した問題1 • チームがまだスクラムに慣れてない頃、スプリントバックログアイテム着手 時の違和感をプロダクトオーナーではなくスクラムマスターに伝えられた り、プロダクトオーナーとの対立の原因となりうる捉え方をされてしまった
21. スクラムマスターになってすぐ直面した問題1 • スクラムマスターとしてはサポートするが、プロダクトオーナーとの直接の 会話でのみ解決されることを伝えた。また対立するのではなく協調して働く 必要性を伝えた。対立の原因については、タスク分解のタイミングまたは バックログリファインメント、デイリースクラム等で違和感を共有して解決ま でもっていけるように促した
22. スクラムマスターになってすぐ直面した問題2 • タスク間の重複がないため、昼会(デイリースクラム)が意味のないものに なりかけていた ◦ 昼会についての改善はたくさんやっているので後ほど話します
23. 最近直面した問題 • 急に思いつきのように昼会の一部変えようとしたら抵抗された話 ◦ 課題感の共有なしにふわっとした提案だけしてしまった ◦ 「つまり何が良くなるの？」(＝効果測定してほしい) という反応が来た ◦ 学んだこと: 提案には背景(の考え)を添える、振り返りなど課題に向き 合いやすい場に持っていく ◦ 結果的には、振り返りの場で提案が受け入れられた
24. チーム運営の オープン化
25. チーム運営のオープン化1 • ある日の振り返りからチーム運営についての内容が多く出るようになって きた。POとスクラムマスターでチーム運営を考える会議をしていたが廃 止。チーム運営に関する話題はスクラムイベントで話すようにした • これによりチームメンバーが自分たちの手で日々のプロセスを変えられる ようになってきた。例えば昼会のアジェンダとか、スクラムイベントのアジェ ンダとか。
26. チーム運営のオープン化2 • 最近では、自分たちの手で日々のプロセスを変えるための変更コストにも 気を使えるようになってきた。スクラムに関するドキュメントをGitHubから、 scrapboxに移したことで簡単に変更できるようになった。 • イノベーター(16) • やってみる(17) • みんなを巻き込む(33)
27. その他にチームとして取り組んだこと • チームランチ開始 ◦ ブラウンバッグ・ミーティング(7)、何か食べながら(9) • 割れ窓タイムの導入 ◦ ふりかえりの時間(5)、グループのアイデンティティ(13)、みんなを巻き込む(33)、お試し期間(47) • 基盤開発タイムの導入 ◦ グループのアイデンティティ(13)、お試し期間(47) • タスク集中タイムの導入 ◦ グループのアイデンティティ(13)、お試し期間(47) • モブレビュータイムの導入 ◦ グループのアイデンティティ(13)、お試し期間(47) • 合宿をしてミッションの確認 ◦ 場所重要(36) • 振り返りのやり方変更 KPT→YWT→KPT ◦ やってみる(17)
28. その他にチームとして取り組んだこと(昼会関連) • 昼会(デイリースクラム)にコンディション共有追加 • 昼会(デイリースクラム)のファシリテーター持ち回り • 昼会(デイリースクラム)にミッションの確認コーナー追加 • 昼会(デイリースクラム)で未アサインのタスク確認コーナー追加 • 昼会(デイリースクラム)にその日時点のベロシティ確認コーナー追加 (mackerelでグラフ！！) • 昼会(デイリースクラム)で各自のタスク進捗状況確認コーナー追加、お互 いに進捗状況にツッコミを入れるようにした
29. その他にチームとして取り組んだこと(昼会関連)
30. 昼会の変更をなぜ行ったのか • コンディション共有追加 ◦ 振り返り時に体調不良者がそこそこいることがわかり、日々のコンディションもお互い気にしてみることに した • ファシリテーター持ち回り ◦ スクラムマスターのファシリテーション疲れ • ミッションの確認コーナー追加 ◦ ミッション作ってみたので日々意識するようにしたかった • 未アサインのタスク確認コーナー追加 ◦ 割り込みタスクアサインしないと進まないことが振り返りでわかったのでその対策 • その日時点のベロシティ確認コーナー追加 ◦ 進捗している/前進している感じを日々味わうため • 各自のタスク進捗状況確認コーナー追加、お互いに進捗状況にツッコミを入れるようにした ◦ 進捗が異常に悪いスプリントの振り返りで出た。止まってる状態を打破するための施策
31. 昼会の変更を行った結果 • メンバーそれぞれのコンディションに配慮しつつ仕事できるようになった • スクラムマスターが楽になり、次なる改善に向かえるようになった • ミッションを意識して仕事できるようになった • 割り込みタスクを処理できるようになった • ベロシティ増えてないことが検知できる • 進捗が止まったタスクに気が付き、相互にツッコミできるようになった
32. 振り返りの変更をなぜ行ったのか • KPT→YWT→KPTと変更した • たぶん深い理由はなくKPTで始まった • YWTにした理由 ◦ 新メンバーが他の人の作業がわからないという課題があり、スプリン トでやったことを確認したかった ◦ Pばかり出てくると気が滅入ってくる • チームの改善がまったりしたと感じたためKPTに戻した ◦ Pを建設的に議論できるチーム状況になった ◦ Pが出てこないとキレがない。改善のネタが出てきにくい
33. 振り返りの変更を行った結果 • 他の人の作業内容がわからないことで困っていることがわかった • Pばかり出ても建設的な議論ができるようになった（と思う • やっぱりKPTの方が改善が進むと感じた
34. 直面している課題 • チームのプロジェクト進捗が停滞するときがあり、停滞の本当の原因にたどり着けて いるか不安がある • 長く取り掛かっているDoingタスクが片付かないときがある ◦ 他チームのプロダクトのリリースに関わる作業についてはコミュニケーションコ ストも高いし、完了タイミングもこちらではハンドリングしきれないとか • スプリントバックログアイテムの完了の定義が足りているのか、過剰なのかがタスク 着手後にしか温度感がわからない
35. まとめ
36. まとめ • プロダクトオーナーいわく、改善するぞって意識がチームにできたのが一番よかった • スクラムマスターとしてもだいぶ良いチームになったと実感がある • 割り込みたくさんあって大変だけど、インクリメンタルにやる仕事の部分はスクラムの エッセンスを取り入れつつやれています • 変化をもたらすということが、スクラムマスターやプロダクトオーナー以外からも起こる ようになってきた • とは言え悩みもあるのでお話させてください
37. まとめ 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。素 早く変えてもし仮にダメだったら素早く戻せばよい。 Songmu https://developer.hatenastaff.com/entry/2018/04/04/111410 変化するには、こうした変化を受け入れる発言や態度とともに同僚、古参、上長とかからのフォロ ワーシップつまりやっていきに対するのっていきが重要だと感じている 参考: https://speakerdeck.com/kentaro/the-secret-of-leadership-and-followership
38. 各職種絶賛募集中 https://hatenacorp.jp/recruit/career/