この記事は、適応型ソフトウェア開発 アドベントカレンダー 2024 の 4日目です。
スクラムとの違い
適応型ソフトウェア開発とスクラムの明確な違いは何か。
それは、完了の定義にあると考えている。
スクラムの場合
チームで定めた完了の定義や成果物のリリースをもって、完了とするケースが多いと思う。
実際に、そのタスクをリリースするまでに必要な相対見積もりをとり、ストーリーポイントという見かけの数字を用いて、見通しを測っていく。
このリリーススパンをどれだけ集中して早く進められるのかを突き詰めるのがスクラムフレームワークの良いところだと個人的には考えている。
適応型ソフトウェア開発の場合
適応型ソフトウェア開発の場合、まず創るものがわからないところからスタートする。
そのため、明確な完了の定義や成果物のリリースまで到底届かないところから始めることが前提になっている。
その結果、重視するのは完了の見通しではなく、「状態」変化までの見通しだ。
状態変化までの見通し
この「状態」という概念が適応型ソフトウェア開発では最も重要なものになる。
「状態」は３つの言葉で示される。
それは、学習・思案・協調の３点だ。
学習・思案・協調
この３つそれぞれの「状態に至る」ことをタスク完了の定義とすると、イテレーションが回り始める。
この時、状態変化する際には何かしらのアウトプットが発生することを期待していることが多く、
そのアウトプットを出すまでにかかる見通しをチームに開示しながら進めていく。
この状態変化にかかるスパンをどれだけ早く回していけるのかを突き詰めるのが、適応型ソフトウェア開発の神髄なのかもしれない。
スクラムと適応型ソフトウェア開発で違うことは少ない
計画を立て、見通しを大切にし、案件を高速で振り返りながら進むというプロセスには、違いはない。
明確に違うのは、タスクに対する切り口の違いでしかない。
この切り口の違いを正しく認識し、適切に行使できるかできないかがアジャイル開発におけるフレームワークの選定基準の１つなのかもしれない。