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 des organisations qui ont une équipe de maintenance distincte ou un programmeur de maintenance. Ce que je m'interroge sur c'est - ce que ... Le raisonnement derrière ceci est?
En dehors de la fossé "vieux code" à des mortels moins élevés, existe-t-il?
Les leçons tirées du maintien de votre propre "déchets" sont beaucoup plus élevées? Ne répartissant pas les défauts beaucoup plus efficaces lorsque ceux qui leur ont fait commencer?
Je manque de vraies raisons pour lesquelles il pourrait être bénéfique d'avoir une équipe de maintenance distincte?
7 Réponses :
Le concept qui me vient à l'esprit pour décrire le mieux c'est " Maintenant, en même temps, je pense qu'il y a une certaine valeur dans un développeur qui a écrit une application qui doit le soutenir. Premièrement, ils trouveront très rapidement des problèmes dans leur code qu'ils peuvent apprendre. Deuxièmement, ils penseront à EXEMPLE DE TROISSION DE VIE REAL:
Vous avez été attribué à un projet de développement de 1500 heures et vous êtes également responsable de la maintenance des systèmes et de la prise en charge 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 faire oublier votre esprit. Après avoir corrigé le problème, vous passez ensuite 20 minutes à remédier à votre esprit autour du code que vous avez touché dans votre nouvelle application. Ceci est 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é dans la semaine juste sur la passer pour soutenir ces applications.
Point solide, difficile à concourir. On pourrait affirmer que les défauts antérieurs sont autorisés à faire mal à vos progrès actuels afin que vous apprendrez d'eux. "Si vous auriez fait correctement votre projet précédent, vous seriez plus de succès sur celui-ci." La tâche de commutation - un cauchemar .. est-ce trop de cauchemar, réfléchissant :-)
Le temps perdu est mauvais, mais les défauts que vous créez à la suite d'une commutation de contexte imparfaite ont un impact bien pire.
Choisir celui-ci comme ma réponse parce que c'est l'argument le plus fort contestant ma position actuelle. Mon lieu de travail a des mesures en place pour essayer de supprimer une partie de la commutation de contexte, je les considère comme inefficace du point de vue de la maintenance. Recherchez cela plus loin, merci :-) Nice Terme "Trashing" :-)
Je pense que la motivation de la motivation de la création des équipes de maintenance et de développement est de garder les choses à courir sans heurts: si l'équipe de développement de l'entité continue de devoir arrêter ce qu'ils font pour gérer une solution de bogue, le projet va étaller. Avoir une équipe de maintenance distincte libérerait le reste des développeurs pour conserver le projet / produit en question d'avancer.
J'ai peur que ce soit une ligne de pensée commune. Problème que j'ai avec cela, c'est le développement sprint avec un seau d'eau, perdant la moitié de celle-ci en cours de route. L'eau renversée étant balayée par des ingénieurs de maintenance, pour lesquels le client est obligé de payer -agagne-.
Je peux totalement comprendre cela - je ne dis pas que je m'abonne à cette ligne de pensée, essayant simplement de fournir une raison possible.
Je demandais un raisonnement, pas ce que vous pensez est le meilleur. Merci pour votre réponse :-)
Un avantage que je peux voir, c'est que, puis il y a au moins une autre personne de l'organisation qui est responsable de la compréhension du code assez bien pour le réparer. En outre, cette personne aura à l'esprit un ordre du jour différent et peut examiner le code du point de vue de la maintenance, s'il est introduit sur des critiques de conception / développement (qu'il / elle devrait ê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 devrait certainement être traitée par une autre équipe.
Bon point. Je pense que le personnel de soutien est tout autant qu'un «utilisateur» du système est évident. Peut-être devrait-être être un rôle dans l'équipe, la personne en mappant des trous fonctionnels et des défauts dans le système, de déterminer des défauts de conception et de tels.
Je ne dirai pas que je suis d'accord avec la pratique mais dans de nombreux organismes consultants sont mis à bord pour écrire des logiciels en bref, les efforts pressés se précipitaient après quoi les projets sont remis à des programmeurs internes pour "maintenir". La justification est que vous pouvez apporter quelqu'un qui est plus qualifié sans formation et que vous les avez ensuite incluant «transfert de connaissances» aux personnes qui travailleront à maintenir un logiciel intact.
En bref, une grande partie du temps qu'il est fait pour des raisons politiques / peu pratiques.
Alors, la seule équipe que vous avez en interne est une équipe de maintenance, une perspective intéressante.
Je pense que cela arrive probablement beaucoup dans beaucoup de magasins. Mais ce que les gens ne parlent pas, c'est à quel point le logiciel fourni par le consultant est et l'ironie supplémentaire que le consultant a été rendue mieux que les personnes qui finissent par la correction de l'application.
Vous êtes sur quelque chose que M. Dy mais pour être aussi optimiste quant aux consultants que possible: leurs objectifs sont très court terme (entrez-vous, Bills fixes # heures, sortez) et d'arriver à «faire» pourraient avoir des intérêts opposés aux personnes qui ont voir quelque chose de travail à long terme dans des conditions variables. Avoir été consultant moi-même, je peux voir comment il y a de la pression pour couper les coins pour être «fait» dans les plus brefs délais.
Le problème est plus pratique, je suppose:
Il est vraiment courant dans beaucoup d'entreprise d'avoir une base de code qui ne sont plus maintenues par les codeurs d'origine, car ils n'y sont plus là. Si la base de code est assez grande, une personne doit le garder à jour afin qu'ils soient appelés mainteneurs.
Si vous pouvez éviter ce cas, bon pour vous, mais assurez-vous qu'il est toujours temporaire.
Je reconnais cette situation oui. Ce que vous décrivez, c'est plus une spécialisation ... Manipulation des basses basses qui sont nulsées de connaissances antérieures. On pourrait soutenir que l'équipe originale devrait pouvoir continuer leur héritage, même lorsque les gens partent ...
Je travaille sur une équipe agile depuis plus d'un an. Je pense que cela n'a pas vraiment d'importance en cas de produit en direct (par là, je veux dire client à l'aide des dernières versions uniquement). Mais dites que vous avez plusieurs versions de votre produit sur le marché et vous devez soutenir chacun d'entre eux.
Prenez par exemple la microstation de Bentley. C'est une application de conception pour 3D (architecture, conception de plantes, ponts routes de rails, etc.). Disons maintenant que nous avons V8, V9, V10 sur le marché. Ils ont différentes fonctionnalités et le format de fichier a changé de manière significative sur les versions. Mais les projets sont si énormes (ou les clients sont si importants) que vous devez prendre en charge les clients V8 et les clients V9 tout en développant V10. Il est donc nécessaire que la société ait une équipe de maintenance (ou une heure) attribué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.
Mon premier emploi contenait des modules logiciels, dont les développeurs originaux avaient passé un nouveau projet.
Je devine:
rend le nouveau développement plus prévisible, plus facile à planifier: parce que les développeurs ne sont pas appelés à résoudre un nombre inconnu de problèmes de maintenance à l'avance
possibilité de former de nouveaux développeurs (par exemple moi)
En outre, le code que j'étais maintenu n'était pas "Junk" - c'était le logiciel Telco, un réseau anticipé à commutation de paquets, qui avait été déployé sur des clients comme Bell, etc. Il était bien conçu, bien écrit, testable ( Suites des cas de test automatisés), maintenable, de nombreux fichiers journaux, une documentation de conception ...
... Le sous-titre à votre op semble être "," Homme, ce code pue! J'aimerais pouvoir obtenir le développeur original et frotter son nez-le: que l'apprendrait! "
Ainsi, lorsque le code est déjà écrit, cet argument (enseignant les développeurs d'origine) n'est pas applicable.
Quand je disais que je faisais "maintenance", il s'agissait d'une sorte de nouveau développement de fonctionnalités, mais de caractéristiques très mineures ... Par exemple, Interop avec de nouveaux dispositifs clients qui ont interprété la spécification du protocole de manière légèrement inhabituelle.
[J'annageais et diagnostiquez le problème et codez un correctif; et une personne QA ajouterait un nouveau test de test correspondant à la suite de tests automatisés.]
Le code n'est pas bien écrit s'il a des défauts. Mon seul "sous-titre" était qu'un défaut détient une valeur pour une seule personne, la personne la créant. Des leçons tirées de l'échec? Si une maintenance la corrige, le problème peut être parti pour l'utilisateur / le client, mais la personne d'où elle provient le répétera?
L'une des raisons de «maintenance» pourrait être nouvelles exigences , que le code soit bien écrit.
Désolé, mon point de vue sur la maintenance était un peu ciblé sur les défauts. J'avais supposé que de nouvelles exigences soient quelque chose que l'équipe «développement» prend en charge. Bien sûr, la maintenance doit également traiter des déficiences fonctionnelles (supprimer les PEEP des listes de messagerie en vrac car votre client ne connaît pas SQL), pas toujours la faute des programmeurs.
Dans mon scénario, le "logiciel Development ingénieurs" était désactivé nouveaux produits - tandis que comme un "logiciel" nouvellement embauché " Maintenance ingénieur" J'étais Mise en œuvre de nouvelles choses réellement mineures dans un produit existant (probablement dans le cadre d'un contrat de support client). Nous (les deux ensembles de développeurs) travaillaient maintenant sur différents produits (pour différents gestionnaires de produits). J'étais maintenu des logiciels qui avaient déjà été libérés, avaient passé les tests d'acceptation du client et était dans le domaine utilisé sur le réseau en direct.