Une définition de TERMINE

get_it_doneSe mettre d’accord sur la définition de TERMINE (ou DONE) prend parfois beaucoup de temps à l’équipe et est souvent sujet à moult discussions si l’équipe n’a pas encore la maturité nécessaire dans sa pratique de l’agilité.

Cette démarche est pourtant ESSENTIELLE dans la vie du projet et contribue fortement au succès, ou échec, de l’utilisation d’une méthode Agile. Pour ceux qui auraient des difficultés à s’accorder sur la définition de TERMINE, je vous recommande d’écouter les conseils de Scott Downey (Coach Agile chez MySpace)

Continuer la lecture de « Une définition de TERMINE »

Scrum Master Changeant

yahoo-2Une pratique plutôt innovante de l’équipe Yahoo sur la photo est la mise en place d’un Scrum Master changeant.

Sur ce projet, le Product Owner est aux US et les 4 personnes de l’équipe technique sont basées à Grenoble. Une des particularités de l’équipe technique est que chacune des 4 personnes est capable de contribuer à la réalisation des items du Product Backlog car ils disposent tous de compétences techniques utiles pour le projet et qu’ils souhaitent d’ailleurs mettre en œuvre.

Continuer la lecture de « Scrum Master Changeant »

Quel outil pour Scrum ?

toolboxDe nombreuses équipes et entreprises se posent  la question de l’outil qui leur permettra de gérer efficacement leurs projets en mode Scrum. Il en existe beaucoup avec des caractéristiques très différentes : Payant ou Gratuit, Distant ou Local, Paramétrable, Type d’OS … mais il est relativement fastidieux de faire toutes les recherches sur le Web.

Continuer la lecture de « Quel outil pour Scrum ? »

Tests et Agilité

Lorsque l’on vous parle d’équipe de test ou de QA, cela vous évoque-t-il des personnes essayant de faire planter le logiciel réalisé pour démontrer à l’équipe de développement qu’elle s’est trompée ?

Si c’est le cas vous êtes dans l’erreur et il serait bon que vous réfléchissiez encore à la situation.

Dans notre culture, le rôle du testeur est généralement dévalué par rapport à celui du développeur (parfois même au niveau du salaire), et pour certains développeurs, le développement de tests est considéré comme une tâche subalterne n’ayant aucun aspect « noble ».

Continuer la lecture de « Tests et Agilité »

Poker Planning

dog-pointLe « poker planning » est une pratique Scrum qui permet d’évaluer la complexité d’un item du product backlog.

Il s’agit de réunir l’équipe de réalisation, le Product Owner et le Scrum Master dans une même salle et de leur donner à chacun un jeu de cartes contenant habituellement les chiffres suivants : 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 (vous aurez surement l’occasion de récupérer un jeu de cartes donné gracieusement par un sponsor lors d’une prochaine conférence Agile). Continuer la lecture de « Poker Planning »

Scrum User Group en Français

french-sugLe French SUG est décidément fort en communication – Merci à Cédric pour le lien – puisque voici un article du Monde Informatique fraichement paru :  Méthodes agiles : les utilisateurs français de Scrum se fédèrent.

Nous sommes quelques « provinciaux » à avoir accepté d’être les contacts privilégiés en région afin de relayer localement cette dynamique nationale en complément d’autres initiatives déjà en place, et cela fait toujours plaisir d’être nommé dans un article du LMI. Continuer la lecture de « Scrum User Group en Français »

Formation Scrum sur Grenoble

Juste un petit mot pour féliciter le CARA (Club Agile Rhône Alpes) de co-organiser la première formation Certifiante Scrum Master sur Grenoble les 12 et 13 février prochains, formation qui sera animée par François Beauregard de la société Pyxis (informations et inscription disponibles en ligne)

Une opportunité pour chacun d’entre vous de devenir un Scrum Master reconnu par la Scrum Alliance … restera ensuite à pratiquer … car rien ne remplace la pratique 🙂

Gestion des Risques : Les risques Business

Hier, alors que je faisais une présentation de la méthode Scrum, nous avons eu une discussion plutôt intéressante sur la gestion des risques en méthode Scrum comparé aux méthodes de gestion de projet traditionnelle et voici ce qu’il en est ressorti.

Pour un produit donné, il existe 2 grandes classes de risques:

  • Les risques Business (traités dans cet article)
  • Les risques Techniques (futur article)

Continuer la lecture de « Gestion des Risques : Les risques Business »

Estimation des tâches

S’il y a consensus pour ce qui est d’estimer les « User Story » en « Story Points » et non en jours ou heures (Cf. dernier article de Claude Aubry et les très bons livres de Mike Cohn), il semble que le chiffrage des tâches issues de la planification des User Story ouvre la porte à quelques discussions.

En résumé, et désolé pour cette simplification extrême, il y a 2 grandes façons de chiffrer les tâches:

Du bon usage de la vélocité

J’ai eu une discussion animée hier avec un ami qui cherche à convaincre une société de basculer dans une mode agile. Le point sur lequel nous avons loguement discuté était l’utilisation de la vélocité comme une mesure de performance de l’équipe et comme critère de maintient en poste ou pas d’une équipe de sous-traitants.

De mon point de vue, la vélocité est une mesure de capacité de production qui est lié à une équipe et une seule dans le contexte spécifique d’un projet. Au grand damme des managers classiques, il n’est malheureusement pas possible de comparer les vélocités entre équipes pour savoir si l’une est meilleure que l’autre et si un sous-traitant travaille mieux qu’un autre.

Lorsque la vélocité est calculée, et je recommande fortement de le faire, je l’utilise principalement de 3 façons différentes (liste non exhaustive bien entendu) : Continuer la lecture de « Du bon usage de la vélocité »