開発チームに新しいバージョンのミドルウェアに移行するようにどのように説得しますか？
私は（サポート対象外の）ミドルウェアスタックを安定しているがサポートされているバージョンに更新するプロジェクトに取り組んでいます。現在本番環境にあるバージョンでアプリケーションを実行しているチームがいくつかありますが、当然のことながら、新しいバージョンで最初に実行されるリスクを負うことは誰も望んでいません。
過去にこのような新しいリリースに移行するために使用した、または最も説得力のある戦略は何ですか？
新しいバージョンによって提供されるパフォーマンスと機能上の利点はいくつかありますが、チームが移動するための主要な技術的インセンティブは実際にはありません。これは今のところ必須です。これは主に、古いバージョンの拡張サポートのコストと、新しいバージョンによって提供される改善された管理を備えたサポートされたバージョンで実行したいというインフラストラクチャチームの要望によって推進されています。
テクノロジーの質問というよりは、人の質問です。
非推奨または廃止された製品またはフレームワークは、通常、 技術的負債 として最もよく分類（および「販売」）されます。
新しいバージョンが素晴らしい改善または利点を提供する場合、あなたの仕事はより簡単です。ただし、そうでない場合でも、古いバージョンを使用し続けると、いくつかのリスクが発生します。
- 開発者サポートの欠如。それが問題になるまで、これは決して問題ではありません-それを取得しますか？
- コミュニティサポートの欠如。時間が経つにつれて、あなたが頼るようになったフォーラム、Q＆Aサイト、メーリングリストなどは、誰もあなたのバージョンを使用しなくなったため、あなたの質問を無視し始めます。
- 回転ロック。アップグレードは、遅れているバージョンが増えるほど、次第に苦痛になります。 1.0から1.1または1.9から2.0へのアップグレードは通常大したことではありませんが、1.0から2.0へのアップグレードは、すべての問題を解決するのに数週間または数か月かかる場合があります。逆説的に、マネージャーにとっては、より頻繁にアップグレードすると、全体の時間が短くなります変更の範囲はそれぞれに小さく、問題は簡単に修正できるため、アップグレードに費用がかかります。
- 生産性の損失（別名機会費用）。 「一部の」パフォーマンスと機能上の利点はあまり面白くないように思われるかもしれませんが、その10％のブーストは、すべての機能/スプリント/リリースで複合され、数週間または数か月の期間にわたって償却されます。アップグレードに1週間を費やして、10か月で推定12か月のプロジェクトを完了することができれば、それは賢明な投資ではないでしょうか。
- レガシーコードの問題。新しいバージョンがかなり広く配布されると、開発者は通常、古いバージョンのバグ、セキュリティの脆弱性、およびその他の深刻な問題の修正を停止します。これにより、重大な障害やシステムの侵害、またはデータの盗難に遭遇する可能性が大幅に高まります。ゼロデイ脆弱性は存在しますが、それらの悪用は、パッチが適用されていない古いシステムの脆弱性ほど一般的ではありません。
これは、everythingの最新かつ最高のバージョンを常に使用している必要があるという意味ではありません。これにも、関連する問題があるためです。しかし、私のチームでは、すべてのスプリントの開始時に、少なくとも1つのフレームワークを最新バージョンにアップグレードすることに重点を置いています。問題が発生した場合は、修正するか、ロールバックします。維持するのは難しいペースではありません。つまり、通常単一の製品またはフレームワークで1〜2か月遅れていることを意味します。 ITまたは企業が関与する必要がある場合。
要するに：ソフトウェア開発者やプロジェクトマネージャーに何か新しいものを導入したり、アプリケーションをアップグレードしたりするよう説得する方法には、まったく異なるアプローチがあります。
したがって、ソフトウェア開発者は時間の節約と、さまざまなフレーバーで一般的でやりがいのあるタスクを実行する際の便利な機能に関心があり、PMは提案された新規/アップグレードの実装による進行中の運用のコストの節約。
現在のアプリケーションテストがスクリプトによって自動化されていない場合、QAチームメンバーからは主な重要な欠点のみがもたらされます。 QAチームは当然この変更に反対するかもしれません。
How to convinceには、引数を使用して変更を加えるための関連するSEの質問があります。