Méthode scrum
Globalement, nous nous appuyons sur la méthode Scrum tout en considérant que le déploiement de la méthode dépend de la culture des équipes, de leur expérience, du contexte du projet (localisé à un endroit, avec des bénévoles externe, avec une toute petite équipe ou une plus grosse) et de leur volonté de suivre les bonnes pratiques de Scrum.
Dans Scrum, Il n'y a pas de chef qui décide mais plus des responsabilités prises par chacun en fonction de ses compétences, de ses rôles dans l'équipe et de son envie.
L'Équipe
La taille de l’équipe doit être inférieur à 8 personnes pour favoriser la bonne communication, maximiser la productivité.
Les rôles
Le product owner
Ce rôle est très important. Il donne la vision du client (Utilisateur) final utilisateur du système. Plus on est proche de l'utilisateur final, plus le logiciel a de chances de fonctionner. Moins la personne est technique mieux c'est, même si dans certains cas les contraintes techniques peuvent être difficiles à comprendre.
Le product owner décrit les demandes d'un point de vue fonctionnel. La description de fait dans des histoires ("story" ou cas d'utilisation)
Le product owner définit également les priorités. Ces priorités peuvent être ajustés en fonction de contraintes techniques ou de nécessité d'approfondir le besoin avant de démarrer un développement.
Le scrum master
Le scrum master est un animateur, un coach de l'équipe. Son principal objectif est de faire fonctionner des sprints (phases projet)
Il anime les réunions, coordonne les échanges, demande les évaluations de tâches et s'assure de la bonne application du processus Scrum.
Les rôles classiques
Un rôle n’est pas une fonction. C’est une responsabilité en fonction du contexte du projet et des compétences de la personne. Une personne peut avoir plusieurs rôles sur un sprint. Une personne peut également demander à prendre en charge un rôle pour l’apprendre.
Analyste
Il intervient pour aider le product owner à définir son besoin. Ce rôle doit avoir une bonne connaissance de l'existant et idéalement des possibilités techniques du système.
Ce rôle peut être occupé par des personnes "fonctionnelle", des développeurs, des architectes, des graphistes, des ux designer,...
Développeur
Ce rôle réalise les développements, les mises à jour ou les paramétrages de l'application.
Ce rôle peut être occupé par des gens ayant des compétences de développeur, d'analyste technico fonctionnels, d'architectes,...
Intégrateur graphique
Ce rôle réalisé les développement d’intégration des éléments graphique sur les sites internet et les applications. C’est une compétence entre le développeur écran, le graphiste et le développeur pure.
Intégrateur
Il prend en charge le déploiement des applicaiton développée
Ux designer
Ce rôle travaille sur les interfaces utilisateurs au sens large. Il aide à créer des interfaces répondant aux besoins des utilisateurs
Architecte
Il s'occupe de définir la cohérence technique globale du système et s'assure de la pérennité du système. Il a une bonne expérience technique du système et de ses contraintes. Il est capable de trouver des solutions techniques complexes pour que le système reste simple pour tout le monde et sécurisé.
Expert métier
Ce rôle a une très bonne connaissance du métier et de ses contraintes légales, financières, organisationnelles,...
Déroulement d'un projet
Tous les rôles décrit au dessus sont occupés en fonction des besoins par la Scrum team qui développe globalement le système. Toute cette équipe est SOLIDAIRE. Elle assume globalement le projet.
Il ne peut pas y avoir des phrases du style "tu n'as pas livré ce qu'on t'avait demandé où que tu avais promis", dans des contextes de dérapage ou de non livraison, on aura plutôt des phrases du style: "As tu rencontré un problème ? Comment l'équipe pourrait elle t'aider ?"
De la même manière, une personne technique n'ira pas dire "Tu as encore changé ta demande. C'est n'importe quoi. Tu ne sais pas ce que tu veux", il prendra en compte l'impact du changement, essaiera de trouver une solution et repoussera peut être là demande dans un autre sprint.
Traditionnellement, lorsque les équipes travaillent dans la même pièce ou dans le même lieu, il est courant de faire une réunion hebdomadaire de 5-10 mn dans laquelle chaque personne répond à ces 3 questions:
Ce que j’ai fait hier
Ce que je vais faire aujourd’hui
Les problèmes que j’ai rencontré
Le projet est découpé en phase projet : qui dur entre 2 semaines et 3 semaines. Une phase projet s’appelle un sprint. Durant cette période, l’équipe ne travaille que sur les tâches qui ont été décidées dans le sprint ou sur les tâches qu’elles peuvent prendre dans la liste des demandes qui peuvent être réalisées durant le sprint.
Cette approche présente l’intérêt de permettre à l’équipe technique de travailler tranquillement sans être perturbée par de nouvelles demandes sources de perte de temps.
Cela présente également un avantage pour les équipes demandant les développements car elles ont de la visibilité sur la réalisation de leurs demandes. Les sprint étant de courte période, il est possible pour les utilisateurs de voir les résultats intermédiaires.
Une réunion de sprint se prépare. Les tâches proposées pour le sprint doivent être analysée au préalable ou une tâche d'analyse peut être ajouter dans le sprint
