Les délais sont-ils agiles?
Pour plus de clarté, une date limite est:
Un délai ou une échéance est un domaine temporel étroit, ou un moment particulier, par lequel un objectif ou une tâche doit être accompli.
De wikipedia
Toute ma carrière de développeur de logiciels, j'ai fait "Agile" qui partout a semblé signifier au moins que les pratiques suivantes ont été respectées:
- Sprints hebdomadaires ou bihebdomadaires
- Rétrospectives Planification du sprint
- Un propriétaire de produit
- Scrum
- Histoires d'utilisateurs
Cependant, chaque projet sur lequel j'ai jamais travaillé a insisté pour fixer un délai. Étant donné qu'Agile tente de se concentrer sur la planification adaptative, la flexibilité et le changement; les délais sont-ils agiles?
À mon avis, ce n'est pas le cas, car je vois des délais entraînant un manque de flexibilité et un manque de qualité. Au lieu de cela, je pense qu'il offre plus de valeur pour se concentrer sur les sprints et les livraisons anticipées. Il semble cependant que dans tous les cercles où je me trouve, ce ne soit pas le cas et les délais semblent aller 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 délais, même les projets agiles peuvent succomber à loi de Parkinson :
Le travail se dilate de manière à remplir le temps disponible pour sa réalisation.
En d'autres termes, si votre projet peut continuer indéfiniment, il le sera.
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 accompli avant la date limite
- Assurez-vous que les fonctionnalités les plus importantes sont terminées en premier
- Assurez-vous que les fonctionnalités terminées sont utilisables, dans le sens où elles ne dépendent pas de fonctionnalités qui ne sont pas encore terminées
- Veiller à ce que le développement se poursuive à un rythme durable
De cette façon, lorsque le jour inévitable arrive, vous n'avez pas une pile de code inutile, mais un produit fonctionnel et testé avec, espérons-le, seulement les choses les moins importantes inachevées. 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é. Il y a des choses qui ont une date très ferme.
Nous avons besoin du logiciel de Comdex
ou
Les jeux doivent être sur les étagères des magasins d'ici le Black Friday
etc. On ne peut pas reporter le Comdex ou le 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 l'échéance échouent plus rapidement (et c'est une bonne chose), ou que la portée puisse être réexaminée plus tôt afin que les ressources puissent être concentrées sur le bon retour sur investissement dans un de manière plus opportune.
La date limite est une date ferme fixée avec fermeté. Agile est un outil qui permet de réaliser plus tôt dans le cycle que le développement du logiciel va prendre deux fois plus de temps que prévu. Il est important que les chefs de projet soient en mesure de se rendre compte de ces problèmes plus tôt que tard afin que soit plus de ressources puissent être ajoutées, la portée modifiée, la date limite ajustée (dans le cas où il s'agit d'une entreprise plutôt que d'une date limite solide) ou du projet annulé.
La transparence recherchée par Agile est celle de montrer les problèmes et les progrès plus tôt dans le cycle. L'échec classique de la livraison en cascade est celui où vous avez passé des mois à huis clos et livré le produit une semaine avant la date limite et qu'on vous dit que vous faites tout mal et que vous avez perdu des mois (et que vous avez maintenant complètement dépassé la date limite) . L'autre échec classique de la cascade est de découvrir une semaine avant la date limite que vous avez encore des mois. Agile cherche à faire connaître ces problèmes au début du processus.
L'autre partie qu'Agile cherche à faire dans le contexte d'un délai est que même si seulement une partie des fonctionnalités convenues sont complètes (pour une raison quelconque), la version actuelle du logiciel est utile et déployable.
Ok, nous avons manqué d'avoir tout ce que nous voulions pour que le logiciel fiscal soit déployé le 15 avril, mais nous avons 75% et ce que nous faisons fonctionne et fonctionne depuis que nous avons commencé en novembre dernier. Nous savons que nous ne pourrons pas déployer l'ensemble des fonctionnalités depuis la mi-décembre et avons recentré nos efforts sur les 80% de la clientèle.
Certains délais doivent être respectés. Obligations contractuelles, conventions, exigences réglementaires. Certains sont imposés par des managers qui souhaitent pouvoir mettre le développement logiciel dans le même tableau que la fabrication sur leur tableur. Quelle que soit la cause, la plupart des gens ne peuvent pas s'en éloigner.
Si vous travaillez dans une équipe qui fonctionne, la communication entre les développeurs et la direction/parties prenantes signifie que les personnes qui doivent prendre une décision sont bien informées pour décider si le dépassement du délai ou la poursuite du développement est plus important.
Même si vous livrez des user stories complètes une fois par semaine, ou deux fois par mois, vous aurez probablement des délais. Lorsqu'une approche est à venir, assurez-vous que vos parties prenantes savent ce que vous pensez s'adapter à la date limite et définir les attentes.
Si vous construisez constamment le meilleur logiciel possible avec les exigences que vous avez actuellement à chaque étape, un délai à la fin de tout sprint ne devrait théoriquement pas être un problème. Pratiquement, ce n'est normalement pas le cas, mais les délais ne semblent pas non plus apparaître. Les délais les plus importants qui m'ont été donnés m'ont été communiqués bien avant, c'était l'attente de la qualité et des fonctionnalités qui était en cause. Tous les délais auxquels je peux penser et qui sont venus de nulle part sont dus à des mensonges. Soit les ventes ont dit à un client que la fonctionnalité était là ou pourrait être ajoutée sans consultation et parfois sans même en informer l'ingénierie, soit quelqu'un a dit à son patron que cela avait déjà été fait.
Les délais arbitraires qui n'ont aucune conséquence s'ils ne sont pas respectés ne sont pas très agiles, mais il y a des situations où, pour des raisons hors du contrôle de l'équipe de développement, des délais doivent être fixés et respectés. Heureusement, si les délais sont raisonnables, il existe de nombreuses façons d'inverser l'équation et de gérer les délais de manière agile.
Les délais ne sont pas toujours faux. Comme nous l'avons tous appris d'Obi-Wan:
"Seuls les Sith concluent en absolus"
Il est juste de dire que dans la plupart des cas, les délais sont idiots, inutiles et certainement pas Agiles, mais il serait ridicule de dire que c'est toujours le cas. Le boîtier architypal est un logiciel nécessaire pour une utilisation sensible au temps, tel qu'un logiciel de suivi des élections. Si le logiciel n'est pas prêt à temps pour l'élection, il ne serait pas judicieux ni pratique de reporter l'élection, et il ne semble pas très orienté client de dire simplement `` Désolé, on dirait que nous avons pris trop de temps. Je sais que ce logiciel pour lequel vous nous payez n'a aucune valeur, mais les délais ne sont pas agiles, alors comment pouvez-vous vraiment nous en vouloir de ne pas les avoir respectés?
Ce n'est pas très agile de dire à vos clients de le pousser pour vouloir quelque chose qui est sensible au temps, et à la fin de la journée quelqu'un va avoir pour construire ces choses. Alors, comment pouvons-nous toujours rendre les clients heureux et toujours fournir des solutions apparemment raisonnables aux choses qui sont sensibles au temps? Eh bien, si le développement d'un logiciel prend un temps incertain et que le délai n'est pas variable, quelque chose d'autre devra simplement être variable pour gérer cette incertitude ...
Si la date de livraison est maintenue constante, un autre aspect devient une variable. Comme nous le savons tous, il peut y avoir une grande incertitude dans les projets logiciels. Quelque chose doit être rendu variable en réponse à cette incertitude si vous voulez réussir votre projet, et 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 êtes coincé à vous engager dans une échéance stricte, la façon de gérer cela est de rendre vos fonctionnalités livrées variables. Donner la priorité à une liste de fonctionnalités, communiquer clairement qu'il existe une incertitude quant au nombre de fonctionnalités pouvant être livrées à cette date. Travaillez avec le client pour hiérarchiser ces fonctionnalités afin que les plus importantes aient plus de chances d'être expédiées. Ensuite, c'est comme d'habitude, seulement lorsque la date limite arrive, vous expédiez tout ce qui est prêt à être expédié. Dans ce modèle, l'envoi de plus de fonctionnalités est analogue à l'expédition à une date antérieure, et l'expédition de moins de fonctionnalités est l'analogue de l'expédition à une date ultérieure.
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 de délais et ne livrerions les choses que lorsqu'elles seraient 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 reconnaissent cela, 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 une portée (et un budget), les choses se précipitent et vous vous retrouvez dans le vieux monde de la cascade avec un moment de crise fou à la fin du projet. Augmenter le budget n'est généralement pas la solution, car l'ajout de développeurs et de testeurs ne résout pas un problème plus rapidement. C'est une vue bien connue (et je suis d'accord avec l'expérience), que plus vous ajoutez de personnes (chacune avec ses propres faiblesses), plus cela prend de 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 qu'on le lui dise, nous pouvons respecter votre échéance mais nous ne pouvons pas faire tout ce que vous voulez. Cela peut être géré en priorisant les fonctionnalités qui composent le logiciel. Votre discussion sur la priorisation pourrait se dérouler comme suit:
Équipe de développement (D): "S'il vous plaît, pouvez-vous hiérarchiser les fonctionnalités que vous souhaitez proposer, la plus importante en premier?"
Client (C): "Tout est prioritaire 1 - je veux que tout soit fait avant la fin du mois prochain."
[~ # ~] d [~ # ~] : "Cela peut être possible, mais cela peut ne pas être possible si les exigences changent ou si nous découvrons des problèmes que nous ne m'attendais pas à travers le 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 démarrer; donc, si vous ne savez pas comment hiérarchiser les fonctionnalités, dites-nous simplement lesquelles vous souhaitez effectuer en premier. "
C: "Ok je veux le gros bouton mais le rendre vraiment gros, et puis ... etc"
Vous pouvez maintenant commencer à travailler sur les fonctionnalités dans l'ordre de priorité. Il est également utile de regarder à l'avance avec votre équipe les éléments inférieurs dans l'ordre de priorité et de faire des estimations précoces, sachant que vous pouvez les modifier lorsque vous arriverez au développement lorsque vous aurez plus d'informations. Cela peut être utilisé pour redéfinir ou créer votre feuille de route si vous n'en avez pas encore. Cela constitue alors la base de votre plan de mise à jour. La feuille de route peut être discutée avec le client en reconnaissant que la portée peut changer mais vous avez un ordre de choses à livrer.
L'un des grands avantages d'Agile est qu'il reconnaît que les choses changent au fur et à mesure du développement et que vous vous ajustez comme elles le font. Contrairement aux approches plus traditionnelles, ce principe, en conjonction avec les livrables de sprint réguliers et la communication continue avec le client, signifie que vous êtes naturellement obligé d'être plus transparent sur les progrès, ce qui est une bonne chose.
Parfois, le client n'aime pas qu'il n'obtienne pas ce qu'il veut à une certaine date MAIS il comprendra pourquoi et ce qu'il obtiendra sera de bonne qualité. Et 6 mois après la livraison des fonctionnalités, le client ne se souciera pas ou ne se souviendra pas que vous avez livré à une certaine date, il se souviendra de la qualité du produit qu'il utilise toujours.
Les délais sont traditionnellement basés sur le cycle de vie de l'entreprise. Le logiciel d'impôt doit être disponible au plus tard le 15 avril. Le rapport pour le prochain exercice pourrait devoir être fait d'ici juillet.
Le manifeste Agile déclare:
Individus et interactions sur les processus et les outils
Logiciel de travail sur une 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. C'est 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 Agile, mais Agile peut nous donner des commentaires sur les délais. Agile, laissez-nous savoir si notre vitesse ne nous permettra pas de fixer un délai sans qu'une fonctionnalité ne soit coupée. Il nous permet également de savoir si nous devons embaucher pour respecter un délai. Et dans certains cas, il nous fait savoir qu'un délai est impossible, lorsqu'il n'y a plus de fonctionnalités à couper.
La meilleure chose qu'une équipe Agile puisse faire, c'est de laisser sa vitesse et prioriser le backlog conduire 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 même réalisable.
Je dirais que la livraison à chaque sprint n'est pas négociable. Vous évaluez le travail, vous y mettez des tailles de cartes et vous chargez suffisamment pour garder votre équipe occupée jusqu'à la fin du sprint (et le sprint devrait être petit - de une semaine à un mois). Les "délais de livraison" doivent être basés sur la tendance historique des travaux achevés par rapport aux travaux prévus. Agile n'ajoute/ne supprime rien de l'ancienne idée de contrainte "coût/temps/portée", il utilise simplement la portée comme méthode préférée de gestion du glissement sur la base qu'une meilleure priorisation par rapport à la portée est généralement préférable à dépenser plus d'argent ou de temps.
Certaines personnes semblent confondre agile et "Far West". Agile ne veut rien dire. Agile signifie que nous cessons de nous mentir sur la façon dont une personne raisonnable peut estimer. Fondamentalement, nous pouvons estimer le développement de logiciels dans environ 2 à 4 semaines dans le futur. Au-delà de cela, ce sont tous des degrés variables de suppositions et de suppositions. Pire encore, le coût de fournir des estimations pour les choses de plus en plus loin dans l'avenir se rapproche du coût de simplement faire le travail. Pour une raison quelconque, les chefs de projet ont toujours été réticents à admettre ces vérités absolues aux clients. Agile ajuste simplement cette pensée en affirmant qu'il existe une limite à la façon dont nous pouvons prédire l'avenir en génie logiciel, et opère un subtil passage à "l'estimation basée sur des preuves" pour les prévisions à long terme. En donnant une livraison certaine et morte en petits morceaux, et une livraison basée sur des preuves pour des choses à long terme, nous obtenons quelque chose de proche du meilleur des deux mondes - nous arrivons à être véridiques sur ce que nous réellement sommes capables d'estimer , et nous pouvons fournir des estimations assez raisonnables de la livraison future à long terme en fonction de ce que nous avons fourni jusqu'à présent.
TL; DR
Les délais [a] gile? ... [D] es délais sont considérés comme allant de pair avec le développement [a] gile.
De nombreuses réponses ici sont susceptibles de se concentrer sur les aspects techniques de la question. Au lieu de cela, je vais aborder cela du point de vue de la gestion de projet.
Un délai implique une grande planification initiale qui n'est pas conforme aux principes agiles. Au lieu de cela, les modèles de développement itératifs reposent sur des délais, des cadences et des cycles de publication qui incluent une planification juste à temps, mais pas le "gros, haut" -planification initiale "qui est généralement associée aux délais de gestion de projet traditionnels.
Il est toujours possible de faire la planification des versions avec des méthodologies agiles, mais les plans sont généralement basés sur une estimation du nombre d'itérations nécessaires pour atteindre un objectif plutôt que sur les objectifs de gestion fixés 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 manière qu'ils sont définis et atteint est très différent de celui des méthodologies traditionnelles de gestion de projet.
Pensez aux délais, pas aux délais
Cependant, chaque projet sur lequel j'ai jamais travaillé a insisté pour fixer un délai. Étant donné qu'Agile tente de se concentrer sur la planification adaptative, la flexibilité et le changement; les délais sont-ils agiles?
Il s'agit d'un malentendu commun des principes agiles. Les cadres agiles tels que Scrum et Kanban ne sont pas axés sur les délais, mais plutôt sur le time-boxing et une cadence de livraison durable.
Dans Scrum, par exemple, le Sprint n'est pas un "délai". Il s'agit d'une plage de temps qui est remplie avec la quantité de travail que l'équipe estime tenir dans la plage de temps sans la déborder, puis elle est "terminée" ou "non terminée" lorsque la plage de temps expire. Une fois parti, la boîte de temps est partie pour toujours; tout travail qui n'est pas effectué doit être planifié et réestimé dans un nouveau délai également éphémère basé sur les besoins actuels (plutôt qu'historiques) du projet.
L'importance de la boîte de temps est qu'elle crée à la fois une cadence prévisible pour les parties prenantes pour évaluer les progrès, et un rythme durable pour l'équipe pour fournir des incréments de valeur potentiellement expédiables . Le travail est progressif et suit la cadence; le concept d'un délai important et anticipé n'est donc pas conforme aux principes agiles.
Planification des versions en fonction des délais
La planification des versions est peut-être le domaine où les gens ont le plus de difficulté à faire correspondre les processus agiles aux cadres traditionnels. La planification des versions implique souvent des livrables à portée fixe ou à date fixe. Dans les cadres agiles, la planification des versions se fait généralement par le biais d'un processus d'estimation où la portée est explicitement définie comme une variable mutable, tandis que les dates de publication sont estimées en itérations.
Par exemple, un projet peut être engagé à publier la version 1.0 d'un projet à la fin de 20 itérations; la portée de ce qui est publié peut changer au cours de la vie du projet (car la portée, les fonctionnalités et les priorités peuvent changer au début de chaque Sprint), mais les dates cibles pour 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 Terminé comprend des contrôles de qualité tels qu'une intégration continue pour s'assurer que le projet est dans un état libérable à la fin de chaque Sprint.
Parfois, vous verrez des projets agiles dont la portée est fixe, mais comme la portée est la variable modifiable dans les projets agiles, la date de publication peut changer au fil du temps à mesure que la portée 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 aux équipes agiles, en particulier les équipes inexpérimentées, mais il y a des moments où c'est la bonne approche.
Voir également
Considérez les délais comme un engagement. Le fait que le projet soit agile ne signifie pas que vous ne devez pas vous engager à fournir des fonctionnalités données pour une date donnée.
Ce que l'agilité apporte, c'est ce qui se passe entre les deux. Au lieu d'avoir un document de spécification stricte des exigences logicielles qui définit 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 à livrer la fonctionnalité A pour une date donnée, étant donné qu'au à un stade précoce, ni vous ni votre client ne savez à quoi ressemblera la 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 seulement et qui vient de signer un contrat avec une grande entreprise. Cette grande société utilise EDIFACT, et il semble que le logiciel comptable actuel utilisé par votre entreprise ne gère pas EDIFACT. Vous êtes invité à créer un plugin qui le fait, étant donné que contractuellement, votre entreprise devrait être prête pour le 15 avrile.
L'agilité signifierait que les étapes intermédiaires seront réalisées progressivement et reposeront sur des retours réguliers. Fondamentalement, vous montrerez vos progrès aux comptables, et ils vous diront ce qu'ils en pensent, quels sont les problèmes possibles, etc. Cela signifie également que peut-être à l'origine, les comptables avaient une excellente idée qui, selon eux, pourrait améliorer sensiblement l'expérience utilisateur. Trois semaines plus tard, il est apparu que non seulement cela ne l'améliorait pas beaucoup, mais cela entraînerait également un mois de développement supplémentaire. Grâce à Agile, vous pouvez ensuite rediriger vos efforts de cette fonctionnalité vers autre chose, en vous assurant de livrer à temps.
Vous devez également comprendre le point de vue du client:
Souvent, les entreprises ont besoin d'une date de livraison spécifique. Par exemple, vous ne pouvez pas fournir le service de streaming en ligne des Jeux Olympiques après la fin des Jeux Olympiques. 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 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 les délais pour cela, d'autant plus que les échéances se produisent très facilement, 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: un délai non respecté, dans ce contexte, peut être un rappel clair que quelque chose devient incontrôlable et doit être traité dès maintenant.
Programmation eXtreme indique la planification des versions:
La philosophie de base de la planification des versions est qu'un projet peut être quantifié par quatre variables: portée, ressources, temps 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 amenez par inadvertance un autre en réponse. Notez que la baisse de la qualité à un niveau moins qu'excellent a un impact imprévu sur les 3 autres variables
Et comme déjà noté par br3w5 , l'augmentation des ressources est une solution limitée. Vous pouvez probablement ajouter quelques personnes qui faisaient déjà partie de l'équipe si elles ont été envoyées sur 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.
Ainsi, avec une qualité irréductible et des ressources fixes: un délai étant une contrainte de temps, cela signifie que vous devez adapter le périmètre. Et l'utilisation de 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 garantir qu'une partie de la portée sera effectuée à temps. C'est la partie que vous pouvez en toute confiance estimer son temps pour être limité en dessous de la date limite. Généralement, quelque chose qui est vraiment proche de ce que vous avez fait plusieurs fois et qui est peu connu.
Le but des méthodes de développement logiciel, lorsqu'elles sont bien comprises, est de nous rendre plus productifs en concentrant nos pensées et de fournir un langage commun pour les situations typiques. Il s'agit d'inspiration et d'activation, pas de contrôle mental et de culpabilité.
Suivre une méthode de développement logiciel littéralement sans compromis correspond à ce que l'on appelle le radicalisme ou le fondamentalisme dans d'autres contextes. La forme pure de cette aberration est rarement observée dans la pratique car elle conduit généralement à une défaillance rapide du marché. Mais bien sûr, lorsque les développeurs sont en concurrence dans la tâche difficile d'implémenter une méthode spécifique, le dépassement de la marque est un phénomène naturel.
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 veille à ce qu'elle reçoive moins d'attention.