Pourquoi séparer les travaux de maintenance des travaux de développement?

Question

Je travaille dans une entreprise où la maintenance est effectuée par la même équipe qui donne vie à un logiciel.

Très souvent, j'entends parler d'organisations qui disposent d'une équipe de maintenance distincte ou d'un programmeur de maintenance. Ce sur quoi je me demande, c’est «quel est le raisonnement derrière tout ça?

Mis à part abandonner l'ancien code pour les mortels, y en a-t-il?

Les leçons tirées de la gestion de votre " indésirable " sont de valeur beaucoup plus élevée? Réparer les défauts n’est-il pas bien plus efficace que ceux qui les ont provoqués?

Me manque-t-il de véritables raisons pour lesquelles il pourrait être avantageux de disposer d'une équipe de maintenance distincte?

Answer 1

Le concept qui nous vient à l’esprit pour décrire au mieux cette notion est le suivant: " rossé ". Il s’agit essentiellement des coûts de commutation que vous avez associés aux travaux de maintenance et de développement. C'est probablement la raison principale pour séparer les responsabilités. D’autres permettent également aux programmeurs débutants ou débutants de se familiariser avec la vie, et de laisser vos développeurs plus expérimentés produire des éléments de plus grande valeur.

Maintenant, dans le même temps, je pense qu’un développeur qui a écrit une application doit la supporter. Premièrement, ils trouveront très rapidement dans leur code des problèmes dont ils pourront tirer des leçons. Deuxièmement, ils penseront à la maintenabilité et à la qualité du code, car ils doivent le prendre en charge.

Exemple de contestation dans la vie réelle:

Un projet de développement de 1 500 heures vous a été attribué. Vous êtes également responsable de la maintenance des systèmes et du support de vos 3 dernières applications. Au cours de ce nouveau projet, vous êtes interrompu 7 fois par semaine en moyenne pour prendre en charge ces 3 applications. Chaque fois que vous commencez à travailler sur les 3 autres applications, vous passez 20 minutes à vous concentrer sur le problème. Une fois le problème résolu, vous passerez 20 minutes à vous remémorer le code que vous avez utilisé pour la dernière fois dans votre nouvelle application. Cela représente un coût total de 40 minutes par interruption ou 280 minutes par semaine. Cela signifie que vous avez perdu 2,67 heures de productivité au cours de la semaine au moment de basculer pour prendre en charge ces applications.

Answer 2

Je travaille sur une équipe agile depuis plus d'un an. Je pense que cela n'a pas vraiment d'importance dans le cas d'un produit en direct (par cela, je veux dire les clients utilisant les dernières versions uniquement). Mais disons que vous avez plusieurs versions de votre produit sur le marché et que vous devez supporter chacune d’elles.

Prenons l'exemple de Bentley's Microstation. C’est une application de conception pour la 3D (architecture, conception d’installations, ponts routiers, etc.). Maintenant, disons que nous avons v8, v9, v10 sur le marché. Ils ont des fonctionnalités différentes et le format de fichier a considérablement changé au fil des versions. Mais les projets sont si énormes (ou les clients sont si importants) que vous devez prendre en charge les clients v8 et v9 tout en développant des outils v10. Il est donc nécessaire que l'entreprise dispose d'une équipe de maintenance (ou de temps) allouée aux versions précédentes. En outre, ces équipes sont généralement appelées équipes de personnalisation si votre produit prend en charge la personnalisation et le scénario mentionné ci-dessus.

Answer 3

Le problème est plus pratique, je suppose:

• les anciens codes ont été écrits par des personnes qui ne font plus partie de l'entreprise ou de l'équipe;
• l'ancien code a été écrit par des développeurs externes;

Il est très courant dans de nombreuses entreprises d’avoir une base de codes qui ne soit plus gérée par les codeurs d’origine, car elles ne sont plus là. Si la base de code est suffisamment grande, quelqu'un doit le tenir à jour pour s'appeler les responsables.

Si vous pouvez éviter ce cas, tant mieux, mais assurez-vous qu'il soit toujours temporaire.

Answer 4

Je ne dirai pas que je suis d’accord avec la pratique, mais dans de nombreuses organisations, des consultants sont invités à écrire des logiciels. Bref, des efforts précipités sont ensuite passés à des programmeurs internes pour les "entretenir". La raison en est que vous pouvez faire appel à une personne plus qualifiée sans formation et que vous lui faites ensuite inclure "transfert de connaissances". aux personnes qui travailleront à garder un logiciel intact.

En bref, la plupart du temps, cela est fait pour des raisons politiques / peu pratiques.

Answer 5

Je pense que la scission des équipes de maintenance et de développement de fonctionnalités a pour motivation de faire en sorte que les choses se déroulent sans heurts: si l'équipe de développement de fonctionnalités continue de devoir arrêter ce qu'elle est en train de faire pour gérer un correctif, le projet va stagner. Avoir une équipe de maintenance séparée libérerait le reste des développeurs pour faire avancer le projet / produit en question.

Answer 6

Mon premier travail consistait à maintenir certains modules logiciels, dont les développeurs originaux étaient passés à un nouveau projet.

Je devine:

• Rend le nouveau développement plus prévisible et plus facile à planifier: les développeurs ne sont pas appelés à le résoudre pour résoudre un nombre inconnu de problèmes de maintenance

• Possibilité de former de nouveaux développeurs (par exemple, moi)

De plus, le code que je maintenais n'était pas "indésirable". - c’était un logiciel telco, un ancien réseau à commutation de paquets, qui avait été déployé chez des clients tels que Bell, etc. Il était bien conçu, bien écrit, testable (suites de scénarios de test automatisés), maintenable, de nombreux fichiers journaux, un peu de conception documentation ...

... le sous-titre de votre OP semble être, "Man, ce code pue! J'aimerais pouvoir obtenir le développeur d'origine et lui tacher son nez: pour que l'apprenne! "

Donc, quand le code est déjà bien écrit, cet argument (qui apprend aux développeurs originaux) n'est pas applicable.

Quand je dis que je faisais la "maintenance" Cela ressemblait un peu au développement de nouvelles fonctionnalités, mais à des fonctionnalités très mineures ... par exemple, une interopérabilité avec de nouveaux périphériques clients qui interprétait les spécifications de protocole de manière légèrement inhabituelle.

[J'analyserais et diagnostiquerais le problème et coderais un correctif; et une personne d’AQ ajouterait un nouveau cas de test correspondant à la suite de tests automatisés.]

Answer 7

Un avantage que je peux constater est qu’il ya au moins une autre personne de l’organisation responsable de la compréhension du code suffisamment bien pour le réparer. De plus, cette personne aura un ordre du jour différent et pourra réviser le code du point de vue de la maintenance si elle fait l’objet d’une revue de conception / développement (comme il devrait l’être).

En outre, "maintenance". peut faire référence à une foule d’activités telles que le déploiement, la configuration, la sauvegarde, etc., qui devraient assurément être gérées par une équipe différente.