テトリスで学ぶアジャイル

アジャイルの行動規範をテトリスを使って説明してみました。アジャイルの基本用語を知っているけど、イマイチ行動に落とし込めない入門レベルの人向けです。

まず基本ルール。横一列が揃ったら完成(=Done)です。画面の右上には、次に控えているバックログが表示されています。

埋められていない部分は、負債(要件漏れ、バグ、技術的負債など)です。負債が残っているとDoneの定義を満たせず、完成しません。

リリースしてユーザーが実際に利用すると、何かしらのフィードバックが返ってきます。タイミングは不定期、修正箇所はランダム、量は予測不能です。唯一わかっているのは、必ずフィードバックがあることです。

多くの負債がたまるとパンクし、プロダクトが死にます。ユーザーは離脱し、開発者も修正するモチベーションを維持できません。そのプロダクトは捨てて、新しく作り直したほうがよい、と判断します。

さて問題です。アジャイルな行動規範では、このテトリスはどこに置くべきでしょうか。(次のスライドに答えがあるので、じっくり考えたい人は注意)

答えはCです。動くプロダクトを小さく速く作ることが大事です。またアジャイルでは不確実性を抱えたまま進めるので、突然負債が生まれます。これらに対処するためには、常にクリーンな状態を維持します。

Badな例は「最後にまとめてテストする」「最後にまとめてリリースする」を表しています。とてもリスキーな立ち回りなので、やめましょう。

バックログアイテムは、扱いやすい状態に分割しましょう。大きくて、いびつな形のバックログは、どうやって対処したらいいか瞬時に判断できないし、負債を生む要因にもなります。

バックログの分割方法はある程度パターン化されています。テトリスのようにお馴染みのパターンで分割すると、対処が楽になります。参考記事はこちら→https://www.ryuzee.com/contents/blog/14554

アジャイルは行き当りばったりではありません。ある程度、先を見通しながら計画を立てて行動します。そのためにバックログは予め準備しておきましょう。

とはいえ、準備しすぎても、計画を立てるのには役立ちません。テトリスで言えば、現在のアイテムが落ち切るまでに参考にできる量があれば十分です。状況によって無駄になるリスクがあるため、必要最低限を狙います。

さて問題です。アジャイルな行動規範では、チームプレイにより必要な要素はどちらでしょうか。(次のスライドに答えがあるので、じっくり考えたい人は注意)

答えはBです。兎にも角にも、会話しましょう。もちろんプロセスやルールは役立ちますが、刻々と状況が変化するときには、弊害を生むことのほうが多いです。まずは会話で協力できるようにしましょう。

Badな例は、Player1がフロントエンド、Player2がサーバーサイド、...、Player5がテストのような役割分担を表しています。明確な役割分担は、負債を生む原因になるので、やめましょう。

必要なのは対話です。誰がどこを担当しても構いません。プロダクトにとって、今必要な箇所をチームで連携してカバーします。全員で協力して、小さくリリースし、常にクリーンな状態を維持しましょう。

いかがでしたか？テトリスを通じて、アジャイルで具体的にどんな行動をとるべきかを想像してもらえたら嬉しいです。ではでは。

p.s. 以前、スクラムの図解をつくったので、よかったらどうぞ。

@ryuzee さんのスクラム概要図をベースに、見やすくリデザインしてみました。 pic.twitter.com/79gR5AnlUj

— さかぱ (@zacapa_23) March 1, 2021

スクラム作成物の関連性をサイクル図にしてみました。チームの課題点を見つけるためにお使いください。

例えば「プロダクトバックログ」の品質が悪ければ、バックログリファインメントやスプリントレビューのやり方を見直します。 pic.twitter.com/vo64gjmVEn

— さかぱ (@zacapa_23) March 3, 2021

よくある「スクラムをやっているようでやっていないパターン」を図にしました。

スクラムの実現には、肩書を変えるだけではなく、ふるまいも変える必要がある。コミュニケーションパスや、その内容によって、スクラムをしているか判断する。

スクラムをリネームしただけの組織にならないように注意。 pic.twitter.com/T5bWXNEec7

— さかぱ (@zacapa_23) March 17, 2021