ユーザーストーリーマッピングを読んだ。面白かった。
0章から5章までと、12章が好きです。books.rakuten.co.jp
しっくりこない
僕のチームでは、スクラムを自分たちに合うようにアレンジして開発してます。
開発自体は、まぁ、そんなにもう悩んでなくて。
でも、その前の部分がいまいちしっくりこないなぁって思ってたん。
つまり、バックログを作るまでの部分のことね。
回想
勘でやってた期
最初の頃は、バックログを作る部分をプロデューサーとUI/UXディレクターと僕でやってました。
んで、エンジニアリーダーとしての僕は、勘だけで適当にやってました。それなりにうまくいってたんじゃないかな。
仕組みにする期
でも、まぁ、その仕事をしてるのが僕だけってのも、あんまり良くないし。つーか、僕もコード書きたいし。
リーダーを交代制にしようぜー。って言って、別のメンバーが僕と交代でエンジニアリーダーになりました。
大変そう
けど、エンジニアリーダーはチームの開発も見つつ、プロダクトバックログの準備もやりつつ。
自分でやってるときは気づかなかったけど、結構大変そう。
チームで？
そこって、リーダー1人がやるよりチームでやったほうがいいんじゃね？ってことになって。チームでやることにしてみたの。つまりバックログを作るためのバックログを作ってスプリントでやってみたってことになるね。
混乱期
そしたら、混乱したよね。
バックログを作るというゴールと、リリースするというゴールの2つの視点でスプリントにのぞむんで。
やっぱわけよう
ということで、今は分けてて、チームは平和。
結局、プロデューサーとディレクターとエンジニアリーダーがプロダクトオーナーチームみたいな感じでやってます。
大変そう
で、やっぱり大変そうなわけね。
これ、「準備」って名前であたかも開発のための前段階の作業みたいに見てるけど、
もしかして、結構重いんじゃないか？それなら、なんかもっとやり方があるんじゃないか？
というのを最近やっと感じてきました。
回想オワリ
そんなときにユーザーストーリーマッピングを読みました。
ユーザーストーリーマッピングを読んで
やっぱり、開発のループの前に、同じくらい大変そうなディスカバリーのループがあるじゃん！
ってことに気づかせてくれました。ありがとう。Jeff。
そして、その辺りの上手なやり方のヒントを沢山教えてもらったように感じています。
なので、色々と試行錯誤してみようと思います。たまに川口さん召喚してアドバイスもらいながら。
とにかく、色んな気づきを与えてくれるカラフルな絵の素敵な本でした。オススメです！
ざっくり紹介
この本では、主に上記の写真の左側の部分に重点を置いてますー。
0章 ←この本にイントロダクションはない
この本の中で1つだけ選ぶとしたらどこ？って言われたら迷わず0章。
この本の全てはここに詰まってるって言ってもいいんじゃないかな。
1章←全体像
フラットバックログの悲劇、というのがウンウンってなる。
全体の中のどこにいるのか、というのがわかりにくくなるんだよね。
2章←MVP
MVPは仮説の証明のため！
3章←MVPe
実験のためのMVPe。プロトタイプとか。ふむ。
4章←スライス
リリースのスライスって、言われてみればそんな風に作ってた。
でも、スクラム的にはPotentially Shippable Productになってないなぁって、ちょっと後ろめたくも思ってたので。仲間がいて安心した。
5章←ユーザーストーリーマッピング
0-4章までの話が、ここにつながる。気持ちがいい。
