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

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

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

  1. 方向付け   このフェーズでは、プロジェクトの立ち上げに必要な活動が行われる。”フェーズ”という言葉はアジャイルコミュニティの中では嫌われている言葉(swear word)だが、現実にはほぼ全てのチームでプロジェクトの初めの段階で先行するなんらかの作業が行われている。人によってはこの労力をスプリント(あるいはイテレーション)0と、やや誤解しているが、よく見られるのは1イテレーションよりも多くの時間を割いていることだ(2013Agile Project Initiation surveyでは、平均的なチームは方向付けに1カ月程度割いており、その一方で典型的なイテレーション/スプリント期間は2週間だった)。それ故、DADの方向付けフェーズは、ビジョンを明確にするための負担の非常に軽い活動を提唱しており、プロジェクトを適切に立てつけることができる。これが、「方向付けフェーズは短時間で」というディシプリンだ。
  2. 構築  このフェーズでは、デリバリーチームは潜在的に利用可能なソリューションをインクリメンタルに
    構築する。複数のイテレーション(スクラム世界
    スプリント)を1セットとして実装することもあるし、リーンのような継続フローアプローチ(ライフサイクルのバリエーションについては後述する)こともあるだろう。チームは、ソリューションをデリバリーチームするために、スクラムやxp、アジャイルモデリングやアジャイルデータ、その他様々なメソッドからのプラクティスを組み合わせたハイブリッドアプローチを採用する。
  3. 移行  DAプロセスは、洗練されたエンタープライズアジャイルプロジェクトにとって、利害関係者にソリューションをデリバリーことは、取るに足らないつまらない作業からはしばしば程遠いものになるとみなしている。デリバリーチームチームは、そしてエンタープライズ全般でも同様だが、デプロイメントプロセスを合理化しこのフェーズの時間を出来るだけ短くしようと試みるし、理想的には継続的デリバリーアプローチからこのフェーズが消えることが望ましい。これが、「フェーズから活動へ、移行を進化させる」というディシプリンだ。

 

 そう、読者がこの後見ていく図(システムライフサイクルを図示したものだが)にも見られるように、アジャイルSDLCには3つのフェーズだけに留まらない。第1に、ポートフォリオ管理にはプロジェクトに先行して作業する局面がある。そこでは、潜在しているプロジェクトやプロダクトが顕在化され、優先順位付けされ、方向付けフェーズの作業を開始するために十分な予算が採られる。さらに、チームをガイドするビジネス面とテクニカル面でのロードマップが開示されるかもしれない。移行フェーズの後では、本番の環境でソリューションが運用されサポートされる(商用製品であれば市場に供される)。結果的に、何十年か使われた後、ソリューションはリタイアされる(運用から外れる)。もしITの視点からこれらを見れば、エンタープライズレベルでプロダクト/プロジェクト横断的な関心事(例えば、エンタープライズアーキテクチャーやポートフォリオ管理、再利用エンジニアリングなど)があるし、DADフレームワークが現在サポートする以上のものがあるのだ。

3 - DAD lifecycle high level

 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

DADでよくある質問

最近はエンタープライズアジャイルの勉強会なるものも立ち上がってきたり、説明の機会をいただくことも多くなってきましたが、そこで「DADはこれまでとなにが違うの?」という質問を受けることが多く・・・でも、それは洋の東西を問わずいずこも同じのようで・・・

DADのUSサイトのほうにFAQがポストされたので、その翻訳をここに挙げておきます。
「みんな同じようなところがわからないのね」と、ある意味安心することでせう。また文化的に”比較広告”に慣れていない私達には、SAFeとの比較のあたりは「おいおい・・・」という感じもw                       (by Tomohiro Fujii)

—ここから翻訳—-

//original :  FAQ( http://www.disciplinedagiledelivery.com/faq/ )

ここでは、DADに対してよく受ける質問を取り上げていこう。これ以外にも新しい質問があれば大歓迎だ。

次のような構成で質問を採り上げていこう。
・DADライフサイクル
・DADと他のメソッド
・DADとスケーリング
・一般的な質問

DADライフサイクル

Q)DADは、ウォーター・スクラム・フォールの一例ですか?
 いいえ。ウォータースクラムフォール(WSF)は、Dave West氏(彼は、DAD本の推薦も書いてくれた紳士で、Foresterのアナリストだ)が定義した言だ。WSFや不幸なプラクティスだープロジェクトの早い段階でかなりの工数をかけてモデリングと計画づくりを行い、構築期間中はスクラムのアプローチを採る。その後には、多大な工数をかけて長時間に渡るデプロイプロセスが続く。WSFは、まだ完全にアジャイルに移行しきっていない組織に典型的に見られる病状であり、スクラムのライフサイクルを構築期間中に絞って適用してしまう(プロジェクトをどう始めどう終えるかはあなたにお任せのままにしておく)ことで、病状をさらに悪化させているように見える。DADは後述するように、デリバリーライフサイクル全体を提唱しているースクラムベースであり、アジャイルであり、継続的デリバリーやその他諸々ー。つまり、あなたの状況に合わせて適切な枠組みを作ることができる。
Q)なぜ、フェーズが3つなのか?
 DADはデリバリーライフサイクル全体を提唱しており、結果として3つのフェーズを明示的に定義している:方向付けはプロジェクトの立ち上げ、構築はソリューションの構築と構成、そして移行はソリューションを本番環境や市場へデプロイする。筆者達は、”楽しい”構築部分のみを取り扱う代わりに、デリバリーライフサイクル全体を扱うということを明確に位置付けているが、これは経験的に観察された事実から導き出されたモノだ。その事実とは、ほとんどのアジャイルチームが実際にはプロジェクト開始初期に先行してなんらかの作業をする必要があり、それに続けて構築作業に多くの時間を費やし、デプロイにあたって幾ばくかの作業を行うということだ。また多くのチームがライフサイクルのすべてにアジャイルであることに苦闘しておりー前述したWater-Scrum-Fallを参照いただきたいー、唯一責任を持てるのはデリバリーライフサイクル全体にアドバイスすることだけだと感じているところを目にした。この点についての詳細は、別ポストWhy are there Phases(※翻訳中)を参照いただきたい。
Q)推敲フェーズに何が起きたか?
 DADにおける3つのフェーズの名称ー方向付け、構築、移行ーは統一プロセス(UP)から来ている。筆者達は、安直に3つのフェーズを立ち上げ、構築、デプロイと呼ぶことも出来たかもしれない。あるいは開始、実行、リリースとも。または、スプリント・ゼロ、作成、出荷。または・・・。筆者達はなにか決めなければならなかったし、UPのフェーズ名が一番適切だった。
 しかし、UPに詳しい人達は、筆者達が4フェーズではなく3フェーズにしたことに注目した。DADには推敲フェーズがないのだ。筆者達は2つの理由から、推敲フェーズを外した。まず第1に、UPの4フェーズを採用したが、伝統的な要件−アーキテクチャープログラムーテストフェーズと誤って適用した多くの組織を見てきた。DADを適用する際に、いとも簡単に同じような過ちが引き起こされるのを避けたかった。2番目の理由として、推敲フェーズの成果である”実証されたアーキテクチャ”マイルストーンは、ハイリスクな要件を早期に実装しエンド−トゥーエンドで機能するシステムのスケルトンを構築することによって、プロジェクトの技術的リスクを早期に減少させることができた。が同時にフェーズをひとつ設けることに伴う官僚主義的な諸事にも対処しなければならなかったからだ。
 Q)移行フェーズからのフィードバックループはあるのか?
 ある。ハイレベルのライフサイクル図では示しているが、各論での詳細な図には示していない。この質問はよくいただくので、これらの図はアップデートされる可能性がある。

DADと他のメソッド

Q)DADとスクラムとの比較
 スクラムと異なる点として以下を挙げておこう:
  1. カバーするライフサイクルの幅が広い:DADはライフサイクル全体(※full delivery lifecycleは翻訳中)をフルにサポートする。つまり、スクラムでの構築ライフサイクルに留まらずに、アジャイルプロジェクトの立ち上げをどう効果的に進めるか、本番環境にどのように移行/リリースしていくかまでカバーする。言い換えると、実際に現場でアジャイル開発に携わるスタッフがどう振る舞っているかという疑問を払拭する助けとなっている。
  2. エンタープライズ対応にフォーカスしている:スクラムの強みはプロジェクトチームにおける振る舞いという内向きにフォーカスを合わせることで、集中を妨げる要因を最小化し、チームが利害関係者とコミットしたモノをデリバリーすることにフォーカスすることを可能にしている。様々な概念ープロダクト・オーナーという役割、同じ場所、ホールチーム(whole team)、デイリースクラム等ーによって、目的が達成される。しかし、この内向きなフォーカスと自立は、エンタープライズとして考慮しなければならない諸処ー基本となるガバナンスやアセットやパターン、テンプレートやガイドラインの再利用ーを無視して、チームがサイロ的な振る舞いをするよう進みがちだ。アーキテクチャとシステムとが、メンテナンスしづらい相容れないモノへとなっていくのが関の山だ。DADは、チームに対しエンタープライズの事情を意識するよう働きかけるし、アーキテクチャ・オーナーという役割を組み込むことを推奨し、エンタープライズでの良いプラクティスを無視せず必要に応じてプロジェクトとエンタープライズレベルの権威(訳補足:エンタープライズ・アーキテクトなど)とのコラボレーションを強く推奨している。
  3. より広範囲のプラクティス:DADは様々なソースースクラム、XP、アジャイル・モデリング、カンバン、アウトサイド・イン・デベロップメント(OID)、その他多くの手法ーから戦略を取り入れたハイブリッドなディシジョン・プロセス・フレームワークであり、それら戦略をどううまく組み合わせるかを提示している。(スクラムがやっているように)デリバリープロセス全体の中の極一部にフォーカスする代わりに、DADはより広いスコープを扱い、結果としてより堅牢で効果的なガイドをアジャイルチームに提供している。
  4. 少ない規定:DADはゴール駆動アプローチを推奨している。このアプローチでは、効果的なテーラリングやスケーリングを可能にしている。DADプロセルゴールにひとつ、”利害関係者のニーズの変化に対処する”を考えてみよう。スクラムが定めているたったひとつの方法はプロダクトバックログだが、DADはいくつかのオプション(プロダクトバックログ、ワークアイテムリスト、ワークアイテムプール、公式な変更管理プロセス)を提示している。この際、各々のストラテジーをいつ検討するかへのアドバイスも同時に提示している。また、DADはワークアイテムリストープロダクトバックログを強化したものだがーをデフォルトとしているが、これは良い開始点となる。別のゴール、”アクティビティを調整する”の場合はどうだろうか?スクラムは15分のデイリーミーティング(”デイリースクラムミーティング”や”デイリースタンドアップ”等と呼ばれる)を規定しているが、DADは適用可能な複数のオプションを提示し、読者にとって正しいアプローチをどうやって選択するのか、そのウォークスルーを示している。
  5. 少ないブランディング:DADを記述するときに筆者達が採った哲学のひとつは、アジャイルコミュニティにこれまで見られた”プロセスのブランディング”を避ける、というものだ。DADは出来た当初から用語について柔軟だった。例えば、”イテレーション”の代わりに”スプリント”を使いたければ、気にせずに使えばよい。DADは用語をブランド化していない。だから、筆者達は例えば”スクラムミーティング”ではなく”調整ミーティング”を使い、”スクラムマスター”ではなく”チームリード”を使い、”スプリントふりかえり”ではなく”ふりかえり”を使う。
 スクラムはこれからアジャイルを始めようとスタートラインに立っているチームには良いものだと考えている。しかし、スクラムを採用する組織は、これまで述べてきた類いのチャレンジに対処するためにスクラムを拡張することにかなりの労力を費やすか、あるいはDADを採用することでジャンプスタートを果たすのかのどちらかであると知ることになる。筆者達は、スクラムからよりディシプリンドアジャイルのアプローチへの移行をサポートすることができる。
Q)SAFeとの比較
 DADとSAFeは補完的な関係だ。SAFeはひとつの組織内でアジャイルをスケーリングすることにフォーカスを合わせている。一方DADは、複数からなる大きなチーム、分散した拠点、その他諸々のスケーリングファクターによって作り出される複雑さを扱うために、アジャイルをスケーリングする戦略の強固な基盤を提供することにフォーカスを合わせている。DADはSAFeにおけるプログラムレベルに容易にフィットさせることが出来る(SAFeはプログラムレベルではスクラムを提示しており、DADはスクラムを拡張しているからだ)。実際にエンタープライズ対応(enterprise awareness)とゴール駆動アプローチという明確な論点を提示しており、筆者達はこれらがDADをスクラムよりもSAFeに合わせやすくしていると考えている。面白いのは、DADとSAFeどちらも、統一プロセス(UP)をバックグラウンドに強く持っている人達から生まれていることだ。
Q) DADとラショナル統一プロセスとの比較
 DADはハイブリッドなプロセスディシジョンフレームワークであり、RUPがカバーしていた領域とその多くが重なる。DADは統一プロセス(UP)からいくつかアイディアを、特にガバナンスとリスク削減アプローチを採り入れており、同時にRUPの実装でよく見られたチャレンジの多くを避けている。不幸なことだが、RUPはあたかもウォーターフォールプロセスであるかのように誤解して実装されたことが珍しく無かったし、さもなければとても重量級のやり方として実装されたことも多かった(あるいはその両方も)。DADの立ち上げでは、(RUPの4フェーズに代わり)3フェーズライフサイクルとゴール駆動アプローチを通して前述の誤りを避ける。これらが重量級プロセスにまつわるチャレンジを解決する。より詳しい議論はDADとRUPを比較してPart1、同じくPart2(※訳注:どちらも未訳)をお読みいただきたい。筆者達はRUPからDADへ効果的に移行する手助けをすることが出来る。
Q)DADとIBMAgility@Scala戦略との比較
 DADはIBM Agility@Scala戦略から現れたもので、未だにAgility@Scale戦略の欠くことの出来ないパーツである。その上、DADフレームワークはIBMでその基礎が作られたが、現在ではディシプリンド・アジャイル・コンソーシアム(DAC)が提供している。
Q)DADとCMMIとは共に使えるか?
 筆者達はCMMIを、プロセスに対する仕様のように考えたい。CMMIは、SEIが信じる「プロセスに対するよく練られた要件のセット」であって、実装はあなた次第だということだ。だから、CMM-に準拠したプロセスは、ウォーターフォールのパラダイムにも(実際に頻繁にそうなる)、アジャイルのパラダイムにも(たまにそうなる)、その他のパラダイムにも準じる。CMMI-準拠のプロセスは重量級に始まることも(頻繁にそうなる)、軽量級で始まること(たまにそうなる)もある。あなた次第なのだ。
  その一方で、DADは、ソリューションのデリバリーw、アジャイル/リーンのお作法でどのように進めていくか、より具体的にアドバイスを提供する。またあなたが置かれているコンテキストに応じて適切なアプローチを採る助けとなるよう、より具体的なテーラーリングのアドバイスを提示している。あたなは、これを行うためにCMMI準拠のやり方をしてもよい。実際、筆者達はコンプライアンスを潜在的な助−リングファクターとして明確に位置付けており、DADをテーラリングするにあたっての意思決定を左右する要素とみている。
Q)PMI/Princeとは一緒に使えるか?
 DADのスコープはソフトウェアベースのソリューションである。だから、答はYesとなり、プロジェクト管理の一連の活動を包含する。よいニュースは、PMIやPrinceのような戦略はよりアジャイルへと移行しているということ。悪いニュースはそれがまだ道半ばであることだ。これが暗に意味するのは、組織にいるプロジェクト管理者達と一緒に仕事をするときには彼らがもっとアジャイルな仕事のやり方を理解し実践できるように、助けてあげなければならないということだ。

DAD とスケーリング

このテーマについては、Agility at scaleも併せてご参照いただきたい(※未翻訳)。
Q) DADは小規模で同一場所で作業するチーム向けか?
 イエス。事実、DADフレームワークのもっともありふれた構成がこれだ。DADのプロセスゴールで提案されている、そしてデフォルトの選択肢は事実このような構成で作業するチームをターゲットにしており、これにより読者が自身の置かれた状況とニーズに合わせて、より短期間でプロセスをテーラーリングすることを可能にしている。
Q) DADは大規模チームでも有効か?
 イエス。DADフレームワークは様々なサイズのチームに適用されつづけている。小規模なチームから数百人の人々からなる大規模プログラムのレベルまで。様々なチームサイズを扱うためにDADをどうテーラリングするかについての議論は、Large Agile Teams(※未翻訳)を参照いただきたい。
Q) DADは地理的に分散したチームでも機能するか?
 イエス。DADフレームワークは様々な分散体制に適され続けている。同じ場所で働くチームから一部かちりぢりに分散したチーム、さらに分散したチームで全体が構成されるチーム、サブチームが分散したりそれらの組み合わせ等々。このような状況でのテーラリングについての議論は、地理的に分散したアジャイルチーム(※未翻訳)を参照いただきたい。
Q)DADは、他のスケーリングを必要される状況にも対応できるか?
 イエス。チームサイズや地理的な分散にとどまらず、読者のチームが考慮すべきスケーリングファクターを複数挙げている。例を挙げると、ドメインの複雑さ、技術的な複雑さ、組織の分散度合い(アウトソーシングがその例)、コンプライアンス要件だ。これらのファクターに対してDADをどう扱うかについては、筆者達はその詳細を現在記事に起こしている。

一般的な質問

Q)なぜDADなのか?
 DADフレームワークに注意を払うべきと思う理由はいくつかある。
  • それはソフトウェアデリバリーをスケールさせる際の基礎を提供する。
  • すべての状況に対応するたった一つの戦略(例えばアジャイル/スクラム、リーン、SAFe)など存在しない。人々は成功のチャンスを最大限活かすために、様々なレベルで多くのプロセス上の意思決定を行う必要があるだろう。
  • 全員がプロセスのエキスパートというわけではない。DADは、よりよい意思決定をリードすることができる。
  • DADは実践的(Pragmatic)である。教条的(Dogmatic)ではない。
Q)他のフレームワーク/メソッドと、DADは何が違うか?
 他のオプションと異なるのは、DADが”規範的(prescriptive:あらかじめ規定されている)”フレームワークではないという点だ。DADはプロセスディシジョンフレームワークであり、ユーザの状況特有のコンテキストに対してより良い決定を下すことを助ける様々な戦略を提供している。
 筆者達はSAFeのような単一のフレームワークがスケーリングが必要とされるあらゆる状況に対してベストな解となるとは信じていない。例えば、大規模なアジャイルチームを編成する方法にはいくつかある(単一の大きなチーム、複数のフィーチャーチーム、複数のコンポーネントチーム、そしてそれらのハイブリッド)。DADは一つの戦略を規定する代わりに、与えられた状況で意味のある戦略を選択するためのガイドを提示する。同様に、読者は自身の戦略を進化させていくだろう、例えば地理的に分散したチーム体制であるとか、直面している複雑さの度合いや、チームの文化、コンプライアンス要件への対応や分散した組織でのチーム編成(アウトソースする場合がこれにあたる)、その他もろもろに応じて。kこれに関する詳細な考察については、Software Development Context Framework (SDCF)(※未翻訳)を参照いただきたい。
 DADのプロセスゴール駆動アプローチは、読者の選択をあいまいさのない明らかなものにする。その明快はガイダンスは、読者のプロセスでとりうるオプションを浮かびあがらせ、そのトレードオフを理解する助けとなる。これにより、ふりかえりでチームのムードを高める効果がある。このようなアプローチを用いることで、自身のプロセスを実際に所有するということがより簡単に実現できる。
 ゴール駆動戦略の興味深いところは、ほとんどの状況では疑わしい戦略を表に出していることだ。例えば、ライフサイクルの早い段階で詳細な要件仕様を作成するといったような。この戦略はある環境、例えばライフクリティカルな規制が存在する環境下では意味があるかもしれないが、ほとんどの状況では理想からは程遠い。DADフレームワークはこの戦略の有利な点(多くはない)と不利な点(たくさんある)を明確にし、望むらくは、そのアプローチをいまだに信じている人々に自分たちがとっているリスクへの洞察を提供できれば、と考えられている。 より重要な点はDADはより良いオプションへのガイダンスを提供し、プロセス改善へ着手するよう促すことができればよいと狙っている。
Q)なぜDADにはプライマリーロースとセカンダリロールがあるのか?
 プライマリーロール(チーム・リード、チーム・メンバー、プロダクト・オーナー、利害関係者アーキテクチャ・オーナー)は、ほとんどのアジャイル開発の現場で目にするだろう典型的なロールだ。セカンダリロール(ドメイン・エキスパート、テクニカル・エキスパート、スペシャリスト、インテグレータ、独立テスター)は、スケーリングが行われる状況で必要に応じて設けられる。
Q)それでもまだ間違いは犯しうる?
 イエス。保証などない。しかし、筆者達はDADフレームワークは、ライフサイクル全体のサポートとプロセス・ゴール駆動アプローチ、そして広範囲なソース(非アジャイルもふくめて)から得たアイディアのハイブリッドという事実は、これまでよりも情報に基づいたプロセス上の意思決定を行う助けとなると信じている。
Q) DADの”いけてないところ”はなにか?
 潜在的にある課題を以下に挙げよう。
  • DADは、ソリューションデリバリーにおける複雑さを明確にするが、それは「やることだけを教えてくれ」というシンプルなアプローチを探している人を圧倒してしまいがちだ。これに対処するため、DADは着手点となるデフォルトの選択をいくつか提案している。それらの多くはスクラムで推奨されているモノによく似ている。
  • DADはそれ自身まだ生まれたばかりであり、他のフレームワークほどよく知られているわけではない
Q) DADをサポートしているツールには何がありますか?
 Tool Support for DADに紹介しているので、参照いただきたい。
Pocket

DevOps戦略:エンタープライズ・アーキテクチャ − DDevOps#12

devops-practices-enterprise-architecture1
DADフレームワークは、アーキテクチャに関連する活動や、アーキテクチャ/オーナーという役割を明確に定義しており、エンタープライズ対応(Enterprise-aware)という哲学を前面に打ち出している。我々の経験では、ディシプリンドDevOpsの考え方を組織に適用するにあたって、アジャイル・エンタープライズ・アーキテクチャは、実現のための鍵となることが実証されてきた。
一般的なDevOps戦略に加えて、DevOpsをサポートするエンタープライズ・アーキテクチャの活動がいくつかあるので、以下に見ていこう。
  • 再利用のマインドセット エンタープライズ・アーキテクチャの労力が将来に実を結ぶために重要なことは、IT部門、そして組織全体に再利用のマインドセットを定着させることだ。再利用のマインドセットが定着したデリバリー・チームは、既存のデータソース、サービス、コンポーネント、フレームワーク、テンプレート、および他の多くの資産を活用するように努めている。このマインドセットは、エンタープライズ・アーキテクト(理想的には、アーキテクチャ・オーナーとしてITデリバリー・チームのアクティブメンバーであることが望ましい)による教育、コーチングとメンタリングを通して植え付けられる。また、ITデリバリー・チームが使うべき、あるいは使用すべきではない技術を示す技術ロードマップによって可能となる。そしてもちろん、発見しやすく理解しやすく、適用して真の価値を提供できる高品質なアセットの存在が再利用を可能にする。
  • 技術的負債のマインドセット エンタープライズ・アーキテクチャの取り組みでは、デリバリーチームが技術的負債を発見した時にその負債を返済するよう、彼らを動機付けるアプローチを推進すべきだ。さらに重要なのは、最初の段階でそのような負債をかぶらないようにすることだ。多くの技術的負債戦略が、DADフレームワークに埋め込まれているが、技術的負債のマインドセットなしでは、無駄に終わることが珍しく無い。エンタープライズアーキテクト(しばしば、デリバリー・チームのアーキテクチャ・オーナーとして機能する)は、技術的負債に関連する問題を中心に、開発者をコーチし、メンターとしての役割を果たす必要がある。同様に、この技術的負債にかかわってコラボレートする、よりシニアなマネージャーや利害関係者を教育するために役立つはずだ。技術的負債を回避し取り除くためには投資が必要であり、普通IT投資の判断は彼らの手にあるからだ。
  • 開発のガイドライン エンタープライズ・アーキテクチャの重要な側面は、ITデリバリー・チーム全体で共通の懸念に対処するためのガイドラインの開発である。組織は、セキュリティガイドライン、接続のガイドライン、コーディング標準、および他の多くを開発することがある。共通の開発ガイドラインに準ずることで、ITデリバリーチームはより一貫性のあるソリューションを構築し、それは転じて本番稼働時により簡単に操作できサポートできるソリューションとなり、DevOps戦略をサポートする。共通の開発ガイドラインの潜在的な欠点は、開発者がそれらによって制約を感じるかもしれないということだ。この問題への対抗策は、ガイドラインはデリバリーチームとのコラボレーションを通して開発され進化されるべきであり、上から課せられるべきではない。
  • 技術ロードマップ エンタープライズ・アーキテクチャでは、技術ロードマップの定義、サポート、そしてそれを進化させるという活動が含まれ、そのロードマップが組織の他の活動(同様に重要なビジネスのロードマップはプロダクトマネージメントの範疇)をガイドする。このロードマップは、本番環境に共通の一貫した技術的インフラストラクチャーを構築することを助ける。この技術インフラが共通のDevOpsプラクティス―継続的デプロイ、自動化されたエンドトゥエンドのリグレッションテスト環境、以前のブログでも議論した運用のモニタリング―を実現するのだ。
技術ロードマップの重要な側面は、既存のITインフラストラクチャと、そのインフラの将来ビジョンの両方を捉えることだ。ここでITインフラとは、ネットワーク、ソフトウェアサービス、サーバ、ミドルウェア、および主要な構成要素となる少数のデータ・ソースが含まれている。以下の図に見られるように、技術インフラへのビジョンを作る際、考慮すべき2つの問題があります。
  1. オーナーシップ あなたの組織は自身のインフラストラクチャを所有し運営するのか、あるいは外部の専門家にその一部または全部をアウトソースするのだろうか?アウトソーシングオプションには、他の組織(HPやIBMなど)が外部の組織(AmazonやGoogleのような)が提供するクラウド技術を使ってあなたの会社のデータセンターを運用するという従来のアプローチも含まれる。独自のインフラを所有することの利点は、かなりの部分をコントロールできることだ。これはITソリューションのセキュリティと整合性を保証しなければならないときに非常に重要だ。アウトソーシングは、潜在的に規模の経済からITインフラストラクチャとコスト削減を管理する上でより大きな柔軟性をもたらす。しかし、アウトソーシングは、より洗練されたガバナンスを必要とし、前述した従来のアプローチの場合には、アウトソーサーがあなたの要求にタイムリーに応答できない場合、潜在的なボトルネックになる。
  2. 仮想化 特定のソリューションのニーズを満たすために構築された、あるいは可鍛性(※訳注)と進化のしやすさを実現するためにソフトウェア化(softwarization)されたITインフラストラクチャの構成要素があるか?ソフトウェア化―ソフトウェア定義インフラストラクチャ(SDI)として知られている―では、ITインフラストラクチャの要素が完全に仮想化される。ソフトウェア化は、ソフトウェア定義データセンター(SDDC)、ソフトウェア定義(SDS)、およびソフトウェア定義ネットワーク(SDN)を包含したITインフラストラクチャモデルを含む。ソフトウェア化は、通常、ファイアウォールの両側で、クラウドベースのテクノロジを使って実装される。さらに進んだ仮想化のソリューションでは、ITインフラストラクチャの柔軟性とプログラマビリティを高めており、それによってリソースの最適化を可能にする。その一方で、仮想化がもたらすより大きな柔軟性は、あなたのテスト作業の複雑さを増加させ、運用での課題をシミュレーションすることをより難しくする。
    ※訳注 ”可鍛性”:原文では”malleable”。外的圧力を受けても破壊されることなく変形できる能力。ここでは、ビジネス等の外部環境の変化に呼応して変化できる柔軟性という意味。
ITインフラ戦略クアドラント
オリジナル:DevOps Strategies: Enterprise Architecture
(翻訳 藤井智弘)
Pocket

ああ、投稿の間が空いているというのに、宣伝とは・・・orz

突然の告知ですが、この度「エンタープライズ・アジャイル実践入門」という、なんとも身の程知らずなタイトルの書籍を上梓いたしました。宣伝URLはこちら(http://book.impress.co.jp/books/1115170060)。なぜここで告知しているかというと、サブタイトルが「HPE Agile Managerではじめるディシプリンド・アジャイル・デリバリー」だからです!1115170060-170x

WebサイトThinkITさんで連載していたツール解説記事に加筆修正・・・とは名ばかりのほとんど書き直しに近いモノです。

私は現在ヒューレット・パッカードに勤務しており、会社としてはSAFe(Scaled Agile Framework)推しだし、このAgile ManagerというツールもSAFe推しなのですが、そんなこたぁ気にもかけず、DADしてみました。ま、100ページくらいですから、抜けも多く記述も大雑把ですが、「500ページのDAD本に挫けたあなたにはちょうど良いかも・・・」ということで、時間と小遣いが余ったら、暇つぶしにぜひ。

ちなみに、電子書籍では中の図表がカラーです。上記リンクに取り扱い書店の一覧が出ておりますmOm

Pocket

DevOps戦略:データ管理 – DDevOps#11

devops-practices-data-management1
 ディシプリンド・アジャイル・デリバリー(DAD)フレームワークにおけるデータ管理とは、データ指向アーキテクチャ、ポリシー、およびプロセスに焦点を当てた、実行(Run:運用)時の活動を意味する。組織の、データを核とした諸々の活動に対する長期にわたる計画作成の取り組みは、エンタープライズアーキテクチャの取り組みの一環であることに注意しよう。
 同様に、組織のエコシステムのデータまわりの開発は、ソリューションデリバリー・チームによって為される。
データ管理は運用業務の重要な要素なので、ディシプリンドDevOps戦略の影響を被る。経験によれば、以前紹介した一般的なDevOps戦略に、以下に挙げるようなDevOpsをサポートするデータ管理戦略を加える必要がある。
  • データと情報に関するのガイドライン 開発と、データや情報ソースの応用利用との間により高度な一貫性を確保するための直接的な方法は、チームが利用する共通のガイダンスを策定することだ。このガイダンスには標準ポリシーとガイドラインの両方が含まれる。利用者間のコラボレーションとオープンなやり方で定義され、サポートされ、そして時を経て進化し続ける。
  • 質の高いデータソース ファイル、データベース、およびデータフィードなど、本番のデータソースは、簡単に利用出来る高品質なアセットであるべきだ。データソースに記録された後、それらのレコードが高品質であることは特に重要で、それがあってこそそれらは簡単に利用され、進化するのだ。残念ながら、多くの組織では、これは空想の域を出ていない。ディシプリンドDevOpsの考え方では、チームはデータソース内の技術的負債を増やすことについては非常に注意を払い、彼らが見つけた技術的負債を返済するための払う労力に投資することがより重要である。
  • ITインテリジェンス ITインテリジェンスは、データウェアハウス(DW)/ビジネスインテリジェンス(BI)ソリューションの作成・サポートとその進化、そしてオペレーションという相対的な活動である。これにより、あなたの会社のIT活動全般の管理とガバナンスをサポートする。ディシプリンドDevOpsの観点から見ると、ITインテリジェンスには、2つの重要な側面がある:デリバリーチームがどのように機能しているかへの洞察を提供する開発インテリジェンスと、運用で何が起きているのかを提示するオペレーショナルインテリジェンスだ。多くの開発プラットフォームが提供する自動化されたチームのダッシュボードは、開発インテリジェンスの単純な形態だが、より洗練された(そして有用な)ものは、様々な開発ツールからの情報を統合し、統合ダッシュボードに表示するものだ。さらに有用なのが異なるデリバリーチームからの情報を集約/統合し提示するポートフォリオマネージメントダッシュボードだ。
    同様に運用チームも各々のソリューション毎に独立したダッシュボードを持っている。各々のソリューションによって生成された情報を結合し
    統合されたダッシュボードに提示したり、ITポートフォリオマネージメントビューで共有すればさらに有用なものとなる。
次回は、エンタープライズアーキテクチャに関連するDevOps戦略を検討する。
オリジナル:DevOps Strategies: Data Management
(翻訳 藤井智弘)
Pocket

DevOps 戦略: リリース管理その2 – DDevOps#10

decops-practice-releasemanagement
これまでリリース管理の一般的戦略DevOps戦略の概論開発に焦点を当てたDevOps戦略(継続的デプロイメントを含む)を取り上げてきたが、それらに加えてDevOpsをサポートするリリース管理戦略は複数存在する:
  • 統合デプロイメント計画作り:開発チームの視点で見ると、デプロイメント計画作りは、組織の運用部門やリリース管理部門のスタッフと常にやり取りすることが求められる:いくつかのケースでは、運用部門の中にリリースエンジニアと呼ばれる専門の渉外担当を置き、彼/彼女を介してやりとりしている場合もある。あなたがディシプリンドDevOpsの考え方を採用するとすぐに理解することになるのは、運用スタッフがすべての開発チームと一緒に作業する必要があるので、デプロイメント計画にはチーム横断のアプローチが必要であろうということだ。運用スタッフにとってはこれはニュースではない。しかし、自分達だけで、サイロ化された環境で作業することに慣れている開発者にとっては驚きとなる(幸運なことに、この戦略は、DADの”Move Closer to a Deployable Release process goal”(未訳)に組み入れられている)。チームがまだこれをやっていない場合は、組織全体のデプロイスケジュールの中でリリース·スロットをめぐる争いを始める必要があるだろう。
  • 運用環境に準じた標準的な開発環境とテスト環境:開発チームは、開発、テスト、本番環境との整合性が高まるほど、テストとデプロイがより簡単になることを知っている。複数のチームが作業する環境でこれが暗に意味するのは、最終的には環境の多くの側面が事実上標準化されるだろうということだ。開発者は、別の開発ツールを選択することができるが、インフラの側面ーオペレーティングシステム、アプリケーションサーバー、ミドルウェア、データベース、などーでは、リリースプロセス全体が合理化され、時間をかけて整合性が取られることとなるだろう。
  • リリースサービスストリーム:DADフレームワークの主要テナントは、すべてのチームがユニークであるという点だが、それはチームによっては他のチームよりもより多くの助けを必要とするモノがあるということを暗示している。チームの成果物の品質レベルは異なっており、自動化の程度も様々、さらには異なるリリースケーデンスを採用しているといった具合にだ。その結果、これらの状況に対応できるように、リリース管理戦略は、高い柔軟性が求められる。その方法の一つは、ソリューションデリバリーチームに、状況に合わせた異なるサーバーストリームやサービスレベルを提供することだ。たとえば、あなたのチームは基本的なリリース管理サービスストリームを持っているかもしれない。そこでは、リリース管理エンジニアが積極的にデリバリー·チームを支援し、開発成果物を運用環境へのデリバリーし、さらに彼らのプロセスのどこかを自動化する手助けを始めてさえいるかもしれない。
    他方極端な例では、デリバリーチームに対して、継続的デリバリーサービスストリームを提供している可能性もある。その種のストリームでは、テストとデプロイメントプロセスが完全に自動化され、成功にデプロイされるその仕組みに対して高い信頼が寄せられているかもしれない。
    そしてもちろん、これらの両極端の間にいくつかの他のサービスストリームの形態がありうる。このアプローチの利点は、スケジューリングの複雑さのコストが僅かに大きなものになるが、非常に柔軟であることです。
  • リリースブラックアウト期間:一部の組織では、よほどのことがない限り、運用環境に新機能をリリースしないと決めた期間を設定している。この種のブラックアウト期間は、多量のビジネストランザクションが発生する時期に設定されることが典型だ。例えば、多くの北米の小売企業は11月半ばから1月上旬のホリデーセールスシーズンのブラックアウト期間を設定することが多い。多くの組織では会計年度の終わり近くに設定する。年度の終わりに必要な処理を終わらせることに集中するためだ。
  • 共有されたプラクティス:これは本当にプロセス改善の問題だが、リリース管理に関わる人々は誰でも、効果的なプラクティスをチーム間で共有するために積極的に努力すべきであると指摘する価値がある。学びを共有するというのは、エンタープライズ対応の重要な側面の一つだ。
このシリーズの次のブログ投稿では、DevOpsの考え方をサポートするデータ管理戦略を検討する。
オリジナル:DevOps Strategies: Release Management Part2
(翻訳 藤井智弘)
Pocket

DevOps 戦略 : リリース管理その 1 – DDevOps#9

decops-practice-releasemanagement
今回は、DevOpsをサポートする主要なリリース管理戦略4つを採り上げる。効果のあまり高くないものからより高いものへと、順に紹介していく。
  • リリースウィンドウ(スロー・ケーデンス):リリースウィンドウは、一つ以上のチームが運用環境にリリースまでの期間のことだ。リリーススロットは、リリースウィンドウのサブセット(あるいはリリースウィンドウ全体のこともある)であり、この枠の中でチームがソリューションを運用環境へデプロイすることもあるうる。たとえば、本番へのリリースは土曜の夜午前1時から午前5時の間(リリースウィンドウ)に行わなければならず、そのウィンドウの中で4リリースまでは行われうる(リリーススロット)。リーンの用語では、リリーススロットは、チームがデプロイできるカンバンカードに事実上相当する。リリースウィンドウは、システムの利用状況が比較的低調な時間帯に合わせて設定されるのが普通だ。もっとも昨今のグローバル化が進み24×7運用があたりまえの時代には、このウィンドウはあまり意味を持たなくなったが。これにスロー・ケーデンス・アプローチを適用すると、リリースウィンドウは長くなり、1週間に一度など滅多になく、それどころかもっと長くなりさえするだろう。このアプローチの利点は、それがビジネス利害関係者に対しては、一貫したケーデンスでリリースを行い、デリバリー·チームに対しては一貫したリリース目標日をもたらすことだ。スロー・ケーデンス・リリースウィンドウの欠点は、複数チームをサポートする場合にリリース管理プロセスのボトルネックになることだ。各ウィンドウ(期間)中に、あまりに多くのリリーススロットだけがあり、しかもその数は簡単に増やされうるし、これによってチームの意識が将来のリリースウィンドウに向けさせられる。チームが継続的デリバリー戦略に移行し始めると、この問題はさらに悪化してしまう
  • リリーストレイン:リリーストレインというアイディアは、ある”列車(トレイン)”に乗っているすべてのチームが、同じリリースケーデンス・・・例えば、四半期に一度か、月に一度、あるいは週に一度・・・で活動するというものだ。この戦略は、一般的により大規模なプログラム(訳注:いわゆるポートフォリオープログラムのプログラム)、またはチーム・オブ・ チームズ(team of teams)と呼ばれる独立したチームの各々が大きな枠組みの中の一部として活動する形態で採用される。リリーストレインが刻むビートを共有することによって、利害関係者に対しては一貫性したリリーススケジュールを提供し、開発チームのためのラリーポイント(= 各々が開発していた成果物を集めて統合するタイミング)を提供する。列車のメタファーは、実際に非常にうまく機能する。あなたのチームがリリース日を逃し(リリースできず)、列車に乗り遅れれば、列車はあなたなしで 先に行ってしまい、あなたは次に乗車できる場所で待機する必要がある。依存関係も尊重される。例えば、複数のコンポーネントを一緒に出荷する必要がある場合、それらは同じ列車に乗らなければならない(家族が一緒に旅行するようなものだ)。主な欠点は、開発チームが共通のリリーススケジュールに制約され、それがリーンや継続的デリバリー戦略を難しくすることだ。潜在的な欠点は、スロー・ケイデンス・リリースウィンドウのボトルネック問題に苦しむ可能性があることだ。
  • リリースウィンドウ(クイック・ケーデンス): 継続的デプロイメントをサポートするためには、特に多くのデリバリー·チーム全体を考えた場合、多数のリリーススロットが必要になる。これが暗に示すのは、あなたもこれまで以上に多くのリリースウィンドウを必要とするだろうということだ。クイック・ケーデンス・リリースウィンドウの利点は、スロー・ケーデンス・リリースウィンドウやリリーストレインに起因するボトルネックの影響を受けづらいだろうということだ。
  • 継続的リリース・アベイラビリティ:このアプローチでは、デリバリー·チームは、必要なときにいつでも運用環境にリリースすることが許されている。多くの点で、単にリリースウィンドウを24/7にする、これまでのリリースウィンドウ戦略の拡張です。これは本来の意味で、継続的デリバリーをサポートする唯一の戦略です。これを可能にするためには、DevOpsプラクティスのホストがひつようとされる。例えば、完全に自動化されたデプロイメント、完全に自動化されたレグレッション・テスト、フィーチャーのトグル、自己回復コンポーネント、および諸々が必要とされる。
私たちが経験したところでは、今日ほとんどの企業は、スロー・ケーデンス・リリースウィンドウ戦略を採用しているが、同時にクイック・ケーデンスバージョンに至る進化の入口に立っている。 継続的デリバリープラクティスによってよりも、ソリューションデリバリーチームがアジャイルテクニックを適用することで動機付けされることのほうが多い。
私たちは、大規模なプログラムがリリーストレイン戦略を採用するのは見ている。この戦略は1990年代にマイクロソフトやラショナルといった複数のプロダクトを同時に出荷するソフトウェア・スイート製品を販売していたソフトウェア企業によって開拓されてきた。近年、OpenUPやSAFeフレームワークがリリーストレイン戦略を広めている。 継続的リリース・アベイラビリティ戦略は、EtsyやAmazonといった、高度なDevOps組織で採用されている。
重要なことだと理解して欲しいのだが、あなたには複数のオプションがあるということだ。その各々が利点も欠点もある。完璧なたった一つの戦略などはないし、あらゆる状況で機能するたった一つのアプローチも存在しない。あなたは選択肢を必要としているだけでなく、実際に選択肢があるのだ。
次回は、リリース管理DevOps戦略を続けて深掘りしていこう。
(翻訳 藤井智弘)
 
Pocket

DevOps戦略:組織的リリース管理の戦略 – DDevOps#8

今回のテーマはリリース管理戦略をまとめ上げるにあたっての2つの課題について取り上げる。その2つとは、リリース管理のスコープをどうやって決めるかとチーム編成だ。

リリース管理作業のスコープを考慮する際に、2つの基本的な課題がある。

  1. パラダイムのサポート  あなたの組織のリリース管理プロセスがフォーカスをあてているのは単一のパラダイムのチーム・・・例えばアジャイル/リーンチーム・・・だけだろうか?あるいはもっと広範囲な・・・アジャイル/リーンチーム、従来型の手法を採用するチーム、反復型を採用するチーム、そしてアドホックでプロセスに則らないチームまで・・・サポートを検討しているだろうか?リリース管理については現在著述している人々の多くが単一のパラダイムにフォーカスをあてる傾向がある(そのように明確に記してはいないが)。しかし、実際には複数のパラダイムが必要とされているのが、エンタープライズの現実だ。
  2. ドメインのサポート  あなたのリリース管理プロセスは、ITに関連する課題だけにフォーカスをあてているだろうか?それともビジネスに関わるリリースの課題すべてを扱おうとしているのだろうか?ITに関連する課題には、新しいソフトウェアとハードウェアを運用環境にデプロイすることが含まれる。ビジネス面でのリリースの問題には、2,3例を挙げると、マーケティング·キャンペーンや販売組織へのトレーニング、エンドユーザーのための外部支援の枠組みの構築等がある。これは、エンドユーザに向けて構築されたコマーシャルなソリューションであれば、とりわけ重要な要素だ。

これら2つの課題から、リリース管理として扱われる可能性のある範囲を表現する次のグラフが導かれる。

Scope

ディシプリンドDevOpsの観点からは、我々はエンタープライズ全体を対象とする戦略を当然ながら推奨する。対象範囲についてどのような選択をしようが、リリース管理戦略は、デリバリチームがスケーリングすることに対応・支援できる必要がある。検討すべき要因には次のようなものがある:様々なサイズのチーム、地理的分布の度合い、様々なレベルのドメインや技術的な複雑さ、法令遵守が求められる状況下での異なる組織によって構成・分散されているチーム。

リリース管理チームを編成するために考慮すべき戦略には次の3つがある:

  1. 運用部門主導   多くの小〜中規模の組織におけるリリース管理は、運用チームによる多くの活動のうちのひとつとなっている。この”リリースチーム”・・・個人の場合もあるが・・・のアプローチでは、プロジェクト単位でのソリューションのリリースに組み入れられる。開発チームから運用チームへの引き渡しは何回か起こりうるが、運用チームは、開発チームから数名のメンバーがデプロイメント作業に積極的に関与するよう要求するかもしれない。
    運用部門がリリースを管理することの利点は、彼らが現在の運用環境に習熟しており、他のリリースが(もしあれば)並行して行われることを知っている点だ。それにより彼らは全体の状況を把握している。
    主な欠点は、新しいリリースの複雑さについて知らないだろうということであり、それゆえ開発チームメンバーの参画が必要なのだ。
  2. 別々のリリースチーム  より大規模な組織では、リリース管理チームを明確に設けている姿がしばしば見られる。運用部門のサブグループとして設けられることも珍しくない。別チームとする利点は、リリース管理の専門知識をより深めることが出来、本番運用環境に精通し、統合されたやり方でリリースを管理することができるという点だ。欠点は、リリースされるソリューションについては詳しくはなく、リリースプロセス全体でみると、瀬在的にオーバーヘッドをもたらす恐れがあることだ。
  3. デリバリーチームが主導  このアプローチは、開発チームとは別の運用チームを持っていない、非常に小さな組織では一般的であり、そのような組織のデリバリー·チームは、継続的デプロイのプラクティスを実現し、DevOpsに対して非常に統制の取れたアプローチを採用している。デリバリーチームによるアプローチの利点は、チームが、ソリューションがどのようにビルドされるかを知っていることであり、運用へのデプロイ作業を必要に応じて柔軟に行うことができることだ。欠点は、複数のチームの持つ環境でデプロイが衝突するリスクがあることと、異なるシステム間の運用環境への統合問題のリスクがあることだ。幸いなことに、これらの欠点は、開発チーム主導のDevOpsプラクティスと次回以降取り上げるリリース管理プラクティスとの組み合わせで対処することができるだろう。

 

 

オリジナル:Strategies for Organizing Release Management

http://www.disciplinedagiledelivery.com/devops-release-management-teams/

(翻訳 藤井智弘)

Pocket

DevOps戦略:サポート – DDevOps#7

devops-practices-support1

今回は、DevOpsシリーズの一環として、ソリューションサポート戦略を探索する。ソリューションサポート(ヘルプデスク)戦略にはいくつかあるが、それらは組み合わせることが出来、適切なモノを選択することができる。以下に見ていこう:

  • オンライン情報   「自己解決(Self Serve)」を促すとても一般的な戦略は、オンラインのアセットを開発・維持することだ。2,3例を挙げるとFAQページ、トレーニングビデオ、ユーザマニュアルといった類いのものだ。 この戦略は、エンドユーザが自分自身をサポートし問題を解決することを促しているが、「よんだつもり症候群」にかかっているにもかかわらず
  • オンラインディスカッションフォーラム   多くの組織では、エンドユーザー同士がお互いを助けあいながら自社システムの使い方を学習できるように、社内にディスカッションフォーラムを立ち上げている。これは、エンドユーザーが自分で問題を解決するにあたって、効果的に機能する助け合いオプションである。大きな利点は、「パワーユーザー」や場合によっては開発チームのメンバーが、問題と格闘している他のユーザを助けにやってくるだろうという点だ。潜在的な欠点は、問題がタイムリーに解決されない場合に、ディスカッションフォーラムが苦情フォーラムになってしまうリスクがあることだ。
  • 非同期サポート   非同期サポート戦略では、エンドユーザーがヘルプ要求を提出し、その後少し時間をおいて、誰かが助けに戻ってくる(望むらくは)。非同期サポートを実装する一般的な方法は、標準化されたサポート電子メールまたはサポートリクエストページ/画面を実装することです。多くの組織で、ヘルプを必要とする人々の待ち時間を制限するために、サービスレベルアグリーメント(SLA)を設定しているのがよく見られる。
  • 同期サポート    同期サポート戦略では、エンドユーザーがリアルタイムでサポート担当者(アプリケーション開発者の一人であるかもしれない)と接触する。オンラインチャットソフトウェア、ビデオ会議、電話等がよく使われる。同期サポートの重要な利点は、その応答性だ。しかし、同期サポートは、運営が高くつく可能性があり、エンドユーザにとっていらいらの元になり得る。特に、サポートデスク機能がアウトソースされ、所定のスクリプトにただ従うだけのような担当者の場合は、顕著だ。
  • サポートアラート    この戦略では、ソリューション自体がエンドユーザに影響を及ぼすような重大な問題ー例えばデータソースやサービス/コンポーネントが稼働しない等ーを検出する。このようなイベントが発生し、ソリューションが迅速に復旧することができない場合、エンドユーザーは問題の通知を受け、場合によっては「助けが必要ですか?」と尋ねられる。yesを選択すると、問題解決に適切なサポート担当者と、その場で直接コンタクトが取られる。これは、ソリューションの自己回復プロセスの一部です。
  • 開発者主導のサポート    この戦略は、開発チームが自分達で構築したソリューションサポートを行うというものであり、「DevOps戦略:開発」で紹介したものだ。

DevOpsシリーズの次回は、リリース管理戦略を取り上げる。

オリジナル:DevOps Strategies: Support

http://www.disciplinedagiledelivery.com/devops-strategies-support/

(翻訳 藤井智弘)

Pocket

DevOps戦略:運用 – DDevOps#6

devops-practices-operations

これまで説明してきた一般的なDevOps戦略開発に焦点を当てたDevOps戦略に加え、DevOpsの運用面をサポートする技術的な戦略を取り上げていこう。

  1. ソリューションの監視  名前が示すように、これは、運用に入った後稼働しているソリューションやアプリケーションを監視するという運用プラクティスである。オペレーティングシステム、アプリケーションサーバー、および通信サービスなどの技術基盤プラットフォームは、ツール(例えば、Microsoft管理コンソール、IBM Tivoli Monitoringの、およびjManageなど)を使って監視する機能を提供していることが珍しくない。しかし、アプリケーション固有の機能を監視するーたとえば特定のタイプのユーザに使われているのは、どのユーザーインターフェイス(UI)機能かといったーためには、組織の監視インフラに準じた監視機能をアプリケーションに組み込む必要がある。開発チームは、このような運用面での要求に注意する必要があるし、そのような機能を組みいれを簡単に行えるフレームワークに利用出来ることが、より望ましい
  2. 標準プラットフォーム  継続的デプロイメントや初期のアーキテクチャ構想のようなソフトウェア開発プラクティスは、運用インフラの一貫性が維持されていてこそ可能になる。一握りの標準のハードウェア構成に展開する方が、ユニークなモノが無数にある環境に展開するよりもはるかに簡単だ。インフラのソフトウェア(オペレーティングシステム、データベース、ミドルウェア等)のバージョンが一貫しているほうが、デプロイはより簡単だ。たとえば、Oracle DBのすべてのインスタンスが11.2.1.3であり、11.2.0.0、12.0.1.0あるいは11.2.1.3がさまざまな場所にインストールされていないという状態だ。また、最初にインフラストラクチャ·ソフトウェアパッケージに一貫性があると、アーキテクチャ上の決定を行うことが非常に容易になる。たとえば、サーバーオペレーティングシステムとしてLinuxを標準化したら、Windows、z/OSおよび他のものは運用しない(さらには、積極的にそれらを引退させる)といったようにだ。
  3. デプロイメントをテストする  ソリューションあるいは運用インフラを構成するコンポーネントをアップデートしたら、デプロイが成功したかを検証する短時間で実行できるテストを実施すべきである。必要とされた正しいバージョンがインストールされたか?そして、それらはすべて適切なサーバーにデプロイされたか?データベース変換が正常に行われたか?必要なら、適切な通知が行われたか?展開プロセス全体が、要求された時間枠内で実行したか?
  4. 自動デプロイ  デプロイは、手動ではなく自動化されるべきである。これはデプロイ作業の一貫性を高め、継続的デプロイの実現をサポートする。自動化に向けての作業の一部を割いて、自己回復と自己テストの両方をサポートするべきだ。
  5. サポート環境  ソリューションをサポートするチームは、たとえそれがデプロイメントチーム自身であったとしても、エンドユーザが体験した問題を再現出来るような環境を必要とするだろう。オプションをいくつか挙げておこう:
    1. 運用環境を利用する  運用環境をそのまま利用しても十分なケースもあるが、規制制度が関係する場合の多く、特にライフクリティカルや金融等の規制業界では、これは許可されない。
    2. プリプロダクションテストサンドボックス  サポートチームの中には、運用上の問題をシミュレートするために、プリプロダクションテスト環境を使用できることがある。この利点は、問題を再現しようとしたときに運用環境へリスクを注入しないことだ。デメリットはテスト環境が運用環境とは異なることであり、結果として報告された問題すべてをシミュレート出来ないかもしれないことだ。
    3. サポートサンドボックス  一部の組織では、サポートスタッフが運用上の問題をシミュレートするために、特定の環境をセットアップしているところがある。この戦略は、プリプロダクションテストサンドボックス同様のトレードオフに加えて、さらに別の環境を所有する追加コストやメンテナンスというトレードオフがある。

このDevOpsシリーズの次のブログ投稿では、ソリューションのサポート戦略を探る。

オリジナル:DevOps Strategies – Operations

https://disciplinedagiledelivery.wordpress.com/2015/02/19/devops-strategies-operations/

(翻訳:藤井 智弘)

Pocket