Gestion de Projet

Rappels sur la gestion de projet

Phases d’un projet

Initialisation/démarrage

L’initialisation d’un projet détermine la nature et le périmètre d’un projet. C’est une étape primordiale dans le cycle de vie d’un projet. Si cette étape est négligée, il y a de forte chance que le projet soit un échec.

Cette phase va regrouper un nombre important d’informations concernant le projet:

• La proposition: qui ou quelle idée est à l’origine du projet, quel est son but, combien de temps va être nécessaire à sa réalisation
• Le périmètre du projet, qui va le diriger et assurer le suivi
• Quels sont les composants et livrables
• le WBS: Work Breakdown Structure: qu’est ce qui doit être fait, jusqu’aux tâches quotidiennes
• la matrice RACI: qui est responsable, concerné, consulté et informé?
• Une ébauche de l’agenda du projet: milestones (jalons), dates importantes, deadlines
• Analyse des coûts et bénéfices, budget
• Analyse SWOT: Strengths (forces), weaknesses (faiblesses), opportunities (opportunités), threats (menaces) posées par le projet à l’entreprise.

Planification

Une fois la phase de démarrage du projet terminée, la phase de planification va permettre de déterminer les tenants et aboutissants du projet de façon plus détaillée:

• Quelle méthodologie va-t-on utiliser?
• Sélection de(s) l’équipe(s)
• Identifier les livrables et les tâches nécessaires pour atteindre les buts fixés
• estimer les ressources à allouer
• estimer le temps et le coût
• mettre en place l’emploi du temps/la timeline du projet
• le budget
• la gestion des risques
• comment mesurer la qualité des livrables
• et enfin, obtenir l’accord formel pour commencer à travailler sur le projet

Exécution (et la documentation!)

La phase d’exécution doit s’assurer que chacun connaît son rôle, les tâches qui lui sont assignées, leur importance pour la réussite du projet. Cette phase nécessite communication et coordination au sein de l’équipe, dans le but de pouvoir fournir les livrables attendus à la fin de cette phase.

La documentation est un facteur de réussite non négligeable d’un projet: une documentation complète et correcte permet de déterminer rapidement quels objectifs ont été atteints, ou pas.

Contrôle et supervision

Durant l’exécution, il est important de contrôler et superviser les tâches effectuées, en cours d’exécution ou non réalisées pour identifier rapidement les potentiels problèmes, points de friction, points de blocage afin d’y remédier le plus rapidement possible. Pour cela, on dispose de différents indicateurs de performance, permettant de savoir:

• Où en sommes nous? (mesure)
• Où devrions nous en être? (évaluation)
• Comment nous remettre sur les rails (en cas de problème)? (correction)

Finalisation

Enfin, la finalisation d’un projet va consister:

• à clore la phase d’exécution une fois les livrables… livrés
• à clore le projet de manière formelle (facture finale remise au client, etc)
• Enfin, à effectuer une revue du déroulement du projet (process d’amélioration continue, alimentation d’une base de connaissances, etc) afin de prendre de la hauteur et d’identifier ce qui a bien fonctionné, moins bien fonctionné, pas du tout fonctionné, les causes des difficultés rencontrées, etc.

Méthodologie Agile

Définition

La méthode Agile de gestion de projet, ou plus précisément le management agile, se base sur trois grands principes:

• La motivation rationnelle des ressources humaines: chaque collaborateur est impliqué dans le processus, le but étant que chacun participe au processus d’amélioration continue.
• L’utilisation des nouvelles technologies afin d’accélerer, simplifier et améliorer les processus de l’entreprise
• Des processus flexibles, reconfigurables en continu afin d’améliorer la qualité globale (services, logiciels, SI, etc)

L’”agilité” est donc une capacité de l’entreprise de procéder à des changements continus de façon harmonieuse, et où “la politique, la stratégie et les opérations sont pilotées en continu” (Michel Guérin).

Maintenant, dans l’organisation de projets informatiques (développement logiciel, cybersécurité, infrastructure), on dispose de plusieurs outils et méthodes permettant de fonctionner de façon “agile”:

Scrum

Le nom Scrum est tiré du rugby: c’est la mêlée. Cette méthodologie a été définie pour la première fois en 1986 par Hirotaka Takeuchi et Ikujiro Nonaka. La métaphore autour du rugby associe les différentes phases de réalisation d’un projet à la stratégie et cohésion d’équipe nécessaire dans le Rugby pour marquer un essai. Scrum découpe volontairement un projet en sprints courts afin de faciliter l’adaptabilité de l’équipe notamment dans un environnement évoluant rapidement, typique notamment des projets informatiques (développement, infrastructure, etc)

Cette méthode s’appuie sur trois principes:

• La transparence
• L’inspection
• L’adaptation

Elle définit aussi plusieurs rôles, notamment:

• Le PO, Product Owner, qui définit les priorités du projet, et qui a pour rôle de décider de l’orientation du projet.
• Le Scrum Master, dont le rôle est de faciliter la communication entre l’équipe et les clients finaux. Il sert d’interface, évitant ainsi à l’équipe d’être distraite par des demandes clients incessantes. Il n’a pas de pouvoir hiérarchique sur l’équipe, son rôle principal étant d’éviter à l’équipe de perdre du temps en étant perturbée par des éléments extérieurs. Le Scrum Master ne doît pas se comporter en Chef de Projet, ce qui contreviendrait à son rôle de facilitateur.

La méthodologie Scrum s’organise ainsi autour d’un cycle bien défini.

Tout d’abord, le Sprint Planning permet de définir les buts à atteindre sur une période donnée et de planifier les différentes tâches à accomplir pendant le Sprint pour atteindre les objectifs fixés. Ces tâches sont stockées dans le Backlog. La durée d’un Sprint peut être variable (de quelques heures à un mois), mais on retrouve assez souvent une durée de l’ordre de deux semaines.

Chaque jour, un Daily Scrum d’environ 15 à 30 minutes permet de vérifier la progression des équipes vers les buts définis lors du Sprint Planning et si besoin d’affiner le Backlog.

La Sprint review permet, à la fin du sprint, de déterminer et démontrer les objectifs atteints au regard du Sprint Planning initial. La review clôt le sprint et est suivie de la rétro:

La “rétro” (Sprint Retrospective) qui va nous permettre de vérifier l’état du backlog, de calculer des métriques précises et des indicateurs de performance (KPI: Key Performance Indicator) concernant le déroulement du sprint, et de définir les différentes tâches à conserver et/ou ajouter dans le prochain Sprint Planning. En effet, à la fin d’un sprint, toutes les tâches du Backlog n’ont pas nécessairement été traitées. Il convient alors d’identifier les points de blocage et/ou friction, tâches non finalisées, pour améliorer l’efficacité du prochain sprint.

Ci-dessous, un schéma rétrospectif du cycle d’un Sprint dans la méthodologie Scrum, issu de Wikipedia (je suis nul en schémas ):

En gestion de projet, le but est de découper les objectifs généraux en tâches atomiques distribuées aux membres de l’équipe en fonction de leurs capacités, de leur disponibilité, tout en favorisant la communication à l’intérieur de l’équipe, notamment pour identifier les points de blocage potentiels. Ces tâches atomiques sont dénommées User Stories lorsqu’elles sont assignées et leur difficulté estimée (story points).

Sur des projets de plus grande ampleur, on rassemblera plusieurs sprints dans une Epic. Attention cependant, un sprint peut contenir des stories de plusieurs Epic.

Contrairement à la méthode du Cycle en V, la méthode Scrum est nettement plus flexible, le projet lui même ainsi que ses objectifs pouvant évoluer de façon beaucoup plus libre.

Cependant, plusieurs facteurs peuvent nuire au bon déroulement du projet dans la méthode Scrum:

• L’accumulation de dette technique
• Un Scrum Master se prenant pour un chef de projet
• Le cycle en V déguisé en Scrum

Kanban

Kanban, dans notre cas, est une méthode de visualisation des tâches du backlog et de leur avancement, organisées dans un tableau à plusieurs colonnes, permettant - à mon avis - une meilleure visibilité des différentes tâches du sprint et de leur évolution.

Ces tâches sont déplacées de colonne en colonne en fonction de leur réalisation. Par exemple, une organisation Kanban classique dans un projet pourrait ressembler à cela:

Personnellement, j’aime bien cette représentation lors d’un sprint. Comme chaque tâche peut être associée à des commentaires et discussions, il devient facile de visualiser les points de blocage et d’apporter de l’aide à la personne à qui la tâche a été assignée. Cette visualisation permet donc de fluidifier le sprint. De plus, comme il est assez aisé d’ajouter ou supprimer une colonne (du moins dans la plupart des logiciels de gestion de projet implémentant cette visualisation), on peut facilement adapter Kanban en fonction des besoins du sprint.

Scrumban

Scrumban, c’est une approche agile liant Scrum et Kanban. Ici, les User Stories sont “transformées” en tâches kanban. Lors du sprint planning, on voudra idéalement bien prioritiser les différentes tâches (et donc user stories), afin d’aider les membres de l’équipe à identifier correctement les tâches à réaliser en priorité: on placera donc les tâches les plus importantes en haut de la colonne “Todo”, les moins importantes en bas, etc. Une tâche importante n’est pas forcément une tâche avec un nombre élevé de Story Points (qui indiquent la difficulté de réalisation d’une tâche).

La méthodologie Scrumban implique qu’un membre de l’équipe ne devrait travailler que sur une seule tâche à la fois, ce qui veut dire qu’il ne peut y avoir qu’un nombre limité de stories dans la colonne “En cours” notamment. De même, dans la méthodologie scrumban, ce sont aux utilisateurs de s’assigner eux-mêmes les user stories, et non au chef de projet.

Enfin, lorsque le sprint arrive à terme, il convient de se concentrer sur la finalisation des tâches en cours, et de ne plus déplacer de tâches de la colonne “Todo” vers la colonne “Doing” qui ne puissent être complétées avant la fin du sprint. C’est ce qu’on appelle le Feature Freeze. Les tâches “freezées” seront donc reportées sur le prochain sprint.

Enfin, la dernière étape à la fin du sprint est l’étape de Tri: le chef de projet va alors décider quelles tâches vont rester non-terminées, et en général si elles seront reportées dans le sprint suivant. Cela permet à l’équipe de se focaliser sur les stories les plus importantes du sprint en priorité et de ne pas “stresser” sur la non-réalisation des stories les moins importantes.

SAFe: Scaled Agile Framework

La méthodologie SAFe a pour but d’adapter les méthodologies Agile et notamment Scrum à des projets plus larges nécessitant le travail de plusieurs équipes (la méthodologie Scrum étant “taillée” pour une équipe), et de plus longue portée dans le temps.

Cet ensemble de méthodes permet ainsi de mieux gérer la délégation d’autorité, d’optimiser et synchroniser la livraison des… livrables (hum). En général, au bout d’un certain nombre de sprints, un temps est pris pour prendre de la hauteur et réfléchir rétrospectivement à l’avancée des projets afin d’améliorer les prochains sprints. Historiquement cette phase était planifiée tous les six sprints et durait une semaine, cependant cette rigidité a été revue car il s’agissait d’un anti-pattern par rapport à la méthodologie Agile.

Bien qu’efficace pour piloter de gros projets, cette méthode n’est pas exempte de critiques, notamment car elle aurait tendance à décourager la liberté créatrice des différentes équipes, car elle introduirait un contrôle trop strict des différentes équipes liées au projet et un cadre trop rigide et donc trop proche du cycle en V.

Outils

De nombreux outils nous permettent de gérer nos projets de façon plus ou moins complète, suivant la complexité des projets de l’entreprise. Certains sont open-source, d’autres propriétaires. Dans le TP qui va suivre nous utiliserons OpenProject, un projet majoritairement open-source (certaines fonctionnalités étant payantes).

Propriétaires

• Atlassian JIRA: on ne le présente plus. Certains adorent, d’autres détestent. Malheureusement, Jira n’est plus “selfhostable” et donc seule l’offre cloud est disponible.
• Microsoft Project: là aussi, très connu. Ne l’ayant jamais utilisé je n’ai pas d’avis dessus
• Trello: orienté kanban/scrumban. Peut être limité d’un point de vue fonctionnalité pour des projets d’envergure
• Asana: beaucoup de fonctionnalités, attention, plus un projet devient complexe, plus le logiciel le devient aussi. Offre gratuite adaptée aux petites équipes.

Open Source

• Kanboard: léger, simple, peut convenir à de petites équipes. PHP, SQlite/MariaDB/PostgreSQL
• Redmine: très connu, design un peu vieillot mais efficace. Ruby, MariaDB/MySQL/PostgreSQL/SQLite et même SQL Server (eurrgl)
• OpenProject: là encore un ténor de l’open-source, très complet, certaines fonctionnalités sont par contre payantes. Assez consommateur en ressources (Ruby on Rails). Bonus: charte helm officielle pour un déploiement relativement simple sur Kubernetes.
• Taiga: assez jeune, orienté Scrum+Kanban (scrumban donc). à surveiller. Là aussi assez gourmand en ressources (Django, python).
• ProjeQtOR: Complet, apte à gérer des projets complexes, développé en France - il existe une stack docker mais pas de chartes Helm kubernetes pour le déployer. PHP/Mysql ou MariaDB, la stack classique!
• Tuleap: européen :flag_eu:, complet - jamais testé ici donc je ne peux pas en dire plus.

Métriques / KPIs

Burndown

Le burndown de sprint indique la quantité de travail restant à réaliser (soit en heures, soit en story points, en ordonnée ) sur un sprint, en fonction du temps écoulé (en abscisse).

De la même façon, le burndown d’epic va nous permettre d’estimer l’avancement de nos epic et donc d’optimiser nos sprints sur le long terme.

Vélocité

La vélocité représente la quantité de story points (et donc de travail) réalisée par l’équipe pendant un sprint.

Par exemple, si nous avions un sprint avec 3 user stories:

• Une première user story à 10 points
• Une seconde à 5 points
• et une troisième à 13 points

et que nous avons réalisé la première et la troisième stories, notre vélocité est de 10 + 13 = 23 points de vélocité sur 28 points attendus. On a peut être sous-estimé la difficulté de la seconde tâche et donc sa valeur en story points, ou surestimé ce que notre équipe peut “produire” sur un sprint.

En règle générale, cette valeur est plus intéressante si on en calcule la moyenne sur plusieurs sprints (en général 3): cela nous permet de déterminer la quantité de travail moyenne réalisable par nos équipes par sprint. Par exemple, si notre équipe a une vélocité moyenne de 35 points par sprint, on peut imaginer qu’un projet dont les tâches totalisent 95 points devrait être réalisable en à peu près trois sprints.

Attention, c’est un indicateur, pas une valeur gravée dans le marbre!

Exemple:

Tableau de contrôle

Un tableau de contrôle sert à indiquer le temps d’exécution de nos stories entre leur état “en cours” et leur état “terminé”. Il est particulièrement utile aux équipes Kanban. Cela permet d’estimer un temps moyen de résolution, cependant cette métrique peut fluctuer largement en fonction des équipes et des sprints.

Cependant, cette métrique peut indiquer:

• que vos équipes de sprint s’attribuent trop peu de tâches par sprint
• À l’inverse, qu’elles s’attribuent trop de tâches et ne peuvent pas les compléter dans le temps du sprint
• Un mauvais découpage des tâches (fortes baisses irrégulières) avec des tâches trop lourdes.

Diagramme de flux cumulé

Un diagramme de flux cumulé référence la somme des tâches à faire, en cours et terminées d’un sprint. Il permet donc d’identifier les goulots d’étranglement et difficultés rencontrées, notamment si le graphe montre un “trou” dans sa courbe. Ci-dessous un exemple:

ROTI

Le ROTI, Return On Time Invested, est une métrique relativement subjective: c’est le retour de chaque membre du sprint sur son estimation (en général entre 1 et 5 points) du travail qu’il ou elle a effectué durant le sprint: difficultés rencontrées, stories s’étant mieux déroulées que prévu, satisfaction personnelle, etc.

On additionne ensuite les notes de chacun et on en calcule la moyenne. Cela permet d’avoir un visuel du ressenti subjectif de l’équipe sur le sprint écoulé.

Projet Technique

Sprint 0 (le mien )

Milestones

• Comptes VPN créés et accès vérifiés
• Comptes OpenProject créés
• Groupes constitués
  • Scrum master et PO désignés
  • Rôles techniques assignés (peuvent être assignés au scrum master et au PO)
• Projets créés

Sprint 1

Objectifs: mettre en place une petite infrastructure (soit sur le labo, soit sur un laptop pêchu):

• une VM BDD (mariadb ou postgre) (1vCPU, 1Go RAM, 10Go disque)
• Une VM routeur et futur pare-feu L3/L4 (1vCPU, 2Go RAM max)
  • idéalement une patte sur le réseau “public”/réseau de l’école et une sur un réseau privé/VLAN
• Une VM soit k3s (kube) soit docker ou podman (2vCPUs, 4Go RAM, 20Go disque)
  • héberger gitea ou forgejo dessus, la bdd étant sur la VM BDD
  • héberger opencloud dessus (pas de bdd)
  • voir si on héberge autre chose (kanboard, etc)
• Documentation installation et configurations

Milestones

Tâches, story points

Intégration dans OpenProject

Prenez des captures d’écran de l’évolution de vos tâches au fur et à mesure!

Sprint 2

Objectifs: sécuriser l’infra précédente:

• Pare-feu:
  • matrice de flux
  • défense en profondeur
• WAF: mettre en place un WAF (bunker web)
  • identifier les urls sensibles à protéger en priorité
  • mettre en place les règles correspondantes
• Documentation installations et configurations

Milestones

Tâches, story points