Trop de frais de contrôle de version et de suivi des bogues par modification?

Je travaille dans un endroit qui est dingue de CVS et de Bugzilla-nuts.

1. Il y a tellement de branches de chaque version que l'on ne peut pas les compter. Tout le monde s'auto-fusionne constamment.

2. Il n'y a pas de fluidité à ce travail. Tout se sent proche . Il faut 25 étapes, même pour une chose simple. Ce n'est pas comme être sur une chaîne de production d'usine, c'est comme installer une usine moi-même tous les jours.

Exemple de situation:

Pour corriger un seul bogue, j'obtiens d'abord une nouvelle machine virtuelle. Ensuite, je crée une branche pour ce correctif, basée sur une autre branche décrite dans le rapport Bugzilla. J'installe la branche sur la machine, je la configure. Je corrige le bug. Je l'enregistre, la laissant ainsi que la machine aux autres. Ensuite, je dois aller dans le logiciel de contrôle de bugs, expliquer ce que j'ai fait et écrire un scénario de test, avec toutes les étapes. Finalement, quelqu'un d'autre le fusionne avec un communiqué.

Même si le bug est minuscule, je dois faire toutes ces choses. Parfois, les gens combinent plusieurs bugs, mais comme je l'ai dit, il y a tellement de branches que c'est à peine possible.

À n'importe quel autre travail, j'irais juste et corrigerais le bogue. Je me souviens à peine d’avoir utilisé la gestion de la chaîne d’accès, bien que chaque emploi que j’ai occupé l’ait utilisé: c’est parce qu’à tous les autres emplois, ils l’écartaient d’une manière ou d’une autre .

Y a-t-il un moment où le processus s'interpose et devient une fin en soi? Est-ce même l'ingénierie?

Y a-t-il un moment où le processus s'interpose et devient une fin en soi?

Les processus lourds sont communs, malheureusement. Certaines personnes - en particulier les responsables - imaginent religieusement que des processus produisent des produits. Alors , ils exagèrent les processus et oublient que c'est vraiment une poignée de gens intelligents, qui travaillent dur effectivement créer les produits. Pour les cadres supérieurs, il est effrayant de penser que leurs affaires sont entre les mains de quelques geeks. Ils doivent donc fermer les yeux sur la réalité et penser à leur cher "processus", ce qui leur donne l'illusion d'un contrôle.

C'est pourquoi les startups agiles, composées de quelques bons ingénieurs, peuvent battre les grandes entreprises bien établies, dont les employés consacrent 95% de leur énergie à la production de processus et à la production de rapports. Quelques exemples de petites startups qui ont déjà battu leurs concurrents et / ou créé de tout nouveaux marchés:

• Apple (Apple I a été créé par 1 ingénieur; il y avait 3 hommes dans l'entreprise à l'époque).
• Google (créé à l'origine par 2 programmeurs).
• Facebook ( effort de 1 homme à l'origine).
• Microsoft ( 2 société -man en 1975).

On pourrait facilement dire que ce ne sont que des valeurs aberrantes, des exceptions extrêmes et que, pour faire quelque chose de sérieux, vous feriez bien de devenir une grande société bien établie. Mais la liste est longue. Et sur. C'est embarrassant longtemps. Aujourd'hui, presque toutes les grandes entreprises ont commencé comme un garage, ce qui a eu un effet inhabituel. Quelque chose d'étrange. Ils le faisaient mal. Pensez-vous qu'ils le faisaient conformément au processus?

Les entreprises souffrent généralement de ce que je voudrais appeler le dilemme Contrôle-Flexibilité. Moins il y a de règles, de structures et de frais administratifs bureaucratiques, plus il est facile et rapide d'accomplir des tâches (c'est aussi plus amusant). Cependant, il est tout aussi facile de faire de "mauvaises" choses que de "bonnes" choses. Cela signifie que vous ne pouvez vous en tirer que si vous avez des employés qualifiés qui font peu d'erreurs non critiques.

D'autre part, si vous avez beaucoup d'employés peu ou pas qualifiés et / ou si le coût des erreurs est trop élevé (comme le risque de débris de la navette spatiale sur l'hémisphère nord), les entreprises ont tendance à se soumettre de plus en plus à des "règles". "et" processus "pour essayer de les minimiser.

Le seul problème est que les frais généraux cumulés de ces processus rendent difficile la réalisation de tout ce qui pourrait conduire les employés les plus talentueux à quitter l'entreprise. Il en résulte que les compétences moyennes diminuent encore plus, nécessitant encore plus de processus et de bureaucratie. Ainsi, la spirale de la mort continue jusqu'à ce que quelque chose de radical se produise ou que la société se mette à plomber.

Si vous vous trouvez dans une entreprise qui semble avoir dépassé le point de non-retour dans cet aspect, vous pouvez soit vous résoudre à "ne pas vous soucier" de votre travail (ce que la plupart de ceux qui sont restés ont fait), soit à vous en sortir. de là avec ton âme intacte :)

Si la société n’est pas allée trop loin et si vous avez les moyens, vous pouvez essayer d’inverser la tendance par pure détermination et volonté. Cependant, sachez que cela peut prendre énormément de travail et d’énergie personnelle sans aucune garantie de succès, alors soyez sûr que cela en vaut la peine. Parfois, il est préférable de réduire ses pertes et de se compter comme une expérience plus riche.

Un tel style de développement n’a qu’une raison valable: le logiciel développé est absolument essentiel à la mission et ne doit en aucun cas contenir d’erreur. Pensez au micrologiciel d'injection de carburant des moteurs à réaction dans les avions de passagers, ou au micrologiciel du stimulateur cardiaque ou au système de lancement de missiles nucléaires.

Dans tous les autres cas, les coûts indirects vont tuer l'entreprise. Il est temps de passer à autre chose.

Cette question contient en réalité deux questions, qui doivent être traitées séparément:

Pourquoi certaines équipes ont-elles un processus de développement strict?

La réponse est simple: sinon, des erreurs se produisent. Erreurs coûteuses. Cela est vrai pour le développement, mais également pour le reste du domaine informatique (administrateurs système, administrateurs de base de données, etc.).

Il est très difficile à comprendre pour beaucoup de développeurs et d’informaticiens, car la plupart d’entre nous n’avons jamais travaillé que dans un des «extrêmes»: grandes entreprises du type Fortune avec au moins une douzaine de développeurs et des processus stricts à suivre, ou de petits micro-éditeurs de logiciels ou même des travaux en free-lance où les gens ne se trompent pas ou où le coût d'un tel vol est peu élevé.

Mais si vous avez déjà vu une entreprise entre ces phases - même une entreprise dotée d'un personnel informatique brillant et talentueux - vous comprendrez les dangers de ne pas avoir de processus ou d'avoir un processus à moitié assommé. Vous voyez, la communication entre le personnel souffre d'un problème d' explosion combinatoire ; une fois que vous atteignez le niveau d'environ 6 à 10 développeurs d'une même équipe, la principale cause des défauts majeurs ou critiques n'est pas un manque de talent ou de savoir-faire, mais plutôt un manque de communication.

Alice demande autour de lui lundi matin et décide qu'il est correct de faire une chirurgie reconstructive dans le coffre car personne d'autre ne travaille sur cette partie. Bob arrive une heure plus tard, de retour de ses vacances et plein d'énergie, et décide de mettre en œuvre une nouvelle fonctionnalité majeure dans ce même domaine. Pourquoi s'embêter avec une succursale car personne ne touche à ce code de toute façon? Alors Alice paye cette "dette technique", Bob met en œuvre sa fonctionnalité redoutable qui est restée en suspens pendant 6 mois, et quand ils ont finalement tous les deux consigné leur code (juste avant la fermeture vendredi, bien sûr!), L'intégralité L’équipe doit rester derrière et essayer de surmonter l’enfer cauchemard des conflits qui perdureront sous forme de bugs et de régressions au cours des deux prochaines semaines.

Alice et Bob ont tous les deux fait un excellent travail sur les tâches de codage, mais ils ont tous les deux pris une mauvaise décision ("Quel est le pire qui puisse arriver?"). Le chef d'équipe ou le chef de projet leur fait passer un bilan post mortem et élabore une liste de contrôle pour éviter que cela ne se reproduise:

• Les enregistrements doivent être quotidiens pour minimiser l'impact des conflits;
• Les changements qui prendront beaucoup plus que 1 jour doivent être faits sur les branches;
• Toutes les tâches importantes (y compris les tâches ne faisant pas appel à des fonctionnalités telles que le refactoring) doivent être correctement suivies et affectées dans le suivi des bogues.

Je parie que, pour beaucoup d'entre nous, ce "processus" semble être du bon sens. C'est vieux chapeau. Mais saviez-vous que beaucoup de petites équipes ne le font pas? Une équipe de deux hommes pourrait même ne pas se soucier du contrôle de source. On s'en fout? Honnêtement, ce n'est pas nécessaire. Les problèmes ne commencent à se produire que lorsque l’équipe se développe, mais pas le processus.

Bien entendu, l'optimisation des processus s'apparente à l'optimisation des performances. il suit une courbe exponentielle inverse. La liste de contrôle ci-dessus peut éliminer 80% des défauts, mais après l'avoir mise en œuvre, vous constaterez que quelque chose d'autre représente les 80% restants . Dans notre exemple fictif mais familier, il peut s'agir d'erreurs de construction dues à la présence d'environnements de construction différents, ce qui s'explique par le fait qu'il n'existe pas de matériel standard et que les développeurs utilisent des bibliothèques open source mises à jour toutes les deux semaines.

Vous avez donc trois choix: soit (a) normaliser le matériel et restreindre sévèrement l’utilisation de la bibliothèque tierce, ce qui est coûteux et peut nuire considérablement à la productivité, ou (b) configurer un serveur de compilation, ce qui nécessite la coopération du groupe sysadmin et une développeur à temps plein pour le maintenir, ou (c) laisser les développeurs le faire eux-mêmes en distribuant une machine virtuelle standard et en leur demandant de s’appuyer sur cela. Clairement, (b) est la meilleure solution à long terme, mais (c) présente un meilleur équilibre entre fiabilité et rapidité.

Le cycle continue encore et encore. Chaque "politique" que vous voyez a généralement été mise en place pour résoudre un problème réel. Comme Joel Spolsky l’a écrit en 2000 (sur un sujet tout à fait différent, mais néanmoins pertinent):

Lorsque vous entrez dans un restaurant et que vous voyez un panneau indiquant «Aucun chien autorisé», vous pouvez penser que ce panneau est purement proscriptif: M. Restaurant n'aime pas les chiens, alors quand il a construit le restaurant, il l'affiche.

Si c'était tout ce qui se passait, il y aurait aussi un panneau "Pas de serpents"; Après tout, personne n'aime les serpents. Et un panneau "Pas d'éléphants", parce qu'ils cassent les chaises quand ils s'assoient.

La vraie raison pour laquelle ce panneau est historique est qu’il s’agit d’un repère historique: c’est un repère historique qui indique que les gens essayaient d’amener leurs chiens au restaurant.

C'est la même chose dans la plupart des équipes de logiciels (je ne dirai pas toutes): des règles telles que "Vous devez ajouter un scénario de test pour chaque correction de bogue" indiquent presque invariablement que l'équipe a toujours eu des problèmes de régression. Les régressions sont un autre des problèmes qui sont le plus souvent dus à une défaillance de la communication plutôt qu’à l’incompétence. Tant que vous comprenez la politique, vous pourrez peut-être utiliser des raccourcis légitimes (par exemple, je devais corriger 6 petits bogues mais ils étaient tous dans la même fonctionnalité, donc je ne peux en réalité écrire qu'un seul cas de test pour les 9 d'entre eux).

Cela explique pourquoi les processus sont là, mais ce n'est pas toute l'histoire. L'autre moitié est:

Pourquoi le processus est-il si difficile à suivre?

C’est en fait la question la plus simple à laquelle il faut répondre: c’est parce que l’équipe (ou sa direction) se concentre sur des résultats reproductibles et minimise les défauts (comme ci-dessus) mais n’a pas accordé suffisamment d’attention à l’ optimisation et à l’ automatisation de ce processus.

Par exemple, dans la question initiale, je vois plusieurs problèmes:

• Le système de contrôle de révision (CVS) est hérité des normes actuelles. Pour les nouveaux projets, il a été presque entièrement remplacé par la subversion (SVN), qui elle-même est en train de devenir rapidement éclipsée par les systèmes distribués tels que Mercurial (Hg). Le passage au mercure simplifierait considérablement la création de branches et la fusion , et même dans mon exemple hypothétique ci-dessus, l'exigence de validation quotidienne deviendrait beaucoup moins pénible. Le code n'a même pas besoin d'être compilé, car le référentiel est local; - En fait, les développeurs plus paresseux pourraient même automatiser cette étape s'ils le souhaitaient, en configurant un script de déconnexion pour valider automatiquement les modifications apportées au référentiel local.

• Aucun temps n'a été consacré à l'automatisation du processus de la machine virtuelle. L'ensemble du processus d'obtention, de configuration et de téléchargement des sources / bibliothèques sur une machine virtuelle pourrait être automatisé à 100%. Il peut s'agir d'un processus autonome que vous exécutez sur un serveur central quelque part pendant que vous corrigez un bogue sur votre ordinateur local (et que vous utilisez uniquement la machine virtuelle pour vous assurer d'une construction propre).

• D'autre part, à une certaine échelle, la solution VM par développeur commence à devenir ridicule et vous devriez simplement avoir un serveur d'intégration continue. C’est là que les avantages réels en termes de productivité entrent en jeu, car ils permettent (en grande partie) aux développeurs de ne plus avoir à s’inquiéter des versions. Inutile de vous préoccuper de la configuration de machines virtuelles propres, car le serveur de génération est toujours propre.

• Le libellé de la question ("scénario de test avec toutes les étapes") implique que des tests manuels sont en cours. Cela, encore une fois, peut fonctionner pour de petites équipes avec une charge de travail relativement faible, mais cela n’a aucun sens à plus grande échelle. Les tests de régression peuvent et doivent être automatisés. il n'y a pas d '"étapes", juste une classe ou une méthode ajoutée à la suite de tests unitaires / d'intégration.

• Il va sans dire que passer de Bugzilla à un système de suivi de bogues plus récent (et plus performant) rendrait cette partie de l'expérience beaucoup moins pénible.

Les entreprises ne sont pas nécessairement bon marché ou stupides simplement parce qu'elles n'ont pas résolu ces problèmes. Tout ce qu'ils savent, c'est que le processus actuel fonctionne et que, dans certains cas, ils sont peu enclins à prendre des risques et peu disposés à changer quoi que ce soit. Mais en réalité, ils doivent simplement être convaincus des avantages .

Si les développeurs passent une semaine à surveiller leur temps sur toutes les tâches non codantes, vous pouvez facilement l'additionner, montrer à la direction que (par exemple) un investissement nul en capital de 100 heures-homme dans une mise à niveau vers Mercurial serait éliminer jusqu'à 10 heures-homme par semaine pour résoudre les conflits de fusion, ce sera un gain de 10 semaines et ils seront presque certainement d'accord. Idée identique avec des serveurs de build (CI) ou un meilleur suivi des bogues.

Pour récapituler: les équipes ne l’ont pas encore fait car personne n’a convaincu le management qu’il est assez important de le faire aujourd’hui . Alors, prenez l’initiative et transformez-la en une équation coûts-avantages; Déterminez combien de temps est consacré aux tâches pouvant être simplifiées / automatisées avec un risque minimal et calculez le seuil de rentabilité et le gain éventuel d'un nouvel outil ou d'une nouvelle technique. S'ils n'écoutent toujours pas, vous savez déjà quelles sont les options restantes.

Si les développeurs passent une semaine à suivre leur temps sur toutes les tâches non codantes, vous pouvez facilement l'additionner, montrer la gestion ... et la transformer en une équation coûts-avantages, etc.

La partie ci-dessus semble mériter d'être développée davantage.

Je peux confirmer que cela fonctionne. Les programmeurs l'ont utilisé à quelques reprises dans l'un des projets sur lesquels j'ai travaillé et chaque fois que cela a conduit aux changements souhaités.

Mon impression générale était que, si elle était bien faite, cette astuce pourrait éviter beaucoup d’ignorance et d’inertie de la part de la direction.

Je voudrais cependant noter que la société dans laquelle nous (les développeurs) avons dû recourir à cette approche de type bricolage était très immature du point de vue informatique. Chez des éditeurs de logiciels plus aguerris, j’ai vu des tâches comme celle-ci être confiées principalement aux gestionnaires eux-mêmes. Et en règle générale, ils ont été plus productifs que les programmeurs. Beaucoup plus productif.

Si vous travaillez dans un secteur très réglementé, ce processus fastidieux peut avoir une raison quelconque: un jour, vous pourriez être audité et vous devrez montrer tous vos enregistrements pour expliquer qui a corrigé le bogue, comment, qui l'a examiné, qui l'a testé. ça, etc ...

Donc, cela pourrait être un mal nécessaire.

D'autre part, si rien ne justifie ce processus, mis à part peut-être un manque de confiance de la part de la direction, vous devriez essayer de parler à votre responsable et lui dire comment vous pouvez gagner du temps (et donc de l'argent) pour la société.

Personne dans son bon sens qui refuse un processus plus rapide et meilleur s’il est correctement expliqué.

Mais soyez prêt à défendre votre argument pour justifier le changement.

La moitié du problème est que vous utilisez des outils obsolètes dans un processus, pour lesquels ils n'étaient pas conçus. Ce que vous décrivez est très facile à avoir dans les DVCS modernes, sans tâche fastidieuse de création de branche par bogue.

Un autre problème est que vous n'êtes clairement pas dans la ligne de travail que vous aimez. Vous travaillez dans la maintenance, alors que vous souhaitez du développement. Il n'y a pas grand chose à faire à ce sujet, à part changer de travail.

La discipline du génie logiciel est intrinsèquement «tout au sujet du processus», donc se demander si «il est devenu» ainsi, c'est un peu passer à côté de l'essentiel.

Alors que la plupart des programmeurs préfèrent être gênés par le minimum absolu de processus, dans la mesure où certains préconiseront des méthodologies agiles même s'ils ne résolvent pas les problèmes auxquels leur organisation est confrontée, il est tout à fait possible pour une entreprise de choisir " lourds "processus pour des raisons commerciales saines, telles que" le client l'exige ". Cela est courant si vos clients sont des entreprises du Fortune 500, des universités ou des agences gouvernementales. Les avantages de la vente à ces clients peuvent être suffisamment importants pour justifier l’augmentation des frais généraux liés au processus.

Votre entreprise est un point de données, et il est impossible de généraliser votre expérience en une tendance à l’échelle de l’industrie en faveur de processus plus lourds ou plus éloignés de ceux-ci. La vraie question est de savoir quel équilibre fonctionne le mieux pour votre entreprise, vos produits, vos clients et vous-même, personnellement, en tant que programmeur. Si vous n'aimez pas travailler pour cette entreprise, incitez le changement ou trouvez un autre emploi.

De l’ autre question que j’ai vue de vous aujourd'hui, vous semblez assez mécontent de votre travail. Vous n'êtes pas là depuis longtemps, vous pouvez simplement dire à votre superviseur que vous pensez avoir commis une erreur et qu'il est temps pour vous de vous séparer plus tôt que prévu.

Si vous êtes bon dans votre travail, vous n'aurez vraiment pas beaucoup de mal à en trouver un nouveau, et honnêtement, s'il n'y a pas de bonne raison pour que ce processus existe, je penserais probablement aussi à déménager. Utiliser CVS du tout serait vraiment un avantage décisif pour moi, mais je pose toujours la question du contrôle de source lors de l'entrevue. De toute évidence, je ne peux pas connaître votre situation et il peut être impossible de quitter un emploi si vous avez d'autres obligations.

J'allais dire que le génie logiciel est inondé de très mauvais programmeurs, mais la situation que vous décrivez est terrible.

D'après mon expérience personnelle, une partie de ce "processus" que vous décrivez est accompagnée par le fait que la direction et l'administration du système ignorent complètement l'inefficacité des systèmes qu'ils imposent aux programmeurs. Les exemples incluent la restriction du choix du système d'exploitation, la limitation du logiciel utilisé, l'accès à Internet, les privilèges administratifs du bureau personnel; toutes ces choses sont essentielles au bon développement.

En outre, les exigences de compatibilité entre les "solutions magiques" utilisées par différentes branches d’entreprise. Parmi les exemples, citons les sièges sociaux qui imposent un contrôle de source centralisé, des serveurs Outlook hors site et des consignes de codage ou des langues qui pourraient ne pas convenir à tous les problèmes.

Ce n’est pas très amusant de faire rouler les roues des poids lourds d’entreprise, mais j’ai trouvé que de petites bulles d’innovation, de créativité et de brillance existent dans certaines entreprises.

Vous travaillez probablement dans une entreprise orientée processus . J'essaierais plutôt de trouver une entreprise axée sur les résultats , où il importe de savoir comment vous faites.

Dans mon entreprise, nous avons également un «processus» (mais c'est très simple). Personne ne me dira jamais rien tant que je ne casse rien en prenant des raccourcis parce que j'obtiens des résultats.

Y a-t-il un moment où le processus s'interpose et devient une fin en soi? Est-ce même l'ingénierie?

Littéralement, la plupart des ingénieurs mettent en place des pièces bien établies dans un ordre défini en réponse à un problème particulier. Ceci est particulièrement évident si vous demandez à un ME ce qu’ils font toute la journée. Vous confondez l'ingénierie avec l'architecture ou le développement de produits à un stade précoce (dans n'importe quel domaine). J'ai deux observations à propos de votre question.

1. Vous semblez avoir été affecté à des travaux de réparation de bogues, pas d’architecture ou de conception.
2. Vos collègues semblent avoir mis au point des solutions de contournement limitées (combinaison de machines virtuelles correctrices de bogues) pour les rendre plus efficaces. Vous ne semblez pas suivre leur exemple judicieux.

Il est tout simplement vrai que dans toute entreprise constructive impliquant un grand nombre de personnes, certaines personnes doivent effectuer la conception et un groupe plus large «se charger» de la mise en œuvre. Désolé, mais vous êtes dans ce deuxième groupe.

Comme d'autres commentateurs l'ont noté, CVS n'est pas le meilleur outil pour un modèle de développement très ramifié, mais je remarque également que vous n'êtes pas responsable de la fusion ... ne vous inquiétez donc pas.

La plupart de vos plaintes semblent essentiellement être "Je ne veux pas tester, avant, pendant ou après le développement!" Décomposons vos pas, point par point.

• Pour corriger un seul bogue, j'obtiens d'abord une nouvelle machine virtuelle propre. Un environnement de test
• Ensuite, je crée une branche pour ce correctif, basée sur une autre branche décrite dans le rapport Bugzilla. - Vous dupliquez l'environnement dans lequel le bogue a été trouvé ... comment est-ce déraisonnable?
• J'installe la branche sur la machine, je la configure. Je corrige le bug. Je l'enregistre - Le processus de développement de base
• ... Laissant cela et la machine pour que d'autres testent avec. - Votre équipe de fusion souhaite probablement que cela soit en mesure de vérifier le correctif si la fusion se fait au sud.
• Ensuite, je dois entrer dans le logiciel de contrôle des bogues et expliquer ce que j'ai fait - Si vous êtes dans un magasin qui ne le fait pas ... pourquoi suivez-vous les bogues du tout?
• et écrivez un cas de test avec toutes les étapes. - Je peux me tromper, mais cela semble être la direction que tous les 'enfants cool' vont quand même
• Finalement, quelqu'un d'autre le fusionne avec un communiqué. - Et plusieurs des étapes ci-dessus visent à faciliter leur travail

Quelqu'un d'autre devant vous fait évidemment le tri des bogues pour s'assurer qu'un bogue trouvé n'est pas corrigé dans une autre version ou cassé dans une version ultérieure (c'est le cas des tests-cas).

La seule chose, même de loin inhabituelle ou trop zélée, à propos de ce processus est le problème de la VM. Il y a de bonnes chances que cela soit considéré comme raisonnable si nous savions dans quel domaine vous travailliez.

Intéressant. Avez-vous des testeurs? Ils devraient faire une partie de cela. Je suis un et, là où je travaille, nous avons une solution décente.

Pour un défaut fonctionnel, comme vous l'expliquez, notre processus est le suivant:

1. Je teste le défaut d'une machine virtuelle (soit signalé par un client, soit lors de mes tests exploratoires, soit w / e)
2. Un bug est trouvé / reproduit.
3. Je crée le bug. Les bugs incluent:
   • Repro complète, du point d'installation au point de voir le bogue.
   • Un lien vers un instantané de la machine virtuelle (si je pense que le développeur en aura besoin ... je le fais quand même, juste au cas où ils le demanderaient).
   • Informations système, tous les paramètres spéciaux que je devais effectuer.
4. Ce bogue est assigné au dev. Pendant qu'ils travaillent sur un correctif, je:
   • Créer un cas de test
   • Écrivez (ou convertissez) le test manuel en un test automatisé

Ensuite, j'attends une résolution et aide le développeur de la manière dont il le souhaite. Quand il revient comme résolu, je:

1. Exécutez le scénario de test automatisé et une version manuelle (parfois) pour confirmer le correctif.
2. Fermez le bug.

TL; DR: Si vous n'avez pas de testeurs, vous en avez besoin. Si vous en avez, ils ne font pas leur part.

Tom DeMarco:

... Mon premier livre de mesures ... la ligne la plus citée est sa première phrase: "Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer." Cette ligne contient une vérité, mais je suis de plus en plus mal à l'aise avec mon utilisation. La citation (et même le titre du livre) sous-entend que le contrôle est un aspect important, peut-être le plus important, de tout projet logiciel. Mais ça ne l'est pas.

... plus vous vous concentrez sur le contrôle, plus vous travaillez sur un projet qui s'efforce de fournir quelque chose d'une valeur relativement mineure.

À mon avis, la question qui importe beaucoup plus que de savoir comment contrôler un projet de logiciel est de savoir pourquoi nous faisons tant de projets qui offrent une valeur aussi marginale? ...

Génie logiciel: une idée à qui le temps est venu?

"Ensuite, je crée une branche pour cette correction de bogue,"

Il n'est pas nécessaire de créer une branche pour le correctif unique. Commencez par créer le bogue dans Bugzilla. Découvrez la branche de publication. Faites le correctif. Effectuez la validation avec le message de validation contenant le numéro de bogue, qui met à jour le bogue et le marque "réparé, a besoin d'un test" ou "corrigé, testé, doit être fusionné" de manière appropriée, en fonction des mots-clés de texte écrits dans le message de validation. La base de données de bogues est le mécanisme de suivi idéal pour toutes les modifications apportées et la raison pour laquelle elles ont été apportées. les rapports peuvent être exécutés à partir de la base de données de bogues pour extraire ces informations.

Je pense que la plupart des processus pourraient être automatisés , de sorte que la création de la machine virtuelle et des branches (y compris la compilation du code, la configuration des débogueurs, etc.) ait été effectuée avant que vous ne commenciez à travailler sur le bogue.

Décrire ce que vous avez fait et comment cela devrait être testé en vaut la peine pour toutes les corrections de bugs. J'ai trouvé que le simple fait d'écrire un texte peut résoudre des problèmes , car cela me fait penser au risque, etc.

Je pense donc que le processus est peut-être un peu «exagéré», mais que le véritable problème est l’absence d’outils automatisés personnalisés permettant de prendre en charge le processus.

Yo mec, votre façon de penser est la bonne en ce que ce que vous avez décrit est complètement nul et montre à quel point les choses peuvent être fausses dans un logiciel. Cependant, voici la bonne nouvelle: il y a tellement d'entreprises qui pratiquent l'Agile avec un véritable esprit. La société pour laquelle je travaille en est un. Il y a beaucoup de ces jours-ci et c'est une très bonne nouvelle.

Lorsque vous sentez que quelque chose ne va pas vraiment sur votre lieu de travail, vous pouvez faire deux choses: vous pouvez soit influencer un changement positif, soit quitter cet endroit et en rejoindre un meilleur.

CVS ou tout système de gestion de configuration n'est pas mauvais. Malheureusement, la façon dont il est utilisé, sans vraiment en connaître le but, cause un peu cette douleur dans le! @ # $ Pour l’ensemble de l’organisation.

Pour comprendre rapidement ce qu'est vraiment l'agile, parcourez le livre "Pratiques d'un développeur agile" de Venkata Subramaniam. Son bien écrit dans un langage facilement compréhensible.

Je vous souhaite bonne chance!