稼働中のシステムを交換する場合、アジャイルはどのように機能しますか？

理想的なアジャイルの世界では、目的のエンドシステムの小さいながらも有用なサブセットをすばやく構築し、ユーザーに提供します。彼らは興奮している、なぜならそれは便利だからだ。彼らはそれを使い始め、フィードバックを与える。次に、何を追加するのかを考え出し、それを構築し、時間がなくなるまで繰り返します。

私は最近、いくつかの種類の作業システムの交換を伴うプロジェクトをいくつか行ってきました。上記のモデルはまったく機能しませんでした。既存のシステムのほぼすべての機能を含むシステムを構築するまで、ユーザーはまったく興味を持ちませんでした。彼らはそれを使用しません。

「最小の有用なサブセット」が「すべて」の場合、どのようにアジャイルを適用しますか？

アジャイルソリューションがあるかもしれないではない一度にすべてを置き換えるために、徐々にで交換相に。

古いシステムの一部を実行したまま、少しずつ新しいシステムを徐々に導入します。古いシステムは一度にすべてオフにされるのではなく、消えていくだけです。新しいパーツは新しい機能やその他の利点を提供するため、ユーザーはそれらを使用して喜んでいます。また、常に100％稼働しているシステムがあるため、これはリスクが低くなります。

• マーティン・ファウラーの詳細をご覧ください。
• マイケルフェザーのレガシーコードを効果的に使用する方法の戦略は有用です。

既存のシステムを書き直すのではなく（前述のように、新しいシステムが既存の機能と一致するまでにかなりの労力が必要になります）、絞め殺しのアプローチを検討してください。基本的に、既存のアプリケーションの上に新しいアプローチを使用して新しい機能を実装します。最終的に、新しい機能に対処するために古いシステムの欠点に対処すると、新しいコードが古いコードを完全に置き換えます。

これには、古いアプリの「再起動」よりも高い精度と労力が必要です。しかし、ROIにかかる時間は短くなります。また、プロセスを経て、「新しい」システムを次の「新しい」システムによって簡単に絞めることができるように、フックを配置することができます。

小さな増分を世界にリリースすることは、グリーンフィールドプロジェクトには有効かもしれませんが、それでも少数の機能はあまり有用ではないかもしれません。

スクラムは、各スプリントの後に製品が「潜在的に出荷可能」であると主張しています。出荷する必要はありませんが、出荷可能な製品の品質が必要です。

ユーザーにアプリのインクリメンタルバージョンを提供したい場合は、実際のプロダクションアプリを引き続き使用しながら、アルファ版、ベータ版、候補版のリリースとして分類できます。

ユーザーからのフィードバックを組み込むと、新しい機能が追加され、古い機能が削除される場合があります。

私は、主要な全国ケーブルテレビネットワークの大規模な基幹業務アプリケーションの交換に取り組みました。新しいシステム開発はSCRUMで行われ、ほぼすべての主要なサブシステムを再実装するための18〜24か月の開発プロジェクトでした。10歳に近づいていました。

開発が始まる6か月前などの計画段階がありましたが、SCRUMとしてもアプローチされました。これは、既存のシステム分析と顧客へのインタビューの後に、製品所有者が高レベルのストアと叙事詩を書いた場所です。

既存のシステムは非常に安定しており、重要なメンテナンスモードに移行しました。ストッパーの問題のみが修正され、すべてが履歴目的で記録され、同じ問題が新しいシステムに表示されないことを確認するためにのみ表示されました。

新しいシステムはアジャイルプロセスで説明されているように進化し、ほとんどの部分で非常にスムーズでした。交換システムが機能の一部に達したとき、それは実稼働に入りませんでしたが、並行生産トライアルに入りました。新しいシステムが古いシステムと同様に動作することを検証するために、重要ではないワーカーのサブセットが両方のシステムの使用を開始しました。もちろん、古いバグは修正されています。

新しいシステムがほぼ100％の新機能を完了した時点で、一般的な並行生産の実行に向けて展開され、数か月続きました。

顧客がニーズを満たすと判断した後、古いシステムをバックアップし、電源を切り、座った。カットオーバー後に古いシステムに戻す必要がなかったため、古いシステムハードウェアを再利用したと考えられます。

このシナリオでは、アジャイルが多くの価値をもたらすと今でも考えています。

「現在のシステムを置き換える」という非常に明確な最終目標を持っているだけです。

アジャイルの技術とプロセスは、さらに効果的にあなたをそこに導くことができます。

例えば：

それでも、システム上で反復して小さなスプリントで配信できます。

主要な人々とコミュニケーションをとった後でも、アジャイル技術を使用して作業の優先順位を決めることができます。

アジャイルを使用して、観測された速度に基づいて計画することもできます。

プロジェクトの品質と内部設計を強化するために、知識の拡散、TDD、クリーンコーディングなどのアジャイルテクニックと哲学を引き続き使用できます。

プロジェクトに純粋に「興味がない」人がいて、完全に置き換えられるまでプロジェクトに関与しない場合、ウォーターフォール、アジャイル、または実際に何らかのプロセスを使用しているかどうかに関係なく、より大きな問題が発生します。

同じように機能しますが、このアプローチは既存のユーザーに販売するのが難しくなります。彼らは新しいシステムを望んでいないかもしれませんし、定期的なテストに割り込まれたくないかもしれません。彼らはできるだけ長く待ってから、最後にテストするだけです。ほとんどのユーザーはある程度このように感じますが、それらを教育するのは担当者次第です。彼らの頭の中では、あなたは既存のアプリケーションで作業しているので、何をすべきかを知っておく必要があります。

楽しいと思い、ウォーターフォールプロセスを使用して孤独になるので、このようにしたくないことを彼らに理解させます。長期的にはより良いアプリになります。

主なセールスポイントは、常に望んでいた新しいアプリの構築中にその1つの変更を実装することですが、古いシステムには決して入れることはできませんでした。

古い錆びた車があり、仕事に行くために運転する必要がある場合、ディーラーに行って新しい車を購入します。私が欲しいモデルは在庫がないので、彼らは工場にそれを注文しなければなりません、そして、それが入る前にそれは少しです

ディーラーは誠意を持って、注文した車が入るまで車のエンジンブロックを渡すことにしました。車のエンジンをどうするつもりですか？確かに、いくつかのコンポーネントを接続してテストし、動作させることはできますが、それは本当に古い錆びた車のように明日働かせる助けにはなりません。

確かにそこにある遠くの車を構築し、カスタムソフトウェアを構築する間に異なる泣く、しかしのは、議論のためにそれを無視してみましょう。ストーリーの要点は、クライアントが既に仕事を完了するのに十分なソフトウェアを既に持っている場合に、クライアントが増分変更を使用できないことに困惑しないことです。すでに当面のニーズを満たしています。

アジャイルは、プロジェクトのステータスに関する継続的なフィードバックをクライアントに提供するため、ここでのプロセスの重要な部分ではないということではありません。主要なマイルストーンと成果物の前に確実に進歩を遂げることができます。潜在的な問題や問題を早期に特定してから、修正するのに費用がかかりすぎます。

たぶん、自動車の顧客として、あなたはエンジンを見て評価して、あなたが本当にあなたが期待したものを手に入れようとしていることを確認したいかもしれません。おっと、実際には4気筒エンジンではなく6気筒エンジンが必要でした！もっと早く言ってなかった？問題ありません。変更を工場発注に入れましょう。

新しいソフトウェアリリースをまだ代替品として使用するのではなく、それを評価し、途中の各ステップに満足していることを確認することが彼らの最大の利益であるという考えをクライアントに売ります。