feat: add task part

content/conduite_projet/3_taches/index.md

@@ -0,0 +1,95 @@
+---
+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*.