この記事の後編です。
前編では、チームが集まるところから始まって、目的を理解し、ソリューションの仮説をストーリーに分解して見積もり、計画を立てるところまで辿り着いた。
最初の計画が立ったら、週次サイクルで開発を進めていく。
週始まりに30分程度のプランニングセッションを行い、週終わりにチームでふりかえりを行う。
日々の活動は、ペア作業をベースに、いい感じにやる。いい感じがどういう感じかは、この記事に書いた。
ここからは、上の記事に表現できていない部分を補う形で書いていきたい。
週次のプランニング
週次のプランニングはチーム全体で行う。チーム全体というのは、開発者だけでなく、プロダクトマネージャーやデザイナーを含むという意味だ。*1
プランニングの前半では、手短にバーンダウンを見てペースを確認し、直近のサイクル（週）にどんなストーリーを届けられたかを簡単に確認する。
直近のサイクルで発見したことで、参加者（の一部）に共有できていないことがあれば、共有しておく。たとえば「想定以上に難易度の高い部分が見つかった」であったり、「このような機能もあった方がよいのではないか*2」であったりだ。
後半では、これまでにわかったことを踏まえて、次のサイクルに取り組むことの優先順位を見直す。
見直す、と言ったのは、最初に一定の計画は立てており、また前週までにも見直し続けてきた結果として、優先順位は一応ついているからだ。それでも、毎週状況は変わるので、優先順位も毎週見直し続ける。
最低限、次のサイクルの優先順位は全員でしっかりと確認する。それ以降の計画をどの程度しっかり見直すかは、状況による。
バーンダウンの序盤であれば、全体を大きく見直すことは少ないだろう。まだ見直すに足る情報も集まっていないことが多いからだ。
中盤に差し掛かった頃には、よほど「想定通り」でない限りは、一度全体を大きく見直すことも多い。
見直すといって、すでにあるストーリーの順番を単純に入れ替えることもあれば、すでにあるストーリーのうちひとかたまりを取り除いて、異なるストーリー群を入れることもある。かたまりで取り除くこともあれば、細かく削っていくこともある。
計画づくりとは価値の探究なのだ。
（『アジャイルな見積もりと計画づくり』）
まとめて30分くらいだが、すべて30分ですむかは日々のコミュニケーション頻度にもよる。
プロダクトマネージャやデザイナーが兼任で忙しく、日常的に頻繁なコミュニケーションが取れていない場合は、少し長めに（たとえば45分）必要になることもあるようだと思っている。
単に計画した仕事を終わらせていくための、業務連絡の会話に終始したくない。
こういう新しいことがわかった、もっとこうした方がいいんじゃないか、といった、不確実性を生かして価値を探求する会話を増やしたい。
そのために必要なら、少し長めに時間を取るのもいいと思う。
もちろん理想は、常にそういう会話ができていて、プランニングは便利な一つの区切りにすぎない状態だ。それなら、30分もかからずに終わるだろう。
日々の活動
日々の活動について前掲の記事に書けていなかった部分として、ストーリーの選択や分割がある。
バックログは基本的に優先順位に従って並んではいるが、状況は刻一刻と変わっていく。一週間の中でも、開発を進めることで新たにわかることも多い。
もし4人チームなら、2ペアだ。WIPは最大2となる。各ペアでそれぞれ1つのストーリーを進めていて、片方が終わったとする。次に何をやるか。これは自動的には決まらない。
現状を鑑みて、次に何をやるのが最善かを都度考える。一番重要なのは、価値だ。原則として、バックログは価値の高い順に並べている。作り手の都合で順序を歪めることも時には必要になるが、最小限にしたい。
現時点のすべての情報を考慮に入れたとき、次に何をやるのが一番価値が高いのか、チームでもう一度考える。計画づくりとは価値の探究なのだ。
また、ストーリーを分割した方がよいと気づくこともある。
個人的には、基本的にストーリーはできる限り小さくした方がよいと思っている。その方がフロー効率（価値の流れ）も最大化されるし、WIPが小さくなってエンジニアリングの観点でも都合がよいからだ。
ストーリーを進めていて、あるストーリーが数日間WIPにとどまっていることに気づく。そんなときは、ストーリーを分割できないか考える。そして、ほぼ必ず、分割できる。
あるいは、ストーリーを始めて、まずE2Eテストのシナリオを考え始めた時点ですぐに分割できることに気づくこともある。分割しなくてもすぐに終わるレベルなら、無理に分割しなくてもいいかもしれない。しかし、たいていは分割した方がよいという結論になることが多い。
ストーリーの分割は、隠れていた価値に気づくことでもある。ストーリーや会話の中で明示されていなかったさまざまな価値が実はあったのだ。
場合によっては、分割したストーリーのうち一部には取り組まないという選択もする。価値の大きさと、届けるまでの早さや全体のバランスを見て考える。その場で判断しきれない（また、しなくてもよい）場合は、次回のプランニングに持ち込む。
最近は、出したストーリーはすぐにチームで見積っている。見積もりは1〜2分もあればでき、特に遅らせる理由もないからだ。
週次のふりかえり
週の終わりには、チームでふりかえりを行う。
ふりかえりは、ふりかえりだ。どうすれば、チームとしてよりよくなれるか？ ということをみんなで話し合う。
特筆できることはあまりないようにも思える。
それでも最近思うのは、「チームとしてよりよくなる」という言葉には広く深い意味があるということだ。
今思えば、ずっと前、はじめてふりかえりに取り組んでいた頃は、「どうすればベロシティが上がるか？*3」だったり「チームの雰囲気をよくするには？」といった、狭く、かつ浅いフォーカスを持っていたなと思う。
ここはまだうまく言語化できないんだけど、ふりかえりには無限の可能性があるんだよな、ということを改めて考えている。
またいつか、がんばって言語化してみたい。
リリース
新機能（※既存機能の置き換えを含む）の場合、ある程度のかたまり（いわゆるMVP）で公開する。その単位を1〜3ヶ月のリリースバーンダウンチャートとして計画しているので、バーンダウンが落ち切ったときが公開のときということになる。
公開自体は、ある意味、特になんでもない日常だ。
フィーチャーフラグを使って常に本番環境にデプロイし続けており、最後にフィーチャーフラグを外すだけだからだ。
フィーチャーフラグのついた機能は特定のユーザには公開できるので、関係者には早期から公開しておき、常にフィードバックを得られる状態にしておく。
既存機能の改善の場合は、特に「リリース日」を待つ必要はない。でき次第デプロイし、即時に公開していく。週に数件は新しい機能が公開されていくイメージだ。
ちょっとした機能エリアを増やす場合、ある程度育ててから公開したい場合もある。その場合はエリアをフィーチャーフラグで隠しておき、満足のいくラインまで育ったら公開する。
それから
エンドユーザを含む、周囲からのフィードバックは常に得る。公開前から。公開してからも。
得られたフィードバックには優先順位をつけて、取り組みの優先順位を考える。ここでは特にプロダクトマネージャーが活躍する。
チームが解散しない限りは、一つのバーンダウンが終わる前には、次のことを考え始める。だいたい終わる2週間前くらいには動き始める必要がある。（もちろん、もっと前から少しずつ考えてはいる）
終わる一週間前にはストーリーを出し、見積もっておく。
次のサイクルの初めには、集まる時間を長く取っておき、新しいバーンダウンを引く。
こうして、価値を探究し続ける。
