Faire face aux échecs de sprints et de délais

80

De nombreux ouvrages et articles de Scrum indiquent qu'un sprint échoué (lorsque l'équipe ne parvient pas à compléter certaines fonctionnalités du backlog de sprint) n'est pas si grave, il arrive de temps en temps et peut s'avérer utile si l'équipe apprend de ses erreurs. et améliore quelque chose dans les sprints suivants. Et l'équipe ne doit pas être punie pour ne pas avoir achevé le travail auquel elle s'est engagée.

Cela semble très bien du point de vue du développeur. Cependant, supposons que nous avons une société de logiciels " Scrum-Addicts LLC " qui développe quelque chose pour les clients sérieux (" Money-Bags Corporation "):

  1. Les gestionnaires de Scrum-Addicts suggèrent de créer un logiciel pour Money-Bags
  2. Ils s'accordent sur une liste de fonctionnalités et Money-Bags demande de fournir une date d'expédition
  3. Les responsables de Scrum-Addicts consultent leur équipe de mêlée et celle-ci indique qu'il faudra 3 sprints d'une semaine pour compléter toutes les fonctionnalités.
  4. Le responsable de Scrum-Addicts ajoute une semaine pour plus de sécurité, s’engage à expédier le logiciel dans un mois et signe un contrat avec Money-Bags
  5. Après 4 sprints (délai d'expédition), l'équipe Scrum ne peut fournir que 80% des fonctionnalités (en raison de l'inexpérience avec le nouveau système, de la nécessité de corriger les bugs critiques des fonctionnalités précédentes dans l'environnement de production, etc.).
  6. Comme le suggère Scrum, à ce stade, le produit est potentiellement livrable, mais Money-Bags a besoin de 100% des fonctionnalités, comme indiqué dans le contrat. Alors ils rompent le contrat et ne paient rien.
  7. Scrum-Addicts est au bord de la faillite car Money-Bags ne leur a pas donné d'argent et les investisseurs ont été déçus des résultats et ne veulent plus aider la société.

De toute évidence, aucun éditeur de logiciel ne veut être à la place de Scrum-Addicts. Ce que je ne comprends pas à propos d’Agile et de Scrum, c’est la façon dont ils suggèrent aux équipes de gérer la planification et les délais afin d’éviter la situation décrite ci-dessus. Donc, pour résumer, j'ai 2 questions:

Qui est à blâmer?

  1. Les gestionnaires, car c'est à eux de faire la planification appropriée
  2. L'équipe, parce qu'ils se sont engagés à faire plus de travail qu'ils ne le pourraient
  3. Quelqu'un d'autre

Qu'y a-t-il à faire?

  1. Les gérants doivent déplacer l'échéance deux fois (ou trois fois) plus tard que l'estimation de l'équipe d'origine.
  2. Les membres de l'équipe doivent être encouragés à faire tout le travail auquel ils se sont engagés, peu importe les circonstances (en infligeant des pénalités pour les sprints manqués).
  3. L'équipe doit abandonner Scrum car cela ne correspond pas à la politique de l'entreprise en matière de délais
  4. Nous devrions tous abandonner le développement de logiciels et rejoindre un monastère
  5. ???
André Borges
la source
31
Le point 3 sous "À faire" suppose que le fait de ne pas utiliser Scrum n’aurait rien changé en ne disposant que de 80% des fonctionnalités prêtes en un mois. C'est ridicule.
Doc Brown
7
@ DocBrown, je ne peux pas convenir que c'est ridicule. Abandonner certaines activités Scrum telles que des réunions rétrospectives et de démonstration pourrait accélérer le développement. Et dans le cas d'un contrat solide, cela pourrait aider à atteindre l'objectif ultime: fournir un nombre fixe de fonctionnalités à la fin du délai.
André Borges
26
@AndreBorges Votre suggestion de supprimer des rétrospectives et des démonstrations est la même que de suggérer de supprimer les freins d'une voiture. Bien sûr, les freins ne vous ralentissent que. Mais c’est ce qui vous permet d’aller très vite.
Euphoric
13
le même problème subsiste quel que soit le système. Notez que vous pouvez pratiquement remplacer Scrum par une cascade équivalente et que la société continue de faire
faillite
6
Peut-être que si ces responsables de Scrum-Addicts avaient prêté plus d'attention lors de ces fastueuses réunions "rétrospectives", ils auraient eu la chance de freiner dès la première ou la deuxième semaine, au lieu de regarder le projet se diriger vers la falaise et taper sur la pédale d'accélérateur .
Dorus

Réponses:

134

Je vois plusieurs problèmes de gestion fondamentaux dans votre exemple:

  • si un responsable de Scrum-Addicts signe un contrat à "délai ferme", mais n’ajoute qu’une marge de sécurité de 33% dans une situation où "un nouveau système est impliqué", c’est assez téméraire.

  • la possibilité de livrer au moins x% des fonctionnalités après un mois aurait pu être utilisée pour négocier un contrat dans lequel le client paie au moins partiellement l'argent alors qu'il ne reçoit que 80% des fonctionnalités à la date limite. Un contrat "tout ou rien" est quelque chose dont ni le fournisseur de logiciels ni le client ne bénéficieront. Cela signifie non seulement 0 dollar pour le fournisseur, mais également 0 fonctionnalités pour le client. Et une méthodologie de développement tout-ou-rien comme "Waterfall" ne vous laissera que rédiger de tels contrats; une approche agile offre des possibilités supplémentaires.

  • En regardant les résultats du premier ou des deux premiers sprints, le manager aurait dû se rendre compte que l'équipe ne pouvait pas respecter l'échéance. Il aurait donc dû prendre des mesures plus tôt et redéfinir les priorités des tâches et fonctionnalités restantes, ou essayer de renégocier avec le client plus tôt. Par exemple, le responsable aurait pu essayer de réduire la portée de certaines des fonctionnalités restantes. L'équipe aurait donc pu fournir toutes les fonctionnalités mentionnées dans le contrat, mais chacune d'entre elles dans une portée réduite.

Si une tâche prend plus de temps que prévu, aucune méthodologie de développement ne vous épargnera. Cependant, une approche agile telle que Scrum offre aux responsables plus de possibilités pour contrôler ce qui se passe dans cette situation. S'ils n'utilisent pas ces opportunités, c'est clairement leur faute, pas celle de l'équipe, ni celle de "Scrum", ni celle du client car "il n'accepte pas l'agilité".

Doc Brown
la source
47
+1 pour "Un contrat" ​​tout ou rien "est quelque chose dont ni le fournisseur de logiciel ni le client ne bénéficieront" . C’est l’essentiel des contrats agiles.
guillaume31
5
Et c'est certainement le cas que 80% n'est pas bon pour certains types de projets (en fin de compte, il est possible , bien que peu probable, que l'agile soit trop contraignant pour prévoir ces projets). Ainsi, par exemple, il est inutile d’utiliser 80% des fonctionnalités de votre satellite lorsque vous le lancez, raison pour laquelle vous ne vous souciez pas de la contingence de ces projets. Si vous ne parvenez pas à livrer, alors la mission de votre client échouera (ou sera retardée), vous ne pouvez rien faire dans le contrat pour changer cela.
Steve Jessop
6
@SteveJessop: Je suis presque certain que même lorsque vous construisez un logiciel aussi complexe pour un satellite, il existe différentes priorités pour différentes fonctionnalités, et de nombreuses fonctionnalités dont l'étendue peut varier dans une certaine mesure. La date limite peut être fixée pour une telle situation, bien sûr, car si vous ne mettez pas la fusée dans l'espace avant décembre de l'année prochaine, vous pourriez ne pas avoir une seconde chance.
Doc Brown
6
Mais pour cet exemple spécifique ... bien sûr, personne n’aurait ouvert de nouveaux horizons s’il n’était pas parvenu à terminer le tournage du film. Mais même pour des projets de cette envergure, je parierais que l'on ne va pas dans l'espace avec toutes les fonctionnalités imaginables.
Zaibis
6
peut-être que payer par jalon ou par fonctionnalité pourrait également être une option.
Bram
68

Un des énoncés de valeur du " Manifeste pour le développement logiciel agile " est le suivant:

Collaboration client sur négociation de contrat

Le fait que Scrum-Addicts LLC ait négocié un contrat au lieu d'établir une collaboration avec un client me fait douter de son agilité.

Une chose est claire: l’agilité doit être acceptée par tout le monde. L'agilité n'est pas seulement pour les développeurs. Les gestionnaires et les clients doivent également accepter les valeurs du Manifeste Agile. Si les clients n'acceptent pas l'agilité et exigent toujours des contrats rigides et une collaboration minimale, n'utilisez pas l'agilité ou ne trouvez pas de meilleurs clients.

C'est la faute du client, ils sont bloqués dans leur bulle de contrat avec un développement basé sur des délais.

Euphorique
la source
9
@RubberDuck Il n'y a pas encore de méthodologie de gestion de projet logiciel permettant de définir les fonctionnalités à l'avance, de définir une date limite et de ne pas coûter très cher. Portée, temps, argent; Choisis en deux.
Euphoric
8
@RubberDuck: le projet n'est déjà pas agile, car les exigences sont immuables. Et l'estimation est seulement trois semaines. Il n'y a rien de mal magiquement dans la cascade qui le retarde toujours, il ne peut tout simplement pas gérer les exigences vagues et les changements. Ouais, j'utiliserais "cascade" dans ce cas, ou plus précisément "décidons ce qu'il faut faire et faisons-le".
RemcoGerlich
3
@RemcoGerlich ironiquement, "décidons ce qu'il faut faire et le faisons" est remarquablement agile en soi :-)
gbjbaanb
2
@RemcoGerlich ah, je pense que vous comprenez mal ce que je veux dire: dans le fait que l'agile ne concerne pas vraiment les méthodes de développement, mais la capacité de travailler, en utilisant le moyen que vous voulez. Il s’agit de progrès pas de procédures après tout. (par exemple, une équipe qui ne fait que Scrum n'est pas agile, une équipe qui ne fait que du style cascade mais qui la modifie en fonction des circonstances)
gbjbaanb
2
Je suis d'accord avec Doc Brown ici. Vous pouvez absolument avoir une "limite de temps" sans dire exactement "pour quoi". Il est parfaitement raisonnable de dire, par exemple, "Notre date limite est <une date>. À cette date, nous vous ferons parvenir ce que nous avons fait." La portée de ce qui est expédié ne doit pas nécessairement être gravée dans la pierre au moment où la date limite est créée. Le développement agile consiste essentiellement à gérer l'étendue et à communiquer les progrès réalisés dans des incréments de temps, qui sont en réalité des mini-délais.
Eric King
15

Qui est à blâmer?

Gestionnaires, service juridique, comptables - faites votre choix ...

Je sais que l'exemple est quelque peu artificiel, mais le fait que la société puisse s'en aller sans payer un centime s'il n'était pas satisfait à 100% aurait dû sonner l'alarme immédiate, tout comme le mélange de réflexion agile et de réflexion agile.

Les clients veulent avoir leur gâteau et le manger - ils sont heureux d'accepter cascade, mini-cascade, agile, la-la-la-terre tant qu'ils obtiennent le produit X pour $ Y par date Z.

Le développement agile exige absolument que l'équipe de développement et le client soient sur la même page du point de vue de la méthodologie. Penser aux différences de culture ne fera que ressortir dans le lavis.

Robbie Dee
la source
12

Les projets informatiques traitent des inconnus ; certaines de ces inconnues sont même inconnues . Qu'est-ce que ça veut dire?

Prenons par exemple un pont jouet pour votre modèle de chemin de fer. Il y a tous les paramètres que vous connaissez:

  • Vous savez combien la vallée est grande

  • Vous connaissez le matériau des montagnes, leur hauteur, leur stabilité, etc.

  • Vous savez combien de matériel vous avez besoin

  • Vous savez de précédents "projets" combien de temps il vous a fallu pour construire des choses similaires

De nombreuses variables interviennent dans votre calcul d’investissement de temps et d’argent. Mais vous pouvez dire sans réfléchir si c'est terminé le week-end prochain.

Prenons l'exemple un peu plus loin:

  • Supposons que vous ne construisiez pas le pont pour votre propre modèle de chemin de fer, mais que vous le construisiez pour un étranger: votre travail consiste à construire un pont de chemin de fer entre deux montagnes.

  • Supposons que vous ne disposiez d'aucune information à l'avance du paysage modèle

  • L'information sur le paysage est, c'est-à-dire a deux montagnes, qui ne semblent pas trop grandes

  • La consistance de la montagne est entre roche et gelée

  • Le coût total a un maximum de 10 $

  • Le lieu de travail est complètement noir et il n'y a aucune chance de lumière: vous avez seulement une boîte de 8 allumettes

  • La date limite est de 3 heures

Ce serait l'analogie avec un projet informatique. Vous avez de l'expérience dans la construction de ponts et il est facile de marcher sur un terrain connu. Ce qui rend difficile, c'est l'obscurité . Il y a beaucoup de choses que vous pouvez à peine prédire: Les mesures des montagnes ne sont connues qu'après avoir passé du temps dans l'obscurité. La cohérence des montagnes l'est aussi. À partir de là, vous pourriez faire une estimation du temps que cela vous prendra et de son coût. Ici, les inconnues sont des choses que vous ne connaissez pas au début du projet, comme le terrain concret, etc. Mais il y a des choses que vous ne pouvez pas prévoir, même avec la plus grande expérience et les estimations les plus conservatrices. Ces choses sont les inconnues inconnues qui portent un peu de chaos.

Chaque entreprise informatique devrait le savoir. Ils doivent faire face aux risques du projet.

1) Il existe plusieurs façons de minimiser le risque (financier): l’accord peut inclure que le client paie pour chaque augmentation de travail. Donc, après que l'incrément 1 soit livré, un tarif partiel doit être payé. Tant que Scrum-Addicts LLC livre ses résultats, le risque financier est minime. Plus les objectifs de sprint à grain fin sont planifiés, plus le risque total de chaque sprint est faible. Cela signifie que, si Money-Bags Corporation a reçu 80% du contrat, elle devrait au moins payer 80% de la valeur du contrat. S'ils refusent de payer après un sprint raté, le risque n'est pas aussi élevé que le refus de payer à 100%.

2) Scrum-Addicts LLC a un problème avec leurs développeurs

Les responsables de Scrum-Addicts consultent leur équipe Scrum. Selon l'équipe, il faudra trois sprints d'une semaine pour compléter toutes les fonctionnalités. Le responsable de Scrum-Addicts ajoute une semaine pour être sûr, promet d'envoyer le logiciel dans un mois et signe un contrat. avec des sacs d'argent

Cela suggère que a) les développeurs n’ont pas d’expérience avec Scrum ou b) qu’ils ne font pas correctement Scrum. Plus les équipes travaillent longtemps avec Scrum, meilleures sont leurs estimations. Si les équipes font des estimations et que le manager ajoute un "tampon" comme "sécurité", le manager semble en savoir plus que l'équipe, ce qui est un mauvais signe . Si vous avez une équipe expérimentée, vous n'avez pas besoin d'un "managerbuffer", l'équipe l'a déjà inclus dans l'estimation. L’idée est que plus l’équipe a travaillé ensemble sur les sprints, plus elle connaît ses forces et ses faiblesses et dispose de certains paramètres pour faire des estimations réalistes. Bien sûr, il y a - comme déjà mentionné - les inconnues inconnuesqui ont tendance à rendre les estimations difficiles; ou du moins imprécis. Mais à long terme, les estimations devraient aller de mieux en mieux.

Qui est à blâmer?

1) gestion

Comme indiqué ci-dessus: il y a clairement un échec dans la gestion des risques. Si l'entreprise est au bord de la faillite, elle le mérite. Si vous travaillez dans une telle entreprise: partez!

2) l'équipe

Même si la direction est complètement stupide, l’équipe aurait dû s’opposer à un tel projet. Un bon manager devrait connaître les risques; mais un bon développeur doit signaler les risques. Et surtout: l’équipe doit se présenter tôt si quelque chose échoue.

Qu'y a-t-il à faire?

Maintenant: amenez vos valises à la cour

Pour l'avenir: ne faites pas de tels contrats

Scrum n'est pas à blâmer pour l'échec de la gestion. Scrum a été développé sur la base de l’expérience de nombreux projets informatiques en échec. Il ne peut empêcher l’échec, ni remédier à l’incompétence des équipes ou du management. L'idée de base est:

  • structurer les moyens de communication (qui parle à qui, quand et de quoi)

  • encourager les développeurs à signaler les échecs de manière précoce

  • diviser les problèmes en tâches et sous-tâches

  • structurer le temps et les capacités (qui travaille quand sur quoi)

  • répartir les tâches sur les plages horaires

  • rendre l'imprévisible un peu plus prévisible (planification du poker)

ou globalement: pour minimiser les risques.

Scrum est un outil comme un marteau. Que ce soit un bon outil dépend de votre connaissance de l’utiliser. Mais parfois, un tournevis convient mieux. C'est à vous.

Thomas Junk
la source
1
Un autre aspect de Scrum est d’une importance vitale pour comprendre pourquoi ce projet a échoué: Scrum embrasse l’échec . On s'attend à ce que les deux premiers sprints d'une nouvelle équipe ou d'un nouveau projet échouent. Par le biais du processus Scrum de rétrospectives, l’équipe s’améliorera et, à long terme, ses estimations deviendront exactes, mais seulement tant qu’elles resteront la même équipe travaillant sur le même projet. Lorsque l'un de ces changements change, vous devez à nouveau vous attendre à une défaillance car les variables sous-jacentes changent.
Cronax
9

Tout d'abord, "qui est à blâmer?" est la mauvaise question à poser. Assigner le blâme est amusant et tout, et fera probablement que tout le monde sauf le (s) responsable (s) se sente soulagé (dans un "hé, ce n'est pas de ma faute, le patron l'a dit!"), Mais ce n'est pas une utilisation productive de votre temps , et peut effectivement être contre-productif et provoquer une baisse du moral des employés.

Une meilleure façon de voir les choses est "Quelle est la cause du retard?". Était-ce un manque d'expérience dans la technologie? Bugs critiques non détectés lors des tests / assurance qualité? Manque de test / QA? Trop optimiste dans l'estimation? Ne pas prendre en compte les estimations pas si optimistes de l'équipe? Quelqu'un a été frappé par un bus? Quelle que soit la cause, la question suivante est "Comment faire en sorte que cela ne se reproduise plus?". Dans certains cas (espérons-le rares), la réponse à cette question pourrait être "se débarrasser de tel ou tel", mais si vous partez de "je dois punir le responsable", il est peu probable que vous voyiez la majorité des cas où ce n'est pas la bonne solution.

Dans le projet, vous êtes déjà coulé. La date butoir étant passée, vous avez prévenu le client dès qu'il était évident qu'il allait glisser (parce que vous l'avez fait, non? Si non, c'est une partie du problème), et il faut maintenant le gérer comme il était précisé dans le contrat (il est en fait précisé dans le contrat, non?). De manière générale, cela devrait impliquer de négocier avec le client la manière dont vous allez livrer ce qui manque. Beaucoup de gens aiment penser à un contrat comme quelque chose qui ne peut pas être changé, mais devant soit: a) le laisser tomber et ne pas avoir ce que vous avez acheté, b) poursuivre la société en justice pour rupture de contrat et dépenser beaucoup d'argent devant les tribunaux, et c) en négociant comment obtenir leur produit avec le moins de problèmes possible, la plupart des entreprises choisissent c.

Avant de proposer un prix / une date limite à un client, vous devez analyser les risques liés à une échéance décalée ou à un dépassement des coûts (quelles en sont les causes possibles? Quelles causes pouvez-vous atténuer d'une manière ou d'une autre et que vous ne pouvez pas juste planifier et utiliser ces informations pour vous aider à décider de ce que vous allez promettre. Si c'est un cas où c'est 100% ou rien, vous indiquerez évidemment des prix plus élevés et des délais plus longs, car le risque est plus élevé.

Vous remarquerez que je n'ai pas parlé d'Agile dans toute cette réponse. C'est parce que (je vais oublier une seconde la participation du client à Scrum, bien que ce soit très, très important), à ce stade, cela n'a pas vraiment d'importance. Vous serez confronté à ce problème dans Agile, Waterfall ou tout autre processus de développement que vous utilisez. Oui, Agile est censé vous aider à mieux gérer les risques, en vous permettant de voir s'ils sont devenus des problèmes réels plus tôt, et d'impliquer le client dans le processus lui-même afin qu'il soit toujours informé, mais ce n'est pas une panacée.

Iker
la source
3
-1 Le point agile est qu'un grand nombre des risques ne peuvent tout simplement pas être prédits. Par exemple, ils ont ajouté un tampon d'une semaine au cas où quelque chose se glissait. Vous pouvez toujours tripler le temps nécessaire, mais vous perdez alors contre la concurrence qui ne le fait pas. Agile devrait adopter la mentalité "C'est fait quand c'est fait". Ce qui est tout simplement incompatible avec les contrats et les délais décrits.
Euphoric
3
@Euphoric, je ne peux pas tout à fait d'accord. Oui, le point Agile est que beaucoup de risques ne peuvent pas être prédits, et c'est à quoi sert la mémoire tampon, je vous l'accorde. Cependant, cela ne signifie pas que tous les risques sont imprévisibles, ni que vous devez entrer dans un projet en aveugle, sans tenir compte des risques que vous pouvez prédire.
Iker
2
@Iker L'un n'empêche pas l'autre, mais le point essentiel pour être vraiment agile dans le processus de développement est que la mentalité "c'est fait quand c'est fait" pour le client et pour l'équipe. Bien sûr, il y a toujours des risques que vous pouvez prévoir, mais vous ne pouvez jamais prédire avec succès tous les risques possibles et leur impact exact sur vos progrès. À moins que vous ne puissiez voir l'avenir d'une manière ou d'une autre. C'est pourquoi le travail agile nécessite un contrat spécifique. Vous acceptez ainsi de "continuer à travailler jusqu'à épuisement des fonds, ou si l'une des parties ne veut plus ou ne peut plus le faire, ou si tous les besoins des clients sont satisfaits"
Cronax,
ok, j’ai voté pour le rejet immédiat du blâme en tant que concept. Je conviens que le blâme est un élément non productif qui détourne du succès. Changeons la question. Peut-être pourrions-nous le faire "comment aurions-nous pu gérer cela"? "Comment pouvons-nous transformer cela en un succès pour nous?" "Quels changements de chaque parti auraient pu aboutir à un résultat positif?" Je serais peut-être d'accord pour changer le mot "responsable" en "responsable", mais comme chaque projet avec un fournisseur et un client est une interaction d'équipe, la «équipe» globale n'est-elle pas responsable de toute façon? la question de savoir qui est à blâmer devient alors rhétorique.
Joshua K
4

Tout d’abord, c’est un problème de méthodologie de développement. Au moins avec un système de développement itératif, vous avez quelque chose à montrer au client à la fin du délai, ce qui peut suffire à obtenir une extension pour compléter le produit (même si le client ne paie plus!).

Il existe des cas où une date limite est une date limite, mais imaginez que vous écrivez un jeu et que celui-ci doit absolument être publié à temps pour les vacances de Noël. Se tromper a fait faillite à de nombreuses entreprises!

Scrum n'est probablement pas la meilleure méthode à utiliser pour les méthodes agiles qui doivent compléter une certaine quantité de fonctionnalités avant une certaine date (car j'ai toujours constaté que scrum rend dev go plus lent et ne permet pas assez d'agilité pour modifier le processus lorsque nécessaire.

Quelle que soit la méthodologie, vous avez besoin de créer un arriéré de fonctionnalités requises pour donner une visibilité des progrès. Les progrès sur chaque sprint ne sont pas assez bons, vous ne saurez pas si vous atteignez la cible ultime. Il serait donc préférable d'utiliser une méthodologie de type kanban: définissez toutes les fonctionnalités à gauche et utilisez-les dans le système pour afficher les progrès accomplis.

Cela concentre l'esprit des gens sur ce qui doit encore être fait d'une manière que Scrum ne gère pas, et permet à des personnes autres que l'équipe de développement de voir ce qui reste et si vous êtes susceptible d'atteindre la cible (et ainsi de gérer les attentes du client plus tôt). , ou organisez ces bonus en heures supplémentaires avant qu’ils ne soient nécessaires).

Scrum est un système à la fois indélébile, définissant et perfectionnant en permanence quelque chose. Son tout simplement pas adapté à ce genre de développement. D'autres peuvent gérer ce type tout en conservant le concept de développement itératif, Kanban en est un, Crystal en est un autre. Mais ce qui est essentiel à comprendre, c’est que si vous suivez Scrum avec religion, vous n’êtes pas agile. Tout véritable système agile doit pouvoir s'adapter à ces problèmes particuliers, c’est pourquoi il s’appelait agile en premier lieu. tenez compte de cela dans votre façon de travailler.

gbjbaanb
la source
6
"Jeu prêt pour Noël" pourrait être un posterchild pour Scrum. Expédiez les 80% que vous avez finis, vendez le reste en DLC. Ce n'est pas la situation hypothétique discutée ici, où la date limite fixe à la fois le temps et la portée, avec une pénalité de 100% pour une livraison partielle.
MSalters
2
@MSalters, vous supposez que le jeu fonctionne, que 80% des éléments ne seront peut-être pas manquants, mais que des fonctionnalités peuvent être ajoutées ultérieurement, mais que des fonctionnalités ne sont plus disponibles. Ce n'est pas
obligatoirement
6
C'est le principe de base de Scrum! Les fonctionnalités cassées ne comptent pas. Si vous venez d'un fond d'écran Waterfall, vous constaterez que Scrum donne donc la priorité aux corrections de bogues plutôt qu'à l'ajout de nouvelles fonctionnalités. "80% fait" signifie qu'il manque des niveaux, des patrons manquants, etc.
MSalters
1
@gbjbaanb Selon ce raisonnement, quelque chose peut être fait à 99,9% mais ne fonctionne toujours pas car il se bloque immédiatement au démarrage.
user253751
@immibis mais c'est vrai cependant. Des choses comme les jeux ne tendent pas à laisser les fonctionnalités dehors jusqu'à la fin, la plupart des parties d'un jeu doivent être implémentées pour que tout fonctionne - alors que vous pouvez supprimer certaines fonctionnalités (et je sais que les jeux qui l'ont fait) ne les ajoutent pas caractéristiques progressivement. Donc, un patron manquant serait un jeu cassé. Je n'ai choisi que les jeux comme exemple, car ils ont tendance (particulièrement avant la livraison sur Internet) comme exemples de délais serrés.
gbjbaanb
4

Le paradigme de développement n'est pas synchronisé avec le paradigme du contrat. Idéalement, la manière dont les contrats sont écrits changerait, mais cela ne se produira probablement pas. Cependant, même si vous laissiez tomber Scrum, vous auriez toujours des surprises et des échéances non respectées (seulement vous le seriez probablement beaucoup plus tard, car vous aviez conçu tout cela à l'avance et tout était faux !!).

Avec ou sans modification de la rédaction des contrats, vous livrez ce que vous avez travaillé . Ensuite, remplissez le contrat en consommant un cycle de temps de développement afin de terminer les fonctionnalités que vous n'avez pas réalisées.

Est-ce bien que vous ayez omis de tenir tout ce que vous avez promis le jour de votre promesse? Non, mais votre client sera beaucoup plus heureux si vous pouvez livrer quelque chose qui fonctionne à temps, puis le reste rapidement après que si vous êtes simplement en retard et que vous n'avez rien du tout à leur donner.

Canard en caoutchouc
la source
3
Oui, parfois, le client est plus heureux si son équipe fournit au moins certaines fonctionnalités, mais ce n'est pas toujours le cas. Je parle de cas où (1) le produit est inutile pour les utilisateurs finaux à moins que 100% des fonctionnalités ne soient implémentées (par exemple, il nécessite une certification coûteuse qui ne doit être effectuée que lorsque tout est terminé) ou (2) le client est une société de la vieille école à l’approche «tout ou rien»: si le produit n’est pas prêt à 100%, nous considérons qu’il est en échec, rompons le contrat et renvoyons tout le monde responsable.
André Borges
2
Le client sera toujours plus heureux de voir les progrès réalisés dans le fonctionnement du logiciel. La certification coûteuse peut attendre que le produit soit à leur satisfaction. Le divulguer au client ne signifie pas qu'il doit le divulguer au public. Dans le cas 2, il n'y a vraiment pas d'autre choix que de demander à vos équipes juridiques / commerciales de rédiger de meilleurs contrats. Honnêtement, vos problèmes seraient les mêmes, si ce n’était pire, avec une chute d’eau là-bas.
RubberDuck
2
@AndreBorges Le client sera certainement plus heureux de voir 80% des fonctionnalités que de voir 0% des fonctionnalités? Au moins, le client sait que le produit est principalement fabriqué.
user253751
@immibis, si vous dites cela, cela signifie que vous avez été assez heureux d'éviter certains clients "particuliers" dans votre travail. Il existe de très grosses sociétés maladroites liées au gouvernement qui appliquent des conditions contractuelles pas très raisonnables, mais si vous investissez toutes vos ressources dans leur tâche et réussissez à réussir, elles paient une somme importante qui pourrait élever votre petite entreprise à la hausse. Cependant, si vous échouez, vous risquez de vous trouver un nouvel emploi. C'est le risque que certaines personnes sont disposées à prendre.
André Borges
2
Exactement! En raison de sa bureaucratie interne et de son manque de personnel de direction expérimenté, il est parfois plus facile pour une grande entreprise de considérer un délai échoué comme une "expérience infructueuse" et d'abandonner complètement le projet plutôt que de déployer des efforts supplémentaires pour tenter de communiquer et de renégocier la portée. Triste, mais vrai :(
André Borges
1

De nombreux ouvrages et articles de Scrum indiquent qu'un sprint échoué (lorsque l'équipe ne parvient pas à compléter certaines fonctionnalités du backlog de sprint) n'est pas si grave, il arrive de temps en temps et peut s'avérer utile si l'équipe apprend de ses erreurs. et améliore quelque chose dans les sprints suivants. Et l'équipe ne doit pas être punie pour ne pas avoir achevé le travail auquel elle s'est engagée.

Vous «punissez» ce type de comportement en limitant la quantité de travail que ceux qui n'ont pas terminé peuvent assumer le prochain sprint. Les chances de travailler sur des trucs sympas disparaissent. La récompense pour faire du bon travail est plus de travail.

Cela semble très bien du point de vue du développeur, cependant, supposons que nous avons une société de logiciels "Scrum-Addicts LLC" qui développe quelque chose pour les clients sérieux ("Money-Bags Corporation"):

Les responsables de Scrum-Addicts suggèrent de créer un logiciel pour Money-Bags. Ils conviennent d'une liste de fonctionnalités. Money-Bags demande à fournir une date d'expédition. Les responsables de Scrum-Addicts consultent leur équipe Scrum. Selon l'équipe, cela prendra 3 semaines. -longues sprints pour compléter toutes les fonctionnalités Le gestionnaire Scrum-Addicts ajoute une semaine par sécurité, s'engage à expédier le logiciel dans un mois et signe un contrat avec Money-Bags. Après 4 sprints (délai d'expédition), l'équipe Scrum ne peut livrer que 80% de fonctionnalités (en raison de l'inexpérience avec le nouveau système, de la nécessité de corriger des bogues critiques dans les fonctionnalités précédentes dans un environnement de production, etc.) Comme Scrum le suggère, à ce stade, le produit est potentiellement livrable, mais Money-Bags a besoin de 100% de fonctionnalités, comme mentionné dans le contrat. Alors ils rompent le contrat et ne paient rien.

Scrum-Addicts est au bord de la faillite car Money-Bags ne leur a pas donné d'argent et les investisseurs ont été déçus des résultats et ne veulent plus aider la société.

Si lundi je te parie 100 $ qu'il va pleuvoir jeudi et qu'il ne pleuvra pas avant vendredi, tu aurais raison de prendre mon argent. Si, au lieu d’une chance de jouer, vous voulez des prévisions météorologiques, nous avons besoin d’un contrat nous permettant de vous donner une prévision à jour mardi.

De toute évidence, aucun éditeur de logiciel ne veut être à la place de Scrum-Addicts. Ce que je ne comprends pas à propos d’Agile et de Scrum, c’est la façon dont ils suggèrent aux équipes de gérer la planification et les délais afin d’éviter la situation décrite ci-dessus.

Pensez à POURQUOI MB veut prendre sa balle et rentrer à la maison. MB n'a pas exigé que le travail soit effectué dans un mois au début. SA a promis 100% des fonctionnalités critiques en un mois et n'a pas tenu ses promesses. SA a défini l’échéance et non le MB. SA a même ajouté arbitrairement une semaine à la date limite. Alors, pourquoi est-ce une date limite?

Parfois, lorsqu'ils sont en concurrence pour le travail, les éditeurs de logiciels cèdent à la tentation de se montrer et de promettre la lune. Les professionnels établissent avec soin si une lune est même nécessaire. Quel est le besoin le plus critique de MoneyBags? 100% de fonctionnalités ou un produit fonctionnel dans un mois? Savent-ils même ce qui est vraiment critique? Y at-il un événement à venir fixant une date limite?

Si je négociais ce contrat avec Scrum-Addicts, je voudrais en savoir plus sur les besoins de Money-Bags et structurer le contrat afin d’accorder autant de flexibilité que possible avec Money-Bags. Je leur apprendrais comment fonctionne le processus agile pour qu'ils sachent à quoi s'attendre de nous.

Ainsi, au lieu de s’attendre à ce que tout fonctionne à la perfection en un mois, ils s’attendraient à ce que le premier produit livrable soit évalué en 1 à 2 semaines.

Donc, pour résumer, j'ai 2 questions:

Qui est à blâmer? Les gestionnaires, parce que c'est leur travail de faire la planification
L'équipe, parce qu'ils sont engagés à faire plus de travail qu'ils pourraient
quelqu'un d' autre

N'importe qui aurait pu arrêter cette mascarade avant que nous ayons un mois plus tard.

Je pourrais aller aussi loin que blâmer Money-Bags Corp pour avoir embauché une équipe qui, de manière frauduleuse, représentait de manière agile un processus en cascade comme agile. Le contrat lui-même indique clairement que ce n'est pas agile. Planifier d'être fait dans un mois ne le rend pas agile.

Si vous insistez pour que ce soit agile, c'est agile avec un seul sprint d'un mois. Ce qui, oui, je ne le recommanderais pas car c'est, encore une fois, la même chose que cascade.

Qu'y a-t-il à faire?

Que diriez-vous de l'agilité? Livrer quelque chose à chaque sprint? Obtenir des commentaires avant la date limite? Des sprints d'une semaine? Pourquoi ne pas renégocier le contrat draconien au moment même où vous soupçonnez que le délai est en danger plutôt que de vous cacher et de prier? À tout le moins, vous pouvez arrêter de perdre du temps sur un projet condamné et trouver un client plus raisonnable.

Les gérants doivent déplacer l'échéance deux fois (ou trois fois) plus tard que l'estimation de l'équipe d'origine.

Les multiplicateurs de date limite sont à peu près aussi utiles que de régler votre montre 15 minutes plus tôt pour ne jamais être en retard. Vous pouvez seulement vous tromper si longtemps avant de réaliser ce que vous êtes en train de faire.

Les premières estimations sont fausses. Essayez de capturer comment mal. 5 semaines, donner ou prendre quelques semaines est une expression simple qui vous permet d'exprimer à quel point la date d'achèvement est incertaine. Plutôt que d'essayer de deviner avec précision, vous devinez à quel point votre hypothèse est folle. Faites du vrai travail et obtenez de vraies données. Ensuite, vous pouvez commencer à faire des estimations avec une plage plus étroite. Une à deux semaines, c'est amplement le temps de le faire.

Les membres de l'équipe doivent être encouragés à faire tout le travail auquel ils se sont engagés, peu importe les circonstances (en infligeant des pénalités pour les sprints manqués).

Les membres de l'équipe doivent être encouragés. Échec, commis ou autre. Plutôt que de construire des conséquences artificielles telles que des punitions ou même des bonus (carottes et bâtons), des études ont montré que les personnes qui font du travail créatif, tel que la programmation, réagissent mieux si trois choses sont fournies: Autonomie, Maîtrise et But.

Daniel Pink en a parlé à TED . La discussion porte sur la motivation, pas l'agilité, mais j'ai facilement vu comment mapper ces points sur l'agile:

Autonomie - Je veux diriger ma propre vie - Laissez-moi choisir un travail dans l'arriéré.
Maîtrise - Je veux améliorer quelque chose qui compte - Les commentaires des clients.
Objectif - Je veux faire partie de quelque chose de plus grand que moi - Une équipe collaborative.

L'équipe doit abandonner Scrum car cela ne correspond pas à la politique de l'entreprise en matière de délai. Scrum peut respecter un délai plus précis que la cascade. Compte tenu d'un délai, Scrum peut le respecter. Il peut le rencontrer avec seulement 1 fonction sur 47 en fonction du temps, des fonctionnalités et des compétences, mais il peut le faire.

Un projet agile peut être conçu de manière tellement efficace que chaque soir, lorsque l'équipe rentre chez elle, elle est prête à être expédiée. Cela semble idiot, à moins que vous ne pensiez à l'expédition comme à un test du client. Le plus tôt possible, le plus tôt vous pourrez faire des ajustements. Cela touche toutes les échéances possibles. Juste pas toutes les fonctionnalités. Mais cela vous oriente vers les fonctionnalités qui comptent.

Nous devrions tous abandonner le développement de logiciels et rejoindre un monastère

Oui, comme m'enfermer dans une pièce à l'écart de la vraie vie, ça va me faire écrire moins de code.

J'ai édité cette réponse à la taille. Si vous êtes curieux, lisez l'historique d'édition.

confits_orange
la source
Je voudrais simplement supposer que vous vouliez parler de sprint, pas d'arriéré - je voulais dire exactement ce que j'ai écrit dans la question: l'arriéré de sprint
André Borges,
les personnes qui font du travail créatif, comme la programmation, réagissent mieux si on leur propose trois choses: autonomie, maîtrise et objectif - cela peut être un sujet énorme pour la spéculation en soi, mais le fait est que malheureusement, beaucoup de travail de programmation devient de moins en moins créatif et de plus en plus créatif. routine (tâches ennuyeuses, jeux de piles et de fixations techniques fixes, contrats stricts). Par conséquent, dans de nombreux cas, la carotte et le bâton fonctionnent très bien.
André Borges
@AndreBorges Vous avez raison, je pensais au carnet de produit. Récemment, j'ai travaillé avec un outil qui appelle le backlog de sprint le sprint et le backlog de produit le backlog. Vous m'avez surpris en train de perdre le combat pour que mon vocabulaire ne devienne pas exclusif.
candied_orange
La programmation d'AndreBorges ne sera jamais un bourrage d'enveloppe. C'est fermement un problème de bougie. La raison en est que tout problème répétitif peut être résolu avec le même code que celui qui a résolu le premier problème. Malgré cela, la direction peut s’engager dans un état d’esprit où elle pense que la créativité est un problème à éliminer. J'ai travaillé et couru depuis plusieurs de ces magasins. Ils ne gardent pas les bonnes personnes. Ils ne produisent pas de bons logiciels. Les développeurs sont des artisans. Essayer de les transformer en travailleurs à la chaîne de montage ne fait que nuire à votre cause. Mon travail n'est pas de retourner des œufs. C'est pour s'assurer que les œufs sont retournés.
candied_orange
0

Tout le monde doit être agile. Quoi que vous décidiez, cela ressemblera à qui fait quoi, comment, quand, où et pourquoi par toutes les parties. Clients, responsables et développeurs agiles.

Vous ne pouvez pas donner une date d'expédition trop éloignée dans le futur. Vous donnez une estimation.

Quelqu'un avait besoin de gérer les attentes du client. La raison pour laquelle vous ne craignez pas trop de perdre quelques sprints, c’est parce que vous vous ajustez pour empêcher tout le projet de prendre du retard. Si, après un sprint ou deux, vous concluez que vous ne finissez pas de respecter la "date d'expédition", vous en informez le client.

Maintenant que veux-tu faire? Supprimez les fonctionnalités dont vous n'avez pas besoin ou déplacez la date. Si vous pouviez livrer à temps, vous le feriez. N'hésitez pas à apporter de mauvaises nouvelles.

Qui sait, sur certains projets, vous pouvez expédier plus tôt.

Vous ne pouvez pas être agile si le client ne veut pas.

JeffO
la source
0

Objectif

Je crois que les deux "mesures" suivantes devraient constituer la base de toute décision opérationnelle:

  • le travail est-il rentable (pour le client)
  • travaillons-nous le plus efficacement possible

Ce sont assez universels. Bien sûr, cela devient très compliqué très rapidement, par exemple, pour que le travail soit rentable, il faut que le produit fonctionne correctement, que l'utilisateur puisse utiliser le produit, qu'il soit commercialisé correctement, etc. - pour bon nombre de ces " Scrum-Addicts". LLC "ne porte pas la responsabilité.

Problème

Le contrat ne se concentre pas sur les objectifs décrits ci-dessus. Il existe une clause "tout ou rien" - tout faire et être payé, ou ne rien faire et ne pas être payé. Cependant, cela ne concerne pas directement la création de valeur. Un autre inconvénient est le suivant: nous devons maintenant passer du temps et de l’argent pour assurer et vérifier que le contrat est respecté. Pourquoi voudrions-nous dépenser cet argent? Comment faire en sorte qu'un contrat soit rempli aide-t-il lorsque les exigences ont changé entre-temps et que nous avons découvert que le logiciel commandé ne crée aucune valeur? Il y a juste plus d'argent qui coule à l'eau! Maintenant, bien sûr, il y a une raison à ce comportement:

  • Culturellement, nous avons l'habitude de magasiner pour des choses comme ça. Nous attendons des acheteurs de logiciels comme nous le ferions pour une voiture: choisissez une configuration, obtenez un prix et une échéance, et soyez très mécontent si ces deux problèmes ne sont pas respectés.
  • nous voulons décharger le risque et la responsabilité
  • nous voulons de la stabilité, cela aide à la planification et nous fait sentir mieux (ainsi que notre client, qui est un aspect important!)

En fin de compte, nous devrons choisir un compromis qui nous permettra de satisfaire au mieux nos objectifs.

Voici comment cela devrait fonctionner

  • avoir un contrat de services et de travail au lieu d' un produit
    • doit pouvoir être résilié avec un préavis relativement court
  • travailler en étroite collaboration pour assurer une efficacité optimale
  • impliquer toutes les parties nécessaires, à la fois de " Scrum-Addits LLC " et de " Money-Bags Corporation " - un "point de contact unique" crénelant toutes les informations ne fonctionnera pas ici

Eh bien, en gros, je viens de dire "soyez agile". Maintenant, voici pourquoi:

  • processus et contrat sont optimisés pour dépenser autant d' argent sur le but que possible
  • vous devrez faire confiance à l'entrepreneur pour faire son travail et ne pas avoir à investir beaucoup d'argent pour vérifier qu'il est à la hauteur.
  • la possibilité de poursuivre votre entrepreneur en justice si vos attentes / votre contrat n’est pas respecté n’aide en général pas, car cela coûtera plus cher que de simplement le laisser tomber. Certaines des principales préoccupations ici sont la mise sur le marché. Vous allez probablement perdre beaucoup plus d’argent / d’affaires en allant au tribunal que vous ne l’obtiendrez.
    • à la fin de la journée, vous devrez assumer vous-même certains risques.
BatteryBackupUnit
la source