Scrum a-t-il du sens lors de l'implémentation d'un nouveau backend de compilateur?

J'ai une langue existante que je dois porter sur une nouvelle plate-forme. J'essaierai probablement ceci en changeant le backend du compilateur existant.

La réécriture du backend représente un travail considérable. Je ne vois pas comment décomposer cela en histoires sensées sans violer les critères INVEST.

Je ne vois pas comment chaque histoire peut être négociable - elles sont toutes requises pour un compilateur fonctionnel. Les histoires ont toutes la même priorité et peu importe l'ordre dans lequel je les livre. J'ai besoin de tout faire.

Certaines parties du logiciel que j'implémente sont moins prioritaires que d'autres et je peux voir que nous pouvons le fournir progressivement. Cependant, il existe un noyau important qui est indispensable .

J'ai l'intention d'essayer de suivre Scrum, mais est-ce que je passe en revue les motions?

Existe-t-il des pratiques recommandées pour ce type de projet?

Gardez à l'esprit que la principale raison pour laquelle les processus Agiles ont été créés était de faire face aux exigences changeantes. Si les exigences sont figées (les exigences vraiment fixes sont rares, mais je vous prendrai au mot ici!), Alors certaines des meilleures pratiques pour faire face à l'évolution des exigences - par exemple, les histoires négociables - deviennent quelque peu hors de propos. Cela dit, suivre un workflow Scrum a encore beaucoup de valeur potentielle en termes de planification et de fourniture de livrables. Même si vos livrables ne constitueront pas un produit entièrement utilisable pendant un certain temps, il y a encore quelque chose à dire pour pouvoir démontrer les progrès à votre client (et à l'équipe!).

Considérez que toutes ces histoires «incontournables» comprennent une seule épopée: «Être capable de compiler sur la plateforme X». Dans ce cas, l'épopée entière doit être terminée avant qu'une valeur ne soit livrée à l'utilisateur, mais c'est souvent le cas au début de grands projets. Commencez par une histoire pour compiler le programme le plus simple possible, puis créez d'autres histoires pour prendre en charge de plus en plus de fonctionnalités linguistiques.

Surtout, ne vous attardez pas trop à essayer de forcer chaque situation à s'inscrire dans une approche très généralisée. Agile est censé travailler pour vous, et non l'inverse!

Bien sûr, Scrum est utile. C'est une méthodologie qui fait deux choses pour vous:

1. Il permet à votre projet de s'adapter au changement et
2. Il vous permet de suivre les progrès et d'avoir une idée du moment où il sera terminé

Il y a donc une certaine valeur à l'utiliser.

Je pense que certaines de vos conditions préalables ne sont pas correctes et c'est là que vous vous perdez.

Je ne vois pas comment chaque histoire peut être négociable - elles sont toutes requises pour un compilateur fonctionnel

Ce n'est pas vrai. Vous pouvez prendre en charge un sous-ensemble de la langue et toujours avoir un compilateur qui fonctionne sous certaines conditions. Sûrement moins précieux qu'un compilateur complet, mais toujours précieux.

En outre, vous comprenez mal ce que signifie "Négociable": cela ne signifie pas nécessairement "Facultatif" et il n'est pas nécessaire que les histoires soient facultatives dans INVEST. Une histoire est un objectif précieux et la négociation porte sur la manière d'atteindre cet objectif. Il y aura sûrement plus qu'un moyen de mettre en œuvre le backend de chaque fonctionnalité linguistique. C'est là que vous avez besoin de négociation.

Les histoires ont toutes la même priorité et peu importe l'ordre dans lequel je les livre.

Ce n'est pas correct, car vous dites ci-dessous que certaines histoires ne sont pas "indispensables", donc certaines ont certainement moins de valeur. Mais même dans la catégorie "must have": certaines fonctionnalités du langage sont beaucoup plus fondamentales que d'autres, et de manière mesurable.

Une façon de mesurer cela est «combien de lignes de code supplémentaires nous pouvons compiler sur une base de code existante» ou «combien de tests supplémentaires réussissent» si vous avez une suite de tests prédéfinie.

Il existe également d'autres options. Si vous compiliez un langage de type C, à proprement parler, vous n'avez besoin que d'un ifet d' une gotoboucle pour avoir un langage (à peine) fonctionnel et vous pouvez l'implémenter while, foret en repeattant que macros. En supposant qu'il soit assez facile d'écrire une utilisation d'un précompilateur, vous pouvez avoir une solution bon marché (hé, négocions-nous? :-)

En ce qui concerne l'adaptabilité, la prise en charge d'une langue est un ensemble d'exigences assez statique, mais les langues changent également et votre connaissance de vos besoins change. Avez-vous besoin de tout mettre en œuvre? Y a-t-il des choses dont vous n'avez pas besoin spécifiquement pour vos objectifs? L'un des locataires de base de l'agile est la connaissance d'avoir des connaissances incomplètes, pouvez-vous en tirer parti?

En conclusion, pour répondre plus directement à votre question: avez-vous besoin de processus agiles lorsque vos besoins sont immuables? Définitivement pas! Sont-ils utilisables? Probablement oui! Vaut-il votre temps? Probablement pas - mais vos exigences sont-elles immuables? Dans mes expériences passées, "exigences immuables" => "propriétaire de produit paresseux" - pas une règle, mais mérite d'être gardé à l'esprit.

TL; DR

Tous les contrôles de gestion de projet ajoutent des frais généraux. N'ajoutez pas de frais généraux dont vous n'avez pas besoin.

Scrum est le mauvais marteau ici (ne soyez pas un clou)

Scrum est un cadre de gestion de projet plutôt qu'un ensemble de pratiques de développement adaptées à un développeur individuel. Sauf si vous faites de la gestion de projet, Scrum n'est probablement pas le bon choix.

De plus, lorsque vous dites:

Les histoires ont toutes la même priorité et peu importe l'ordre dans lequel je les livre. J'ai besoin de tout faire.

vous sous-entendez deux ou trois choses:

1. Le projet n'a aucune valeur, sauf si toutes les histoires sont terminées à 100%.
2. Les histoires ne dépendent pas les unes des autres.

Si ces deux affirmations sont vraies, alors il n'y a vraiment aucun intérêt à utiliser un cadre ou une pratique conçue pour hiérarchiser le travail par valeur ou ordre de dépendance.

Alternatives suggérées

Tout projet de développement pourrait potentiellement bénéficier de certaines pratiques agiles. En particulier, dans votre cas spécifique, je recommanderais:

1. Assurez-vous que toutes vos histoires ont une «définition du fait» qui comprend des tests unitaires et d'acceptation.
2. Intégrer et refactoriser souvent; ne vous laissez pas confier une tâche d'intégration géante à la fin du projet.

De plus, même si votre produit n'a vraiment aucune valeur à moins que toutes les histoires soient terminées, je passerais un peu de temps à regrouper les histoires en thèmes que vous pouvez traiter comme des jalons terminés. Il est souvent plus utile de dire "J'ai terminé la fonction foo" que de dire "J'ai fait 23/117 histoires aléatoires." YMMV.

Je comprends vos préoccupations, mais je pense qu'il est toujours utile pour vous d'utiliser Scrum.

Certes, les user stories sont bien plus figées que dans une application grand public. Cet aspect de la mêlée offrira donc moins de valeur.

Je pense que vous obtiendrez de la valeur grâce aux versions itératives et fréquentes . Avoir un produit potentiellement libérable à la fin de chaque sprint vous oblige à maintenir une qualité de code élevée et une dette technique faible. C'est également un excellent moyen de détecter précocement les défauts.

Je pense que vous auriez également intérêt à connaître votre vitesse . Après plusieurs sprints, vous pouvez voir combien de points d'effort votre équipe termine à chaque sprint. Cela vous donne une métrique objective pour vous aider à déterminer la date de votre expédition.

Surtout, rappelez-vous que l' agilité est un adjectif . À la fin de chaque sprint, vous devriez organiser une réunion rétrospective puis adapter votre processus à vos besoins. S'il y a une partie du processus Scrum qui ne s'applique pas au développement du compilateur, supprimez-la. S'il existe un autre élément de processus qui pourrait vous être utile, ajoutez-le. La partie la plus importante de l'agile à mon avis est d'être conscient de votre processus et de s'améliorer constamment pour votre situation spécifique.

(Veuillez noter que je n'ai jamais fait de mêlée sur un projet de compilateur; suivez mes conseils avec un grain de sel.)

Oui, tant que vous vous souvenez que Scrum n'est pas un ensemble de règles strictes à suivre. Vous pouvez l'adapter à votre projet. Les sprints, les standups, les mêlées hebdomadaires seront toujours utiles afin de favoriser une meilleure communication entre les membres de l'équipe et de s'assurer que le projet continue dans la direction prévue.

Toutes les histoires peuvent sembler avoir une priorité égale, mais vous devez prendre en compte la difficulté relative de leur mise en œuvre. Vous ne souhaitez pas conserver vos éléments les plus difficiles jusqu'à la fin du projet. Vous voudrez commencer à travailler sur eux dès que possible.