プロジェクトのスコープが設計され、正式なウォーターフォールプロセスを使用して最終的にコード化される大規模なエンタープライズアプリケーションがあります。コードの同じセクションにあるという理由だけで、関連のないイニシアチブのコード変更が頻繁に与えられます。すべてのイニシアチブは同時に引き渡される必要があります。開発チームは、範囲や納期についてもほとんど発言していません。ビジネスを知らない要件収集のグループを通過する必要があるユーザーと話すことはできません。
そのような定着した環境に最小のアジャイル技術を実装する方法について、誰かがアドバイスを持っていますか？
少なくとも、単体テストの作成を開始することも、状況が許す限り、テスト駆動開発を自分で作成することもできます（おそらく、他の共同開発者にもアイデアを広めることができます）。あなたは何にも気づかなくても管理者なしで多くを変えることができます;-)
もちろん、平均的またはより良い場所では、経営陣の人々は完全に愚かではありません。時間が経つにつれて、開発チームの間でこれらの問題についての認識を高めることができたとき、あなたは（チームとして）上級管理職にも話しかけ、正しい方向に向かって一歩を踏み出すように説得することができます。小規模から始めて、具体的な結果を取得し、それらに基づいて構築します。開発チームと（可能な限り）管理者とユーザーの両方で仲間を見つけることで、レバレッジを構築します。
非常に多くの場合、特定のプロセスは、「私たちは常にこのように行っていた」という理由だけで実行されます。より良い方法があることを人々に示し、説得力のある議論でそれを証明できれば、成功する可能性は十分にあります。管理者とユーザーは、開発者とはまったく異なる議論を必要とすることに注意してください。大まかな費用便益計算を試してみることができます（またはグーグル-これらについてはネット上にたくさんのものがあると確信しています）。また、ケントベックの最初のXPの本には、これに関する優れた資料があることを覚えています。また、時間の経過とともに（うまくいけば）アジャイルな方法で開発された機能の欠陥が後の（統合テストまたは本番）フェーズで著しく少ないことを示すバグ統計を収集することもできます。（このためには、欠陥追跡システムが必要です（まだ持っていない場合）。）
もう1つの便利なツールは、質問をすることです。あなたが何か-文書、物事のやり方-あなたが理解していないなら、あえて質問してください：
多くの場合、人々は物事を「与えられた」ものと見なしますが、原因を尋ね始めると、興味深いものがたくさん見つかるかもしれません...そして改善のためのアイデア。
非常に便利なアジャイルツールは回顧展です。各反復（実際のプロセスで呼び出されるものは何でも）の後、チームは集まり、ブレインストーミングを行います。
これは経営陣に受け入れられるのはかなり簡単かもしれませんし、前向きな変化を始める良い方法です。最も重要なことは、人々を目覚めさせ、活性化させることです。プロジェクトの成功または失敗は（少なくともある程度は）自分の手に委ねられていること、状況を改善するために何かできることを全員に認識させることです。
私の経験では、大企業はリスク、予測可能性、および測定可能な結果に関心を持っています。アジャイルが既存のプラクティスよりもこれらのメトリックとどのように整合しているかを示すと、アジャイルを導入するのが簡単になります（簡単ではないかもしれませんが）。
まだ出荷していない場合でも、頻繁に出荷できるようにします。CIツールと自動ビルドスクリプトを活用して、アプリケーションをビルドおよびパッケージ化します。このようにして、出てくる可能性のある新しいコードを段階的にリリースする機会を利用する準備ができています。
ベースラインが得られるように、今すぐ生産性を測定してください。測定できる量が多いほど、より良い結果が得られます。
アジャイルプロセスの下でこれらのメトリックの変更を予測します。たとえば、ほとんどの場合、バグを見つけるのが早ければ早いほど修正が容易/安価になるため、TDDとQAへの迅速なリリースのメリットを簡単に定量化できます。
小さく始める：ウォーターフォールスケジュールが渡される場合がありますが、それでも反復に分割できるので、そうしてください。エンジニアリングの実践を整えてから、プロセスの調整を試み始めます。概念実証として、小さな補助プロジェクトでアジャイルを試すことができるかどうかを確認してください。
スポンサーを探す：アジャイルのメリットについて、自分よりも順位が高い人を説得してみてください。意思決定者に馴染みのある言葉で「アジャイルvs.ウォーターフォール」の議論を組み立てるのに彼らの助けを借りてください。
しばらくお待ちください...結果が表示されるまでに時間がかかる場合があります。
...またはしないでください。アジャイルに深く興味があり、サポートがゼロの場合は、新しい仕事を見つけてください。はい、獣の腹から変化をもたらすことはやりがいがありますが、ソフトウェアの構築についてのあなたのアイデアを共有する人々と協力することもやりがいがあります。
アジャイルとは、これらの滝の壁を壊すことです。BDUF; 同時マルチコンポーネントリリース。開発者とビジネスプロセス所有者の間のコミュニケーションの欠如。計画された反復-これらはすべて、ウォーターフォールプロセスの邪魔になります。
私の立場では、これらの壁の多くを壊しました-そしてそれは顧客に直接アクセスすることから始まりました。それが起こったとき、顧客はより良い製品を手に入れました。それはより幸せな顧客につながりました。それはBDUFなどのようなものを追い払った。
真のイテレーション/スプリント、継続的インテグレーションなどはまだありませんが、そこに到達しています。（古い習慣、そしてそのすべて。）
開発チームとしてのあなたは、アジャイル手法（テスト駆動開発、ペアプログラミング、ストーリーカード、CI、共通言語など）を使用して内部で調整することができます。
私の頭の中の敏捷性とは、ソフトウェアの変更に自信を持ち、ウォーターフォールルートを3歩下る必要のない機能への大規模な誤投資を防ぐことです。ここでは、テストとリファクタリング、および過剰設計の回避が重要です。
私には、問題はアジャイルではなくウォーターフォールを使用していることではないようです。ウォーターフォールの実装には大きな問題があるということです。最も明らかに：
ビジネスを知らない要件が集まります
ウォーターフォールは、適切に実行されればうまく機能します。関係者の中には、概念的なプロセスではなく、彼らのやり方が間違っているように思えます。
ドメインによっては、自動テストと継続的インテグレーションが実行可能である必要があります。
また、現在割り当てられているタスクについて、独自の非常に詳細なバーンダウンリスト（インチストーン）を作成することを検討してください。これにより、作業の見積もりがより予測可能になり、スケジュールのずれや計画外のタスクを簡単に説明できるようになります。
一般に、システム内のいくつかのメトリックを追跡します。アジャイル手法が付加価値をもたらすことを示すことができれば（サイクルタイムの短縮、欠陥率の低下など）、その手法でリーダーシップを売り込むのは簡単です。
...マネージャーによっては、「アジャイル」という言葉を実際に使用することは避けたい場合があります。特に、1つの手法を使用して小さな勝利を求めている場合はなおさらです。