タスクボードで手戻りを見える化したい（のでスプレッドシートに書いてみた）
発端
なんだか手戻りが多そうなんだな、と思うことがあって、なんとかそれを可視化したいなと思ってスプレッドシートで見える化してみました。 雑なやり方だったけど効果があったのでメモしときます。 もっといいやり方知ってる人いたら教えてください。
やったこと
前提
これができてる必要があります。
- 開発の各ステップが分かれている（タスクボードが運用されているならそうなっているはず）
- 各ステップから次のステップにいつ移動したかが追える（私はJIRAでこれをやっていたのでステータスの変更で追えた）
作ったもの
これだけだと意味わからないと思うので補足説明します。
何を書くか
このルールに則って書くだけです。
- ステップが進むごとに、そのステップに入った日時をプロットする。
- この例ではスプリントの何日目かをプロットしています。
- もし手戻りがある（ステップが前に戻る）場合は、その案件の行を追加し、戻ったステップのところに日時をプロットする。
何がわかるか
この図からは
- 手戻りの多い案件がわかる
- 行数が多いのがそれなので
- 手戻りによってどのくらいリードタイムが伸びたのかがわかります
- 手戻ったところのステップと、そのステップを最終的に通過した日がわかるので
がわかります。図を書き足すとこんな感じ。
この例だと、
- 案件A
- コードレビューでめっちゃ手戻ってる
- これによってリードタイム3日伸びてる
- 案件B
- 最後の受け入れで手戻った
- 結果もう一度受け入れに行くまで+5日かかった
あたりがデータから読み取れます。
効果
手戻り多っ！という共通認識
これを見せると、ほぼ確実に、A案件の手戻り多い！と言います。共通認識の構築にバッチリ。
リードタイム観点で、自分たちの行動を振り返れる
例えば、コードレビューの行ったり来たりで、3日リードタイムを失うのって良いことなんだっけ？と言った議論ができます。
ペアプロやモブプロした方が早かったんじゃ？と言ったことが感覚的に出てくるので、そう言ったTryも出て来やすくなります。
また、大きな手戻り（ステップを大きくまたぐもの）があった場合に、それによるダメージの大きさのインパクトが伝わります。それによってどうしたらこれ前ステップでなんとかできるかな、と考えるきっかけになっています。
まとめにかえて
カンバン運用していたりすると、手戻りの可視化、改善ってラインストップで防いでいると思います。ただしラインストップは、初めてやる場合は心理的負担が高いと思います。その手前でこう言った形で手戻りを見える化できると、その観点でのカイゼンに目が向くのでやってみてよかったな、と感じました。
ScrumButしてリードタイムがクッソのびちゃう話。
ScrumButは簡単にいうとスクラムアンチパターン集みたいなものです。
上記によればこういうフォーマットをとります。
(ScrumBut: スクラムやってるよ。けど)(Reason：理由)(Workaround： 応急処置)
今回はそのScrumButの一つの話です。
スクラムやってるよ。けど...
今回の例のScrumButは下記のような事例です。
スクラムやってるよ。でも1スプリントでundoneが多くあるから、 doneにできるように開発しやすい形にタスクを分けて、1スプリントで完結できるようにしたんだ。
例えば、調査、サーバーサイドのAPI開発、フロントエンド開発、というタスク群があったとして、下記のようにしてしまう状態です。
何が起きるか？
これによって、doneはすると思います。doneするようなタスクわりにしているわけですから。 でも、これは結局APIだけリリースしてもユーザーに価値を提供しません。
むしろ、元々のやり方に比べ、途中に他の案件をしてしまったりして待ちが発生し、doneしているのにリードタイムをいたずらに伸ばしてしまっている状態になってしまっています。
なぜこうなるのか？
引力は色々あるかと思うのですが
- 何がなんでもdoneしなければならない
- 調査は見積もりをぶらしてしまうので、スプリントを分けたい
といった引力があるのかな、と思います。
派生して起きる厄介なこと
この事例にはまってしまうと、開発内部は自分たちを「予定通りに安定して開発をしているチーム」と認識するかもしれません。 しかし、ステークホルダーから見ると、これはリードタイムがただただ長くなっているだけの状態です。
こうなると、開発に何かを依頼する側は「開発してもn週間かかるから、よく練って確度上げてから開発に依頼しよう」となる引力が働きます。 しかし、開発内部がもし勘違いしていると、「俺らアジャイルなのに、ステークホルダーが全然案件を小粒で出さねーから仮説検証できねー」といった軋轢がおきかねません。
どうするのか
月並みですが、なんのためにスクラムやっているんだろう？を問い直すことからかな、と思っています。
スクラムをやっている、ということは検査、適応、透明性のサイクルが回っているということなので、スプリントを回すことによって何を明らかにしたいのか、あるいは明らかにしたことから何を考察してきたかをトレースすると良いのではないでしょうか。ここまでの例で言えば、undoneになるのが課題だったとすると、それがなぜ課題なのかを考えるとか。undoneはとにかくいけない、なので無くさねば、というのはその背後にあった目的を見失ってしまう場合があります。
その明らかにしたいものに開発のリードタイムが入っているのであれば、その観点でふりかえりしたり計測してみたりすると良いですね。場合によってはスクラムにこだわる必要もないかもしれません。 私が似たような経験をした時は、手戻りの可視化してたりしました。それは別エントリーで。
まとめ
結局は目的に忠実な点にフォーカスした検査・適応・透明化をしていきましょう。って話でした。
JJUG CCC Fall 2017でしゃべってきた。
というわけで@shimashima35さんとSelenideとGebの話をしゃべってきました。
当日のスライド
思い
今まで登壇するときは、Geb推しでGebの良さを語ることが多かったです。その場合もコンテクスト大事、というのは気をつけて発表していたつもりだったのですが、最近自分の周りで必ずしも幸せなツールチョイスをしていない場合があるかも、というのを気にしていました。
というわけで、今回はそういうツール選びで悩んでいる人に寄り添える形のセッションにしようと考えました。
結果、特定のツールを強く推すの色を薄めにして、 @shimashima35さんとタッグを組んだ対話型にすることで、複数のツールのスイートスポットがどんなところにあるのか、というのを細かいコンテクスト含め明らかにするのを目指したセッションにしました。
それがどういう結果になったのかはわかりませんので、参加してくださった方はぜひアンケートでフィードバックいただければと思います。
最後に
JJUG CCCでの登壇は２度目でしたが、しゃべることでむしろ元気をもらえる良いイベントだと思います。
参加してくださったみなさん、スタッフのみなさん、ありがとうございました。
