---
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*.