Bonjour à tous,
 
Travaillant actuellement sur un mémoire, j'aurais besoin de quelques témoignages (positifs ou négatifs) sur votre expérience de la gestion de projet à l'aide des Méthodes Agiles.
 
Je vous serais très reconnaissant de votre aide.
 
Merci d'avance.

up

Drapo
 
Et bon courage pour le memoire

Merci, mais le sujet n'a pas beaucoup de succès apparemment...  

deja qu'avoir de la gestion de projet serais bien

Saessen > A mon avis, t'as choisit un sujet très intéressant mais pour participer utilement à ce sujet, il faut trois prérequis :
1) être chargé de la gestion d'un projet ou d'un bout d'un projet
2) utiliser une méthode appartenant à la classe des "méthodes agiles"
3) savoir qu'on utilise un telle méthode et en passant savoir ce que sont les "méthodes agiles"
 
Le premier point élimine d'emblé la plupart des participants de ce forum. Le second élimine un certain nombre de participants qui gèrent des projets.
Le dernier élimine quasiment tous les autres.
 
Personnellement avant de voir ton message, je ne savais même pas ce qu'étaient des "méthodes agiles". Au boulot, je n'ai jamais eu à gérer de projet, tout au mieux j'avais à gérer les priorités entre plusieurs demandes faites par plusieurs personnes sur des projets différents. Chez moi par contre j'ai une gestion de projet basique pour les développements que je fais.
 
Après avoir consulté la page de wikipédia, je peux te dire que dans mon cas les trois points m'ont empéché de te répondre (pas de vrai gestion de projet, pas d'utilisation d'une telle méthode pour mes projets persos et en plus je ne savais pas ce que c'était)
 
 
 
Tout ça pour en venir à une idée qui peut t'aider à lancer cette discussion : modifie le titre et le texte de ton premier message.
Comme titre je te proposes de mettre "Gestion de projets, méthodes agiles". Ca attirera d'avantage ceux qui ont à gérer des projets ou qui ont eu à gérer un projet dans le passé.
Dans le message, rajoute un paragraphe dans lequel tu cites le noms des méthodes les plus connus qui sont des méthodes agiles (voir wikipedia) en mettant le lien de wikipedia pour ceux qui veulent en savoir plus.
 
En tout cas, bonne chance pour ton mémoire.

moi je fais du agile ou presque (celle qui consiste à livrer des lots successifs étendant au fur et à mesure la couverture fonctionnelle du produit)
 
tout ce que je vois, c'est qu'à chaque fois le client est super intéressé par le premier lot.
 
puis voyant que ça fait 2% des specs il est déçu*
 
et après du coup il fait plus de recette ni rien.
 
résultat, le seul intérêt de la méthode c'est qu'on a des milestone réguliers qui permettent de prévoir les dérappages.
 
sorti de ça, la mise ne prod finale est toujours aussi bordelique puisque le client à laissé pisser le truc pendant 6 mois en attendant de tout avoir et être complètement dépassé par l'outil
 
 
* : en fait il est déçu dans la mesure où quand il s'agit d'un nouvel outil, les premiers lots ne couvrent pas un domaine suffisant pour être intéressant par rapport à leur méthodes "plan B" actuelles. résultat, plutôt que de perdre du temps à faire avec le nouveau produit et des bouts de plan B, il laisse tout de côté. pour cette raison, je pense que agile est plus adapté à des projet de montée en puissance d'un outils existant, puisque là le client découvre de nouvelles choses à chaque fois, qu'il ne faisait pas déjà autrement. à partir du moment où il a déjà des solutions en place, c'est rappé, c'est du moins ce que j'ai constaté.

Pour ma part, je bosse a Hong Kong et ici on bosse comme des cons. Donc c'est impossible d'appliquer une telle méthode.
Par exemple le scrub master est censé s'assurer que les conditions de travail sont bonnes, que les binômes de prog travail bien ensemble.
- Deja, on a 2 jours d'arrêt maladie par mois et quasiment tout le monde les prends, donc tu te retrouves le matin a apprendre que untel viendra pas bosser ... demerdes toi.
- pour l'ambiance, les gens gueulent dans les bureaux et commandes de la bouffe a longueur de journée. Donc ça pue et impossible de se concentrer.
- les mecs se lancent dans un projet sans aucun travail de préparation, pas de planning, rien. La plus part du temps, ils n'ont meme pas de dead-line.

Sinon, j'ai essayé de mettre en place le Time Boxing. J'avoue que c'est assez efficace, mais il faut se faire violence pour s'y tenir, sinon tu repars sur les vieilles habitudes (repousser la dead-line)

Merci à tous pour vos réponses.
 
@omega2: je n'ai pas explicité ce qu'étaient les Méthodes Agiles pour la bonne et simple raison que j'ai construit ce topic pour pouvoir recueuillir des témoignages pour mon mémoire, donc les gens qui ne connaissent pas le sujet n'ont aucune aide à m'apporter.
Après, si des gens sont curieux d'en connaitre plus sur le sujet, on peut en parler...

à la base, je dis que je fais de l'agile, mais je sais pas exactement ce que c'est. nous on parle de développement ittératif, ce qui est inclu dans les méthodes agile. après, je ne sais pas quel est le périmètre exact d'agile (pour moi agile c'est le nom du logiciel de caisse livré en bundle avec Générix, l'ERP sur lequel je travaille )

Depuis quand t'as des tests automatisés (voir unitaires) toi

unitaire, oui
 
et ils marchent très bien mes tests unitaire :
 
click => tiens ça plante
click => tiens ça plante
click => tiens ça plante
 
ah ben voilà, il est prêt mon programme. vous prennez le contrat de TMA de 5 ans qui va avec ?

Donc tu fais rien qui ressemble à de l' "agile"

certainement plus que tu ne le crois. je travaille pas comme dans tes fantasmes hein. sinon ça fait longtemps que je ne gagnerais plus ma vie avec

Ah mais je ne fantasme absolument pas à ton sujet, je constate juste

n'ayant jamais eu l'occasion d'utiliser un outil que j'ai pu écrire, t'as vachement dû constater quelquechose

J'ai l'occasion de constater le code que tu colles ici, que ce soit quand tu poses des questions ou que tu réponds

c'est marrant, parceque je ne te vois jamais répondre à mes questions ni apporter d'améliorations à mes réponses. dois-je pour autant en déduire que tu ne sais pas coder, mais juste faire des tests unitaires ?

Tu peux en conclure que tu postes habituellement dans des technos ne m'intéressant absolument pas (.net cat, qui je ne lis que pour mon édification personnelle) ou que je ne connais absolument pas (sql)

Et comme je disais, j'en conclu pas forcément que tu ne sais pas coder.
 
Quand je pose une question sur un truc qui marche pas, évidement que le code est crade, puisque j'en suis à la phase de me demander pkoi ça marche pas, j'ai pas commencé à me demander quelles erreurs gérer si par hasard y'a un scud qui tombe sur la salle informatique...
Idem pour mes réponses, je donne le truc qui marche, je vais pas m'emmerder à en plus gérer tous les cas possibles, d'autant que la plupart du temps c'est de tête dans compilateur sous la main pour vérifier quoi que ce soit. D'ailleurs si tu regardes de près, la plupart du temps je précise "si ça compile, j'ai rien sous la main pour vérifier".

Vous ne pensez pas que votre discussion aurait d'avantage eu sa place dans vos MP?

M'en fout, j'ai répondu au questionnaire de Saessen par mail

Hum. Oui, merci beaucoup d'ailleurs.

moi j'ai bossé dans une boite qui se voulait aussi agile que possible.
 
C'était cool.

Une nouvelle méthode de travail révolutionnaire qui consiste à faire le cahier des charges étapes par étapes, à la guise du client ?
Je me contente d'annoncer de gros délais pour généralement finir le taff à 1/2 deadline puis glander le reste du temps
A quand le feng-shui dans l'art de mener les projets à terme ?

et .. tu does ?

Support : PPT FR ou EN
Temps : 30Min
Theme : Retour d'experience Scrum
 
Vous avez 2h

Faudrait pas déconner! Les questions que se pose MB sur ce forum et ses solutions font partie des rares sujets qui m'interessent dans cette section.
 
Perso, j'ai pas fait d'agile, mon dernier job avec une méthodologie standard etait planifié par le team manager sur un an et demi a deux ans, de la conception a la fabrication du master pour l'usine de pressager des CDs, avec une timeline precise et des checkpoints réguliers, pour une equipe d'une cinquantaine de personnes en tout.
 
A+,

Sur le projet dans lequel je suis, on est passé à la méthode "super agile". Jusqu'à il y a peu:
- specs non systématiquement validées par le client
- pas de gestion de sources
- gestion de projet au jour le jour
- pas de test systématique des livraisons
- rien d'automatisé

Le résultat ne s'est pas fait attendre: livraisons pourries, relations tendues avec le client, parfois des régressions, etc.
Pas de surprise, c'est ce qui arrive quand il n'y a pas de volonté de la part des chefs de faire de la qualité. J'ai quand même poussé pour qu'on prenne le temps de mettre en place une gestion de source (c'est contractuel), et c'est finalement arrivé quand le chef de la qualité nous a momentanément rejoint pendant un mois. Mais certains devs ne prennent tjrs pas la peine de l'utiliser, soi-disant par manque de temps (dont l'"architecte", qui n'a aucune volonté de faire de la qualité). Et un de mes chefs s'imagine tjrs qu'une gestion de source sert juste d'archivage. Perso, j'ai arrêté de me battre contre les moulins à vent, je m'en fous vu que je bosse sur ma partie indépendamment des autres.

Euh... Je connais pas "super agile", mais ça me semble vachement loin des méthodes AGILE au contraire... A la base, AGILE c'est pas faire n'importe quoi pour le plaisir de faire de la merde, mais justement d'avancer vite tout en gagnant en qualité (notamment grâce aux livraison itératives, permettant de détecter au plus tôt les problèmes d'adéquation entre les besoins utilisateur et les solutions retenues). Ca englbe de facto le versioning, puisqu'il faut être capable de livrer des correctifs sur une version livrée plusieurs semaines en amont et qui ne comprend pas des fonctionnalités développées depuis...

Pour moi, le problème d'AGILE se situe justement au niveau du suivit de projet, car il demande bien plus de boulot de la part du chef de projet, puisqu'il doit constamment revalider point par point chaque élément des spécifications avec le client. Ca pose aussi un énorme problème au niveau de la facturation, puisqu'il devient impossible de travailler au mode "forfait". Les chiffrages deviennent complètement arbitraires et le temps effectif totalement aléatoire, selon la stabilité et la droiture du client et de l'analyste.

 
Tiens, je pense que ça pourra t'être utile :

Ben je vois pas où se trouve l'ironie
 
Il reproche à AGILE tout ce que AGILE au contraire permet d'éviter. Du coup non, désolé. C'est comme s'il reprochait à sa ceinture de sécurité de l'envoyer à coup sûr à travers le pare-brise en cas d'accident. L'ironie serait plutôt de parler de la ceinture si se bloque en l'empêche de quitter sa voiture en flammes
On doit pas avoir le même sens de l'ironie

T'as vraiment rien compris en fait

Pour les ignares : http://fr.wikipedia.org/wiki/M%C3% [...] li.C3.A9es
 
Petit retour d'expérience sur un projet de dév mais bon, on pourrait critiquer sur le fait que j'étais dans une équipe composée de moi-même uniquement
 
Contexte : faire un soft de gestion de conf (au moins, les fonctions de base) avec spécs, dossier de conception, dév, manuel d'exploitation et manuel utilisateur en 50 jours... le projet précédent basé sur un outil du commerce modifié par l'éditeur afin de le faire coller à notre besoin ayant duré 4-5 ans et ayant capoté (du classique, quoi).
 
J'ai essayé la méthode XP + développement piloté par les tests. Le soft a été codé en PHP 5 + MySQL 5 + Smarty + archi en MVC et j'ai utilisé la lib SimpleTest pour automatiser mes tests unitaires et même un certain nb de tests d'intégration (SimpleTest pouvant simuler des actions d'utilisateur genre clic ou saisie d'infos dans un formulaire).
 
Vu le peu de temps, pour valider l'IHM et les fonctions, j'ai utilisé XP pour le côté itératif (et interactivité avec le client et les utilisateurs finaux). D'abord, j'ai fait un prototype en HTML/CSS et une fois celui-ci validé, j'ai codé la logique métier. A chaque fois qu'une fct était terminée, je la mettais à disposition des utilisateurs pour qu'ils me fasse un retour afin de corriger le tir rapidement si j'avais mal compris certaines exigences ou s'ils s'étaient mal exprimés, ou si j'avais bien compris mais qu'ils se rendaient compte que ce qu'ils avaient demandé était naze. Pour chaque classe, je définissais les méthodes et avant de coder leur contenu, je codais la classe Test équivalente avec un fonction de test pour chaque méthode de la classe : je codais d'abord la classe de test avant la classe "réelle".
 
Je pense que j'ai réussi à tenir les délais et répondre au mieux aux besoins des utilisateurs et du client du fait que j'étais en contact régulier avec eux. Ca a surtout évité ce qui s'était passé sur le premier projet (je n'y avais pas participé) : on filait des spécs (plus ou moins précises peut-être) à l'éditeur, ça passait par différentes personnes qui comprenaient chacune à leur sauce, et le développeur final (ou les 2) faisaient ce que leur chef leur disait. Bref, tout était déformé, mal compris et sans dialogue direct entre les développeurs et les utilisateurs.

 
Faut réviser le concept de l'ironie, ma foi.

http://jamesshore.com/Blog/The-Dec [...] Agile.html

up

quelqu'un a expérimenté ces techniques récemment ?

Perso, je ne suis pas fan du tout. Je trouve que la ou les méthodes (scrum, lean, ...) vantent un gain de productivité, alors que dans la réalité c'est le plus souvent du gros BullShit et une perte de temps dramatique.  C'est le contrôle par la division du travail et l'infantilisation des ingénieurs. Bref ce sont des méthodes de contremaitres "rebrandées".

Au final, de par mes précedentes expériences j'ai pu voir que le gain apporté est nul ou quasi-nul. Par contre, cela tue dans l'oeuf la motivation des équipes et le gain en compétences des gens, avec toute la bureaucratie qui va avec (morning meetings interminables et sans aucun interêt, process débiles avec jeu de cartes, sprints qui peuvent être déprimants sur la longueur, etc).

Qu'en pensez vous ? Ces méthodes ont tendances à se démocratiser par effet de mode ces derniers temps, mais bon ... est-ce bien UTILE à un quelconque niveau, autre que celui de tirer vers le bas la R&D, de faire confiance davantage aux process qu'aux hommes, et de remplir les poches des formateurs ?