私はエンジニア4人のチームでスクラム開発をしています。
発足してもうすぐ一年ほどですが、ここ一ヶ月でとても良い「変化」を感じていて、
より重要なコトに向き合えている感覚があります。
なので、一ヶ月間の「変化」について頑張って言語化してみようと思います。
（次に活かす意味でも大切！）
また、他のチームメンバーが書いたスクラム開発の記事が素敵だったので、私も続いてみました。
同じような課題を感じているチームに届いたら良いなと思います。
チームメンバーの記事
-
普段のスプリントを言語化してみる
- 各セレモニーに対してどんな進め方をしているか書かれています。一ヶ月ほど前の記事ですがもう今は結構違う・・・！変わっていないのは、リリース時にゲンスルーの画像を貼っていることくらいでしょうか。
-
僕らのスクラム開発１
- 最近書かれた記事。「変化」後です。スクラム開発の現状についてとても具体的にまとめられています。
小さいようで、大きな「変化」
ここ一ヶ月で変化をもたらす小さな改善はたくさんありました。本当にたくさん。
- スプリント中に1タスクにかかる時間を測るようになった
- プランニングで漏れていた「追加タスク」を👿悪👿だと捉えるようになった
- タスクを追加する際の「ギロンのルール」を定めた
- セレモニーでの議論は結構厳密にタイムボックスを切るようになった
- 複雑度とは何かを言語化した上で、AC（受け入れ条件）をGiven/When/Thenで書くようになった
- etc...
そのような小さい改善が、各セレモニー、特にリファインメントとプランニング2の進め方を大きく変化させたので、それぞれについて変化を書いていこうと思います。
リファインメントの課題と変化
私たちはリファインメントでPBIを見積もることをゴールとしています。
なので、課題を理解し→AC（受け入れ条件）を明確にして→それを元に見積もる、という流れをだいたい8PBIくらい行います。
その当時のACは、テストケースを書くかのようにがっちり書いてみたり、課題の裏返し「〜ができる」と書くだけにしてみたり、プランニングで都度書き足すスタイルになっちゃったり・・・という感じでした。
そうなるとどうしても見積りには不要な議論もしてしまうのです・・・。
また、最近のPBIは課題は特定されているがプロトタイプがない状態、要するにHOWが決まっていない状態でプロダクトバックログに積まれていることが多く、HOWの話をしすぎて1つも見積もれずに1時間がすぎる、なんてこともありました。
チームが守るべき「生産性」を下げるような形になっていたはずです。
一ヶ月前のこと。
まずは、「見積もる」というゴールを満たすために最速で終わらせる努力をしてみました。
HOWを明確にせず、「これができるようになる機能を作るんだよね！今回はデータの"更新"の機能だね。」くらいの最低限の会話で見積もってみた結果、過去最速でリファインメントを終わらせることができました🎉㊗️
しかし、そのしわ寄せがプランニングに来るということにすぐに気づきました😇
必要最低限の会話しかしてないのでACがざっくりしており、プランニングにてタスクが出せず詳細を詰める羽目になったのです（笑）
では、私たちにとってのリファインメント時点での"あるべきAC"というのはどのくらいの粒度なんでしょうか。
リファイメントのゴールは見積もることなので、私たちにとってのACは、「POが想定するシナリオが表現されており、それを見て複雑度がわかる形」が良さそうです。
そこで、複雑度に対して認識を揃える会を開催しました。（SMの巧みな導きによって気づいた課題だった）
なんとなく「これって複雑度高いよね〜〜〜」と会話しているのは、一体どんな要素が絡んでいるのかを言語化してみました。
複雑度に関係する要素（未知のものは解消している前提）
- 正常系・異常系のパターン数
- 対応すべき画面の数
- DB設計があるかどうか
- etc...
このように、しっかりと因数分解してみることで複雑度に対する認識が合いました。
よって、これらの要素が確認できるミニマムのTRYとして、 「ACをGiven/When/Then」で書くこと を徹底することにしました。
そうすることによって、リファインメントで会話する範囲がかなり明確になり、議論が目的からずれることがあまりなくなりました。
副次的メリットもあって、このACがそのままE2Eテストコードになっていたりもしています。
また、Given/Whenの裏返しに異常系が潜んでいるのではないか！と考えることによって、異常系を出しやすくなった気がします。
例）
課題：「ユーザーは保存した検索条件を削除できない」
Given 一覧閲覧権限を持っている人
And 一覧画面にいる
And "検索条件A"が存在している 👉 検索条件が一個も存在しない時はどうする・・・？！とか
ある程度フォーマットがあった方が議論はブレないものです。
この変化は、リファインメントを円滑に進めるのに有効でしたし、結果的に複雑度を確度高く捉えるコトでベロシティの安定に繋がるといいなと思います。
プランニング2・スプリントの課題と変化
プランニング2では、PBIのACを満たすためのタスクを30min単位で出していきます。
例えば「APIのコントローラのテストに正常系を1パターン足す」のようなものです。
30minのタスクに切っているので、全てのPBIを完了させるために必要な時間が当然わかります。
しかし「え、これ計算上今日終わるじゃん（笑）」っていう会話をしたにも関わらず、一週間経ってみる全てを完了することができなかった・・・という事象が3回ほどありました。（恥ずかしい）
いかにも課題が隠れていそうなこの事象に対して私たちは遂に真摯に向き合うことにし、まずは1タスクにかかる時間をタスクの付箋に記載することにしました。（まずは検証！！）
すると、タスクは意外と30min以内に終わっており、実はプランニングでは出しきれていなかった「追加タスク」の付箋がかなり増えていたのです・・・！
真の課題を発見できたので、その週から「追加タスク」の付箋の色をバキバキのピンク色にし、目立つようにしてみました。
実質、「追加タスク」が増えなければ、期限内にタスクを終わらせることができ、見積もり通りにリリースできるわけです。
そうして、「いかに追加タスクを出さないよう、プランニングで出し切るか」ということを重視し始めました。
様々な試行錯誤をした結果、以下のような流れでプランニング2を行なっています。
- ACの確認
- (ストーリーポイント×8)minでタスクだし
- コードを見ながら青い付箋にタスクを書く（E2Eテスト→インフラ→フロント→サーバーサイドの順）
- コードを見ている時にリファクタすべき箇所を見つけたら、リファクタのタスクを黄色の付箋に書く
- 1minでタスクとACを見比べ、漏れがない確認
- 3minで上記の行いを振り返り、小さなTRYをだす
- PBIの数これらを繰り返す
特に3minで振り返る時間は有意義で、小さなTRYをすぐに次に活かせます。
個人的に思うのは、議論していれば何かしらの違和感や課題を検知してなんとなくモヤモヤするもので（笑）それをチームで発散して改善すべく案を出し、すぐに実行できるというのは、とても成長を感じられます。
なぜ「変化」したのか
小さなTRYをできるだけ出して規則や共通言語を増やしていけたから、それによってより重要な課題の改善に時間を割けるようになったからな気がします。
スクラムチームは、「生産性」を最大化する責任があります。
このような変化が「生産性」を最大化する強い意識に繋がった気もしています。
小さなTRYを出すのは簡単なようで難しい、ようで、簡単です。（チームを信頼しているから簡単と思える）
大きな改善をするには、今までを振り返るとなんとなく2ルートあると思っています。
正統派改善ルート
課題の原因を特定するための検証方法が思いつけば、まずは検証する！（タスクの時間を測ってみる、とか）
そして検証結果に応じて真の課題の原因を特定し、小さな改善案をTRYすることを繰り返す。
やんちゃ系改善ルート
課題だとは感じるが、どうしたらいいのかなあ、となったとき。
そんなときは100%振り切ってみる！（どんなACがいいか悩んでるなら1行しか書かないようにしてみる！とか（笑））
そうするとまた何か課題が出てきます、それを改善しようとしてみる。
それでも分からなければ、0%に振り切ってみる。
そうすると、落とし所が見えてくることがある・・・！
何かやってみて、失敗したとしても、その気づきがまた最強のチームにしてくれるのだから、失敗ではないし。
とにかく、何か変化を起こすことが大切なんだなあ。（悟）