Gérer les sprints et les délais échoués
De nombreux livres et articles Scrum disent qu'un sprint échoué (lorsque l'équipe ne parvient pas à compléter certaines fonctionnalités du Sprint Backlog) n'est pas quelque chose de si mauvais, cela arrive de temps en temps, et cela peut être utile si l'équipe apprend de ses erreurs et améliore quelque chose dans les sprints suivants. Et l'équipe ne devrait pas être punie pour ne pas avoir terminé le travail auquel elle s'était engagée.
Cela semble très bien du point de vue du développeur, cependant, disons que nous avons une société de logiciels " Scrum-Addicts LLC " développant quelque chose pour les clients sérieux (" Money-Bags Corporation "):
- Les managers de Scrum-Addicts suggèrent de créer un logiciel pour Money-Bags
- Ils conviennent d'une liste de fonctionnalités et Money-Bags demande de fournir une date d'expédition
- Les managers de Scrum-Addicts consultent leur équipe Scrum, et l'équipe dit qu'il faudra 3 sprints d'une semaine pour compléter toutes les fonctionnalités
- Scrum-Addicts manager ajoute 1 semaine pour être sûr, promet d'expédier le logiciel en 1 mois et signe un contrat avec Money-Bags
- Après 4 sprints (délai de livraison), l'équipe Scrum ne peut fournir que 80% des fonctionnalités (en raison de l'inexpérience du nouveau système, de la nécessité de corriger des bugs critiques dans les fonctionnalités précédentes de l'environnement de production, etc ...)
- Comme le suggère Scrum, à ce stade, le produit est potentiellement livrable, mais Money-Bags a besoin de 100% des fonctionnalités, comme mentionné dans le contrat. Ils rompent donc le contrat et ne paient rien.
- Scrum-Addicts est au bord de la faillite car ils n'ont pas reçu d'argent de Money-Bags, et les investisseurs ont été déçus des résultats et ne sont plus disposés à aider l'entreprise.
De toute évidence, aucune entreprise de logiciels ne veut être à la place de Scrum-Addicts. Ce que je ne comprends pas sur Agile et Scrum, c'est comment ils suggèrent aux équipes de gérer la planification et les délais pour éviter la situation décrite ci-dessus. Donc, pour résumer, j'ai 2 questions:
Qui est à blâmer?
- Les gestionnaires, parce que c'est leur travail de faire la bonne planification
- L'équipe, parce qu'elle s'est engagée à faire plus de travail qu'elle ne le pouvait
- Quelqu'un d'autre
Que faire?
- Les managers doivent déplacer le délai 2x (ou 3x) plus tard que l'estimation initiale de l'équipe.
- Les membres de l'équipe devraient être encouragés à faire tout le travail auquel ils se sont engagés quoi qu'il arrive (en imposant des pénalités pour les sprints ratés)
- L'équipe devrait abandonner Scrum car cela ne correspond pas à la politique de l'entreprise en matière de délais
- Nous devrions tous abandonner le développement de logiciels et rejoindre un monastère
- ???
Je vois plusieurs problèmes de gestion fondamentaux dans votre exemple:
si un manager de Scrum-Addicts signe un contrat "hard-deadline", 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 disponibilité de la livraison d'au moins x% des fonctionnalités après un mois aurait pu être utilisée pour négocier un contrat où le client paie l'argent au moins partiellement lorsqu'il n'obtient que 80% des fonctionnalités à la date limite. Un contrat tout ou rien est quelque chose dont ni le vendeur de logiciels ni le client ne bénéficieront - cela signifie non seulement 0 argent pour le vendeur, mais aussi 0 fonctionnalités pour le client. Et une méthodologie de développement tout ou rien comme "Waterfall" ne vous permettra que de rédiger de tels contrats, une approche agile offre des possibilités supplémentaires.
regarder les résultats du premier ou des deux premiers sprints aurait dû faire comprendre au manager que l'équipe ne pouvait pas respecter le délai. 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 gestionnaire aurait pu essayer de réduire la portée de certaines des fonctionnalités restantes, de sorte que l'équipe aurait pu fournir toutes les fonctionnalités mentionnées dans le contrat, mais chacune dans une portée réduite.
Si une tâche s'avère plus longue que vous ne le pensiez, aucune méthodologie de développement ne vous en épargnera. Mais une approche agile comme Scrum donne à la direction plus d'occasions de contrôler ce qui se passe dans cette situation. S'ils ne profitent pas de 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é".
L'une des déclarations de valeur du " Manifeste pour le développement logiciel Agile " est:
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 remettre en question leur agilité.
Une chose est claire: l'agilité doit être acceptée par TOUS. L'agilité n'est pas réservée aux développeurs. Les managers et les clients doivent également accepter les valeurs du Manifeste Agile. Si les clients n'acceptent pas l'agilité et nécessitent toujours des contrats rigides et une collaboration minimale, alors n'utilisez pas Agile ou trouvez de meilleurs clients.
C'est la faute du client s'il est enfermé dans sa bulle contractuelle avec un développement axé sur les délais.
Qui est à blâmer?
Gestionnaires, service juridique, comptables - faites votre choix ...
Je sais que l'exemple est quelque peu artificiel, mais le fait que l'entreprise puisse s'en aller sans payer un centime si elle n'était pas satisfaite à 100% aurait dû sonner l'alarme immédiatement, tout comme le mélange de la cascade et de la pensée agile.
Les clients veulent avoir leur gâteau et le manger - ils sont heureux d'accepter la cascade, la mini-cascade, l'agile, la-la-land tant qu'ils obtiennent le produit X pour Y $ à la date Z.
Développement agile nécessite absolument l'équipe de développement et le client doivent être sur la même page d'un point de vue méthodologique. Penser que les différences de culture ressortiront au grand jour est un vœu pieux.
Les projets informatiques traitent des inconnues ; certaines de ces inconnues sont même inconnues inconnues . Qu'est-ce que ça veut dire?
Prenez par exemple un pont jouet pour votre chemin de fer miniature. Vous connaissez tous les paramètres:
Tu sais à quel point la vallée est grande
Vous connaissez le matériau des montagnes, leur hauteur, leur stabilité, etc.
Vous savez de combien de matériel vous avez besoin
Vous savez des "projets" précédents combien de temps il vous a fallu pour construire des choses similaires
De nombreuses variables impliquées influencent votre calcul de l'investissement de temps et d'argent. Mais vous pourriez dire sans réfléchir, si c'est terminé le week-end prochain.
Prenons l'exemple un peu plus loin:
Disons que vous ne construisez pas le pont pour votre propre chemin de fer miniature, mais que vous le construisez pour un parfait inconnu: votre travail consiste à construire un pont ferroviaire entre deux montagnes
Supposons que vous ayez presque aucune information avant le paysage du 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 sombre et il n'y a aucune chance de lumière: vous n'avez qu'une boîte de 8 allumettes
Le délai 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évoir: les mesures des montagnes ne sont connues qu'après avoir piqué quelque temps dans l'obscurité. Il en va de la cohérence des montagnes. À partir de cela, vous pourriez faire des estimations sur combien de temps cela vous prendra et combien cela vous coûtera. Ici les inconnues sont des choses que vous ne connaissez pas au début du projet comme le terrain en béton etc. Mais il y a des choses que vous ne pouvez pas prévoir, même avec le plus d'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 au risque du projet.
1) Il existe plusieurs façons de minimiser le risque (financier): l'accord peut inclure le fait que le client paie pour chaque incrément de travail. Ainsi, après la livraison de l'incrément 1, un taux partiel doit être payé. Tant que Scrum-Addicts LLC livre, le risque financier est minime. Plus les objectifs de sprint sont précis , plus le risque total de chaque sprint est faible. Cela signifie que si Money-Bags Corporation a reçu 80% du contrat, elle doit au moins payer 80% de la valeur du contrat. S'ils refusent de payer après un sprint échoué, le risque n'est pas aussi élevé que le refus de payer 100%.
2) Scrum-Addicts LLC a un problème avec ses développeurs
Les managers de Scrum-Addicts consultent leur équipe Scrum, et l'équipe dit qu'il faudra 3 sprints d'une semaine pour compléter toutes les fonctionnalités Scrum-Addicts manager ajoute 1 semaine pour être sûr, promet d'expédier le logiciel dans 1 mois et signe un contrat avec des sacs d'argent
Cela suggère que a) les développeurs ne sont pas expérimentés avec la mêlée ou b) qu'ils font mal la mêlée Plus les équipes travaillent avec la mêlée, meilleures sont leurs estimations. Si les équipes font des estimations et que le manager ajoute un "tampon" comme "sécurité", le manager semble mieux connaître que l'équipe, qui est un - mauvais signe. Si vous avez une équipe expérimentée, il n'y a pas besoin de "managerbuffer", l'équipe l'a déjà inclus dans l'estimation. L'idée est la suivante: plus l'équipe a travaillé ensemble, plus elle connaît ses forces et ses faiblesses et dispose de paramètres pour faire des estimations réalistes. Bien sûr, il y a - comme déjà mentionné - les inconnues inconnues qui ont tendance à rendre les estimations difficiles; ou du moins imprécis. Mais à long terme, les estimations devraient de mieux en mieux.
Qui est à blâmer?
1) Gestion
Comme dit plus haut: 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 totalement stupide, l'équipe aurait dû s'opposer à un tel projet. Un bon gestionnaire doit connaître les risques; mais un bon développeur doit signaler les risques. Et surtout: l'équipe doit signaler tôt si quelque chose échoue.
Que faire?
Maintenant: Amenez Sacs d'argent au tribunal
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 pas empêcher l'échec, ni guérir l'incompétence des équipes ou de la direction. L'idée de base est:
pour structurer les voies de communication (qui parle à qui quand à propos de quoi)
pour encourager les développeurs à signaler les échecs tôt
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 (planifier le poker)
ou globalement: pour minimiser les risques.
Scrum est un outil comme un marteau. Que ce soit un bon outil dépend de vos connaissances sur son utilisation. Mais parfois, un tournevis convient mieux. C'est à vous.
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 les personnes blâmées se sentent soulagés (dans un sens "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 en fait être contre-productif et entraîner une baisse du moral des employés.
Une meilleure façon de voir les choses est "Qu'est-ce qui a causé le retard?". S'agit-il d'un manque d'expérience dans la technologie? Bogues critiques qui n'ont pas été détectés lors des tests/QA? Manque de tests/QA? Trop optimiste dans l'estimation? Ne tenant pas compte des estimations pas si optimistes de l'équipe? Quelqu'un a été renversé par un bus? Quelle que soit la cause, la question suivante est "Comment pouvons-nous nous assurer que cela ne se reproduise plus?". Dans certains cas (espérons-le rares), la réponse pourrait être "se débarrasser de telle ou telle chose", mais si vous partez de "J'ai besoin de punir la personne 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é. Le délai est venu et passé, vous avez averti le client dès qu'il était évident qu'il allait glisser (parce que vous l'avez fait, non? Si cela fait partie du problème), et maintenant il doit être géré comme il a été précisé dans le contrat (il est en fait précisé dans le contrat, non?). D'une manière générale, cela devrait impliquer la négociation avec le client de 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 face à a) abandonner le contrat et ne pas avoir ce que vous avez acheté, b) poursuivre la société pour rupture de contrat et dépenser beaucoup d'argent au tribunal, et c) négocier comment obtenir leur produit avec le moins de problèmes possible, la plupart des entreprises choisissent c.
Pour l'avenir, avant de proposer un prix/délai à un client, vous devez analyser les risques liés à un délai dépassé ou à un dépassement de coût (quelles sont les causes possibles d'une telle chose? Quelles causes pouvez-vous atténuer d'une manière ou d'une autre et que vous ne pouvez pas et simplement planifier) et utiliser ces informations pour décider de ce que vous allez promettre. Si c'est un cas où c'est 100% ou rien, vous proposerez é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 l'implication du client dans Scrum pendant une seconde, 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 en impliquant le client dans le processus lui-même afin qu'il soit toujours informé, mais ce n'est pas une panacée.
Le paradigme de développement n'est pas synchronisé avec le paradigme du contrat. Idéalement, la façon dont les contrats sont rédigés changerait, mais il est peu probable que cela se produise réellement. Cependant, même si vous deviez abandonner la mêlée, vous auriez toujours des surprises et des délais manqués (seulement vous seriez probablement beaucoup plus tard parce que vous avez fait tout ce design à l'avance et que tout allait mal !!).
Avec ou sans modification de la rédaction des contrats, vous expédiez ce que vous avez travaillé . Ensuite, remplissez le contrat en mangeant un cycle de temps de développement afin de terminer les fonctionnalités que vous n'avez pas faites.
Est-il bon que vous n'ayez pas livré 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 livrer le reste rapidement après que si vous êtes simplement en retard et que vous n'avez rien du tout à leur donner.
Premièrement, c'est un problème avec toute 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 pour obtenir une extension pour compléter le produit (même si le client ne paie plus!).
Il y a des cas où un délai est un délai cependant, imaginez que vous écrivez un jeu et qu'il doit absolument être publié à temps pour les vacances de Noël. Se tromper a mis en faillite de nombreuses entreprises!
Pour les méthodes agiles qui doivent compléter une certaine quantité de fonctionnalités à une certaine date, la mêlée n'est probablement pas la meilleure méthode à utiliser (car j'ai toujours trouvé que la mêlée ralentit le développement et ne permet pas une agilité suffisante pour modifier le processus lorsque nécessaire.
Ce dont vous avez besoin, quelle que soit la méthodologie, est de mettre en place un backlog de fonctionnalités requises pour donner une visibilité sur les progrès. Les progrès par sprint ne sont pas assez bons, vous ne saurez pas si vous atteignez l'objectif ultime. Une méthodologie de type kanban serait donc préférable: définissez toutes les fonctionnalités sur la gauche et travaillez-les dans le système pour afficher les progrès jusqu'à leur achèvement.
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 aux personnes autres que l'équipe de développement de voir ce qui reste et si vous êtes susceptible d'atteindre l'objectif (et donc de gérer les attentes du client tôt ou organisez ces primes pour heures supplémentaires avant qu'elles ne soient nécessaires).
Scrum est un système qui ne s'arrête jamais, définissant et affinant continuellement quelque chose. Ce n'est tout simplement pas adapté à ce type de développement. D'autres peuvent gérer ce sytle et garder le concept de développement itératif, Kanban en est un comme ça, Crystal un autre. Mais ce qui est essentiel à comprendre, c'est que si vous suivez Scrum religieusement, vous n'êtes pas agile. Tout vrai système Agile devrait être capable de se transformer pour faire face à ces problèmes particuliers, c'est pourquoi il a été appelé agile en premier lieu, il s'agit de faire ce qui doit être fait, et si un délai fixe en fait partie, alors vous devriez tenez compte de cela dans votre façon de travailler.
De nombreux livres et articles Scrum disent qu'un sprint échoué (lorsque l'équipe ne parvient pas à compléter certaines fonctionnalités du Sprint Backlog) n'est pas quelque chose de si mauvais, cela arrive de temps en temps, et cela peut être utile si l'équipe apprend de ses erreurs et améliore quelque chose dans les sprints suivants. Et l'équipe ne devrait pas être punie pour ne pas avoir terminé le travail auquel elle s'était engagée.
La façon dont vous "punissez" ce type de comportement consiste à limiter la quantité de travail que ceux qui n'ont pas terminé peuvent effectuer au 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, disons que nous avons une société de logiciels "Scrum-Addicts LLC" développant quelque chose pour des clients sérieux ("Money-Bags Corporation"):
Les managers de Scrum-Addicts suggèrent de créer un logiciel pour Money-Bags. Ils se mettent d'accord sur une liste de fonctionnalités, et Money-Bags demande de fournir une date d'expédition. -des sprints longs pour compléter toutes les fonctionnalités Scrum-Addicts manager ajoute 1 semaine pour être sûr, promet d'expédier le logiciel en 1 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 du nouveau système, de la nécessité de corriger des bogues critiques dans les fonctionnalités précédentes de l'environnement de production, etc ...) 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. Ils rompent donc le contrat et ne paient rien.
Scrum-Addicts est au bord de la faillite car ils n'ont pas reçu d'argent de Money-Bags, et les investisseurs ont été déçus des résultats et ne sont plus disposés à aider l'entreprise.
Si lundi je vous parie 100 $ qu'il pleuvra jeudi et qu'il ne pleuvra pas jusqu'à vendredi, vous auriez raison de prendre mon argent. Si, plutôt qu'une chance de jouer, ce que vous voulez, ce sont des prévisions météorologiques, nous avons besoin d'un contrat qui me permette de vous donner une prévision mise à jour mardi.
De toute évidence, aucune entreprise de logiciels ne veut être à la place de Scrum-Addicts. Ce que je ne comprends pas sur Agile et Scrum, c'est comment ils suggèrent aux équipes de gérer la planification et les délais pour éviter la situation décrite ci-dessus.
Pensez à POURQUOI MB veut prendre son ballon et rentrer chez lui. MB n'a pas exigé que le travail soit fait en un mois au départ. SA a promis 100% des fonctionnalités critiques en un mois et n'a pas livré. SA fixez la date limite non Mo. SA = même arbitrairement ajouté une semaine au délai. Pourquoi est-ce un délai?
Parfois, en concurrence pour les entreprises de logiciels de travail céder à la tentation de se montrer et de promettre la lune. Les professionnels établissent soigneusement si une lune est même requise. Quel est le besoin le plus critique de MoneyBags? 100% de fonctionnalités ou un produit fonctionnel en un mois? Savent-ils même ce qui est vraiment critique? Y a-t-il un événement à venir qui fixe une date butoir?
Si j'étais Scrum-Addicts négociant ce contrat, je voudrais en savoir beaucoup plus sur les besoins commerciaux de Money-Bags et structurer le contrat pour accorder autant de flexibilité que Money-Bags est à l'aise avec. Je leur apprendrais comment fonctionne le processus agile pour qu'ils sachent à quoi s'attendre de nous.
De cette façon, plutôt que de s'attendre à ce que tout fonctionne soudainement parfaitement dans un mois, ils s'attendraient à évaluer le premier livrable 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 bonne planification
L'équipe, parce qu'elle s'est engagée à faire plus de travail qu'elle ne le pouvait
Quelqu'un d'autre
N'importe qui aurait pu arrêter cette parodie avant que nous ayons un mois sur la route.
Je pourrais aller jusqu'à blâmer Money-Bags Corp d'avoir embauché une équipe qui a manifestement frauduleusement représenté un processus de cascade comme étant agile. Le contrat lui-même indique clairement que ce n'est pas agile. Planifier en un mois ne le rend pas agile.
Si vous insistez pour qu'il soit agile, il est agile avec un seul sprint d'un mois. Ce que, oui, je ne recommanderais pas parce que, encore une fois, c'est la même chose que la cascade.
Qu'y a-t-il à faire?
Et agile? Vous livrez quelque chose à chaque sprint? Obtenez des commentaires avant la date limite? Sprints d'une semaine? Que diriez-vous de renégocier le contrat draconien au moment même où vous pensez que l'échéance 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 managers doivent déplacer le délai 2x (ou 3x) plus tard que l'estimation initiale de l'équipe.
Les multiplicateurs de délais sont à peu près aussi utiles que de régler votre montre 15 minutes plus tôt afin que vous ne soyez jamais en retard. Vous ne pouvez vous tromper que si longtemps avant de réaliser ce que vous faites.
Les premières estimations sont fausses. Essayez de capturer à quel point. 5 semaines, donner ou prendre quelques semaines est une expression simple qui vous permet d'exprimer à quel point la date d'achèvement est vraiment incertaine. Plutôt que d'essayer de deviner avec précision, vous devinez à quel point votre supposition est sauvage. Faites du vrai travail et obtenez des données réelles. Ensuite, vous pouvez commencer à faire des estimations avec une plage plus étroite. Une à deux semaines suffisent pour le faire.
Les membres de l'équipe devraient être encouragés à faire tout le travail auquel ils se sont engagés quoi qu'il arrive (en imposant des pénalités pour les sprints ratés)
Les membres de l'équipe doivent être encouragés. Échec, engagement ou autre. Plutôt que de construire des conséquences artificielles telles que des punitions ou même des bonus (carotte et bâton), des études ont montré que les personnes qui font un travail créatif tel que la programmation répondent mieux si elles fournissent trois choses: autonomie, maîtrise et objectif.
Daniel Pink a un TED talk à ce sujet. Le discours porte sur la motivation, pas agile, mais j'ai facilement vu comment mapper ces points sur agile:
Autonomie - Je veux diriger ma propre vie - Permettez-moi de choisir le travail dans l'arriéré.
Maîtrise - Je veux m'améliorer dans 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 devrait abandonner Scrum car cela ne correspond pas à la politique de la société en matière de délais. Scrum peut atteindre un délai plus précisément que la cascade. Étant donné un délai, Scrum peut le respecter. Il peut le rencontrer avec seulement 1 des 47 fonctionnalités en fonction du temps, de la fonctionnalité et des compétences, mais il peut le rencontrer.
Un projet agile peut être conçu si fort que chaque soir, lorsque l'équipe rentre chez elle, elle est prête à être expédiée. Cela semble stupide à moins que vous ne pensiez à l'expédition comme demandant au client de tester et de fournir des commentaires. Plus tôt cela se produit, plus tôt vous pourrez effectuer des ajustements. Cela atteint tous les délais possibles. Mais 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
Bon, comme m'enfermer dans une pièce éloignée de la vraie vie va me faire écrire MOINS de code.
J'ai édité cette réponse jusqu'à sa taille. Si vous êtes curieux, lisez l'historique des modifications.
Tout le monde doit être agile. Quoi que vous décidiez, ce sera, qui fait quoi, comment, quand, où et pourquoi par toutes les parties. Clients, gestion et développeurs agiles.
Vous ne pouvez pas donner une date d'expédition trop loin dans le futur. Vous donnez une estimation.
Quelqu'un devait gérer les attentes du client. La raison pour laquelle vous ne vous inquiétez pas trop de la perte de quelques sprints est que vous vous ajustez pour empêcher tout le projet de prendre du retard. Si vous arrivez à la conclusion après un sprint ou deux que vous n'allez pas finir de respecter la "date d'expédition", c'est à ce moment-là que vous le dites au client.
Maintenant, que veux-tu faire? Débarrassez-vous des 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 le veut pas.
Objectif
Je pense que les deux "mesures" suivantes devraient être à la base de toute décision commerciale:
- le travail est-il rentable (pour le client)
- travaillons-nous aussi efficacement que possible
Ce sont assez universels. Bien sûr, cela devient plus compliqué très rapidement, par exemple, le travail rentable consiste à faire le bon produit, à permettre à l'utilisateur d'utiliser le produit, à le commercialiser correctement, etc. - pour beaucoup de ces "Scrum-Addicts LLC "n'est pas responsable.
Problème
Le contrat ne se concentre pas sur les objectifs décrits ci-dessus. Il y a une clause "tout ou rien" - tout faire et être payé, ou ne rien faire et ne pas être payé. Cependant, cela n'est pas directement lié à la création de valeur. Un autre inconvénient qui suit: maintenant nous devons dépenser du temps et de l'argent pour assurer et vérifier que le contrat est respecté. Pourquoi diable voudrions-nous dépenser cet argent? Comment le fait de s'assurer qu'un contrat est 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! Maintenant, bien sûr, il y a une raison à ce comportement:
- Culturellement, nous sommes habitués à acheter des choses comme ça. Nous attendons un magasin de logiciels comme nous le ferions pour une voiture: choisissez une configuration, recevez un prix et un délai, et soyez très mécontent si ces deux ne sont pas respectés.
- nous voulons décharger le risque et la responsabilité
- nous voulons de la stabilité, cela aide à planifier et nous fait nous sentir mieux (et aussi notre client, ce qui est un aspect important!)
En fin de compte, nous devrons choisir un compromis qui nous permettra de satisfaire au mieux nos objectifs.
Voilà comment cela devrait fonctionner
- avoir un contrat de services et de travail au lieu de pour un produit
- doit être résiliable dans un délai relativement court
- travailler en étroite collaboration pour assurer une efficacité optimale
- impliquer toutes les parties nécessaires, à la fois de "Scrum-Addits LLC" et "Money-Bags Corporation" - un "point de contact unique" tunnelant toutes les informations ne va pas travailler ici
eh bien j'ai simplement dit "être agile". Maintenant, voici pourquoi:
- le processus et le contrat sont optimisés pour dépenser autant d'argent sur le Objectif que possible
- vous devrez faire confiance à l'entrepreneur pour faire son travail et vous n'aurez pas besoin d'investir beaucoup d'argent pour vérifier qu'il est à la hauteur de l'emploi.
- la capacité de poursuivre votre entrepreneur si vos attentes/contrats ne sont pas satisfaits n'aide généralement pas, car cela coûtera plus cher que de le laisser tomber. Certaines des principales préoccupations ici sont le délai de mise sur le marché. Vous perdrez très probablement beaucoup plus d'argent/d'affaires en allant au tribunal que vous n'en obtiendrez.
- à la fin de la journée, vous n'aurez qu'à supporter certains risques vous-même.