Reprise du message précédent :

 
Pour le genre de situation que tu décris, c'est le principe même des itérations qui ne fonctionne pas.
 
Par contre, oui, un Kanban agile (appelé pure Kanban, voir mon deuxième post sur ce topic) est bien plus adapté à leurs besoins et sera sans doute bien plus efficace. Il permet aussi de mettre des deadlines pour les tâches qui en ont besoin sans paralyser le système. Mais bon, ils auront peut-être (comme nous) besoin de temps et de faire des erreurs pour changer leur système.
 
Le drame des méthodes agiles, c'est que bien souvent, les gens plongent la tête la première dedans en tentant d'appliquer SCRUM sans considérer les alternatives, sans savoir si c'est adapté à leur cas et sans aucun recul. Et le pire, c'est qu'ensuite, une fois qu'ils ont embauché leur SCRUM master, il est évident que ce dernier ne va pas remettre en cause son propre rôle et usera de tous les moyens dont il dispose pour s'accrocher. C'est aussi cela qui fait qu'on peut rapidement se retrouver dans des situations ultra toxiques.
 
Et pas mal de consultants ne valent pas forcément mieux et vont tenter de vendre SCRUM à tous prix...
 
Bref, alors que l'agilité est VRAIMENT une bonne chose si bien adapté et bien appliqué et que ça peut booster la productivité, souvent ça va produire l'effet inverse.
 
Je finirai en disant que de toutes manières, l'erreur, c'est déjà d'imposer un système sans obtenir l'approbation de ceux et celles qui vont le subir.

 
Je suis naturellement attiré par ce pure Kanban. Le coté pompier rend cela naturel et on pourrait même dire que c'est d'une manière informelle ce que l'on applique déjà avec un petit suivi en plus pour avoir une vision sur les actions long terme et accepter ou refuser les demandes et deadlines des clients. Par exemple pour des projets a 50-70h de boulot on a rarement des deadlines a moins de 3 mois, donc facile de les ventiler sur la période et absorber la variabilité. J'ai du mal a imaginer garder cette capacité de faire trainer une tâche qui prend 10h de boulot sur 1 mois en fonction de contraintes externes avec une approche SCRUM...
 
D'un certain coté, on pourrais voir un refus du changement, parce que la méthode se rapproche le plus de ce que l'on applique déjà    
 
Il y a déjà eu une demande de rajouter une composante plus Kanban dans l'autre équipe agile qui est gérée par notre duo SCRUM/PO, mais ça avait été refusé par le binôme. Je n'avais pas pensé effectivement qu'avec un pure Kanban ils perdaient une grosse partie de leurs raison d'être. Même si on a des aspects organisations et coordinations qu'on aimerais beaucoup leurs déléguer. En tant que technique, ça me fait chier d'organiser des réunions d'alignement et coactivité avec 20-30 personnes par exemple pour certains sujets
 
En tout cas merci beaucoup pour l'avis et les informations. Je vais continuer de me renseigner sur le sujet, j'ai envie d'avoir un dossier en béton a présenter en face  

C'est quand même triste que la plupart des décideurs aient oublies de prendre en compte la première phrase du manifeste agile: "Individuals and interactions over processes and tools"
( bon probablement bien aide par les sales/marketeux des boites de conseils qui vendent des scrum master et qui n'ont rien a foutre dudit manifesto... quand ils sachent qu'il existe )

Imposer Scrum a toute une boite en mode top-down, c'est tout le contraire de la méthodologie agile (ce qui ne veut pas dire que Scrum dans certains cas ne peut pas être adapte a certaines équipes/projets, même si je suis pas un grand fan de cette méthode)

 
Ben...
 

Déjà couvert par nos précédents échanges.
 

La documentation est une obligation réglementaire dans notre domaine, impossible de s'en séparer.
 

Là pourquoi pas, même si les rôles et responsabilités sont toutes établies a l'avance pour pas mal de choses et difficile de trop improviser sur certains sujets.
 

Nos plans sont tracés et documentés et nous sommes obligés de les appliquer jusqu'au bout ou de rentrer dans des flux de déviations très lourds a gérer. On préfère souvent terminer de la manière documentée même si il y aurait eu plus simple techniquement.

 
Oui, jamais réellement compris cette opposition. Je pense que c'est lié à ceux qui ont participé à la rédaction du manifesto et de leurs expériences. Ça ne s'applique pas partout, ni pour tout.  
 

 
Un peu comme précédemment, ça ne s'applique pas pour tout, ni pour toutes les industries. Parfois le moindre changement dans de la fabrication hardware par exemple peut être un véritable casse-tête. Dans un tel cas, c'est donc AVANT d'arrêter le plan final du hardware que l'agilité a du sens. Une fois la fabrication commencée, on est dans le temps longs et l'agilité ne concerne plus que, par exemple, le développement des firmwares pour corriger ce qui peut l'être ainsi que les prochains modèles (et on retombe sur l'agilité au niveau de la conception AVANT d'arrêter les plans).
 
Je réalise que ce que j'écris est sans doute un peu confus.
 
Dans tous les cas, oui, l'agilité n'est pas pour tout, ni tout le temps et il existe différentes manières d'être agile qui ne peuvent intervenir parfois que sur certaines étapes d'un développement.

Pareil, je comprends cette opposition entre documentation/traçabilité et lisibilité/compréhension facile du code
je pense que l'idée, c'est surtout d'éviter une surdocumentation difficile à mettre à jour et de s'y retrouve.

https://agilemanifesto.org/
Je pensais qu'on était sur le forum de l'élite

Y a pas d'opposition de principe entre les deux cotés en Agile, c'est même la phrase juste en dessous des 4 principes:

Bien sur que si réglementairement tu dois faire de la doc, bin tu la fais, ils disent pas du tout que la doc est toujours inutile.

 
C'est quand même faux car la documentation est une partie du produit attendu donc elle est tout aussi importante que le reste. Y a pas de hiérarchisation a faire ou autre, il faut faire les deux obligatoirement et c'est tout. Une documentation erronée c'est potentiellement les périodes de productions depuis le changement remises en question pouvant aller jusqu'aux rappels de lots.
 
C'est comme si je te disais "Working code over comprehensive interface", ça n'a aucun sens de mettre ça en principe de gestion de projet général. Le client a besoin des deux.

Je pense que faut se rappeler l'époque et le contexte ou se manifeste a été écrit avec des cycles de dev très long et très complexes pour tout.
Mais même actuellement, j'ai tendance à être d'accord avec l'essentiel du manifeste.
 
La doc c'est bien, mais encore faut-il qu'elle soit à jour. Je suis pas d'accord quand tu dis que c'est aussi important que le reste. Avoir une appli qui fonctionne, ça me parait plus important qu'avoir une doc parfaite. Avoir une appli sécurisée, aussi... Bref oui c'est mieux quand t'as une bonne documentation, mais comme c'est pas gratuit à produire (et à maintenir), quand tu dois faire des arbitrages, bin ça me choque pas que parfois ce soit la doc qui en fasse les frais.
Quand tout est important/urgent/prioritaire, rien n'est important. On évolue rarement dans un contexte où on a un budget/délai illimité, donc souvent on est amené à faire des choix et des arbitrages.

 
Tu ne semble pas comprendre que dans le domaine où je suis la documentation précise et à jours est une obligation réglementaire, sans elle tu ne met pas en route les machines/systèmes et tes produits ne vont pas sur le marché. Si elle est erroné ou pas a jours, tu te met aux devants de très graves soucis avec les autorités qui peuvent aller jusqu’à la fermeture du site.

Mon poste précédent:

Du coup t'es dans un cas où la doc (et je suppose la QA) ne peut PAS faire partie de l'arbitrage.

Mais c'est un topic général sur l'Agile, pas juste sur le cas de vylkor
Bien sur que si tu bosses sur du nucléaire, de l'aérien ou des équipements médicaux les réglementations et contraintes seront pas les même que si tu fais un blog, une marketplace ou une app mobile...Mais ça représente pas 100% des gens qui font du dev...

 
Désolé, loupé le passage entre les gens qui me répondaient pour m'aider et le retour a l'Agile en général.

Si c'est pas indiscret, tu évolues dans quel domaine, vylkor ? Dans le mien aussi, la doc à jour des softs est très important, je parle même pas des procédures opérationnelles où là, c'est une obligation réglementaire.

 
Industrie pharmaceutique injectable. On a les autorités de santé qui regardent par dessus notre épaule en permanence... Et le système sur lequel on bosse assure le suivis de la qualité produit et l'enregistrement de la production.