Business : Utilisation de Rick et Morty pour résoudre un dilemme d’estimation agile

Agile est génial. Agile est merveilleux. Agile est le sauveur de tout ce qui touche au génie logiciel.

Sur papier.

En pratique, Agile classique est difficile, déroutant, frustrant et carrément difficile à mettre en œuvre. Parce que nous savons que beaucoup de gens contesteraient la déclaration précédente, nous avons besoin d’une certaine contextualisation ici. Par conséquent, une déclaration clarifiée se lit comme suit:

Dans une petite entreprise avec moins de 10 développeurs de logiciels et une poignée d’ingénieurs en matériel, où les projets changent constamment et le nombre de personnes travaillant sur un seul projet peut changer d’une semaine à l’autre, Agile classique est difficile, déroutant, frustrant et juste carrément difficile à mettre en œuvre.

Certains aspects d’Agile sont géniaux pour les petites équipes des petites entreprises. Cela est d’autant plus vrai lorsque les projets en cours suivent de près les besoins et les opportunités de l’entreprise. Les petites entreprises n’ont pas le luxe de tampons entre les ingénieurs et les opportunités. Souvent, de nouvelles opportunités nécessitent de nouvelles fonctionnalités ou des ajustements aux produits existants pour conclure l’accord. Cela place le groupe de développement immédiatement au milieu d’un cycle de vente incertain et en constante évolution.

Lorsque cela se produit, l’équipe de développement se sent comme un navire sans gouvernail dans une tempête avec le vent du changement qui les souffle sur différents projets chaque fois qu’un gros coup de vent survient.

Cela se manifeste par des groupes de développement en constante évolution et des projets en constante évolution. En surface, une méthode agile semble idéale pour attaquer ces changements.

Cependant, deux des principaux problèmes liés à l’utilisation d’Agile dans cet environnement concernent le calcul de la vitesse et la réalisation d’estimations de projet. Nous pourrions considérer ces aspects étroitement liés comme les deux faces d’une même pièce. Le problème qui se pose, comme indiqué ci-dessus, est que lorsque les projets fluctuent souvent et que les personnes qui y travaillent varient d’une semaine à l’autre, il est presque impossible de calculer la vitesse de groupe et donc aucune donnée métrique n’existe pour soutenir une technique d’estimation validée.

Fondamentalement, sans moyen cohérent pour mesurer la vitesse, l’estimation reste ancrée dans le domaine de la REMUER (Devin sauvage). Dans Agile classique, la suppression d’une métrique clé telle que la vitesse déclenche une panne de l’ensemble du processus. Au lieu de continuer de cette manière pendant que le processus s’effondre autour de nous, pourquoi ne pas être proactif et déconstruire d’abord la méthode entière, puis la reconstruire avec des solutions pour les lacunes et les problèmes afin que le processus global soit plus fort et orienté vers les personnes, l’équipe, et entreprise utilisant le système?

Ce qui suit explique comment notre équipe a réussi dans un processus agile personnalisé et a créé une solution aux défis liés à l’estimation des cas d’utilisation.

L’un des principaux défis de l’agilité dans cet environnement concerne la présentation de la comparaison et de la hiérarchisation des pommes aux pommes pour l’effort global requis pour atteindre les objectifs et les fonctionnalités de l’entreprise. Cela couvre à la fois les besoins de priorisation de l’équipe de développement tout en tenant compte des besoins des clients pour l’organisation.

Le spectacle Rick et Morty fournit en fait une réponse étonnante et simple à cette énigme et, ce faisant, pour une petite équipe et le processus de cette équipe, résout un dilemme Agile critique.

UNE « point« Pour une personne n’est pas la même »point»À une autre personne, à la fois en termes de compréhension des estimations et en termes de production réelle. Dans ce scénario, les équipes de développement statiques n’existent pas. Par conséquent, la modélisation d’équipe agile classique n’est pas valide. Il prédit la vélocité en tant que métrique sur BEAUCOUP d’hypothèses dans lesquelles les articles et les livres et vidéos pédagogiques n’entrent jamais vraiment. Les équipes agiles classiques nécessitent la suppression d’un grand nombre de variables:

• Équipes statiques – L’équipe prototypique est composée de 3 à 5 personnes, et cela ne change pas. Cela permet à l’équipe d’estimer l’effort ensemble et la vitesse mesurée comme prédicteur de l’effort futur.
• Les contributions individuelles sont minimisées – L’approche d’équipe classique minimise les écarts dans la signification des points pour les individus et applique cette logique à une équipe. C’est super quand il y a des équipes statiques. Ce n’est pas bien quand les gens se déplacent et que le calcul recommence à chaque fois qu’un changement se produit.
• L’effort d’équipe maximise la production par rapport au niveau de compétence – Lors de la planification et de l’estimation de futurs projets, le fait d’avoir une vitesse d’équipe permet une estimation fiable et à plus haute confiance. Lorsque vous tentez d’appliquer des individus à de futurs projets lorsqu’il existe un large éventail de compétences (débutant, intermédiaire, expert) et de rythme (lent vs rapide). Ces variables rendent cette planification difficile, voire carrément impossible, sans affecter à l’avance des personnes à de futurs projets.
• Les mesures passées déterminent la planification future – Le calcul de la vitesse est la clé de beaucoup de la modélisation agile classique. Cela n’est possible qu’après une certaine période de travail où les mesures de vitesse atteignent en moyenne un niveau de confiance raisonnable. À ce point, des mesures de vitesse sont disponibles pour prévoir les futurs projets. Lors du changement d’équipes et de priorités, ce cycle recommence à zéro et n’arrive jamais là où ces données peuvent faire avancer le processus.

Alors, comment contourner ces problèmes et fournir des estimations raisonnables pour les futurs projets? Comment normaliser ce qu’est un «point»Signifie d’une manière que nous pouvons l’appliquer dans un sens général pour la planification? Comment supprimer autant de variables que possible?

Rick et Morty fournit une réponse étonnante et simple à cette énigme et, ce faisant, pour une petite équipe et le processus de cette équipe, résout un dilemme Agile critique.

Qu’est-ce qu’un ingénieur logiciel moyen? Ils semblent toujours avoir un comportement amical et serviable, prêts à aider quiconque le demande. Ils aiment résoudre des problèmes et terminer la tâche devant eux. Si cette tâche dépasse leurs capacités de résolution, ils y resteront comme un chien à la chasse.

À mesure que le temps passe et que la tâche reste inachevée, leur attitude et leur état mental commencent à empirer de façon spectaculaire. Si la tâche dure assez longtemps, ils sont même sujets à des comportements violents et à une folie pure et simple. Les ingénieurs logiciels appelés à associer des programmes sont connus pour se méfier et s’attaquer les uns les autres au fur et à mesure que leur santé mentale se détériore, bien qu’ils continueront à travailler pour trouver une solution possible à la tâche à accomplir, y compris en collaborant avec d’autres ingénieurs logiciels. Les symptômes psychologiques et physiques de cette existence douloureuse peuvent se manifester en moins de 24 heures.

Le plus drôle, c’est que la description ci-dessus est la description de M. Meeseeks, un personnage de Rick et Morty. J’ai simplement remplacé « M. Meeseeks » avec « Ingénieur logiciel”Et voilà! Le reflet du personnage fictif contre un ingénieur logiciel moyen est d’une précision effrayante.

Dans l’émission Rick et Morty, M. Meeseeks apparaît lorsque quelqu’un appuie sur le bouton d’une boîte Meeseeks. Lorsque cet événement se produit, M. Meeseeks naît et existe seulement assez longtemps pour remplir un objectif singulier. Après avoir atteint cet objectif, ils expirent et disparaissent dans l’air. Empruntant au spectacle, leur motivation pour aider les autres vient du fait que l’existence est douloureuse pour un Meeseeks, et la seule façon de supprimer la douleur de l’existence est de terminer la tâche fournie. La violence physique ne peut pas leur nuire. Plus les Meeseeks restent en vie, plus ils perdent leur raison. Dans le spectacle, le personnage principal Rick avertit la famille Smith de garder leurs tâches simples.

Malheureusement, la vie ne suit pas toujours les recommandations des personnages ultra-intelligents sur le petit écran. Tout comme la famille Smith Rick et Morty donne des tâches de plus en plus complexes à leur collection croissante de Meeseeks, nous définissons chaque jour des problèmes de plus en plus complexes pour les ingénieurs logiciels.

Le concept de M. Meeseeks est utilisé pour tenter de minimiser autant que possible les variables. Les descriptions et la configuration ci-dessus ont un objectif important. Lorsqu’il est enfoncé, le bouton de la zone Meeseeks produit un clone de la même capacité. Chaque fois que le nombre dépasse une ou deux personnes, il y a une complexité supplémentaire qui met en évidence le fait que l’ajout d’une deuxième personne à un projet n’augmente pas linéairement la sortie à 2x la sortie actuelle. Cette idée de rendements décroissants est encore plus apparente et influente plus le projet se poursuit.

Par conséquent, le concept de Meeseeks sert à fournir un cadre simple pour l’estimation de projet. Ce cadre vise une réduction des variables ouvertes et une normalisation des métriques utilisées pour l’estimation. Nous accomplissons cela grâce aux efforts suivants:

• Nous avons défini un «curriculum vitae», un ensemble de compétences et des attentes en matière de capacités pour M. Meeseeks. Le but est de définir un membre générique et moyen de l’équipe. Cette définition d’un M. Meeseeks est utilisée pour estimer les projets et ajouter des fonctionnalités aux produits existants
• Nous avons estimé dans le vide. Cela signifie que l’estimation de projet ne tient pas compte des projets ou du personnel actuels ou futurs. Il ne prend pas en compte le mouvement des personnes entre les projets, les interruptions ou toute autre influence extérieure.
• Bien que de nombreuses variables soient supprimées en estimant à l’aide de l’approche Meeseeks, nous minimisons les variables supplémentaires grâce à des hypothèses. Nous avons supposé que tous les Meeseeks travailleraient sur le projet du début à la fin. Nous avons supposé qu’aucun problème de support, vacances ou changement des besoins commerciaux n’interromprait le projet.
• L’estimation du projet cible un «projet idéal». Cela signifie qu’en utilisant les hypothèses de Meeseeks, nous évaluerons la manière la plus efficace de terminer un projet. Cela ne signifie pas le plus ou le moins de Meeseeks pour y arriver. Cela ciblera le groupe idéal et le plus efficace pour faire le travail.
• Nous avons créé une mesure de «facteur de fudge» pour chaque projet afin d’ajouter du temps tampon à la chronologie estimée du projet. Cette mesure tente de définir les risques et les obstacles potentiels inconnus pour le projet.

Nous sommes NE PAS essayer de fournir une représentation précise de la durée d’un projet. nous SONT essayer de fournir une mesure cohérente de l’effort nécessaire pour ce projet par rapport à celui nécessaire pour un autre projet. Lors de l’estimation, nous ne savons pas combien de personnes seront disponibles pour travailler sur le projet cible ni le niveau de compétence de ces personnes. Nous éliminons donc ces variables tout en nous efforçant de fournir une mesure cohérente d’un projet par rapport à un autre.

Nous devons reconnaître que ceux-ci ressemblent à des délais. Nous essayons d’être agiles et les délais et l’agilité semblent souvent être des concepts en désaccord les uns avec les autres. Il est également à craindre que les délais perçus conduisent à des mesures par rapport à l’équipe de développement. c’est noté. Veuillez continuer.

Un processus doit commencer quelque part et les exigences en jeu concernent une évaluation de la portée des projets ou des cibles. Ce processus tente d’atteindre cet objectif. Cela nécessite également de revoir les données collectées par rapport aux variables connues actuelles présentes au lancement du projet. Cela permet à la fois de revoir les chiffres et de les ajuster au besoin.

Par conséquent, nous visons l’objectif suivant:

La planification de l’estimation génère leprojet idéal« Métriques. Cela permet également un examen des exigences et des cas d’utilisation pour le travail prévu. L’objectif principal est de fournir des données cohérentes d’un projet à l’autre et d’un objectif à l’autre afin que la hiérarchisation donne plus de valeur aux projets de feuille de route et à la planification générale des versions.

Pour la mise en œuvre, nous avons défini cinq paramètres d’estimation pour donner une idée de la portée de la cible à estimer. Ils sont également utilisés pour comparer différents projets ou fonctionnalités les uns par rapport aux autres.

N’oubliez pas – le concept Meeseeks définit un membre génériquement moyen de l’équipe!