従来のウォーターフォール手法からアジャイル手法への移行
私の開発チームは「アジャイル化」の過程にあり、多くの人々がお互いを何も考えずに見ています。すべての経営陣は、特定の方法論を提案せずに「アジャイルで作業を開始する」と言っているので、彼らは私たちが自分で何かを考え出すことができるかどうかを確認するのを待っています。誰かが以前にこの状況にあったことがあり、どのようにそれを処理しましたか？すべきこと、すべきでないことはありますか？私はチームの上級メンバーの1人なので、イニシアチブを示すことが期待されています。ある方法でうまくいくと、別の方法ではうまくいくとは限らないので、正しいアプローチで自然に結果が得られると思うので、最終結果ではなくアプローチにもっと興味があります。
（まだ行っていない場合）まず、 Scrum や [〜＃〜] xp [〜＃〜] 彼らの哲学、アプローチ方法、ツール、方法についてのアイデアを得る。
これらについてチームメンバーおよび管理者と話し合い、どのプラクティスがあなたに適しているか（適切でないか）を決定します。
例えば。管理者がペアプログラミングに反対している（本当または架空の理由で）か、エンドユーザーがチームワークと計画セッションに物理的に参加できない可能性があります。それについて際限なく議論する意味はありません。最初のプロセスから除外する方が良いでしょう。
（あなたは確かに絶対に必要な管理サポートを持っているようです、非常に良いことです-しかし、このサポートが困難に直面してもあなたと一緒にいることを確認する必要があります。このため、管理者が実際にアジャイル大まかに意味し、そこから何を期待するか（しないか）。）誰にでも受け入れられる簡単な最初のルールセットで、それを始めましょう。エッジが粗い場合は問題ありません。最初のプロセスを定義し、できるだけ早くそれを実践してください。新しいプロセスと考え方に慣れるには時間が必要なので、混乱の初期の期間、混乱、そしてその後の生産性の低下を期待してください。あなたの努力が実を結び始めるために、あなたはこれらの数週間と数ヶ月生き残る必要があります。
プロセスに絶対に含める必要がある1つのことはretrospectives：での定期的な会議議論する各反復/スプリントの終わり- 何がうまくいったか（続く）
- 何がうまくいかなかった（止められるか、より良いものに置き換えられる）、
- 何がより良い方法でできるか。
これにより、いくつかのアクションポイントが連続して微調整され、プロセスが改善されます。
結果*は、さまざまな方法論からのアイデアと実践の「奇妙な」混合である可能性がありますが、それは、独自のチームとプロジェクトに合わせて調整された、独自の個人的なプロセスになります。
*実際には、進化の過程に最終結果がないのと同じように、「最終結果」はありません。プロセスの改善は決して終わりません。状況の変化、プロジェクトの変化、チームメンバーの変化、そして適切なアジャイルプロセスがこれらすべての変化に適応し続けます。
私たちが行ったいくつかのことは、私たちの移行に役立ちました。
アジャイルコーチ：私たちの移行（これまでのところかなり成功しています）に最大のメリットをもたらしたのは、外部から誰かを助けてもらうことです。幸運にも、私たちのために働いていた賢くて尊敬される仲間がいくつかの異なるアジャイルショップで働き、成功と失敗を経験しました。アジャイルへの切り替えを提案、計画、そして最終的に実行するのを助けるために、私たちはしばらくの間彼を捕らえました。入って来て、彼は私たちのビジネスと私たちを特別な/違う/難しい/何であれ私たちにさせるもの、そしてアジャイルをよく理解しているものをよく理解していました。彼は人々と話をし、最終状態のモデルを検討し、移行計画を検討し、コストとメリットを確実に理解するのにかなりの時間をかけました。
移行チーム-これが私たちに適していることがわかったら、アジャイルコーチの指導の下で、部署のほとんどの機能分野の経験豊富な人々で小さなチームを編成しました。このチームはアジャイルチームとして機能し、移行のために計画または実行する必要があるものをモデル化するバックログがあります。メンバーシップはかなり静的です。チームメンバーには、「デイジョブ」と移行チームの職務があります。集合的に、チームはほとんど全員を知っており、人々を刺激するものを理解し、会社の隅々で私たちが使用しているプロセスを理解し、そして私たちが物事を変え始めると何が壊れるでしょうか。
エグゼクティブサポート-これがもたらす違いに驚いています。私たちにとって、アジャイルになりたいという願望は、組織と組織内の個人の両方に認められた利益に基づいて、トップから来ました。私たちが人々にインタビューするとき、アジャイルに行こうとしているほとんどの場所は、管理サポートまたはリップサービスの欠如にもかかわらず、行こうとする草の根のアジャイルムーブメントを持っているようです。仕事への取り組み方は劇的に変化します。上からのサポートがなければ、移行がどのように成功するか想像できません。あなたはこの方向に経営陣から押し込まれています。彼らは「ただアジャイルでいてください」以上のものを望んでいると思います。彼らはそれから特に何かを望んでいます。
移行自体はトリッキーな獣です。アジャイルのもとで私たちが重視するこれらすべてのプラクティス（ストーリー、チームは推定を行い、反復を設定し、利害関係者にアクセスし、テストと継続的な統合に焦点を当てるなど）は非常に重要ですが、遷移それらを使うのは難しいです。それ自体がプロジェクトです。私たちは平均的なサイズのスクラムチームがたくさんいる中規模の場所なので、実際の走行距離は異なる場合がありますが、コンセプトは引き続き適用されると思います。
現在の方法論を突然落とさないでください。代わりに、一度に1ステップずつ俊敏になるように調整します。現在の方法論は、より機敏な内部フレームワークに構造を与える外部フレームワークにすることができます。
- 管理および運用ドキュメントを簡素化する方法を見つけます。プロセスからいくつかのドキュメントを削除します。
- リリースから展開までのサイクルを短縮します。 6か月を超えるスケジュールのプロジェクトを、3か月ごとにリリースされるいくつかのバージョンに変更し、次のバージョンの作業を開始する前に、計画と機能を改訂します。
- ストーリー、シナリオ、またはユースケースを機能単位として使用し、開発者にそれらを推定させ、それらの推定に基づいてプロジェクト計画を立てます。
- 2〜4週間の反復で実用的なユースケースを提供することを計画します。
- 計画された機能と実際の機能（理想と実際の速度を合わせたもの）を測定し、それに応じて一般的な計画とそれに続く反復を変更します。
- 機能テストの自動化に投資し、それらのテストの実行を日常業務の一部にします。
- 単体テストとそれを使用する個人コード統合プロセスを紹介します。開発者が共有リポジトリのコードを壊さないようにしてください。
- アジャイルに移行するには、クライアントまたはユーザーを代表する人々への頻繁で迅速なアクセスが不可欠であることを経営陣に伝えます。質問への回答は、機能がリリースされた後ではなく、構築されているときに必要です。
- ペアプログラミングができない、またはできない場合は、少なくとも開発者にシステムのさまざまな部分でさまざまなイテレーションを行わせるようにしてください。これにより、すべての人がコードをレビューできるようになり、システムコンポーネントとテクノロジーに関する誰もが知っている知識が増えるため、コンポーネント/モジュールの所有権のリスクが軽減されます。
- 最初は、リスクの少ないパイロットプロジェクトから始めます。
私はソフトウェアチームや企業に俊敏性を導入することについて相談しましたが、うまくいったのは、彼らがすでに行っていることの中心に、アジャイルな方法を徐々に導入することです。キーワードはsimplifyおよびiterate（アジャイルの導入プロセスにも適用されるもの）です。
アジャイルはすべて短いイテレーションであり、変更に反応し、常に実行可能なバージョンを持っています。残りは、多かれ少なかれ、次から次へと読んで実行できる詳細です。私は以下を読むことをお勧めします：
私の開発チームは「アジャイル化」の最中です
悪魔の擁護者を1分間プレイする：なぜ？
間違っているとは何をしているのですかすでに？
アジャイル（または他の）の作業方法に移行すると、現在実行しているよりもbetterでジョブを実行できますか？
この作業から得たいと思う利点を評価できない場合（そして、方法論間での変更は多くの作業です！）、なぜあなたの時間を無駄にしているのですか？
あなたが達成したいことの明確な考えがなければ、あなたはそれを実現するのに本当に苦労するでしょう。そして、「アジャイル」チームとして自己組織化することをあなたに明確に期待しているあなたの経営陣は、おそらくあなたが現在そうしているよりもはるかに長く生産するために「はるかに」長くかかると「感心するよりも少ない」でしょう。
アジャイルはnot Magic Bulletです。はい;一部のタイプの開発（ほとんどの場合、ユーザーが見たり運転したりするのが好きな「光沢のある」フロントエンドのもの）には適していますが、他の多くの種類（バックエンド「すべてのシステムに必要ですが、だれも行きたくないものです。