Que sont les méthodes Agiles ?
Lou
Membre
Salut,
qu'est-ce qu'on appelle concrètement travailler avec les méthodes Agile? La page wikipédia ne m'a pas trop aidé...
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Une présentation PDF assez complète sur le blog d'un spécialiste du sujet : à la fois sur les principes (ce que l'on a sur la page Wikipedia) et sur les pratiques.
Je suis pas expert mais l'agilité, c'est un manifeste qui dicte 12 règles de base (de mémoire) sur la façon de gérer un projet.
L'une des règles très importante et le fait de travailler en cycle court et itératifs
Une autre règle est de communiquer très régulièrement.
Etc, etc...
Ensuite, il y a des méthode de travail qui se sont créées et qui permettent de travailler en respectant les règles dictées par le manifeste de l'agilité.
L'une des plus utilisés est la méthode SCRUM.
Voilà
Merci jpimbert, pour le lien, très instructif, en fait ce sont des réunions quotidiennes avec une équipe de 4,5 dév qui échangent sur leur planning, et un gars qui veille à ce que les priorités soient bien remplies. SCRUM.... "C'est une ... révolution"
Les 12 règles sont elles-mêmes réparties en 4 principes :
-La communication entre les personnes plus que les processus et les outils.
-Un logiciel qui marche (plutôt qu'une doc exhaustive)
-La collaboration étroite avec le client
-L'adaptation aux changements (puisqu'ils se produisent toujours)
L'agilité c'est aussi : ne pas passer d'abord 6 mois à écrire des specs qui sont obsolète au bout de 2 jours...
De 4,5 dev.. et du client ! Très important dans agile d'avoir une collaboration étroite avec le client et le mieux pour ça c'est qu'il soit directement impliqué au sein de l'équipe de dev
Et les daily meeting sont très intéressants car :
=> ils doivent durer 10mn max
=> tout le monde est debout (exit les réunions avec des tas de mecs qui ont leur PC et n'écoutent pas)
=> ils utilisent les 3 canaux de communication ce qui maximisent le partage d'infos (très visuel avec les posts it, échange oral et déplacement des post its au fur et à mesure de l'avancement (pour les pragmachinchoses, les gens qui mémorisent mieux quand ils touchent ^^)
Au boulot on utilise Scrum, c'est très bien pour la productivité et la tranquillité du dev.
Au début d'un sprint, on te dit tout ce que tu dois faire avec des taches que tu as défini et après quand y'a des demandes, t'envoie bouler ton boss en lui disant de rajouter la tache
"Prochain sprint"
retour d'expérience sur le choix de mener des projets en mode 'Agile'...
ben en fait au départ la méthode 'Agile' semble plus tôt sympathique : pas vraiment de cahier des charges, cycle cours de dev'.
mais au final, le gros problème c'est que ça peut durer longtemps les cycles courts...
et puis les gens s'épuisent au bout de quelques semaines, à la fin on ne sait plus vraiment quelles sont les fonctionnalités à implémenter ou pas...
bref ça devient vite le bordel ( en cycle court bien sûr ;-)
perso, je préfère passer un peu de temps avec les personnes qui ont besoin du produit et construire sereinement un cahier des charges et rien interdit de produire une première version puis des révisions pour pouvoir implémenter des évolutions solides.
bilan : 1 app' produite en mode 'Agile' qui ne répond pas au besoin des utilisateurs finaux et 2 apps développées en mode 'classique' et qui tournent parfaitement et surtout qui sont utilisées ;-) et avec des specs robustes.
bien sûr ce n'est qu'un avis perso et un retour d'expérience...
Il faut bien comprendre qu'une méthode agile n'est pas (ou pas que) une méthode de développement. C'est surtout une organisation des relations entre l'équipe de développement et le client.
Un des deux risques n°1 (oui ! il y a 2 numéros 1) de l'agile est lié à la représentation du client (le Product Owner en Scrum). Il est impératif que le PO représente effectivement le client, qu'il ait une vision claire de l'objectif à atteindre et des priorités. Je pense que c'est le rôle le plus compliqué à pourvoir. Règle : pas de PO pas d'Agile. (règle dérivée de celle plus générale pour tout projet : No Owner, stop the project)
Accessoirement le second risque n°1 est lié à la dette technique.
Je vois trop d'équipes qui disent travailler "en Agile" parce qu'elles fonctionnent grossièrement en Scrum, mais qui n'ont absolument pas intégré les idées du manifeste Agile.
Déjà elles commencent par me dire "on fait une Scrum Meeting tous les matins, on a des sprints, on attribue des points", etc. .
Le premier point du manifeste n'est-il pas " Les individus et leurs interactions plus que les processus et les outils " ?
Par contre, quand entre deux options je choisis celle qui a le meilleur rapport 'valeur pour le client'/'quantité de travail', on me répond que j'adopte des solutions imparfaites. Comme si nous savions quelle est la perfection pour le client.