Faire face à un projet sans fin fixe

Nous avons un grand site Web (1200+ heures) qui a beaucoup de dettes techniques. Cela est principalement dû aux raisons (habituelles) suivantes.

1. Plusieurs programmeurs qui vont et viennent pendant le développement.
2. Modification des spécifications en cours de développement.
3. De nombreuses fonctionnalités supplémentaires ajoutées (en peu de temps).

Le client veut beaucoup de nouvelles fonctionnalités, et cela revient essentiellement à travailler sur ce projet chaque semaine pendant plus de 10 heures.

En raison de la dette technique, nous passons BEAUCOUP d'heures à résoudre ou à enquêter sur des problèmes, qui trouvent généralement leur origine dans l'un des éléments suivants:

1. Un insecte stupide et sans vergogne qui fait pleurer les gens.
2. Une nouvelle fonctionnalité résulte de ce qui précède car nous n'avions pas prévu tous les endroits où la nouvelle fonctionnalité aurait une influence.
3. Quelques autres problèmes que nous avons rencontrés (migration du serveur, mises à niveau)

Nous avons des problèmes quotidiennement et nous avons essayé de suivre les choses pour mettre un terme à cela:

1. Création d'une documentation technique concernant l'importation, le paiement et le fonctionnement général du site Web.
2. Organisez une réunion au début de la semaine pour discuter des problèmes ou des améliorations actuels et de la manière de les résoudre.
3. Ayez un plan de test. Programmeur A test B, B tests C et C tests A. Ensuite, notre chef de projet lancera quelques tests. Concernant l'impact de la fonctionnalité, nous la jetons sur un environnement de mise en scène et laissons le client vérifier par lui-même.

Le problème est que les problèmes continuent de se produire ... et d'une manière ou d'une autre, nous ne pouvons pas le maîtriser. Les nouvelles fonctionnalités causent toujours des bugs, et les anciens bugs continuent de dire bonjour. D'une manière ou d'une autre - peut-être en raison de la taille du projet - nous ne pouvons pas sembler avoir une emprise sur ce projet.

Je suppose qu'il y a beaucoup de programmeurs qui travaillent sur de plus gros projets. C'est pourquoi j'en viens à ma question:

Que pouvons-nous faire ou que faites- vous pour éviter ces problèmes sur les grands projets?

Modification mineure, informations supplémentaires:

1. Nous utilisons le contrôle de version (SVN).
2. Nous avons un processus de développement DTAP.

Je jouerai l'avocat du diable, ayant vu trop souvent comment cela se produit: vous ne pouvez pas y faire face. Je vous garantis que vous êtes le seul qui voit réellement un vrai problème avec le système tel qu'il est, sinon vous n'auriez pas à vous demander comment y faire face car la culture de l'entreprise serait celle d'éliminer les bogues et de corriger le code dans la mesure du possible, c'est-à-dire comment fonctionnent de vrais professionnels

Je parie qu'il est trop volumineux pour commencer à écrire des tests unitaires, car il n'y a eu personne qui sait tester les tests unitaires avant vous (et avec de la chance d'autres personnes de votre équipe) et il est impossible de savoir par où commencer, et peut-être même impossible de test car il repose sur des implémentations exactes et des données concrètes, il faudrait donc beaucoup trop de temps pour supprimer tout cela aux interfaces, aux maquettes, aux stubs et autres pour pouvoir le tester en premier lieu. Je parie également que vous ne pouvez pas simplement refactoriser ce qui doit être refactorisé car il est trop étroitement couplé et, puisqu'il n'y a pas de tests, qui sait ce qui sera cassé en corrigeant un mauvais code. En bref, il est probablement devenu trop cancéreux pour être sérieusement réparé, mais bien sûr, il ne peut pas simplement être coupé et recommencer à zéro.

Vous livrez une bataille perdue, mon ami. Soit vous vous épuiserez de frustration et finirez par arrêter ou devenir fou, ou si vous vous plaignez suffisamment longtemps pour essayer de faire comprendre les problèmes aux autres, ils penseront que le seul problème est vous et on vous montrera la porte.

Les tests unitaires sont un bon point de départ si vous n'en faites pas. À tout le moins, ils vous protégeront de l'ajout de nouveaux bogues lors de la correction d'anciens bogues.

Le contrôle des sources est également utile, sauf si vous ne l'utilisez pas. Les fonctionnalités de blâme et de journalisation, en particulier, sont merveilleuses pour comprendre comment / pourquoi un morceau de code buggé a été commis.

Du côté du client, j'ai constaté que discuter du prix et des (longs) retards dès que des modifications / fonctionnalités supplémentaires sont demandées fonctionne assez bien, tout comme le fait de facturer le temps que vous passez à en discuter / à les concevoir. Souvent, les clients décideront à la réflexion qu'ils peuvent attendre.

(En revanche, si vous explorez immédiatement les spécifications et les idées d'implémentation avec lui, ils vous mettront généralement en place pour un "oh, je pensais que nous avions convenu que vous le feriez de toute façon" ou (pire, après plusieurs jours de retour et sur les détails) "mais regardez, il est déjà conçu et nous ce que nous avons discuté ne semble pas si difficile!".)

Enfin, j'ai constaté que le fait de ne pas lire les courriels une fois par jour (à mon arrivée au travail) et d'avoir un téléphone pour quelque chose de plus urgent entraîne une énorme augmentation de la productivité.

Je vous suggère d'ajouter des tests basés sur CI, principalement sur les zones les plus fréquentes. Cela vous aidera à améliorer la qualité au fur et à mesure que le projet est en cours.

Il est également plus évident de savoir quelles zones / fonctionnalités se cassent le plus souvent et il est donc plus facile de décider quelles pièces doivent être refactorisées, ou du moins des tests accrus.

Ajouter plus de tests manuels risque de faire mal tourner le projet en termes de $$$ et de temps requis par fonctionnalité ajoutée.

Une révision de code est bonne, mais peut-être que cela fait partie du schéma de test A-> B-> C-> A. (Peut-être la révision du code dans l'autre sens?)

Permettez-moi de vous lancer une fable. Vous vous promeniez avec une personne plus tôt dans la journée dans la rue et vous atteignez votre destination. La personne avec laquelle vous marchez découvre rapidement qu'il a perdu sa bague quelque part en cours de route, alors vous décidez tous les deux de faire marche arrière et de la chercher. La personne avec laquelle vous marchez s'arrête rapidement à un lampadaire et commence à regarder frénétiquement. Vous dites: "Pourquoi regardez-vous le lampadaire alors que je pense que vous l'avez peut-être perdu lorsque nous avons traversé l'allée?". Il répond: "Je sais mais la lumière est meilleure ici."

J'ai été dans cette situation plusieurs fois et j'ai remarqué quelques points communs. Ces types de projets de cauchemar de maintenance sont généralement exécutés dans un environnement lourd de processus avec une lourde surveillance et des améliorations de processus imposées par la direction. Je ne dis pas que les améliorations de processus sont une mauvaise chose, mais le plus souvent, les types d'améliorations de processus que la direction voudra généralement adopter ont deux points clés.

1) Ils ne perturbent généralement pas la politique du bureau et l'équilibre des pouvoirs. 2) Ils réussissent à créer l'illusion d'un contrôle par la direction plutôt que de frapper au cœur du problème.

La direction "la lumière est meilleure ici" pense généralement en disant: "Chaque nouvelle fonctionnalité doit avoir une spécification technique détaillée", ou "Permet d'avoir une réunion horaire tous les jours pour discuter des problèmes et comment les surmonter."

Aucune de ces choses ne frappe vraiment au cœur des problèmes et elles pourraient simplement diminuer la productivité, mais elles valident certainement l'illusion du contrôle par la direction.

Les seuls vrais changements que vous pouvez aider à promouvoir sont ceux qui font bouger les choses. Je soupçonne cependant que votre monstruosité d'un site Web est probablement irréparable à ce stade et vous seriez plus en avance pour ré-architecturer et réécrire. Pour l'avenir, cependant, vous pouvez garder à l'esprit l'importance de la méthodologie Agile, de l'intégration continue, du développement piloté par les tests, des revues de code et des spécifications des exigences commerciales qui sont réglementées par des procédures strictes de contrôle des changements pour aider à minimiser le fluage de la portée sans ajustements de calendrier.

Ces types de changements nécessitent vraiment un changement dans la façon de penser au niveau de la gestion et dans toute mon expérience professionnelle, je n'ai jamais rencontré cela sans une sorte de remaniement au niveau de la gestion intermédiaire. J'espère que ce n'est pas trop décourageant car vous devriez essayer de trouver ce qui est juste, que vous meniez une bataille difficile, car vous rencontrerez probablement une résistance farouche de la part de personnes qui aiment le statu quo.

J'ai été au même endroit il y a quelque temps. Je ne le suis plus grâce à deux règles simples:

• Chaque semaine, un ou deux jours sont consacrés à réparer / réécrire la plupart des parties velues de l'application. Pas de recherche de bogues, pas de développement de nouvelles fonctionnalités.
• Lors de la mise en œuvre de nouvelles fonctionnalités, nous nous efforçons de bien faire les choses même lorsque nous avons passé plus de temps que ce que le client attend.

Le seul problème est d'amener les autres à les respecter. La partie facile était étonnamment le client. Je ne peux pas vraiment expliquer pourquoi, mais nous l'avons en quelque sorte convaincu que lorsque nous travaillons sur une fonctionnalité un peu plus longtemps, c'est mieux pour tout le monde. Le respect de la première règle s'avère plus problématique, mais nous pensons également que cela nous aide beaucoup. Il garantit une progression régulière à mesure que les différentes parties de l'application s'améliorent.

Revues de code. Tests unitaires. Test de QA réel. Processus de collecte de spécifications et développement incrémentiel - ce sont des choses qui devraient résoudre la plupart de vos problèmes.

Ne laissez pas non plus les clients cingler directement vos développeurs - c'est généralement le moyen le plus improductif de résoudre les problèmes. Embaucher un bon gestionnaire de programme qui formera l'interface entre vos clients et développeurs. Son travail serait de connaître le produit de bout en bout, l'état actuel, les orientations futures, etc. Chaque fois que le client souhaite une autre nouvelle fonctionnalité, il devrait être en mesure de donner la liste actuelle des articles et de montrer aux clients ce qui sera annulé si cette nouvelle demande doit être prise.

Le processus est mauvais lorsqu'il est utilisé trop peu ou trop. Je pense que vous êtes dans l'ancien état.

Comme le mentionne Deni, si vous pouvez ajouter des tests unitaires au projet, cela vous aiderait. Ayez un test qui couvre une partie du système que vous êtes sur le point de modifier / corriger, et donc lorsque votre code de refactoring, utilisez ce test comme guide pour vous assurer que vous ne cassez rien.

Triez également les parties les plus cassées du code. Essayez de mettre les plus touchés dans une liste de risques et de gérer ces risques de manière indépendante. Essayez d'avoir une idée de la quantité de code cassé dans la base de code en demandant où les bugs se produisent le plus. Vous pouvez ensuite répertorier la zone affectée par le nombre de bogues (ou les problèmes signalés, selon ce qui vous convient.).

Corriger et nettoyer le code prendra du temps, mais si chaque développeur de l'équipe peut laisser le code un peu plus propre, il l'était avant de le modifier, puis avec le temps, la base de code s'améliorera. Si vous cherchez une solution rapide et militaire, faites-la trier maintenant, je doute qu'il existe quelque chose de pratique (ou recommandé) qui pourrait aider.

À votre santé. Jas.

Rédiger des spécifications fonctionnelles claires; pédantiquement donc si vous pouvez le supporter et revoir régulièrement les fonctionnalités par rapport à ces spécifications. Moins un développeur a d'idée sur ce qu'il est censé développer, moins il y a de chance que ce soit la façon dont il est censé se développer.

Avant de commencer à écrire du code, effectuez un travail de conception initial; cela n'a pas besoin d'être parfait, ou énorme, ou de contenir UML, mais cela devrait décrire une solution assez solide au problème qui doit être résolu. Pour autant que je sache, moins de logiciels sont prévus, pire c'est. Discutez de la conception avant de commencer à travailler dessus.

Lorsque vous commencez à travailler sur une zone du code qui est clairement mauvaise et entrave vraiment votre progression; arrêtez d'y ajouter, prenez du recul par rapport au problème, déterminez comment vous pourriez repenser l'architecture afin que les obstacles ne soient pas là et qu'elle soit plus adaptable à l'avenir. Plus vous la laissez longtemps avant de régler une dette technique, plus il sera difficile de la régler sans une réécriture complète. Je dirais que c'est une chose exponentielle.

Concevez des tests qui testent le comportement et ne se couplent pas étroitement à votre architecture. Ce n'est pas très à la mode, mais je dirais que ne commencez pas les tests avant que le véritable objectif de votre code ne soit clair. Plus précisément, ne commencez pas les tests avant de savoir ce que vous voulez vraiment tester; IMO un test mal pensé est pire que pas de test. Et plus vous avez de tests, plus il est difficile de changer votre code en interne. Traitez votre code de test comme vous le feriez avec du code de production; il doit être planifié et bien écrit.

Faites des révisions de code régulières / quotidiennes: il s'agit davantage de vérification de la santé mentale pour vous assurer que le développeur n'est pas allé trop loin. Utilisez ces sessions pour planifier le travail des prochains jours. Il peut y avoir des jours où cela prend 5 minutes ou 1 heure; il s'agit de maintenir un dialogue ouvert et de donner aux développeurs la possibilité de discuter de leur travail avec d'autres développeurs et de demander conseil. Faites des sessions de jumelage sur des parties difficiles du code ou pour prototyper des idées, mais laissez les gens avoir leur propre temps pour travailler.

Facilitez la création et le déploiement de votre code. Essayez de raccourcir les temps de construction. Plus il est facile de construire, plus il sera construit, plus il sera rapide, plus il sera construit.

Adoptez des normes de codage et appliquez-les de manière rigide. Cela devrait couvrir tout, de l'endroit où un projet doit vivre dans le système de fichiers à la casse d'un const privé. Cela peut sembler inutile et ennuyeux, mais les bonnes habitudes sont la pierre angulaire d'un processus de développement.

Fondamentalement, je ne pense pas que le processus que vous utilisez soit si important, les modes vont et viennent. Ce qui importe vraiment, c'est que vous soyez professionnel dans la façon dont vous développez des logiciels et que vous soyez discipliné dans votre pratique.

Je commencerais par concevoir et automatiser les tests de fumée et les lancer dans l'environnement CI. Ceux-ci devraient être fonctionnels. Lorsque le client vous dit que quelque chose devrait fonctionner tel ou tel, demandez-le par écrit, afin que vous puissiez vous y référer plus tard. Lorsque vous voyez une certaine solution dans le logiciel, posez des questions et dès que vous recevez des réponses, incorporez-les dans la base de connaissances et rendez-les traçables.

Assurez-vous que la fonctionnalité de base pour les cas positifs fonctionne. Ensuite, commencez à créer des tests incrémentiels pour une gestion incorrecte des données, en plaçant les défauts si nécessaire. Ayez une discussion longue et approfondie sur les priorités et informez-en le responsable des tests afin qu'il puisse attribuer le temps de test en conséquence. N'essayez pas de tout automatiser, mais dès que certains tests ont du sens pour être automatisés, n'hésitez pas.

En général, utilisez les tests pour augmenter la confiance dans le produit, et non pas comme l'outil qui augmentera instantanément la qualité. Soyez calme, mais sûr de vous :). Essayez peut-être de devenir agile, mais seulement si vous pouvez engager positivement et positivement un PM certifié. Introduire Agile par une personne qui ne connaît pas Agile, tuera très probablement le projet.