3

「捨てるために作る」というフレーズに慣れているなら、まあ、私たちはそれをやったようです。オンライン アプリのバージョン 1 の制限に達しています。次の方法で物事をクリーンアップする時が来ました。

  • コードと UI の再編成
  • UI プロセスの統一
  • より多くの機能を追加する
  • 未来のための建物
  • 上記のすべてを処理するためにデータベース構造を変更する

この移行を実現する最善の方法は何ですか?

すべてのユーザーを (システムが完成したら) 新しいシステムに引き渡すことは避けたいと考えています。私たちのユーザーは、技術的に熟練した使い慣れたソフトウェア タイプから、HTML が何であるかを知らないタイプまで、あらゆる範囲を実行します。

システムの新しい「インストール」を開始し、この新しい設計がバージョン 1 の問題を十分に解決したことを確認した後、ユーザーを徐々に移行する必要がありますか?

システムの各モジュールを（どういうわけか）段階的に変更し、段階的に変更する必要がありますか？データベースのレイアウトが変更され、「コア コード」といくつかの周囲のモジュールのコードを微調整する必要があるため、これは難しい場合があります。

アプリの最新バージョンを使用する、信頼できる忍耐強い「ベータ テスター」クライアントのセットを持つことは一般的ですか? (ここでの目標は、フィードバックを得て、新しいシステムのバグをテストすることです)

他にアドバイスはありますか？初体験？

4

4 に答える 4

2

残念ながら、答えは場合によるということです。アプリケーションの種類とユーザーの種類によって異なります。システムが何であるか、およびバージョンの変更の範囲を知らなければ、答えを提供することは困難です.

とはいえ、いくつかの経験則があります。

まず、ビッグバンの打ち上げを避ける。システムの起動には問題があります。業界には、バンバン打ち上げは素晴らしいアイデアだと人々が考えたプロジェクトが散らばっていますが、歯が生える問題が立ち上げをひざまずかせただけです。Cuilは、ビッグバン打ち上げの最近の注目を集めた因果関係でした。

歯が生える問題を扱いやすくするには、最初は少数のユーザーで作業し、その後徐々にユーザー数を増やしていく必要があります。

第二に、絶対に積極的にやらなければならないことは、ユーザーを第一に考えることです。ユーザーは、システムの V2 を使用するために最小限の作業を行う必要があります。仕事量ゼロが理想です。

これは、あるシステムから別のシステムにユーザーをゆっくりと移行することを選択した場合、すべてのデータと設定が確実に移行されるようにする責任があることを意味します。たとえば、2008 年 12 月 9 日より前のすべてのレコードには V1 を使用し、それ以降のすべてのレコードには V2 を使用する必要があるとユーザーに伝えるような愚かなことはしないでください。

V2 をリリースするポイントは、ユーザーの生活を楽にすることであって、不必要に難しくすることではありません。

第三に、ベータプログラムを用意してください。これは、イントラネット アプリケーションにも当てはまります。アプリケーションの開発は、多項式の根を見つけるためのニュートン ラフソン法によく似ています。ユーザーが何を望んでいるかを推測し、それをユーザーに提供し、ユーザーがフィードバックを提供し、ゆっくりと、しかし確実に反復を繰り返すことで、問題の解決策に近づけます。

ベータ プログラムを使用すると、変更についてコメントする時間がない状態で新しいバージョンを人々に押し付けるよりもはるかに早くルートを見つけることができます。ベータ版は、ユーザーを早期にオンボードし、プロセスに参加していると感じさせるのに役立ちます。その重要性はいくら強調してもしすぎることはありません。

于 2008-09-12T21:26:24.283 に答える
1

ユーザーに真新しい CRM システムの導入を終えたばかりですが、そのような方法で行うのはひどいアイデアでした。チームと顧客にとって非常に苦痛でした。

たとえそれがより多くの仕事をすることを意味するとしても、段階的なリリースを行うために可能な限りの手段を尽くします。すべてを動かすのに大がかりな努力をする必要がないので、あなたは感謝するでしょうし、あなたの顧客は、少しずつ製品を紹介できることを評価するでしょう.

それが役立つことを願っています!

于 2008-09-12T21:16:20.377 に答える
1

段階的なリリースが最適であるというEstebanの意見に同意します。それは家を改造するようなものです: 最初は良い考えに思えます。しかし、すべてを前もって計画し、たくさんの請負業者を雇い、引っ越さなければならないことを意味します。その後、計画が変更されたり、請負業者が姿を消したりして、節約したいと思っていたすべての時間が失われます。その間、段階的な変化は、誰もがステップの合間に立ち止まって考える機会を与えてくれます。以前の変更が計画よりもうまくいった場合、後の変更を避けることができる場合があります。

私は、スケーリングに大きな問題があるシステムに取り組んでいます。必要だと思われるすべての変更のリストを作成し、影響の可能性が高い順に優先順位を付けました。それから、一度に 1 つの変更を加え始めました。リストの約半分で、スケーリングの問題が解決したことがわかりました。リストはまだありますが、完成させる必要はないかもしれません。自由に機能を追加したり、他の問題を解決したりできます。

もちろん、弾丸をかみ砕いてすべてを壊すのが最善の場合もあります。しかし、それは人々が信じがちなほど一般的ではありません。また、重要な運用システムの場合、「破棄」の決定は致命的となる可能性があります。誰もが現代のコンピューティング時代に持ち込む必要があることに同意しているが、いくつかの重要なサービスが失われるためできないという大規模な政府プロジェクトを見てください。哲学が段階的な変化だったら、おそらくそれらは一度に 1 つずつ近代化されていたでしょう。

于 2008-09-12T21:45:22.973 に答える
0

インクリメンタルな再アーキテクチャーは、アジャイルのバズフレーズとして選ぶべきだと思われます。

私は Web アプリケーションでそれを行ったことはありませんが、段階的に行われたいくつかのかなり根本的なクライアント アプリケーションの変更を経験しました。事前に少し時間を投資して、作業の断片がかなり賢明な方法で順序付けされていることを確認すると、うまく機能する可能性があります。優れたリファクタリング支援ツールをまだ持っていない場合は、それらへの少額の投資が非常に役立ちます。個人的には、.NET を使用している場合はjetBrains Resharperをお勧めします。Java ベースの場合は、IntelliJ IDEA に同様の機能が含まれていると思います。

于 2008-09-12T21:36:09.080 に答える