今回のテーマ: 「チームの課題を起点とした改善」
チームの課題に目を向け、それを解決する手段としてScrum Practiceを利用していく。
チームメンバがその課題の当事者として解決策に対して納得感を持って行動できるようにすることを前提として進めることで、Scrumに抵抗意識を持つことを極力防ぐだけでなくメンバ間でよりよい提案も生まれることを期待!!
01. 課題の発見
背景
自分が今のチームに配属されてから、進め方に対して少し違和感を覚えたことがきっかけ
- PM やビジネス側の人との距離が遠い
- プロジェクトごとにチーム作成&解散
- 1人/Projectの場合もあり何をしているのか把握が難しい(属人化?)
など
これは自分だけが感じている違和感なのだろうか
自問自答しても答えが出ないので、実際に聞いてみよう！と動いてみた
やったこと
- 概要
- プロジェクトでは
2week / 1sprintとして活動 - 属人性を無くすこと・知識の共有のためにモブ/ペアワークが前提
- 週に1回顔を合わせ、進捗確認や認識合わせを行なっていた
(事前にアジャイルサムライを読んでもらい、アジャイルの進め方について理解を深めてもらっている)
- 目的
迅速な開発やFBによる改善を繰り返して、より良いものを届けること
※手段として以下が挙げられる
- すぐに顧客のもとに届ける手段としての、CI/CD
- 認識齟齬をなくすための
Sprint review/Backlog refinement - 属人化を防いでメンバのカバーを行うためのチーム横断的な組織づくり(タスク洗い出し、モブなど)
- Sprint の流れ
- タスク内容洗い出し&見積もり
- チーム分け&タスク決定
- Sprint Start
- Backlog Refinement
- Sprint Review
- Retrospective
- Sprint Close
- Update Story Point
- Sprint Details
タスク内容洗い出し & 見積もり
タスク洗い出し(~2h)
- 画面共有をして進行する
-
driverとnavigatorを15分おきに交代しながら作業を進める。
(複数人に説明する機会を設けて、説明できないものを有識者が補うスタイル) - 場合によってはコードレベルまで確認することで、そのタスクにて何をすべきかを全員で明確にする。
- 洗い出す数は次
スプリントで must なものと、万が一終わった場合に手持ち無沙汰にならないように nice to have を数個 - タスクの粒度は最大で 2week で終わるもの。大きすぎる場合は
Storyとして作成しsub taskに分割 -
Doneの条件(期待値？)や必要な資料、修正の入るリポジトリや class など判明したこと(作業の段取り)は、description に記述する
※PMが事前にtaskやストーリーをBacklogに作成してくれていることを前提としている。
タスク見積もり(~1h)
- 洗い出したタスク(ストーリー)に対してポイントを振り分ける
(利用していたtool → Pointing Poker: https://www.pointingpoker.com/) - ポイントはあくまでタスクの規模のため、
sprintを回していく上でチーム内でイメージを固めていく -
Sprint終わりに行うpointの振り返りにて、pointの基準となるタスクを順次更新
例: Sprint Retrospective
ここで見えてきた課題
このうち今回は 取り掛かりやすそうなものを pick up して解決に向かって取り組んでいくことに
02. pair(mob) work
以下、ざっくりと記述しています。
やったこと
-
ペア作成
- たまたま 自分が担当することになったプロジェクトが
review問題について問題提起してくれていた方と一緒だったこともありPair Workを提案して開始
- たまたま 自分が担当することになったプロジェクトが
-
実践プラクティス
-
mob時間の確保 -
VSCodeを利用した共同編集 - 意図的に休憩を挟む
- 最初: 45m → 45m → 休憩10m の繰り返し
- いま: したくなったときに伝える
-
pairの片方しかassigneされてないタスクも共有 - 雑談を適度に織り込む
pair review- 集まる
zoom roomを固定化 - 仕様確認
- お菓子など気にせず食べてOK
- わんちゃんや赤ちゃん登場すると和む
-
結果
- 効果的だったこと
- QA 対応が複数人で対応可能になった
- どちらかが休んでも稼働し続けられるようになった
-
pairの片方をレビュワーに設定すると、pairsしている人のレビューコストについては下げることにつながった - 仕事以外の話もすんなりできる間柄になれた
- もやもやポイント
-
Pairに慣れるまではタスクが進まなくて不安になる - エディタ問題は根が深い
- この他にも細々と...
生まれた課題
お互いのもやもやした気持ちがうやむやになってしまった
03. Sprint ごとにふりかえり(Sprint Retrospective)
やったこと
- Keep / Good
-
keepしたいことや、良かったことをどんどん書き込む！ -
tryで実践したことがいい結果につながったかどうかの確認にもつながる
- MoyaMoya
- どんなことでもいいので、少しもやっとしたことを書く
-
Problemとしなかった理由は、問題として捉えようとすると萎縮してかけないこともあるため - ここで出した内容を基本的に
tryとして次sprintで改善していく
- Try
- 上記二つで出た付箋をもとに、投票をして決定(
keep/goodでもmoyamoyaでもどちらからも選出可) - 必ず次の週に実践可能な粒度で作成
-
Mobで若干話していた「mob timer」や「vscode shere」, 「sprint planning」や 次章で説明する「sprint review」はここから生まれた
結果
- 繰り返すことでお互いの心境を話しやすい仲になれた
- 片方に何か問題があったときはお互いの問題として捉えて解決をすることが自然にできるようになった
- 他のメンバを積極的に誘って、大きめなモブを実施したりすることにつながった
- さまざまなTryで実験できた
- もやもやに対して、さまざまな
tryをすることで自分達に合う方法をたくさん探ることができた(もちろん合わないものも多数) -
retrospectiveのおかげでtryから自然な流れでsprint planning,sprint reviewの実施につなげることができた
- 生まれた課題
Mob や Pair 作業に対する課題は各々解決することができるようになってきたが、プロジェクトの対応してからその Feedback をいただくまでに期間が空くことがあり、別の開発タスクに携わってからだと、思い出す作業も必要になり時間のロスが発生してしまう。
04. Sprint Review
やったこと
- ビジネス側の人に直接交渉
たまたま 担当者のうち一人が仕事で携わったことのある人だったこともあり、「やってみよう」と声掛け
お疲れさまです！
開発内容の確認やラフなコミュニケーションの場として週に一度30分程度の mtg を設けたいと考えているのですが、ご検討のほど、よろしくお願いします！
■背景
STG 反映後の確認+Feedback が時間がかかることがあること
別の開発タスクに携わってからだと、思い出す作業も必要になり時間のロスが発生してしまうこと
チーム間に距離を感じ、気軽に質問や雑談ができる雰囲気になっていないこと(主観)
■目的
一緒にディスカッションしながら開発内容の review+feedback
次週開発する内容の確認(既存からの変更など)
チーム間のラフなコミュニケーション!!!
- 上記依頼と話し合い
- 担当者・MGR 好印象を持っていただくことができた
- 次に他チームも交えて相談することで、開発寄りな話し合いの場を作成
※ 相談から MTG 開始まで大体 2~3week
- 目的
- 一緒にディスカッションしながら開発内容の review+feedback
- 次週開発する内容の確認(既存からの変更など)
- チーム間のラフなコミュニケーション!!!
- 進め方
- 事前に
confluenceページを作成 - 当日はページを確認しながら以下の順番で進めていった
-
JiraタスクベースにSprintで実施した内容の確認 - さまりとして全体像の共有
- 動作確認
- 今回は mobile を使った挙動確認だったので動画を事前に用意
- この動画を見ながら現状の問題を共有して議論
- 全体的な質問や Feedback タイム
-
結果
- 課題認識 → ビジネスサイドの判断 →
Tryまでのスピード感が格段にup - コミュニケーションの場として機能するようになった
- 他チームからこの取り組みについていい評価をいただけた
終わりに
まだまだこれからも取り組んでいきたいと思います！