この記事は、適応型ソフトウェア開発 アドベントカレンダー 2024 の 10日目です。
タイムボックスについて
スクラムフレームワークにおけるスプリント期間の話である。
適応型ソフトウェア開発ではどのように期間を設定するのだろうか。
という話だ。
イテレーション
イテレーションについては、こちらの記事で記載しているが、大きく異なっているのは開発の進捗指針が「状態」という概念であることだ。
「状態」に向き合う
「状態」を最新化し続けることが、適応型ソフトウェア開発で重要なポイントである。
しかし、「状態変化」に追従し、観測を続けることはなかなか難しい。
その難しさがどこにあったのかというと、時間軸の違いである。
時間軸の違い
「状態」が変化するタイミングは、文脈の大小や環境変化、関わるものの多さによって変化する。
そのため、スクラムのように定点的なタイムボックスを置いた観測だけでは開発指標である「状態」の追従・最新化が追いつかない。または顕在化しない状態が続いてしまうことだ。
チームで取り組んだ際に有効だった時間設定
今まで登場した「目標」・「カオス」・「タスク」はそれぞれ状態を持っている。
しかし上述した通り、状態変化を観測できる時間軸は異なっている。
タスク
これが最も状態変化を観測するまでのスパンは短かった。
早ければ、半日。遅くても3日で状態変化を観測できるものだ。
カオス
これはなかなか手強い。
そもそもわからないものの状態を変えようというのだから、それはそうなのだ。
しかし、カオスの淵をなぞっていくうちに状態が変化することも多かった。
これは１週間か２週間で状態が変わってくることが多かった。
目標
これが最も動かない。
おおよそプロジェクトのフェーズと言い換えても良いものだから、マンスリー単位で変化が観測できるものかもしれない。
有効な時間軸
上述した通り、有効な時間軸はday, week, month の3つの観点での状態観測を行うことで、
最新状態を維持し、適応型ソフトウェア開発を継続できることを知った。
チームでの取り組み
私たちは、このday, week, month の観点でそれぞれイテレーションを回す三重ループを行うことにした。
その結果、毎日状態がわかり、週単位でどれだけの状態が進んだかを整理し、月が変わった時にどれだけの進捗があったのかを知ることができるようになった。