4- Réalisation / Développements

Le développement dépend du contexte technique mais il peut consister en codage ou en paramétrage. Lors de cette étape et notamment au démarrage il faut s’assurer de la bonne compréhension par l’équipe des fonctionalités à développer. Il faut donc démarrer par une réunion d’initialisation de la phase de réalisation. Lors de cette réunion le CP doit présenter le projet, son contexte et les objectifs de développement. Il doit aussi présenter les différentes fonctionnalités ainsi que les lots ou phases envisagées. Le planning doit être revue avec l’équipe. L’architecture de l’application doit être aussi revue.
Réalisation développementSuite à la présentation des spécifications, il faut demander à l’équipe de les lire et de lister les différentes questions. Une préselection des fonctionnalités ou User stories que chaque développeur souhaite implémenter doit être effectuée par chaque membre de l’équipe. Cette sélection doit être fournie au chef de projet.
Une nouvelle réunion doit être organisée pour éclaircir les points et répartir les tâches. Le CP doit probablement faire un arbitrage sur certaines tâches et les affectés aux membres de l’équipe. Idéalement, je conseille de prendre autant que possible en compte la répartition choisie par l’équipe. Ceci permet de mieu reponsabiliser et motiver les membres sur le périmètre de tâches à réaliser. Lorsqu’un arbitrage est fait, celui-ci doit être expliqué (compétence ou monté en compétence, suite logigue, complexité par rapport à un profil, planning…). La répartition doit se faire par lot ou sprint. Une fois la répartition effectuée, il faut demander à chaque intervenant de faire une estimation des charges. Cette estimation permet d’évaluer le degré de complexité vu par le développeur. Cette estimation doit être rediscuté entre le développeur et le CP, notamment lorsqu’une différence en plus ou moins existe vis à vis de l’estimation initalement réalisée en phase de spéficifications. Ceci permet d’éclaircier les points où subsistent des doutes ou une différence d’interprétation dans ce qu’il y a à faire et la façon de faire. Une grosse différence dans l’estimation est souvent le signe d’une mauvaise compréhension. Echanger et expliquer la charge permet une meilleure acceptation par les différents memebre de l’équipe de cette charge. Ceci est d’autant plus vrai lorsque l’estimation proposé par, par exemple un développeur, est acceptée. Des tests unitaires doivent être fait par chaque développeur avant de déclarer une tache terminée. Pour ces tests le développeur doit idéalement s’appuyer sur le cahier de recette. Il doit faire des tests lignes par lignes, ou pas à pas.

Les points d’équipe:
Pour ma part, je m’inspire des daily scrum de la méthodologie Agile du même nom. En effet un point d’un quart d’heure par jour permet au CP ainsi qu’au reste de l’équipe de se ternir au courant de l’avancement et des difficultés qui peuvent être rencontrées. Cette réunion permet aussi de communiquer entre les différents membres de l’équipe. Certains problèmes peuvent trouver leur résolution dans les conseils que peuvent se partager les uns et les autres. Attention, il faut que le CP soit attentif au fait que cette réunion sert à partager l’information et non pas à résoudre les problèmes en direct. Les développeurs lorsqu’ils ont un échange à faire sur une solution, peuvent le faire après la réunion. La réunion doit donc rester courte (idéalment 15 min). Les sujets échangés peuvent se limiter aux questions suivantes:

  • Ce que chacun a réalisé la veille (?)
  • Les problèmes rencontrés (?)
  • Ce que chacun compte faire le jour même (?). Sur quel sujet il travaille, sur quelle tâche il avance…

Lors de la phase de réalisation, les documents en entrée sont par exemple:

  • Les spécifications fonctionnelles et techniques
  • Les spécifications de sécurité
  • Les documents d’architecture
  • Les story board avec les user stories (récits utilisateurs)
  • Les cahiers de test ou de recette
  • La maquette graphique

En sortie:

  • L’application ou module développé
  • Le manuel d’installation et d’exploitation
  • Les résultats des tests réalisé
  • Un document décrivant le contenu de la livraison: Liste des fonctionnalités développées, les limitations, les fonctionnalités qui n’ont pas pues être incluses…