アジャイルソフトウェア開発は、契約で定義されたプロジェクトで使用できますか？

私は最近、仲間の開発者とアジャイルソフトウェア開発について話し合いました。私はその原則を理解していますが、要件が絶えず変化することで、プロジェクトが永遠に続く可能性が生まれるようです。しかし、少なくとも私が働いている場所では、プロジェクトは契約であるため、完成する必要があります。

つまり、一部のプロジェクトでは顧客が不完全なアプリケーションを使用できないため、最初の反復には数か月かかる場合があります。一部のプロジェクトでは、最初に終了を定義する必要があり、それを反復に分割し、各反復後に定義を改良する必要があると思います。ただし、常にこの定義が必要です。

アジャイルソフトウェア開発が要件の変化を受け入れる場合、それがどこで終わるのかをどのように知るのですか 最終結果が常に変化する場合、どのようにプロジェクトの予算を立てることができますか？

アジャイルソフトウェア開発は、アジャイル製品というよりもアジャイルプロセスに関するものですか？

OPのコメントから、彼は私がクライアントに開発サービスを提供しているコンサルティングショップで働いているようです...私はこのマインドフレームが彼/彼女の混乱を引き起こしているからだと思うので...よく知っているが、事実を述べたことはない。

アジャイルは、契約で定義されているソフトウェア開発と互換性がありません。

• 契約は厳しくする必要があります。Xを支払い、Yを支払います。X+ Mを支払い、Y +（M * N）を支払います
• 契約は満たす必要があります（IEはオープンエンドではありません）。（連絡先が関与している場合は、厳密な変更管理プロセスを実行する必要があります。）

多くのコンサルティングショップがアジャイルを主張し、嘘をついています。彼らは、アジャイルがバズワードステータスを獲得したからと言っています。

アジャイルは、プログラマーが常勤であり、予算についてほとんど語らない内部開発に最適です。ちょうど時間枠と機能。

最初に最も重要なこと（と思われること）に集中している場合、プロジェクトは次の場合に終了します。

• 予算を立てました。
• 予算を設定しました。
• 何かを追加したり変更したりする必要はもうありません。
• 最も優先度の高い変更の次のバッチは、コストがかかるだけの価値はありません。

ビジネスがそれ以上の反復を希望しないと判断したときに停止します。これは、かなりの量の価値が提供された後、収益の減少の領域に踏み込みすぎる前であることを望みます。

それはあなたの状況で意味するものは何でも「ビジネス」によって常に駆動されるべきです。ソフトウェア開発ショップの上級管理者、または社内開発環境の実際のビジネススポンサーである可能性があります。彼らは、次のイテレーションのコストが次のイテレーションで提供される機能の利益を上回る時期を決定します。

決して、それはそれの美しさです。

プロジェクトは決して終わらない。別のリリース、別のマイルストーンに到達しましたが、お金が流れている限り、追加する機能、改善するためのピース、修正するバグが常に1つあります。プロジェクトは、不要になると死にますが、終了することはありません。要件->プロジェクト->製品->終了のウォーターフォールモデルとは対照的に、これは、あなたが支払いを受けている限り、永遠に回転するループです。

このテクノロジーの頻繁に言及されるビジネス機能ではありませんか？

ここには誤解があります。アジャイルはプロジェクトの要件を変更することを奨励していません。代わりに、作業を無駄にしたり、開発の重要な領域を犠牲にすることなく変更を行うことができます。

エンジニアリングプロジェクトには4つの基本的な制約があります。範囲、コスト、時間、品質。Waterfallは、これらが静的であることを前提としています。それは間違った仮定です。これらの1つ以上は常に変更されます。スコープクリープ、予算の削減、およびその他の「未知の未知数」は、常にプロジェクトを妨害し、制約を変更します。ウォーターフォールはこれを予期していません。そのため、それが起こると、プロジェクトは望ましくない形で変化します。まだ追加されていない重要な機能がなくなるか、すぐに完了するか、リリースを遅らせる必要があるか、PMが新しい開発者にお金を投じて適切に処理するためにバルーンの費用がかかります。

対照的に、アジャイルは制約の変更を許可し、実際にそれを期待しています。これは、所有者の優先順位に従って、使用可能な小さなチャンクで作業を行うことでこれを行います。したがって、チャンクはプロジェクト所有者にとってすぐに役立つことが理想的です。したがって、未知数が大きい時間枠で大きな計画を立てないことにより、未知数への露出を減らします。タイムラインが変更された場合、チームを追加したり、重要性の低い機能を「対象範囲外」にしたり、チームが既に構築したシステムに影響を与えたりすることはできません。

また、指定されたスコープを必要な品質で生産するために必要な時間とコストのより良い見積もりを提供します。人々は大きな仕事を見積もるのが悪名高い。適切に行うには、多くの経験と、より多くの事前の計算が必要です。対照的に、人々は一般に、1日、1週間または2週間で何ができるかを判断します。これにより、安定した状態が迅速に生成され、過去のペースに基づいて、かなりの正確さで、残っている作業の時間とコストを推定できます。

エンドポイントの定義に関しては、あなたは正しいです。アジャイルプロジェクトは永遠に続くことができます。ただし、従来のSLDCも同様です。クライアントはしばしば、より多くのお金とアップグレードのウィッシュリストを持って戻ってきます。違いは、プロジェクト全体を見ると、「分析」、「設計」、「開発」、「保守」の間に明確な線が存在しないことです。それはすべて、レンガごとに、スプリントごとに行われます。所有者がプロジェクトを「完了」と呼びたい場合はいつでも可能です。また、支払い済みの「レンガ」の合計が「壁」に収まっています。当初の計画ほど高くない場合もありますが、しっかりと設置されており、仕事をこなし、後日最小の分解で追加できます。

すべての機能が実装され、すべてのバグが修正されると終了します。

期限が修正され、要件も修正された場合。その後、これは問題になりません。ただし、期限が修正されていても要件が変更されている場合は、プロジェクトを正常に進めるために行うべきことがあります。

固定価格パート1、何がそんなに悪いのですか？

固定価格パート2、アジャイルで修正！

アジャイル開発の背後にある大きな仮定は、どの方法論を使用しても、要件は常に変化しているということです。もちろん、要件文書を作成し、それを実行する計画を作成し、最後に配信することもできますが、要件は変わらなかったように見えるかもしれません。彼らはあなたの計画で変わっていないかもしれませんが、市場の変化と製品に対するあなたとあなたの顧客のより良い理解によって、顧客が望むものに関する要件は変わるでしょう。アジャイルがやって来て、これらの変更を固定スケジュールで隠さないプロセスを提案しますが、代わりにプロセスへの避けられない変更への対応を構築します。

完了したら、固定スケジュールの終了から、顧客が現在の状態でソフトウェアを出荷および販売できる十分なビジネス価値を提供できる場所に製品が移る時期に移行します。実行されることは、スケジュールを順守する方法ではなく、提供する価値に大きく結び付けられます。