Implémentation de changements majeurs dans le système [fermé]

Question

Si vous connaissez l'expression « en construire un pour le jeter », eh bien, il semble que nous l'ayons fait ;nous atteignons les limites de la version 1 de notre application en ligne.Il est temps de faire le ménage en :

• Réorganisation du code et de l'interface utilisateur
• Unifier les processus d'interface utilisateur
• Ajout de plus de fonctionnalités
• Construire pour l’avenir
• Modifier la structure de notre base de données pour gérer tout ce qui précède

Quelle est la meilleure façon de réaliser cette transition ?

Nous voulons éviter de renvoyer tous nos utilisateurs vers un nouveau système (une fois qu'il est terminé)...ils paniqueraient et nous ne pourrions pas gérer la charge d'appels.Nos utilisateurs couvrent toute la gamme, depuis les types de logiciels utilisés pour écrire techniquement compétents jusqu'à ceux qui ne savent pas ce qu'est le HTML.

Devrions-nous démarrer une nouvelle « installation » de notre système et y déplacer progressivement les utilisateurs après nous être assurés que cette nouvelle conception résout suffisamment les problèmes de la version 1 ?

Devrions-nous (d’une manière ou d’une autre) modifier chaque module de notre système progressivement et par phases ?Cela peut être difficile car la disposition de la base de données va changer, ce qui nécessitera de modifier le « code principal » et le code de plusieurs modules environnants.

Est-il courant d'avoir un ensemble de clients « bêta-testeurs » fiables, patients et utilisant une version de pointe d'une application ?(Le but ici serait d'obtenir des commentaires et de tester les bugs sur un nouveau système)

Un autre conseil ?Première expérience?

Answer 1

La réponse, j'en ai bien peur, est que cela dépend.Cela dépend du type d'application et du type d'utilisateurs dont vous disposez.Sans savoir ce qu'est le système et l'ampleur des changements de version, il est difficile de proposer une réponse.

Cela dit, il existe quelques règles empiriques.

Tout d’abord, évitez le lancement du big bang.Tout lancement d’un système va rencontrer des problèmes.L'industrie regorge de projets pour lesquels les gens pensaient que le lancement bang-bang était une excellente idée, mais des problèmes initiaux ont mis le lancement à genoux. Cuil était une causalité récente et très médiatisée du lancement du big-bang.

Afin de rendre les problèmes de démarrage gérables, vous devez d’abord travailler avec un petit nombre d’utilisateurs, puis augmenter progressivement le nombre d’utilisateurs.

Deuxièmement, la chose que vous devez absolument faire positivement est donner la priorité à l'utilisateur.L'utilisateur doit avoir à faire le moins de travail possible pour utiliser la V2 du système.La quantité de travail idéale serait nulle.

Cela signifie que si vous choisissez de migrer lentement les utilisateurs d'un système à l'autre, toi sont responsables de s’assurer que toutes leurs données et paramètres sont migrés.Par exemple, ne faites rien de stupide, comme dire à l'utilisateur qu'il doit utiliser la V1 pour tous les enregistrements avant le 09/12/2008 et la V2 pour tous les enregistrements après.

Le but de la sortie de la V2 devrait être de faciliter la vie des utilisateurs, et non de la rendre inutilement plus difficile.

Troisièmement, ayez un programme bêta.Cela s'applique également aux applications intranet.Le développement d'une application ressemble beaucoup à la méthode de Newton-Raphson pour trouver la racine d'un polynôme.Vous devinez ce que veut l'utilisateur, vous le lui fournissez, l'utilisateur fournit des commentaires et, lentement mais sûrement, chaque itération vous rapproche de la solution au problème.

Un programme bêta vous aidera à trouver la racine beaucoup plus rapidement que de simplement imposer de nouvelles versions aux gens sans avoir le temps de commenter les modifications.Les versions bêta aident à intégrer vos utilisateurs plus tôt et à leur donner le sentiment d'être inclus dans le processus ;dont je ne saurais trop insister sur l'importance.

Answer 2

Nous venons de terminer l'installation d'un tout nouveau système CRM sur nos utilisateurs, et laissez-moi vous dire que c'était une TERRIBLE idée de procéder de cette façon :C'était extrêmement pénible pour mon équipe et pour nos clients.

J'utiliserais tous les moyens possibles pour réaliser des versions progressives, même si cela implique de faire plus de travail.Vous serez reconnaissant car vous n'aurez pas à déployer des efforts héroïques pour tout faire bouger, et vos clients apprécieront la possibilité de se familiariser avec le produit un peu à la fois.

J'espère que cela pourra aider!

Answer 3

je suis d'accord avec Estéban que les versions progressives sont les meilleures.C'est comme rénover une maison :en finir avec cela semble être une bonne idée au début.Mais cela signifie que vous devez tout planifier à l’avance, embaucher un groupe d’entrepreneurs et déménager.Puis quelque chose change dans le plan ou un entrepreneur disparaît, et tout le temps que vous espériez économiser disparaît.Pendant ce temps, un changement progressif donne à chacun la possibilité de s’arrêter et de réfléchir entre les étapes.Parfois, vous pouvez éviter des changements ultérieurs lorsque les changements antérieurs fonctionnent mieux que prévu.

Je travaille sur un système qui avait un énorme problème de mise à l'échelle.Nous avons dressé une liste de tous les changements dont nous pensions avoir besoin et les avons classés par ordre d'impact probable.Ensuite, nous avons commencé à apporter un changement à la fois.À peu près à mi-chemin de la liste, nous avons découvert que nous avions résolu le problème de mise à l’échelle.J'ai toujours la liste, mais je n'aurai peut-être jamais besoin de la terminer.Je suis libre d'ajouter des fonctionnalités et de résoudre d'autres problèmes.

Bien sûr, il y a des moments où il est préférable de serrer les dents et de tout démolir.Mais c’est beaucoup moins courant qu’on a tendance à le croire.Et pour les systèmes opérationnels critiques, la décision de « démanteler » peut être fatale.Regardez les grands projets gouvernementaux dont tout le monde s'accorde à dire qu'ils doivent être amenés à l'ère informatique moderne, mais qui ne le peuvent pas car certains services vitaux seront perdus.Si la philosophie avait été un changement progressif, ils auraient peut-être été modernisés pièce par pièce.

Answer 4

Cela ressemble réarchitecture incrémentielle devrait être votre expression à la mode agile de choix.

Je ne l'ai jamais fait sur une application Web, mais j'ai subi des modifications assez radicales de l'application client qui ont été apportées progressivement.Si vous investissez un peu de temps dès le départ pour vous assurer que les tâches sont séquencées de manière assez judicieuse, cela peut bien fonctionner.Un petit investissement dans de bonnes aides à la refactorisation sera très utile si vous ne les disposez pas déjà.Je peux personnellement recommander Reaffûteur jetBrains si vous utilisez .NET et si vous êtes basé sur Java, je pense qu'IntelliJ IDEA inclut des fonctionnalités similaires.