Moosh:

Déjà là j'ai un problème, je prévois 1h de gestion de projet/j   + 1 journée
Je ne sais pas si c'est utile.

Xavier:

1h par jour + 1/2 journee du vendredi
je ne sais pas si on peut aussi facilement forcer un programmeur 
a n'écrire que des tests lundi, etc
c'est bien d'avoir de temps en temps un temps plus long 
pour penser au projet dans son ensemble

"je ne sais pas si on peut forcer un programmeur ...", Perrick répond ici

Moosh:

je me demande si c'est "tordu" de travailler en agile l'aprem et à l'ancienne le matin.

Xavier:

l'agile peut s'introduire petit à petit, pour s'adapter 
et s'approprier la technique en douceur si on le fait graduellement 
ca permet aussi de mesurer ce qui va bien et moins bien 
sans mettre le projet en danger

Moosh:

oui c'est ce que j'aimerai faire, mais par où commencer ?

Par où commencer

Suite à cet échange, voici par quoi je vais en tout cas commencer.

1° établir des règles de codages.

Chaque mois je veux compléter les coding rules et se donner 2 mois pour les appliquer partout.

2° Découpage des tâches et mise en place d'un radiateur comme Perrick en parle sur son blog

J'avais personnellement ce genre de pratique chez Skynet, inspiré d'un conseil de base de Sébastien, j'ai toujours un tas de fiche "A6".

Chaque fiche est une tache plus ou moins monolithique. J'y placais

  • un titre,
  • un "tag-projet",
  • une liste de choses à faire et
  • une durée pour chaque petite chose à faire.
  • une durée totale estimée
  • Un symbole supplémentaire montre s'il y a une partie "d'inconnue" ou de "recherche" sur la tâche.

Au dos, une description de la partie inconnue de la tâche.

Ce que j'ai vu à l'agile-tour que je ne connaissait pas, c'est une information sur la valeur ajoutée de la tâche. C'est plutôt au "client" à donner cette information. Ca j'aurais eu du mal à le faire chez skynet, puisque les "autres" étaient dans un process à l'ancienne et donc 'tout est important'.

Dans le livre "Gestion de projet, vers les méthodes agiles" il y a une colonne en plus que dans ce que j'ai vu auparavant. Entre "en cours " et "fini", il y a la colonne "à vérifier". Livre "Gestion de projet, vers les méthodes agiles" aux editions Eyrolles

3° Mise en place d'une structure automatisée de tests unitaire

  • Créer des tests pour l'existant, sur base d'une discussion avec les codeurs en place, où la question sera "ce code, a quoi il sert ?"
  • Créer des tests pour l'ajout de fonctionnalités
  • Créer des tests pour les bugs recensés

4° Documentation du code.

  • Utilisation de PhpDocumentor
  • Génération automatique de la documentation.

5° Mettre en place le standup meeting : j'en parlais hier

6° Plus tard, mettre en place le timeboxing à 1, 2 ou 3 semaines c'est un peu difficile à décider ca maintenant, parce que j'ai l'impression que la taille du timeboxing dépends du temps moyen de concrétisation des fonctionnalités.

Lectures

Lectures sur les radiateurs
Lecture pour le prochain post