Le contenu suivant est tiré du livre blanc populaire "Agile Project Management : Quelle est l'histoire ?" écrit par Jerry Manas. Il est si bon que nous avons voulu le rendre gratuit pour nos lecteurs et lui donner une vie éternelle sur notre blog pour votre plaisir.
Avant de poursuivre votre lecture, nous vous suggérons de lire la première partie de cette série qui explique pourquoi vous devriez adopter une approche collaborative et itérative.
L'agilité est un mode de pensée totalement différent. Il n'est donc pas surprenant que la terminologie soit également différente. Vous trouverez ci-dessous un résumé du fonctionnement d'Agile, ainsi que la terminologie pertinente :
- Les fonctionnalités sont définies dans des histoires , qui identifient le ou les utilisateurs, les actions et les avantages de cette fonctionnalité (par analogie, pensez aux histoires de fiction : elles impliquent un personnage, une intrigue et un motif).
- Les User stories sont estimées en points relatifs (bien que certaines organisations utilisent des jours idéaux). Les story points sont une mesure de la complexité et de l'effort relatifs. Au fur et à mesure que le travail est terminé, l'équipe peut "gagner" des points pour les histoires terminées.
- Les histoires d'utilisateurs sont classées par ordre de priorité afin que les fonctionnalités de plus grande valeur ou les fonctionnalités habilitantes soient livrées le plus rapidement possible. L'équipe travaille en collaboration sur des histoires classées par ordre de priorité à partir d'un backlog dans des itérations à durée fixe, généralement de 1 à 4 semaines (dans la méthodologie Agile Scrum , populaire dans le développement de logiciels, ces itérations sont appelées sprints ).
- L'équipe se réunit régulièrement pour partager les informations et les progrès. Dans la méthodologie Agile Scrum, il s'agit de réunions de standup quotidiennes de 15 minutes. La clé est de rester en dehors des mauvaises herbes. Il n'y a pas de réunions de résolution de problèmes.
- Après chaque itération/sprint, l'équipe et les parties prenantes se réunissent pour évaluer les progrès, faire des ajustements et planifier les prochaines étapes (c.-à-d. planification évolutive). On parle souvent de rétrospective . Elle diffère de la traditionnelle revue post-implémentation, qui a généralement lieu longtemps après le projet et bien trop tard pour faire la différence sur le projet en cours.
- Le suivi de l'avancement se fait par le biais de tableaux d'avancement (burndown) , qui permettent de suivre le travail restant au fil du temps (en termes de story points planifiés par rapport à ceux gagnés).
- Vélocité mesure les story points réalisés par itération/printemps (c'est-à-dire la vitesse à laquelle la valeur est livrée).
La version d'un produit est généralement constituée de plusieurs itérations/impressions. Souvent, il y a un sprint de planification au début de chaque version pour planifier les histoires pour cette version.
Rôles Agiles
Avec les projets Agile, le rôle du chef de projet doit être reconsidéré. C'est parce que :
- Les bases de référence ne sont pas pertinentes - Une base de référence n'a pas de sens si le concept même d'Agile consiste à planifier et à adapter les fonctionnalités pour qu'elles s'inscrivent dans des itérations fixes en termes de temps et de coûts.
- Les exigences formelles initiales ne s'appliquent pas - Les besoins du client doivent être compris, mais les exigences détaillées ne sont pas toutes fixées d'emblée ; les exigences évoluent en fonction des enseignements tirés de chaque sprint.
- Le diable est dans les détails - Les projets agiles réussissent ou échouent sur la base d'une compréhension mutuelle des besoins du client et des capacités techniques. Ainsi, les responsables de projets Agile doivent comprendre les détails.
- Tout tourne autour du produit - Contrairement aux projets traditionnels, où l'accent est mis sur la gestion de la portée, du calendrier et du budget, les projets Agile tournent autour du produit, par opposition au projet. Les éléments comme le calendrier et le budget sont fixes.
- Les projets Agile sont axés sur la communauté - Dans les projets Agile, les développeurs, les analystes, les propriétaires de produits et les clients sont en communication constante. S'ils ne le sont pas, alors la méthodologie Agile n'est pas suivie. Contrairement aux projets traditionnels, le chef de projet n'est pas la principale source de communication.
- Les projets Agile sont relativement peu risqués - Dans le cas d'un projet complexe et de grande envergure, avec beaucoup d'implication des équipes et de pièces mobiles, Agile n'est peut-être pas la meilleure approche. La méthode Agile est souvent utilisée dans le développement de logiciels et d'autres projets axés sur le savoir qui peuvent supporter une certaine tolérance à l'incertitude et où une seule équipe peut travailler à un rythme rapide.
Avec tout cela en tête, certains peuvent se poser l'inévitable question : Que doit donc faire un chef de projet ? C'est une question valable, et les organisations ont adopté différentes approches, allant de l'absence totale de chef de projet à l'utilisation du chef de projet comme facilitateur entre le propriétaire du produit, les clients et les développeurs. Dans certaines organisations, le Scrum Master fait office de chef de projet.
Vous trouverez ci-dessous les rôles typiques dans un projet Agile :
- Chef de produit/propriétaire - détermine la vision du produit et veille à ce que les fonctionnalités répertoriées dans le backlog soient classées par ordre de priorité et comprises ; fournit des User Stories (utilisateurs/actions/avantages).
- Client - surveille l'avancement des travaux et apporte sa contribution aux livrables de valeur (Remarque : le chef de produit sert généralement de mandataire au client lorsqu'il s'agit d'enregistrer électroniquement les commentaires et les contributions).
- Responsable du développement/SCRUM Master/Chef de projet - alimente les sprints à partir du backlog du projet et met à jour les story points en fonction des sprints de planification ; facilite les réunions quotidiennes et les démonstrations de sprint.
- Développeurs - sont affectés aux histoires et prennent des notes de test par rapport aux histoires ; rapportent l'effort à des fins de suivi des coûts.
- Gestionnaires de ressources - optimisez l'utilisation des ressources sur plusieurs projets et assurez la disponibilité des ressources sur les projets critiques.
- Responsable AQ/QE/Testeurs - se concentre sur l'assurance/ingénierie de la qualité, y compris l'amélioration des processus, les tests et les mesures.
Avez-vous rempli ces rôles au sein de votre organisation ? S'adapter à cet état d'esprit, surtout s'il est nouveau pour vos équipes, peut prendre du temps, mais les avantages valent toutes les peines de croissance. Visitez https://www.planview.com/lean-agile-delivery/ pour découvrir comment nos solutions peuvent aider votre organisation à s'adapter, et inscrivez-vous à une démo gratuite de notre solution Lean and Agile Delivery pour découvrir les avantages par vous-même. Dans la dernière partie de cette série, nous examinerons les préoccupations de nombreuses personnes qui souhaitent passer à une méthodologie Agile.
