Convaincre les chefs de produit «agiles» de la valeur de la planification
Il est devenu responsable technique d'une startup il y a quelques mois. Le développement logiciel est sous Produit dans l'organigramme.
Même selon les normes de démarrage, la base de code dont j'ai hérité est médiocre. Exemple: l'équipe de développement a mis trois semaines pour mettre à jour le texte statique dans le pied de page du site et même alors, elle a abandonné après 80% des pages. La mise à jour du `` composant réutilisable '' du pied de page casse certains modèles, ils ne peuvent pas dire pourquoi, même s'ils travaillent avec le code depuis des mois. Les entrepreneurs d'origine ont bien sûr disparu depuis longtemps et n'ont laissé aucun document derrière.
J'ai obtenu l'adhésion pour nettoyer les choses, les écrire et réduire la dette technologique, mais, bien sûr, premier nous devons créer une nouvelle fonctionnalité de taille moyenne, qui impliquera l'ensemble empiler. Nous savons que c'est un pas vers d'autres fonctionnalités plus importantes. La base de code semble pleine de fonctionnalités abandonnées et à moitié terminées, j'ai donc obtenu l'adhésion d'un des développeurs pour passer cinq jours à explorer le code et à proposer différentes approches, plutôt que de partir avec la première idée dans la tête de quelqu'un.
Le troisième jour sur cinq, le chef de produit a demandé au développeur de progresser - réponse courte, voici quelques idées que nous pourrions faire, mais n'a aucune idée qui sont encore bons car le code est un gâchis, il y a eu une panne de site le deuxième jour pour y faire face, et il a besoin de plus de temps. Ce soir-là, le manager a jonché le pic et l'a remplacé par un "prototype", basé sur l'une des idées. Ce faisant, ils, le chef de produit, ont pris plusieurs décisions techniques sur le champ, me faisant passer pour le responsable technique. De cela et d'autres incidents, je suis sûr que le "prototype" finira rapidement par être mis en ligne, après un rapide "est-ce que ça vous va?" test sur le Macbook du développeur.
Je reçois toute la chose "démarrage agile". La semaine dernière, j'ai une attitude détendue face au risque et la nécessité de mettre quelque chose n'importe quoi entre les mains des utilisateurs. Cela ne me dérange pas que le rang me soit tiré dessus.
Mais ... on m'a dit explicitement "nous sommes une startup, nous ne sommes pas dans cette enquête ****" - "recherche" a été dit comme si c'était un sale mot. J'apprécie également davantage pourquoi la base de code est telle qu'elle est.
Les vieilles mains remarqueront que cela semble être un cas où le produit est pauvre parce que les processus sont pauvres; peut-être du culture de l'organisation étant pauvre. Immergé dans les tranchées, cela ressemble au pire des cas: "Agile signifie que vous rattrapez au fur et à mesure, apprendre de nos erreurs est pour les perdants! que j'ai vu.
Comment puis-je convaincre le gestionnaire de la valeur d'une planification et d'une prévoyance? Ou, peut-être, devrais-je convaincre moi-même que c'est à quoi devrait ressembler cette startup agile?
Il y a quelques points clés à éviter:
- Agile! = Développement paresseux
- Les pointes et les prototypes ne sont pas des idées interchangeables
- Rien de ce que vous avez décrit ci-dessus n'est prescrit par Agile ou Scrum
Pour votre question sur la façon de faire votre cas, cela dépend de leur véritable motivation. S'ils ne comprennent pas les impacts de ce qu'ils font, vous pouvez démontrer l'impact de la dette technique sur la capacité à fournir rapidement de nouvelles fonctionnalités. Si, d'autre part, ils utilisent simplement "nous sommes agiles" pour masquer les mauvaises pratiques de développement et commerciales, il n'y a aucun argument que vous pouvez faire qui changera les choses parce qu'ils savent déjà et qu'ils s'en moquent. Maintenant, j'ai vu beaucoup des deux, donc je vous encourage à ne pas en assumer un ou, si vous le devez, à choisir l'option optimiste pour commencer.
Dette technique
La façon dont j'ai vu le plus de succès dans la défense de la dette technique est la suivante:
Vous avez X temps dans un sprint. Avec un niveau élevé de dette technique, disons que 40% de votre temps est consacré à la gestion de votre dette technique et 60% à de nouvelles fonctionnalités. Si nous sommes excellents en développement, peut-être que cette pile augmente légèrement. Choisissons un nombre et appelons-le 1-2% par sprint. Cependant, dans une start-up, nous devons pivoter rapidement et beaucoup de temps nous finissons accidentellement par endetter beaucoup de dettes techniques, donc même une bonne équipe de démarrage pourrait encourir 5-10% supplémentaires dans un sprint. Bien sûr, si vous n'essayez pas de bien travailler, cela pourrait se développer beaucoup plus rapidement. Si vous ne nettoyez pas cette dette technique, elle ne fait que s'accumuler. Bientôt, un changement qui devrait prendre un jour ou deux prend 3 semaines (cela vous semble familier)?
À ce stade, vous pouvez vous montrer utile ou curmudgeon, et cela dépend vraiment si vous sympathisez avec eux. Ce serait bien si vous pouviez simplement arrêter et résoudre les anciens problèmes, mais l'organisation ne le fera probablement pas, alors trouvons une nouvelle solution. Tout d'abord, vous devez cesser de contracter des dettes techniques si rapidement. Des mesures de qualité efficaces, notamment des tests unitaires, des normes de code et des revues de code, sont essentielles. Ensuite, vous devez commencer à rembourser la dette que vous avez déjà contractée. Peut-être que le vendredi de nettoyage de code avec de la glace est quelque chose que l'entreprise peut absorber. En outre, le ciblage des zones où le développement de fonctionnalités le plus récent devra être réalisé aidera à démontrer comment une base de code plus propre se rentabilise avec une livraison plus rapide des fonctionnalités.
Planification/analyse
Dans votre question, vous semblez confondre dette technique et analyse. Donc, au cas où cela serait utile, vous devrez peut-être également les vendre. Pour ce faire, il est important de comprendre qu'il existe des problèmes complexes et complexes. Avec un problème compliqué, un expert peut, en peu de temps, analyser le problème et identifier une bonne solution. La meilleure structure de données pour stocker des entrées à partir d'un formulaire connu en est un bon exemple. Dans les problèmes complexes, il existe de nombreux facteurs inconnus ou la manière dont les différents facteurs s'influencent mutuellement est difficile à prévoir. Cela nécessite l'expérimentation et l'observation des résultats. Aucune analyse ne vous mènera à la réponse, vous devez entrer et essayer quelque chose. Il est essentiel de savoir quel type de problème vous résolvez.
Ceci est également distinctement différent du développement itératif, qui consiste davantage à résoudre des parties du problème plutôt qu'à s'attaquer à un problème global à la fois.
J'espère que cela t'aides. Bonne chance et j'espère que les gens avec qui vous travaillez ne sont tout simplement pas conscients de l'impact de leurs actions.
Vous ne pouvez pas parce qu'il n'y a aucune valeur pour eux dans la planification.
Les PM recevront des crédits pour terminer les projets dans les délais et le budget, et non sur la qualité du fonctionnement du produit.
Ce que vous pouvez faire, c'est les inciter à ajouter plus d'exigences avant le début du travail. par exemple "fonctionne sur un PC".
Ce sont les exigences les plus nuancées qui animent les bonnes pratiques de programmation. Pas "qualité" ou "bien faire"
Il semble que vous ayez besoin d'exigences telles que "fonctionne avec le système de modèles" et "déploiements à temps d'arrêt zéro" pour piloter une partie du refactoring que vous souhaitez effectuer.
Si vous pouvez obtenir les bonnes exigences, la correction du code devient le projet et les MP fonctionnent pour vous plutôt que contre vous.
"Comment puis-je convaincre ..." les questions supposent que vous avez raison et que le chef de produit a tort. D'après le cadrage de votre question, il ne semble pas que vous ayez fait un gros effort pour comprendre le raisonnement du chef de produit. Mais considérez que le chef de produit pourrait avoir une vue d'ensemble. En tant que développeurs et responsables techniques, il est de votre devoir de comprendre les contraintes commerciales sous lesquelles vous opérez.
Comme vous avez expliqué l'histoire, le chef de produit a économisé deux jours de recherche en prenant une décision rapide. Vous déclarez également que vous comprenez "la nécessité de mettre quelque chose, n'importe quoi, entre les mains des utilisateurs la semaine dernière". Compte tenu de ces prémisses, le chef de produit semble avoir fait le bon appel.
Étant donné que vous avez buy-in pour utiliser certaines ressources pour le nettoyage, il semble que la direction do comprennez que des compromis sont impliqués dans de telles solutions rapides et sales . Alors, qu'est-ce que tu veux les convaincre? Que vous devriez toujours consacrer trois jours à la recherche quelle que soit la criticité du correctif ou de la fonctionnalité à développer?
Le délai de mise sur le marché peut être critique pour une startup. Disons qu'une start-up technologique est à un stade critique - si vous continuez la croissance des utilisateurs pendant un mois, vous obtiendrez de nouveaux investissements majeurs. Si la croissance stagne, l'entreprise doit fermer. Dans de telles circonstances, une startup acceptera volontiers la dette technique - vous optimisez vers une livraison rapide des fonctionnalités au détriment de la maintenabilité à long terme. Si l'entreprise ferme, la question de la maintenabilité à long terme est sans objet. Si cela réussit, vous pouvez embaucher plus de développeurs pour nettoyer le gâchis.
Je pense que la première chose que vous devriez faire est d'avoir un entretien avec le responsable produit pour mieux comprendre les contraintes et les priorités avec lesquelles vous travaillez.
Regardez de près:
Là! Une image vaut mille mots, n'est-ce pas? Eh bien, ne prenez pas ce graphique à sa valeur nominale, c'est juste une illustration, mais de des choses très spécifiques .
Le premier cas (ligne passant au bas de la zone rayée) représente le cas où vous commencez soigneusement, adoptez des modèles et des pratiques appropriés, consacrez le temps nécessaire à la planification et à la conception. Vous évitez la dette technique en passant un peu de temps supplémentaire à rembourser "à la naissance", afin de ne pas accumuler " intérêts ".
Le deuxième cas (ligne passant en haut de la zone rayée) représente le cas où vous commencez
négligemmentsous beaucoup de pression, vous avez donc besoin de résultats maintenant, et de nettoyage plus tard. Dans ce cas, quelle que soit votre expérience et celle de votre équipe, tout ce que vous pouvez faire est simplement de réduire les intérêts sur la dette technique. Mais il s'accumule avec le temps.
Je me concentre sur ces cas parce que vous semblez tomber dans le deuxième cas. J'irais jusqu'à dire que c'est un "deal" plutôt typique avec les startups. Soit vous prenez du temps (et des ressources) pour briller, soit vous obtenez des résultats rapidement et vous les payez plus tard (mais au moins vous avez toujours votre travail).
Le point est aussi simple que cela: étant donné tout point de départ , il y a un instant critique dans le futur, à partir de là, vous commencerez à souffrir d'avoir sérieusement entravé votre productivité en ayant ignoré la "recherche" (vraiment un mot à la mode pour simplement prendre le temps de réduisez votre dette technique ou évitez-la tout le temps). En conséquence, bien sûr, alors que vous ignorez la "recherche", vous ferez plus de travail pendant un certain temps, mais cette période n'est pas éternelle. Ce fait est représenté par la zone rayée orange-y dans le graphique ci-dessus.
Peu importe à quel point on peut se cogner la tête contre un mur, il est impossible de contourner ce fait. La dette technique accumule des intérêts . Un problème qui prend x heures à résoudre maintenant, prend y> = x heures pour corriger plus tard, avec le "> " étant beaucoup plus probable et la différence augmentant avec le temps.
Il ne reste alors plus qu'à prendre des considérations sérieuses , que ce moment critique à venir soit plus proche ou non que certains délai extrêmement important . Si vous allez handicaper votre productivité future, vous devez avoir très bon rea $ on $ pour le faire! Pensez à quelque chose dans le sens d'un accord tout ou rien, par exemple.
Gardez à l'esprit qu'ignorer la recherche peut parfois être la chose " sage " à faire. Par exemple, votre entreprise peut avoir besoin de ressources, qui devraient arriver avant t-critique , mais certainement pas plus tard. Ainsi, un rattrapage douloureux vaut souvent mieux qu’aucune entreprise.
Ce sont les choses difficiles que les gestionnaires doivent gérer, bien sûr, c'est donc leur appel, mais ils doivent très bien comprendre les faits. Peut-être que si vous y réfléchissiez un peu, vous pourriez y approximer les nombres réels et discuter avec votre manager en utilisant ces nombres sur la façon dont vous êtes au-delà de cet instant critique dans le temps et vous vous préparez constamment à des taux de productivité toujours plus bas.
Si votre manager prend le temps, au moins, de faire attention à ce que vous dites/montrez, un graphique accrocheur pourrait faire avancer le point bien mieux que n'importe quelle quantité de mots prononcés.
Mise à jour
En raison de certains des commentaires soulevant de nouvelles questions, il convient de préciser que le graphique ci-dessus n'est qu'une approximation (n trop) simpliste. Estimer l'emplacement approximatif de cet instant t-critique est un problème très difficile, mais ce n'est pas le problème que nous essayons généralement de résoudre (c'est, selon le principe de la responsabilité unique) , un problème de gestion). Ce que nous devrions viser , c'est de savoir de quel côté de l'axe temporel nous sommes, par rapport à cet instant, à un moment donné.
En outre, ce graphique représente simplement ce que la direction doit savoir: "Si nous ignorons l'enquête ****, la recherche (et tous les autres mots clés, qui ne sont que des alias pour le bon code Housekeeping ) , nous ne deviendrons jamais aussi bons que nous aurions pu être si nous vient de passer un peu plus de temps au début ". Si l'une des ambitions/objectifs/nécessités de l'entreprise est une équipe technique hautement flexible et performante, compte tenu de l'état actuel de la base de code/produit, ils pourraient tout aussi bien l'abandonner plus tôt au lieu de gaspiller plus de ressources sur un cas perdu.
Sur cette base, la boîte de dialogue pourrait ressembler à ceci:
- Voir cette 1ère ligne plus haut, "Productivité maximale avec la recherche"? C'est là que nous ne serons probablement jamais encore proches.
- Voir cette 2e ligne ci-dessous, "Pic de productivité sans recherche"? C'est là que nous serons au mieux, c'est-à-dire, si nous avons de la chance . N'essayez pas de mesurer cela en unités métriques, l'échelle verticale est réduite de plusieurs ordres de grandeur!
- Si la survie de l'entreprise dépend d'être " viablement " au-dessus de la ligne inférieure , nous devons simplement le suspendre maintenant que nous le pouvons, pour économiser des ressources et commencer à envisager différentes opportunités de carrière.
La façon dont nous nous dirigeons en ce moment, nous sommes passés t-critiques , donc, afin de même pouvoir grimper au-dessus de la 2e ligne à un moment donné dans le futur, nous devons travailler très dur pour d'abord rembourser les gains de travail virtuel représentée par la zone à rayures orange, et puis s'efforcent de traduire lentement les gains de productivité en une quantité de travail suffisamment importante pour fournir .
Notez que par "gains de travail virtuel", je veux dire que faire plus de travail puis était comme voler ce travail du futur. Pouvez-vous imaginer à quel point notre vie serait meilleure si nous avions 10 minutes supplémentaires de temps productif chaque jour? Eh bien, aller travailler dans nos sous-vêtements nous offrirait ces 10 minutes de productivité supplémentaire. C'est précisément ce qui a été fait. Ne pas s'habiller n'est pas un bon moyen de gagner du temps de votre travail , j'espère que vous suivrez l'analogie et la métaphore.
Soit dit en passant, il ne suffit pas d'être suffisamment productif, vous devez également garder à l'esprit la quantité de travail nécessaire pour
être réaliséont été effectuées à tout moment. Ceci est représenté par des délais! Soit vous déplacez les prochaines échéances prévues pour obtenir du temps pour la récupération, soit nous rentrons tous à la maison ... pas maintenant, bien sûr, mais quelques échéances à partir de maintenant, lorsque le respect d'une échéance nécessitera une productivité bien supérieure à cette 2e ligne sur le tableau ... celui que nous n'atteindrons jamais si nous continuons comme ça ...
Avec agile, l'idée est de planifier en faisant et de nettoyer au fur et à mesure. Lorsque j'ai une semaine pour planifier une fonctionnalité pour une base de code en désordre, le processus se déroule comme suit:
- Passez une matinée à réfléchir à des idées grossières et à un tableau blanc avec mes collègues.
- Passez l'après-midi à essayer de faire la première étape de l'idée la plus prometteuse. Si c'est une nouvelle technologie, cela signifie une sorte de monde bonjour. Je n'essaie pas vraiment d'accomplir la tâche principale ici. J'essaie de savoir ce qui m'empêchera d'accomplir la tâche principale.
- À ce stade, j'ai souvent rencontré le premier dans un code mal structuré. Je passe un jour ou deux à le nettoyer et à améliorer les tests, juste dans la zone que je vais devoir modifier directement pour ajouter la fonctionnalité.
- Passez une matinée à essayer d'ajouter à nouveau la fonctionnalité. Frappez un barrage routier plus fondamental et décidez de pivoter vers le plan B que j'ai réfléchi lundi.
- Étant donné que la fonctionnalité se trouve dans la même zone générale, le nettoyage que j'ai effectué mardi est toujours utile, mais la nouvelle approche nécessite un nettoyage supplémentaire dans une zone légèrement différente. Passez l'après-midi à faire un peu plus de nettoyage.
- Maintenant, le code que je dois changer est en bien meilleure forme. Je le comprends plus profondément. J'ai essayé quelques approches différentes. Je peux mieux expliquer à la gestion des produits pourquoi certaines approches sont irréalisables. Je peux progresser beaucoup plus rapidement, avec des cycles de nettoyage/ajout de code plus courts.
Le nettoyage du code au fur et à mesure est comment vous vous déplacez rapidement. Le travail dans le code permet aux programmeurs d'apprendre ce qui fonctionne. Cela ne signifie pas que vous ne planifiez pas. Cela signifie que vous effectuez vos cycles de planification/exécution/nettoyage sur l'ordre des heures au lieu des semaines.