よくある質問

最近はエンタープライズアジャイルの勉強会なるものも立ち上がってきたり、説明の機会をいただくことも多くなってきましたが、そこで「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に紹介しているので、参照いただきたい。
LINEで送る
Pocket