BT

InfoQ ホームページ アーティクル ロードマップによるアジャイルイニシアチブプランニング

ロードマップによるアジャイルイニシアチブプランニング

ブックマーク

キーポイント

  • Agile was created by software people to uncover better ways of developing software. It provides little guidance for managers on what they should do or how they should do it.
  • Common agile frameworks don't explain how the product manager gets a budget or development team; how they design the product and solution or how they integrate the initiative with the rest of the organisation and manage their expectations.
  • Most organisations have responded to this gap between management and Agile by staying with plan-driven waterfall and hybrid approaches that have a track record of going well over budget while delivering much less value than predicted.
  • Agile Roadmaps build a bridge between management and technical teams by adding product, project, architecture and UX planning to agile initiatives so that you can get the funding and support you need to deliver an initiative in an agile way.
  • Roadmaps allow you to plan initiatives in a fraction of the time and cost of predictive methods, which means that you can deliver benefits much sooner at a lower cost.

シチュエーション

ほとんどの組織は、プロジェクトを用いてイニシアチブを提供します。

Project Management Instituteは、世界中に少なくとも6600万人のプロジェクトマネージャがおり、内IT部門に少なくとも25%いると推定しています。これは、おそらく少なくとも1700万のITプロジェクトが同時に進行していることを意味します。

アジャイルコミュニティでは、プロジェクトから継続的に資金提供を受けるデリバリーチームに移行することについて多くの話し合いがありましたが、調査によると、大多数の組織が依然としてプロジェクトを通じてイニシアチブに資金を提供しています。2019年のGartnerの調査によると、89%の組織が新しいイニシアチブに従来の年間予算編成プロセスを使用しています。2018 Gartner Researchによると、多くの組織がプロダクト中心のモデルへの移行を望んでいますが、85%はまだプロジェクト中心のモデルを使用しています。

問題

ビジネスの期待に応えるプロジェクトはほとんどない

しばらくデジタル業界で働いてきた人なら誰でも、ソフトウェアイニシアチブの大部分、特に段階的なものは深刻な問題を抱えていることを知っています。Project Management Instituteの調査によると、プロジェクトの20%のみが目標と時間どおりに達成され、65%が呼び止められ、15%が失敗しました。Standish Groupによる調査でも同様の結果が示されています。

McKinseyとOxford大学の調査によると、大規模なITプロジェクトの平均45%が予算を超えて実行され、7%が長期にわたって実行され、予測よりも56%少ない価値を実現しています。

ほとんどの機能は使用されません

同時に、Standish Groupの社内製品に関する調査では、開発した製品機能の3分の1しか使用されていないことが示されています。標準的な調査は、Pendoによる最近の調査によってサポートされています。これは、顧客が典型的なクラウドソフトウェア製品の機能の80%を使用していないことを示しています。この調査は、ほとんどのデジタルイニシアチブへの取り組みの50%〜80%を浪費していることを示しています。

ほとんどのプロジェクトは大規模な事前計画に基づいています

PMI Researchによると、組織の70%が予測アプローチ (ウォーターフォール) またはハイブリッドアプローチ (ウォータースクラムフォール) を使用してプロジェクトを提供しています。Southern Denmark大学の研究でもアジャイルと従来の開発手法を使用する、ウォータースクラムフォールは現実的ですか?にあるように同じことがわかりました。

ウォータースクラムフォール (Hybrid Agile) は、構築およびその他のいくつかの段階がスプリントで行われる従来の予測プロジェクト管理です。

私の経験では、この「ハイブリッドアジャイル」または反復アプローチは、多くの競合、混乱、および変更要求を作りだし、その結果、従来の段階的な開発プロセスと同じかそれ以上に悪い結果をもたらします。Disciplined Agileコンソーシアムによる調査では、反復 (ハイブリッド) チームは従来のチームよりも失敗する可能性が高く、アジャイルまたは継続的デリバリーチームよりも成功率が低いことが示されています。

ウォーターフォール開発モデルは建設業界で始まったもので、開発プロセスの早い段階で設計変更が法外に高額になりました。ソフトウェア開発業界のプロジェクトマネージャは、知識ベースの創造的な仕事には別のアプローチが存在する、または必要があることを認識していなかったため、最初からこのアプローチを適用してきました。

ウォーターフォールまたはウォータースクラムフォールのアプローチを使用する組織は、時間の半分と労力の3分の1 (したがって予算) を費やして、詳細な計画、要件、設計を事前に開発します。Phase Distribution of Software Development Effort, 2008をご覧ください。

組織は、イニシアチブを開始する前にいくらかかるか知りたいため、ウォーターフォールまたはウォータースクラムフォールのアプローチを使用します。要求や設計段階で問題を修正する方が開発や運用よりも50倍から200倍安いので、多くの時間とお金をかけて事前設計に費やす価値があると支持者は主張します。

組織はまた、組織全体の活動を統合および制御するために、財務、製品、プロジェクト、調達、およびリソース管理計画を策定する必要があります。アジャイルメソッドは、これを行う方法に関するガイダンスをほとんど提供しません。

大きな事前設計は多くの問題を引き起こします

大きな設計を行い、多くの仮定を事前にテストすることなく、事前に計画を立てるプロジェクト。これらのプロジェクトは、テストするまでソリューション設計が機能するかどうかがわかりません、また、製品をデプロイするまで要件が正しいかどうかわかりません。テスト中に、プロジェクトチームはいつも、彼らが行った多くの仮定が間違っているか変更されていることを発見します。これは、非常にコストがかかり、変更がとても遅くなることにつながります。

実は、環境、スコープ、優先順位が変化し、要件とソリューションがどうあるべきかを学習するにつれて、設計と計画は腐敗するということです。詳細な計画は急速に腐敗し、アーキテクチャと戦略はよりゆっくりと腐敗します。

変化のコストはアジャイルプロジェクトではるかに低くなります

アジャイルフレームワークは、フィードバックループの長さを数年から数日および数分に短縮することにより、変更のコストを削減するようにゼロから設計されています。

アジャイルの変更コストは低いので、利害関係者はプロジェクトの生涯を通じてプロジェクトのコストをより詳細に制御できます。 アジャイルを使用すると、組織はプロジェクトの範囲と設計を変更して、可能な時間と予算内で可能な限りの最大の価値を提供できることを知っているため、事前設計と計画をウォーターフォールプロジェクトのごく一部に減らすことができます。

イニシアチブロードマップ

計画は価値がありませんが、計画がすべてです。Dwight D. Eisenhower大統領。

計画は、目標、戦略、および必要なリソースの期待値を設定するため重要です。それらはイニシアチブに対する組織の支出を正当化します。これにより、途中で発生する可能性のある問題を検討し、それらを回避する方法を開発することができます。計画は、経営陣と開発チームの間に架け橋を築きます。計画を立てることで、さまざまな事態に備えて成功の可能性を高めることができます。計画を立てることで、目標を達成するために必要な取り組みとリソースを得ることができます。計画がなければ、成功するために必要な資金やリソースが他の人から与えられることはまずありません。

イニシアチブロードマップ

ここ数年、私はイニシアチブのロードマッププロセスを開発および改良して、イニシアチブを数か月または数年ではなく数週間で定義、設計、および計画できるようにしました。イニシアチブロードマップでは、目標、戦略、方向性を大まかな計画に設定し、デリバリーチームの構築に必要な資金とサポートを得ることができるようにします。開発チームが開始すると、ビジネスのステークホルダーと共に計画を発展させて、利用可能な時間と予算内で可能な限り最大のビジネス価値を提供します。

イニシアチブロードマップは、デジタル製品またはサービスの開発のためのリソースを取得する必要があるすべての人に役立ちます。一般管理者、製品管理者、営業、マーケティング、アカウント管理者、プロジェクト管理者、分析者、企業の設計とソフトウェア開発者、コンサルタント、デジタルエージェンシー、またはサービスプロバイダの人々に役立ちます。

イニシアチブロードマップを使用して、次のことを行いました:

  • 自動車メーカの新しいeコマースサイトを計画し、ディーラーに行く前にユーザが車をカスタマイズして価格を設定できるようにします
  • 企業顧客向けのTelcoセルフサービス携帯電話注文および管理ポータルの速度とパフォーマンスを向上させます
  • Telcoが銀行やその他の企業顧客に提供するセルフサービスネットワーク管理ポータルを強化します
  • 健康保険会社のコールセンターのスタッフとナレッジマネジメントウェブサイトの設計と計画
  • 旅行会社の新しい旅行ウェブサイトの設計と計画

始める前に

問題を理解する

イニシアチブロードマップは、既知の問題を解決するための計画を立てるのに役立ちます。解決すべき問題や質問すべき質問がわからない場合は、解決すべき適切な問題を見つける必要があります。これを行うために、私たちは要約をとり、要約を質問し、仮説を立て、研究を計画し、実施します。

研究は、定性的または定量的、行動的または態度的である可能性があります。定性的調査には、インタビュー、ユーザビリティ調査、ビジネスプロセスマップが含まれる場合があります。定量的調査には、ビジネスプロセス、顧客、製品データの分析が含まれます。ほとんどのイニシアチブは、複数の研究方法からの洞察を組み合わせることから利益を得ます。

ディスカバリーの目的は、「どうすればよいのか」というステートメントに要約されている明確なビジネス課題を取得することです。私たちがどのようにステートメントを発表するかは、性格、目標、および方向性を備えた短く覚えやすいものでなければなりません。コンテキストを知らせるのに十分な狭さで、さまざまなアプローチを探求する余地を与えるのに十分な幅でなければなりません。

新しい郊外の建設について話している場合、課題は次のとおりです:

「最初の住宅所有者、若い家族や退職者に新しい郊外に手頃な価格の質の高い家を一日も早く提供するにはどうすればよいでしょうか?」

計画を立てるための資金とコミットメントを得る

イニシアチブロードマップの開発を始める前に、計画を行うための資金とリソースを入手する必要があります。ほとんどの場合、スポンサーは経営者向けのプレゼンテーションを作成し、ビジネス上の問題とは何か、そして組織がそれを解決するための計画を立てるために数週間リソースを投入する理由を説明します。一部の組織では、スポンサーに正式なプロジェクト開始プロセスを実行するよう要求する場合があります。ロードマップはイニシアチブの詳細なビジネスケースを作成するため、イニシアチブロードマップを開始する前にビジネスケースを実行する必要はありません。

イニシアチブロードマップは、重要な取り組みと迅速な意思決定を必要とする激しいプロセスです。イニシアチブロードマップを開始する前に、参加者を予約し、プロセスにコミットするようにしてもらう必要があります。

イニシアチブロードマップとは何ですか?

イニシアチブのロードマップは、あなたがどこに行こうとしているのか、そしてどのようにそこに到達しようとしているのかを定義しています。チーム、予算、時間、必要なリソースについて説明しています。イニシアチブロードマップは、製品計画、UXデザイン、テクニカルアーキテクチャ、イニシアチブ計画を実行可能な戦略に統合して、ステークホルダーの期待に応えます。ロードマップは、上級のステークホルダーと関連する専門家を結び付け、新製品を迅速に設計および計画して、開発に必要な資金とリソースを確保できるようにします。

ロードマップは、最終製品計画、ユーザエクスペリエンス、システムアーキテクチャ、およびプロジェクト計画の最終段階についてのものです。これらは、マルチステッププロセスとマルチシステムデータフローを定義します。ロードマップは、スプリントで行われる詳細設計のコンテキスト、方向、および戦略をチームに提供します。

スクラムでは、バックログの詳細項目に対して行われた作業は「すぐに減し、頻繁に再見積する必要がある」と想定しているため、数週間先の計画は避けます。製品、UX、アーキテクチャ、およびプロジェクトロードマップは、スクラムのプロダクトバックログを教え統合するための全体像を提供します。

イニシアチブロードマップでは、技術とUXアーキテクチャ、設計、および計画を適切なタイミングで行うことで、遅延と無駄を回避することを目指しています。これを達成するために、次の12か月の高レベルの製品とイニシアチブロードマップ、今後3〜6か月のUXとアーキテクチャのロードマップとモデル、次の2〜4週間の詳細な設計を作成します。私たちの目標は、これらの計画を毎日、すべてのスプリントで見直し、改訂することです。プログラムとチームが学習するにつれて、ロードマップとモデルを変更します。

イニシアチブロードマップは、予算の3分の1、時間の半分を費やす、従来の段階的な分析、設計、計画プロセスの代替手段です。イニシアチブロードマップは、従来のプロジェクトとハイブリッドアジャイルプロジェクトの設計スプリント、ビジネスケース、プロジェクト計画、詳細なビジネスケース、ビジネス要件フェーズ、ソリューションアーキテクチャフェーズ、UX設計フェーズ、技術設計フェーズを置き換えます。

先にさらに計画を立てる必要がある理由

私の経験では、今後数週間のストーリーの計画にのみ焦点を当てているチームは、小さな機能にはうまく機能するが、製品の他の領域に適用するとうまく機能しない狭いソリューションを生成します。したがって、Webサイト用に一貫性のある再利用可能なUIスタイルを開発する代わりに、各開発者は作業しているコンポーネントのUIスタイルのバージョンを作成します。これにより、切断され断片化されたソリューションになり、多くの重複した作業が発生します。

ローカル最適化は組織を悩ませ、AI研究では特に一般的です。小さなステップで前進するチームは、全体的に最適ではないローカル最適に簡単に引っかかる可能性があります。対照的に、全体像を見るグループは、ローカル最適化からグローバル最適化までをより簡単に見ることができます。

イニシアチブロードマップを使用すると、より高度なロードマップを作成できます。これにより、先を見通すことができるため、ローカル最適化にとらわれることなく、最適なソリューションに簡単に到達できます。

参照先: Ayoosh Kathuria氏、ディープラーニングの最適化の概要

ロードマップの設計

経験によると、モデルをスケッチしてプロトタイプを開発するために集まる少数の賢い人々は、2週間で70%から80%正しい実行可能なソリューション設計を定義できます。これは、パレートの原則の例で、20%の労力で80%の利益が得られます。その後、チームは数か月以内に試行錯誤を繰り返し、95%正しいものに反復できます。

参照先 Scott Ambler氏: ほんの少しだけの十分なモデルとドキュメント

参照先 Scott Ambler氏: アーキテクトがアジャイルチームにどのように適合するか

成果物

イニシアチブロードマップでは、次のことを定義します。

  • ビジネス上の問題
  • 目標と主な結果
  • カスタマーエクスペリエンスロードマップ
  • ソリューションアーキテクチャロードマップ
  • 価値、規模、依存関係を優先した製品ロードマップ
  • イニシアチブのリスクと問題
  • イニシアチブの予算とリソース計画

従来のプロジェクトでは、これらの各成果物は、詳細な包括的なモデル、スプレッドシート、プロトタイプを含む80〜100ページのドキュメントで、開発に6週間、レビューに2週間かかります。私たちはそれをしません。

アジャイルロードマップでは、各成果物は2〜3ページのテキストで、1〜2枚のスライドで示され、記録、モデル、プロトタイプ、およびスプレッドシートを通じて示されます。目的は、チームが実行可能な戦略と合理的な時間とコストの見積を定義する計画を作成できるようにするために十分な詳細を提供することです。

カスタマエクスペリエンスロードマップは、グラフィックデザインをテストするための1つまたは2つのカラーモックアップとの重要な相互作用の白黒のワイヤーフレームで示される、エンドツーエンドのプロセスフローをマッピングします。完成したアート、実際のコード、またはすべてのユーザインターフェイスの包括的な青写真は提供されません。

ソリューションアーキテクチャロードマップは、データを一方の端からもう一方の端に渡して、主要な技術コンポーネントが私たちの環境でどのように機能するかを示す簡単なプロトタイプになります。これは完全で詳細な技術設計ではなく、本番用のコードは提供されません。

さまざまなイニシアチブの例を以下に示します。

イニシアチブロードマップをどのように開発しますか?

熟練したファシリテーターが率いる経験豊富なチームは、2週間でイニシアチブロードマップを作成できます。ロードマップ計画の初日には、アプローチを説明し、目的を設定し、カスタマジャーニーと機能ロードマップを決定し、設計および技術概要を作成します。次に、製品、ユーザエクスペリエンス、技術アーキテクチャを同時に設計します。ロードマップ計画の最後に、すべてをまとめて、機能の見積り、優先順位付け、予算の作成、および調査結果の文書化を行います。

活動内容

主な活動:

  • 課題を定義し、アプローチについて話し合います
  • ビジネス目標と期待される主要な結果を定義します
  • カスタマのペルソナを定義します
  • カスタマジャーニーを定義します
  • 製品の機能マップを定義します
  • サービスブループリントを定義します
  • 現在の技術環境を定義します
  • UXスケッチ
  • テストのためにカスタマを募集します/li>
  • アーキテクチャソリューションモデルを開発します
  • 技術的なPOCを定義します
  • UC POCを定義します
  • 製品の機能を定義します
  • UXワイヤーフレームを開発します
  • 技術的なPOCを開発します
  • ブランドガイドラインを定義します
  • イニシアチブのリスクと問題を定義します
  • ムードボードを開発します
  • UXおよびソリューションモデルをレビューし、製品の機能と統合します
  • インタビュースクリプトを作成します
  • カスタマとのUXテストを実施します
  • アーキテクトとテクニカルソリューションをレビューします
  • UXの調査結果をレビューします
  • 特定された機能をレビューします
  • 機能の価値と規模、チームの速度を見積ります
  • 優先リリース計画を作成します
  • 予算とリソースの計画を立てます
  • リスクと問題をブレインストーミングします
  • 配信方法を定義します
  • 結果を詳細なビジネスケースとして記述します
  • UX、アーキテクチャ、およびデリバリー計画をステークホルダーとともにレビューします

計画チーム

私の経験では、イニシアチブロードマップは6〜12人のチームで最適に機能します。プロセスを実行する3〜6人、方向性を提供し、知識を共有し、意思決定を行う3〜6人。この製品のデリバリーチームがすでにある場合は、そのチームが専門家の助けを借りて計画を行う必要があります。製品デリバリーチームがいない場合や、まだイニシアチブを設定していない場合は、イニシアチブを進めると予想される人をまとめてください。

イニシアチブロードマップでは、チーム全体に約70日間の作業があると思います。計画チームには、ファシリテーター、デザイナ、アーキテクト、ビジネスリーダ、ビジネスエキスパート、テクニカルエキスパート、プロジェクトマネージャを含める必要があります。フルタイムで対応できない場合は、これらの各役割を2人で分割できます。たとえば、スポンサーは、50時間参加するチームのプロダクトマネージャ/プロダクトオーナのサポートを得て、30時間参加できます。また、UX/UIデザインの役割は、UXデザイナとUIデザイナの間で分割できます。

役割 (Role)

工数 (時) (Hours Effort)

ファシリテータ / アジャイルコーチ / ビジネスアナリスト

80

UX / UI デザイナ

80

ソニューションアーキテクト / Dev リード

80

スポンサ / ビジネス部門マネージャ / プロダクトマネージャ / プロダクトオーナ

80

内容領域専門家

80

テクニカルドメインエキスパート / エンタープライズアーキテクト / インテグレーションデベロッパ

80

イニシアティブマネージャ / ビジネスアナリスト / ドキュメンタ

80

避けるべき落とし穴

従来のマネージャは、従来の段階的な計画プロセスで使用されているすべての成果物を要求することにより、アジャイルロードマップを誤って妨害する可能性があります。たとえば、彼らは次の詳細を主張するかもしれません:

  • ビジネス要件文書
  • ソリューションアーキテクチャドキュメント
  • 技術仕様書
  • すべてのページのワイヤーフレームとアートアセットが完成したUIデザインドキュメント
  • ガントチャートを使用したプロジェクト計画

従来のマネージャは、ロードマップで定義されたすべてを変更なしで提供するために、イニシアチブロードマップを固定範囲、固定価格契約に変えようとする場合もあります。

これらの問題に対処するには、従来のマネージャーを計画プロセスに参加させ、ワークショップで時間を使って、固定価格、固定費、アジャイルチームによる可変スコープの提供について人々に教え、成果物を説明します。

また、ワークショップをスキップしたり、ラップトップや電話でワークショップに時間を費やしたりする人にも問題があるかもしれません。進行役は、この行動をスポンサーと計画チームの注意を引き、影響を説明し、グループに彼らがそれに対して何をすべきかを尋ねる必要があります。

ロードマップの後に何が起こるか

計画チームがイニシアチブロードマップを作成した後、スポンサーはそれを使用して、製品デリバリーの資金を要求できます。または、計画が高すぎると判断し、問題を解決するためのより安価な方法を見つける必要があります。

イニシアチブロードマップは、変更なしで提供する必要がある固定スコープを作成する1回限りのイベントではありません。イニシアチブロードマップは、プロジェクトのライフサイクル全体にわたるすべてのレベルで継続的なレビューと再計画を経て進化する、生きた計画です。次のレベルでは、継続的な開発、統合、展開に至るまで、スプリント計画、そして受け入れテストがあります。チームは、ロードマップの仮定の1つが間違っていることを発見した場合、利用可能な時間と予算内でビジネス価値を最大化するように計画を変更します。それは計画主導ではなく、適応的で進化的です。

イニシアチブロードマップのスケーリング

イニシアチブロードマップを使用して、3か月から6か月で実行できる大きな作業の塊をマッピングし、各部分を独自のロードマップを使用して個別のイニシアチブとして計画することにより、大規模なプログラムを計画できます。Standish Groupの調査によると、小さなプロジェクトは大きなプロジェクトよりも成功する可能性がはるかに高いため、大規模なプログラムを小さな部分に分割することは常に良い考えです。

プログラムのスケーリング

一度に大規模なプログラムを開始するのではなく、1つのチームから始めて、期待される価値を提供できることを証明してから、それを2つのグループに分割し、有糸分裂のプロセスを通じて4つに分割することなどが最善です。

チームを分割して、チームごとに外部顧客または内部クライアントができるようにする必要があります。これらのチームの中には、顧客に直接価値を提供するものもあれば、ビジネス向けの製品チームをサポートするプラットフォームや機能を提供するものもあります。グループの独立性が高いほど、優れています。複雑な内部チーム間の依存関係は遅くなります。

プログラムを時間をかけて成長させることで、リスクが大幅に減少し、チーム全体で一貫した文化と戦略を構築できるようになります。

統合チーム

プログラムでは、統合チームが統合された製品、アーキテクチャ、UX、イニシアチブ、および次の6〜12か月の予算ロードマップを作成することにより、グループ間の相互依存関係を管理します。このチームには、プロダクトオーナ、イニシアチブマネージャ、アジャイルコーチ、ソリューションアーキテクト、UXデザイナ、および個々のグループの代表者がいます。統合チームは、Scrum Nexusで定義されたものと似ていますが、予算、リソース、アーキテクチャ、およびUX設計に重点を置いています。統合チームは、新しいイニシアチブのイニシアチブロードマップの開発を主導し、承認された場合に提供する担当者を確実に含めます。

利点

より速く計画し、より良い計画。

イニシアチブロードマップは、製品またはプロジェクトマネージャーが、新しいイニシアチブの製品計画、ソリューションアーキテクチャ、および資金調達を迅速かつ効果的に決定するために使用できるアプローチを定義します。この計画により、プロジェクトの予算とリソースを取得し、早期に開始し、より迅速に提供し、顧客満足度を高め、リスクを減らし、利益をより早く実現できます。

ロードマップでは、顧客をイニシアチブの中心に置いて、顧客のニーズを満たすソリューションを開発できるようにします。これにより、貴重な製品を時間と予算に合わせて迅速かつ効率的に提供するための現実的な計画を定義できます。そして彼らはあなたがあなたのサプライヤーから最高の結果を得たり、あなた自身でイニシアチブを開発したりできるようにあなたを開発プロセスの管理下に置きます。

イニシアチブロードマップにより、計画の時間とコストが50%以上削減され、利益をはるかに迅速に提供し、遅れをとったときに追いつくことができます。下のグラフは、中規模のWebサイトの再開発の計画を、通常行われることとアジャイル計画で起こり得ることと比較して示しています。アジャイルデリバリーと組み合わせたアジャイル計画を使用することでわかるように、通常は計画にかかる時間でイニシアチブを完了することができます。

私たちが協力した大手自動車会社のデジタルディレクターは、イニシアチブロードマップを実施することで12か月と数十万ドルを節約したと語っています。また、ヘルスファンドのナレッジマネジメントイニシアチブのスポンサーから、ウォータースクラムフォールアプローチでIT組織が過去12か月で達成したよりも2週間でさらに進んだことがわかりました。

私は過去7年間、多くの大小の組織のためのイニシアチブロードマップを開発し、発展させてきました。このアプローチを実装するための支援が必要な場合は、murray@ev0lve.coまでご連絡してください、実行します。

参考文献と謝辞

アジャイルイニシアチブロードマップは、リーン、アジャイル、スクラム、XP、アジャイルアーキテクチャ、UXデザイン、プロジェクト管理コミュニティのさまざまな思想家のアイデアを利用しています。エクストリームプログラミングの計画はKent Beck氏とMartin Fowler氏、アジャイルの見積りと計画はMike Cohn氏、ストーリーマッピングはJeff Patton氏、アジャイルアーキテクチャはScott Ambler氏、リーンアジャイル製品開発はEric Reiss氏、デザインスプリントはJake Knapp氏、リーンUXのJeff Gothelf氏と、スクラムとカンバンのHenrik Kniberg氏が塹壕に入っています。

2004年にアジャイルXPを紹介してくれたDean Netherton氏、2009年にTelstraでアジャイル計画アプローチの開発を手伝ってくれたBen Scown氏、2016年にデザインスプリントを紹介してくれたDavid Cox氏に感謝します。また、この記事を確認してフィードバックを提供した多くの人々にも感謝したいと思います。

ここで説明する計画アプローチが、次のデジタルイニシアチブを開始および計画するためのより良い方法を提供してくれることを願っています。

著者について

Ev0lve 修士 Murray Robinson氏は、組織と協力してデジタルイニシアチブを設計し、それを実現できる組織をデザインする。彼はソフトウェア開発者としてITで30年の経験があり、デジタルは20、製品とプロジェクト管理は20、アジャイルは16、UXは3である。デジタルイニシアチブの計画と実行について詳しく知りたい場合は、murray@ev0lve.coに連絡してください。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。