アジャイル環境での大規模プロジェクトの見積もりの提供[終了]
https://stackoverflow.com/questions/414346
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私の会社は最初の大規模な開発プロジェクトの問い合わせを受けたばかりで、アジャイルプロセスを使用したいと思います。クライアントはアプリケーションに対するビジョンを持っていますが、要件が非常に少ないことを公然と認めており、時間ごとに課金する必要があることを認識しています。このため、私は彼をアジャイルアプローチで販売しました。
問題は、彼が周りに予算を立てるための数字を望んでいることです。クライアントはその数に予算を割り当て、要件が変わっても頭と本の数は変わらないので、私は見積もりを放棄することをほとんど支持しない多くの記事を読みました。
契約の価格設定を考慮に入れる方法はいくつかありますが、それらのほとんどすべて（1つを保存）に先行番号が組み込まれています。これは、アジャイル開発の一連の原則全体に違反しているようです。
それで私の質問は、あなたがアジャイルショップなら、どのようにアジャイル開発のこのキャッチ22を回避するのですか？
解決
基本的な質問です。
クライアントはいつ完了したと思いますか
6月までに完了すると思われる場合は、アジャイルチームを配置します。それは6ヶ月で4-6人です。それが予算です。基本的に、それらの乗算を行います。チーム*レート* 6か月。
ほとんどが6月までに完了すると考えているが、その後さらに作業が行われる場合は、おそらく9か月の作業を見ています。繰り返しますが、あなたは彼らが自分自身のためにできる掛け算をしているだけです。チーム*レート* 9か月。
もしあなたが近い将来、あなたが彼らの開発チームになると彼らが考えているなら、彼らにプロジェクトを年の終わりまで終わらせる価格を彼らに与えてください。チーム*レート* 12か月。
各リリースは優先順位を変更する機会であるため、各リリースの価格設定は、そのリリースで行うことになる ことに基づいて個別の作業として行う必要があります。それは彼らの優先順位スキームなので、彼らはあなたが構築するものを制御し、予算を段階的に制御します。
多くの場合、クライアントは特定の機能セットのコストを本当に知りたがっています。それを尋ねる代わりに、彼らは全体的な予算について質問します（これはばかげています）。最初のリリースに多くの時間を費やして、彼らが何を手に入れ、その最初のリリースにどれくらいの費用がかかるかを示します。
最終的に、彼らは基本的な真実を見るでしょう。
彼らは、最も重要なものから最も重要でないものまで機能を購入しています。彼らが正しく優先順位付けをすれば、いつでもお金を使うのをやめ、有用な何かを持つことができます。
完了は相対的な用語です。一部のプロジェクトは「完了」しています。お金がないからですもう時間がありませんので、他のことが行われます。まれに（少なくともソフトウェア開発において）やることがなくなったためにこれまでに行われたプロジェクトです。
他のヒント
この状況では、作業の最初のチャンクの推定値を提供し、クライアントが必要なレベルまで作業を完了するために必要に応じてさらにスプリントを購入できるようにします。
システムをさらに開発し、クライアントからのフィードバックをスプリントの成果物に組み込むと、関連する作業量とそれに伴うコストをよりよく感じるようになります。
編集：クール。素晴らしい方法！アジャイルアプローチでそれらを販売したという事実から、良い方法です！実装される機能の観点からアジャイルの観点からアプローチすることでそれらを見ることができる可能性があります。この＆quot; スクラムの紹介＆quot;ポッドキャスト。おそらく、彼らがすぐに必要と思うすべての機能を備えている必要はないという事実に基づいて、それらを売ることができるかもしれません。
HTH
歓声、
ロブ
見てください、ここには核となる事実があります。コストの見積もり、特定の納期の契約、および提供された機能の完全なセットへのコミットが求められます。
3つすべてを行うことはできません。
「するべきではない」ではないまたは「しない」のが賢明でしょう。あなたは（すべての実用的な目的のために）できません。つまり、3つすべてを成功させる確率は非常に小さいということです。
最良の答えは、コストとスケジュール、および迅速な反復と定期的なフィードバックを伴う反復プロセスにコミットし、固定コストとスケジュールに基づいて完了するように契約を書くことです。配信されるものです。つまり、時間と費用がなくなるまで新しい機能（および変更）を提供し続けます。
真実は、たとえ3つすべてにサインアップしたとしても、とにかく3つのうち2つがベストだということです。同様にオープンであることもあります。
最近、私が知っている無愛想な古い政府の請負業者が次のように言っています。「売春婦が言うように、最初に階上に行かなければなりません」
それはあなたの質問には答えませんが、覚えておく価値はあります。彼らが前もって番号なしで二階に来ない（そして彼らがそうしない）なら、あなたは彼らに番号を与えなければならない。
ソフトウェアプロジェクトのスポンサーになる人は、投資が価値があるかどうかを評価できるように、どのような種類の投資を回収するのかを知る必要があります。 100万ドルの費用がかかり、12か月かかるプロジェクトは価値があります。 200万ドルの費用がかかり、24か月かかる場合は、実行する価値がない場合があります。
本当の問題は、クライアントが適切な投資収益率を実現できるような時間枠と予算内でこのプロジェクトを実行できるかということです。その質問に対する答えが「はい」以外の場合は、それから彼らはあなたをプロジェクトに雇うべきではありません。そうでなければ、彼らはお金を使ってサイコロを振るだけです。
その質問に対する現在の回答が「まだわからない」の場合、それから彼らはあなたをプロジェクトに雇うべきではありません。しかし、だからといって、プロジェクトにやりがいがあるかどうかを知るために雇われてはいけないということではありません。このための優れたコンサルティング会社の流行語は、「予備のスコーピング演習」です
アジャイル開発とは、費やしたお金、カレンダーの時間、機能セットの3つの次元で曲線を管理することです。予算とスケジュールが固定されている場合、機能セットは可変でなければならないことは当然です。これらの制約を考えると、最終的な機能セットが どうなるかはわかりません。ただし、これらの制約内で作成できる a 機能セットが、クライアントが許容できる範囲内に収まるかどうかを 知ることができます。
これを知ることができ、それを見つけることができます。それを見つけることはあなたの会社ができることであり、あなたのクライアントはできません。それはあなたが彼らに提供できるサービスであり、彼らはあなたにお金を払うべきです。これを無料で行う誘惑を避け、それを売上原価と呼びます。プロジェクトスコーピングは、ソフトウェア開発と同じくらい専門的なサービスの一部です。これは、販売を終了するためではありません。これは、クライアントがまだ十分な情報を持っていないというビジネス上の意思決定を支援するために行っています。
しかし、最初にそれらを上に持って行かなければなりません。
これらの答えは本当に素晴らしいです。共有する経験はあまりありませんが、類似点を考えました：
昨年、妻と私はキッチンを改造しました。請負業者は、時間どおりの請求を提案しました。配管、床下の損傷などに関して私たちが何を発見したかわからなかったためです。私は自宅で仕事をしていて、質問に答えることができるので、同意しました。請負業者と私は良い関係を持っていたので、何かが起きたとき、彼は私のオフィスのドアを自由にノックして、それについて話し合いました。すぐに決定が下され、作業は私が望んだ方法で行われました。これは、頻繁な顧客レビューにおけるアジャイルの優先度に似ています。
対照的に、妻のいとこも彼の家を改造しています。彼はERの医師であり、改造中は現場で利用できない 。そこで彼は、請負業者が彼に相談せずに主要な決定を下すことに定期的に驚いていると説明しました（「何？私はその写真の窓を遮りたくありません！壁を引き裂いて、窓を元のように再構成してください！」）。これはもちろん痛いほど高価であり、スケジュールを水から吹き飛ばします。間違いなくアジャイルではありません。
クライアントに時間と時間を説得する1つの方法マテリアルモードが機能するのは、フィードバックを得るために頻繁に進捗レポートを作成することです。これはすでにほとんどのアジャイル手法の中心的な推奨事項であると思います。もちろん、これを開始するには、顧客がコンサルタントに信頼を与える必要があります。
別のリソースとして、＆quot; アジャイルに関する本を検索しました。見積もりと計画＆quot;マイク・コーン。そのページにある印象的なアジャイルの専門家からの賞賛の引用を読んでください。
まず第一に、アジャイルアプローチと時間あたりの価格設定で彼を売ったことは素晴らしいことだと思います。それはとても難しいです。
ジレンマについては、おおよその価格の見積もりとそれに含まれる機能/範囲を提示する必要があると思います。開発プロセス中に、スコープ/コストを変更する重要な何かが出てくるのを見ると、クライアントに「やめなさい-これは素晴らしいですが、議論した元のスコープを変更することを理解してください」
この時点で、クライアントは同意する特権、最初に思っていた以上のお金を支払うことに気づく、または今のところ新しい開発を中止する特権を持っています。多くのアジャイルプロジェクトは多くのミニステージで構築されています-そのために、価格/時間のかなり正確な見積もりを与えることができます。新しいミニステージを開始する前に、あなたとクライアントが次に何が起こっているのか、それにどのくらいの時間/コストが費やされるのかを目で見て確認することが重要です。
いつものように、主なパラメータである品質、機能、時間（=リソース）があります。私たちはもはや品質をいじっていないので、機能とリソースのみが残っています。かなりの頻度で、一定量のリソースが最低でも一定の機能セットに到達することを納得させることができます。したがって、もっともらしい機能セットを提供するリソースを見つけることができる限り、これはかなりの数の顧客にとって十分だと思います。利点は、移動中に進捗を制御できることです。また、いつでもバックアウトするオプションがあります。
これを行う方法は、現在の速度を使用して、複雑さ（ストーリーの数）の大まかな推定に基づいて範囲を推定することです。アプリケーションの計画を開始するときにこれを更新して、範囲の推定値が徐々に良くなるようにします。
たとえば、6か月から2年までの見積もりを提供します（2年未満の時間がかかると確信している場合。機能に分割して、それらの機能を計画し、より良いものを見つけ、 6か月後に確実に発言できるように（他の変更がない場合）、さらに2〜3か月（合計8〜9か月）になります。 '次の反復（2週間から1か月）後に行われます。
これを組み合わせて、機能を追加すると完了するまでの時間が長くなることをお客様に知らせ、機能を削除するか時間を長くするかのどちらかを進める方法をお客様に決定させる必要があります。どのプロジェクトでも、実際に変更できる変数はスコープと時間だけです。品質とリソースはほぼ固定されています。実際には、リソースを追加できますが、通常は最初に時間が長くなり、品質が低下するため、これは時間範囲が長い場合にのみ機能します。
取ることができるアプローチの1つは、比較的近いと思われる一般的な見積もりをクライアントに提供することです。また、割合を示します。割合は、要件の変更による予算の割り当ての増減になります。
例：一般的な見積もりは10,000ドルですが、要件は曖昧であり、プロジェクトはコースを簡単に変更できるため、+ /-30％の価格調整オプションがあります。
こうすることで、クライアントは予算の対象についての一般的なアイデアを得ることができ、プロジェクトへの請求にある程度の柔軟性があります。
これは本当に難しい問題です。彼の本の中でこのテーマについてロバートグラスが言っていることを参照してください＆quot; ソフトウェアの事実と誤Fallエンジニアリング＆quot;。 （ Amazonでは、中古の本よりも少ない本を入手できることに注意してください！[2009-01-05 12:20 -08：00現在]。Googleブックでも）
顧客にアジャイルでのアプローチを成功させ、時間単位で請求する場合、プロジェクトの完了にかかる費用の見積りを提供しないでください。予算の目的でのみ使用したい場合でも、しないでください。
理由は、コストの見積もりが確定的なコミットメントとして扱われるようになるためです。何回言っても、顧客がそれを理解したと言ったとしても、それはコミットメントとして扱われます。たとえ顧客が理解していても、上司は理解できず、あなたが言った価格で配達することを法的に強制することはできませんが、約束されたものを配達しない会社として知られるようになります。見積もりを提供すると、そもそもアジャイルであることの利点がすべて失われます。
私が提案しているのは、会計年度の終わりまでに（または顧客が関心を持っている他の請求期間）、それ以上の金額は使わないということです。プロジェクトがそれまでに終了するとは言わずに、財政的に計画するには十分なはずです。
これは私の クローズド質問ストーリーポイントに関連。私はこれを常にマクロ推定に使用しています。
ポイントに切り替えたとき、次の2つのポイントを満たすことができる場合にのみ決定しました。 1）スイッチを正当化し、チームを納得させる論拠を見つけ、2）それを使用する簡単な方法を見つけます。
説得力のある
このテーマについて多くの読書をしましたが、最終的に私と私のチームを納得させる議論を見つけました：タスクがかかる時間に同意する2人のプログラマーを見つけることはほとんど不可能です2人のプログラマは、2つの異なるタスクを表示すると、どのタスクが最大であるかについてほぼ常に同意します。
これは、推定する必要がある唯一のスキルです。バックログ。ここでは、「推定」という言葉を使用します。しかし、この初期段階では、バックログをタフなものから簡単なものに注文するようなものです。
バックログへのポイントの挿入
このステップは、スクラムチーム全体の参加で行われます。
次の順序を維持しながら、新しいスプレッドシートにストーリーを1つずつドロップし始めます。最大のストーリーが最上部に、最小のストーリーが最下部にあります。すべてのストーリーがリストに表示されるまでそれを繰り返します。
これで、これらのストーリーにポイントを置く時間です。個人的にはポーカープランニングスケール（1 / 2、1、2、3、5、8、13、20、40、100）を使用しているため、この例ではこれを使用します。そのリストの一番下には、おそらくマイクロタスク（実行に4時間以下かかるタスク）があります。すべてのマイクロタスクに1/2の値を与えます。次に、ストーリーがはるかに大きくなる（1ではなく2なので、2倍大きくなる）ことが明らかになるまで、ストーリーに値1（スケールの次）を指定して、リストを続けます。ここで値「2」を使用して、2ではなく3を明確に含むストーリーが見つかるまでリストを上に続けます。このプロセスをリストの一番上まで続けます。
注：大部分のポイントを1から13の間に維持するようにしてください。初めて大きなストーリー（20、40、100）ができたら、それらをチャンクにまとめる必要があります。 13以下。
これは、ポイントと元のバックログに関するものです。新しいストーリーがある場合は、それをそのリストと比較して、どこに収まるか（より大きな/より小さなプロセス）を確認し、その隣人の価値を与えます。
速度と推定（マクロ計画）
そのバックログを通過するのにかかる時間を見積もるには、最初のスプリント計画を立てます。チームが選んだストーリーに付けられたポイントの合計とVOILA !、これが最初の速度測定です。その後、バックログ内のポイントの合計をその速度で除算して、必要なスプリントの数を知ることができます。
その速度は最初の2〜3回のスプリントで変化して落ち着くので、常にその値に注意してください
