軽量マイルストーンによるアジャイルプロジェクトリスク軽減

DADは、プロジェクト/リリースの進捗状況と健康状態を測定するために、ライフサイクルにいくつかのマイルストーンを組み込んでいる。

DADにはなぜマイルストーンがあるのか?

主流のアジャイル手法には、ガバナンスの考え方はほとんどなく、アジャイルにはマイルストーンは不要であると考える人は多い。スクラムは、最も価値の高い作業をバックログの一番上に位置付ける。そして各スプリント(反復)の終了時に、バックログ内の次の作業が十分な価値を生み出すかどうかによって、次のスプリントに予算をつけるかどうかが決まる。価値がないとみなされると、プロジェクトは終了する。基本的にこの戦略は理にかなっているが、ガバナンスの面で、以下のような欠陥がある:

  • 十分ではない
    プロジェクトへの予算割り当てをやめるタイミングで判断する以外に、はるかに効果的なガバナンスがあるのではないか。例えば、プロジェクトはどのように始まったのだろうか?
  • 現実的ではない
    実際問題、ほとんどの組織では、スプリントごとに予算配分の意思決定を行うわけではなく、複数の反復で構成されるリリース単位で判断をすることのほうが多い。
  • 効果的なマイルストーン
    スクラムはマイルストーンを持たないと主張しているが、本番移行するのに十分な機能があるかどうかを検討したり、今後の戦略を決定したりすることは、暗黙的なマイルストーンである。DADは、マイルストーンを効果的に適用するための指針を明示している。

アジャイルガバナンスはなぜ必要か?

多くの人が思い込んでいるのとは違って、アジャイル・イニシアチブの中で、ガバナンスは不要にはならない。スポンサーやその他の利害関係者には、彼らの投資に対する現在の状況を定期的に報告するべきである。彼らは以下のような質問への答えを期待している:

  • 投資から何が得られ、それにはどんな価値があるのか?
  • 最初の予算要求に沿って提供されているものは何か?
  • 未解決のリスクの状況は? そのリスクを緩和するために何が行われているか?
  • 現在のリリース予定は、元の予測と一致しているか?
  • 本番リリースのために十分な機能はいつできるか?
  • すべての利害関係者がリリース準備できているか?
  • プロジェクトはいつ完了するか?

「それはアジャイルじゃない」という主張は、上のような質問に答えないことで、アジャイルが時に無規律とみなされるゆえんである。事実、このような主張は、アジャイルがなぜ効果を発揮しないかという言い訳のひとつとして、よく利用される。幸いなことに、DADにはこれらの質問に答えるための仕組みがあり、多くの組織ではアジャイルの適用を拡張し、DADのガイダンスを組み込んでいる。実際、アジャイル性を保ちつつ、プロジェクトを管理する方法を模索している人にとっては、DADは非常に魅力的である。

マイルストーン・レビューは非公式なものとすべき

DADの目標で推奨されている戦略に沿った形で「チームミッション達成」マイルストーンをレビューする時には、軽量な形式にするべきである。アジャイル基本ライフサイクルを使用する場合、それは通常、反復もしくはフェーズの終了と一致する。DADになぜフェーズがあるか疑問に思われる場合は、このブログの関連記事にその情報がある。

マイルストーンの日付は伝達する必要がある

DADプロジェクトの各マイルストーンの日付をカレンダーにして、それを利害関係者に提供し、その利害関係者が関心のあるマイルストーンのレビューにあたる反復レビューに参加する予定を組めるようにすることは、良い習慣としておすすめできる。マイルストーンの日付が変更される可能性はあるが、すべての利害関係者へのロードマップとして、プロジェクトポートフォリオ全体にまたがった目標マイルストーンを表示するのは、大変有用だ。

DADマイルストーン

利害関係者のビジョン
方向付けフェーズの目標は、最低限のしかし十分な時間をかけて(通常1〜4週間で)、今回のプロジェクトに意味があり、よって構築フェーズに進んでよいという、利害関係者の合意を得ることである。DADの方向付けの各目標に取り組むことで、初期スコープ、技術、スケジュール、予算、リスクといった従来のプロジェクト情報を、できるだけ軽量な形でデリバリーチームが得ることになる。この情報は、「共通のビジョンを作る」ゴールに記述されているビジョン・ステートメントとして整理され、利害関係者に提示される。ビジョンの形式やレビューの公式度は、状況によって変わりうる。典型的なやり方は、方向付けフェーズの終了時に主要な利害関係者で数枚のスライドをレビューし、プロジェクトの意義とデリバリー手法に関して全員が同じものを確認していることを確実にすることである。

検証されたアーキテクチャー
プロジェクトのリスクを早期に軽減することは、よいプロジェクト管理手法のひとつである。「アーキテクチャーを早期に実証する目標が示すように、このためにはいくつかの戦略が採用できる。最も効果的なのは、技術的にリスクの高いビジネス要求を、エンド・ツー・エンドで動作するコードのスケルトンに実装してみることである。DADにおけるアーキテクチャーオーナーの重要な責務は、方向付けフェーズでリスクを特定することである。これらのリスクは、構築フェーズの1〜3回の反復の中で関連する機能を実装することで、軽減もしくは解消することが期待されている。この手法を適用した結果、初期の反復レビューやデモで、機能要件に加えて/もしくはその代わりに、非機能要件をサポートするソリューションの能力が示されることがある。このため、アーキテクチャーに関心を持つ利害関係者がこれらのマイルストーンレビューに参加する機会を与えられることが重要である。

プロジェクトの実行可能性
リリーススケジュールに含めるオプションのマイルストーンは、プロジェクトの実行可能性に関するものである。プロジェクトのあるタイミングで、利害関係者は、方向付けの終了時に合意したビジョンに沿ってプロジェクトが進行しているかどうかを確認するチェックポイントを要求することができる。これらのマイルストーンの予定を立てることによって、利害関係者は、プロジェクトの状況を評価し、必要があれば変更に合意するために、チームと一緒にいるべき重要な日程を認識することができる。ここで可能性がある変更としては、投資レベル、チーム構築、スコープ、リスクアセスメント、もしくはプロジェクト中止の可能性さえ含まれている。これらのマイルストーンは複数存在する可能性がある。もし利害関係者が変更に合意したら、ビジョンはそのタイミングで更新される。スクラムは暗黙的にこのマイルストーンを各スプリントの終了時に行う。DADはこれを明示的に選択し、その頻度を任意にしている。

十分な機能性
各反復の終了時に使用可能なソリューション(スクラムで「潜在的に出荷可能なインクリメント」と呼ばれるもの)をリリースすることを目標とする、ということもある一方、本番移行するのに十分な機能をチームが実装するために、構築フェーズの反復を複数回必要とする、というのもよくあることである。これは時として、最低限実行可能な製品(MVP)と呼ばれるが、これは技術的には正確ではない。古典的にMVPは最小限の本番移行可能な機能を示すものではなく、製品の実用性を確認するためのものである。このマイルストーンと対応するより正確な用語は、「最小限の機能セット」だろう。しかしながら、後者の意味でこの略語が使われていることが多い。

十分な機能が利用可能になり、利害関係者へのリリース移行コストが正当と判断された場合に、DADの「十分な機能性」マイルストーンは、構築フェーズ終了時に達成したとみなされる。例えば、使用可能なソリューションインクリメントは2週間の反復ごとにできるかもしれないが、高いコンプライアンスレベルが要求される環境では実際にそれを本番移行するのに2週間かかるかもしれない。この場合、より多くの機能が完成するまで、移行に要するコストは正当とはみなされない可能性がある。

本番準備完了
重要な場面では、利害関係者へのソリューションデリバリーの一環として最終準備を行うために、公式の移行フェーズが必要になることがよくある。十分な機能が開発され、テストされたら、その後通常必要なのが、データ変換、最終受け入れテスト、製造及びサポート関連の文書化のような移行関連の活動である。理想的には、これらの作業の多くが、機能の各インクリメントを作る一環として構築フェーズの間に継続的に行われている。いくつかのポイントでは、ソリューションを準備完了とするための決定が必要となる。もちろん、継続的デリバリーライフサイクルに従っている場合には、「移行フェーズ」は「移行作業」になるだろう。しかしながら、ソリューションをデプロイする前に、そのソリューションが使用可能であることを確認したい関係者は依然として存在する。

満足した利害関係者
ガバナンス組織やその他の利害関係者は、プロジェクトがいつ公式に終了するかを知りたいことがある。それによって次のリリースを開始したり、他に予算を振りかえたりすることができるからである。プロジェクトは、ソリューション本番開始の翌日に終了するわけではない。トレーニングや本番移行後のチューニング、サポート移管、実装後の再レビューなどのプロジェクト完了作業はしばしばあり、プロジェクトが完了したと判断される前に保証期間を設けることもよくある。リーンには「顧客満足」という用語があるが、これは「満足」の閾値が低すぎることを示唆している。一方DADは、プロジェクトが完了したと判断する前に、サポート担当などの顧客以外の利害関係者の満足を満たす必要もあると考え、マイルストーンの名前を「満足した利害関係者」としている。

マイルストーンを試してみる

アジャイルは、利害関係者に対する透明性と説明責任を促す。みなさんのプロジェクトで重要なマイルストーンの達成を共有し、お祝いしよう。

オリジナル:Reduce Agile Project Risk with Light-Weight Milestones

Reduce Agile Project Risk with Light-Weight Milestones


 (翻訳 中佐藤麻記子)

Pocket

アーキテクチャーオーナー

上の図でおわかりいただけるように、DADの基本的な役割はスクラムのものと似ている。スクラムでは、プロダクトオーナーは何をどの順番で構築するかを決定する。DADではアーキテクチャーをプロジェクトリスクの重要な鍵とし、チームがこれらのリスクに確実に対処することに責任を負う何らかの役割が必要と考えている。結果としてDADプロセスフレームワークには、アジャイルモデリングの役割であるアーキテクチャーオーナーを明示した。アーキテクチャーオーナーはチームのアーキテクチャー上の決定を行い、ソリューション設計全体の構築と進化をファシリテートする役割である。チームリードの役割にあたるメンバーがアーキテクチャーオーナーになることも多いだろう。これは大規模開発ではあまりないが、小規模なアジャイルチームではよくあるケースである。

アーキテクチャーオーナーの責務は以下のようなものである。

  • チームが開発しているソリューションのアーキテクチャー構築/進化をガイドする。アーキテクチャーオーナーは、単にアーキテクチャーに責任があるだけではなく、技術的な議論をリードする役割であることに注意すること。
  • アーキテクチャー上のプラクティスや課題について、他のチームメンバーに助言・指導を行う。
  • 組織のアーキテクチャー上の方向性や標準を理解し、チームがそれらを適切に順守できるようにする。
  • フレームワークやパターン、サブシステムのような企業内にすでに存在する資産を理解し、チームが適切にそれらを使えるようにする。
  • 技術的負債を最小限にするためによい設計とリファクタリングを奨励し、それによってソリューションのサポートが容易になるようにする。
  • ソリューションが定期的に、理想的には継続的インテグレーション(CI)のプラクティスによって、統合されテストされるようにする。
  • 最終的な技術的決定はしつつも、協調的にチームプレイでアプローチするため、アーキテクチャー的な方向性を「指示」することは避けようとする。アーキテクチャーオーナーは、チームリードと緊密に協力し、プロジェクトの重要な技術的リスクを軽減するための戦略を特定・決定する必要がある。
  • プロジェクト初期のアーキテクチャー検討をリードし、初期段階の要件検討を(特にソリューションの非機能要件を理解・進化させる点で)サポートする。

DADにおいてこのような役割を作っている主な理由のひとつは、作業項目一覧(スクラム用語でいうバックログ)に作業項目を追加し優先順位付けするにあたり、プロダクトオーナーと同様アーキテクチャーオーナーにも発言権があるという点である。確かにビジネス価値は優先順位を決定する際の主要な要因ではあるが、技術的リスクを緩和するための作業も同じように重要である。加えて、DADの目標は、単に動作するソフトウェアというだけではなく、使用可能なソリューションをデリバリーすることである。そのため、例えばエラーログや監視などの本質的に技術的な作業項目を追加することも必要になる。もしくは、継続的インテグレーション/デプロイのプロセスを改善するための作業項目を追加する必要もあるかもしれない。我々は、プロダクトオーナー・アーキテクチャーオーナー両方の概念があることで、使いやすさやサポートのしやすさのような機能要件・非機能要件の両方に適切に対処できることに気づいた。実際、私(原著者)の現在のプロジェクトでは、プロダクトオーナー・アーキテクチャーオーナーの双方と連携し、作業中のイテレーションに優先度の高いストーリーを入れるだけではなく、利害関係者にソリューションを提供する移行フェーズに入るための準備として、ソリューションを強化するための作業項目も含めるように、優先順位を交渉している。アーキテクチャーオーナーが役割として明確になっていなければ、作業項目一覧内で重要な技術的項目の優先順位を上げるのは難しいかもしれない。結果として、プロダクトオーナーの知識のみで優先順位付けが行われ、健全なプラクティスとならず、最悪の場合、低品質のソリューションに帰結してしまう。

スコット(原著者の一人)がアーキテクチャーオーナーの役割をより詳細に記述した良記事を書いているので、こちらもご覧いただきたい。

オリジナル:The DAD Role of Architecture Owner

The DAD Role of Architecture Owner


 (翻訳 中佐藤麻記子)

Pocket

DAD説明会は、”怖い”のか?

さる10月24日、縁あってQConTokyo2016で、ディシプリンドDevOpsをネタにしたセッションの機会を頂戴しましたが、その後の懇親会の場である方に言われたのが、
DAD説明会への申込みは、”怖い”と思われているのではないか?
という点。すでに数件依頼をいただいていたので、
へ? ”怖い”?
って感じだったのですが、その方曰く、どうやら怖いと思われる要因は以下の2つのようで・・・

  1. ベンダーに勤めている人がただで説明会に来てくれるってこと自体が、なんだか”怪しい”。その後どどどって、営業がやってくるのではないか?
  2. 講演料とか払わなくてもいいのだろうか?なにか魂胆があるのではないか?

「うーむ、みんなそんなに筆者のことを理解しているのか」・・・じゃなくて、「おじさんは、怖くないんですよ〜」と理解していただくために、ちょっと補足説明しておきます。

まず、1について。
ご依頼いただいた場合には、基本的には筆者(ヒューレット・パッカード所属)が伺いますが、スケジュール等合わない場合には、DAD本翻訳メンバー(ゼンアーキテクツさんとか豆蔵さんとか)に依頼することもありえます。その意味でも特定のベンダーやツールに依存した話はありません。
説明会の趣旨はあくまでもDADをご理解いただくことにあり、DADを売りに伺うわけではありません。DADの有効性を理解いただきチャレンジする方が増えていけば、自然とビジネス機会が増えていくという捉え方です。ですから、筆者もこの活動に関する限り、交通費等のコストはすべて自前でやってます。

で、2.の費用面について
まず、講演料を頂戴することを前提条件にしてはいません。あくまでもボランディアですから、無料でも全然結構です。もちろん、「払いたい」と言っていただいたものをむげにお断りするような非人道的な振る舞いに及ぶことはありません。その額の多寡によって講演者の熱意・集中力・説得力等が影響を受けることは、たぶん、おそらく、あまりめったにありません(と予想はしていますが、確信となると・・・)。

ただし、以下の場合には、費用負担をお願いする可能性が高いです。
・ちょっと交通費がかかっちゃう場合
一応、都内(23区周辺)を前提に考えているので、交通費がやや多めにかかる場合、実費程度のご負担をお願いする可能性は高いです。あらかじめご承知おきください。

・宿泊が必要になる場合
例えば、時間帯によっては講演後宿泊が必要になる場合もあるでしょう(大阪で午後8時開始みたいな)。交通機関の発達した日本ですから、日帰りできるエリアはかなり広くなっていますが、そういうセッティングはできるだけご勘弁を。

あ、もうひとつ。これまで、「ボランティアなので出来れば夕方で・・・」と申込みページに書いていましたが、「一緒に開発するベンダーさんも含めて聞きたいから、早い時間で出来ないか」とリクエストされることもあり、今後午後の早い時間での開催リクエストにも対応させていただくことにします。

 

・・・ということで、敷居は低く設定していますので、ぜひ遠慮なさらずに気軽にお声がけくださいませ。

記)藤井智弘

Pocket

DADとラショナル統一プロセス(RUP)の比較(パート2)

この投稿は、DADとラショナル統一プロセス(RUP)の比較(パート1)の続編である。パート1では、ディシプリンド・アジャイル・デリバリー(DAD)が “アジャイル版RUP” ではない理由を何点か記述した。DADはその取り組み方においても内容においても、全く異なるものである。しかし、アジャイル手法の主流ではないが、統一プロセス(UP)には含まれているもので、大変すぐれた原則もまた存在する。本投稿では、UPの中で、DADのプロセス・デシジョン・フレームワークに組み込まれたものをいくつか紹介する。

DADはRUPと同様、すべてのデリバリー・ライフサイクルを網羅している。アジャイルの文脈では否定されているが、DADでは実際のプロジェクトはいくつかのフェーズを経るものと考えている。RUPは、方向付け・推敲・構築・移行という、明確な4つのフェーズを持っている。以前の投稿で記述したいくつかの理由により、DADは明示的な推敲フェーズを持っていない。しかし、推敲のマイルストーンは依然DADの中に存在する。以下のDAD基本ライフサイクルの図にあるように、DADには、RUPの4つのフェーズのうち3つがある。

3 - DAD Lifecycle agile scrum

・方向付けフェーズ
プロジェクト初期の活動を方向付けフェーズという形で明示しているのは、DADの重要な特徴である。Scott Ambler(訳注:DAD本著者の一人)が自身の投稿の中で以下のように述べている。
”アジャイル・コミュニティの中では「フェーズ」という言葉はNGワードとして扱われがちであるが、現実問題として、ほとんどのチームではプロジェクトの初期段階で事前作業として行うべきことがある。この作業は、スプリントゼロ/イテレーションゼロという間違った認識をされることもあるが、一般的に想定されている以上に、通常この作業には時間がかかっていることは、容易に見て取ることができる(2009年アジャイルプロジェクト開始時に関する調査では、平均的なアジャイルチームは方向付けに3.9週間かけている)。”
そのため、DADの方向付けフェーズ(通常1回の反復)では、非常に軽量なビジョン作成の活動を行い、プロジェクトの枠組み作りが適切に行えるようにした。このフェーズのマイルストーンは、プロジェクトの進め方について「利害関係者の合意」を得ることである。DAD本では、方向付けフェーズをできるだけ素早く進めるためのさまざまな戦略、なすべきこと、利害関係者の合意をいかに得るかを記述した。

・構築フェーズ
このフェーズは、ソリューションのインクリメント(増分)を構築するイテレーション(スクラム用語ではスプリント)の集まりとして考えることができる。各イテレーションの中でチームは、スクラム、XP、アジャイル・モデリング、アジャイル・データ等のプラクティスをハイブリッドで適用し、ソリューションをデリバリーする。DADは、初期のイテレーションにおいて作業を優先付ける際に、リスク−価値駆動のアプローチを推奨する。これは、動作するソリューションとともにアーキテクチャーを提供することで、プロジェクトのリスクをできるだけ早期に軽減しようとするRUPの原則から来ている。そのため我々は、ビジネス価値の高い部分をデリバリーすることと、アーキテクチャーリスクを軽減するための作業とのバランスを取るようにした。初期のイテレーションでは、高いビジネス価値とリスク軽減の両方に関わるストーリー/機能をデリバリーすることが理想である(故に、DADは「リスク−価値駆動」である)。初期イテレーションの完了時に、本当に技術的リスクに対処できているかどうかを評価するためのチェックポイントを置くことには、意義がある。DADはこれを「実証されたアーキテクチャー」として明確なマイルストーンとしている。これはRUPの推敲フェーズのマイルストーンと類似しているが、RUPの実装においてしばしば混乱の原因になった推敲フェーズのリスクを冒さずにすむ。アジャイルの手法はすべて、利害関係者にできるだけ素早く価値を届けることをめざしている。ほとんどではないにしても多くの大企業では、イテレーション完了のたびにソリューションの新規追加分をデリバリーすることは、現状困難である。それゆえDADは、この現実を認識し、ほとんどの場合、ソリューションが実際に顧客にデリバリーされる前に、構築フェーズのイテレーションが複数回存在するだろうと結論付けた。DAD本の中で明確にしたように、これがDADの基本パターンではあるものの、「継続的デリバリー」の目標達成の精神をもって、今まで以上に頻繁にソリューションをリリースするように努めるべきだ。構築フェーズ完了のマイルストーンは、利害関係者へデプロイするのに「十分な機能」があることである。これはRUPの構築フェーズのマイルストーンと同じである。構築フェーズの間、方向付けフェーズで合意されたビジョンに沿ってプロジェクトが進捗しているかどうかを定期的に振り返り、時には方向性を修正するのは、意味のあることだ。これはDADの補足的なマイルストーンで、「プロジェクトの実現可能性検討」と呼ばれる。

・移行フェーズ
高度なエンタープライズ・アジャイルプロジェクトでは、利害関係者に頻繁にソリューションをデプロイすることはそう簡単なことではないと、DADは認識している。この現実を考慮して、DADはRUPの移行フェーズを組み込んでおり、通常1回の短いイテレーションを想定している。DADチームとしても、企業全体の流れとしても、このデプロイプロセスはより短縮され、継続的デプロイとなって徐々に消滅していくことが理想である。RUPの移行フェーズのマイルストーンは、顧客が満足し、自足することで達成される。DADではこれを「利害関係者の満足」に変更した。これはリーンでいう顧客満足に似ているが、エンタープライズにおいては、例えば製品サポートのような、顧客以上に幅広い利害関係者の満足が重要だと我々は考えている。RUPの移行フェーズの特徴のひとつは、このフェーズのどこでデプロイが行われるかが明確でないことである。明らかに利害関係者の満足が得られていない場合は、ソリューション開発は継続して行われている。通常このフェーズは、利害関係者のニーズを完全に満たすための安定化、調整、トレーニングなどの期間である。そのためDADには、移行フェーズの途中に「運用準備」と呼ばれるマイルストーンがある。時にはこれは「go/no go(進むか止まるか)」を判断するための正式なものになる。

まとめると、DADはエンド・ツー・エンドのリスク−価値駆動ライフサイクルの考え方の元、プロジェクトが適切に進捗しているかどうかを確認するためのマイルストーンによって、アジャイルプロジェクトに道筋をつける。これらのチェックポイントは、道順を変更し、適応し、プロジェクトを次フェーズに進めるための機会を提供する。このライフサイクルはRUPに似てはいるものの、パート1で述べたように、イテレーション内で行われる実際の作業は全く異なり、典型的なRUPのプロジェクトよりはるかにアジャイル的であることを理解することが重要である。

Scott Ambler + Associatesでは、RUPから、よりアジャイルな、しかしディシプリンドなDADの提供する手法へ移行するための助けをもとめる企業から、多くの問合せがある。

オリジナル:Comparing DAD to the Rational Unified Process (RUP) – Part 2

Comparing DAD to the Rational Unified Process (RUP) – Part 2


 (翻訳 中佐藤麻記子)

 

Pocket

DADとラショナル統一プロセス(RUP)の比較(パート1)

先日、私(訳注:Mark、DAD本原作者の一人)が初めての顧客とDADについて議論していた際、DADはRUPのアジャイル版なのか? という質問を受けた。ひと言でいえば、ノーである。DADは以下の図にあるように、複数の手法やプラクティスのハイブリッドで構成されたフレームワークである。ここには、スクラム、エクストリーム・プログラミング(XP)、アジャイル・データ&モデリング、そしてもちろん統一プロセス(UP)も含まれる。DADにはまた、これらの手法では示されていない、アジャイル・ガバナンスのような追加部分も含まれる。この図を見ていただければ分かるように、DADに最も大きく寄与しているのは、UPではなく、おそらくXPだろう。

hybrid-of-methods11

ラショナル統一プロセス(RUP)は、主に反復的なライフサイクルでのソフトウェア構築を想定し、扱いやすい小さなプロセスフレームワークとして始まった。しかしその後、ラショナル(そして後にはIBM)は、パッケージ実装、保守プロジェクト、J2EEや.Netのような技術特化のガイド、システムエンジニアリングなど、あらゆる種類のプロジェクトにRUPの適用可能性を拡張するべく、付加的なガイドや成果物を徐々に追加していった。結果として、重すぎて扱いづらく、正しく理解して適用するのが難しいプロセスとなってしまった。事実、RUPはしばしば間違って使用される(例えば、推敲フェーズがBRUF – “最初にまとめて要求定義する” フェーズとして扱われる)。このような誤った使い方を、Julian HolmesはRINO(名ばかりRUP)と言っている。誤解のないように言っておくと、RUPは正しい環境で適切に適用されればとても効果的だ。しかし、不幸なことに、その逆のことが頻繁に発生している。RUPフレームワークをさまざまなタイプのプロジェクトに適用する際の問題のひとつは、それが「ユースケース駆動」のアプローチとして示されることだ。要件をユースケースとして記述し、それらのユースケース実現からコンポーネントベースのアーキテクチャーを作成していくことは、RUPの基本である。これは、ユースケースを作ることがほとんど意味をなさない可能性のある保守プロジェクトやパッケージ実装では、大きな壁となる。

DADはユースケース駆動のアプローチを強いていないし、サービスやコンポーネントを構築する際に厳格にOOAD(オブジェクト指向分析設計)を適用することも主張していない。ユースケース駆動アプローチを適用することは可能だが、アジャイルに逆行するような包括的で詳細な要件定義につながる危険性は否定できない。我々はどちらかと言えば、皆さんのプロジェクトの状況下で道理にかなう範囲での、ユーザーストーリー駆動のアプローチをお勧めする。ユーザーストーリーも常に正しい選択とは限らない。もしかしたら皆さんは昔ながらのソフトウェア要件定義書(SRS)を要求されるような規制のある環境にいるかもしれない。重要なポイントは、皆さんが自身の置かれている状況に適応しなければならないということである。これが、ユーザーストーリーで構成されているスクラムのバックログではなく、(訳注:各項目をユーザーストーリーに限らない)作業項目一覧を、チームの作業の優先順位付けに使用するゆえんである。作業項目一覧を使うことで、バックログにあらゆる種類の作業を入れることができ、RUPやスクラムが理想的とするプロジェクト以外にも、多くの種類のプロジェクトにDADを適用することができるようになる。

DADはゴール駆動であり、成果物駆動ではない。特定の成果物やプラクティスも指定していない。むしろ、ライフサイクルのある時点で適用可能な代替手段を、それぞれのメリット・デメリットと共に提案するが、そのどれを選択するかは皆さんに任されている。

次の投稿では、統一プロセスのどの側面がDADに受け継がれたかということと、その理由を解説する。

オリジナル:Comparing DAD to the Rational Unified Process (RUP) – Part 1

Comparing DAD to the Rational Unified Process (RUP) – Part 1


 (翻訳 中佐藤麻記子)

 

Pocket

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

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

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

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

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

Pocket

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

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

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

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

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

(藤井智弘)

 

 

 

 

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/
 (翻訳 藤井智弘)
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/
 (翻訳 藤井智弘)
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/
 
(翻訳 藤井智弘)
Pocket