Ca Scrum !

Lors d’un moment d’échange entre équipes agiles, nous avons eu de vives discussions sur « les tests fonctionnels ».

D’un côté, certaines équipes prônaient la validation fonctionnelle dans la définition du terminé. Cela pouvait se faire de plusieurs manières :

1 – Par délégation : La User Story est claire pour l’équipe, le P.O partage ce sentiment et les critères d’acceptation sont écris et non ambigus. La « simple » écriture d’un scénario avec Sélénium servira de validation fonctionnelle.

2 – Par participation : Le P.O est sollicité pendant le Sprint afin de validé la Story.

3 - Par la démo : Le P.O valide pendant la démo.  :)

Dans tous les cas, il s’agit de validation et non de remise en question de la fonctionnalité. Si le besoin change, on laisse tomber la fonctionnalité : elle ne sera pas produite (terminée) lors du Sprint et le P.O pourra de nouveau la présenter lors du prochain SPM.

De l’autre côté, d’autres équipes prônaient la validation fonctionnelle en dehors du Sprint. Le principe est le suivant :

1. La User Story est développée lors du Sprint X : elle est présentée au P.O lors de la démo.
2. Le P.O prend le temps de la valider pendant le Sprint X+1.
3. Si la Story ne « marche pas » ; alors il y aura une « Bug Story » lors du Sprint X+2. S’il faut la compléter ou modifier son fonctionnement, alors il y aura une nouvelle « User Story »

Ces 2 approches ont leurs avantages :

• Dans la première, la définition du « done » est claire : on peut mettre en production. Comme lu sur Twitter cette semaine :

@danielbrolund If « done » doesn’t mean 100%, « donedone » is less and « donedonedone » even less. Compare 0.99>0.99*0.99>0.99*0.99*0.99. :-)

• La deuxième solution a aussi son avantage : elle réduit la « pression » mise sur la validation fonctionnelle et permet à l’équipe d’avancer !

Je vous propose donc le jeu suivant :

 Loading ...

Fin du jeu Dimanche 29 à 23h59 :)

Lors de notre dernière rétrospective, nous avons pas mal discuté de la gestion des « incidents de production ». En effet, en tant que client final, nous développons nos outils mais nous devons aussi en assurer le bon fonctionnement, parfois en temps réel (on ne peut pas attendre le prochain Sprint pour résoudre un problème).

Dans ce genre de cas, toute l’équipe n’est pas forcement mobilisée sur la résolution de l’incident de production !

L’équipe a donc proposé d’investir dans un nouvel outil de visualisation : le gyrophare, et le fonctionnement suivant : lorsqu’un membre de l’équipe est informé d’un incident de production, il allume le gyrophare et TOUTE l’équipe se réunit afin d’identifier et de trouver au plus vite la meilleure solution au problème.

Il ne nous reste plus qu’à trouver une solution pour ne pas perturber les équipes voisines :)

Cela fait maintenant plusieurs mois que je voulais faire cet article sur la rédaction des tests selenium (et en plus, c’était plutôt bien noté dans mon backlog :p). J’espère que les commentaires seront nombreux !

Voici un exemple de scénario que l’on peut facilement générer avec Sélénium et son IDE. C’est déjà chouette ! On a largement de quoi repenser notre manière d’organiser les projets ; comme mettre en place du Développement Piloté par le Comportement (BDD).

Après quelques projets, quelques points négatifs demeurent :

1 – Peut-on dire que la lisibilité est suffisante ? Peut-on échanger avec un P.O ou des fonctionnels sur la pertinence de tel ou tel scénario ?

2 – Lorsque l’application évolue, il faut reprendre beaucoup de tests : il n’y a aucune factorisation du « code » des tests.

Je vous propose donc un exemple d’organisation des tests Selenium. Pour cela, je vous propose de « tester » la vente en ligne du site fnac.com (J’ai choisi ce site pour sa célébrité et sa « complexité » ergonomique) (suite…)

Baleine et banc de poissons

Lors de ma formation Scrum, j’ai retenu 2 éléments concernant Scrum et le management :

1 – Le ScumMaster n’est pas un chef de projet qui fait obéir son équipe au doigt et à l’oeil : il ne manage pas l’équipe mais le processus.

2 – Les rôles « utiles » pour le produit sont le P.O, le ScrumMaster et la Team (auto-gérée et possédant toutes les compétences nécessaires à la réussite du projet) : tout autre rôle est inutile à Scrum.

Durant cette première année de pratique de Scrum, j’ai tout de même eu quelques interrogations :

• En mettant en place un Niko-Niko, en « protégant » l’équipe, en l’incitant à mettre en oeuvre certaines pratique d’ingenierie (BDD, Pair programmning, …), en mettant en place des entretiens OneOnOne, ne suis-je pas entrain de faire du management d’équipe  ?
• Mon manager, son manager, les autres services ainsi que la direction générale, même s’ils ont compris notre mutation vers l’agilité, fonctionnent toujours de manière traditionnelle. Et pourtant, la communication doit avoir lieu entre « eux » et « nous ». Quelle type de relation dois-je mettre en oeuvre entre mon management hiérarchique (ainsi que celui de l’équipe) ? Est-il possible d’aller plus loin et d’envisager une entreprise agile ? (suite…)