はじめに

工程以外の基準でスケジュールを考えることになるよ。という話。
タイトルは大日程って言って書いてるけど、まぁ優先順位の考え方の話だよ。
「アジャイルは計画立てない」みたいな話もあるけど、それでうまくいくと思える状況ならそうすればいいし、うまくいかないと思うなら多分うまくいかんよ。
受託アジャイルの現場は、ウォーターフォールPJと足並み揃える場面などもあり、そこに向けた準備等も考えると、ある程度中長期的なスケジュールイメージはあった方が良いと思ってるよ。

先人の知恵

大日程の考え方以外にも色々書いてあるけど、ボリュームが多いので、今回は大日程の話だけ。

実感としてのウォーターフォールとの違い

工程はスケジュールの前提にならない

ウォーターフォールの案件を考えると、基本的には設計→製造→テスト→移行といった流れで考えることが多いのですが、アジャイルだとその必要性がなくなります。
そもそも１スプリントで設計〜リリースまでやることを目指すのであれば、工程云々はどうとでもなります。（実際はどうともならん部分はあるが）

何を目的にアジャイルを選択したのかが重要

要件の不確実性

ニーズが不明、結果として要件が不明、市場にリリースしないとニーズすら測れない。
そういったものであれば、MVPの整理などから入っていくことでしょう。
多くのアジャイルがこのタイプだと思っています。
先人の知恵にあげた記事もこの前提で記載されています。

「市場で何を優先的に検証していくのか？」というビジネス上の優先順位判断がポイントになります。
何かしらのマイルストーンなどもあるでしょう。このキャンペーンは来年の夏に間に合わせたい！とか。

実現方法の不確実性

要件はある程度明確だが、どのようにそれを実現していいかわからないケース。
なかなかニッチなケースだとは思いますが、今の現場がまさにそうなので、意外とあるもんだな、という印象。

（今の案件ではないですが）オンプレ基盤が保守できなくなったので、クラウドに移行したい。といったときに、クラウド都合に合わせてアプリを作り替えるケースなどはあります。
クラウドサービスなどは実装してみないと細かい挙動が不透明な部分が多く、ウォーターフォールの場合PoCなどで事前に潰し込むことも多いと思います。

この場合は技術的リスクを先に潰し込むことを求められます。
見通し精度をどんどんあげていくためにはリスクが高い部分を先に食わないと、ずっと見通しは不透明なままです。

後回しにされがちだけど優先すべきだと個人的に思ってること

「移行・リリース」あたりは特に優先するべきだと思ってる。
受託アジャイルとかだと、リリースタイミングが固定化されていて、後回しになるケースもあると思う。

でも、移行・リリースこそが一番魔物が潜むタイミングなのはみんな実感してるはずなので、とにかく空っぽでもいいからリリースした方が良いと思ってる。
外部公開はしなくてもよい。ただ定期的にリリースできる仕組みは整えておくのが良い。

DevOps界隈でもよく言われる話。
ここら辺はもう少し深掘りして書きたいので別の記事として書きます。

とはいえ、本質的なところはウォーターフォールと変わらない

うだうだ書いたけど、結局は

PJとして目指していることを明確にする
「提供すべき価値」「リスク」を洗い出す
「ビジネス観点でのイベント」「各種マイルストーン」を整理して中期的なターゲットを明確にする
「工程」にこだわりすぎずに線を引く

という話。最後だけが特徴的なだけで、本質的な考え方はそう大きく変わらないはず。

受託アジャイルでの実際

これが全てではないと思いますし、あくまで一例としてみてください。

大きな分類

「開発スプリント」「リリーススプリント」の二種類がメジャーですけど、場合によってはもう少し細かくしてもいいと思います。
結合テストやシステムテストをどちらに含めるかはPJによって決めればいいと思いますが、結合テストは開発スプリントに、システムテストはリリーススプリントに入れてます。
ただ、結合テストやシステムテストが意味するところもPJによって違う気がするので、この例にいかほどの意味があるかはよくわからん。

ウォーターフォール案件と足並みを揃える

アジャイル開発側だけの都合だけでスケジュールは組めないことが多いです。
足並みを揃えることがある程度求められてきます。
外部接続テストなどのタイミングなどは考慮する必要が出てくるでしょう。

そういう意味で、ある程度ウォーターフォールライクなスケジュール表の作成は必要にかられる場面はあるかと思っています。

まとめ

スケジュールの考え方の基本はウォーターフォールと本質的なところは変わらない
「工程」という制約は少し緩くなるので、自由度が増す。（その分納得するのが難しくなる）

あくまでもサンプルとして

ちょっと実例持ってくるの微妙な予感したので、だいたいのイメージで。

「要件定義〜システム内結合テスト」をサイクリックに回す「開発スプリント」の単独線をしばらく走らせる。チームの成長やスケールも合わせて考える。
「システム外結合テスト・システムテスト」などの「リリーススプリント」は、移行のタイミングや審査の内容に合わせて考える。（必要に応じて都度やる）
ウォーターフォールPJと足並み揃えるようなマイルストーンがあるなら、そこに向けての整理も必要。

この記事薄いかなぁ・・・
でもこれ以上具体的に書こうとすると結構PJの個別事情を話さないと意味わからんくなるのと、その場合の塩梅がちょっと見つかんないので、許して・・・

次回予告

次回は「スクラムマスターとしてファシリテーションするときに注意していること」を書きます。