Discussion :

[__Ez__]

Bonjour communauté agile !

Alors que je rédige un mémoire sur le thème : "Les méthodes agiles
répondent elles aux besoins de tous types de projets ?", je
m'interroge sur certains points :

Alors, ces méthodes répondent elles aux besoins ? Pour le moment, je
pense qu'être agile pourrait être la clé à la réussite de tout projet
mais je ne suis pas certains que les méthodes agiles le sont.
Prenons un exemple : Une équipe de 300 personnes qui utilisent Scrum,
le projet ne marche pas comme on le voudrait, le problème est ce la
méthode Scrum, l'implémentation de Scrum dans ce projet ? ou
simplement que le fait de développer un logiciel a 300 dans des
conditions optimales relève de la gageure ?

Certains de mes contacts soutiennent que les méthodes agiles peuvent
s'appliquer à tout projet car elles donnent le "quoi atteindre?" et
pas le "comment faire?" Ils soutiennent que le probleme viens de
l'implémentation de Scrum.
Mais disons que cela est faux, suivre alors les principes du manifeste
agile, est ce la solution? Si oui, sortir de la méthode
n'entraine-t- il pas le chaos qu'on cherche justement à éviter en
imposant des méthodes.

Je suis friand de toutes les réponses que l'on pourrait m'apporter sur
cette réflexion et tout document qui parle de ce sujet.

Merci d'avance.

Clément MASSCHELIN.

[jleroulley]

Nous mettons en place agile dans ma boite
10 dev....
nous en sommes relativement satisfait car nous pouvons faire des livrable projet de façon assez rapide tous les mois.
Par contre a la longue je pense que agile est tout simplement une itération plus rapide du cycle en V.
c'est tout simple.

Le plus important a mon avis reste le génie logiciel de base :
- Gestion de config
- Gestion des sources
- Industrialisation du procédé de dev.

[ssate36]

Bonjour ,

je traite le même sujet que vous , je serai très reconnaissant si vous pouvez m'aider ...merci d'avance.

[el_slapper]

Si on lit Alistair Cockburn(un des papes de l'agile, fondateur de la méthode Crystal), la différence d'efficacité entre les méthodes lourdes et les méthodes légères n'est pas énorme(même si elle est réelle). L'important, c'est d'avoir un esprit agile. L'agileté, c'est les gens. D'après lui, ce qui explique la différence est moins la méthode que les gens : en agile on traite mieux les gens, donc ils bossent mieux(je caricature, il dit ça beaucoup mieux, et avec plein de subtilités).

Pour un projet de style reglementaire, ou à issue unique(par exemple quand j'ai refondu les courriers d'avis d'échéance d'une boite d'assurances), le découpage en petits sprints n'a pas grande signification(même si, pour une immense majorité de projets, il est positif). Mais l'important, c'est d'être soi même capable de se remettre en question. de se dire "je fais fausse route, je dois changer de manière de bosser". Sur ce projet d'assurances, je me suis rendu compte au milieu du gué qu'il me fallait un outillage de test plus costaud(parcequ'il m'était impossible de valider mes devs autrement). Ma hiérarchie a été assez souple pour me laisser le faire(ça a bouffé 15% du budget, non budgetisé au départ). Et le projet a été un succès(1% de dépassement de budget final, une seule anomalie en production, facilement corrigée) grâce à lui. Un projet one-shot, mais avec des intervenants capables de se remettre en question.

Celà étant, dans la plupart des cas, un découpage plus fin des cycles, même sans agileté, présente de nombreux avantages. Il est plus facile d'aller au bout, et, surtout, ça permet au métier d'avoir de quoi travailler(et faire du business) plus tôt. Le tout étant de ne pas être dogmatique. C'est vrai la plupart du temps. Mais j'ai vu des exceptions.

Et, pour répondre à la première question(même si elle a 4 ans), un projet de 300 personnes, c'est du suicide. Quelle que soit la méthode. Martin Fowler pense que la productivité d'une équipe est à la racine de sa taille.

The trouble is that that assumption assumes productivity scales linearly with team size, which again observation indicates isn't the case.(.../...)As usual we have no clear measure, but I'm inclined to guess at it being closer to the square root.

. Sauf qu'avec le poids organisationnel démentiel qu'implique une équipe de 300 personnes, on ne peut plus s'en sortir. Même avec de l'agile. Le projet est trop ambitieux, il finira entre 4 planches.

Et je plussoie jleroulley sur la gestion des sources et des configs. C'est la base.