アジャイルプロジェクト管理の究極の紹介

ブリーフ

あなたは、「WidgetsInternational」の顔を永遠に変えることになるあなたの会社の最新かつ最大のイニシアチブを提供する責任があります。 これは、顧客を引き付けて魅了し、同僚の生活を楽にし、会社の収益を数百万にするソフトウェアプロジェクトです。 たくさんの期待、熱意、興奮、そして期待があります。 あなたのビジネスが利益を享受し始めることができるように、あなたはそれをできるだけ早く終わらせる必要があります。 会社の将来の成功はあなた次第です。 すべての目があなたに向けられています。 失敗することはできません。

最初、あなたは自分自身に考えています。 このことを成し遂げましょう！」 少し立ち止まって、一歩下がって、「さて、どうやってこれを行うのか」と考えます。 あなたは同僚や仲間と話し始めます。 あなたはベストプラクティスのソフトウェア開発とプロジェクト管理技術を探すことに時間を費やしていますが、選択肢とアプローチは無数にあります。 頭字語と方法論がたくさんあります。 注目すべきものがトップに上がります。 疑いが忍び寄る。どちらを使うべきか？ どうすれば成功を保証できますか？ 間違った決定をした場合はどうなりますか？

ソフトウェアプロジェクトの管理に関しては、無数の意見に裏付けられたさまざまなオプションがあります。 部屋の隅からの声がささやきます、「このようにしてみてください」。 他の人は「これがそれをする唯一の方法です」と叫びます。 残りの部分は、「それをまったく管理しないで、ただそれを続けてください」と呟きます。 実際には、それらすべての声はいくつかの真実を話します。 しかし、重要なのは、あなたのニーズ、あなたのチーム、あなたのビジネス、そしてあなたの顧客にとって何が正しいかを理解することです。

シーンの設定

ソフトウェアプロジェクト管理が3つの陣営のうちの1つに正直に座っていた時期がありました。 制御とガバナンスを維持するための構造を提供しながら、実行と提供の方法を決定できる重いフレームワークがありました。 ウォーターフォールのような規範的なシーケンシャルな方法論があり、長いプロジェクトを計画し、すべての要件を理解してコミットし、複雑なシステムを設計してサインオフし、多くのコードを記述してからテストする必要がありました（すべて、顧客が最初にそれを見る前に）時間）。 そして最後に、ラピッドプロトタイピングまたはより大規模なシステムを段階的に設計、構築、および提供することを促進する、それほど規範的ではないが反復的なソフトウェア開発ライフサイクル（SDLC）であり、それぞれが互いに重なり合っています。

アジャイルソフトウェア開発とアジャイルプロジェクト管理は、ウォーターフォールの不十分さとソフトウェア配信への反復アプローチの利点から生まれました。 彼らのルーツは1950年代、70年代のソートリーダーシップ、90年代の成熟、そして00年代までの採用にまでさかのぼることができます。 2001年に、実践者と専門家のグループがアジャイルマニフェストを作成しました。これは、アジャイルソフトウェア開発の精神を具現化し、その進化を促進することを目的とした4つの価値観と12の指針を定義することを目的としています。 そしてそれは間違いなく進化しました。

さて、単にアジャイルと呼ぶことは特に役に立ちません。 この言葉は、ソフトウェアの文脈でも、人や組織によって意味が異なります。 多くの側面、定義、実装、および解釈があります。 アジャイルを採用する各ボディは、独自の定義を与えようとする傾向があります。

アジャイルソフトウェア開発とプロジェクト管理は、関連する動作、フレームワーク、手法、および概念のグループであり、適切に機能するソフトウェアをできるだけ早く、できるだけ頻繁に提供することを基本的に支持していると言えば十分です。

ソフトウェア開発やプロジェクト管理に適用されるアジャイルは、別のものになる可能性があることを先に述べました。 一言で言えば、アジャイルソフトウェア開発は、通常のビジネス（BAU）またはプロジェクトコンテキストで優れたソフトウェアを開発する役割を果たします。 一方、アジャイルプロジェクト管理は、ソフトウェアを含むがこれに限定されない複雑なプロジェクトを提供するために必要なガバナンスと制御を処理します。

スクラム、かんばん、XP、リーンソフトウェア開発など、利用可能な多くのアジャイルソフトウェア開発方法があります。 しかし、ラグビーのゲームがスクラム以上のものであるように、アジャイルもそうです。 単独では、これらのアジャイルパラダイムは、ガバナンス、リソース、財務、明示的なリスク管理、およびその他の多くの重要なプロジェクト管理の概念などの複雑なプロジェクトで必要とされるプロジェクト管理のライフサイクル全体に対応していません。 これらについては、PMIアジャイルまたはPRINCE2アジャイルを検討することをお勧めします。これを「ガバナンスされたアジャイル」と考えてください。

なぜアジャイルである必要があるのですか？

ずっと前に、私たちは生き残るために食べ物と避難所を集めるために土地を歩き回りました。 それらは単純なニーズでしたが、かなり機敏でした。 しばらくして、産業革命を背景に国や経済が成長し繁栄しました。 これが管理と制御の誕生であり、敏捷性の喪失でした。 今、私たちは情報化時代または革命の時代にあり、企業は知識労働者を雇用しています。 知識労働者は、顧客、ビジネス、社会、経済、および世界の問題に対する優れたソリューションの作成に努める、あなた、あなたのパートナー、およびあなたの同僚や仲間です。 知識労働者は、分析、知識、推論、理解、専門知識、およびスキルを、大まかに定義され変化するニーズに適用します。 これらの企業や労働者は、古い産業時代のプロセスや手順では満たすことができない方法や技術を必要としています。 アジャイルは相互作用をサポートします。

事実上、最初に自信を持って着手し、変更なしで価値のある実用的なソフトウェアを提供するために必要なすべてを知ることができるソフトウェアプロジェクトはありません。 変化は、プロジェクトの成功に機会とリスクの両方をもたらします。 管理されていない機会は、素晴らしい会社と素晴らしい会社の違いを意味する可能性があります。 管理されていないリスクは、災害と破滅を招きます。 アジャイルは変化を管理します。

アジャイルを採用すると、変化する要件や新しい要件に対応できます。 これにより、開発チームは専門家になり、熱心で信頼できる情報に基づいたビジネスに支えられた意思決定を行うことができます。 それはあなたが彼らが本当に欲しいものを顧客に届けることを可能にします。 最終的には、お客様と組織が、顧客のニーズと期待に応えながら、投資費用の見返りをできるだけ早く引き出す、高品質で価値のあるソフトウェアの提供を管理できるようになります。 アジャイルは価値を生み出します。

アジャイルを採用するにはコストがかかります。 無料ではありません。 ソフトウェア配信のためのアジャイルアプローチへの変換は、たどるのが難しい道である可能性があります。 ただし、アジャイル哲学を内面化し、慎重に踏み込み、適切なチームを適切な態度で関与させ、物事を分解し、達成可能で現実的なものにし、フィードバックに対応すれば、報酬を得ることができます。 アジャイルはコラボレーションを強調します。

以下に、期待できるいくつかの利点を示します。

• 市場投入までのスピード
• 早期の収益創出
• 真の価値の定期的な配達
• あなたの投資の保護
• データ、データ、データ
• より良い製品品質
• 管理可能な期待
• 顧客満足度の向上
• パフォーマンスの高いチーム
• 進行状況の可視性が向上
• 予測可能性、透明性、および信頼性
• 管理可能なリスク

成功は最終的なものではなく、失敗は致命的なものではありません。重要なのは継続する勇気です。

ウィンストン・チャーチルは実際にこれを言ったことがないかもしれませんが、それはアジャイルのかなり良い要約だと思います。 私たちは、アジャイルがほとんどのプロジェクトにとって最善の前進であることを知っています。 それはあなたが成功のために努力することを奨励しますが、私たちは常にそれを繰り返し、それを基に構築し続けます。 アジャイルはあなたが失敗することを奨励しますが、早く失敗して先に進みます。 継続し、顧客からの洞察に基づいて適切なソリューションを構築する勇気を持つことが、報酬をもたらします。

覚えておくべきことは、アジャイルをニーズに合わせて調整できるということです。 ビジネスに適した方法とガバナンスを使用してください。 どこから始めても、使用する方法の内容、コンテキスト、精神に忠実であり、バニラを維持します。 始めたばかりの場合は、を学びましょう。 しばらくやっているのなら、理解してください。 あなたが素晴らしくなっているなら、適用してください。 最後に、ビジネスとプロジェクトが複雑で相互依存している場合は、を管理します。 時間が経つにつれて、あなたとあなたのチームはあなたのビジネスに最適なものを見つけ出すでしょう。

実現可能性

だから今あなたは考えていますどうすれば始められますか？ どこから始めればいいですか？」 さて、すべての良いことで、私たちは最初から始めます。 そして、アジャイルでは、「どのようなビジネス価値を提供したいのか」と自問することによって実現します。 結局のところ、それが私たちがビジネス価値を生み出すためにプロジェクトに着手する理由です。 プロジェクトがビジネス価値を引き出すために着手する価値があるかどうかを確認するには、それが実行可能かどうかを理解する必要があります。

ヴィジョン

あなたのプロジェクトは、収益の増加、新しい市場への参入、より多くの顧客の獲得、顧客の認識の向上、または特定した特定の問題の生活を楽にすることを予測していますか？ これを念頭に置いて、あなたはあなたの「ビジョン」を述べることができます。

• あなたのビジョンは、一般的な問題を解決するための大胆なスタートアップ、ビジネス管理戦略、CEOのペットプロジェクト、特定の製品チーム、さらには顧客のニーズなど、さまざまなソースからもたらされる可能性があります。
• あなた自身の靴から一歩後退して、あなたの顧客の手にあなたの新しい製品またはサービスで未来がどのように見えるかを「見て」みてください。
• 利害関係者（CEO、製品担当者、顧客）を関与させます。 それをワークショップしてください、これを単独で試みないでください。 仮定に挑戦し、議論を検証します。
• それを書き留めて、短くしてください。 ビジネス価値に焦点を当てます。
• ビジョンがすべての人に共鳴し、どこに向かっているのかを示す一般的な解釈に出会うことに全員が同意するまで、それを改良します。
• あなたの視力は、有効であれば、めったに変わりません。 どのようにしてそこにたどり着くのかは間違いありません。

人々はあなたがしていることやあなたがそれをどのように行うかを購入しません。 彼らはあなたがそれをする「理由」を買います。 これはあなたのビジネスとあなたの顧客の間に感情的なつながりを作り出すものです。 ビジョンはこれを説明するのに役立ちます。

それは実行可能ですか？

実現可能性には、少なくとも2つの色合いがあります。 通常、ビジネスと顧客の明るい未来のビジョンが技術的に実現可能であるかどうか、そしてそれを実現することがビジネスにとって実現可能であるかどうかを理解する必要があります。

• 1時間以内に世界中のどこにでも旅行できるようにすることがビジョンである場合、技術的な実現可能性に問題がある可能性があります。 科学、物理学、技術はまだその夢に追いついていないので、あなたの技術的解決策は理論以外では実行できないかもしれません。 さらに、ソリューションが新しい場合、これは最小実行可能製品（MVP）の概念をはるかに超えます。

• 製品の技術的実現可能性をテストするには、Discoveryプロトタイププロジェクトでさらに調査するか、プロジェクトの初期段階でスパイクを実行することを検討してください。 考えているソリューションの規模や複雑さを考えることで、どの方法を使用するかがわかります。

  「私のチームが技術的な実現可能性を理解する上で得た最高の知識のいくつかは、スパイクを実行することから得られました。 そして、多くの場合、それが勝つ最も簡単なソリューションです！」

• 考慮すべき実現可能性の2番目の色合いは、あなた、あなたのチーム、またはあなたのビジネスがそれを機能させるためのスキルと動機を持っているかどうかです。 例を挙げて、あなたが子供の誕生日のために家でケーキを焼くのが得意なら、それは甘いです。 しかし、これを世界に最高のケーキを販売するビジネスに変えたいのであれば、それを拡大し、ビジネスと生産を処理し、流通と履行を管理し、顧客サービスを管理できるかどうかを理解する必要があります。
• このタイプのビジョンは、長期的には達成可能かもしれません。 しかし、今のところ、おそらくそうではありません。 それで、それを縮小し、小さく考え、現実的に見える小さな塊を取り、あなたができる最高の小さな願望を提供することに集中してください。 それがなんとかあなたの顧客を引き付けて喜ばせることができたら、彼らにもっと戻ってきて彼らの友人に話してもらい、そしてあなたの顧客のフィードバックをあなたのガイドと羅針盤として使ってそこからそれを拡大してください。
• また、プロジェクトが予算と時間枠の観点から実行可能かどうかを知る必要があります。 あなたのビジネスはこのプロジェクトを提供する余裕がありますか？ 時間枠は達成可能ですか？ 時間とお金は、修正されたアジャイルプロジェクトの3つの制約のうちの2つです。 一定の時間内、一定の予算内で納品することを目指しています。
• 製品の品質とは、顧客が使用する最終製品と、チームが優れた堅牢で信頼性の高いソフトウェアを提供するために使用するエンジニアリング手法を指します。 品質も私たちが短期間で変更しないものです。 一方、品質基準は変更される可能性があります。 あなたがフェラーリを作ることに着手していないならば、製品は高品質の知覚を持っていないかもしれません。 宇宙ロケットを製造していない場合は、生産面で達成される許容誤差がはるかに高くなる可能性があります。 早い段階で適切なトーンと期待を設定します。

だから今、あなたはあなたの夢がチョコレートの空想以上のものであることを確認し、あなたの仮定をテストし、この努力が投資する価値があることを人々に証明することに着手しました。

正当化

さて、あなたの状況に応じて、正当化はさまざまな形でやってくるでしょう。 しかし、基本的には、このプロジェクトが顧客の成功基準を満たし、成功の可能性があり、価値を提供し、手頃な価格であることを証明する必要があります。

• 顧客のニーズに基づいて仮定を述べ、それを検証します。 リーンスタートアップは、製品が顧客に必要であり、価値を生み出すことを特定して証明するための優れたガイダンスを提供します。

• ビジネスプランを作成、テスト、検証します。 今、これはあなたの銀行やあなたのビジネスと金融の専攻があなたに生産するように言ったもののようには見えません。 それらは使用しないでください。インクが乾く前に古くなります。 代わりに、ビジネスモデルキャンバスをチェックしてください。 これは基本的に、価値提案、顧客、収益、およびコストに焦点を合わせ続ける短い形式のビジネスプランです。 あなたがうまくいくビジネスを持っているかどうかを検証するためにそれを使用してください。

  「私はこのアドバイスを一度無視し、長い伝統的な50ページのビジネスプランを書くのに長い時間を費やしました。 それは私をどこにも連れて行かなかった。 私が行ったすべての仮定は根拠がなく、私が行ったすべての予測は検証できませんでした。 二度とやらないように教えてくれたのは、苦痛で費用のかかる経験でした。」

• プロジェクトのポートフォリオが複雑な環境で提供されている成熟したビジネスをしている場合は、財務モデリングが必要になる場合があります。 必要な場合は、上記を証明した後でのみこれを行ってください。
• MVPを作成すると、従来のビジネスプランを作成する場合があります。たとえば、競合するプロジェクトやリソースの会社のポートフォリオ内で資金調達や選択を行う必要がある場合などです。 ただし、これは、上記で使用したツールに基づいて通知されたビジネスプランになります。 軽くなります。
• いずれにせよ、これらのツールを生きた呼吸のアーティファクトとして使用してください。 あなたのガイドとしてそして鐘としてそれらを使用してください。 それらは決して静的ではありません。 それらを参照し、プロジェクトまたはビジネスの発展に合わせて修正してください。

正当な理由があり、すべての利害関係者が参加すると、火がつきます。

実現可能性フェーズは通常、プロジェクトの存続期間中に1回実行されます。 特にデータ、顧客、市場、またはビジネスがそのように示している場合は、プロジェクトのビジョンと実現可能性を再検討することに気付くかもしれません。 少なくとも、それらは全体を通してあなたのガイドライトになります。

印心

素晴らしい。 決定が下され、プロジェクトは青信号になり、構築する準備が整いました。 まあ、ほぼ。 私はあなたが考えていることを知っています。 私たちが今これをしなければ、私たちは決してそうしません。 このショーを外出先で手に入れましょう！」 しかし、これを考慮してください。アジャイルは、顧客を喜ばせながら、早期に、そして頻繁に価値を提供することではないにしても、何の意味もありません。 プロジェクトを実現するための最良の方法を見つけるために時間をかけることは、成功のための最良の基盤です。

チーム

スポーツでは、お気に入りのチームゲームについて考えることで、チームがそのように実行できるようにする重要な役割を認識することができます。 伝統的に、あなたはマネージャー、キャプテン、そしてチームの残りの部分を見つけるでしょう。 それ以外にも、コーチ、理学療法士、栄養士、そしてさまざまなサポートスタッフがいます。 しかし、ラグビーの試合を見ると、チーム内にチームがあります。それは、スクラムを構成するプレーヤーです。 このパックは、ボールを取り戻してプレーを続けることを仕事とする指定選手で構成されています。 スクラムが行われているときは、各サイドのプレーヤーがリーダーなしで、ボールを取り戻すために可能な限り協力的、コミュニケーション的、効率的に単一のユニットとして作業します。 ジェフ・サザーランドが彼のソフトウェア開発方法論を「スクラム」と名付けたのは、ラグビーのゲームです。

• アジャイルプレイブックのソフトウェア開発方法はスクラムだけではありません。 しかし、それは、チームとして働き、個人をやる気にさせ、信頼関係を築き、自己組織化、使用人のリーダーシップ、コミュニケーション、透明性、およびコラボレーションのアジャイルの概念と行動を最もよく表すものです。
• あなたのチームは、主にあなたが自分自身を見つけた状況によって形成されます。あなたはあなたに利用可能な開発者を持っているかもしれません。 それらの一部、なし、またはすべてが、さまざまな程度でアジャイルに精通している可能性があります。 新しいチームを雇ったり、サードパーティとパートナーを組んだりすることをお勧めします。
• 他の役割も必要になりますが、それらについては後で説明します。
• あなたがあなたの開発チームを形成するなら、あなたはあなたの技術を選んだと言われています。 チームをどこから集めるかに応じて、特定のスキルセットが付属します。 したがって、開発チームをどのように形成するか、そして旅のこの時点に到達する前に技術評価を実行する必要があるかどうかを慎重に検討してください。
• これにより、部門の枠を超えたチームになります。 チームは、肩書きに関係なく、個人が仕事を成し遂げるために参加するときに、一緒に仕事をするときに最もよく機能します。 自給自足のチームと複数の役割を担う個人を構築するようにしてください。
• 環境、文化、および関係の中心を構築します。これは、チームが制約や制限に邪魔されることなく提供できる場所です。 チームに、効果的でパフォーマンスの高いツール、人、リソース、およびスペースを提供します。
• チームのサイズを7または8以下に保ちます。 さらに多くの開発者が必要な場合は、チームを複数の新しいチームに分割します。 その後、各チームが特定の機能領域を担当する場合があります。 複数の場所に複数のチームがある場合は、スクラムオブスクラムを開催することを検討してください。 そして、これらが複雑な環境で多数ある場合は、アジャイルプロジェクト管理を使用してください。
• チーム、ビジネス、利害関係者、さらには顧客が互いにアクセスできるようにします。 彼らがコミュニケーションとコラボレーションを行うことを確認し、進行の邪魔になるものをすべて取り除きます。 毎日のコミュニケーションは、プロジェクトの病気の最善の治療法です。 人々が話すとき、彼らは物事を成し遂げます。

チームをまとめてソフトウェアを提供する方法はたくさんあります。

プロジェクト概要説明書

実現可能性のステップでは、プロジェクトの「理由」を理解し、スタートアップを前進させる自信を築くか、または後戻りして続行します。 プロジェクトブリーフは、「なぜ」と「何」、「いつ」、「誰」をまとめた生きたドキュメントです。 あなたが進歩するにつれて、あなたの知識、理解、そして道が変わるかもしれないので、それは「生きている」です。 この文書を一度書いたままにして、二度と戻らないということは、ある時点にあなたの考えを委ねるだけです。 アジャイルの世界では、ポイントインタイムの参照は毎週または毎日の早い段階で変更される可能性があるため、これを最新の状態に保つことが重要です。

• プロジェクトの概要をカプセル化して維持するための優れたツールは、ジョナサン・ラスムソンが著書「アジャイルサムライ」で「インセプションデッキ」と呼んでいるものです。 ここでは、プロジェクトに関心がある、影響を受けている、または関与しているすべての人が同じページにいることを確認するための優れたアドバイスを見つけることができます。
• プロジェクトを提供する上での最大の敵は、プロジェクトが何であるか、そしてどのような「要件」が満たされるべきかについて、不明確、一貫性のない、または単に異なる理解を持つことです。 重要な利害関係者が1人でも、あなたがしていることについて異なる理解や見方をしている場合、その結果は重大なものになる可能性があります。
• 優れたプロジェクト概要は次のことを伝えます。
  1. 利害関係者とチームメンバーの間で共通の合意された期待。
  2. プロジェクトの理解。すべての関係者が同じように理解している。
  3. 目標、ビジョン、目的、範囲、およびプロジェクトのコンテキスト。
• 実現可能性から収集された概要については、多くの優れた情報が得られます。 プロジェクトの概要は、質問の検索に対する答えを定義して見つけるのに役立ちます。 それは、利害関係者、あなたの存在意義、高レベルの範囲、リスク、ターゲットソリューション、予算、タイムライン、期待、および優先順位をまとめます。

ある同僚が廊下で私を止めて、プロジェクトの概要をどこで入手できるか尋ねました。 私は「ブリーフは必要ありません、私たちはアジャイルです」と装備しました。 彼は私の正気や権威に疑問を投げかけているように、混乱しているように見えました。 彼はそうするのが正しかった。

先に進む前に、全員が同じページにいることを確認し、ワークショップを行い、難しい質問をして、人々が立ち止まり、読んで、コメントし、修正できる場所に釘付けにします。

文化と働き方

あなたはあなたのビジネスがどのように機能するか、そしてその文化、それが物事を成し遂げるのが好きな方法を知っています。 アジャイルは、その性質上、ビジネスが長年にわたって培ってきたこれらの働き方のいくつかに挑戦する可能性があります。 アジャイルが実装され、誰もが最初からそれを愛情を込めて採用することを期待しないでください。 一部の人々はそれを混乱させ、恐れと恐れだけでそれを見るかもしれません。 一部の人々は公然とそれに従事することを拒否するかもしれません。 これらは、克服しなければならない課題と認識です。 しかし、初期の頃は、アジャイルスティックを振って、それを聞いていない人を殴打しないでください。 それは信頼、採用、または関与を構築しません。

私はかつて大きなことわざの棒を振るのが好きでした、そしてそれは私に多くの否定的な報道をもたらしました。 私はそれを好転させましたが、最初にかなりの痛みに苦しむ前ではありませんでした。

養子縁組の道を歩むときは、慎重に、敬意を持って、共感を持って踏み込んでください。 あなたがきしむような古い伝統的なビジネスをしているなら、おそらくそれはビジネス全体を調整するための最良のアプローチではないでしょう。 小さなことから始めて、徐々に尊敬と認識を獲得してください。 チームのみから始めます。 これまで以上に高品質でより迅速なソフトウェアの提供を開始すると、人々は気づき始め、ゲームをプレイしたいと思うようになります。 彼らがそうするとき、彼らにボールを提供して、彼らをコーヒーのために取り出して、あなたの新しい世界に彼らを楽にしてください。 彼らを助ける。

あなたのチームと一緒に、彼らがプロジェクトの内容を理解し、アジャイル採用の計画が合意されたので、チームがチームとしてどのように行動し、運営したいかを決定させます。

• チームを導き、集合的なニーズに合っていると感じるアジャイルの概念、手法、動作、およびフレームワークを特定します。
• チームメンバーから、可能な限り最高のパフォーマンスを発揮するために必要な要件についてリクエストを受け取ります。 これらのリクエストの一部は、すぐに解決できるようになります。 他の人は、あなたは予算や外部の助けを得る必要があるかもしれません。 それを実現するためにできることをしてください。
• これらは、真の使用人リーダーになるための最初のステップです。
• チームが採用することを選択している概念と手法について、適切なトレーニングを編成することを検討してください。 これは、すべてのチームメンバー、さらには利害関係者が同じページにいて、同じメッセージを受け取るようにするための最良の方法です。 ニーズに合わせて製品を調整できるサプライヤー組織と協力してください。
• 慎重に。 アジャイルになる方法を学ぶワークショップで数日後、誰もアジャイル忍者にはなりません。 あなたの道は長くなります。 「なる」という言葉は非常に明確です。 あなたが本当にアジャイルを受け入れるときだけ、あなたはその価値を見るでしょう。 それはあなたを興奮させるはずです。 それがあなたを興奮させるなら、他の人も興奮させてください。
• チームが概念と手法に同意し、彼らの願いが叶い、アジャイルトレーニングを行っているので、チームの注意を自分自身と、あなた、ビジネス、そしてお互いに期待するものに向けます。
• チーム内およびチームによる作業方法（WoW）を定義すると、信頼、関係、期待を構築するのに役立ちます。 うわーは戦争と平和ではありません。 それは短く、要点まで、7から10の箇条書きの文章でなければなりません。 これらの文章は、人々がどのように行動し、コミュニケーションし、協力し、支援し、提供し、そして一緒に行動するかを明確に述べています。 また、チームがビジネスに何を期待しているかも記載する必要があります。

• アジャイルは、原則や概念を導くのと同じくらい考え方です。 それはあなたが行動し、考え、交渉し、相互作用し、コミュニケーションし、実行し、そして改善する方法であなたが成長するのを助けます。 それは、共通の目的を達成するために、互いに支え合う意欲的な個人に依存しています。 アフリカのことわざがあります：

今では、あなたのチームは非常に興奮し、活力を与えられ、やる気を起こさせるはずです。 次に、ユーザーストーリーのバックログをさらに活用します。

やり残し

あなたのプロジェクトには不確実性があることを心に留めておいてください。 人生の早い段階で、顧客に適した製品を構築するために何が必要かを正確に知ることはできないでしょう。 水晶玉を物憂げに見つめ、未来を予測することはできません。

「バックログ」または「製品バックログ」は、要件が存在する場所です。 アジャイルは、「要件」の本質を捉えた、短くて簡潔なステートメントの記述を好みます。 バックログは単にエントリの長いリストであり、各エントリはユーザーストーリーとして単一の個別の「要件」を定義します。 そしてこれからは、「要件」ではなく、ユーザーストーリーという言葉を使用します。 あなたはおそらく「なぜ」と尋ねているでしょう。 それは良い質問です。 永遠のように思えますが、顧客がソフトウェアプロジェクトに必要な機能や側面を述べることは、常に要件と呼ばれてきました。 その言葉には、アジャイルでは価値のない解釈があります。 オックスフォード辞書はそれを次のように定義しています：

必要なもの、または求められているもの。 または、強制的なもの。 必要な条件。

そして残念ながら、私たちが解決策を定義し、物事は「強制的」であると述べた場合、私たちは問題を抱えることになります。 これらのユーザーストーリーはすべて必須であると言うのは簡単すぎます。 その見方をすると、与えられた範囲のすべてを実現しようとして、スケジュールや予算を超過するリスクがあります。 この製品では、ソリューションを実行可能にするためにこれらのストーリーが必要であると言っても問題ありません。特定の単語の解釈を避けたいだけです。

• 常にペルソナの観点からストーリーを書きます。 ペルソナは、ソリューションのユーザーまたは利害関係者を表します。 バックログを開始する前に、これらのペルソナを開発することをお勧めします。
• この段階では、適切なタイミングでユーザーストーリーについてより深く会話することを基本的に思い出させる、短くて単純なステートメントのみを記述します。
• 実在の人々は、目標を達成するために実行する必要があるタスクの観点から考えます。 ペルソナの観点から、そして彼らが成し遂げる必要があることに関してあなたの物語を書いてください。
• 完全なバックログを書き込む必要はありません。製品を実行可能にするために顧客が必要とすることを想像できる限り多く書き込むだけです。
• 製品のライフサイクルを通じて、ユーザーストーリーが変更されたり、多かれ少なかれ重要になったり、完全に削除されたりする可能性があることが後でわかります。 頻繁にリリースし、フィードバックを受け取り、何が優先事項であるかを評価することで、この動作を知ることができます。
• ストーリーを単独で書かないでください。 チーム、利害関係者、さらには顧客と関わります。 ストーリーはプロジェクトの存続期間中いつでも更新できますが、開発作業が開始されたら変更しないでください。
• あなたの物語のいくつかは「叙事詩」と見なされるかもしれません。 これらは多くをカバーする大きなストーリーであり、配信時間の近くで小さなストーリーに分割されます。
• 優れたユーザーストーリーの品質を検証するためのチェックリストであるINVESTモデルの使用を検討してください。
• 誰でもバックログにストーリーを追加できます。 一番下、または特別に作成された「駐車場」に配置する必要があります。 この追加されたストーリーは、チームやビジネスと話し合うためのプロンプトとして機能します。 ビジネスとチームがそれをサポートしている場合は、それを見積もり、優先順位を付けることができます
• また、システムの中で最もリスクの高い部分を検討することもできます。 複雑な、新しい、または技術的に不明なユーザーストーリーや機能がある場合は、これらをバックログの最上位に優先します。 このようにして、最初のリリースのわずか数週間前に、製品のやりがいのある重要な部分を提供しようとはしません。

ニーズを満たすバックログができたら、その中のストーリーを見積もり、優先度の高い順にランク付けして、リリース計画を立てることができます。

高レベルの推定と優先順位付け

高レベルの見積もりは、バックログのサイズを決定するプロセスです。 プロジェクトはどのくらい「大きく」、どのような価値をもたらしますか？ 優先順位付けは、どのストーリーがあなたにとって最も重要であるか、製品の実行可能性、および顧客の利益を決定するプロセスです。 私たちは、ビジネスに最大の価値を提供し、顧客からのフィードバックを得て、小さなものに汗を流さないように、最も価値の高いアイテムを最も早く提供したいと考えています。 出力は、優先順位が付けられ、適切なサイズの順序付けられたバックログになります。

• 一番上のストーリーは最も価値があると考えられています。 最も価値のあるアイテムをできるだけ早くお届けしたいと思います。
• サイズ設定と見積もりには多くの手法がありますが、この時点では、ストーリーのサイズを適切に示す必要があります。
  • Tシャツのサイズ、相対的なサイズ、理想的な日、またはストーリーポイントを使用します。
• この時点でも、利用可能なすべての情報を入手できるわけではありません。それで問題ありません。 それで実行するだけです。
• ビジネスの利害関係者またはプロダクトマネージャーがいる場合は、それと、作業を行うチームを関与させます。
• 見積もりを行うのに最適な人は専門家であるため、作業の設計、開発、テストを行う人にサイズを調整してもらいたいと考えています。
• チームはストーリーをより小さな部分に分解し始めるかもしれません。 これが発生した場合は、よりきめ細かいが離散的なストーリーを作成してください。
• チームはまた、テクノロジーや特定のユーザージャーニーをサポートするために、他のものよりも先に配信する必要があるものがあるため、いくつかのストーリーのランク付けを開始する場合があります。
• あなたとチームの間で、埋める必要のあるバックログの穴を見つけ始めるかもしれません。 それらの穴を新しいストーリーで埋め、必要に応じて見積もりと優先順位を付けてください。
• 優先順位付けは、MoSCoW分析を使用して最も簡単に実行できます。 MoSCoWは、製品を成功させるために「必須」のストーリーを決定するのに役立つシンプルな手法です。
• 見積もりを開始する前に、優先順位付けパスを実行できます。 ただし、特定の要素のサイズ設定によって、優先順位と実際のビジネス価値に関する決定が決まる場合もあります。 ですから、見積もりと優先順位付けを互いにやりとりしますが、それについて争わないでください！
• 2つのストーリーが他のストーリーほど重要になることはありません。 ランク1のストーリーは、ランク2のストーリーよりも重要または価値があります。
• ストーリーの重要性や価値を示すための優れた方法は、ストーリーに金銭的価値を追加することです。 たとえば、ストーリーAが5000ドルの追加収益をもたらすと考えられ、ストーリーBが100ドルを引き付ける可能性がある場合、ストーリーAの方が価値があります。 同様に、ストーリーCがストーリーDよりもビジネスを節約する場合、ストーリーCの方が価値があります。
• バックログのサイズを設定すると、番号が残ります。 リリース計画を立てるとき、その数は、特定の時間枠内にチームがどれだけの量を提供できるかを理解するのに役立ちます。

すべてのユーザーストーリーを前もって知る必要はないことを忘れないでください。 また、顧客があなたの製品を見る前に、すべてのストーリーを提供する必要はないことを忘れないでください。 You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

リリース計画

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

アダプティブプランニング

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

スプリント

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• 少しずつ作業することには大きなメリットがあります。 つまり、配信の当面の将来にのみ焦点を当てており、新しい入力、フィードバック、および学習により、短い反復サイクルで変更に対応できます。
• リリースの開始時に、スプリント0を実行します。これにより、チーム、ビジネス、およびプロジェクトのリリースを調整し、成功するための考え方を設定できます。 リリースの基盤をサポートする基本的な技術フレームワークとアーキテクチャを引き出します。 環境、アカウント、およびツールをセットアップします。 スパイクを実行して、難しい問題や未知の問題を理解します。 スプリント1の準備としてユーザーストーリーを詳しく説明します。スプリント0は準備をすることです。
• リリース中は、バックログを改善し続けます。 理解を深めたり、新しいことを学んだりすると、優先順位が変わり、新しい要件が明らかになり、以前は優れた機能だと思っていたものが完全に削除される可能性があります。
• スプリント内で完了する可能性のない作業を開始しないでください。 できない場合は、小さなチャンクに分割します。 また、以前に開始した作業が完了していない場合は、新しい作業を開始しないでください。 完全とは見なされない多くのことを開始することによって、価値を生み出すことはありません。 さらに、コンテキストの切り替えは避けてください。 これは、あるタスクを開始し、邪魔され、別のタスクを開始し、最も問題となるのはどちらも完了しないというアクティビティです。
• チームが一度に進行中の作業の量を制限します。 たとえば、3人の開発者と1人のテスターがいる場合、開発者とテスターに​​WIP制限を設定できます。
• 計画された後は、スプリントにこれ以上作業を追加しないでください。 途中でスプリントを止めないでください。 これに対する例外は次のとおりです。
  • 予想よりも早くパフォーマンスを行った場合は、適切に準備されている限り、バックログの先頭から次のストーリーを取得することを検討してください。
  • スプリントのパフォーマンスが非常に悪いために完了しない場合。 これは通常、何らかの説明の大惨事があった場合にのみ発生します。
  • ビジネスのニーズが急変しているために、スプリントの目標をサポートできなくなった場合。
• スプリントをキャンセルする場合は、優雅に行い、時間をかけて焦点を合わせ直し、他のスプリントと同じように新しいスプリントを開始します。
• リリースの終わりに向けて、最終リリースのスプリントを検討してください。 新しい機能は作成されておらず、いくつかのバグはクリーンアップされ、製品の新しいバージョンを実際に顧客にリリースするための準備を行うことができます。 それまでの間、顧客の段階的なリリースを行うことができないと言っているわけではありません。これは、制御され、測定され、持続可能なリリースメカニズムであるということだけです。
• リリースの最後に、1週間のスプリントを検討するかもしれません。 このスプリントでは、チームと協力して、いくつかの新しいアイデアを分解したり、いくつかの新しいテクノロジーを見つけたりすることができます。 これらはビジネスに役立つ優れたツールであり、チームに考えて創造性を発揮するためのブリーフィングスペースを提供します。 それは間抜けのためではなく、それでも価値を生み出します。 同様に、誰もが休憩が必要です。 この時期に休暇を取ることで、リリースの途中でケイデンスとベロシティを良好な状態に保つことができます。

完了の定義

「完了」が実際に何を意味するかを定義することは非常に重要です。 プロジェクトの存続期間中に「完了」には多くのバージョンがあります。つまり、ストーリー、リリース、またはプロジェクト全体で「完了」することの意味です。 それはすべて、あなた、あなたのチーム、そしてビジネスが出荷の準備を満足させるために適切なレベルの品質に完全であるとみなすものに要約されます。

チームにとって、「完了」ストーリーの定義は、すべてのコードが完了し、ピアレビューされ、定義された受け入れ基準を満たし、単体テストされ、UATされ、コードリポジトリにプッシュされるようなものになります。 ストーリーをデザイナーから開発者、テスターに​​渡すことができるようにするには、「完了」の定義をチェーン内の次の人が受け入れる必要があります。 あなたの製品所有者は、あなたの顧客に製品の増分をリリースするために、これが彼らにとって何を意味するかについて期待するでしょう。 いずれにせよ、誰もが「完了」の意味を認識し、その意味が確実に満たされるようにする責任のある当事者でなければなりません。 「完了」の定義を定義し、それを伝え、同意し、進化させます。 完了しました。

連続測定

あなたがそれを測定することができないならば、あなたはそれを管理することができません。 同じことが改善にも当てはまります。 アジャイルプロジェクトで経験的データを収集する必要性は、静脈を通る血液の流れとほぼ同じくらい重要です。 データがない場合、何を管理、修正、または改善する必要があるかをどのように知ることができますか？ まあ、簡単に言えば、あなたは腸の感触と根拠のない当て推量に頼ることになるでしょう、それは精査の下でかなりすぐに崩壊します。 そして、誰が精査を行っているかによっては、これはかなり不快な場所になる可能性があります。 したがって、プロジェクトの最初から、進捗状況をどのように示し、他の人がどのような方法で成功を確認するかを確実に理解してください。

幸いなことに、アジャイルには便利なツールとテクニックが搭載されています。 最初に行うことは、アジャイルマニフェストに戻り、次の単語をお気に入りのワードプロセッサに入力し、96ポイントまで爆破し、印刷して、壁に適用してすべての人に見てもらうことです。

ソフトウェアを提供する上での最大の実証可能な力は、ソフトウェアを実行している人々に、ソフトウェアが実行するはずのことを実行していることを示すことです。 これはあなたの顧客を幸せにするだけでなく、あなたのチームに大きな尊敬を集め、ビジネスを通してより多くの採用のために車輪に油をさします。

その他のツールは次のとおりです。

• 毎日のスタンドアップ：このセレモニーにはいくつかのバリエーションがありますが、基本は、チームメンバー全員が顔を合わせて話し合うことです。短くし、集中し、軽くします。 何か長い議論が必要な場合は、立ち上がった後に必要な人たちの間でより長い会話をするためにそれを駐車してください。 障害が発生した場合は、ストーリーのように書き留め、バックログに追加して、できるだけ早く対処してもらいます。 チームの進行を妨げているものはすべて、進行を遅らせ、速度の低下や期待に沿わないソフトウェアで実証されます。
• Velocity：歴史的なツールです。 これは、過去のパフォーマンスが将来のパフォーマンスを保証するものではないという財務上の警告に少し似ています。 しかし、アジャイルの場合、チームの速度がほぼスムーズになることを望んでいます。 それは私たちが将来のパフォーマンスと私たちの計画への自信を予測することを可能にする速度です。 特定のスプリントで出力されるストーリーポイントの数を減らす可能性のある、制御できない影響がある可能性があります。 これが発生した場合、おそらく回復することができます。 チームを打ち負かすためのスティックとしてベロシティを使用しないでください。 それはあなたに好意を勝ち取ることはありません。 確かなことの1つは、最初の2〜4スプリントでは速度が不安定になることです。 ただし、その時間枠のどこかで、一貫性と安定性が見られるようになるはずです。 速度が極端なものから別の極端なものへと揺らいでいる場合は、チームで修正する必要のある問題があります。
• バーンダウンチャート：今、この進歩の尺度は厄介なものです。 そのため、詳細を確認するためのリンクは提供していません。独自の調査を行い、自分に合ったチームおよびビジネスとして同意する必要があります。 とげがある理由は？ まあ、そこにある1つのリソースが同じ話をしているわけではありません！ 合意された1つのことは、スプリントまたはリリース内で、タイムボックスに対してどのようにパフォーマンスしているかを示すことです。 毎日維持されている場合は、順調に進んでいるか、逸脱しているかが表示されます。 一部のチームはこれを使用して、作成する必要のある残りの量を表します。多くの場合、他のチームは、これを使用して、完了する必要のある残りの作業量を示します。 前者は成功と価値の創出を祝うものであり、後者はそれほど刺激的でやる気を起こさせません。
• バーンアップチャート：作業完了率を表示する必要がある場合は、バーンダウンチャートを使用します。 ただし、バーンアップチャートを使用すると、作成された価値と、スプリントの終わりまでに作成する予定の価値を示すことができます。 チームが何が行われたか（または、うまくいかない場合はほとんどない…）、そして彼らがまだ目標を設定していることの両方をビジネスに示すための、はるかにやる気を起こさせるツール。 いずれの場合も、チャートを使用して、進捗状況が期待どおりに追跡されていない場所を特定し、パターンまたは逸脱を探し、それらを把握して、根本的な問題をできるだけ早く修正します。 スプリントの場合は毎日更新し、リリースバージョンチャートの場合はスプリントの最後に1回更新します。
• タスクボード：これらは、創造されている価値を実証するための優れた視覚的ラジエーターです。 毎日、または1日の任意の時点で更新されると、進捗状況がすぐに表示されます。 かんばんと組み合わせると、システム内の流れと閉塞を視覚化するための優れたツールにもなります。 多くの開発が完了していることがわかりますが、テストの生産性が低い場合は、問題が発生していることを確認し、適切かつ迅速に対応できます。

考慮すべき他のツールは、アジャイルアーンドバリュー、サイクルタイム、および累積フロー図（CFD）です。

これらの測定値、チャート、およびその他のツールを目に見える状態に保ち、できれば壁に大声で誇らしげに見せて、すべての人が見ることができるようにします。 チーム、利害関係者、およびその他の利害関係者は、プロジェクトのステータスをすぐに確認できます。 透過的で、貴重なコミュニケーションツールとして機能します。 これらのアーティファクトを壁に置くことができない場合は、共有可能で協調的なツールを使用し、アクセスしたい人がそれを持っていることを確認してください。

継続的改善

アジャイルライフ全体を通して、どこで改善を行うことができるかを特定し、学ぶように努めてください。 プロジェクトの終了時にレッスンがキャプチャされて学習されることはありません。 それは、運転免許試験に合格し、インストラクターなしで最初のドライブを暫定的に受けるようなものです。 何が機能し、何をすべきかはわかりますが、時間の経過とともに、運転のスキルと能力を調整し、新しい技術を学びます。 あなたも悪い習慣を拾うでしょう。 それらを探し、理解し、改善する方法を見つけてください。

何がうまくいかないかを特定し、救済策を適用するための多くの機会があります。 アジャイルでこれに組み込まれているアプローチは、回顧的です。 これは、反射と調整のための主要なツールです。 すべてのスプリントの終わりに、チームと時間をかけて、作業の実行方法、品質の提供方法、効率を最大化する方法、無駄を最小化する方法、および容量を増やす方法を改善します。 改善策を見つけたら、すぐにすべての問題を解決しようとしないでください。 最も影響が大きく、次のスプリントで実装できるものを特定します。 測定して観察します。 それが望ましい影響を与えた場合は、それをロックし、作業方法と完了の定義に書き留めます。 うまくいかない場合は、もう一度考えてみてください。 次のスプリントに入れられないことを学んだ教訓は、次のスプリントで注意を引くために駐車して優先順位を付けることができます。

プロセスを調整します。 動作しないものはすべて削除してください。 障害物を取り除きます。 アジャイルチームとしてのあなたの成熟度は、あなたがそれを許せば限界を知りません。

アジャイルプロジェクト管理を超えて

プロジェクトが実施された後に何が起こるかを知ることは重要です。 サポートとメンテナンスは、プロジェクトが顧客の手に渡った後もパフォーマンスを維持できるようにするための鍵です。 顧客からのフィードバックは、将来のリリースに含めることができます。 顧客の問題は適切に処理されます。 プロジェクトは、時間に制約のあるユニークな取り組みです。 それが提供する製品は、プロジェクトチームが解散した後の寿命があります。 製品が稼働したら、製品をサポートできることを確認してください。

アジャイルプロジェクトは、より伝統的なアプローチと共存しています。 予算管理と利害関係者の可視性の要件とアジャイルの目標とのバランスをとることは、柔軟性と応答性を目的としています。

ガバナンスフレームワークまたはアジャイルガバナンスモデルは、スクラムなどの標準的なアジャイルプロセスと組み合わせて使用​​されます。 それらは2つの特定の方法で機能します。

• これらは、開発の反復（スプリント）の外部で発生するプロセスを明確にすることにより、アジャイルプロジェクトのラッパーを提供します。 これには、プロジェクトの開始を成功させるための明確な基準の提供、および決定と計画の適切な検証が含まれます。
• それらは、標準のアジャイルプロセスの特定の部分の重点をシフトし、ガバナンスを必要とする、またはガバナンスをサポートする特定の原則と手法を強調します。

今日の絶え間なく変化する世界では、組織や企業はプロジェクトを提供するためにより柔軟なアプローチを採用することに熱心であり、よりアジャイルになりたいと考えています。 ただし、プロジェクトやプログラムを提供している組織や、既存の正式なプロジェクト管理プロセスがすでに存在する場合、アジャイルアプローチの多くの非公式性は気が遠くなるようなものであり、リスクが高すぎると見なされることもあります。 これらのプロジェクトに焦点を当てた組織には、成熟したアジャイルアプローチ（プロジェクトデリバリーの概念内のアジャイル）、アジャイルプロジェクト管理が必要です。

アジャイルを採用することで学び、成長します。 チームが快適なことを行い、彼らの声が確実に聞こえるようにし、彼らの要求に応じて行動することだけを行ってください。 適切なタイミングで、チームに新しくより価値のある手法を採用するように促します。 ビジネスと交渉し、アジャイル組織であることが何を意味するのかを理解するように促します。

よい旅路を。