Les délais sont-ils agiles?

Pour plus de clarté, une date limite est:

Une limite de temps ou une date limite est un champ de temps étroit, ou un moment particulier, au cours duquel un objectif ou une tâche doit être accompli.

^{De wikipedia}

Toute ma carrière dans le développement de logiciels que je faisais "Agile", ce qui partout a semblé signifier au moins que les pratiques suivantes étaient respectées:

• Sprints hebdomadaires ou bi-hebdomadaires
• Rétrospectives Planification Sprint
• Un propriétaire de produit
• Scrum
• Histoires d'utilisateurs

Cependant, chaque projet sur lequel j'ai jamais mis l'accent a insisté pour fixer une échéance. Étant donné que Agile tente de se concentrer sur la planification adaptative, la flexibilité et le changement. les délais sont-ils agiles?

Mon avis personnel est que ce n'est pas le cas, car je vois des délais conduisant à un manque de flexibilité et de qualité. Au lieu de cela, je pense qu'il est plus utile de se concentrer sur les sprints et les premières livraisons. Il semble toutefois que dans tous les cercles où je me suis trouvé, ce n’est pas le cas et que les délais sont considérés comme allant de pair avec le développement Agile.

Les délais sont une réalité. La plupart du temps, vous devez avoir quelque chose à une certaine date. C'est inévitable. Sans échéances, même les projets agiles peuvent succomber à la loi de Parkinson :

Les travaux se développent de manière à occuper le temps imparti pour les mener à bien.

En d'autres termes, si votre projet peut durer éternellement, il le fera.

En ce qui concerne les délais, Agile essaie de faire quelques choses:

• Assurez-vous que tout le monde peut toujours voir combien de travail sera effectué dans les délais
• Assurez-vous que les fonctionnalités les plus importantes sont complétées en premier
• Assurez-vous que les fonctionnalités terminées sont utilisables, en ce sens qu'elles ne dépendent pas de fonctionnalités non encore terminées.
• Veiller à ce que le développement se poursuive à un rythme soutenu

De cette façon, lorsque le jour inévitable se présentera, vous ne disposerez pas d'une pile de code inutile, mais d'un produit fonctionnel et testé contenant, espérons-le, uniquement les éléments les moins importants inachevés. Et personne n'est surpris par le produit fini.

Donc oui. "Agile" et "délais" peuvent être parfaitement compatibles.

Les délais sont une réalité de la vie. Il y a des choses qui ont une date très ferme.

Nous avons besoin du logiciel de Comdex

ou

Les jeux doivent être dans les rayons du Black Friday

etc. On ne peut pas différer Comdex ou Black Friday - le reste du monde ne fonctionne pas de cette façon.

L’objectif d’Agile est que les choses qui ne respectent pas les délais échouent plus rapidement (c’est une bonne chose), ou que le périmètre peut être réexaminé plus tôt afin que les ressources puissent être concentrées sur le retour sur investissement correct. manière plus opportune.

La date limite est une date difficile qui est fermement établie. Agile est un outil qui permet de réaliser plus tôt dans le cycle que le développement du logiciel prendra deux fois plus de temps que prévu initialement. Il est important que les responsables de projet soient en mesure de résoudre ces problèmes le plus tôt possible, afin de pouvoir ajouter davantage de ressources, de modifier le périmètre, d'ajuster l'échéance (dans le cas où il s'agit d'une échéance ferme plutôt que solide) ou du projet. annulé.

La transparence recherchée par Agile consiste à montrer les problèmes et les progrès réalisés plus tôt dans le cycle. L'échec de la livraison cascade classique est celui où vous avez passé des mois derrière des portes closes et livrez le produit une semaine avant la date limite et on vous dit que vous vous trompez et que vous avez perdu des mois (et que vous avez maintenant complètement dépassé la date limite) . L'autre cas d'échec classique consiste à découvrir une semaine avant la date limite qu'il vous reste encore des mois. Agile cherche à faire connaître ces problèmes au début du processus.

L’autre partie que Agile cherche à faire dans le contexte d’une échéance est que, même si une partie seulement des fonctionnalités convenues sont complètes (pour quelque raison que ce soit), la version actuelle du logiciel est utile et déployable.

D'accord, nous avons manqué de tout ce que nous souhaitons pour que le logiciel d'impôt soit déployé le 15 avril, mais nous en avons 75% et ce que nous avons fonctionne et fonctionne depuis notre lancement en novembre dernier. Nous savons que nous ne pourrons pas déployer l'ensemble des fonctionnalités complètes depuis la mi-décembre et recentrer nos efforts sur 80% de la clientèle.

Certaines échéances doivent être respectées. Obligations contractuelles, conventions, exigences réglementaires. Certaines sont imposées par les gestionnaires qui souhaitent pouvoir placer le développement logiciel dans le même tableau que la fabrication sur leur feuille de calcul. Quelle que soit la cause, la plupart des gens ne peuvent pas s'en échapper.

Si vous travaillez dans une équipe qui fonctionne bien, la communication entre les développeurs et la direction / les parties prenantes signifie que les personnes devant prendre une décision sont bien informées pour décider s'il est plus important de manquer de délai ou de poursuivre le développement.

Même si vous fournissez des user stories finalisées une fois par semaine ou deux fois par mois, vous aurez probablement toujours des délais. Le cas échéant, assurez-vous que vos parties prenantes savent ce qui, à votre avis, s’intégrera d’ici à la date limite et définit les attentes.

Si vous construisez en permanence le meilleur logiciel possible avec les exigences que vous avez actuellement à chaque étape, une échéance à la fin d'un sprint ne devrait théoriquement pas être un problème. Dans la pratique, ce n’est pas normalement le cas, mais les délais ne sont pas clairs non plus. Les délais les plus importants que j’ai jamais été fixés m’ont été communiqués bien avant, c’était l’attente de la qualité et des fonctionnalités qui étaient en cause.

Les délais arbitraires qui n'ont pas de conséquences s'ils sont manqués ne sont pas très agiles, mais il existe des situations où, pour des raisons extérieures aux délais de contrôle de l'équipe de développement, il est nécessaire de définir et de conserver. Heureusement, si les délais sont raisonnables, il existe de nombreuses façons d’inverser l’équation et de les traiter de manière agile.

Les délais ne sont pas toujours faux. Comme nous l'avons tous appris d'Obi-Wan:

"Seuls les Sith négocient en absolus"

Il est juste de dire que dans la plupart des cas, les délais sont ridicules, inutiles et certainement pas agiles, mais il faudrait un fou pour dire que c'est toujours le cas. Le boîtier architypal est un logiciel nécessaire pour une utilisation urgente, tel qu'un logiciel de suivi des élections. Si le logiciel n'est pas prêt à temps pour l'élection, il ne serait ni raisonnable, ni pratique de reporter l'élection, et il ne semble pas être très orienté client de simplement dire: «Désolé, on dirait que nous avons pris trop de temps. Je sais que le logiciel pour lequel vous nous payez n'a aucune valeur, mais les délais ne sont pas agiles, alors comment pouvez-vous nous en vouloir de ne pas les respecter? '

Ce n’est pas très agile de dire à vos clients de le pousser parce qu’il veut quelque chose qui dépend du temps, et au bout du compte, il va falloir que quelqu'un construise ces choses. Alors, comment pouvons-nous toujours satisfaire les clients et continuer à proposer des solutions apparemment raisonnables à des problèmes sensibles aux délais? Eh bien, si le développement d'un logiciel prend un temps incertain et que la date limite n'est pas variable, il faudra que quelque chose d'autre soit modifié pour gérer cette incertitude ...

Si la date de livraison est maintenue constante, un autre aspect devient une variable.Comme nous le savons tous, les projets de logiciels peuvent être très incertains. Si vous voulez réussir votre projet, vous devez faire quelque chose de variable en réponse à cette incertitude. C'est généralement la date de livraison. Cela semble assez naturel, de toute façon. Mais ce n'est pas votre seule option. Si vous ne vous engagez pas dans une échéance difficile, vous devez gérer les fonctionnalités livrées de manière variable. Donne la priorité à une liste de fonctionnalités et indique clairement qu’il existe une incertitude quant au nombre de fonctionnalités pouvant être fournies à cette date. Collaborez avec le client pour hiérarchiser ces fonctionnalités afin que les plus importantes soient plus susceptibles d’être expédiées. Ensuite, les choses se passent normalement, mais seulement lorsque l’échéance est proche, vous expédiez tout ce qui est prêt à être expédié. Dans ce modèle,

Si quelqu'un veut fixer un délai, c'est très bien et le délai peut être fixé, mais ce qu'ils doivent comprendre, c'est que si le délai est fixé, la portée doit rester flexible.

tl; dr

Dans un monde idéal, nous n’aurions pas d’échéances et nous ne ferions que livrer les choses quand elles sont prêtes. La réalité est que les gens qui paient pour des choses veulent généralement savoir quand ils ont fini. Les méthodologies agiles le reconnaissent, mais reconnaissent également que tout ne peut pas être lié.

Cela garantit que vous pouvez maintenir la qualité de livraison au niveau qui convient au produit. Si vous fixez une échéance et un périmètre (et un budget), les choses se précipitent et vous vous retrouvez dans l'ancien monde des chutes d'eau avec un temps de crise fou à la fin du projet. Augmenter le budget n'est généralement pas la solution, car ajouter davantage de développeurs et de testeurs ne résout pas le problème plus rapidement. C'est un point de vue bien connu (et je suis d'accord avec cela par expérience), que plus vous ajoutez de personnes (chacune avec ses propres faiblesses), plus cela prend du temps.

Maintenant, généralement (à moins qu'ils ne comprennent vraiment les méthodes Agiles), la personne qui paie pour le logiciel n'aime pas être informée. Nous pouvons respecter votre date limite, mais nous ne pouvons pas faire tout ce que vous voulez. Cela peut être géré en donnant la priorité aux fonctionnalités du logiciel. Votre discussion de priorisation pourrait ressembler à:

Équipe de développement (D): "Pouvez-vous donner la priorité aux fonctionnalités que vous souhaitez, avec les plus importantes en premier?"

Client (C): "Tout est la priorité 1 - Je veux que tout soit terminé d’ici la fin du mois prochain."

D : "Cela pourrait être possible, mais cela pourrait ne pas l'être si les exigences changent ou si nous découvrons des problèmes auxquels nous ne nous attendions pas au cours du développement."

C: "Et si je te donnais plus d'argent?"

D: " soupir ... même avec plus de ressources, il leur faudra un mois pour vraiment commencer; donc si vous ne savez pas comment hiérarchiser les fonctionnalités, dites-nous simplement celles que vous voulez faire en premier."

C: "Ok, je veux le gros bouton mais le rendre vraiment gros, et puis ... etc"

Vous pouvez maintenant commencer à utiliser les fonctions par ordre de priorité. Il est utile de regarder également à l’avenir avec votre équipe les éléments situés plus bas dans l’ordre de priorité et de faire des estimations préliminaires, sachant que vous pouvez les modifier lorsque vous arrivez au développement lorsque vous avez plus d’informations. Cela peut être utilisé pour redéfinir ou créer votre feuille de route si vous n'en avez pas encore. Ceci constitue alors la base de votre plan de publication. La feuille de route peut être discutée avec le client en reconnaissant que la portée peut changer, mais que vous avez un ordre de livraison.

Un des grands avantages d’Agile est qu’il reconnaît que les choses changent au fur et à mesure que vous avancez dans le développement et que vous vous ajustez comme elles le font. Contrairement aux approches plus traditionnelles, ce principe, associé aux éléments livrables du sprint régulier et à la communication permanente avec le client, vous oblige naturellement à faire preuve de plus de transparence quant aux progrès, ce qui est une bonne chose.

Parfois, le client n'aime pas qu'ils n'obtiendront pas ce qu'ils veulent avant une certaine date, MAIS ils comprendront pourquoi et ce qu'ils obtiendront sera de bonne qualité. Et 6 mois après la livraison des fonctionnalités, le client ne se soucie pas ou ne se souvient pas que vous avez livré avant une certaine date, il se souvient de la qualité du produit qu'il utilise encore.

Les délais sont traditionnellement basés sur le cycle de vie de l'entreprise. Le logiciel fiscal doit être disponible avant le 15 avril. La déclaration pour le prochain exercice pourrait devoir être faite en juillet.

Le manifeste Agile déclare:

Individus et interactions sur les processus et les outils

Logiciel de travail sur documentation complète

Collaboration client sur négociation de contrat

Répondre au changement au sujet d'un plan

Les délais sont un contrat. Ils sont un plan. Ils ne répondent pas à la vitesse de votre équipe. Ils ne changent pas si vous perdez vos trois meilleurs développeurs.

Les délais ne sont pas Agiles, mais Agile peut nous donner des informations sur les délais. Agile nous permet de savoir si notre vitesse ne nous permet pas de respecter une date limite sans suppression d'une fonctionnalité. Cela nous permet également de savoir si nous devons embaucher pour fixer une échéance. Et dans certains cas, cela nous permet de savoir qu'une échéance est impossible, lorsqu'il ne reste aucune fonctionnalité à supprimer.

La meilleure chose à faire pour une équipe agile est de laisser sa rapidité et son carnet de commandes hiérarchisé respecter les délais. Cela donnera des dates de livraison estimées. Si ceux-ci ne respectent pas le délai, il est temps de discuter sérieusement avec le client et de déterminer si le délai est réalisable.

Je dirais que chaque livraison de sprint n'est pas négociable. Vous évaluez le travail, vous définissez la taille des cartes et vous chargez suffisamment pour que votre équipe soit occupée jusqu'à la fin du sprint (et le sprint doit être petit - d'une semaine à un mois). Les "délais de livraison" devraient être fondés sur la tendance historique des travaux achevés par rapport aux travaux prévus. Agile ajoute / supprime rien de l’ancienne idée de contrainte «coût / temps / champ», elle utilise simplement le champ d’application comme méthode privilégiée de gestion des glissements, étant donné qu’une meilleure hiérarchisation des priorités par rapport au champ est généralement préférable à un investissement en temps ou en argent plus long.

Certaines personnes semblent confondre agile pour "Far west". Agile ne veut rien dire. Agile signifie que nous cessons de nous mentir sur la capacité d'une personne raisonnable à estimer. Fondamentalement, nous pouvons estimer le développement logiciel environ 2 à 4 semaines dans le futur. Au-delà de cela, ce sont tous des degrés variables de butins et de conjectures. Pire encore, le coût de la fourniture d’estimations pour des choses plus en plus éloignées dans l’avenir se rapproche du coût du simple fait de faire le travail. Pour une raison quelconque, les gestionnaires de projet ont toujours refusé d’admettre ces vérités absolues à leurs clients. Agile ajuste simplement cette pensée en affirmant qu'il y a une limite à notre capacité à prédire l'avenir en ingénierie logicielle et opère un changement subtil en "estimation basée sur des preuves" pour la prévision à long terme.sont capables d'estimer, et nous pouvons fournir des estimations assez raisonnables de la livraison future à long terme en fonction de ce que nous avons livré jusqu'à présent.

TL; DR

Les échéances sont-elles [...]? ... [L] es lignes sont considérées comme allant de pair avec le développement de [a] gile.

Beaucoup de réponses ici sont susceptibles de se concentrer sur les aspects techniques de la question. Au lieu de cela, je vais aborder cette question du point de vue de la gestion de projet.

Une échéance implique beaucoup de planification préalable qui ne cadre pas avec les principes agiles. Au lieu de cela, les modèles de développement itératifs reposent sur des calendriers, des cadences et des cycles de publication incluant une planification juste à temps, mais pas la "grande planification initiale" généralement associée aux délais traditionnels de gestion de projet.

Il est encore possible de planifier les mises en production avec des méthodologies agiles, mais les plans reposent généralement sur une estimation du nombre d'itérations nécessaires pour atteindre un objectif plutôt que sur les objectifs de gestion définis par fiat. Cela ne veut pas dire que les dates d'expédition ne peuvent pas être définies, ou que les objectifs ne peuvent pas être atteints, mais la façon dont ils sont définis et atteints est assez différente de celle utilisée dans les méthodologies de gestion de projet traditionnelles.

Pensez aux boîtes de temps, pas aux délais

Cependant, chaque projet sur lequel j'ai jamais mis l'accent a insisté pour fixer une échéance. Étant donné que Agile tente de se concentrer sur la planification adaptative, la flexibilité et le changement. les délais sont-ils agiles?

Ceci est un malentendu commun des principes agiles. Les frameworks agiles tels que Scrum et Kanban ne sont pas axés sur les délais, mais sur la box-time et une cadence de livraison durable.

Dans Scrum, par exemple, le sprint n'est pas une "échéance". C’est une boîte de temps qui contient la quantité de travail que l’équipe estime pouvoir entrer dans la boîte de temps sans le déborder, puis est "terminé" ou "pas terminé" à l’expiration du délai. Une fois parti, le time-box est parti pour toujours; tout travail non effectué doit être re-planifié et réestimé dans une nouvelle boîte de temps, tout aussi éphémère, basée sur les besoins actuels (plutôt qu'historiques) du projet.

L’importance de cette plage horaire est qu’elle crée à la fois une cadence prévisible pour que les parties prenantes examinent les progrès et un rythme soutenu pour l’équipe, dans laquelle elle peut générer des augmentations de valeur potentiellement livrables . Le travail est incrémental et suit la cadence; le concept d'une grande date limite n'est donc pas conforme aux principes agiles.

Planification des libérations en fonction des plages horaires

La planification de la publication est peut-être le domaine dans lequel les utilisateurs rencontrent le plus de difficultés à faire correspondre les processus agiles aux cadres traditionnels. La planification des versions implique souvent des produits livrables à portée fixe ou à date fixe. Dans les cadres agiles, la planification des versions est généralement effectuée à l'aide d'un processus d'estimation dans lequel la portée est explicitement définie comme une variable mutable, tandis que les dates de publication sont estimées par itérations.

Par exemple, un projet peut s’engager à publier la version 1.0 d’un projet à la fin de 20 itérations; l'étendue de ce qui est publié peut changer au cours de la vie du projet (l'étendue, les caractéristiques et les priorités peuvent changer au début de chaque sprint), mais les dates cibles de chaque version sont fixées dans le plan de projet. L'équipe s'efforce de fournir un incrément potentiellement livrable à chaque sprint, et la définition de fait comprend des contrôles de qualité tels qu'une intégration continue pour s'assurer que le projet est dans un état pouvant être libéré à la fin de chaque sprint.

Parfois, vous verrez des projets agiles dont l'étendue est fixe, mais comme cette variable est la variable mutable des projets agiles, la date de publication peut changer au fil du temps, à mesure que l'étendue de chaque itération s'ajuste, change ou s'adapte aux besoins changeants du projet. . Je ne recommande certainement pas l'approche à portée fixe pour les équipes agiles, en particulier les équipes inexpérimentées, mais il y a des moments où c'est la bonne approche.

Voir également

• Comment effectuer une planification de publication agile

Pensez aux délais comme à un engagement. Le fait que le projet soit agile ne signifie pas que vous ne devriez pas vous engager à fournir des fonctionnalités données pour une date donnée.

Ce que l'agilité apporte est ce qui se passe entre les deux. Au lieu d’avoir un document de spécification des exigences logicielles strict qui indique que vous devez fournir la fonctionnalité A composée des sous-fonctionnalités B, C, D et E pour une date donnée, vous vous engagez à fournir la fonctionnalité A pour une date donnée, étant donné que à un stade précoce, ni vous ni votre client ne savent à quoi ressemblera cette fonctionnalité, ou aurait-elle des sous-fonctionnalités B, C, D et E ou peut-être B et C ou une douzaine d’autres sous-fonctionnalités.

Imaginez une entreprise qui livrait auparavant des marchandises à de petites entreprises uniquement et venait de signer un contrat avec une grande entreprise. Cette grande entreprise utilise EDIFACT et il semble que le logiciel de comptabilité actuellement utilisé par votre société ne gère pas EDIFACT. Vous devez créer un plug - in qui fait que, étant donné que le contrat, votre entreprise devrait être prêt pour le 15 Avril ^e .

L'agilité signifierait que les étapes intermédiaires seront exécutées progressivement et seront basées sur un retour d'informations régulier. En gros, vous montrez vos progrès aux comptables, et ils vous diront ce qu’ils en pensent, quels sont les problèmes possibles, etc. substantiellement l'expérience utilisateur. Trois semaines plus tard, il est apparu que non seulement cela ne l’améliorait pas beaucoup, mais qu’il en résulterait également un mois de développement supplémentaire. Merci à Agile, vous pouvez ensuite rediriger vos efforts de cette fonctionnalité vers autre chose, en veillant à livrer à temps.

Vous devez également comprendre le point de vue du client:

• Souvent, les entreprises ont besoin d’une date de livraison précise. Par exemple, vous ne pouvez pas fournir le service de diffusion en ligne des Jeux Olympiques après la fin des Jeux. Sur le plan commercial, il s’agit simplement d’un échec, avec d’énormes conséquences négatives.

• Sans engagement, il est tentant pour un développeur ou un sous-traitant d'être perfectionniste ou de ne pas donner la priorité au projet. Bien que la régularité des sprints aide, cela n’empêche pas totalement ce risque.

  Je n’aime pas trop les délais, surtout que les délais sont très faciles, mais je comprends toujours pourquoi de nombreuses entreprises le font. Il n'est pas toujours facile de voir que le projet est en retard sur le calendrier en ne regardant que les sprints: une échéance manquée, dans ce contexte, peut être un rappel clair que quelque chose échappe à la contrôle et devrait être traité dès maintenant.

Les états d' eXtreme Programming concernant la planification des versions:

Selon la philosophie de base de la planification des versions, un projet peut être quantifié à l'aide de quatre variables: portée, ressources, durée et qualité.

Ce qui semble juste. Il indique également que

Personne ne peut contrôler les 4 variables. Lorsque vous en changez un, vous en causez par inadvertance un autre en réponse. Notez que réduire la qualité à moins d’excellent a un impact imprévu sur les 3 autres variables

Et comme déjà noté par br3w5 , augmenter les ressources est une solution limitée. Vous pouvez probablement ajouter quelques personnes qui faisaient déjà partie de l'équipe si elles étaient envoyées pour autre chose. Mais vous ne pouvez pas simplement augmenter la taille de l'équipe rapidement et indéfiniment, du moins pas sans une réorganisation de l'équipe qui prend beaucoup de temps.

Donc, avec une qualité irréductible et des ressources fixes: une échéance étant une contrainte de temps, cela signifie que vous devez adapter la portée. Et utiliser l'agilité vous donne le moyen de respecter l'échéance avec la portée la plus productive possible. Cependant, vous pouvez généralement vous assurer qu'une partie de l'étendue sera réalisée à temps. C’est la partie sur laquelle vous pouvez estimer avec confiance que le temps s’est écoulé en deçà du délai. En règle générale, quelque chose qui est très proche de ce que vous avez fait à plusieurs reprises et a peu d'inconnu.

Lorsqu'elles sont correctement comprises, les méthodes de développement de logiciels ont pour objectif de nous rendre plus productifs en nous concentrant sur nos pensées et de fournir un langage commun aux situations typiques. Il s'agit d'inspiration et d'habilitation, pas de contrôle mental ni de culpabilité.

Suivre une méthode de développement logiciel littéralement sans aucun compromis correspond à ce qu'on appelle le radicalisme ou le fondamentalisme dans d'autres contextes. La forme pure de cette aberration est rarement vue dans la pratique car elle conduit généralement à une défaillance rapide du marché. Mais bien sûr, lorsque les développeurs se font concurrence pour mettre en œuvre une méthode spécifique, il est naturel que les résultats soient dépassés.

Le problème est exacerbé par le fait que les missionnaires et les évangélistes ciblent principalement ceux qui ont encore besoin de convaincre d'utiliser la méthode. et même s'ils prêchent la modération, la nature humaine fait en sorte qu'elle attire moins l'attention.

Les délais ne sont pas agiles, ils sont:

1) cascade, et 2) faux.

Les logiciels et les délais ne fonctionnent pas bien ensemble et ne l’ont jamais été. À bien des égards, les méthodes Agiles sont une réaction au problème massif des délais manqués ou des logiciels qui ont été abandonnés quand il est devenu évident que le délai ne pouvait pas être respecté (ainsi que les problèmes budgétaires).

Tentative agile d'injecter la réalité dans la situation en disant "Vous connaissez l'échéance ou les fonctionnalités vont glisser et / ou changer, nous le savons, partons du bon pied sans même faire semblant".

La clé est que la date limite devient simplement une date de publication pour la première version du logiciel. Cela pourrait encore être gravé dans le marbre - par exemple, le logiciel est à usage universitaire et DOIT être utilisable d’ici le début du trimestre - mais ce que vous allez livrer ne l’est pas. Vous avez un produit minimum viable que tout le monde est certain de pouvoir livrer d'ici là, et vous avez une charge de "aimerait avoir". Au lieu que tout le monde lève les mains quand il s'avère que la liste complète ne sera pas remise dans les "délais", vous vous assurez que le MVP sortira de la porte et autant de "voudraient avoir" comme possible et ensuite évaluer le rapport coût / bénéfice du reste à ce moment-là.

Quiconque a joué à des jeux informatiques pendant un certain temps sait exactement comment cela fonctionne! Si la première version est conforme aux normes bêta, de nombreux joueurs sont satisfaits, tant les attentes vis-à-vis de ce que "des délais fermes et réels" signifient dans la vie réelle sont faibles.

Les échéances ne sont donc pas agiles. Ce sont des retenues de l'époque où les gens pensaient que les logiciels pouvaient être traités comme du matériel et de l'ingénierie métallurgique. Nous avons appris que cela n’est ni possible ni souhaitable, car il jette le plus grand avantage des logiciels par rapport au matériel: c’est un logiciel.

Agile essaie d'exploiter cette souplesse en permettant aux objectifs de se développer et de se modifier au cours du projet d'une manière impossible à concevoir par un pont.

Répondez "probablement non"

Le paramètre Project_management_triangle indique que les coûts, la durée et l’étendue (ainsi que la qualité) dépendent les uns des autres. ("Choisissez deux et obtenez le 3")

Un sprint Scrum choisit une heure fixe (7 jours = durée du sprint) et un coût (budget de 7 membres de l’équipe) et en estime la portée (le nombre de récits à réaliser dans le sprint).

Si la direction ou le service des ventes essaie de définir les trois facteurs (coût, temps et portée), il n’est pas agile au sens de scrum car l’équipe ne peut pas promettre d’atteindre le but (sans violer quality = definition-of-done)

La direction professionnelle essaie de définir les coûts et les délais et, au besoin, de réduire le champ d’application si une date fixe doit être respectée.

Ne peut-on pas répondre simplement et directement à cette question?

Aucune échéance n'est pas agile.

L’essentiel est de construire ce que vous pouvez de manière itérative, d’apprentissage et d’adaptation au fur et à mesure.

Une échéance correspond à "vous devez livrer x par y", ce qui échoue pour les deux points, dans la mesure où vous promettez un produit livrable fixe dans un délai prédéfini (où Agile indique que nous ne sommes pas sûrs de ce que nous essayons de fournir. apprendre de l'agile nous enseigne que même si nous savons qu'il est très difficile d'avoir une certitude sur les échelles de temps - ou que c'est un problème résolu, nous ne devrions pas le faire de toute façon).

Après avoir établi que la réponse à la question est "Non, les délais ne sont pas agiles" - nous pouvons alors avoir une conversation intéressante qui aborde la question "comment pouvons-nous traiter les délais dans un contexte agile" et il y a beaucoup de bonnes penser à cela dans les autres réponses.

Selon moi, une réponse raisonnable à ce dernier point est que nous allons fournir des augmentations de valeur tôt et souvent et que nous verrons où nous en serons en temps voulu - mais il n’existe pas de solution unique.

Le degré d'agilité requis dans son travail est inversement proportionnel à la place qu'ils occupent dans l'organigramme.

"Agile" c'est bien, pour ce que c'est. "Agile" signifie "esprit ouvert associé à une compétence suffisante". Ce sont les grognements au bas qui doivent être les plus agiles.

Si, au niveau de la direction, le patron aux cheveux pointus était suffisamment agile pour comprendre que repousser une échéance une semaine reviendrait à créer un meilleur produit, ou un code plus propre, plus sans bug et plus exploitable de sorte que la société ( ou la division) économise deux semaines dans l’avenir, c’est une échéance agile.

Mais comme l'intérêt personnel éclairé, il n'existe pas vraiment.