所要時間と節約時間の両方の見積もりを必要とするプロジェクトに柔軟でアジャイルなアプローチを取ることは可能ですか？

以前にアジャイルと効果的に仕事をしたことがある人として、私は現在の雇用者にアジャイルの利点を納得させようとしています。ただし、経営陣は、プロジェクトのビジネス価値を評価するために、事前に見積もる能力を保持することを強く求めています。

私の顧客のほとんどは社内にいるので、最近、チームを回って、自動化するビジネスプロセスのアイデアを彼らに尋ねることを任されました。次に、これにどれだけの時間がかかっていたかを調べ、ソリューションがどれだけの時間を節約できるかを調べ、総開発時間を見積もりました。そうすれば、管理者は、時間の節約という点でソリューションがどれほど効果的であるかを測定することができます。

しかし、この要件に「アジャイル」でアプローチする方法はないように思えます。柔軟な要件とは、所要時間の推定が間違っているだけでなく、潜在的な時間の推定も節約されることを意味します。私は多くのことを説明し、なぜそれが問題になる可能性が高いのかを説明しましたが、それは交渉不可能であると言われました。

（ウォーターフォール）クライアントにアジャイル開発を販売する方法の質問には、外部顧客にアジャイルを「販売」する方法に関する有用なアドバイスがあります。私はそれを外部のクライアントに販売しようとはしていません。うまくいくと信じている方法論を保持しながら、内部管理の要求をどのように調整できるかを考えています。

少なくともいくつかのアジャイルの利点を保持できる柔軟な方法でこのタスクにアプローチする方法はありますか？

他の回答が述べているように、経営陣はプロジェクトの前もって高レベルの見積もりを得るためのあらゆる権利を持っています。ROIを決定しようとするのは不合理ではありません。

ただし、アジャイルについて私が気に入っているアプローチの1つは、プロジェクトの範囲が固定されていないことです。最初に機能レベルとエピックレベルでサイズを調整し、次に最も重要な機能に基づいてROIを決定できます。多機能なUIの機能はビジネス価値が低いかもしれませんが、クレームを処理するためのワークフローエンジンは高いROIを持っています。

プロジェクト全体をひとまとめにする場合、必要な重要なビジネス機能に集中する場合よりもROIを満たすのが難しくなります。

これが私がこれを行った方法です：

WBSのマイルストーンを取り、それぞれを成果物に変えます

これにより、プロジェクトをさまざまなビジネス価値を持つミニサブプロジェクトに分類できます。これらはそれぞれ、ビジネス価値の点で独立している必要があります。

Tシャツサイズの機能への取り組み

これは、特定の機能がどれだけ大きいか、または関与するかについて大まかなアイデアを得るための非常に簡単な方法です。おそらく、低価値の機能は、簡単に勝つように見える場合でも、優れたROIを維持しています。

機能をストーリーに分解する

演習を行って、よく理解されている小さな機能を見つけ、最初にストーリーに分解します。これらのストーリーをポイントごとに見積もります。今、あなたはどこに基礎を持っています

小-> 40ポイント

これは、他の機能との比較の基礎になります

ストーリーポイントの取り組みをすべての機能に関連付ける

Small Featureを他の機能と比較します。例えば、

ミディアムフィーチャーYは、40ストーリーポイントのスモールフィーチャーXの2倍のサイズと労力であるように感じます。

Medium Feature Yは、おそらく80ストーリーポイントです。すべての機能のストーリーポイントが高いレベルで推定されるまで、これを続けます。

Team Velocityを見積もる

開発チームを見て、特定のスプリントでこのチームが効果的に提供できるストーリーポイントの数を決定してください。このチームの例として以前のアジャイルプロジェクトがある場合は、開始するのに最適な場所です。チームの背後にそのような履歴がない場合は、チームで模擬スプリントプランニングを行い、詳細なスモールフィーチャーの確認を開始します。これらのストーリーのタスクのために、人々はどのような種類の時間ごとの見積もりをしますか？

チームが2週間で達成できると考える作業量に基づいて、その合計ストーリーポイント数をチームの平均潜在速度として使用します。

完了予定日を見つける

モックスプリント計画のチームがスプリントで25ストーリーポイントを納得し、プロジェクトのゴールドキャデラックバージョンの合計バックログが300ストーリーポイントのように見える場合、チームは理想的には12スプリントまたは24週間かかると思われますすべてを完了します。

チームのリソースのコストを1週間あたりのドルに変えるのは簡単で、ROIとビジネスバリューのコストを実現できます。最も重要な機能が何であるかについて交渉を続けることができ、その後、プロジェクト管理は基本的にナップザックの問題になります。

これは「管理」の問題ではありません。開始する前に、潜在的なプロジェクトのコストと利益を見積もることができることは絶対条件です。そうでなければ、何をする（または試みる）価値があるかを誰がどのように知るでしょうか？

それではなぜアジャイルなのでしょうか？

アジャイル手法を使用することは、不確実性を選択することではないと主張します。むしろ、アジャイルは不確実性は避けられないという議論であり、従来の方法の詳細な仕様と推定は誤った確実性をもたらしますが、これは非常にコストがかかる可能性があります。

時間推定に関するいくつかの重要なポイント：

• プロジェクト全体の要件の変更は避けられません。アジャイルは、変更がないと見せかけるのではなく、これを考慮します。
• 多くの場合、詳細な仕様には設計上の欠陥が含まれていますが、これらの欠陥はプロジェクトに入るまで明らかになりません。これは、アジャイルプロジェクトよりも従来のプロジェクトで大きな変化を意味する場合があります。
• 「このプロジェクト全体がどれくらい大きいと思うか」に基づく時間の見積もり。多くの詳細な要件の推定時間を合計するのと同じくらい正確です。
• 適切な見積もりにつながる主なものは、見積もり、測定、レビューのサイクルです。これは、一貫性のあるプロセスに適用できます。
• 「作業節約」の見積もりは、詳細ではなくプロジェクトの主要な要件によって決定されるため、アジャイルがこれを見積もる能力を大きく損なうことになるとは思いません。

更新：

明確にするために、上司に対するあなたの反応は、「柔軟であるため、アジャイルを使用した場合、時間の節約や開発の総労力を非常にうまく見積もれない」と思われます。これは間違っていると思います。とにかく不確実性が存在するため、アジャイルプロセスを使用する場合にも、これらの推定値を作成できると考えています。そしてもちろん、アジャイルはプロジェクトが展開するにつれて、より柔軟で応答性の高いプロセスを可能にします。

これは確かにアジャイルを導入する最も難しい部分の1つです

「経営陣はまだ時間の見積もりが必要です」

私のアプローチは：

• パッド300％。300％という古い言い回しは、管理レベルで実際に俊敏性が発揮されない状況にあるときに役立ちます。これはおそらく「アジャイルアプローチ」ではありませんが、この状況に対する妥協案です。あなたは数回先に来ることができます-しかし、それを頼りにしないでください！

• プロジェクトの「中間点」となる点で達成された作業に基づいてレビューを依頼します。完了した作業に基づいてプロジェクトを完了します。次に、管理者に相談し、プロジェクトの開始時の推測に基づいて時間が固定されていることを考慮して、機能または品質を犠牲にするものを検討します。

• 彼らが実際にそれらの決定を下すように、あなたが完了した機能と品質管理でコラボレーションしていることを確認してください

• このプロジェクトの流れに沿って、通常のこと-締め切りの遅れ、品質の低下、燃え尽き、退職した従業員のストレス（そしておそらくは去った）が起こるようにします。次のフェーズのプロジェクトが立ち上がったら、これらの「副作用」について話し合います。

• 「真の」アジャイルアプローチの利点に焦点を合わせて実証します。品質の改善について話します。生産を開始する直前まで、変更を加える能力について話します。再作業の必要性が減ったことについて話しました。最終的に開発を急がせる技術的負債の減少について話してください。現実の世界に例えれば、たとえば、いつでもオイル交換を延期できますが、それを十分に延期すると、エンジンが損傷し、性能が低下し、最終的にロッドを吹き飛ばします。

• 履歴書とlinkedInプロファイルを最新の状態に保ちます。ケースを数回作成しても管理サポートが受けられない場合は、先に進みます。一部の組織はあなたの議論にリストされないので、そうするものに移動します。それをダーウィニズムの雇用と呼んだ;）

アジャイル開発について誤った仮定をしていると思います。柔軟性と変化する要件は、文字通りアジャイルマニフェストに組み込まれています。

開発の後期であっても、要件の変更を歓迎します。アジャイルプロセスは、顧客の競争上の優位性のために変化を利用します。

アジャイルでは、柔軟な（読む：変化する）要件を歓迎します。ほとんどの開発者に尋ねると、変更は合理的でなければならないという警告が追加されます。チームに3Dゲームを作成するように依頼し、要件を「原子炉の制御システム」に変更するのは少し大変です。ただし、プロジェクトの範囲内で要件を追加、削除、または変更することはまったく問題ありません。

問題は、変化する要件にどのように対処するかです。典型的な答えは、短い反復を使用して、時間を浪費する前にコースを早期に調整できるようにすることです。また、チームが要件をより小さな部分に分解することを強制するため、誰もが要件をよりよく理解し、妥当な時間と労力でそれらを実装できます。

シンプルさ-完了していない作業量を最大化する技術-は不可欠です。

このアジャイルの原則も気に入っています。通常、チームは冷酷な効率性を通じて必要なものだけを提供するよう努力する必要があることを意味します。たとえば、顧客が何かが必要だと思っているが、怪しいと思われる場合は、掘り下げます。たぶん、エンドユーザーはそれを実際に使用しないので、作業を行うべきではありません。

ただし、この原則の別の側面にあなたの質問が当たったと思います。ソフトウェアは通常、手動プロセスを自動化する目的を果たします。ソフトウェア自体は、エンドユーザーによって行われない作業量を最大化するために存在します。

ソフトウェアがエンドユーザーを救う労力を測定することは、間違いなく価値のある指標です。私はこれを自分のキャリアで自分で測定しました。実際には、費用/便益分析の重要な要素です。つまり、最終製品がエンドユーザーを節約するのに比べて、ソフトウェアプロジェクトの実装にどれだけの労力がかかるかです。

これは、アジャイル（またはその他の）開発哲学と完全に互換性があり、経営陣は絶対にこれに同意する必要があります。

ええ、アジリティにはいくつかの利点があります。

• これにより、ビジネスマンは飛行中に気分を変えることができます。
• エンジニアの絶え間なく悪い見積もりからビジネスを保護します。
• 最終ビジョンが達成される前に、多くの場合、早期に価値をもたらします。
• 事前計画のコストをいくらか節約できますが、とにかく悪い計画を作成することがよくあります。
• とてもクールです。右？

ただし、かなり正確な先行見積を行う必要があります。

そうしないと、製品に初期投資の価値さえあるという証拠もなく、場合によってはまったく何もせずに、製品に投資するようビジネスに効果的に求めています。

そして今、私はそれを聞くことができます。

前に聞いたことがあります。私は前に言ったことがあると確信しています：

ああ-しかし、ハウ！？HAOWは私のような単なる人間のような人間が、私のような目でそのようなものの運命を注視します！神自身だけが神聖で指示できるもの。死すべき者が最も深い眠りで夢を見ることができて、一日のうちに忘れることができるもの！おおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお

あなたの過去のパフォーマンスをガイドとして使用し、正直にしてください。

• 利害関係者やエンドユーザーと十分に話し合い、製品や主要コンポーネントが他の主要コンポーネントとどの程度複雑であるかを判断します。初期の相対点推定を行います。
• その数を、過去に見たスコープ変更の歴史的な量とバグのフォールアウトで増やします。
• 過去の速度をポイント推定値に適用して、大まかなタイムラインに到達します。そして、不確実性の合理的な円錐を適用します。
• プロジェクトの見積もりと理解を再検討します。確信してあなたは、あなたの評価に基づいてプロジェクトに取り組むことについての決定を下すことをいといません。

最後に、不確実性のコーンを利害関係者に提示し、仮定と懸念を述べ、そのままにしておきます。

余談ですが、あなたやチームの通常の見積もりを健全性チェックするための客観的なポイント推定ヒューリスティックを提案することもお勧めします。

この見積もりは、ポーカーのプランニング中、または単独で行っている場合はプライベートの見積もりを検証する際に、N番目の投票として使用できます。たとえば、私のチームは、1分あたり約1ポイントの、おおよその技術的な発見のストーリーのディスカッションを見積もる傾向があります。これは、腸が5ポイントであると伝える場合に特に役立ちますが、何をする必要があるかを理解するのに20分かかりました-通常、まだ複雑で誤解が潜んでいることを示す良い指標です。

一貫して良い時間を見積もることができた会社で働いたことはないし、そうしたと主張する人と働いたこともない。検索により、推定は業界全体で未解決の問題であることがわかります。

抽象的なストーリーポイントに基づいて速度を測定することについて賛同を得ようとします。それができない場合は、さらに見積もりを追加します。

アジャイルは、さまざまな問題に対する優れたソリューションですが、一部の福音主義者が示唆していることにもかかわらず、それが唯一のソリューションではなく、常に適切なソリューションとは限りません。

あなたの述べたケースは、単にアジャイルの問題ではありません：

私は最近、チームを巡回して、自動化するビジネスプロセスに関するアイデアを求めました。次に、これにどれだけの時間がかかっているかを調べ、ソリューションがどれだけの時間を節約できるかを計算し、総開発時間を見積もりました。そうすれば、管理者は、時間の節約という点でソリューションがどれほど効果的であるかを測定することができます。

一部のビジネスプロセスを自動化することのコストと利点を決定することは、変更の対象となるアジャイルタスクではなく、特定のソリューションの特定の問題です。任意の数のビジネスプロセスを含むリストを作成します。それぞれに、自動化の推定コスト、自動化しない推定コスト、および自動化の推定利益があります。経営陣はこれを予算、リソース、要件、戦略的目標と照合し、これらのプロセスのうちどれを自動化するか（もしあれば）を決定します。良心的であれば、ROI自体は潜在的に低いが、他のフェーズのコストを削減してROI全体を改善する選択したタスクを強調表示します。また、社内および外部委託の特注開発（アジャイルおよび/またはウォーターフォール技術を使用）、既製のソリューションの購入、サードパーティのサービスプロバイダーの使用など、自動化を実現するさまざまな方法を特定している場合があります。このプロセス全体は、ビジネスプロセスのリエンジニアリングとして知られていた90年代に非常に流行しました。