作成者別アーカイブ: 中佐藤麻記子

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

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とラショナル統一プロセス(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