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.