95 lines
3.5 KiB
Markdown
95 lines
3.5 KiB
Markdown
---
|
|
title: "Conduite de projet: les tâches"
|
|
date: 2024-09-23
|
|
tags: ["tâche", "scum", "agile"]
|
|
categories: ["Conduite de projet", "Cours"]
|
|
mathjax: true
|
|
---
|
|
|
|
Maintenant que les besoins sont définis, nous allons les décomposer en tâches
|
|
pour les passer à l'équipe. Là encore il est question de bonnes pratiques,
|
|
d'abord concernant leurs rédactions:
|
|
|
|
* il faut limiter le travail;
|
|
* et aussi le préciser;
|
|
* il faut lier les tâches aux besoins.
|
|
|
|
Mais aussi concernant l'organisation:
|
|
|
|
* Organiser les tâches;
|
|
* suivre leurs avancements.
|
|
|
|
## Rédaction
|
|
|
|
La granularité d'une tâches doit être la plus fine possible et représenter un
|
|
élément atomique du projet. Une tache doit se tenir dans un périmètre donné, par
|
|
exemple:
|
|
|
|
> Écrire du code et documenter sont deux choses.
|
|
|
|
Une tâche doit en général monopoliser un dévelloppeur pendant un/deux jours
|
|
maximum. Si elle demande plusieurs dévellopeur sur plusieurs jours alors **nous
|
|
avons un problème de granularité**.
|
|
|
|
Elle doit être écrite pas l'équipe qui va la réaliser. Il faut définir
|
|
précisément ses objectifs en définissant le **DoD* -- *Definition of done* qui
|
|
représente la ligne d'arrivée. une tâche est **obligatoirement** être
|
|
**rattachée à un besoin**.
|
|
|
|
Le **niveau de précision** d'une tâche doit permettre à n;importe quel
|
|
dévellopeur de l'équipe de savoir **exactement quoi faire**.
|
|
|
|
## Plannification
|
|
|
|
Une fois les tâches rédigée, nous pouvons passer à la plannification. Il est
|
|
toujours question de composer avec le facteur *humain*. Il s'agit ici de
|
|
disposer les tâche sur *un calendrier* et d'affecter les resources nécessaires.
|
|
|
|
Nous pouvons utiliser des diagrammes de *Gantt* pour cette étape
|
|
|
|
## Suivi
|
|
|
|
Pour le suivi est tâches, nous pouvons utiliser la méthode Kanban. Il sera
|
|
alors question de "changer" les tâches de colonnes aux fur et à mesure de leurs
|
|
avancement.
|
|
|
|
## Scrum / agilité
|
|
|
|
Alors que le le projet avance, les besoins peuvent changer. Si dans un cycle de
|
|
production classique comme celui en V, les besoin sont figé tout au long du
|
|
project, *SCRUM* permet d'ajuster les besoins tout au long du cycle.
|
|
|
|
C'est alors le propriétaire -- appelé ici *Product Owner* -- qui est repsonsable
|
|
des changements. L'équipe de dévellopement comporte aussi un *scrum master*, qui
|
|
anime l'équipe. Le *product owner* détermine les priorité.
|
|
|
|
L'équipe itère lors de *sprints* d'une durée définie (en général entre deux et
|
|
quatre semaines). Une nouvelle version du logiciel est livrée à la fin du
|
|
*sprint*.
|
|
|
|
Deux *backlogs* coexistent: le backlog **produit** et celui du **sprint**
|
|
|
|
### Le backlog
|
|
|
|
Il est orienté *user stories*, mais nous pouvons y ajouter des *US* non
|
|
fonctionnelles comme les temps de réponses ou les tolérances aux pannes
|
|
|
|
#### Chiffrage du backlog
|
|
|
|
Chaque tâche a un coût, il faut l'estimer. On utilise un chiffrage abstrait
|
|
relatif à la difficulté et défini par comparaison.
|
|
|
|
### Conception et suivi des tâches
|
|
|
|
Les choix architecturaux impactent les sprints.
|
|
|
|
Pour organiser les tâches et gérer leurs avancement, des réunions quotidienne --
|
|
les *daily* -- sont organisés. Il est question de savoir **qui fait quoi**.
|
|
|
|
En fait de *sprint*, une réunion bilan est organisée pur faire le point de ce
|
|
qui est a été réalisé, les points dur, les amélioration à effectuées que se soit
|
|
le produit lui même ou l'organisation du travail. Lors de cette réunion, on
|
|
calcule la **vélocité** : la sommes des coûts des tâches réalisées sur le
|
|
*sprint*.
|
|
|
|
Deux méthodes existent pou gèrer le suivi des tâches : *GANTT* et *PERT*.
|