Agile - Qu'est-ce que nous faisons de mal?
Je suis développeur dans une équipe agile et nous essayons d'utiliser Scrum.
Je vais donc mettre ici un problème hypothétique pour illustrer la situation.
Nous avons une très ancienne application, utilisant du code JQuery de maintenabilité désordonné et mauvais. Nous avons également des parties de l'application utilisant React, et ces parties sont beaucoup plus faciles à mettre à jour/à maintenir. En plus de cela, l'objectif de l'entreprise est de créer une application cliente d'une seule page, sur React, donc l'utilisation de JQuery vous éloigne davantage de cela.
Lorsque nous faisons la planification, nous optons toujours pour la solution facile en termes de temps de développement, donc par exemple si nous créons une nouvelle boîte de dialogue ou quelque chose, nous utilisons l'ancien JQuery parce que c'est plus rapide, et nous disons que nous revenons plus tard pour ranger et transformer en React, mais cela arrive rarement.
Nous obtenons les exigences de ce que nous devons faire à partir des histoires d'utilisateurs (qui sont bien faites IMO, elles sont minces mais elles expliquent ce que nous faisons et pourquoi nous le faisons).
Parfois, les exigences des nouvelles fonctionnalités sont très minces, donc pour un exemple si une exigence dit "créer une boîte de dialogue qui charge des tonnes de contenu" mais ne dit pas d'implémenter une fonctionnalité de chargement, nous, dans la plupart des cas, ne l'implémenterons pas , même si nous savons tous que ce serait mieux pour les clients, car cela pourrait compromettre notre objectif de sprint (même si je pense personnellement que ce ne serait pas le cas).
Le résultat est que notre base de code est un gros gâchis avec une très mauvaise maintenabilité, et les nouvelles fonctionnalités parfois, sont très petites et prennent un sprint complet à faire (quelque chose qui pourrait être réalisé en une seule journée dans une bonne base de code) principalement à cause de ce développement stratégie, allez vite, faites le minimum.
Dans ce cas, que faisons-nous de mal? Devrions-nous aborder les solutions de manière plus complète afin de ne pas toujours écrire de mauvais code et réécrire du code que nous venons d'écrire la semaine dernière? Ou devrions-nous continuer à le faire en nous assurant simplement que tout ce code est en cours de réécriture? Quelle serait une bonne approche agile de ce problème?
Cela n'a rien à voir avec Agile ou Scrum.
Le problème avec "du ruban adhésif maintenant et nous le réparerons plus tard" est que plus tard ne vient jamais et en attendant vous accumulez beaucoup de dette technique .
La première étape de la récupération consiste à reconnaître le problème et à cesser de l'aggraver.
Pour chaque nouvelle user story, l'équipe doit considérer "quelle est la bonne façon de coder cela?", Et non "quelle est la manière la plus rapide de pirater cela?" et planifier les sprints en conséquence.
Pour nettoyer le problème existant, voir les excellentes réponses à J'ai hérité de 200K lignes de code spaghetti - et maintenant?
Ce que vous avez là, c'est ce que Martin Fowler appelle "la mêlée flacide".
Si vous avez bien lu tous 12 principes derrière le Manifeste Agile , vous découvrirez que vous échouez à la plupart d'entre eux.
Fournissez fréquemment des logiciels fonctionnels, de quelques semaines à quelques mois, en privilégiant les délais plus courts.
Pouvez-vous dire que vous livrez un logiciel vraiment fonctionnel? Ou tout simplement un logiciel qui fonctionne à peine?
Les processus agiles favorisent le développement durable. Les sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment.
Pouvez-vous dire que votre processus est durable? Prenez-vous des décisions en tenant compte de la durabilité? Ou choisissez-vous des solutions qui résolvent le problème actuel sans tenir compte des effets à long terme?
Une attention continue à l'excellence technique et à une bonne conception améliore l'agilité.
Le principe vraiment majeur. Je crois que cela devrait être mis dans les ÉNORMES LETTRES ROUGES sur la page. C'est là que vous échouez le plus.
À intervalles réguliers, l'équipe réfléchit à la façon de devenir plus efficace, puis ajuste et ajuste son comportement en conséquence.
Et bien évidemment. Si vous découvrez que votre comportement ne mène pas aux résultats souhaités, vous devez le changer. Si votre équipe ne voit pas qu'elle a des problèmes, elle ne peut pas commencer à les résoudre.
D'après votre commentaire
Comment prévoir cela en agile?
Tout d'abord, en apprenant ce qu'est réellement l'agilité. Scrum n'est pas agile. Certains diront que Scrum est le pire des cadres agiles, car il est trop facile d'atteindre votre situation exacte. Vous devez en savoir plus sur les autres cadres agiles. Celui que je recommanderais est Extreme Programming. Ce qui résout clairement vos problèmes. Les solutions ne sont pas simples (se concentrer sur l'excellence technique grâce à des tests automatisés robustes, la programmation de paires et la livraison continue), mais très efficaces. Comme indiqué dans rapport sur l'état des DevOps .
Ce que vous décrivez est - au moins d'après mon expérience - un assez modèle émergent commun d'équipes essayant de "être Agiles". Il est possible de débattre si cela fait réellement partie de l'Agile lui-même ou si une mauvaise mise en œuvre courante de celui-ci, est contraire au manifeste/aux principes agiles ou à une conséquence inhérente de celui-ci, etc. D'un point de vue empirique et sur la base de mon propre petit échantillon d'expérience (et des personnes à qui je parle), si une équipe est agile, elle semble avoir une chance supérieure à la moyenne de tomber sur ce modèle. Restons-en là et concentrons-nous sur votre exemple concret.
Il y a deux aspects distincts à ce que vous décrivez:
- Manque de compréhension/vision commune et donc pas efficace
- Comment mesurer le succès/progrès et le coût total
Prendre le mauvais chemin ou tourner en rond
D'après mon expérience, la principale raison pour laquelle cela se produit est que pour tenter de produire du code rapidement, les équipes écartent activement les cas d'utilisation ou les exigences qu'elles connaissent déjà ou pourraient facilement en savoir plus. Pensez-y de cette façon: il y a 10-20 ans, les gens essayaient d'écrire des spécifications géantes et pensaient à tout à l'avance et échouaient souvent. Ils ont pris trop de temps ou ont oublié quelque chose. L'un des enseignements du passé est que dans le développement de logiciels, il y a des choses que vous ne pouvez pas savoir et les choses changent beaucoup, d'où l'idée d'itérer rapidement et de produire rapidement une sortie sensible. C'est un très bon principe. Mais aujourd'hui, nous sommes à l'autre extrême: "Je m'en fiche parce que ça fait partie du prochain sprint" ou "Je ne dépose pas ce bug, je m'en occupe quand il revient". Mon conseil serait:
- Rassemblez tous les cas d'utilisation de haut nivea, exigences, dépendances et restrictions que vous pouvez trouver. Mettez-le dans un wiki pour que toutes les parties prenantes et les développeurs puissent les voir. Ajoutez-y quand quelque chose de nouveau arrive. Parlez à vos actionnaires et utilisateurs. Utilisez-le comme liste de contrôle lors du développement pour éviter d'implémenter des choses qui ne contribuent pas au produit final ou sont des solutions de contournement/hacks qui résolvent un problème mais en provoquent trois nouveaux.
- Formuler un concept de haut nivea. Je ne parle pas de concevoir des interfaces ou des classes, mais plutôt d'esquisser grossièrement le domaine problématique. Quels sont les principaux éléments, mécanismes et interactions de la solution finale? Dans votre cas, cela devrait être évident lorsque vous utilisez l'aide jquery-workaround comme une étape intermédiaire et quand cela ne provoque qu'un travail supplémentaire.
- Validez votre concept en utilisant la liste que vous avez réunie. Y a-t-il des problèmes évidents? Est-ce que ça fait du sens? Existe-t-il des moyens plus efficaces d'atteindre la même valeur utilisateur sans engendrer de dette technologique à long terme?
N'en faites pas trop. Vous avez juste besoin de quelque chose pour que tout le monde dans l'équipe (y compris les non-développeurs) ait une compréhension commune du meilleur chemin vers votre MVP. Tout le monde devrait convenir qu'il n'y a pas d'oubli évident et que cela pourrait réellement fonctionner. En général, cela permet d'éviter de tomber dans des impasses ou d'avoir à refaire la même chose plusieurs fois. Agile peut vous aider à mieux faire face à l'inattendu, ce n'est pas un argument pour ignorer ce qui est connu.
Soyez conscient du sunk-cost-fallacy: si vous commencez avec une architecture ou un type de base de données, la plupart des gens hésitent à le changer en cours de projet. C'est donc une bonne idée d'investir un peu de temps pour avoir une "meilleure supposition éclairée" avant de commencer à mettre en œuvre des choses. Les développeurs ont tendance à vouloir écrire du code rapidement. Mais souvent, avoir quelques simulations, des prototypes en direct, des captures d'écran, des images filaires, etc. permet une itération encore plus rapide que l'écriture de code. Sachez simplement que chaque ligne de code écrite ou même les tests unitaires rendent plus difficile de modifier à nouveau votre concept global.
Mesurer le succès
Un aspect complètement différent est la façon dont vous mesurez les progrès. Disons que l'objectif de votre projet est de construire une tour de 1m de haut en utilisant des objets qui traînent. Construire un château de cartes peut être une solution totalement valable si, par exemple, le temps de mise sur le marché est plus important que la stabilité. Si votre objectif est de construire quelque chose qui dure, utiliser Lego aurait été mieux. Le point est: ce qui est considéré comme un hack et quelle solution élégante dépend entièrement de la façon dont le succès du projet est mesuré.
Votre exemple de "chargement" est assez bon. J'ai eu des choses comme ça dans le passé où tout le monde (y compris les ventes, les bons de commande, les utilisateurs) a convenu que c'était ennuyeux. Mais cela n'a eu aucun impact sur le succès du produit et n'a provoqué aucune dette à long terme. Nous l'avons donc abandonné car il y avait des choses plus précieuses à faire avec les ressources de développement.
Mon conseil ici est:
- Gardez tout, même les petits bugs, comme tickets dans votre système de ticket. Prenez une décision active ce qui est dans la portée du projet et ce qui ne l'est pas. Créez des jalons ou filtrez autrement votre backlog afin d'avoir toujours une liste "complète" de tout ce qui reste à faire.
- Avoir un ordre d'importance strict et un point de coupure clair où le projet pourrait être considéré comme un succès. De quel niveau de stabilité/qualité de code/documentation le produit final a-t-il réellement besoin? Essayez de passer chaque jour de travail le mieux possible en choisissant par le haut. Lorsque vous travaillez sur un ticket, essayez de le résoudre complètement sans introduire de nouveaux tickets (à moins qu'il ne soit logique de reporter les choses en raison d'une priorité inférieure). Chaque engagement devrait vous faire avancer vers votre objectif final, pas latéralement ou en arrière. Mais pour le souligner à nouveau: parfois un hack qui produit du travail supplémentaire plus tard peut toujours être un net positif pour le projet!
- Utilisez votre PO/utilisateurs pour déterminer la valeur utilisateur mais demandez également à vos développeurs de calculer le coût de la technologie. Les non-développeurs ne peuvent généralement pas juger du véritable coût à long terme (pas seulement du coût de mise en œuvre!), Alors aidez-les. Soyez conscient du problème de la grenouille bouillante: beaucoup de petits problèmes non pertinents peuvent au fil du temps mettre une équipe en attente. Essayez de quantifier l'efficacité de votre équipe.
- Gardez un œil sur l'objectif/les coûts globaux. Au lieu de penser de sprint en sprint, plutôt gardez un état d'esprit de "pouvons-nous en tant qu'équipe faire tout ce qui est nécessaire jusqu'à la fin du projet". Les sprints ne sont qu'un moyen de décomposer les choses et d'avoir des points de contrôle.
- Au lieu de vouloir montrer quelque chose tôt, tracez votre cours sur le chemin le plus rapide vers un produit viable minimum qui peut être donné à l'utilisateur. Pourtant, votre stratégie globale devrait permettre des résultats vérifiables entre les deux.
Donc, lorsque quelqu'un fait quelque chose qui ne correspond pas à votre objectif de mise en œuvre final, idéalement, ne considérez pas l'histoire comme terminée. S'il est avantageux de fermer l'histoire (par exemple pour obtenir des commentaires des clients), ouvrez immédiatement une nouvelle histoire/bogue pour remédier aux brèves lacunes. Faites en sorte que la prise de raccourcis ne réduise pas les coûts, elle les masque ou les retarde!
L'astuce ici est d'argumenter avec le coût total du projet: si par exemple un bon de commande pousse à prendre des raccourcis pour faire un délai, quantifier la quantité de travail qui doit être fait par la suite pour considérer le projet fait!
Méfiez-vous également de optimisation basée sur des critères: si votre équipe est mesurée par le nombre d'histoires qu'ils peuvent montrer lors d'une revue de sprint, la meilleure façon d'obtenir un bon "score" est de couper chaque histoire en dix minuscules. S'il est mesuré par le nombre de tests unitaires écrits, il aura tendance à écrire beaucoup de tests inutiles. Ne comptez pas les histoires, mesurez plutôt combien de fonctionnalités utilisateur nécessaires fonctionnent, quel est le coût de la dette technologique à résoudre dans le cadre du projet, etc.
Sommaire
Pour résumer: aller vite et minimal est une bonne approche. T le problème est d'interpréter "rapide" et "minimal". Il faut toujours considérer le coût à long terme (sauf si vous avez un projet où cela n'est pas pertinent). L'utilisation d'un raccourci qui ne prend qu'un jour mais génère une dette technique d'un mois après la date d'expédition coûte plus cher à votre entreprise qu'une solution qui a pris une semaine. Commencer immédiatement à écrire des tests semble rapide, mais pas si votre concept est défectueux et qu'il cimente une mauvaise approche.
Et gardez à l'esprit ce que signifie "à long terme" dans votre cas: je connais plus d'une entreprise qui a fait faillite en essayant d'écrire du code génial et donc expédiée trop tard. ne bonne architecture ou un code propre - du point de vue de l'entreprise - n'a de valeur que si le coût pour y parvenir est inférieur au coût de ne pas l'avoir.
J'espère que cela pourra aider!
Du point de vue de la mêlée, il semble que ce que vous faites mal, c'est que vous ne travaillez pas avec le client. Vous devez travailler avec le client pour comprendre ce qu'ils ont besoin et pas seulement ce qu'ils veulent. Ont-ils besoin d'une série de solutions rapides ou ont-ils besoin d'un système stable et maintenable qui les servira à long terme? Cela peut être difficile à déterminer, mais la qualité est autant une exigence qu'une couleur d'arrière-plan ou une référence de performance. Le client doit être conscient que la stabilité et la maintenabilité ne sont pas gratuites et doivent être intégrées au produit.
S'ils disent que c'est le premier, vous ne faites rien de mal - en supposant que vous leur expliquez dans les revues de sprint que vous coupez les angles de l'ingénierie pour atteindre leurs objectifs.
S'ils disent que c'est le dernier, alors ce que vous faites mal, c'est que vous ne leur donnez pas ce qu'ils veulent.
L'une des pierres angulaires de Scrum est la transparence. Si vous faites de la mêlée, vous devriez faire des revues de sprint avec le client. Dans ces avis, dites-vous au client que vous prenez des mesures afin de fournir des logiciels plus rapidement? Sinon, vous devriez l'être. Vous devez être à 100% clair avec votre client sur les ramifications de vos choix de conception, pour lui donner une chance de prendre une décision éclairée quant à savoir si vous livrez votre logiciel avec un niveau de qualité approprié.
Ewan a raison. La raison pour laquelle la direction aime Scrum, c'est parce qu'elle obtient des fonctionnalités dans un style staccato et obtient rapidement des résultats. Jusqu'à ce que le désordre qui en résulte soit le problème de quelqu'un d'autre.
Maintenant que j'ai votre attention, laissez-moi vous expliquer. Ce n'est pas Scrum en tant que tel. C'est le cadre typique d'un chef de produit solide et d'une équipe de développement faible qui n'est pas en mesure de faire des estimations raisonnables et réalistes car ils ressentent la pression. Ils parviennent donc à des estimations très optimistes et se retrouvent plus profondément dans les ennuis, coupant les coins afin de livrer à temps.
Dans Scrum, vous (en tant que développeur) pouvez faire votre propre planification. Personne ne vous dit de livrer une fonctionnalité en x jours. Si quelqu'un vous dit de livrer dans x jours, vous ne faites pas Scrum.
Quel que soit le problème à résoudre, réclamez votre temps. Pensez-vous que vous avez besoin de temps pour retravailler quelque chose en premier? Incorporez-le à votre estimation. Pouvez-vous vous le permettre?
Examinons ce que vous faites, en laissant de côté Agile pendant un moment.
Lorsque nous faisons la planification, nous optons toujours pour la solution facile en termes de temps de développement, donc par exemple si nous créons un nouveau dialogue ou quelque chose, nous utilisons l'ancien jquery parce que c'est plus rapide, et nous disons que nous allons revenir plus tard pour ranger et transformer en réagir, mais cela arrive rarement.
C'est ce qu'on appelle "Prendre la dette technique". Martin Fowler a décrit le "Quadrant de la dette technique" dans un blog de son le long des deux axes: "Reckless vs Prudent" et "Deliberate vs. Inadvertent".
Vous décidez explicitement d'utiliser l'ancienne technologie jquery connue qui vous éloigne de l'un de vos objectifs express (à savoir une application d'une seule page). Vous faites cela pour livrer "rapidement". C'est délibéré.
Ce que ce calcul de "rapidement" n'inclut pas, c'est le temps dont vous avez besoin pour implémenter la fonctionnalité pour réagir ensuite. Vous choisissez une alternative qui n'a que des inconvénients par rapport à l'alternative que vous - savoir pour être la bonne (à savoir prendre le temps de mettre en œuvre la fonctionnalité en réaction) sur la base d'une évaluation que la vitesse est essentielle. C'est téméraire.
Martin Fowler résume ce type de dette sous "Nous n'avons pas le temps de concevoir". C'est un choix approprié dans un environnement où vous ne vous attendez pas à maintenir le code ou même à coder pendant plus de quelques jours. Mais votre projet est un projet de longue durée qui implique explicitement une maintenance pour vos clients
Ce que vous faites est faux au niveau très basique. C'est une mauvaise ingénierie !
Vous avez contracté une dette technique, ignorant que cette dette doit être remboursée et des intérêts. Et vous avez continué à le faire jusqu'à ce que le taux d'intérêt sur votre dette commence à se rapprocher de votre travail disponible pendant votre sprint.
Ce que vous devriez faire, c'est réduire le niveau d'endettement . Parlez à votre patron, parlez à votre client. Vous devez travailler sur la maintenabilité hier.
Arrêtez d'utiliser Agile ...
Ou plutôt, arrêtez d'essayer de faire quelque chose d'une certaine manière uniquement parce que c'est ce que (votre compréhension de) agile (ou scrum etc ...) dicte. Essayer d'appliquer une (mauvaise) interprétation de l'un de ces termes à un projet au mauvais stade peut rapidement devenir la pire solution. Utilisez plutôt votre raison.
La raison pour laquelle votre projet, et presque tous les autres projets dans le monde, est un gâchis de code et d'approches divergentes, est due au manque de conception architecturale centralisée et omnisciente (là, je l'ai dit).
Les raisons pour lesquelles cela pourrait faire défaut sont les suivantes:
- L'architecte n'a pas l'expertise (comme vos dix premiers projets de loisirs)
- L'architecte n'a pas le temps
- L'architecte n'a pas le pouvoir (le gestionnaire dit non, ou oui mais seulement pour certaines parties)
- L'équipe a foi en une méthodologie vaudou qui les sauvera (tout se résoudra car nous utilisons Agile)
La solution simple est de laisser tomber tous ces mots magiques et de regarder la réalité de la situation, qui peut se résumer comme suit:
- L'état du code entrave la capacité de l'équipe à livrer à temps et sans bogue.
- Plus nous ajouterons de fonctionnalités, pire cela deviendra.
- Par conséquent, il est vraiment judicieux de mettre en pause, de réévaluer et (peut-être radicalement) de repenser les pièces.
Vous arriverez naturellement à vous demander pourquoi il est arrivé à cet état en premier lieu, avec le doigt du blâme qui tourne en rond. La réponse est que cela est inévitable: à mesure que votre conception mûrit, vous réalisez que vous auriez dû le faire différemment, mais vous ne pouviez pas le prévoir. De plus, ce n'est pas une réalisation unique par projet, cela se produira plusieurs fois, et vous devez le planifier.
Cela dit, les gestionnaires peuvent faire beaucoup de choses pour exacerber les choses:
- Deathmarching vos devs aux délais.
- Dire que les développeurs ne peuvent enregistrer le temps que sur les tickets, sans qu'il y ait de tickets pour "réflexion, consolidation et refactoring de qualité" et une allocation de temps généreuse sur ceux-ci.
- Ne pas donner à une seule personne la propriété de l'architecture pendant assez longtemps pour la maîtriser
- Ne pas permettre à cette personne d'apporter les changements qu'elle juge nécessaires
En le regardant de cette façon, il est facile de voir comment certaines interprétations de l'agile et de la mêlée vous feront avancer encore plus rapidement sur cette voie!
Une approche consiste à créer des tickets pour chaque bit de refactoring. Le problème est que souvent vous ne réalisez pas que vous avez besoin d'un grand refactoriseur jusqu'à ce que vous commenciez à travailler sur un ticket plus petit, ce qui repousse les délais, et que le ticket passe par des boucles d'approbation, il ralentit tout simplement.
Une autre approche consiste à planifier des sprints pour n'utiliser que 25 à 50% de la capacité de votre équipe. Les développeurs enregistrent ensuite leur temps sur les vrais tickets (notez le temps que cela aurait dû prendre sans refactorisation) et le temps de refactoring (un gros ticket pour la semaine, pas de boucles d'approbation, uniquement des discussions entre les développeurs). S'il n'y a pas de refactoring, vous pouvez retirer les tickets du sprint de la semaine prochaine. Vous ajustez le curseur de pourcentage pour les semaines à venir à mesure que le code sous-jacent du projet s'améliore.
Donc, pour répondre "qu'est-ce que nous faisons mal", je dirais que vous placez la confiance dans une méthodologie sur le bon sens. Vous demandez même une "approche agile de ce problème". Je dirais de laisser tomber les mots et de réfléchir au problème réel. Si vous voulez vraiment séparer divers manifestes essayant de déchiffrer si votre approche finale de bon sens tombe bien sous le couvert de "agile" ou "scrum", allez-y certainement :-)