稼働中のシステムを交換する場合、アジャイルはどのように機能しますか？
理想的なアジャイルの世界では、目的のエンドシステムの小さくても便利なサブセットをすばやく構築し、ユーザーに提供します。彼らはそれが便利であるので興奮しています、彼らはそれを使い始めてフィードバックを与えます。次に、それに何を追加するかを検討し、それを構築して、時間がなくなるまで繰り返します。
私は最近、いくつかの種類の作業システムを置き換えることを含むプロジェクトをいくつか持っています。上記のモデルはまったく機能しませんでした。既存のシステムの実質的にすべての機能を含むシステムを構築するまで、ユーザーはまったく興味がありませんでした。彼らはそれを使わないでしょう。
「最小の有用なサブセット」が「すべて」である場合、どのようにアジャイルを適用しますか？
アジャイルソリューションは、ではないかもしれませんすべてを一度に置き換えるのではなく、徐々に段階的に置き換えます。
古いシステムの一部を稼働させたまま、新しいシステムを少しずつ導入します。古いシステムは一度にすべてオフにされるのではなく、単に消えていくだけです。新しいパーツは新しい機能やその他の利点を提供するので、ユーザーはそれらを使用して喜んでいます。また、常に100％稼働しているシステムがあるため、これもリスクが低くなります。
- Martin Fowlerの続きを読む 。
- Michael Featherの戦略 レガシーコードを効果的に使用する は役立つ場合があります
既存のシステムを書き直すのではなく（新しいシステムが既存の機能と一致するまでにかなりの労力が必要になることをお伝えしました）、 絞首刑Vine アプローチを検討してください。基本的に、新しいアプローチを使用して新しい機能を実装します上に既存のアプリケーション。最終的に、古いシステムの欠点に対処して新しい機能に対処すると、新しいコードが古いコードを完全に置き換えます。
これには、古いアプリの「再起動」よりも多くの精度と労力が必要です。しかし、ROIまでの時間は短くなります。また、プロセスを実行する際に、フックを配置して、「新しい」システムを次の「新しい」システムに簡単に絞めることができます。
小さな増分を世界にリリースすることは、グリーンフィールドプロジェクトではうまくいくかもしれませんが、それでも少数の機能はあまり役に立ちません。
スクラムは、各スプリントの後に製品が「潜在的に出荷可能」であることを提唱しています。出荷する必要はありませんが、出荷可能な製品の品質が必要です。
アプリの増分バージョンをユーザーに提供したい場合は、実際の製品版アプリを引き続き使用しながら、アプリをアルファ、ベータ、リリース候補のバージョンに分類できます。
ユーザーからのフィードバックを組み込むと、新しい機能が追加され、古い機能が削除されることがあります。
私は、主要な全国ケーブルテレビネットワークの大規模な基幹業務アプリケーションの置き換えに取り組みました。新しいシステム開発はSCRUMを使用して行われ、ほぼすべての主要なサブシステムを再実装するための約18〜24か月の開発プロジェクトでした。 10歳に近づいていた。
開発が始まるまでに約6か月の計画段階がありましたが、SCRUMとしてもアプローチされました。これは、既存のシステム分析と顧客へのインタビューの後に、製品所有者が高級店とエピックを書いた場所です。
重要なメンテナンスモードに移行したため、既存のシステムは非常に安定していた。ストッパーの問題のみが修正され、すべてが履歴の目的で記録され、同じ問題が新しいシステムに表示されないようにするためにのみ表示されます。
新しいシステムはアジャイルプロセスで説明されているように進化しましたが、ほとんどの場合非常にスムーズでした。代替システムが機能の不一致に達したとき、それは本番環境に移行せず、並行して生産試験が行われました。重要でないワーカーのサブセットがbothシステムの使用を開始し、新しいシステムが古いシステムと同様に動作することを検証しました。もちろん、古いバグは修正されています。
新しいシステムがほぼ100％の新機能を完了したとき、それは一般的な並行生産の実行のために展開され、それは数ヶ月続きました。
お客様がニーズを満たしていると判断すると、古いシステムのバックアップを取り、電源を切り、座ったままにしました。カットオーバー後に古いシステムに戻す必要がなかったため、古いシステムハードウェアを再利用したと思います。
アジャイルはこのシナリオで多くの価値を追加すると私はまだ思います。
「現在のシステムを置き換える」という非常に明確な最終目標があるだけです。
アジャイル技術とプロセスはそこに着くより効果的です。
例えば：
それでも、システムを繰り返し、小さなスプリントで配信できます。
重要な人々とコミュニケーションした後でも、アジャイル技術を使用して作業の優先順位を付けることができます。
それでも、観測された速度に基づいて計画するためにアジャイルを使用できます。
知識の拡散、TDD、クリーンなコーディングなどのアジャイル技術と哲学を使用して、プロジェクトの品質と内部設計を強化できます。
本当にプロジェクトに「興味がない」人がいて、完全に入れ替わるまでプロジェクトに参加しない人がいる場合、ウォーターフォール、アジャイル、または実際にプロセスを使用しているかどうかに関係なく、より大きな問題が発生します。
同じように機能しますが、このアプローチは既存のユーザーに販売するのが難しくなります。彼らは新しいシステムを望んでおらず、定期的なテストに邪魔されることを望まないかもしれません。彼らはできるだけ長く待って、最後にそれをテストしたいのです。ほとんどのユーザーはある程度このように感じていますが、教育するのは担当者次第です。彼らの考えでは、あなたは既存のアプリケーションで作業しているので、あなたはそれが何をしようとしているのか、なぜそれらを気にするのかを知っているべきです？
楽しいと思うし、ウォーターフォールプロセスを使用して孤独になるので、このようにしたくないと彼らに理解してもらいます。長期的にはより良いアプリになります。
重要なセールスポイントは、彼らが常に望んでいた新しいアプリの構築中にその1つの変更を実装することであるかもしれませんが、古いシステムには決して入ることができませんでした。
古い錆びた車を運転するために運転する必要がある場合、私はディーラーに行き、新しい車を購入します。欲しいモデルは在庫がないので、工場から注文しなければならず、入荷まで少し時間がかかります。
その後、ディーラーは、誠意をもって、注文した車が入るまで車のエンジンブロックを提供することを決定します。車のエンジンはどうするのですか？確かに、いくつかのコンポーネントを接続してテストして機能させることはできますが、古い錆びた車が機能する明日の作業には役立ちません。
確かにfar車の作成とカスタムソフトウェアの作成には大きな違いがありますが、議論のためにそれを無視しましょう。話の要点は、クライアントがすでに仕事を完了するのに十分なソフトウェアをすでに持っているのに、クライアントが増分変更の使用を見つけられないことに当惑しないことです。それはすでに当面のニーズを満たしています。
アジャイルは、プロジェクトのステータスに関するクライアントへの継続的なフィードバックを可能にするため、ここでのプロセスの重要な部分ではないということではありません。彼らは主要なマイルストーンと成果物の前に進歩が行われていることを保証することができます。コストがかかりすぎて修正できなくなる前に、潜在的な問題を早期に特定できます。
たぶんあなたは自動車の顧客として、エンジンを見て評価し、本当に期待通りの結果が得られることを確認したいと思うかもしれません。おっと、実際には4気筒エンジンではなく6気筒エンジンが欲しかったのです。さっき言ったじゃないの？問題ありません。変更を工場注文に入れましょう。
新しいソフトウェアリリースを代わりに使用するのではなく、それを評価して、途中の各ステップに満足していることを確認することが最善の利益であるという考えをクライアントに売ります。