アジャイルプロジェクト管理におけるソフトウェアコストの見積もり

公開: 2022-03-11

序章

ソフトウェア開発で行うのが最も難しいことの1つは、新しいソフトウェア製品を提供するのにかかる時間と量を決定することです。そんなに難しいのでしょうか？答えは簡単ではありません。

ソフトウェアのコスト見積もりは本質的に困難であり、人間は絶対的な結果を予測するのが非常に苦手です。 2つのプロジェクトが同じではありません。それぞれが達成しようとしていることにおいて独特であり、その存在を形成する無数のパラメーターにおいて独特です。多くの場合、表面上は単純な問題のように見えますが、実際に実装するのははるかに困難であるか、技術的に困難です。そして、間違いなく、プロジェクトには、発生したときにのみ識別できる「不明」が存在します。

さらに、あなたが顧客、開発者、ユーザーのいずれであっても、2人が同じになることはありません。私たちは、独自の知識、経験、価値観、期待、リスクに対する態度、および適応する能力を事前に備えています。

質の高いソフトウェアを作成することは、上級エンジニアにとっては大変なことです。素晴らしいソフトウェア製品を作成することは、関係するすべての人にとって、はるかに困難な努力になる可能性があります。

素晴らしいソフトウェアの提供はバランスをとる行為です

つぶやき

しかし、ソフトウェアに関しては、期間とコストを理解することが戦略的なビジネス上の意思決定を行う上で重要です。これは、スタートアップを作成する場合でも、新しいビジネスチャンスを実現する場合でも、ビジネスのパフォーマンスを向上させる場合でも当てはまります。タイミング、投資収益率、および提供される利益は、ビジネスを左右する可能性があります。あなたは自分自身に問いかけるでしょう：私たちは私たちのお金のために何を得るのですか？コストを予測できますか？欲しい製品を作るのにいくらかかりますか？いつ発売できますか？投資のために高品質の製品を手に入れることができますか？それは私たちのビジネスとともに成長しますか？それはビジネス価値をもたらしますか？

では、プロジェクトのサイズ、期間、およびコストをどのように見積もるのですか？アジャイルプロジェクトの見積もりとソフトウェア開発のコスト、およびToptalでそれをどのように行うかを見てみましょう。

従来の契約価格と見積もり

従来、アジャイル以外の手法を使用して、ソフトウェアプロジェクトは機能または範囲を修正し、時間とコストを変動させることを目指してきました。これにより問題が発生します。

プロジェクトの最初に修正する機能が、実際にビジネスや顧客に最も役立つ機能であることをどのように知っていますか？多くの場合、機能またはスコープが変更されます。そのため、「スコープクリープ」について耳にします。プロジェクトのライフサイクルを通じて特定され、必要または必須として決定される、望ましいニーズの結果です。
コストが変動するようになると、達成しようとしている投資収益率（ROI）を制御できなくなります。コストの増加は、多くの場合、未確認のリスクまたは要件の変更の結果です。つまり、同じ時間枠でより多くの作業を行うためにチームメンバーを追加するか、チームメンバーをより長く維持する必要があります。どちらも望ましくない
時間が変動する場合、私たちは市場でのポジションをコントロールできなくなります。おそらく、重要な業界の日付を見逃したり、競合他社が製品を私たちの前に出したりして、プロジェクトが持っていた可能性のある競争上の優位性を失ってしまう可能性があります。

時間とコストが変動する結果は他にもたくさんありますが、それらはしばしば否定的で望ましくありません。

もちろん、多くの顧客や組織は、この「魔法の三角形」の3つのコンポーネントすべてを修正しようとしています。残念ながら、現実的に達成することはほぼ不可能です。この理想を揺るがす要素が多すぎて、最終的にはニーズを満たさない製品になり、顧客に利益をもたらすのに時間がかかりすぎたり、ビジネス価値を実現するのにコストがかかりすぎたりします。

ソフトウェアプロジェクトのアジャイル契約

コストは時間と人（チームメンバー）の積です。より多くの時間を追加し、あなたはより長く人々を雇用するためのコストを追加します。チームメンバーを追加すると、同じビジネス価値を提供するためのコストが増加します。本当に避けたいこと。これが、アジャイルの原則が時間とチームメンバーを修正し、スコープを可変コンポーネントにすることを信じている理由です。

どちらがより良く聞こえ、利害関係者の信頼、固定費または変動費を増加させますか？

もちろん、製品がその約束と顧客のニーズを実現することが重要です。結局のところ、誰も欲しがらない、または効果的に使用できない製品がある場合、正確な時間と正確な金額を費やすことは良くありません。

したがって、アジャイル契約は次のことに焦点を当てています。

固定価格の作業パッケージ-プロジェクト全体が論理的な「ミニ」リリースに分割され、完全な製品の成果に貢献します。各リリースは、それに応じた価格のワークパッケージです。作業パッケージが完了すると、前の作業パッケージから学んだことに基づいて、将来の作業パッケージが再推定されます。これにより、不必要な不測の事態が回避され、顧客が特定のレベルの再優先順位付けと新機能/改訂機能を定義できるようになります。
早期終了-これにより、十分な製品が提供され、わずかな利益しか提供し続けないプロジェクトチームを維持することによって達成されるさらなるROIがない場合、顧客はプロジェクトを早期に終了することを求めることができます。この条項は通常いつでも許可され、プロジェクトチームと顧客が強力で信頼できる緊密な協力関係を維持している限り有効です。お客様にとってのメリットは、製品を実行可能にするために必要なすべての貴重な機能を提供して、プロジェクトが早期に終了することです。その見返りとして、サプライヤーには残りの契約額の20％が支払われ、スタッフを維持するリスクが相殺されます。
柔軟な変更-変更は、アジャイルソフトウェア配信の流れを強力に貫くテーマです。私たちは、製品を最初から成功させるために必要なすべてを知っているわけではないことを期待しています。そのため、関連するデータとフィードバックに基づいて変更を推進し、適切な製品が確実に提供されるようにします。イテレーションの最後に、変更を交換して、不要または優先度が低くなった古い機能に交換することができます。変更の価値が等しい限り、それ以上のコストはかかりません。変更の価値が低い場合は、追加の作業を特定するか、残りのバックログから繰り越すことができます。この条項は、プロジェクトチームと顧客が、プロジェクト全体を通じて強力で信頼できる緊密な協力関係を維持している限り有効です。
追加作業-プロジェクトの存続期間を通じて、既存の固定価格契約では達成できない機能がさらに特定される可能性があります。このシナリオでは、プロジェクトの最後に新たに価格設定された作業パッケージを追加するか、時間と材料に戻すことができます。
範囲付き見積もり-アジャイルプロジェクト契約で見積もりを範囲指定できる方法は2つあります。期間の範囲または機能の範囲です。期間の範囲により、プロジェクトまたは作業パッケージが特定のスコープのセットに対して12〜16週間かかると見積もることができます。ただし、期間を追加すると、プロジェクトチームのメンバーを長く維持するためにコストが増加します。つまり、他の開発プロジェクトで作業するためにメンバーを解放することはできません。 Toptalでは、スコープを可変として維持しながら、作業パッケージまたはプロジェクト全体の一定の時間枠内で顧客に最小レベルの価値を提供することを約束して、さまざまなストーリーポイントにわたって機能を範囲指定することを好みます。

後でいつでもスコープを追加できることを覚えておく価値があります。おそらくあなたは収入を稼ぎ始め、ユーザーを増やしたり、コストを削減したりしました。いずれにせよ、すでに利益または改善を示し、ビジネス価値を提供している場合は、より多くのお金と時間を要求する方がはるかに簡単です。

ソフトウェアのコストと価格設定に対する当社のアプローチ

Toptalでは、お客様やエンジニアと緊密に連携して、プロジェクトの期間とコストに対する利害関係者の信頼を促進する手法を採用しています。私たちは、無駄を避け、管理された変更を可能にするために適切かつ必要な場合、最初の高レベルからより詳細な詳細まで、計画を継続的に精緻化し、適応させることに取り組んでいます。

見積もりおよび固定価格プロジェクトを作成するには、次の手順を実行します。

1.初期の高レベルスコープ

プロジェクトの開始時に、私たちはその最終的な結果についてほとんど知りません。お客様やユーザーが最初から必要としている機能を正確に知ることができると想像するのは愚かなことです。

そこで、プロジェクト憲章と、健全なビジョンと目的に基づいてプロジェクトの方向性を導く「壮大な」機能の高レベルのセットから始めます。

a。 ビジョンと目標の設定何を構築する必要がありますか？あなたは何を達成する必要があり、あなたのビジネス目標は何ですか？これらの質問を理解することで、プロジェクトの規模を設定できます。最初のアイデア、コンセプト、またはテクノロジーをテストするためのプロトタイプが必要ですか？市場でテストされた明確な提案を特定し、最初のMinimal Viable Product（MVP）を構築する準備ができていますか？または、既存のビジネスまたは製品を次のレベルに引き上げるためにスケーリングしていますか？

b。 高レベルの「壮大な」機能詳細に立ち入ることなく、製品が顧客のニーズを満たすために必要な機能を定義する必要があります。これは、製品の要点を説明する構造化された「ショッピングリスト」です。多くの場合、これらは「ユーザーストーリー」または叙事詩と呼ばれます

c。 MoSCoW分析MoSCoW分析は、簡単に言えば、製品を実行可能にするために本当に必要なものと、持っていると便利なものを特定するのに役立つ手法です。「必須」として識別されたものは、ユーザーがあなたの製品に従事し、採用することを奨励するものを満たします。「すべき」と特定されたこれらの機能は、顧客を驚かせ、喜ばせますが、後で構築することもできます。「可能性のある」アイテムは、多くの場合、重要なビジネス価値を追加せず、収益を増加させない可能性があり、優先順位の最も低いものです。「しない」機能はいつか重要になる可能性がありますが、このプロジェクトの反復の範囲外です。ただし、これらを今すぐ特定することは、将来の製品の潜在的な規模とサイズを念頭に置くのに役立ちます。

2.提案

プロジェクトを進めるかどうかを決定するには、十分な情報に基づいたデータ（コストと期間）に基づいて決定する必要があります。これらはあなたがあなた自身に尋ねる必要がある最低限です：私たちが望む製品を作るのに何が必要ですか？いつ発売できますか？これは私たちの事業戦略と財務と一致していますか？

上記の詳細により、私たちは提案を提供する立場にあります。当社のエンジニアは、特定のプロジェクト要件を厳選し、プロジェクトマネージャーと協力して、少なくとも1つの技術ソリューション、既知の範囲を実現する推定期間、およびプロジェクトを完了するための推定コストを導き出します。

前に述べたように、プロジェクトの開始時には、何が提供されるかについてはほとんどわかっていません。意図的に機能とスコープをあいまいにしています。そうしないと、何が必要かを正確に把握していることがわかります。この段階での見積もりは最も正確ではありませんが、プロジェクトを進める価値があるかどうかについてのガイダンスを提供します。

この提案は、プロジェクトの期間とコストを詳しく説明する最初のツールです。提案が受理されたら、固定価格の見積もりを提供するために前進することができます。

3.リリース計画

次のレベルの見積もりの詳細は、特定の時間枠でさまざまな機能を提供するリリース計画を作成することです。これは、機能のリスト、プロジェクトのサイズ、不確実性のリスクを管理するための顧客の期待と技術を満たす高品質のソフトウェアをチームがどれだけ迅速に開発できるかから導き出されます。

a。 製品バックログ製品バックログは、製品に必要な機能を表す「エピック」または「ユーザーストーリー」の順序付きリストです。このリストは、前に説明した叙事詩から始まりますが、割り当てられたプロジェクトチーム、プロジェクトマネージャー、および顧客の間で、これらをより意味のある項目に分類します。各項目は、顧客にとってのビジネス価値の一部を表しています。この段階ではこれ以上詳しく説明しません。受け入れ基準を知る必要はありません。ボタンが青か緑かを知る必要はありません。タスクを許可するボタンがあることを知る必要があります。実行されます。

b。推定ユーザーストーリーとして記述された機能のリストができたので、チームは「プランニングポーカー」と呼ばれる手法を使用してこれらの個別の機能アイテムを推定します。これは、専門家の意見と類似のサイジングに基づいて、迅速で信頼性の高い結果を保証する便利な手法です。プランニングポーカーは、サイズと複雑さを表す合意された番号を各アイテムに割り当てます。これはストーリーポイントと呼ばれます。「理想的な日数」など、他のアジャイル推定手法とサイズが利用可能です。

このプロセスの終わりに、プロジェクトのサイズと機能間の依存関係が決まります。サイズは、製品バックログのアイテムからのすべてのストーリーポイントを合計することによって決定されます。その数が120に等しい場合、プロジェクトのサイズは120ストーリーポイントです。

c。 優先順位付けプロジェクトのバックログとサイズが決まったので、お客様と一緒に優先順位を付けることができます。これは本当に、望ましい結果を達成するために顧客にとって最も価値のあるものを特定することです。リストの一番上にある項目が最も重要であると見なされ、2番目の項目は最初の項目よりも重要度が低く、以下同様にリスト全体で重要になります。 2つのアイテムが他のアイテムほど重要になることはありません。各アイテムの優先順位は、他の各アイテムに対して相対的な重要性または価値があります。

優先順位付けへのこのアプローチは、ソフトウェアプロジェクトを計画する際の重要なマイルストーンです。これで、お客様にとって何が重要であり、どの順序で作業を完了し、依存関係に注意を払い、期待に応える製品を提供できるかがわかりました。

d。 リリース計画これまで、私たちは製品が何であると信じているか、そしてそれがどれくらい大きいかを決定しました。

ここで、リリース可能な製品の配信にかかる時間を決定します。設計者、エンジニア、テスター、スクラムマスター、プロジェクトマネージャーを含む顧客とチームが協力して、何を達成できるか、リリース計画を作成するためにどれだけ迅速に作業できるかを特定します。

リリース計画は、プロジェクトが顧客の戦略計画とどのように整合するかについての洞察も提供します。

そして最後に、この計画は、プロジェクトチームが道を切り開き、開発への論理的なエンドポイントを定義するガイドライトを確実に持つようにします。

始める前に、合意された「完了」の定義を理解していることを確認します。これは、顧客が完全であると受け入れる一連の基準であり、リリース可能と見なされるすべてのエンジニアリング要件も満たしています。

基本的なシナリオをとるために、バックログのサイズ設定から得られたストーリーポイントの総数を取得し、それをチームの予想速度で割ります。（NB速度は通常範囲として表されますが、簡単にするために、ここでは1つの数値を使用します。）2週間の反復で作業するため、速度は、利用可能な2週間のサイクルで完了することができる量に反映されます。チームの能力。ストーリーポイントの合計が120で、反復ごとに20ポイントを完了すると予想される場合、開発期間の合計は12週間または6回の反復になります。これに、2週間のスプリント0と2週間のリリース準備スプリントを追加します。合計で、私たちのプロジェクトの期間は16週間です。計画に適切なリスクバッファーを組み込むのに役立つ、使用できる手法があります。これについては後で説明します。しかし、要するに、不確実性のリスクを管理し、提供されると予想されるストーリーポイントの最小限の合意に達するためにバッファーを使用します。結果は、90から150ストーリーポイントの範囲で提供される可能性があり、90は、実行可能な製品を作成するために許容できる最小値です。

または、プロジェクトを特定の日付、たとえば10週間までに完了する必要がある場合、チームはその時間内に完了することができるバックログの量を決定します。スプリントごとに20ストーリーポイントに加えて、スプリント0とリリーススプリントを予測する場合、プロジェクトの終了までに完了する60ポイントを目標とします。繰り返しになりますが、適切なバッファーを追加することでリスクを管理することを検討します。これにより、45〜75ストーリーポイントのターゲットが完了し、リリースの準備が整う可能性があります。 45のストーリーポイントは、実行可能で価値のある製品を提供するために許容できる最小値と一致します。これは、必要に応じて、速度を上げるためにチームメンバーを追加することを期待できるシナリオの1つです。

もちろん、上記のすべては、達成可能で現実的で顧客に受け入れられるリリース計画を導き出すための、すべての関係者間の質の高いコミュニケーションとコラボレーションによってサポートされています。

4.固定価格契約

リリース計画が合意されると、固定価格のプロジェクト契約の見積もりを作成できるようになります。前述のように、プロジェクトの期間とチームを固定し、スコープを可変にしておくことをお勧めします。

固定価格契約の見積もりは、作業明細書と合意された支払いスケジュールとともに提供されます。

信頼、コミュニケーション、コラボレーション、そしてアジャイルソフトウェアプロジェクトの精神に入る準備ができている限り、上記のすべてのステップにより、プロジェクトが予定どおりに提供され、予算内。もちろん、プロジェクトが早くまたは遅く配信される場合もあり、私たちはこれらのバリエーションに最大限の透明性を持って対処します。

推定手法

アジャイルの計画と見積もりは、開発チームがサイズ、労力、期間、およびコストの信頼を得るために使用できる多くの手法によってサポートされています。これが私たちのチームがソフトウェアプロジェクトのサイズとコストを見積もるために使用するもののいくつかです。

サイズの見積もり

プロジェクトの規模は、実際にはその範囲、複雑さ、規模、リスク、および規模を評価したものです。例えを使用すると、エッフェル塔を建設しているのか、万里の長城を建設しているのかを理解することが重要です。エッフェル塔は、タイトな都市環境に建てられた、背が高く、重く、複雑な構造です。万里の長城は比較的単純ですが、何マイルもの起伏のある地形にまたがる長くて頑丈な構造です。

それらは両方とも提供する大きなプロジェクトですが、その範囲、複雑さ、寸法、規模、したがってサイズは異なります。

見積もりで期待を管理することが重要です。それらは決して予測、コミットメントまたは保証ではありません。合計サイズ、合計期間、および合計コストについて話し合うときは、リスク、不確実性、および未知数を軽減するために、常に範囲内で作業します。

製品の機能を表すストーリーは、ストーリーポイントまたは理想的な日を使用して、個別にサイズ設定および推定されます。これらのユニットの総数は、プロジェクトの合計サイズを定義します。

ストーリーポイント

ストーリーポイントは、ユーザーストーリーの全体的なサイズを表す測定単位です。ストーリーのサイズは、推定すると、設計、エンジニアリング、テスト、コードレビュー、統合などのすべての側面が含まれます。

ストーリーの各サイズは、別のストーリーに関連しています。したがって、たとえば、ストーリーAのサイズは1ポイント、ストーリーBのサイズは2ポイント、ストーリーCのサイズは3ポイントになります。ここで、ストーリーCはストーリーAの少なくとも3倍のサイズであり、ストーリーBの少なくとも半分のサイズです。

製品バックログの次のストーリーに関連するサイズがある場合：

話	サイズ
A	1
B	5
C	3
D	1
E	2

プロジェクトの合計サイズは12ストーリーポイントです。

理想の日

これは、日数で表されるサイズの尺度です。これにより、中断、アジャイル計画アクティビティ、電子メールの読み取り、その他のプロジェクト以外のアクティビティなどのオーバーヘッドの概念が排除されます。それは、開始から終了までの経過時間ではなく、中断することなく継続的に何かに取り組む場合にかかる時間にのみ焦点を当てています。

通常、プロジェクトについてほとんど知らないときに高レベルで見積もる場合、これはストーリーポイントなどの抽象的な数値よりも過去の履歴や経験と相関させるのが簡単な概念であるため、理想的な日数で見積もることになります。特に、高レベルのストーリーが本質的に叙事詩的であり、詳細がほとんどなく、後日分解されたときに追加の要素が含まれている可能性がある場合は特にそうです。

より詳細なレベルで見積もる場合、たとえば確立された製品バックログのストーリーの場合、どちらのアプローチも使用でき、エンジニアリングチームによって決定されます。両方のアプローチには利点があり、各チームに優先順位があります。

推定するためのテクニック

共有見積もり見積もりは単独では実行されません。これらはエンジニアリングチーム全体が共同で実行し、設計、データベース、サーバー、フロントエンドUI、QA、およびその他の部門の枠を超えた専門家が含まれます。これにより、機能を完成させるために必要な作業のすべての側面を考慮しないという問題が回避され、機能のサイズを過大評価または過小評価する負担や不幸を誰も負わないようになります。統合されたチームはすべて、話し合い、合意できる見解を持っています。

類似の見積もりこれは、2つの個別の特徴を検討し、一方が他方よりも比較的小さいか大きいかを判断する場所です。与えられたストーリーを見て、サイズが小さいことに同意できます。ストーリーポイントを使用する場合は、サイズを2にすることができます。次のストーリーは最初のストーリーに比べて大きいと見なされる可能性があり、5つのサイズを指定します。これは、大きなフィーチャが小さなフィーチャの少なくとも2倍のサイズであることを示しています。

私たちはすべての物語でこの演習を続けます。完了したら、小、中、大、特大のすべてのストーリーを並べて配置し、サイズをクロスチェックして、見積もりに一定レベルの均一性があることを確認します。

プランニングポーカープランニングポーカーについては多くのことが書かれています。以前のブログでも触れました。それを理解するための最良のリソースの1つはここにあります。

本質的に、それは専門家の意見、類推、およびチームのコラボレーションを1つの簡単で、速く、信頼できるプロセスに結合します。

技術的およびドメインの経験、活発な対話、および健全な正当化に基づいて見積もりを作成するのに最適な複数の専門家が集まります。

速度

速度は、特定の反復（またはスプリント）で作業を完了するためのチームの能力の尺度です。

これは、特にプロジェクトの初期段階では、スプリントごとに23〜32ストーリーポイントの範囲として表されます。一般的に、これは、同じチームが以前に同じ問題に取り組んだことがない限り、チームの速度を正確に表すことが難しいためです。個人の速度ではなく、チームの速度を参照していることに注意してください。

速度を使用してリリースを計画し、プロジェクトの進行に合わせて計画と作業パッケージを調整します。これにより、実行を通じて定期的かつ正確に完了の予測を調整できます。

最初は、非常に少ないデータで速度の範囲を定義する必要があります。チームと問題の領域が同じである場合は、履歴値を使用できます。これは、多くの場合、最も可能性が低いものです。反復を実行して、実際にプロジェクトに取り組んでいるチームから速度のアイデアを得ることができますが、これはコストがかかり、プロジェクトの開始に同意するかどうかを決定する必要がある場合は機能しません。または、予測を行うこともできます。

速度を予測するには、スプリントに相当するストーリーを取得し、ストーリーを完了するために実行されるタスクに分割する必要があります。設計、開発、テストなどを含む各タスクにかかる時間を見積もり、特定のスプリントでチームがどれだけの能力を持っているかを評価します。障害のないチームの70％の容量は、適切なベースラインです。したがって、単純な状況で、チームが利用できる合計時間が次の場合：

4人のチームメンバー*2週間*週40時間=320時間
70％の容量を掛けた値=224時間
すべての機能タスクを合計し、224でカウントを停止します
完成したすべての機能を取得し、それらのストーリーポイントを合計すると、速度が得られます。たとえば、36
どちらかの側に20％を適用して、最低と最高の範囲を取得し、29〜43ストーリーポイントの推定速度に到達します。

速度は通常、最初の2〜4回の反復で変化し、その後、小さな範囲のポイント内で安定します。したがって、スプリント1の前の初期範囲が29から43であった場合、スプリント4までに、34から38に横ばいになる可能性があります。これにより、最終的な完了日を予測する際の信頼性が高まります。

リスクと不確実性のためのバッファリング計画

すべてのソフトウェアプロジェクトには、ある程度の不確実性が伴います。プロジェクトを進めるにつれて、その不確実性は少なくなり、テクノロジー、環境、パフォーマンス、および顧客とユーザーのニーズについてより多くのことが知られています。

この不確実性またはリスクは、スケジュールのバッファーを使用して軽減します。これにより、見積もりの誤差と、開発を開始する前に判断できない未知数が考慮されます。

通常、バッファタイプには機能とスケジュールの2つがあります。固定納期の固定価格を定義することが多いため、機能バッファーを使用することをお勧めします。

このアプローチは、信頼できるリスク軽減戦略を提供し、プロジェクトが完了したときに結果として何を期待すべきかについて顧客に自信を与えます。

機能バッファ

機能バッファーを使用すると、特定の機能セットを提供することを予測していますが、理想的には、さらに一連の機能を完成させます。これは、少なくとも、実行可能な製品を発売するために顧客が必要と考える最小限の機能セットを反映している必要がありますが、さまざまな内部および外部の影響がすべて許せば、より多くの機能が時間枠内に提供される可能性があります。

したがって、顧客は、最大100ストーリーポイントを追加する、製品バックログからの最も優先度の高い機能が最も重要であると判断する場合があります。次に、さらに30ストーリーポイントになる追加機能を検討する場合があります。したがって、チームは130ストーリーポイントの提供に基づいて計画を立て、特定の固定価格契約の完了予定日の終わりまでに最低100ストーリーポイントを完了します。

いくつかの締めくくりの考え

アジャイルは、完全に把握して採用するのが非常に難しい概念になる可能性があります。これは、価格、範囲、期間などのデリケートなトピックを管理する場合にも当てはまります。残念ながら、私は、要求の厳しいクライアントがすべてのものを前もって修正することを望んでおり、すべてが解き始めたときにサプライヤーを非難することを熱望していることを直接知っています。同様に、私は、かかとを掘り下げ、応答しなくなり、顧客のニーズに応答できないベンダーを認識しています。アジャイルパスを取ることは、基本的に信頼、良好な関係、および優れたコミュニケーションに基づいています。これらは、関係者全員の平等な利益、満足、成功のために健全なプロジェクトを維持するために、両当事者が保持する価値観でなければなりません。コラボレーションと交渉に対してオープンマインドと建設的な態度を保つことは、関係が悪化するのを避けるための最良の方法です。

私は、アジャイルの適応性を受け入れ、コマンドアンドコントロールの姿勢を放棄することが難しいと感じているクライアントと協力してきました。あなたが知らないチームにあなたのすべての信仰と信頼を手放して置くのは難しいです。多くの場合、クライアントは、提供される内容の仕様として、すべての要件を事前に作成することを希望する場合があります。これにより、プロジェクトの範囲が明確に定義されているという自信が得られます。しかし、最終的には、これは成功したアプローチとして実現できません。契約の範囲と非現実的な要求に縛られている場合、問題は非常に迅速に発生します。

従来の方法でこのアプローチを採用すると、スコープが変更されたり、未知のものが明らかになったり、お客様が望んでいたことがもはや真実ではなくなったり、マークから外れたりすることがわかります。価格設定、計画、および範囲に適応的なアプローチを採用することで、顧客は自社の製品が市場のニーズにぴったり合っていることを真に特定できます。これにより、ベンダーは応答性、想像力、効率性も向上します。契約交渉を通じて顧客とベンダー間のコラボレーションを活用することが重要です。

ベンダーは正直である必要があり、顧客は最初から何を達成できるかについて現実的である必要があります。非現実的な目標を約束し、その後コストを増加させるベンダーは、最初の契約を勝ち取る可能性がありますが、不満を持つ顧客からすぐに支持を失うことになります。多くの場合、当事者間の信頼や信頼の欠如が原因で関係が崩壊します。信頼は最初から構築され、プロジェクトの全過程を通じて維持されなければなりません。ベンダーは柔軟性があり、変化するニーズに協力する必要があります。顧客は常にもっと欲しがっています。それはビジネスを行うことの自然な結果です。双方の間で平等で有益な価値交換がなければなりません。顧客にとって、彼らは自分たちのビジネスに価値を創造しようとしています。ベンダーにとって、彼らは顧客との長期的な関係を形成することによって価値を創造することを目指すべきです。アジャイルマニフェストの価値観と指針を守ることは、強力でバランスの取れた長い関係を形成するための健全な基盤です。

概要

これにより、アジャイルソフトウェアプロジェクトの価格の計画、見積もり、および定義についての洞察が得られたことを願っています。上記のすべてのアプローチと手法は、チームへの信頼を構築し、ソフトウェア製品の構築にかかる時間と所要時間について顧客の心に自信を持たせるように設計されています。そして最終的には、続行する決定を下す自信を築くために。

これらのガイドラインに従ってください。そうすれば、ソフトウェア製品に命を吹き込むための満足のいくルートを見つけることができます。