Le développement logiciel Agile peut-il être utilisé dans des projets définis par un contrat?

14

J'ai récemment eu une conversation avec un collègue développeur au sujet du développement logiciel Agile. Bien que je comprenne le principe, il semble que les exigences en constante évolution créent le potentiel pour que le projet se poursuive pour toujours. Mais, au moins là où je travaille, les projets doivent être achevés car c'est un contrat.

Autrement dit, la première itération peut prendre des mois, car pour certains projets, le client ne peut pas utiliser une application incomplète. Pour certains projets, je pense que vous devez d'abord définir terminé, puis vous pouvez le diviser en itérations et affiner votre définition après chaque itération. Mais vous devez toujours avoir cette définition.

Si le développement de logiciels Agile comprend des exigences changeantes, comment savoir où cela se termine? Comment pouvez-vous budgétiser un projet alors que le résultat final est en constante évolution?

Le développement logiciel Agile est-il plus un processus agile qu'un produit agile?

agile

— Verax
source

il se termine lorsque vous devez réellement livrer quelque chose qui fonctionne, plutôt que de bricoler. À ce stade, vous devez commencer à imposer une structure, une planification, à fixer des exigences et des délais, et à commencer à travailler plutôt qu'à vous amuser.

— jwenting

Chaque itération agile se traduit par un produit fonctionnel et livrable que le client peut utiliser et en apprendre davantage. Cela continue jusqu'à ce qu'ils soient satisfaits, ce qui arrive souvent plus tôt que prévu. Cela garantit que le produit fonctionne toujours et prend en compte le fait que le logiciel n'est jamais terminé mais évolue pour toujours ou meurt. Choisissez simplement un moment où vous pensez que le produit est assez bon et arrêtez-vous là (pour l'instant).

— Martin Wickman

@Martin Wickman: Je comprends cela, mais "un produit livrable que le client peut utiliser" est le problème ici. Si tel est le cas, la première itération peut prendre des mois, car pour certains projets le client ne peut pas utiliser une application incomplète. Pour certains projets, je pense que vous devez d'abord définir terminé, puis vous pouvez le diviser en itérations et affiner votre définition après chaque itération. Mais vous DEVEZ TOUJOURS avoir cette définition.

— Verax

@Verax: Le manifeste agile a été créé pour gérer les modifications. Si votre projet n'a pas de modifications, l'agilité n'est pas pour vous. Fin de l'histoire.

— Martin Wickman

2

@Verax: vous devez clarifier votre question et y ajouter plus de contexte. Vos commentaires montrent qu'il y a plus à la question. Cela ressort également du décompte des voix sur la réponse et du fait que la réponse acceptée n'est pas liée au texte de la question (et dit même "d'après les commentaires des PO ...").

— Martin Wickman

7

D'après les commentaires du PO, il semble qu'il comme moi travaille pour une boutique de conseil, où nous fournissons des services de développement à nos clients ... Je pense parce que sur cet état d'esprit qui cause sa confusion ... Je vais donc énoncer un fait bien connu mais jamais déclaré.

Agile est incompatible avec le développement de logiciels défini par un contrat.

Les contrats doivent être durs, vous payez X nous faisons Y. Vous voulez X + M vous nous payez Y + (M * N)
Les contrats DOIVENT être satisfaisables, (IE non ouverts) sinon ils ne sont pas des contacts légaux. (Lorsqu'un contact est impliqué, vous devez suivre un processus de contrôle des modifications strict.)

De nombreux magasins de conseils affirment Agile, ils mentent. Ils disent juste cela parce qu'Agile a atteint le statut de mot Buzz.

Agile fonctionne mieux pour le développement interne où les programmeurs sont à plein temps, et il est peu question de budgets. Cadres et fonctionnalités Just Time.

— Crétins
source

À mesure que j'en apprends davantage à ce sujet, j'arrive à la même conclusion. Votre dernière phrase semble être tout à fait correcte. Je travaillais pour le gouvernement et mon client était l'agence pour laquelle je travaillais, et les programmes devaient être maintenus pendant des années et des années tant que des employés les utilisaient. Je peux voir l'agilité y travailler. Maintenant, je développe des systèmes embarqués. Le projet se termine lorsque la machine fonctionne (tout ou rien). Si la machine fonctionne partiellement, elle ne peut pas être vendue - le projet a échoué.

— Verax

2

En fait, un atelier de consultation où je travaillais il y a quelques années avait en fait un document écrit par un adhérent agile décrivant comment l'agile pouvait être intégré dans un modèle de service à prix fixe.

— mcottle

2

Je dois être en désaccord avec cette réponse. La raison en est que si vous avez un contrat qui n'est pas à durée indéterminée, cela signifie que vous ne voulez pas gérer le fluage de portée (ce qui se produit presque toujours). Les contrats que j'ai l'habitude de voir commencent par: Vous payez X, nous faisons Y. Ils ont ensuite une clause qui stipule que tout changement de portée a un prix supplémentaire. Tant que vous êtes très tôt sur la notification du fluage de la portée (ce qui nécessite des ressources et du temps supplémentaires), les premiers clients peuvent réagir aux changements (obtenir les approbations et le budget de la haute direction, etc.). Ensuite, le processus de gestion lui-même devient agile.

— Spoike

Ce n'est pas incompatible si le contrat concerne le service (écriture du code) et non le produit (logiciel fini). Agile permet d'estimer ce qui sera fait sous quel budget, si une exigence change, le budget doit aussi changer. Vous voulez une autre fonctionnalité? Vous devez contracter encore 500 heures-homme. Le fluage des fonctionnalités est également un fluage des prix, entièrement satisfaisant pour les développeurs, et si le client est prêt à payer, qui sommes-nous pour remettre cela en question?

— SF.

2

Il y a des contrats agiles , donc évidemment cette réponse est fausse par définition.

— Martin Wickman

20

Si vous vous concentrez d'abord sur (ce que vous croyez) les choses les plus importantes, le projet se terminera lorsque:

Vous avez dépensé l'argent que vous aviez prévu.
Vous avez dépassé le temps que vous aviez prévu.
Vous ne souhaitez plus ajouter ou modifier quoi que ce soit.
Le prochain lot de vos changements de priorité la plus élevée ne vaut pas ce qu'ils coûteront.

— Dale Emery
source

5

1. Plus d'argent - Le client a dépensé tout son argent pour un produit inutile incomplet. 2. Plus de temps - Le client a toujours un produit inutile incomplet. 3. Rien à ajouter - Ouais c'est ça! 4. Ça n'en vaut pas la peine - Le client vient d'abandonner le projet. --- Qu'est-ce que je rate? Cela n'a aucun sens pour moi.

— Verax

7

Pour 1 et 2: Si vous faites d'abord les trucs les plus importants, puis quand vous manquez d'argent, vous aurez les trucs les plus importants que vous pouvez obtenir pour l'argent. Similaire pour le temps. J'avoue que 3 est rare. Pour 4: l'arrêt ne signifie pas nécessairement que le client vient d'abandonner. Cela pourrait signifier qu'ils ont les choses les plus importantes qu'ils voulaient de cela, et qu'ils préfèrent maintenant faire autre chose avec leur argent. Comment décidez-vous quand mettre fin à d'autres projets? Quels que soient les critères que vous utilisez maintenant, ils sont toujours disponibles sur les projets agiles.

— Dale Emery

1

Dale, merci pour tes pensées. Je pense que cela ne fonctionne que si le client paie chaque itération individuellement et valorise chaque itération comme un produit lui-même. Je ne vois pas comment cela pourrait bien fonctionner pour les produits à coût fixe ou les produits qui nécessitent tout ou rien.

— Verax

5

@Verax: Il n'existe pas de produit qui nécessite "tout ou rien". Il y a toujours des fonctionnalités qui sont simplement "agréables à avoir" et des bugs qui sont cosmétiques plutôt que fonctionnels. Un projet à coût fixe est un succès s'il ne reste plus que l'argent épuisé. Les méthodes agiles essaient de maximiser la probabilité de cela.

— Michael Borgwardt

1

Bien sûr, la modification des exigences a un coût. Si vous créez quelque chose en une seule itération, puis modifiez les exigences pour ce genre de choses dans la suivante, cela a un coût. Agile réduit le coût. Cela ne l'élimine pas. Si vous avez un budget, gardez-le à l'esprit lorsque vous décidez d'ajouter une nouvelle fonctionnalité ou d'en modifier une existante, sachant que vous échangez toujours l'une contre l'autre. Vous apprenez à hiérarchiser et à redéfinir les priorités, et vous apprenez les conséquences.

— Dale Emery

14

Vous vous arrêtez lorsque l'entreprise décide qu'elle ne souhaite plus effectuer d'itérations. Vous espérez que ce soit après qu'une quantité importante de valeur a été livrée, mais avant d'aller trop loin dans le domaine des rendements décroissants.

Elle doit toujours être motivée par «l'entreprise», quoi que cela signifie dans votre situation. Il peut s'agir de la haute direction d'une boutique de développement de logiciels ou des sponsors commerciaux réels dans un environnement de développement interne. Ils décideront quand le coût de la prochaine itération l'emportera sur l'avantage des fonctionnalités qui seront livrables lors de la prochaine itération.

— mcottle
source

5

Jamais, et c'est ça la beauté.

Le projet n'est jamais terminé . Vous avez atteint une autre version, un autre jalon, mais tant que l'argent coule, il y a toujours une fonctionnalité de plus à ajouter, une pièce de plus à améliorer, un bug de plus à corriger. Le projet mourra lorsqu'il ne sera plus nécessaire, mais il ne sera jamais terminé. Contrairement au modèle Waterfall avec exigence-> projet-> produit-> fin, c'est une boucle qui peut tourner pour toujours - tant que vous êtes payé.

Pas une caractéristique commerciale fréquemment mentionnée de cette technologie, n'est-ce pas?

— SF.
source

2

Les projets en cascade ne sont jamais complètement terminés non plus, mais sont plus susceptibles d'être livrés à prendre ou à laisser avec des fonctionnalités importantes manquantes, ce qui rend nécessaire un nouveau projet coûteux.

— Michael Borgwardt

4

Il y a une idée fausse ici: Agile n'encourage pas les exigences du projet à changer. Il permet plutôt le changement sans gaspiller le travail ou sacrifier des domaines de développement importants.

Il y a quatre contraintes fondamentales à tout projet d'ingénierie; portée, coût, temps et qualité. Waterfall suppose que ceux-ci seront statiques. C'est une hypothèse incorrecte; un ou plusieurs de ces changements TOUJOURS. Le fluage de la portée, les budgets réduits et d'autres «inconnues inconnues» interfèrent TOUJOURS avec un projet, changeant les contraintes. Waterfall ne prévoit pas cela, donc quand cela se produit, le projet change de manière indésirable; les fonctionnalités importantes qui n'ont pas encore été ajoutées disparaissent, ou sont rapidement mises en œuvre, ou la version doit être repoussée, ou coûter des ballons car le PM injecte de l'argent aux nouveaux développeurs pour les aider à bien faire les choses.

Agile, en revanche, permet aux contraintes de changer, et l'attend réellement. Il le fait en effectuant des travaux en petits morceaux utilisables, selon les priorités du propriétaire, et donc les morceaux sont idéalement immédiatement utiles au propriétaire du projet. Réduit ainsi l'exposition à l'inconnu en ne faisant pas de grands projets dans un délai où les inconnues sont grandes. Si la chronologie change, des équipes peuvent être ajoutées, ou des fonctionnalités moins importantes "supprimées", et le système que l'équipe a déjà construit n'est pas affecté.

Il permet également de meilleures estimations du temps et des coûts nécessaires pour produire la portée donnée avec la qualité requise. Les gens sont notoirement mauvais pour estimer les gros travaux; il faut BEAUCOUP d'expérience, et beaucoup PLUS de calculs initiaux, pour le faire correctement. En revanche, les gens sont généralement de bons juges de ce qu'ils peuvent faire en une journée, ou une semaine ou deux. Cela produit rapidement un état stable où vous pouvez extrapoler le temps et le coût du travail restant à faire en fonction de votre rythme historique, avec une bonne quantité de précision.

Quant à la définition des points de terminaison, vous avez raison; un projet Agile PEUT durer éternellement. Cependant, il en va de même pour le SLDC traditionnel; le client revient souvent avec plus d'argent et une liste de mises à niveau. La différence est qu'il n'y a pas de ligne claire entre «analyse», «conception», «développement» et «maintenance» lorsque l'on considère le projet dans son ensemble; tout se passe brique par brique, sprint par sprint. Si, à un moment donné, le propriétaire veut appeler le projet "terminé", il le peut et il aura la somme totale des "briques" qu'il a payées dans un "mur" solide; il peut ne pas être aussi élevé ou s'étendre autant que prévu initialement, mais il est fermement en place, fait le travail et peut être ajouté à une date ultérieure avec un minimum de démolition.

— KeithS
source

Désolé, mais "cela permet à la place de changer sans gaspiller le travail", est une erreur fallacieuse qui est utilisée pour convaincre la direction de sa grandeur. La refactorisation et / ou la refonte du système pour tenir compte des changements inattendus ne constituent-elles pas du gaspillage? Dans le camp des cascades, c'est le cas, apparemment pas dans le camp agile. De plus, si le client ne voulait qu'un travail qui prend 2 semaines pour terminer, peu importe la méthodologie utilisée, les gens peuvent donner de bonnes estimations. Ce que le client veut vraiment, c'est combien de temps avant d'avoir le produit complet, où l'agilité n'est pas meilleure que les autres méthodes d'estimation.

— Dunk

1

De plus, vous donnez l'impression que le propriétaire peut dire que c'est fait à tout moment et ce que vous avez terminé, c'est ce qu'il obtient. IME, généralement le client veut savoir que ses X dollars vont fournir un certain ensemble de fonctionnalités avant de plonger dans l'argent. Je ne vois pas comme un avantage que le client ait dépensé un tas d'argent et n'ait obtenu que la moitié des fonctionnalités attendues. Je considère que c'est un échec de la part des entreprises en développement, même si elles ont peut-être livré quelque chose qu'elles appellent fonctionnel ...

— Dunk

2

Que se passe-t-il si un client a conclu un contrat pour une maison mais que l'argent s'est épuisé avant la pose du toit? Le camp agile qualifierait toujours cela de succès. Personne d'autre ne le ferait; en particulier le client.

— Dunk

1

Quant à l'estimation, l'équipe estime ce qu'elle peut faire dans un sprint, et cela est extrapolé pour créer une chronologie pour l'ensemble du projet. Encore une fois, cela aide à protéger à la fois les développeurs et le client. Vous pouvez mettre tout ce que vous voulez dans un contrat, y compris un montant et une date «à ne pas dépasser». C'est négociable. Agile aide toujours, en montrant très rapidement si les contraintes sont réalisables. Deux semaines plus tard, si cela ne semble pas être fait à temps pour l'argent, des équipes peuvent être ajoutées, des fonctionnalités réduites ou le calendrier étendu.

— KeithS

1

Et s'il avait fait la même chose dans une cascade SLDC? Soit le développement s'arrêtait et le client pouvait obtenir une base de code avec de graves trous de fonctionnalité, soit en anticipant une pénurie d'argent / temps, le calendrier restant serait entassé dans le temps restant. Cela sacrifie TOUJOURS la qualité, et à la fin d'un tel projet, l'équipe de développement est frite. De plus, de nombreux dépassements de coûts se produisent parce qu'une cascade traditionnelle ne produit pas de produit tant que le développement n'est pas terminé; cela limite la capacité du client à dire "ce n'est pas ce que je voulais".

— KeithS

1

Il se termine une fois que toutes les fonctionnalités sont implémentées et que tous les bugs sont corrigés.

Si le délai est fixé et les exigences sont également fixées. Alors ce ne sera pas un problème. Mais si la date limite est fixée, mais que les exigences changent, alors vous devez faire quelque chose pour mener à bien le projet.

Prix fixe partie 1, qu'est-ce qui est si mauvais?

Prix fixe partie 2, Fixez-le avec agile!

— CharithJ
source

Il est difficile de savoir quand tous les bugs sont corrigés.

— Martin Wickman

Peut-être "quand tous les bogues connus qui méritent d'être corrigés sont corrigés"?

— Dan Ray

@CharithJ, vos liens sont rompus. Sont-ils encore disponibles quelque part? Merci.

— TwainJ

1

La grande hypothèse derrière le développement agile est que les exigences changent toujours, quelle que soit la méthodologie que vous utilisez. Maintenant, bien sûr, vous pouvez créer un document d'exigences, construire un plan pour l'exécuter et livrer à la fin, et il peut sembler que vos exigences n'ont pas changé. Ils n'ont peut-être pas changé dans votre plan, mais avec les changements du marché et votre meilleure compréhension du produit par vous et vos clients, les exigences en termes de ce que le client veut vont changer. Agile entre en jeu et suggère un processus qui ne cache pas ces changements à travers un calendrier fixe, mais construit à la place une réponse aux changements inévitables dans le processus.

Lorsque vous avez terminé, vous passez de la fin d'un calendrier fixe à la date à laquelle votre produit se trouve à un endroit où vous pouvez fournir suffisamment de valeur commerciale où votre client peut expédier et commercialiser le logiciel dans son état actuel. Le fait d'être fait dépend beaucoup plus de la valeur que vous offrez plutôt que de la façon dont vous avez respecté un calendrier.

— Brian Geihsler
source

1

Les partisans agiles font l'hypothèse très fausse que dans le monde de la cascade, les développeurs disparaissent après la signature d'un contrat et ne sont plus entendus jusqu'à ce qu'un produit sorte de la porte. La façon dont cela fonctionne dans la vie réelle est qu'il existe un bon nombre de points de contrôle et de nombreux avis avec lesquels le client peut s'impliquer autant qu'il le souhaite. S'ils n'aiment pas la direction ou les décisions, ils peuvent demander des changements. Au moment où un produit est livré, il devrait être ce que le client voulait dans la mesure où il a choisi d'être impliqué. Agile n'améliore pas cela pour de nombreux projets.

— Dunk