- Table des matières
- Manifeste Agile et Gestion de projet
- Les 4 valeurs de la méthode Agile
- SCRUM (La mêlée)
- Outils Organisationnels
La gestion d'un projet en suivant le manisfeste Agile place le client au centre du cycle de vie de ce dernier, en incluant le client au processus de mise en place du projet, l'équipe Agile peut ajuster le développement du projet en fonction de l'évolution du besoin du client dans le temps.
- L'équipe : Les individus et les interactions, plus que des processus et des outils.
- Applicatif : Des fonctionnalités opérationnelles plus qu'une documentation exhaustive.
- La collaboration : Une collaboration avec les clients plus qu'une négociation contractuelle.
- L'adaptation : Une capacité d'adapation au changement plus que le suivi d'un plan rigide.
- Fournir régulièrement des solutions fonctionnelles.
- Prioriser les tâches importantes.
- Segmenter la production du projet.
- Une ligne de conduite rigoureuse lors du développement du projet.
- La simplicité et l'art de maximisé la quantité de travail qu’on ne fait pas.
- Le client fait partie de l'équipe.
- Communication permanente avec le client.
- Établir une relation de confiance avec le client.
- Adaptation et amélioration de l'équipe.
- Privilégier le contact humain.
- Le contact humain facilite la compréhension des différentes contraintes de chaque partie prenantes.
- Communication verbal et non verbal (communication face à face).
- Auto-responsabilisé les membres de l'équipe.
SCRUM est un framework (cadre de travail) permettant de mettre en place la méthodologie Agile de façon incrémentale et itérative.
Le Product Owner (PO) est un membre névralgique sur lequel repose une charge de travail très importante, en effet, il se charge de la communication entre le client et l'équipe, il organise le Product Backlog en fonction des tâches à prioriser et régit globalement le cycle de vie du projet.
Le SCRUM master a pour rôle de s'assurer que le framework SCRUM est bien mis en application, il est aussi responsable de l'animation des rituels Agile.
L'équipe de développement est composée de developpeurs qui auront à leur charges de développer les fonctionnalités du projet.
Le Product Backlog est un registre dans lequel l'équipe pioche des tâches à réaliser.
Le PB est rempli par le Product Owner et peut contenir :
-
Des user-stories : Les user-stories sont des tâches simples expliquant une fonctionnalité du produit, les user-stories peuvent se décomposer en sous-tâche qui serviront d'étapes à l'accomplissement de la user-story liée. Les user-stories sont formattées comme suit "En tant que .. je peux .. afin de .." ou "En tant que .. je dois .. afin de ..", voici un exemple concret : "En tant qu'apprenant je dois m'identifier afin de participer à ma promotion". De cette façon les développeurs savent ce qu'ils doivent faire pour cette fonctionnalité, l'user-story répond à :
Qui ? Quoi ? Pourquoi ?Il ne restent plus qu'au développeur de répondre auComment ?. -
Des Epics : Les Epics sont un ensemble d'user-stories, en générale, les Epics représentent une fonctionnalité complète là où les user-stories représentes des fragment de fonctionnalités. Une Epic pourrait être
Identification des utilisateurset pourrait contenir l'user-story dans l'exemple de user-story.
Le Sprint backlog est un registre contenant des tâches à effectuer pour livrer une fonctionnalité, une fois qu'un sprint est terminé l'équipe, se réunie afin pour les rituels agiles retrospéctif afin d'identifier différents axes d'amélioration et définie les nouvelles tâches pour le prochain sprint.
Dans le framework Scrum, on distingue deux types de backlogs :
- Le product backlog (register de produit)
- Le sprint backlog (registre d'itération)
Le Sprint Planning est un rituel SCRUM qui réunit le Product Owner et l'équipe de développement afin de plannifier le Sprint à venir, ensemble ils établissent une liste de tâche à mettre dans le Sprint Backlog en se basant sur la priorité des tâches ou en fonction de la dernière itération, à la fin du Sprint Planning, l'équipe de développement sait quelles tâches devront être réalisées lors du prochain sprint.
Le Daily Meeting est un rituel dont la charge revient à l'équipe de développement et comme son nom l'indique, il a lieu tout les jours, en générale avant de commencer à travailler sur le projet (vous pourrez aussi entendre parler de Stand Up Meeting). Ce rituel ne doit pas dépasser 15 minutes dans un soucis d'efficacité. Lors de ce rituel les membres de l'équipe doivent répondre aux questions :
- Qu'est ce que j'ai fais hier ?
- Quels obstacles ai-je rencontré ?
- Qu'est ce que je vais faire aujourd'hui ?
Si une problématique notable est relevée, elle doit faire l'objet d'une réunion ultérieure afin d'être résolue.
La Sprint Review est le seul rituel qui incluent les parties prenantes du projet, ce rituel réunit :
- Le client
- Le SCRUM Master
- Le Product Owner
- L'équipe de développement
Il faut compter 1 heure par tranche d'1 semaine de sprint, c'est à dire que si un sprint a une durée de 2 semaines, la review durera 2 heures.
Ce rituel sert à l'équipe de présenter l'état d'avancement du projet à toutes les parties prenantes, de cette façon, le client peut faire part de ses impressions quant au projet, ou dire que le projet nécéssite quelques ajustements.
Avec ce rituel, toutes les parties prenantes s'assurent que le projet avance dans la bonne direction.
De plus, il peut arriver qu'à l'issue d'un sprint, le Product Owner annule ce rituel pour certaines raisons, notamment lorsque le sprint à rencontré des difficultés à être achevé et n'est donc pas présentable.
La Sprint Retrospective et est un rituel qui sert à l'équipe de développement d'identifier ce qui s'est passé durant le dernier sprint.
Ce rituel réunit :
- Le SCRUM Master
- L'équipe de développement
L'idée de ce rituel n'est pas de mettre en évidence ce qui n'a pas fonctionné mais de mettre en lumière ce qui s'est bien passé et vers quels axes d'amélioration le SCRUM Master peut emmener l'équipe afin de corriger ce qui s'est mal passé.
Ce rituel peut durer jusqu'à 4 heures en raison de sa nature.
Jira est un service collaboratif permettant d'appliquer la méthodologie Agile de par son design. Il peut être utilisé avec le Framework SCRUM et avec KANBAN (Bien qu'il n'est pas était conçu dans ce but). Si vous devez travaillez en méthodologie Agile en utilisant le framework SCRUM, Jira est de très loin le meilleur candidat et il est pour ainsi dire Mandatory dans toutes entreprises du domaine qui se respecte.
Jira est un service en ligne, avec Jira vous disposez de tout un tas d'outil simple d'utilisation et accessible via une interface épurée et ergonomique.
Bien qu'il puisse parraitre complexe d'utilisation de prime abord, il s'agit d'un outil très complet qui vous fera gagner beaucoup de temps dans la gestion de projet.
Voyons l'interface de base de Jira :
Voici donc l'interface à laquelle les développeurs sont le plus souvent confrontés, notez d'ailleurs que cette interface est celle dans un projet SCRUM, cette dernière est différente pour un projet Kanban.
Voici l'interface utilisée lors du Sprint Planning :
Cette interface est une celle du Product Backlog et sert donc à transférer les tâches dans le Sprint Backlog. De cette façon, l'équipe prends les tâches prioritaires et le glisse dans l'espace du Sprint, une fois que le Sprint démarre les tâches sont directement transférées au Board.
Voici un apercu de ce à quoi ressemble le Board lorsqu'un Sprint débute :
Ça ressemble à un Kanban.
À la fin du sprint (la date de fin est définissable lors de la création du sprint), les tâches n'ayant pas été achevées retourne au Product Backlog.
Jira n'est absolument pas beaucoup plus compliqué que ça dans le cadre de l'utilisation d'un développeur.
Notons, que ce document sert de découverte et que par souci d'exhaustivité, il ne traite que les aspects de base, cependant, Jira est extrêmement complet, et ne s'arrête pas simplement à ce qui a été montré ici.