J'ai été impliqué dans plusieurs projets qui impliquent essentiellement de remplacer un "ancien" système avec un "nouveau" système. Invariablement, le motif a été que pratiquement personne sur l'équipe qui construit le "nouveau" système a une connaissance réelle du "ancien" système. Chaque fois que j'ai interrogé cela, on m'a dit que ceci est utile ... en ne connaissant pas le "ancien" système, l'équipe est capable de penser différemment et de ne pas être limitée par la façon dont les choses ont été faites là-bas. Donc, ce qui se passe est qu'il n'ya généralement que 1 ou 2 personnes sur l'équipe qui connaisse quoi que ce soit sur le "ancien" système et qu'elles sont consultées chaque fois qu'une question se présente sur la manière dont le "ancien" système a fait quelque chose.
Mais ce qui semble toujours se produire est qu'après que le système "nouveau" est livré, il y a toujours des questions de l'utilisateur du formulaire "Comment faire X (qui était facile dans l'ancien système) dans le nouveau système? " Pour les développeurs, cela est souvent la première fois qu'ils ont entendu parler de X. Ils doivent donc aller chercher ce que X est et souvent la réponse qu'ils redonne aux utilisateurs est "Vous ne pouvez pas" ou "vous pouvez, mais c'est vraiment maladroit ".
Cela ne semble pas vrai pour moi ... Il me semble que beaucoup seraient acquis en ayant tous les développeurs du "nouveau" système connaître vraiment le "vieux" système, et cela ne tuerait pas nécessairement leur créativité, s'ils ont des compétences décentes de conception et de développement.
Toute réflexion sur laquelle une approche est la meilleure?
3 Réponses :
Remplacement d'un ancien système avec un nouveau, implique généralement une fonctionnalité iso-fonctionnalité (c'est-à-dire que la capacité de faire au moins ce que l'ancien système a pu faire)
Donc, tandis qu'une connaissance approfondie de l'ancien système n'est pas obligatoire, connaître les interfaces et construire un ensemble de suites de tests fonctionnels est utile pour développer efficacement le nouveau système.
Cette suite servira à valider les résultats du nouveau développement, en gardant à l'esprit que le résultat ne doit jamais être 100% (sinon, vous auriez reproduit avec succès les bugs du premier système!)
plus, pour un système vraiment volumineux, vous avez besoin d'au moins trois implémentations pour votre nouveau programme:
Si nous parlons d'une grande période de temps, cela implique également un architecte capable de gérer l'évolution de l'ancien système (qui ne peut pas rester immobile, attendre plusieurs mois ou années avant que le nouveau ne le remplace), en gardant ces évolutions dans la même direction que votre nouvelle implémentation.
Vous avez besoin de meilleurs analystes d'affaires. Ce sont ceux qui sont censés examiner l'ancien système et définir exactement (et complètement) ce que le nouveau système doit faire. Ils devraient fournir une liste complète des exigences pour vous afin que tout ce qui doit se produire a été considéré.
Celui qui écrit les exigences doit être plus complet. Si ce n'est pas possible, vous devrez peut-être vous impliquer et apprendre le «ancien système».
Cependant, il y aura toujours des choses manquées - c'est juste la nature humaine. Vous devriez évidemment essayer de rendre le «nouveau système» aussi flexible que possible, afin de pouvoir ajouter des fonctionnalités lorsque les utilisateurs se rendent oubliés.
Je comprends votre douleur.
Été là sans un ba et ça fait mal. Essayant de parler aux utilisateurs des "nouvelles" exigences est parfois difficile aussi difficile car a) ils ne veulent pas toujours d'un nouveau système & B) qu'ils veulent juste qu'il fasse ce que l'ancien a fait
Oh oui. L'exigence de numéro 1 est toujours «identique à celle de l'ancien système». "Vous devez rendre la police Times New Roman, c'est comme ça que l'ancien système était".
Cela ressemble à la spécification du nouveau système était incomplet car une personne (le gestionnaire de projet, l'initiateur de projet) ne garantit pas que la fonctionnalité de l'ancien système a été documentée et vérifiée pour voir ce que le client a réellement utilisé.
Si cela est fait, il ne devrait pas d'importance que personne ne connaisse l'ancien système car la spécification est la chose que vous développez contre.
Si vous n'avez pas de spécification, à part tous les autres problèmes que vous aurez, tout le monde devrait connaître l'ancien système pour éviter ce problème même.
+1 'Si vous n'avez pas de spécification ... Tout le monde devrait connaître l'ancien système' - trop vrai dans trop de cas.