アジャイルなソフトウェア開発：変化するユーザー要件に*財務的に*どのように対応しますか？

SEや他のサイトでこの「アジャイル開発」に関するすべての記事を読むとき、私がいつも疑問に思っていたことが1つあります。

「従来の」ソフトウェアエンジニアリングでは、

1. ユーザーの要件を収集し、
2. これらの要件に基づいて仕様を作成し、
3. それを顧客に渡し、これまでに行った作業の代金を請求します。
4. 実装コストを見積もることができるように（大まかな）技術設計を行います。
5. ユーザーに実装の価格を提示し、
6. 顧客が仕様に署名してオファーを受け入れるまで待ちます。
7. 設計、実装、テスト、
8. ビル。

プロセス中に要件が変更された場合、希望する変更のオファー（価格付き）を送信します（または、変更が小さい場合は無料で行います。顧客は好きで、顧客はあまり頻繁に行いません）。 。

では、頻繁な要件の変更がプロセスの一部であるアジャイルプロジェクトでは、これは（財務的に）どのように機能しますか？

• 設計変更ごとにオファーを書いていますか？（これはかなり面倒ではないでしょうか？）
• または、固定価格について交渉し、顧客が要件を頻繁に変更しないことを望みますか？（リスクを伴う可能性があります。プロジェクトの完了を受け入れる前に、この機会を利用して新しい機能を何年もリクエストする顧客を知っています。）
• または、必要な合計時間に対して顧客に請求するだけですか？（事前にコストを知らない顧客にとっては危険です。）

理想的なアジャイルの世界では、事前に価格と時間数に同意しますが、範囲には同意しません。顧客は、実際に必要な製品ではなく、最小の有用な製品を決定します。これは、合意された時間数よりもかなり短い時間で見積もる必要があります。

その後、彼らに繰り返し配信し、彼らは彼らが望むすべての彼らの心を変更しますが、合意した時間数を超えて行くことはありません。理論的に、そして実際にはしばしば、彼らは本当に欲しい製品ではなく、本当に必要な製品になります。

そして、彼らが元の合意された価値の後に余分な時間のためにあなたに支払い続けることを望むならば、それも問題ありません。ストーリーカード、Greenhopperなどを使用して進捗状況を十分に表示できる場合、新しい機能を追加するたびに、どの機能が失われる（または少なくとも優先順位が下がる）かを顧客に明確に伝えることができます。軽微な変更の停止。

ここで注目に値する2つのリスクがあります。まず、顧客が敏Ag性を事前に理解していない場合、顧客が怖がってしまう可能性があるということです。彼はすべてのリスクを負っているようです。彼が実際にそうではないことを経験だけが示しています。

2つ目は、プロセス全体を通して関与しなければならないということです。そうしないと、全員が負けてしまいます。多くのお客様は、手遅れになるまで、自分がいかに熱心であるべきかを理解していません。

しかし、あなたが、会社として十分に説明してくれれば、誰もが勝者になります。

一部の 人々 は、過去に固定価格プロジェクトで敏ility性を使用するソリューションを提供しようと し ました。私は個人的にそれは一般的に不可能だと思います。

特にスクラムは製品ソフトウェア会社に適しており、サービス会社ではあまり使用されていません。

イテレーション、毎日のスタンドアップ、バーンドーンなど、プロジェクトでいくつかの敏ility性を使用できますが、特定の価格で一定量のものを提供し、契約よりも少ないものを提供する場合、問題が発生します。

Agilityàtoutes les sauceを提供しないでください。特定の問題に対して適切なソリューションを使用する必要があります。

これは、アジャイルプログラミングや使用するモデルとは実際には関係ありません。フリーランサーとして働いている私は、ウォーターフォールとVモデルを組み合わせて使用​​していますが、それでも同じ問題があります。顧客が詳細設計中に何かを変更したい場合はどうすればよいですか。実装中に変更を加えた場合はどうなりますか？

使用しなければならないアプローチは、顧客と関係によって異なります。

連絡先がこの顧客のために行うすべての必需品である場合、彼は彼ができるときに支払いをしようとしないことを知っているか、彼は可能な限りあなたを訴えようとするので、はい、あなたは要件の小さな変更。それは混乱ではありません。あなたがうまく組織化されていれば、開発中に新しい要件に対応することはそれほど難しくないかもしれません。しかし確かに、時間とお金の損失であり、実装に2時間かかる変更の申し出に署名しなければならないのはかなり奇妙です。

他の顧客にとって、うまく機能するアプローチは次のとおりです。

• 最初のオファーに署名するときに、推定コストと最大コストを指定します。推定コストは法的に何を意味するものではありません。それは単なる推定値です。最大費用には法的な価値があります。製品が顧客に3,000ドルかかり、最終的に3,157.24ドルかかると言う場合、顧客は3,000ドルを支払う必要があります。実際には、ほとんどの場合、実際のコストは指定された最大値よりも低く、見積もりに近くなります。

• 顧客が要件を変更するように要求した場合、そのコストを見積もり、実際のコストと状態と比較します。製品がほぼ完成し、実際のコストが2,108.36ドルで、変更のコストが150ドルと見積もられている場合は、それを行ってください。一方、最大に達するリスクがある場合は、全体のコストを一緒に再評価する必要があることを顧客に伝えます。

アジャイルと「オファーを書く」はアンチテーゼのようです:)-後者は生産的なソフトウェアエンジニアリングではありません：D

さて、これで冗談がなくなりました-本物に戻ります。

「アジャイルではどのように機能しますか？」-契約は事態を複雑にしますが、明確にしたいと思います。アジャイルは「信頼」と「コワーキング」の原則に基づいています。つまり、顧客はいつでも何でも変更できることを意味し、少し費用がかかるか、または邪魔にならない場合は、おそらく追加費用なしで理解できることを理解しています。

これは何を意味するのでしょうか？これは、契約が、私たち（クライアント）がコストの初期推定値と+/-分散％を修正できることを示していることを意味します。契約の一部ですが、顧客の心の中にあります）。

さて、設計の変更が発生すると、見積もりと計画を機敏に行います。チームをまとめて、変更の因数分解の複雑さについて「ストーリーポイント」の見積もりを依頼します。速度の見積もりにより、それらを掛け合わせてスケジュールの見積もりを出すことができます。チームとその相対的な給与を知っていれば、ストーリーポイントあたりのコストを比較的簡単に削減できます（全員の給与を平均しないでください。平均の欠陥に負けてしまいます）。

財務情報とともに顧客に戻る必要がありますか？番号。必ずしも。お客様にこれらを優先させ、バックログの正しい場所に挿入してもらいます。バックログのサイズがわかっているので（まだしていない場合）、財務（ストーリーポイントあたりのコスト）に基づいて、特定の予算では実行できない優先度の低い要件がわかります。$$コントラクトごとに実行可能な機能の推定値を付けて、優先順位を変更したバックログを提示します。その後、彼らがあなたが/そこに着いたら/より多くを得るために彼らがもっと払うかどうかを決めさせます。彼らが無料でそれを望むならば...あなたは立ち上がって、彼らにそれがより多くの費用がかかると言います。

これは、顧客が見られるようにこのグラフをどこかに表示できる場合、常に財務に戻ることなく役立ちます。

お役に立てれば！

他の人の経験はおそらく異なるでしょうが、私がそれをやったのを見た一つの方法は、いくつかの注意すべき点があるあなたの「伝統的な」ものとほぼ同じです。

1. 変更のためのオーバーヘッドを組み込みます（たとえば、10％）
2. 大規模な変更を評価して個別に請求する、または組み込みコストを超える変更を集計して請求する追加）

多くの場合、アジャイルプロジェクトは「コア」アイテムとして始まり、必要に応じてそこからモジュラー方式でスパイラルアウトします（これは私が関与したプロジェクトでかなり発生するのを見てきました）。それで、あなたはコア製品から始めます、それがマッピングアプリケーションだとしましょう。最初の実装は、現在の場所（顧客が最初に注文したもの）を中心とした単なる地図です。

顧客は、周囲の特定のアトラクションのピンを落としたいと判断します。さて、それはかなり大きな部分なので（比較的言えば）、新しい「モジュール」または発注書として請求します。これらのピンの色やデザインなどの変更は、その注文のコストに組み込まれています。方向とオーバーレイは別の注文書です。他の注文書が進行するまで要求されなかったなどです。