カテゴリー別アーカイブ: DA2.0

QCon Tokyo2016で、ディシプリンドDevOpsの講演やります。

来る10月24日 QconTokyo2016(http://www.qcontokyo.com/)というイベントで、ディシプリンドDevOpsについて講演する機会をいただきました。

タイトルは、「DevOps導入&実践の落とし穴ーDisciplined DevOpsに見る体系的アプローチ」

DADのDevOpsについては、すでにブログのほうで連載モノを翻訳&公開していますが、DA2になって正式なコンテンツとして組みいれられています(現在翻訳中)ので、それと連動した内容にしようと思っていますので、ご興味のある方は是非。

いちおう筆者の所属する会社(日本ヒューレット・パッカード株式会社)の人として出るので、一部会社の戦略やアプローチが入りますが、基本はDADベースで。

LINEで送る
Pocket

DA2.xサイト リニューアルにあたり。

書籍「ディシプリンド・アジャイル・デリバリー エンタープライズアジャイル実践ガイド」を翻訳した流れで立ち上げたこのサイトですが、DADが無事2.0(そしていまは2.x)へとバージョンが上がったのを受けて、本サイトもそれに合わせてリニューアルしました。

「なるべくたくさんのコンテンツを翻訳してお届けしたい」とは思いつつ、ボランティア活動の悲しさ、すべては無理だと思っています。当面、次の観点から翻訳対象を決めています。

  • メニュー項目から直接リンクされているコンテンツ(これを1stレベルとする)をターゲットとし、1stレベルのコンテンツ内に他投稿へのリンクが貼られている場合には、リンク先は翻訳対象とはしない。
  • ただし、DADの根幹にかかわる概念を説明する投稿については、その重要性を鑑みて翻訳することもある。
  • 書籍で提示されているコンセプトよりも、DA2として拡張されたコンテンツの翻訳を優先する。

ということで、まだまだ未成熟ですが、「DADは進化する」を言い訳にご容赦いただきつつ、ぜひご活用あれmOm

(藤井智弘)

 

 

 

 

LINEで送る
Pocket

ディシプリンド・アジャイル・マニフェスト

このディシプリンド・アジャイルマニェストは、2001年に記されたオリジナルのアジャイルソフトウェア開発宣言を拡張し、DAフレームワークの背景となる哲学を反映させたものだ。

私達が認める価値

私達は次の価値を認める:

プロセスやツールよりも個人と対話
包括的なドキュメントよりも使用可能なソリューションを
契約交渉よりも利害関係者との協調を
計画に従うことよりも変化への対応を

 すなわち、左記のことがらに価値があることを認めつつも、ディシプリンド・アジャイリストは右記のことがらにより価値をおく。

ディシプリンド・アジャイルマニフェストの背後にある12の原則

  1. 利害関係者の満足を最優先し、価値のあるソリューションを早く継続的に提供します。
  2. 要求の変更はたとえ開発の後期であっても歓迎します。
    変化を味方につけることによって、そのお客様の競争力を引き上げます。
  3. 使用可能なソリューションを、2-3週間から2-3ヶ月という
    できるだけ短い時間間隔でリリースします。
  4. 利害関係者と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
  7. 使用可能なソリューションこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。スポンサー、開発者、そしてユーザは
    一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意がアジリティを高めます。
  10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、
    それに基づいて自分たちのやり方を最適に調整します。
  13. 組織のエコシステムの中でアセット利用を促進し進化させます。それらのアセットに責任を担っている人々と共に作業します。
  14. ワークフローを可視化することで、しかかり作業を最小に維持しながら一連のデリバリーフローがスムーズに流れることを助けます。
  15. 組織のエコシステムは、アジャイルチームの努力を反映しまたそれを高めるよう進化しなければなりません。また、非アジャイルあるいはハイブリッドチームを十分サポートできる柔軟なものでなければなりません。
http://www.disciplinedagiledelivery.com/disciplinedagilemanifesto/
 (翻訳 藤井智弘)
LINEで送る
Pocket

ディシプリンド・アジャイル・フレームワーク

ディシプリンド・アジャイル2.0プロセスディシジョンフレームワークは、組織が自分達のITプロセスを、コンテキストに合わせた形で合理化することを助ける軽量なガイダンスを提供する。ソリューションデリバリーや運用、エンタープライズアーキテクチャ、ポートフォリオ管理、そしてそれ以外の多くの活動をどのように組み合わせて実践するかを提示する。このフレームワークは、これらのアクティビティが対処するものがなにかを説明し、それを為すために取り得るオプションと、各オプションに伴うトレードオフを説明する。

この記事では、次のトピックスを見ていこう:

なぜディシプリンド・アジャイル2.0なのか?

筆者達がソリューションデリバリーの域を超えてフレームワークを拡張したのには、以下に挙げるいくつかの理由がある:

  1. アジャイルデリバリーチームの成功を可能にするために
    ディシプリンド・アジャイル・デリバリー(DAD) 1.xのフォーカスは、ソリューションデリバリーにおける活動のすべて(分析、設計、テスト、アーキテクチャ、管理、プログラミング等々)がどのようにしてしっかりとかつ効率的に組み合わされるかを示すことで、アジャイル/リーンチームが初めから終わりまでどのように活動するかを説明することにあった。しかし、デリバリーを成功させるためには、チームはチーム外の人々(例えば、エンタープライズアーキテクト、運用のエンジニア、ガバナンスを司る人達、データ管理者、その他諸々)と共に働かなければならない。アジャイル/リーンチームがより効果的にあるためには、これら(チーム外)の人々も、アジャイル/リーンの作法で活動しなければならない。
  2. アジャイルITの首尾一貫した戦略を提供する
    もし読者がソフトウェア開発をキツい(hard)仕事だと考えているなら、IT部門のすべての活動はさらに大変だ。IT部門とは複雑適応組織 (complex adaptive organiation)なのだ。この言葉を使った意味は、ひとつのチームのアクションは他のチームに影響を及ぼし、それがどんどん伝搬していくということだ。例えば、読者のアジャイルデリバリーチームのやり方が、やり取りしている他のチームに影響を及ぼし、そのチームから影響を受けるだろう。もし読者が(おそらくDevOps戦略の一環で)運用チームと作業しているなら、各々のチームがお互いに効果的に共同作業出来るようなやり方を採用する必要がある。各チームは、他のチームから仕事のやり方を学び改善することが望ましい。この改善はさざなみように他のチームに伝わっていく。難しいのは、IT分野の各領域はひとつかそれ以上の知識体系(bodies of knowledge)を持っており(場合によっては“知識本(books of knowledge)”として出版されていたりするが)、この類いの体系は、各領域で働く人へのガイダンスを提供している。例を挙げると、管理者であればPMIBoKやPrince2、エンタープライズアーキテクトであればTOGAF やZachmanフレームワーク、ビジネスアナリストであれば、IIBA BoK、データ管理者でれば、DAMA BoK等々、といった具合だ。これらのインダストリーグループとそれに関連する知識体系は、お互いを否定しあい、アジャイル/リーンの学習曲線の異なる位置におり、時々アジャイル/リーンではない戦略を推奨したりする。ITのレベルでは、大きな混乱が起こり、機能不全に終わる可能性がある。DAフレームワークは、どのようにこれらすべてを柔軟に組み合わせて、複雑適応系において直面した現実をサポートするかを提示する。
  3. リーンエンタープライズのサポート
    リーンエンタープライズは、市場での変化を予測し、迅速に対応することを可能にする。これは、直面している状況に対応出来るように変化することを促す、組織の文化と構造によってなされる。リーンエンタープライズは主流のビジネスで学び続けるマインドセットと、イノベーションをドライブする底流に流れるリーンおよびアジャイルプロセスを必要とする。これは、アジャイル/リーンのやり方でIT部門が作業出来るということも意味している。
  4. コンテキストを考慮する
    すべての人、チーム、組織が、ひとつひとつはユニークなものだ。これが意味するところは、読者諸氏には、選択肢を提供したフレームワークが必要だということだ。それによって読者は現実に直面している状況に対処するためのアプローチをテイラリングでき、後々それを進化させることができる。SAFeやNexusのようにあらかじめ規定され(prescriptive) 1サイズですべてに適用させるフレームワークは、プロセスに関連する最初期のニーズに対しては魅力的で簡単なソリューションに思えるかもしれないが、現実は採用した組織に対して、良いことよりも害を及ぼすほうが多くなることがしばしば見られる。

なぜ名前を変えたのか?

フレームワークのスコープが、ITソリューションのデリバリーをどう効果的に進めるかから、IT活動全般をどう効果的なものにするかへと、進化している。結果として筆者達は、”ディシプリンド・アジャイル・デリバリー”という名称が、もはやフレームワークのゴールを表現していないと感じた。”ディシプリンド・アジャイル”のほうがより正確だ。

リリース戦略(※訳注:古い情報です)

 基本的な素材は2014年後半から2015年にかけてリリースを始め、最終的には、2015年8月リリースを予定している。つまりまだ終わっていない。2015年8月にDA2.0 のマテリアルを段階的にリリースしていく。

経緯・歴史

 このフレームワークは、3つのメジャーリリースをここまで重ねてきた。
  1. ディシプリンド・アジャイル・デリバリー 0.x     本フレームワークの起源は、IBM Rationalで2009年の始めから2012年6月にかけて開発された。 IBMチームは、ビジネスパートナーと密に協力してきたが、その中にMark Linesが参加し、Scott Amblerがリードしてきた。IBM Rational Method Composer(RMC)は、DADフレームワークの早期バージョン(バージョン0.5)をサポートしている。
  2. ディシプリンド・アジャイル・デリバリー 1.x     2012年6月の最初のDAD本”ディシプリンド・アジャイル・デリバリー”出版を以て、DAD1.0のリリースとしている。DADフレームワークの進化と公開は今ご覧のサイト上で2012年の8月から始まっている。DADフレームワークの知的財産は、Disciplined Agile Consortiumへ2012年10月に引き渡され、2014年6月IBMにより法的に確認された。
  3. ディシプリンド・アジャイル・デリバリー 2.0     これが現在のバージョンである。最初のリリースは2015年8月に行われた。前述したように、フォーカスはITプロセスへの柔軟でコンテキストに応じたアプローチへと進化している。

将来

今後もこのサイト上でマテリアルを開発し続けるつもりだ。アップデートの通知が必要であれば、このブログを購読してほしい。LinkedInのディシプリンド・アジャイルにフォーラムを開設しているので、進行中の議論に参加したければ、そちらにもご参加いただきたい。

 http://www.disciplinedagiledelivery.com/agility-at-scale/disciplined-agile-2/
 (翻訳 藤井智弘)
LINEで送る
Pocket

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

ディシプリンド・アジャイル(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/
 
(翻訳 藤井智弘)
LINEで送る
Pocket