Scrum - Méthodes agiles

Ils z'écrivent pas de specs
C'est la faute à Kent Beck
Laissent tomber les outils
C'est la faute à Jeffries.
Aux clients offrent une Leffe
C'est la faute au gars Jeff
Ne relèvent pas les heures
C'est la faute à Schwaber.

Nous sommes 4 à préparer le prochain séminaire SigmaT qui se déroulera dans le cadre de l'Agile Tour le 16 octobre. En plus de Thierry et Olivier, il y a maintenant Jean-Marie. C'est lui qui s'occupe de confectionner l'affiche qui va nous permettre d'annoncer cette demi-journée. En fait il est parti de l'affiche de Grenoble. Dans la partie droite, il y a une liste de méthodes agiles. Plutôt que de lister des méthodes confidentielles comme DSDM, Crystal, ASD, nous avons décidé de mettre des mots clés. Jean-Marie est parti sur 3 valeurs de XP : simplicité, rétroaction(feedback) et courage. Personnellement j'y aurais plus vu des pratiques que des valeurs et je tique un peu quand je vois écrit courage sur une affiche pour attirer le chaland à une conférence sur l'agilité.

Parce qu'enfin, qui n'est pas d'accord pour mettre le courage en avant ? Mais quel rapport avec le développement de logiciel ?

Le courage est une des 5 valeurs de XP. Je lis que XP valorise le courage. Est-ce qu'on doit comprendre qu'il faut être courageux pour pratiquer XP ? Ou que sa pratique rend courageux ?

Quand il présente XP, Thierry prend souvent comme exemple pour le courage, celui de jeter du code "pas beau". Mmmmmmmmmh, il me semble que ce courage est bien mince, que même parfois du code est jeté trop facilement. C'est l'effet "il vaut mieux tout réécrire".

En recherchant dans ma carrière à quel moment j'ai fait preuve de courage (ou j'aurais dû), la réponse qui me vient, c'est le courage de dire non. En particulier non à une demande qui rajoute du travail sans changer le délai.

De ce point de vue là, on peut considérer que les méthodes agiles encouragent le courage en donnant des facilités pour l'exprimer :

• celui qui consiste à dire qu'on a un problème. Il en faut du courage, pour dire qu'on ne comprend rien à la nouvelle techno du framework de sécurité choisi sur le projet. Le scrum meeting favorise cette expression, avec la 3ème question.
• celui qui consiste à dire non à un chef qui cherche à ajouter du travail à un sprint sans en changer l'objectif. Il en faut du courage pour pouvoir le faire et la gestion de projet à la scrum (ou à la XP) rend les choses plus faciles.
• celui qui consiste à dire que le produit ne sortira pas à la date annoncée depuis longtemps, à moins qu'on réduise son périmètre, et qu'il n'est pas question de sacrifier sa qualité.

Pour en revenir à l'affiche, est-ce qu'y mettre courage (en petit) va nous apporter une inscription supplémentaire pour le séminaire du 16 octobre ?

Encore un backlog !

Lire la suite -->

Encore une enquête qui montre que l'agilité est sortie du bois

Lire la suite -->

Des processus libres...

Lire la suite -->

La vélocité est la mesure de la capacité de l'équipe pendant un sprint. Elle se calcule juste après la démonstration lors de la revue de sprint.

Lire la suite -->

Eclipse Process Framework publie un plugin Extreme Programming

Lire la suite -->

Janvier c'est l'époque des voeux et des prévisions.

Lire la suite -->

Un article d'InfoQ: Debating the Merits of Pair Programming rappelle que la programmation en binôme est un sujet des plus discutés parmi les pratiques que propose Extreme Programming.

La lecture de l'article et des études référencées donne de quoi se faire une idée. Mais le mieux est encore d'essayer. C'est ce que mes étudiants vont faire dans les jours qui viennent sur leurs projets. Le contexte s'y prête assez bien : début janvier chaque équipe ^[1] passe de 5 à 10 ou 11 personnes. Les nouveaux sont des étudiants de l'année précédente ^[2] qui ont moins de compétences à la fois sur le plan technique et sur le domaine fonctionnel. Travailler en binôme ^[3] évite à un nouvel arrivant dans l'équipe d'être bloqué avec la peur de faire une bêtise. Comme le dit Kent Beck dans l'article, c'est déjà le moyen de faire partager les pratiques de l'équipe. Cela a été expérimenté les années précédentes. Avec succès sur la plupart des projets.

Sur le forum Scrum, un étudiant demande des commentaires sur sa thèse qui porte sur l'association de XP et Scrum. Il appelle ça xP@Scrum.
Il a manifestement beaucoup utilisé le copier-coller... Ron Jeffries s'en est vite aperçu.
En fait l'intégration de XP dans un cadre Scrum se pratique déjà. Sur des projets récents j'ai utilisé ou fait utiliser les techniques suivantes d'origine XP (sans parler de ce qui est commun aux 2) : user stories, estimation en groupe (planning game), remaniement (refactoring), développement dirigé par les tests (TDD) -la plus difficile à mettre en place-, binômage (pair programming).

Lors des derniers projets auxquels j'ai participé ou que j'ai coachés, les exigences ont été définies par des "user stories".

Lire la suite -->