Discussion :

[Marco46]

ils veulent qu’on respecte les délais des sprints sans nous en laisser le temps ...

C'est juste que vous faites pas de l'agile. Le principe de base de l'agile c'est que le contenu d'un sprint n'est pas un engagement sur un périmètre. Il y a des dates de livraisons fixes avec un scope variable. Les tâches sont estimées et ensuite on voit le consommé réel. En aucun cas on ne peut exiger une livraisons d'un scope figé à une date figée. C'est justement pour arrêter de faire ça que l'agile a été créé.

La situation que tu décris c'est une organisation qui faisait du waterfall ou du Cycle en V et qui essaie de se mettre à l'agile sans avoir changé fondamentalement sa manière de travailler. C'est un problème très courant du à un manque de compréhension de l'agile à tous les échelons de l'organisation (chef qui veut sa feature à date).

[xbrossard]

"Les individus et leurs interactions plus que les processus et les outils": chacun utilise ses propres outils et plus rien n'est compatible ensemble. Par exemple, l'un fait les docs en markdown, l'autre utilise Word. Après c'est un bordel total.
"Des logiciels opérationnels plus qu’une documentation exhaustive": le retour des logiciels sans doc et non maintenables 1 an après. Et le créateur du logiciel redevient le seul maître à bord (alors que l'objectif des méthodes de conception était justement de partager la connaissance avec le client)
"La collaboration avec les clients plus que la négociation contractuelle": le dialogue impossible avec le client, soit parce qu'il n'est pas toujours disponible (alors que c'est indispensable en Agilité), soit parce qu'il changera sans arrêt selon son bon plaisir. Et pas de négociation contractuelle, c'est une blague à l'heure des centres de services en SSII où tout les échanges sont minutieusement contractualisés étant donné que la responsabilité de la SSII est maintenant engagé (engagement de résultat et plus de moyen)
"L’adaptation au changement plus que le suivi d’un plan" : comme il faudra toujours être à la pointe de la technique, le logiciel sera toujours en béta, ultra-buggué et non maintenable. En plus, comme il n'y aura plus d'architecture (trop contraignant) le logiciel ne satisfera plus les exigences techniques du cahier des charges (performance, sécurité, maintenabilité)

Bref, l'agilité pour les petits projets en interne d'une boite, ça peut marcher...mais ça représente environ 5% des projets

[rheracles]

L'article comme les commentaires en dessous montrent effectivement que l'agilité met beaucoup de temps à infuser.

L'expression "les méthodes agiles" est en qq sorte presque un oxymore, on parlera plutôt de frameworks agiles.

L'agilité est finalement naturelle, des enfants ou des jeunes qui voudraient lancer un projet par eux-mêmes fonctionneraient naturellement en agile sans le savoir.

La difficulté consiste à se déshabituer d'habitudes héritées d'autres domaines du monde du travail, qui ne collent pas à la plupart des projets de SI.

[blbird]

L'agilité est finalement naturelle, des enfants ou des jeunes qui voudraient lancer un projet par eux-mêmes fonctionneraient naturellement en agile sans le savoir.

Ca te semble peut-être naturel, aussi facile que même des enfants devraient y arriver, mais le contexte des très nombreux projets de toute taille que j'ai pu voir s'y prête peu selon mon expérience (délais et budget imposés dès le début).

[youtpout978]

Ca te semble peut-être naturel, aussi facile que même des enfants devraient y arriver, mais le contexte des très nombreux projets de toute taille que j'ai pu voir s'y prête peu selon mon expérience (délais et budget imposés dès le début).

Au finale agilité et test unitaire même combat ...

[grunk]

Mais, si tous les développeurs prenaient l'habitude de refuser ces délais impossibles qu'on essaye de leur imposer à la dernière minutes, en faisant comprendre au client que le développement ce n'est ni facile ni magique, et que

Tant que l'on ne se décidera pas à utiliser des commerciaux qui savent ce qu'est le développement, qui prennent en compte le triangle d'or, les mentalités ne pourront pas évoluer.

En faites ils pourraient juste demander aux développeurs une estimation du temps nécessaire pour réaliser la tâche, avant de faire des promesses au client.

J'ai déjà du mal à faire comprendre que "non je peux pas te donner une release là maintenant tout de suite avec toutes les dernières nouveauté". On a un process de release à respecter qui prend un certains temps et qui garantie une certaine stabilité mais ca c'est juste inconcevable pour eux.
Chez nous les commerciaux on généralement le réflexe de demander les délais de dév, sauf que ce qui n'est généralement pas fait c'est la prise en compte de la charge de travail. Comme on mène de front à minima une dizaine de projet , si je dis il y'a 3 jours de dév , il comprenne c'est prêt dans 3 jours alors qu'en fait ça peut être 2 mois en fonctions des priorité des différents projets.

Mais clairement un des gros problèmes c'est la manque de connaissance transverse. Les commerciaux/marketeux ne connaissent pas nos contraintes et on connais pas forcément les leurs non plus.

[el_slapper]

(.../...)La difficulté consiste à se déshabituer d'habitudes héritées d'autres domaines du monde du travail, qui ne collent pas à la plupart des projets de SI.

Habitudes qui viennent généralement d'un besoin de contrôle de la part du chef. Ce qui rend les méthodes agiles si difficiles à appliquer, c'est que le chef refuse de ne pas diriger l'équipe comme bon lui semble.

J'ai déjà du mal à faire comprendre que "non je peux pas te donner une release là maintenant tout de suite avec toutes les dernières nouveauté". On a un process de release à respecter qui prend un certains temps et qui garantie une certaine stabilité mais ca c'est juste inconcevable pour eux.

On a les mêmes à la maison. Et ils seraient capables de livrer une release avec 0% de couverture de test des nouvelles fonctionnalités ou de non-regression(en fait, ils l'ont déjà fait), ou de demander à un dev de faire la modif sur site, en loucedé, sans passer par un buils propre(ah zut, déjà fait aussi).

Chez nous les commerciaux on généralement le réflexe de demander les délais de dév, sauf que ce qui n'est généralement pas fait c'est la prise en compte de la charge de travail. Comme on mène de front à minima une dizaine de projet , si je dis il y'a 3 jours de dév , il comprenne c'est prêt dans 3 jours alors qu'en fait ça peut être 2 mois en fonctions des priorité des différents projets.

ou alors le dev répond "temps de dev", mais derrière, il faut builder et tester que le build n'a rien cassé. Ca aussi, c'est oublié très souvent. On a un(e) expert métier qui a demandé un feature, le feature est développé, l'expert métier doit tester pour vérifier que le dev a bien compris...mais ça tourne déjà chez le client. Pas buildé, patché à la rache. Si, si.

Mais clairement un des gros problèmes c'est la manque de connaissance transverse. Les commerciaux/marketeux ne connaissent pas nos contraintes et on connais pas forcément les leurs non plus.

Très important de souligner que eux non plus n'ont pas une vie facile. Ils nous martyrisent certes, mais ils sont eux-mêmes martyrisés par des clients souvent impossibles. On a 7-8 gros clients, et un seul est vraiment sérieux - bizarrement, les projets avec ce client-là se passent toujours de manière impeccable, avec un scope respecté, des délais respectés, et des frottements à la livraison de l'ordre de l'anecdotique. Chez tous les autres clients, on raye fortement la camionnette à chaque fois qu'on fait une livraison majeure. Ben oui, mais quand on a un client qui ne connait pas son propre SI, ses propres besoins, qui ne donne jamais de ressources pour connaitre ses spécificités, qui a une infrastructure serveur 5 fois en dessous des prérequis minimaux, dont les ingénieurs systèmes cassent régulièrement les serveurs, qui refusent de former leur personnel, qui lève une "crise" pour une simple demande de feature à laquelle nous n'avons pas répondu en 48 heures(une fois, le big boss milliardaire américain a débarqué en jet privé à ce sujet, ça les a calmés - mais pas pour longtemps, hélas), et qui se servent de notre support pour lui apprendre son métier(authentique), fatalement, les projets connaissent plus de surprises.

Et les commerciaux sont face à ça, tout le temps. Ils n'ont définitivement pas une vie facile.

[Almopine]

Mon expérience de la méthode agile c'est que la gestion de projet ne prend plus la peine de rédiger un cahier des charges ou de faire une roadmap cohérente, toute façon c'est agile.

Les impératif n'étant pas anticiper et les features mal rédiger, les sprints changent constamment mais c'est justement le coeur de l'agilité, par contre si la difficulté est accrus par une mauvaise gestion de projet ça change pas ta deadline de fin de sprint à toi, oh non. Et au final le retard t'es imputé parce que tu t'es engagé en début de sprint sur des specs mal rédiger sans que le client le sache de toute façon. C'est toujours le dev le responsable, au moins en cycle en v la gestion de projet et la maitrise d'ouvrage avait un minima de responsabilité, la c'est forcément le dev qui est incompétent.

[edrobal]

Ce qui me stupéfie dans l'informatique qui est censé être un monde ouvert (agile ?) c'est la soumission incroyable aux effets de mode.

[hotcryx]

On a testé SCRUM pendant 2, 3 semaines.
Finalement on a arrêté ça ne nous convenait pas.
Raison: à chaque SCRUM, on répétait la même chose sans avoir vraiment avancé

[Ryu2000]

à chaque SCRUM, on répétait la même chose sans avoir vraiment avancé

Vous faisiez des sprints de combien de temps ?
Normalement tu as une liste de petites tâches à réaliser pendant la période du sprint et à a fin tu dois les avoir toutes terminé ou presque (si il y a eu un problème et qu'une tâche prend plus de temps que prévu, ou si le temps nécessaire à réaliser une tâche a été mal évalué).
C'est bizarre que vous n'avanciez pas.