Les méthodes Agiles privilégiées en entreprise

Oui, je confirme que c'est assez à la mode en ce moment de se dire "agile", du coup pas mal de chef de projet et de dirigeant veulent travailler en méthode agile alors que le contexte du projet ne s'y prete pas vraiment. Ca fait quelque temps que je bosse en méthode de travail scrum et pour le moment je ne suis pas vraiment convaincu car même si ce sont des méthodes de travail centrée sur le client et le bien être des développeurs je trouve que ca coute plus cher en terme de temps de développement, m'enfin...

Donc si je résume, elle est populaire parce qu'elle est populaire?? XD

C'est ce qui s'appelle un effet de mode...

fatruc_20> Au début, les temps de développement peuvent en effet être augmentés. Voir de manière considérable avec des méthodes comme TDD (Test Driven Development). C'est au bout de quelques mois que tu te rends comptes des bénéfices. Pour mettre en oeuvre TDD et Scrum (enfin, une adaptation adaptée à nos besoins), je peux t'assurer que cela est extrèmement bénéfique. Nous sommes en mesures d'ajouter des fonctionnalités sans crainte de tout casser, le produit évolue de manière constante (pas hyper rapidement, mais en gardant une fiabilité très satisfaisante).

Mes la règle au finale est simple: Plus tu as d'incertitudes dans un projet informatique, plus l'agile est efficate. Plus les choses sont déterminées et figées (genre un outil de compta), moins le bénéfice est important (voir nuisible).
Mais comme la complexité des projets informatiques va dans l'ensemble, en augmentant (donc en augmentant aussi les incertitutes), l'agile devient de plus en plus valable (je dirais même indispensable).

Personnellement, je suis un grand fan de ces methodes, mais il y a clairement plusieurs façon de les voir :
- wééé, on ne s'engage sur rien, et on va voir venir (client pas content)
- chers techs, nous allons passer en methode agile : vous allez passer 100% du temps en dev pur, et tout ce que vous faites à coté (400%), c'est du bonus, ca ne compte pas (mais faut quand même le faire) (=techs heureux)
- ou la méthode proprement dite, qui commence par remettre surtout en question la méthode précédente. (et comme c'est 'achement plus facile de remettre les autres en question que soit même, c'est pas la vision préférée)

Et j'aurais du me relire, c'est bourré de fautes plus grosses que moi.

vaste foutage de gueule...
n'importe quelle méthode, du moment qu'elle est utilisée avec intelligence (rare chez les décisionnaires...) est "Agile"

pch55> Hummm, ta conclusion est un peu hative; je crois que tu oublies quelques détails... Même si je suis tout à fait d'accord qu'appliquer une méthode sans chercher à l'adapter à ses propres besoins est souvent une grosse erreur.

Agiles n'est favorable que pour mettre d'aplomb une relation d'incertitude entre le client et ses développeurs: "on ne sait pas trop, mais on veut au moins ça et ça"... Agiles le permet. Mais dès que c'est spécifié, Agiles autorise le prototypage spaghetti, le codage hétérogène, et à terme un truc impossible à maintenir.

Enfin bon, ce que j'en ai vu ne m'a pas convaincu.

Effectivement sur le papier, TDD et méthode agile c'est le couple gagnant en terme de fiabilité, mais le temps que ca consomme est simplement hallucinant et n'est pas du tout applicable sur un projet contraint par le temps. De plus le tdd implique une exhaustivité des test ce qui est formidable sur le papier, mais qui coute extrement cher quand il faut retoucher un bout de code car tu es obligé de re-coder 75% des tests. En plus je ne suis personellement pas assez psycho-rigide pour véritablement coder en tdd, je fais toujours mes tests après mon code en essayant de les faire plus intelligemment. Le code est de qualité moindre diront les environnements d'intégration continue pourtant bizarrement il n'y a pas plus d'anomalies et je trouve ca plus épanouissant personnellement, et c'est super important dans une méthode de travail centrée sur l'individu. Et oui, les développeurs préfèrent tous leur coté cowboy à leur coté robots pisseur de code, et ca tdd ne fait aucun compromis. Bref le tdd me fait chier donc me rend moins productif et moins appliqué, sacré paradoxe.

Je crois qu'il y a vraiment une incompréhension totale de l'agile. Peut être à cause de SCRUM justement, qui est une méthode agile qui peut s'adapter à n'importe quoi (aucun concept informatique dedans). C'est pour cette raison que je n'y adhère pas du tout (Et la je suis d'accord, les cours du créateur de l'agile sont un gros "BULL SHIT"). Par contre, l'eXtreme Programming par exemple, qui reprend beaucoup de SCRUM, intègre quant à lui des règles très strictes quant au développement d'application: Justement, pour éviter ce que MAGELLAN site, prototypage spaghettit, codage hétérogène etc...

Dans mon équipe on fonctionne avec une méthode qui mixe un peu tout ça, et cela fonctionne très bien (sur un project plutôt complexe):
On fonctionne par sprint (parfait pour savoir ce que l'on a faire et ce que l'on peut faire en un temps donné); nous faisons également de l'intégration continue: toutes les nuits, le code est compilé et testé en auto (tests unitaires, + tests fonctionnelles avec de l'UI pilotée etc...). La facilité de maintenance est excellente: Le moindre bug majeur introduit se voit immédiatement le lendemain.
Evidemment, il y a toujours des cas spéciaux qui passent à la trappe, mais quand on en découvre en prod, on rajoute le test qui permet de le reproduire en auto. Cela évite les regressions futures.


Nous avons également des règles communes de développement que chaque membre de l'équipe doit appliquer (que ce soit à bas niveau ou à plus haut niveau).
Et cela n'a rien à voir avec l'agile. Tu peux en effet écrire de la merde et suivre un process agile.
Ce qui est sur, c'est qu'avec un projet très complexe, il est dur de le maintenir dans le temps, même avec du code de qualité, sans passer par de l'agile (et tout ce qui va autour).

(désolé de mettre les "...", ça prend trop de place^^)

Techniquement, nous sommes d'accord. Seulement, une petite nuance s'impose (à mon sens): les méthodes XP sont chères, car nécessitant deux personnes travaillant en binômes. Cela améliore la qualité de codage (en principe), mais cela s'avère souvent difficile à facturer, sauf si le client est soit bien renseigné sur ces méthodes, soit quand il fait confiance à la prestation. en dehors de cela, difficile de lui faire admettre les coûts engendrés.

PS: j'ai bien précisé que j'ai constaté des délicatesses avec Agiles et SCRUM... pas que cela ne fonctionne pas

Pour le binôme, on ne le fait que pour les parties critiques ou 2 cerveaux sont vraiment mieux qu'un. Pour le codage "plus simple", on pisse le code un par un.
Comme je l'ai dit, le mieux est d'adapter les techniques aux besoins!

Je suis tout à fait d'accord... je ne parlais que de la façon dont le codage est perçu