前書き

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

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

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

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

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

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

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

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

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

1. プロジェクトの開始時に修正する機能が、実際にビジネスや顧客に最も役立つ機能であることをどのように知っていますか？多くの場合、機能やスコープが変更されます。そのため、「スコープクリープ」について耳にします。これは、プロジェクトのライフサイクルを通じて特定され、必要または必須として決定される、望ましいニーズの結果です。

2. コストが変動するようになると、達成しようとしている投資収益率（ROI）を制御できなくなります。コストの増加は、多くの場合、未確認のリスクまたは要件の変化の結果です。つまり、同じ時間枠でより多くの作業を行うため、またはチームメンバーをより長く保つために、チームメンバーを追加する必要があります。どちらも望ましくない

3. 時間が変動する場合、私たちは市場での地位をコントロールできなくなります。おそらく、私たちは重要な業界の日付を見逃しているか、競合他社が私たちの前に製品を出しているため、私たちのプロジェクトが持っていたかもしれない競争上の優位性を失っています。

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

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

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

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

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

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

したがって、アジャイル契約は以下に焦点を合わせています。

ラズベリーパイを実行する方法

• 固定価格のワークパッケージ -プロジェクト全体が論理的な「ミニ」リリースに分割され、製品全体の成果に貢献します。各リリースは、それに応じた価格のワークパッケージです。作業パッケージが完成すると、前の作業パッケージから学んだことに基づいて、将来の作業パッケージが再推定されます。これにより、不必要な不測の事態が回避され、顧客が一定レベルの再優先順位付けと新機能/改訂機能を定義できるようになります。

• 早期終了 -これにより、十分な量の製品が提供され、わずかな利益しか提供し続けないプロジェクトチームを維持することによって達成されるROIがそれ以上ない場合、顧客はプロジェクトを早期に終了しようとすることができます。この条項は通常いつでも許可され、プロジェクトチームと顧客が強力で信頼できる緊密な協力関係を維持している限り有効です。お客様にとってのメリットは、製品を実行可能にするために必要なすべての貴重な機能を提供して、プロジェクトが早期に終了することです。その見返りとして、サプライヤーには残りの契約額の20％が支払われ、スタッフを維持するリスクが相殺されます。

• 柔軟な変更 -変更は、アジャイルソフトウェア配信の流れを強力に貫くテーマです。私たちは、製品を最初から成功させるために必要なすべてを知っているわけではないことを期待しています。そのため、関連するデータとフィードバックに基づいて変更を推進し、適切な製品が確実に提供されるようにします。イテレーションの最後に、変更を交換して、不要または優先と見なされなくなった古い機能に置き換えることができます。変更の価値が等しい限り、それ以上のコストはかかりません。変更の価値が低い場合は、追加の作業を特定するか、残りのバックログから繰り越すことができます。この条項は、プロジェクトチームと顧客がプロジェクト全体を通じて強力で信頼できる緊密な協力関係を維持している限り有効です。

• 余分な仕事 -プロジェクトの存続期間を通じて、既存の固定価格契約では達成できない機能がさらに特定される可能性があります。このシナリオでは、新しい価格の作業パッケージをプロジェクトの最後に追加するか、時間と材料に戻すことができます。

• 遠隔推定 -アジャイルプロジェクト契約で見積もりを範囲指定できる方法は2つあります。期間の範囲または機能の範囲です。期間の範囲により、プロジェクトまたは作業パッケージが特定のスコープのセットに対して12〜16週間かかると見積もることができます。ただし、期間を追加すると、プロジェクトチームのメンバーを長く維持するためにコストが増加します。つまり、他の開発プロジェクトで作業するためにメンバーを解放することはできません。 ApeeScapeでは、スコープを変数として維持しながら、作業パッケージまたはプロジェクト全体の一定の時間枠内で顧客に最小レベルの価値を提供することを約束して、さまざまなストーリーポイントにわたって機能を範囲指定することを好みます。

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

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

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

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

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

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

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

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

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

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

2.提案

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

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

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

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

3.リリース計画

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

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

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の少なくとも半分のサイズです。

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

物語	サイズ
に	1
B	5
C	3
D	1
IS	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ストーリーポイントを完了します。

いくつかの最後の考え

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

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

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

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

m＆aは構造を獲得します

概要

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

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