La décomposition du livre permet de traiter de chaque activité de gestion de projet individuellement (Recueillir efficacement les besoins, Planifier son projet, Suivre et piloter son projet, Gérer les hommes). Pour chacune de ces activités, l'auteur s’efforce à faire un parallèle entre les méthode de gestion de projet classiques (prédictives) et les méthodes de projet agiles.
J'ai été particulièrement intéressé par le chapitre dédié au recueil des besoins qui permet de faire un large tour d'horizon des techniques existantes (approche IEEE, UML/cas d'utilisation, user story), et qui permet de clairement établir les forces et faiblesses de chacune de ces approches.
La grande force du livre est de ne pas prendre parti pour une méthode en particulier. Ainsi, l'auteur s'efforce de trouver des points communs lorsqu'il y en a et n'hésite pas à montrer les différences qui peuvent exister entre les différentes méthodes.
Les propos de l'auteur sont illustrés par un jeux de questions/réponses avec des intervenants reconnus de la scène agile en France (Régis Médina, Laurent Bossavit, Claude Aubry,...).
Bonjour,
RépondreSupprimerJe viens de découvrir ce blog à l'instant et je voulais juste profiter de ce billet pour faire part de mon expérience personnelle. Je travaille sur des projets multimédia assez volumineux et comme beaucoup nous avons succombé à la méthodologie SCRUMM / AGILE.
Et je dis: Attention car un effet de mode s'est emparé de notre industrie en vendant les bienfaits d'une méthodologie dont le nom semblait séduisant mais le retour d'expérience a été un peu cuisant pour plusieurs prestataires
- Dans le cadre d'un projet au forfait avec des paiements liés aux livrables mensuels, continuer d'imposer une phase de spécification du projet (80%) pour garantir vos rentrées d'argent. En vendant le principe que client peut redéfinir ses besoins et les affiner à chaque itération, il trouve cela très plaisant et c'est très constructif pour l'équipe, mais il ne le fait pas pour les paiements en se défaussant sur le service juridique et comptable qui vous annonce que le paiement du mois ne peut pas être fait car le contrat n'est pas respecté à la lettre. Le Product Owner (client) que vous impliquez dans votre méthodologie n'est pas nécessairement le décisionnaire et cette méthodologie peut rapidement vous étouffer financièrement
- Conservez la notion de Chef de Projet au SCRUM MASTER pour gérer les conflits humains, éviter que chacun partent dans des délires techno et confondent décision de R&D et développement. Dans les grosse équipes comme nous (60 personnes) il faut conserver une structure de lead technique, lead artiste, lead ergonome ... avec des strates (de senior à junior). Un jour la problématique des responsabilités individuelles viendra sur la table et la notion d'équipe unifiée explose à ce moment.
Le lead technique prend des choit techniques pour les juniors et est en responsable. Cette pyramide permet également de conserver un système d'évaluation des individus sur le long terme. Ce n'est pas le chef de projet, mais bien les leads qui vont évaluer les juniors ( en cas de primes ou de promotion)
- ne communiquer pas les builds intermédiaires au client mais uniquement les livrables qui sont liés à un paiement car le client va créer un décalage entre le temps pour lui de faire une évaluation (1 semaine pour les grosse applications comme les notre, de formaliser un feedback et nous le communiquer) Entre temps l'équipe à avancer dans la mauvaise direction et c'est du temps perdue. Imposer un délai contractuelles (15 jours max) pour le client formalise son feedback et toujours le faire faire par écrit
- Ne négliger pas la documentation, les réunions stand-up meeting ont la fâcheuse tendance de ne laisser aucunes traces. Réduisez les à l'essentielle et laisser les leads organiser des réunions métier avec un COMPTE RENDU à la clef ... ce qui permet aux gens de s'y référer si un problème resurgit et une décision déjà prise