私はここでいくつかの同様の質問を読んでいますが、それらは同じではありません。パートナーから受け継いだプロジェクトには、範囲と納期が決まっています。私たちは現在、(フレームワークを提供する)方法を管理し、アジャイルにする方法を考えています。基本的にジャグリングするものが何も残っていない場合でも、たとえば、スクラムとそのプロセスは、適切な管理を行うだけです。 (本当の意味で)実際には俊敏ではありませんが、それを実現するためのより良い方法はありません。テスターが完了したタスクをすぐにテストする部門横断的なチームがあるため、ウォーターフォールは意味がありません。私は提案に非常に感謝します。
編集:私は繰り返します-私は見積もりなどについて尋ねていません、プロジェクトはその70%にあります。アジャイルアプローチが実行の管理に役立つかどうかを尋ねています-機能横断的なチームが手元にあるため、ウォーターフォールは意味がありません(テスターは完成した機能ですぐに作業できます)。
時間、予算、範囲
すべてのプロジェクトは、使用する ライフサイクル アプローチが何であれ、コスト、時間、およびスコープの トリプル制約 に対処する必要があります。あなたの場合、時間と範囲は固定されています。コストについては何も言われませんが、このプロジェクトをパートナーから受け継いでいるため、固定(または少なくとも上限あり)のコストもあるのではないかと心配しています。
未実施のリスク
これらの制約はプロジェクトを困難にし、あなたの人生を悲惨なものにする可能性があります。しかし、制約自体はプロジェクトを殺しません。それは プロジェクトを殺すリスク :予算、スケジュール、範囲が定義されたときに考慮されなかったリスク、または発生して制約が不適切になるリスク。
以下のリスクは頻繁に失敗につながります:
結論
私の見解では、アジャイルアプローチは 最大のプロジェクトリスクを予測してマスターする への最良のアプローチです。不確実性に早期に対処し、一定のフィードバックと具体的な進歩を得て、問題が発生した場合に可能な限り迅速に対応することができます。
したがって、アジャイルは問題ではなく、ソリューションの一部です。
追加コメント(コメントの合計)
プロジェクトが70%完了した場合、正確で透過的なバックログ、毎週のイテレーションサイクルによる頻繁な短期目標、毎日の短いスタンドアップなどのテクニックが、フォーカスを維持して軌道に戻るのに役立つと思います。そして、成果とやるべきことについての透明性は、信頼を取り戻すことができます。
この段階では、多くの新しいリソースを追加することは困難です。また、まったく新しいツールを使ってまったく新しいアプローチを学び始めるのは逆効果かもしれません。 アジャイルコア原則 を実用主義で採用する。
最後の発言:納期が遅れた場合に何が起こるかを理解することは価値があります:会社はいくつかの法的義務を失い、破産しますか?ペナルティはありますか?スコープについても同じです。すべての機能/ユーザーストーリーの中で、最悪の場合はコア機能の稼働後に配信できる、それほど重要ではないものはありますか?これらすべては、最終的にそれが必要とされる場合、交渉および損傷制御に役立つ可能性があります。
スコープが固定され、期限が固定されている場合、 あなたが試してみるのはコストだけです です。あなたは問題にもっと多くの人々を投げかけることができます(それは 実際には機能しません )、既製のソフトウェアを購入するか、品質を犠牲にすることができます。 ...または、固定範囲または固定期限のことについて人々の考えを変えることができます。
これはアジャイルの問題ではなく、すべてのプロジェクトの問題です。プロジェクトの実行方法を変更しても、固有の制約は変わりません。
はい、アジャイルなアプローチは仕事を成し遂げるのに役立ちます1。基本的に、スクラムは、意欲的な個人のグループが一緒に製品を提供するための方法を提供します。スクラムは、大きな作業を小さな部分(エピック、ストーリー、タスク)に分割し、それらの小さな部分に取り組むためのフレームワークを提供します。
スクラムは、チームが常に改善するためのフレームワークも提供します。最後に、プロセスを可視化して、利害関係者がプロジェクトの進捗状況を確認できるようにします。
1 アジャイルなアプローチは、作業を整理して実行するのに役立ちますが、時間どおりに、または予算どおりに完了することを保証できません。アジャイルは、予算や期限に重点を置くのではなく、適切な製品を提供することに重点を置いています。そうは言っても、固定された範囲と固定された期限があっても、作業を行うためにチームを編成するためのツールとして、それは間違いなく役立ちます。
あなたが提供した詳細を考えると:
アジャイルは理にかなっていると思いますが、スクラムではありません。あなたはおそらく Crystal Clear のようなもっと軽量なものをしたいと思うでしょう。これについて簡単に説明します。
リードデザイナーと他の2〜7人の開発者…広い部屋または隣接する部屋で...ホワイトボードやフリップチャートなどを使用して...エキスパートユーザーに簡単にアクセスでき、...気を散らさず、ランニングを実行し、テスト済み、ユーザーが使用できるコード…毎月または2か月(最低でも四半期)、...定期的に作業規則を反映および調整します。
スクラム手法は、以前の経験に基づいて配信スケジュールを予測できるように設計されています。つまり、実際に機能するソリューションの作成を開始すると、それによって生成されたデータを使用して、さらに多くの時間を予測できます。あなたはこれを続け、より多くのデータを取得し、それを使用して傾向を測定します。
あなたの言っていることに基づいて、結果を予測することがあなたのプロジェクトにとって非常に重要であるとは思われません。重要なのはそれを成し遂げることです。アジャイル用語で言うと、70%が完成したと言います。つまり、70%の機能が本番稼働または本番稼働の準備が整っていることを意味します(前者は後者よりも信頼性が高くなります)。スクラムを始めたい。それ以外の場合は、もっと軽量なものを実行します。
これはすべて、スコープや配信について交渉する余地がないことを前提としています。できれば、まったく別の話です。通常、これらの状況では、納品が遅れ、最終的にはある種の議論を強いられます。通常、クライアントは訴訟よりも何かを取得することを好み、より多くの時間が与えられます。