読者です 読者をやめる 読者になる 読者になる

今の僕のチームの開発スタイル

Team

f:id:bufferings:20150803085311p:plain

今日は勉強する気が起きなかったので、お絵かきしてた。
今、ちらちらと「ユーザーストーリーマッピング」を読んでるんだけど

books.rakuten.co.jp

今までなんとなく感覚でやってたことが、まとまってて読んでて楽しい。
で、↑の絵を描いたんだけど。これが今の僕のチームの開発スタイルです。
今もずっと改善し続けてるから、もっと良くなっていきそう。

左下の人の絵

ビジネスチーム、開発チーム、UI/UXチームがあるよってことで。
そのそれぞれの代表が意見を出しあうProduct Owner Teamが真ん中にあります。
それを取りまとめるのが、Product Ownerです。

左上のスマイリー

POTがメインで話し合うことです。

1. うちの会社が困ってること
2. それは誰が、どういうことで困ってるからなのか?
3. じゃあ、うちの会社がいい感じになるってどういう状況?
4. そのためには、(2)の人がどういう状態になればいいのか?
5. そういう状態になるためには何が必要か?
6. そのためには何を作ればいいか

つまり、どうやったらユーザーの明日をちょっと良くできるか、それで僕らも嬉しいか。
そんなことを話合います。そして、MVPを決めます。

右上のFeature Definition

スマイリーの部分を、プロトタイプで検証しながら共通理解を築きながら、
簡単なドキュメントに落としこんでいきます。開発着手できるように。

ちなみに、このとき、開発チームはPreparation Backlogというものでタスクを見える化してます。

Sprint Backlog

Feature Definitionに開発チームが合意できたら、Sprint Backlogに落としこんで開発を進めます。

ただ、ここではリリースできるものを作るというよりは作ったものをPOTが確認できるものを作るという感じです。
社内リリースをして見てもらったり、一部のユーザーに公開してフィードバックをもらったり。

「合意できたら」と書いたのは、開発チームは言われたものを作るのではなくて
自分たちが納得したものを作ってるということです。

開発チームを納得させるだけの材料が揃ってないなら、もう一回考えなおしたほうがよいです。

スプリントは9営業日固定です。その後1日中ミーティングDayがあります。Review/Retrospective/Planning。

あ、で、何度か検証を繰り返した後、リリースできるようになったら、エンドユーザー向けにリリースします。

そんな感じです。

Operation Kanban

うちのチームは運用もやってるので、それ用のカンバンもあります。

リリースした後

リリースした後は、僕らが立てた仮説が実際にどうだったかを、POTが検証します。
そして次のプランを立てていきます。

POはSprint Reviewのときに、前回リリースしたものがどういう数字を出しているか
などをチームにフィードバックしてくれます。

ストーリー

の切り方が、もうちょっとうまくできそうだなーって、ユーザーストーリーマッピングを読みながら思った。