Les méthodes agiles

Cet article fait suite à ceux consacrés au cycle en V et au cycle itératif. Dans l’histoire des méthodes de gestion de projets informatiques, les méthodes agiles sont une évolution relativement récente qui tente de résoudre certains défauts des pratiques qui étaient en usage jusque-là.

Le manifeste agile

La définition de toutes les méthodes agiles est synthétisée par le Manifeste agile, qui a été rédigé en 2001 par plusieurs acteurs de ce domaine. Il distingue 4 valeurs fondamentales et 12 principes.

Les 4 valeurs

(traduction © Wikipedia et al)

  • L’interaction avec les personnes plutôt que les processus et les outils.
  • Un produit opérationnel plutôt qu’une documentation pléthorique.
  • La collaboration avec le client plutôt que la négociation de contrat.
  • La réactivité face au changement plutôt que le suivi d’un plan.
Les 12 principes

(traduction © Wikipedia et al)

  • Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  • Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  • Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
  • Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  • La méthode la plus efficace de transmettre l’information est une conversation en face à face.
  • Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  • Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Application concrète

Il existe plusieurs méthodes qui suivent l’esprit du manifeste. Elles ont chacune leurs spécificités, mais de manière globale elles œuvrent toutes dans les mêmes voies.

  • Le client, qu’il soit interne ou externe, est intégré au plus près du projet. Il est informé des avancements et des problèmes rencontrés. Le but est de produire un logiciel qui satisfasse le client, et non qui respecte à la lettre la spécification fonctionnelle rédigée plusieurs semaines ou mois auparavant. Il faut donc valider fréquemment que la direction prise soit celle qui mène à sa satisfaction effective.
  • Les équipes sont réduites, avec peu de distinction hiérarchique, et les collaborateurs peuvent se faire confiance les uns les autres. L’analogie employée est celle d’une escouade de guérilla, plus rapide et efficace qu’un énorme bataillon d’infanterie. En diminuant le nombre d’intervenants, on optimise les communications.
  • Les livraisons de logiciel sont rapides. Chaque version est ainsi plus « légère » : elle est plus rapide à installer et à tester. Il est plus facile de changer d’orientation sur un projet quand chaque évolution « coûte » peu, et évite d’avoir à modifier des fonctionnalités qui ont déjà été développées.

Comme pour toute méthode de gestion de projet, le but des méthodes agiles est de réussir à sortir de meilleurs logiciels (du point de vue du client) pour un coût moindre (principalement grâce à une réalisation rapide). Pour expliquer leur fonctionnement, je dis souvent qu’il s’agit de la mise en place d’un cycle itératif sous stéroïdes. Les développements restent itératifs, mais en tentant de raccourcir au maximum la durée du cycle.

Risques et écueils

Un des principaux écueils qui peuvent être rencontrés quand on décide de mettre en place ce type de méthode dans un groupe de projet, c’est que la frontière est parfois ténue entre l’application de la méthode et le « n’importe quoi » qui s’installe quand on laisse travailler une équipe sans méthode. Beaucoup de gens n’y voient qu’une structuration des plus mauvaises pratiques du monde de l’entreprise :

  • La réactivité, c’est lorsque le client change sans arrêt d’avis, et qu’on s’efforce de le suivre comme une girouette.
  • La mise en place d’une équipe réduite, c’est quand on n’a pas assez de développeurs et qu’on leur donne plus de travail à faire que ce dont ils sont capables.
  • Les cycles de développement ultra-rapides, c’est quand on n’a pas le temps de tester correctement les nouvelles versions, et qu’on est obligé de faire des versions de correction en urgence quand le client découvre des bugs.
  • Sans parler des développeurs incapables d’écrire la moindre documentation technique, des chefs de projet qui ne veulent pas faire de planning, ni des outils de suivi inexistants…

Cela est assez vrai. Mettre en place une méthode agile nécessite que tous les acteurs soient impliqués dans le processus, en connaissent les avantages et acceptent de jouer le jeu. Certaines personnes n’ont pas la flexibilité d’esprit nécessaire pour y arriver et ont besoin de méthodes plus directives (cf. cycle itératif).

Mais si vous réussissez à mettre en place les outils nécessaires et à former les gens, vous pourrez focaliser l’équipe sur un but commun : la réalisation du projet. C’est une grande avancée par rapport à d’autres méthodes, qui sont basées sur l’affectation de tâches à des employés (tels des robots) et leur surveillance par leur hiérarchie. L’objectif est de réussir le travail, pas de permettre à une ou plusieurs personnes de jouer les petits chefs en faisant claquer le fouet au-dessus des têtes.

Quel logiciel de gestion de projets ?

Il existe un certain nombre d’outils pour aider à gérer les projets agiles. Je vous conseille de regarder de près Skriv, que j’ai créé pour répondre à mes besoins alors que j’étais directeur technique et que nous utilisions une méthodologie agile. Il a une approche différente des autres logiciels, car il utilise votre workflow pour automatiser des traitements qui prennent beaucoup de temps.

Testez-le gratuitement pour vous faire votre idée.

26 réponses sur “Les méthodes agiles”

  1. Je reviens sur cet article que j’ai lu il y a quelques temps. Je pense que ces méthodes agiles ne peuvent pas s’appliquer aux grosses structures.
    Cela débouchera inévitablement sur un joyeux bordel.

    Une grosse SSII a besoin de processus précisément définis et d’une industrialisation poussée pour être compétitive. Et la satisfaction du client peut être également obtenue de cette façon.
    Avoir des processus communs à toute l’entreprise permet une meilleur mobilité des collaborateurs et une plus grande efficacité.

  2. Tu serais étonné, si tu savais à quel point les SSII sont justement les « locomotives » qui ont poussé l’usage des méthodes agiles (et plus particulièrement l’extrem programming, en fait).

    Même dans les grosses SSII, la majorité des développements sont fait par des équipes de taille relativement réduite, pour lesquelles l’agilité est primordiale. Il ne faut pas oublier qu’en France, 84% des SSI ont moins de 50 employés (source Wikipédia). Les gros projets, ceux qui réclament des équipes de plusieurs dizaines de personnes restent une exception.
    Sans compter qu’un grand nombre de SSII placent leurs employés chez leurs clients, que ce soit comme développeur, chef de projet ou consultant ; et dans ce cas les méthodes agiles montrent tout leur intérêt.

    Il faut bien comprendre que le but premier des méthodes agiles est la satisfaction du client, plutôt que la conformité à un contrat. Et pour les SSII, un client satisfait est un client qui revient.

    Maintenant, je concède que les méthodes agiles ne sont pas applicables dans tous les cas. Et les sociétés de services ont souvent mis au points leurs propres méthodes de gestion de projet, adaptées à leurs organisations. Mais bien souvent ces méthodes sont – ou évoluent vers – des méthodes itératives malgré tout.

  3. C’est bien pour cela que j’ai précisé grosse SSII, car je sais bie qu’il en exste une multitude de taille réduite.

    Et le travail en AT ou en régie dépend beaucoup des méthode de travail du client. En AT, c’est souvent une obligation de moyen sur laquelle on s’engage. Et le prestataire se plie lors aux processus métier du client.

    Je suis bien placé pour voir ce qu’il se passe dans les groses SSII. Le maître mot aujourd’hui, c’est industrialisaton. Généraliser l’utilisation de mêmes pocessus et des même outils au sein de toute la société. Cela pemet pour chaque collaborateur d’être efficace tout de suite, quel que soit le projet sur lequel il est amené à travailler.

    En cela, c’est donc difficilement compatible avec les méthodes agiles, qui par définition dépendent intrinsèquement du projet sur lequel on travaille. Je persite en disant que cela s’applique sans doute très bien aux petites structures, mais que ce n’est pas adapté aux grosses.

    On ‘sentend donc.

  4. Les méthodes agiles, ou plus simplement les processus itératifs, ne sont pas synonymes de joyeux bordel où chacun fait les choses à sa sauce dans son coin. Ce sont des sujets maintenant bien normalisés. Une rapide recherche sur Internet ou dans les rayons d’une librairie informatique permet de voir à quel point leur utilisation se répand dans les sociétés de service, qui les adaptent évidemment à leurs besoins.

    La plupart d’entre-elles ont entamé leur mutation vers les méthodes agiles, et vont jusqu’à communiquer dessus (à l’image du « Accenture Agile Delivery Capability »).

    Ce qui est par contre assez courant, c’est la résistance passive au changement :
    – « Ça marche, ce truc ? »
    – « OK, ça doit bien marcher chez les autres, mais nos besoins sont vraiment différents ! »
    – « On a nos habitudes, rodées par 20 ans d’expérience, on peut pas faire mieux »
    – « Bon, on va essayer sur un projet, pour voir »

    Les grosses SSII qui forment leurs collaborateurs aux méthodes agiles mettent en place des méthodologies qui sont les mêmes pour tous, et qui sont utilisables sur tous les projets. Je connais des exemples chez Atos, Sopra, Accenture, Cap Gemini, IBM, …

  5. En réponse à Drandran, je pense que au sein d’un proess global de l’entreprise on peut penser, particulièrement dans le domaine du GL, que les équipes appliquent de l’agile (Scrum est assez à la mode) pour le développement de leur sous-projet.

    Il faut cependant ajouter que ça se passe sur des itérations courtes, de l’ordre de la semaine. En Scrum, on va simplement remplir le Backlog (liste des taches qu’il faut réaliser) avec l’info qui dérive du Process global de ta grosse SSII (disons Thalès, si ça te parait de taille suffisante). L’itération du Process externe à l’équipe, auquel elle se plie, englobe plusieurs itérations de scrum (1 mois = 4 itérations). On se fixe donc comme objectif (pas agile du tout) le délivrable spécifié par le process externe, mais on applique Scrum à l’échelle de l’équipe.

    Ce qui reste agile, c’est la façon dont l’équipe attaque le problème, car à objectif fixe (le délivrable), les moyens de l’atteindre varient. La découpe du travail sur ses membres en fonction des besoins et des difficultés renconrées est également agile, et la visibilité du travail de chacun est augmentée par tout le travail sur l’action coopérative que préconise la méthode.

    Bref, l’agile ne me parait pas exclusif de process plus lourds (voire avec nécessité de certification, et ça c’est bien lourd) autour.

  6. Bonjour, chaque année apporte son lot de buzz words, et en 2009 c’était les « méthodes agiles ». qui s’en souvient aujourd’hui? la mise en place de nouvelles méthodes de gestion de projet exige une analyse des risques rigoureuse, et est demandée par la plupart des grandes entreprises. Des outils gratuits d’analyse des risques sont disponibles sur notre site Projiris.fr . Cordialement

  7. Dans le monde des sociétés SSII, on parle de tout et de rien, cycle en V, cylce W, méthide agiles, analyses organiques, méthides experts, et que sais-je. Mais dès qu’il s’agit d’aborder les vrais projets dans toutes leurs définitions, problèmétqiues, ces gens disparaissent de la scène et commence à commenter tel ou tel principae n’a pas fonctionné. En France, notre problème en informtqiue et qu’on perds entre 20 et 30% dans des question inutiles alors qu’il faut se focaliser sur le conceptuel réel et non virtule, sur la créativité, sur la comppréhension directe des règles de gestion , éviter les méthodes inutiles, penser aux méthodes dites de perrtes et adapter à chaque projet ces algorithmes; Même dans les grandes domaines de la science qui dépasse largement cette discipline informatique, il n’existe pas une seule méthode mais bel et bien plusieurs méthodes et seuls les mieux placés svaent de quoi il’agit et quand et comment les adapter au lieu d’écouter des personnes qui viennet apllqiuer telle ou telle méthiode pour une périuode donnée pour justifier leur poste et leur présence. Il faut ques les entreprise qui souffrent de cela; pense avant à adapter des méthodes en fonction de son peojet qu’il soit compliqué ou commplexe et par éxpérience dans la conduite de projtes scientifiques et informatqiues de gestion, je sais de quoi je parle
    MERCI

  8. Le gros problème des méthodes agiles, c’est qu’elles servent trop souvent de prétexte à un nombre trop important de « pseudo chefs de projet » (aussi appelé « petits chefs »), pour ne plus rien faire. « Inutile d’établir un cdc, on fait du scrum, on doit être à l’écoute du client » et autres stupidités du même genre. Au contraire d’augmenter la qualité du produit, on augmente les coups et on bascule toutes les charges et toutes les responsabilités sur les développeurs.

  9. Salut,
    j’espère que je trouve une personnes qui va me répondre, malgès que ce sujet est un peu daté,

    dans un projet cours d’une durée d’un mois, nous avons opté pour une méthodologie agile, mais nous n’avons pas spécifié quelle méthode (xp, scrum,….). C’était un projet web,
    Client parle avec le chef de projet, ce dernier écrit ce que les développeurs doivent effectuer. ces derniers codent, ensuite livre, le chef de projet fait ça recette.

    donc je pense que je vais parle d’une méthodoe Agile tout simplement ???

    merci

  10. Hum ce que tu décris ne me semble pas vraiment « agile ».
    Le chef de projet écrit la spécification, et les développeurs sont de simples pisseurs de code ? Le chef de projet fait la recette ?

    Sans avoir plus d’info, quelques conseils rapides :
    – Définir l’ensemble des fonctionnalités attendues par le client.
    – Découper ces fonctionnalités en fonction de leurs complexité (à discuter avec les développeurs, ce sont eux qui définissent la difficulté de chaque tâche), et les regrouper en sprints d’une semaine.
    – Laisser les développeurs écrire les spécifications techniques de ce qu’ils vont développer. L’équipe entière passe ces specs en revue, en se challengeant les uns les autres.
    – Le client doit être disponible pour répondre aux questions que se posent les développeurs. Car aucune spécification fonctionnelle n’est exhaustive.
    – Idéalement, écrire des tests unitaires en même temps que le code est écrit (TDD inside), ce qui facilite le travail parallèle sur un projet à cours terme. Si ce n’est pas possible, prendre au moins le temps de faire de la revue de code.
    – Les développeurs font les tests fonctionnels de leurs développements. Le chef de projet teste à son tour. Et enfin, c’est le client qui valide l’ensemble de la livraison.

    Pour le reste, responsabilisez les membres de l’équipe. Laissez les développeurs faire des propositions et des choix. Faites des réunions de suivi tous les matins, pour détecter les problèmes rapidement sans pour autant faire du micro-management.

  11. Merci pour votre réponse
    ce que j’aime savoir de plus est ce qu’on peut appliquer la méthode agile ?? sans implémentation , c’est à dire sans XP ou bien Scrum ou bien d’autre,

    merci

  12. Bien sûr. XP et Scrum sont des méthodes agiles. Mais il existe un certain nombre de principes communs à toutes les méthodes agiles. Relis bien l’article que j’ai écrit.

  13. Slt,
    Ce n’est pas toujours le cas de laisser les développeurs écrivent les spécification techniques, il y a un chef de projet ou bien un chef de projet technique qui intéragit avec le client; pour les développeurs on peut les laisser choisir les tâches (je suis d »accord)

    donc, une fois tu as le client qui interagit avec le chef de projet ou bien des fois le chef de projet technique, ce dernier travaille avec les développeurs, (collaboration avec le client).
    aussi il y la possibilité de l’acceptation de changement , ainsi lorsque les développeurs codent une fonctionnalités, ils font leur tests, avant qu’il le fasse le chef de projet.

    Je pense que l’exemple que je t’ai donné implémente 70% de la méthode agile vue que la durée est un peu très courts (1 mois ou bien même moins).

  14. @Amine : Je ne suis pas certain de bien comprendre ton message (relis-toi s’il-te-plait).
    Pour faire court : ce n’est pas parce que ton projet ne dure qu’un mois que ça veut dire que tu fais de l’agile !
    Dans tout ce que tu as écrit, il n’y a rien qui soit propre à la méthodologie agile. Peut-être que si tu m’expliquais en quoi tu appliques la méthodo agile, je comprendrais mieux. Mais, en l’état, commence par relire le message que j’ai écrit ce matin.

  15. Slt,

    Justement j’ai lu et j’ai remarqué qu’il y des points qui ils ont été appliqués :

    – Définir l’ensemble des fonctionnalités attendues par le client. (chose qui été fait)
    – Découper ces fonctionnalités en fonction de leurs complexité ( moitié moitié )
    – Laisser les développeurs écrire les spécifications techniques de ce qu’ils vont développer. L’équipe entière passe ces specs en revue, en se challengeant les uns les autres. (bain non, le cehf de projet qui a fait ce travail)

    – Les développeurs font les tests fonctionnels de leurs développements. Le chef de projet teste à son tour. Et enfin, c’est le client qui valide l’ensemble de la livraison.
    (oui ceci a été fait)
    – Faites des réunions de suivi tous les matins (pas tout les matins , mais il y avait des réunions)

    c’est pour cela que je t’ai dit qu’on peut dire 70% que la méthode agile a été implementé

    merci
    j’espère que j’étais clair cette fois.

  16. Bonjour,

    Je profite de ce billet sur les méthodes agiles pour diffuser ici un questionnaire y étant relatif.
    En effet, je rédige actuellement un mémoire de recherche sur la gestion du temps selon le framework agile.En cela, je recherche donc des avis divers sur le sujet. Même si ma démarche n’est que peu courante, pourriez vous prendre le temps de répondre aux quelques questions le composant. En bien vous remerciant par avance pour les 5 minutes et de l’intérêt accordé. Cordialement, Jenna C.

    https://docs.google.com/spreadsheet/viewform?formkey=dHdxR3JGX044a2gwMjRpVzJFZ3NLT3c6MQ#gid=0

  17. Bonjour,
    merci pour votre article!
    J’aurais une question et j’espère que vous pourrez y répondre, si vous trouvez le temps =)
    Je dois faire une petite étude qui consiste à répondre à la question suivante : « Quels sont les risques de la méthode Agile Scrum? »
    Étant en dernière année du cycle ingénieur, je n’ai pas l’expérience pour avoir mon propre avis sur la question, j’aimerai donc savoir si, de part votre passé, vous auriez des commentaires à me faire?
    Ma démarche pour identifier les risques a été, dans un premier temps, d’identifier les points clés de la méthode et de les caractériser comme risques potentiels si jamais ces « points clés » n’étaient pas respectés à la lettre par toute l’équipe du projet.
    Dans un deuxième temps, ma démarche a été d’identifier quelles autres méthodes étaient utilisées avec Scrum (car apparemment elle est rarement utilisée seule … du moins je crois ..) et donc de pointer les faiblesses (donc engendre risques) de la méthode Scrum.
    Je ne sais pas si ce deuxième point est clair mais en tous les cas il me cause des soucis car j’ai du mal a identifier quelles autres méthodes sont utilisées avec Scrum (après quelque recherche j’ai trouvé que Scrum utilisait en parallèle XP et/ou le cycle en V) et même si j’en ai identifié 2 j’ai du mal à définir pourquoi Scrum à ce besoin et donc être en mesure de définir les faiblesses …
    Avez-vous des idées/ remarques sur mon raisonnement?
    Avez-vous des commentaires par rapport à votre expérience?

    Je vous remercie par avance du temps accordé à ma lecture.
    Bien cordialement.
    H.

  18. @Harmonie : Scrum et XP sont des méthodes agiles, qui sont elles-mêmes basées sur des cycles itératifs (et donc rien à voir avec le cycle en V). Je n’ai jamais vu ces deux méthodes utilisées en même temps ; ça n’aurait pas beaucoup de sens.
    La plupart du temps, on a plutôt tendance à adapter les méthodes en fonction des besoins, mais pas vraiment à les mélanger directement.

    Maintenant, pour répondre à la première question, je ne vois pas vraiment de risque à la méthode Scrum. Il y a par contre des raisons qui peuvent freiner ou empêcher sa mise en œuvre, la principale étant la résistance au changement en entreprise, l’inertie des habitudes.

  19. Merci pour votre réponse rapide!
    Embêtant… je pensais avoir lu cette possibilité de mixer sur le net mais j’ai du mal comprendre …
    Je vais donc changer ce deuxième point, je vous remercie.

  20. C’est ahurissant de bêtises.
    Méthode agile, méthode scrum , extrem programming….

    Parce que certains ne savent pas , plus ou pour raisons fallacieuses faire leur boulot de, BE (bureau d’étude)
    On place les techniciens opérant sur la chaîne de montage en relation avec l’utilisateur pour s’enquérir de ce qu’il faut leur fabriquer. ?
    Le tunnel dans la méthode en V c’est KO ?
    Reste qu’il y a un Tunnel quand même et si c’est précisément sur cette durée qu’il faut travailler travaillons y.
    Mais qu’en final que l’on sache ce qu’il faut produire.
    Et si c’est trop gros a produire. L’analyste conjointement au développeur sauront établir le projet de fabrication sur un plan de « lotissement ». ce qui permettra une présentation de l’avancé des travaux.

    Travailler au « Proto » est déjà à la base commercialement parlant très mal perçu.
    On ne montre pas quelque chose d’inachevé au client qui nous a demande un truc.Juste dans l’optique de signifier le plus souvent « regardez ce que l’on sait faire » : ne pas prendre le client pour un con : s’il fait appel à nous c’est qu’il nous sait capable de le faire.
    Très cher en production également.
    Et je m’arrête là car il y a trop matière a disserté sur le sujet.
    De pourquoi la présence aujourd’hui et surtout de son utilisation maintenant d’un concept de production.
    (Car méthode agile est avant tout un concept de production et pas un concept analytique) vieux de plus de 100 ans
    .Il faudrait revenir à des systèmes qui on fait leurs preuves : technico commerciaux experts professionnels dans une discipline particulière, Ce sont avec ces personnes que l’analyste doit travailler s’il veux toujours travailler là est la question qui reste à répondre.
    Mais de grasse ne donnez pas des réponses en dehors de toutes adéquations du monde réel professionnel dans lequel nous sommes.

  21. @philoo91 : Désolé, mais votre commentaire est un peu difficile à comprendre et à suivre. Mais en substance, si vraiment les méthodes agiles étaient de la foutaise généralisée, ça se saurait. C’est utile. Pas dans toutes les situations, je suis bien d’accord.

    Et merci pour le «ne donnez pas des réponses en dehors de toutes adéquations du monde réel professionnel». C’est mignon (oui je suis sciemment condescendant). Entre mon expérience personnelle de plusieurs année de management agile, et celle de plusieurs dizaines de personnes que je connais qui appliquent les principes de l’agilité au quotidien − sans parler de toutes les sources d’information et tous les témoignages qu’on peut trouver sur le web − je préfère sourire face à cette remarque 😉

  22. Bonjour,

    N’y a t-il pas un risque d’être perpétuellement en phase de conception ?
    Car il arrive souvent que le métier change d’avis,du coup, on modifie le code, on refait des tests, des validations, des livraisons. Puis il arrive que 2 semaines après, sous prétexte qu’un comité de pilotage a parler d’un truc, bah nous revoila à re-changer le code, re tester, etc…
    Je trouve que c’est pas évident cette méthode AGILE, qui met la pression aux développeurs sur qui on attend toujours la nouvelle version du code (mais comme ça change souvent, le pauvre, il n’a jamais le temps de bien faire…
    Je préfère la méthode plus ‘douce’ en faisant de l’itération, c’est moins contraignant, et cela remet la s*responsabilité au chef de projet qui doit faire en sorte que le besoin soit clair et figé. Ainsi, les dev se passent mieux, la qualité est là et on évite le principe du « je fais et je défais » …
    Voila mon avis, avis d’un consultant AMOA en décisionnel qui préfère bien mettre les choses au clair à la base, que de voir les équipes de dev être continuellement en train de faire et défaire.
    A+

  23. @Rémi : Non, mais les méthodes agiles sont basées sur des cycles itératifs. Il y a des gens qui pensent que faire de l’agile, c’est s’autoriser à faire n’importe quoi, n’importe comment. Mais quand on utilise une méthode agile, on décide quand même ce qui va être fait dans chaque itération, et on s’y tient.
    Ceux qui se permettent de changer les spécifications en cours de développement ne font pas de l’agile.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.