完全なアジャイル・デリバリー・ライフサイクル

ディシプリンド・アジャイル(DA)プロセスディシジョンフレームワークの重要な側面の一つは、初期段階から最終段階までの完全なソリューションデリバリーライフサイクルにある。以下に掲げる図は、DAデリバリーライフサイクルのハイレベルな概要だ。3つのフェーズから成り、その期間に渡って利用可能なソリューション(ComsumableSolution)をインクリメンタルにビルドする。このハイレベルな観点から始めることで、詳細に入る前に、幾つかの重要なコンセプトを探っていくことにしよう。

high level Overview

最初に、DAライフサイクルは、3つのフェーズを明確に提示している:

  1. 方向付け   このフェーズでは、プロジェクトの立ち上げに必要な活動が行われる。”フェーズ”という言葉はアジャイルコミュニティの中では嫌われている言葉(swear word)だが、現実にはほぼ全てのチームでプロジェクトの初めの段階で先行するなんらかの作業が行われている。人によってはこの労力をスプリント(あるいはイテレーション)0と、やや誤解しているが、よく見られるのは1イテレーションよりも多くの時間を割いていることだ(2013Agile Project Initiation surveyでは、平均的なチームは方向付けに1カ月程度割いており、その一方で典型的なイテレーション/スプリント期間は2週間だった)。それ故、DADの方向付けフェーズは、ビジョンを明確にするための負担の非常に軽い活動を提唱しており、プロジェクトを適切に立てつけることができる。これが、「方向付けフェーズは短時間で」というディシプリンだ。
  2. 構築  このフェーズでは、デリバリーチームは潜在的に利用可能なソリューションをインクリメンタルに
    構築する。複数のイテレーション(スクラム世界のスプリント)を1セットとして実装することもあるし、リーンのような継続フローアプローチ(ライフサイクルのバリエーションについては後述する)こともあるだろう。チームは、ソリューションをデリバリーチームするために、スクラムやXP、アジャイルモデリングやアジャイルデータ、その他様々なメソッドからのプラクティスを組み合わせたハイブリッドアプローチを採用する。
  3. 移行  DAプロセスは、洗練されたエンタープライズアジャイルプロジェクトにとって、利害関係者にソリューションをデリバリーことは、取るに足らないつまらない作業からはしばしば程遠いものになるとみなしている。デリバリーチームチームは、そしてエンタープライズ全般でも同様だが、デプロイメントプロセスを合理化しこのフェーズの時間を出来るだけ短くしようと試みるし、理想的には継続的デリバリーアプローチからこのフェーズが消えることが望ましい。これが、「フェーズから活動へ、移行を進化させる」というディシプリンだ。
 そう、読者がこの後見ていく図(システムライフサイクルを図示したものだが)にも見られるように、アジャイルSDLCには3つのフェーズだけに留まらない。第1に、ポートフォリオ管理にはプロジェクトに先行して作業する局面がある。そこでは、潜在しているプロジェクトやプロダクトが顕在化され、優先順位付けされ、方向付けフェーズの作業を開始するために十分な予算が採られる。さらに、チームをガイドするビジネス面とテクニカル面でのロードマップが開示されるかもしれない。移行フェーズの後では、本番の環境でソリューションが運用されサポートされる(商用製品であれば市場に供される)。結果的に、何十年か使われた後、ソリューションはリタイアされる(運用から外れる)。もしITの視点からこれらを見れば、エンタープライズレベルでプロダクト/プロジェクト横断的な関心事(例えば、エンタープライズアーキテクチャーやポートフォリオ管理、再利用エンジニアリングなど)があるし、DADフレームワークが現在サポートする以上のものがあるのだ。

high level Overview

 DAフレームワークは単一のライフサイクルをあらかじめ規定していない。これはスクラムのような他のメソッドとは異なる点だ。DAD本ではライフサイクルの2つのバージョン(基本/アジャイルとアドバンスド/リーンバージョン)にフォーカスを合わせたが、実は最初のバージョンが世に出て時に継続的デリバリーと探索的(リーンスタートアップ)ライフサイクルも記述していた。ポイントは、各々のチームは独自の状況にあり、DADフレームワークが有用なものであるためには、ライフサイクルの数種のバージョンを十分サポート出来るよう柔軟でなければならないということだ。
  では、それら4つのライフサイクルを順に見ていこう()

アジャイル/基本ライフサイクル:スクラムの拡張

下の図は、筆者達がアジャイル/基本DADライフサイクルと呼ぶものの詳細を記したモノだ。これはスクラムの構築ライフサイクルを拡張している。このライフサイクルの詳細に加えて、いくつか興味深い側面がある:

  1. イテレーションベースである。スクラムやXPを含む多くのアジャイルメソッドのように、ソリューションはタイムボックスを使ってインクリメンタルに構築される。これらのタイムボックスはイテレーションと呼ばれる(スクラムでスプリントと呼んでいるモノと同じだ)。
  2. スクラム用語は使わない。 ライフサイクルはスクラムをベースとしているが、筆者達はDAではブランド化された用語は使わないという選択をしている。この図の場合を例に取ると、スプリントの代わりにイテレーションを使っている。用語は実際には問題ではないので、読者がスクラム用語になれているのであれば、代わりにそれらを使って構わない。
  3. デリバリーライフサイクルの範囲外からのインプットを示している。前述の概要図ではデリバリーライフサイクルのみ示していたが、下の詳細図では、プロジェクトの方向付けより前になんらかの活動が行われ、しばしば運用後に新しい要求が(変更リクエストや不具合レポートという形で)アジャイルチームに投げられることが示されている。これらのインプットはデリバリーライフサイクル全体にかかわる重要なコンテキストを提供する。
  4. プロダクトバックログではなく、ワークアイテムリスト。 DAはスクラムよりもスコープが広く、読者がこのスコープを取り扱う場合には、スクラムのプロダクトバックログよりも、よりしっかりした変更管理アプローチが必要となることを初めに理解すべきだ。ワークアイテムは、要件、不具合、その他の非機能な側面(トレーニングや休み、他のチームのアシスト等)を含んでいる。これらの作業はすべて優先順位付けされる必要がある。要求を実装するだけではないのだ。この詳細については、Agile Best Practices: Prioritized Requirements(未訳)を参照いただきたい。
  5. 明確なマイルストーンを含む。 ライフサイクル図の底辺に沿って、ライトなマイルストーンが提示されているのが見えるが、デリバリーチームはこのマイルストーンに沿うように奮闘すべきだ。このようなマイルストーンはアジャイルガバナンス(※未訳)の重要な側面だ。

 

3 - DAD Lifecycle agile scrum筆者達はこれを基本/アジャイルライフサイクルと呼ぶが、これは読者が着手するのに適した開始点となりそうだからだ。このバージョンのライフサイクルを適用する共通のシナリオはスクラムを読者のニーズを満たすよう拡張するか、あるいはRUPからディシプリンドアジャイルアプローチに移行するというものだ。

アドバンスド/リーンライフサイクル

下の図はアドバンスド/リーンライフサイクルと呼んでいるモノだ。このライフサイクルの特徴を挙げてみよう:
  1. 継続的なデリバリーフローをサポートしている。このライフサイクルでは、ソリューションは頻繁に、そして理にかなっているならいつでもデプロイされる。作業はそれに対応する余裕がある場合にチームにプルされ、イテレーションのような定期的なリズムに乗るわけではない。
  2. プラクティスは自身のケーデンスを則る。イテレーション/スプリントを使った開発では、多くのプラクティス(詳細な計画策定、ふりかえり、デモ、詳細なモデリング等々)は同じケーデンス、つまりイテレーションに効果的に配置される。リーンアプローチで見られるのは、何かをやる意味があるときにやり、読者がスケジュールした通りカレンダーが指し示す時にやるわけではないということだ。
  3. ワークアイテムプールを使う。すべてのワークアイテムは同じく作られるわけではない。ある種の作業を”標準的なお作法”ースクラムが提唱する価値駆動アプローチやらDAやRUPが提唱するリスクー価値駆動アプローチやらーに従って優先順位付けするという選択をするかもしれないが、他のモノもこの戦略にフィットするかもしれない。ある作業は、特に法令から発生した作業は期限が日付でドライブされる。ある種の作業は手早く片付けられなければならないに違いない。たとえば重要度トップの、稼働中の問題を解決するといったような作業の場合だ。だからワークアイテムプールなのであり、優先順位付けされたスタックではないのだ。現実が理解の進めば、これが持つ意味もわかるだろう。

3 - DAD Lifecycle Advanced

筆者達はこれをアドバンスド/リーンライフサイクルと呼ぶ。チームが時間をかけて進化しているのを見ている。彼らは前述した基本ライフサイクルで始めることが多いが、学ぶにつれ、自分達の作業を改善するにつれ、ライフサイクルはよりリーン度合いを増していく。

継続的デリバリーDADライフサイクル

下の図は、継続的デリバリーDAライフサイクルだ。基本的には、ひとつ前に説明したライフサイクルのさらにリーン化の進んだバージョンで、プロダクトが運用環境や市場へ定期的に出荷される。これは毎日の場合もあれば、週次だったり月次だったりがよく見られる。

3 - DAD Lifecycle Continuous Delivery

探索的(リーンスタートアップ)ライフサイクル

次の図は、DA探索的ライフサイクルだ。このライフサイクルは、利害関係者が新しいプロダクトのアイディアがありながら、ユーザにとってなにが必要とされているのかを自分達がまだ理解できていない状況にあると理解したスタートアップや研究段階のアジャイルやリーンチームによって採用される。結果として彼らは市場が何を求めているのかを、一連の学習体験を通してクイックに探る必要がある。このライフサイクルは他のDAライフサイクルにおける方向付けフェーズを置き換えとなり、ビジョンを検証しライフサイクル期間中を通して継続して実践され続ける。

3 - DAD Lifecycle Exploratory

では、探索的ライフサイクルがどのように機能するか見ていこう。6つのアクティビティがある:

  1. ビジョン化  チームはアイディアを探索し、アイディアを実装するための可能な戦略を特定する。これは、2,3人がひとつの部屋で、ビジネス面と技術的オプションについて ホワイトボードと紙を使ってモデルストーミングするくらいの簡単なモノで済むかもしれない。読者は、顧客が実際に欲するモノが何かに対する実現可能な仮説を見出すためのに十分な検討時間が必要だ。この仮説は、検証が可能である必要がある。ここで、検証可能が意味するのは、読者は作り出した新しい機能性がどれくらい効果的であったかを計測する方法を特定する必要があるということだ。
  2. 少しだけ構築する  仮説を検証するソリューションをビルドするのに十分なだけの労力を割くことに投資すべきだ。リーンの語法で言えば、読者は最小限の実行可能なプロダクト(MVP)として知られているビルドだ。労力の総量は異なる。数日から数週間にわたることもあるーあなたのゴールはなにか使えるモノをとても早く作って仮説を検証できるようになることだ。
  3. デプロイ  現在のソリューションが準備出来たら、仮説を検証できる環境にデプロイされる。このデプロイメントは様々なやり方(多くは”アルファ”や”ベータ”リリースとか呼ばれる)で顧客のサブセットに対して行われる。それにより、ソリューションが顧客の関心を惹くかを決定することが出来る。
  4. 観察と計測:
    ソリューションが運用に供されると、あなたはそのソリューションのどんな面が、それがあるとして、あなたのユーザー・ベースの興味を惹いているのか決定したくなる深い
    これを実現するには、内部で起きた重要なイベントに関するログデータを取得出来るようにあなたはソリューションにコードを挿入する必要があるだろう。
    たとえば、いつ特定の画面/ページがアクセスされるか、いつ販売されるか、特定の業務処理が進行中であるか等々。
    この考えはエンドユーザーがどの機能が役に立つと思っているか、どの機能が顧客保持に繋がるか、どの機能がより大きな売上高をもたらすか・・・ あなたにとって重要であるものは何でも理解したいということだ。
    データを生成することで、あなたは新しい機能がユーザベースからどれくらい有効と受け取られているか、モニターし、観察と計測することができる。転じて事実に基づいて先に進めるか否かの判断を下すことが出来る。もしその機能の評判が良ければ、今の戦略を続けたままで、なにか機能をさらに追加するという選択も出来る。あるいは、あなたの戦略はとてもうまくいったので、ソリューションを商用製品化する準備をしようと判断することができる。もし機能が受け入れられなかったら、貴方のチームは原点に立ち返って、別の方向性に則るか、完全に止めてしますという途を選択することもあり得る。
  5. キャンセル. プロダクトのアイディアが結局動かないことがわかる時がある。事実、スタートアップと同様に研究開発(R&D)で特によく見られる。これのよいところは、アイディアが失敗に向かっている場合に、それが失敗であると学習することで別の戦略にエネルギーを振り向けることができるということだ。
  6. プロダクト化:少しづつ実装しデプロイするイテレーションを複数回繰り返し、観察して計測するという過程を経て、プロダクトは市場で成功を収めるだろう(社内システムの場合には、ユーザベースで成功を収める)。上に述べたように、あなたはこのライフサイクルを使い続けるという選択もできるが、よくあるのは他のDAサイクルを適用すると決定することだー例えば、スクラムベースのアジャイルライフサイクル、カンバンベースのリーンライフサイクル、あるいは継続的デリバリーライフサイクルといったものだ。このライフサイクルを方向付けフェーズとして扱って時間を効果的に使っている。

さらに詳細な議論は、The Exploratory “Lean Startup” Lifecycle(※未訳)を参照いただきたい。

なぜ複数のライフサイクルをサポートするか?

Q)なぜ複数のライフサイクルをサポートするのか?
いい質問だ。第1に、明らかに一つのライフサイクルはすべてに適合するわけではない。チームは、自身の置かれた環境がユニークであることを知っている:チームメンバーは、一人一人がスキルと仕事のパフォーマンスが異なる代えがたい個であり、様々なスケーリング/テーラーリングファクター、たとえばチームサイズや地理的な分散、ドメインの複雑さ、組織の文化といったものは、チームに依って異なる。チームは自身の置かれた環境が様々な可変要因を有していることを知っているので、DAのようなフレームワークは、複数のライフサイクルをサポートすべきではないだろか?さらに言えば、様々なアジャイルのフォーラム、ユーザグループ、カンファレンス、そして組織内でひろく議論されていることから、現実はアジャイルチームは異なるタイプのライフサイクルに則っていることは明らかだ。
2番目に、筆者達は、事前に規定された単一のライフサイクルという考え方には、居心地の悪さを感じる。DAフレームワークの記述を始めるときに、筆者達はあらかじめ規定するということを避けたかった。スクラムコミュニティの中ではあらかじめ規定することの悪についてのレトリックがあるが、実際にはスクラムは明らかに”事前に規定されたもの”だ。筆者たちは、スクラムを「箱から出してそのまますぐに適用」できないような環境で、スクラム法の条文に従おうとしてトラブルになっているチームを数多く見てきた。
3番目は、筆者達はプロセス改善というものを固く信じている。もし読者が、学習しながら自身のプロセスを実際に改善しているなら、ライフサイクルが時を経て進化していくのは現実味がないのだろうか?もちろん、そんなことはない。現実味がある。最初は基本/アジャイルライフサイクルに近い形で開発を始めたチームが、時を経てアドバンスド/リーンや継続的デリバリーライフサイクルへと進化していくのを、筆者達は見てきている。

複数のライフサイクルをサポートすることのデメリット

複数のライフサイクルを明確にサポートすることには、明らかな欠点がある。そうすることによって、DAチームが自身の状況にもっとも合うプロセスのテーラーリングと、繰り返し可能なプロセスの記法にいまだにしがみついている組織においては真逆のものになりうるコンセプトに従うことを筆者達ははっきり認めている(ちなみにDAは”繰り返し可能なプロセスよりも繰り返し得られる結果”(※未訳)を推進している)。また、企業内の専門家―例えばエンタープライズアーキテクトやデータ管理グループ―はこれら複数のデリバリーライフサイクルに対応できるだけの十分な柔軟性が求められる。そのようなエンタープライズでのプロセスを次善のものにする(例えば、全プロジェクトチームが単一のデータ管理戦略に合わせるよう強制するといったような)代わりに、サポート対象のデリバリーチームに最適な方法でサポートするだけの十分なスキルと柔軟性をもった、エンタープライズチーム(※訳注:全社横断チーム、みたいな感じ)を立ち上げたいと思うだろう。最終的には成果物ベースではなく結果ベースのガバナンスが必要とされるのは明らかだ。よいニュースは、DAはフレームワークに”効果的なガバナンス”(※未訳)を組み入れていることだ<

関連する投稿(※訳注:これぜんぶ翻訳するのは、無理orz)
  1. Pingback: An Exploratory “Lean Startup” Lifecycle | Disciplined Agile Delivery
  2. Pingback: Evolving the Goals Overview Diagram | Disciplined Agile Delivery
  3. Pingback: A Full Agile Delivery Lifecycle | Disciplined Agile Delivery
  4. Pingback: Comparing DAD to the Rational Unified Process (RUP) – Part 2 | Disciplined Agile Delivery
  5. Pingback: Just a delivery lifecycle? | Disciplined Agile Delivery
  6. Pingback: Adopting a Full Lifecycle Requires Discipline | Disciplined Agile Delivery
  7. Pingback: Managing Requirements Dependencies Between Agile Teams | Disciplined Agile Delivery
  8. Pingback: Disciplined Agile Lifecycle Posters | Disciplined Agile Delivery
  9. Pingback: What is Disciplined Agile | Reedy Feggins Jr.
  10. Pingback: Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams | Disciplined Agile Delivery
  11. Pingback: JIT – Just in time and Software Development | Agile Design = Adaptive Design
  12. Pingback: The Missing Pieces Of The System! | Seeding The Landscape….Agility For Agile Minds
  13. Pingback: Two dimensions: Just in time and Envisioning | Agile Design = Adaptive Design
  14. Pingback: Does your team own its process or merely rent it? | Disciplined Agile Delivery
  http://www.disciplinedagiledelivery.com/lifecycle/
 
(翻訳 藤井智弘)
Pocket