私の会社は、最初の大規模な開発プロジェクトの問い合わせを受けたばかりで、アジャイル プロセスを使用したいと考えています。クライアントはアプリケーションのビジョンを持っていますが、要件がほとんどないことを公然と認めており、時間単位で請求する必要があることを認識しています。このため、私は彼にアジャイル アプローチを勧めました。
問題は、彼が予算を立てる人物を望んでいることです。私は、クライアントがその数の予算を立て、要件が変わっても、彼らの頭の中や本の中の数はそうではないので、見積もりをあきらめないように主張する多くの記事を読みました.
契約の価格設定を考慮に入れる方法はいくつかあると読んだことがありますが、そのほとんどすべて (1 つを除く) に事前の数字が組み込まれています。これは、アジャイル開発の原則全体に違反しているように見えます。
そこで私の質問は、あなたがアジャイル開発者である場合、どうすればこのアジャイル開発のキャッチ 22 を回避できるのでしょうか?
これが基本的な質問です。
クライアントはいつ完了したと思いますか?
6 月までに完了すると思われる場合は、アジャイル チームを配置します。6ヶ月で4～6人です。それが予算です。基本的に、それらの乗算を行います。チーム * 率 * 6 か月。
6 月までにほぼ完了し、その後さらに作業があると思われる場合は、9 か月の作業が必要になる可能性があります。繰り返しますが、あなたは彼らが自分でできる乗算を行っているだけです。チーム * 率 * 9 か月。
近い将来、あなたが彼らの開発チームになると思われる場合は、年末までプロジェクトをやり遂げる価格を提示してください。チーム * レート * 12 か月。
各リリースは優先順位を再設定する機会であるため、そのリリースで行う作業に基づいて、各リリースの価格を個別の作業として設定する必要があります。それは彼らの優先スキームであるため、彼らはあなたが構築するものを制御し、予算を段階的に制御します.
多くの場合、クライアントは、特定の機能セットにかかる費用を知りたがっています。それを尋ねる代わりに、彼らは全体的な予算について尋ねます (これはばかげています)。最初のリリースに多くの時間を費やし、彼らが得られるものとその最初のリリースにかかる費用を示します。
最終的に、彼らは根本的な真実を見るでしょう。
彼らは最も重要なものから最も重要でないものまで機能を購入しています。優先順位が正しければ、いつでもお金を使うのをやめて、何か役に立つものを手に入れることができます。
完了は相対的な用語です。お金がなくなったために「完了」したプロジェクトもあります。もう時間がないので、他のものは終わりです。(少なくともソフトウェア開発では) やるべきことがなくなったためにプロジェクトが終了することはめったにありません。
この状況では、作業の最初のチャンクの見積もりを提供し、必要なレベルまで作業を完了するために、クライアントが必要に応じて追加のスプリントを購入できるようにします。
より多くのシステムを開発し、クライアントからのフィードバックをスプリントの成果物に組み込むにつれて、関連する作業量と関連するコストの両方についてより良い感覚を得ることができます.
編集：かっこいい。素晴らしい！あなたがアジャイル アプローチでそれらを販売したという事実から、実装される機能に関して、アジャイルの観点から彼らがそれにアプローチしているのを見ることができる可能性があります。この " Intro to Scrum " ポッドキャストを聞いてみてください。彼らが今必要としていると思うすべての付帯設備を持っている必要はないだろうという事実に基づいて、あなたは彼らを売ることができるかもしれません.
HTH
乾杯、
ロブ
私が最近知った無愛想な政府の請負業者は、次のように述べています。
それはあなたの質問に答えませんが、覚えておく価値があります。彼らが前もって番号を言わないと 2 階に来ない (そして来ない) 場合は、番号を伝えなければなりません。
ソフトウェア プロジェクトを後援する人は誰でも、投資に見合う価値があるかどうかを評価できるように、投資に対してどのようなリターンが得られるかを把握する必要があります。100 万ドルの費用がかかり、12 か月かかるプロジェクトは、実行する価値があるかもしれません。200 万ドルの費用がかかり、24 か月かかる場合は、やる価値がないかもしれません。
本当の問題は、このプロジェクトを、クライアントが投資に対して適切なリターンを実現できる時間枠と予算内で実行できるかということです。その質問に対するあなたの答えが「はい」以外の場合は、そのプロジェクトにあなたを雇うべきではありません。そうでなければ、彼らはお金を使ってサイコロを振っているだけです。
その質問に対するあなたの現在の答えが「まだわかりません」である場合、そのプロジェクトを行うためにあなたを雇うべきではありません。しかし、それは、そのプロジェクトが実行する価値があるかどうかを調べるためにあなたを雇うべきではないという意味ではありません。これに関するコンサルティング会社の流行語は、「事前のスコーピング演習」です。
アジャイル開発とは、費やされた費用、予定された時間、および機能セットの 3 つの次元で曲線を管理することです。予算とスケジュールが固定されている場合、機能セットは可変でなければならないのは当然です。これらの制約があるため、最終的な機能セットがどうなるかはわかりません。ただし、これらの制約内で作成できる機能セットが、クライアントが許容できる範囲内にあるかどうかを知ることはできます。
あなたはこれを知ることができ、それを見つけることができます。それを見つけることは、あなたの会社にはできることですが、あなたのクライアントにはできません。それはあなたが彼らに提供できるサービスであり、彼らはあなたにお金を払うべきです. これを無料で行い、それを売上原価と呼ぶ誘惑を避けてください。プロジェクトのスコーピングは、ソフトウェア開発と同じくらいプロフェッショナル サービスの一部です。これは、販売を成立させるために行っているのではありません。これは、クライアントがまだ十分な情報を持っていないというビジネス上の決定を下すのに役立ちます。
しかし、まず彼らを二階に連れて行かなければなりません。
ほら、ここに重要な事実があります。コストを見積もり、特定の納期について契約し、提供される機能の完全なセットを約束するよう求められます。
3つすべてを行うことはできません。
「すべきではない」または「しない方が賢明だろう」ではありません。あなたは（すべての実用的な目的のために）できません。つまり、3 つすべてを成功させる確率は非常に小さいということです。
最良の答えは、コストとスケジュール、および迅速な反復と定期的なフィードバックを伴う反復プロセスにコミットし、固定コストとスケジュールの下で行われることが提供されるものになるように契約を作成することです。つまり、時間とお金が尽きるまで、新しい機能 (および変更) を提供し続けます。
真実は、3つすべてにサインアップしたとしても、あなたができる最善のことはとにかく3つのうち2つです. それについてオープンにすることもできます。
これらの答えは本当に素晴らしいです。共有できる経験はあまりありませんが、類推を考えました。
昨年、妻と私はキッチンを改造しました。請負業者は、見積もりを出すのではなく、時間と材料で請求することを提案しました. 私は自宅で仕事をしていて、質問に答えることができたので、同意しました. 請負業者と私は良好な関係を築いていたので、何か問題が発生すると、彼は気軽に私のオフィスのドアをノックして話し合っていました。意思決定は迅速に行われ、作業は希望どおりに行われました。これは、頻繁なカスタマー レビューに対するアジャイルの優先事項に似ているようです。
対照的に、妻のいとこも家を改装中です。彼は ER の医師であり、改造中は現場に出られません。そのため、彼は請負業者が彼に相談せずに主要な決定を下すことに定期的に驚いていると説明しました (「え? あのピクチャー ウィンドウを塞ぎたくなかった! 壁を引き裂いて、ウィンドウを元のように再構成します!」)。もちろん、これは非常に高価であり、スケジュールを水から吹き飛ばします. 間違いなくアジャイルではありません。
したがって、タイム & マテリアル モードが機能することをクライアントに納得させる 1 つの方法は、フィードバックを得るために頻繁に進捗レポートを作成することを保証することです。これは、すでにほとんどのアジャイル方法論の中心的な推奨事項になっていると思います。まず、もちろん、これには顧客がコンサルタントに信頼を与える必要があります。
別の情報源として、このテーマに関する本を検索して見つけました。Mike Cohn 著の「 Agile Estimating and Planning 」です。そのページにある印象的な一連のアジャイル エキスパートからの賞賛の引用を読んでください。
まず第一に、アジャイルなアプローチと時間単位の価格設定を彼に売り込んでくれたことは素晴らしいと思います。それはとても難しいことです。
あなたのジレンマに関しては、大まかな価格の見積もりとそれに含まれる機能/範囲を彼に提示する必要があると思います. 開発プロセス中に、スコープ/コストを変更する重要な何かが発生した場合は、クライアントに「やめてください。これは素晴らしいことですが、話し合った元のスコープが変更されることを理解してください」と言います。
この時点で、クライアントは同意するか、最初に考えていたよりも多く支払うことを認識するか、新しい開発を今のところ停止する特権を持っています. 多くのアジャイル プロジェクトは、多くのミニ ステージで構築されています。これにより、価格と時間のかなり正確な見積もりを得ることができます。新しいミニステージが始まる前に、あなたとクライアントが次に何をするのか、それにどれだけの時間と費用が費やされるのかを確認することが重要です.
私がこれを行った方法は、現在の速度を使用し、複雑さ (ストーリーの数) の大まかな見積もりに基づいて範囲を見積もることです。アプリケーションの計画を開始するときにこれを更新して、範囲推定が徐々に改善されるようにします。
たとえば、6 か月から 2 年の見積もりを出します (2 年未満の時間がかかると確信している場合)。それを機能に分解し、それらの機能を計画すると、より適切な見積もりが得られます。 6 か月後には (他の変更がない場合)、さらに 2 ～ 3 か月 (合計 8 ～ 9 か月) で完了すると確実に言えます。次の反復の後に行われます (2 週間から 1 か月)。
これと、機能を追加すると完了までの時間が長くなることを顧客に知らせてから、機能を削除するか時間を増やすかのどちらを先に進めるかを顧客に決定してもらう必要があります。どのプロジェクトでも、効果的に変更できる変数はスコープと時間だけです。品質とリソースはほぼ固定されています。実際には、リソースを追加できますが、通常、最初は時間の増加と品質の低下が見られるため、これは時間範囲が長い場合にのみ機能します.
いつものように、品質、機能、時間 (=リソース) が主なパラメータです。もう品質をいじることはないので、残っているのは機能とリソースだけです。多くの場合、一定量のリソースが最低限特定の機能セットに到達することを納得させることができます。したがって、妥当な機能セットを提供するリソースが大量にある限り、かなりの数の顧客にとってこれで十分だと思います。利点は、移動中に進行状況を制御できることであり、いつでも取り消すオプションがあります。
これは本当に難しい問題です。Robert Glass が彼の著書 " Facts and Fallacies of Software Engineering " でこのテーマについて述べていることを参照してください。( Amazon には、中古よりも安く入手できる新品の本があることに注意してください! [2009-01-05 12:20 -08:00 の時点で]; Google ブックスでも。 )
あなたが取ることができる 1 つのアプローチは、比較的近いと思われる一般的な見積もりをクライアントに与えることです。また、パーセンテージを与えます。このパーセンテージは、要件の変更による予算の割り当ての増減になります。
例: 一般的な見積もりは 10,000 ドルですが、要件が曖昧であり、プロジェクトが容易に方向転換する可能性があるため、+/- 30% の価格調整オプションがあります。
このようにして、クライアントは何を予算に入れるかについての一般的なアイデアを得ることができ、プロジェクトに請求する際にある程度の柔軟性が得られます.
ポイントに切り替える際は、以下の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 以下のチャンクに分割する必要があります。 .
ポイントと元のバックログは以上です。新しいストーリーがある場合は、それをそのリストと比較して、どこに適合するか (プロセスが大きいか小さいか) を確認し、隣接するものの価値を示します。
速度と見積もり (マクロ計画)
そのバックログを処理するのにかかる時間を見積もるには、最初のスプリント計画を立てます。チームが選んだストーリーに付けられたポイントの合計を作ってください。これが最初の速度測定値です。次に、バックログのポイントの合計をそのベロシティで割り、必要なスプリント数を知ることができます。
その速度は変化し、最初の 2 ～ 3 スプリントで落ち着くので、常にその値に注意することをお勧めします。
アジャイルアプローチと時間単位の請求を顧客にうまく売り込んだ場合、プロジェクトを完了するのにかかる費用の見積もりを顧客に提供しないでください。. 予算を立てるためだけに欲しいと言っても、やらないでください。.
その理由は、コストの見積もりは明確なコミットメントとして扱われるようになるためです。あなたがそうではないと何度言っても、顧客がそれを理解していると何度言っても、それはコミットメントとして扱われます. たとえ顧客が理解しても上司は理解しませんし、あなたが言った価格で提供することを法的に強制することはできませんが、約束したものを提供しない会社として知られるようになります. 見積もりを提供すると、そもそもアジャイルであることのすべての利点が失われます。
私が提案するのは、会計年度末 (または顧客が関心を持っているその他の請求期間) までに、これこれの金額を超えて支出しないことを伝えることです。それまでにプロジェクトが完了するとは決して言わずに、彼らが財政的に計画するのに十分なはずです.