Sophiaconf 2010 - Scrum

Qu'est ce que Scrum ?

L'approche scrum préconise de faire un backlog, c'est à dire de lister des choses faire, chacunes d'entre elles ont une priorité et une difficulté. Dans les estimations que l'on fera, nous ne les exprimerons pas en jour homme mais en points. Une pratique scrum possible de cette estimation est le planning poker.
En scrum, au centre, il y l'équipe. Dans cette équipe, 2 rôles spéciaux sont définis :

• Scrum master, personne qui fait appliquer Scrum. Ce n'est pas un nouveau nom pour un chef de projet, le role et différent
• product owner qui est le repésesentant du client.

Intéressons nous à la signification se Scrum. Scrum signifie mélée, au même sens qu'au rugby.
Pourquoi donc ? L'origine du terme vient d'un article écrit pas un japonaus qui disait que le développement de système complexe ressemble plus à une effort collectif qu'à une course de témoin.
Sprint = période de temps, c'est un équivalent à un partie du backlog et va le transformer en produit.
Le backlog est une boite de temps qui ne déborde pas. En scrum, on ne déborde pas sur le planning, la date de fin de sprint ne se réajuste pas.
Chaque sprint se déroule de la même façon, il a son cérémonial.
On commence par une réunion de backlog, qui consiste à identifier ce qui sera réalisé pendant le sprint. C'est la réunion la plus longue de l'itération.
Il y aussi la réunion quotidienne, appelée "Scrum meeting". Son objectif est d'être rapide, c'est pourquoi elle est faite debout (à la machine à café par exemple). On y suit l'avancement du sprint, ce qui permet de suit l'avancement, voir si l'équipe est en avance ou en retard (avec éventuellement une révision du backlog), identifier les problèmes.
Une des dernière réunion est celle de démo, ou on démontre ce qui à été réalisé.

Et pour finir, une réunion de rétrospective, elle sert à analyser le sprint et d'en tirer des conclusions afin d'améliorer la façon de travailler.

IceScrum, un outil pour faire du Scrum

Claude, nous fait maintenant, un présentation de IceScrum. En sa qualité d'enseignant en méthodes agiles, il suit ce projet réalisé par des étudiants de Toulouse.

Petit historique des versions :

• 2006 : Client lourd
• 2008 : Passé en JavaEE, Ajax avec IceFaces
• 2010 (en cours) : grails + jquery

Site communautaire et professionnel : www.icescrum.org et www.icescrum.com

IceScrum est téléchargeable et installable sur un tomcat ou un glassfish.

Il reproduit un environnement de travail Scrum avec :

• Systeme de post it
• Définition de stories
• Planning poker
• Roadmap
• ...

Retours d'expérience

Scrum a l'air d'être un méthodogie interessante en théorie, mais qu'en est il en pratique ?
Bertrand Gorge de Epsitema, un éditeur logiciel, vient nous parler de la mise en application de Scrum dans leur société. Il annonce la couleur : scrum leur a sauvé la vie !!!
Pourquoi donc ?
Ils n'étaient pas très organisés et rencontraient des difficultés façe à une croissance rapide de leurs effectifs. C'est un client qui leur a conseillé Scrum. Ils ont lu le livre, "Scrum and XP from the trenches", qui les a convaincu. Scrum leur a semblé adapté, ils ont testé et gardé.
Qu'est ce qui est important dans Scrum ?

• Le daily scrum : "sans lui, ça part en couille", évite la procrastination car les problèmes que rencontre un développeur peuvent y être connus.
• La démo finale : Sans elle, le développement risque de ne jamais être terminé ou que ça ne corresponde pas. Eux ils en font en chaque fin de story. Quand un développeur a fini, il envoie un mail à l'équipe, et les interessés peuvent venir voir; le product owner bien sûr sera toujours là. La notion de terminé n'est pas la même pour un client et un développeur, c'est pour celà qu'ils ont une checklist à vérifier lors de la démonstration.
• Le how-to demo, c'est la spécification. Le développement est est termininé quand le développeur fait passer le how-to demo
• Sprint planning meeting, il sert à valider avec les développeur le contenu de chacune des stories. Le développeur peut interragir sur le how-to demo. Durant cette réunion, on pratique le planning poker qui sert à estimer.
• DOD (Definition Of Done). Sur le scrum board, en plus de : A faire, En cours, Fini; ils ont rajouté une colonne : Vraiment fini. C'est en effet, lors de la démonstration qu'on se le développeur se rend compte :d'un oublie.

Scrum est un processus d'amélioration, si on s'est trompé, on apprends de ses erreurs.

Les erreurs qu'ils ont commis :

• Mélanger maintenance et développement : pas facile à gérer, plusieurs solutions
• Ne pas faire de taches et uniquements des stories, ils n'avaient que des stories. Le découpage en tache permet se rendre compte d'éventuels oublis.
• Splitter une équipe sur le même projet, les daily scrum devenaient longs, ils avaient découpé mais ça marche pas très bien. Solution : équipe plus petite.
• Démarrer un développement sans how-to démo : on est tenté lorsque qu'on n'a pas les infos. Il faut résister et ne jamais commencer les développements quand on a pas de how-to demo
• Ne pas faire de dalily scrum. Parfois, ils n'en faisaient pas car le Scrum master était absent, ou tout le monde n'arrive pas à la même heure, ... Et au final, ce n'est pas bon.

Ce que a changé pour eux;

• Augmentation de la productivité
• Satisfaction des clients et de l'équipe
• meilleur prédictibilité des efforts : ils ont essayé plusieurs logiciels, leur préférence est pour excel pour estimer la velocité.

C'est ensuite au tout de Paul el Khoury, chercheur en sécurité chez SAP.
Dans leur équipe, il y a : 1 scrum master, 2 product owner et 11 team member.
Leur environement est particulier dans la mesure où il s'agit de projets de consultations, et ilsarrive que leur besoin change.
Ils ont indroduit une notion de "timeblock" qui est en durée sur laquelle ils sont sur une tâche importante et ne peuvent faire autre chose. Une autre particularité est que leur équipe est divisée entre la France et l'Allemagne. Au début, ils utilisaient le téléphone pour leur réunion, mais ce n'était pas pratique, on ne sait pas vraiment qui parle ni à qui il parle. C'est pourquoi, ils ont opté pour les visio-conf. Cependant, pour planning meeting tout le monde se rencontre physiquement.
Leur projet est divisé en 2 sous projet (d'où leur 2 product owner). Leur daily scrum se fait à 11h15. Cette horaire peut sembler étrange, mais il semble que c'est pour avoir un effet psychologique : les gens seraient apparement plus concentrés que si elle avaient lieu à 11h.
Scrum leur a appris à se focaliser au jour le jour. Après 9 mois de pratique, ils ont beaucoup appris. Selon eux, les projets de consultations ne sont pas les meilleurs endroits pour utiliser Scrum.

L'intelligence situationnelle
Et pour finir, cette conférence, Claude Aubry revient nous parler de l'intelligence situationnelle.
C'est un terme qui vient de Pierre Villepreux, ancien joueur de rugby. Claude nous montre un extrait du texte, il suffit de remplacer "joueur" par "développeur" et c'est tout à fait dans l'esprit de l'agilité.

3 croyances erronées à propos de Scrum :

• "Par ce que nous disons être agiles, nous le sommes". Beaucoup d'équipes prétendent être agile, en grattant un peu, on voit qu'elle ne sont pas vraiment.
• "Vous pouvez être agile en faisant comme nous". ce n'est pas parce que ça marche que ici que ça marchera là bas, ça dépend du contexte.
• "Nous voudions être agile mais ce n'est pas possible". C'est certainement plus difficile à certains endroits, mais ça reste toujours possible

Une liste de pratiques existe-elles ?

Pas vraiment, cependant, il existe certaines pratiques indispensables de Scrum.

Comment faire ?

En fonction du contexte, il faut identifier les pratiques et définir comment les mettre en oeuvre, il faut étudier la situation.

Quelques exemples :

• Gouvernance forte : Il est important de sensibiliser l'environnement (manager, client, ... ) sur la façon dont on va travailler. Il peut aussi être utile de faire du reporting supplémentaire pour coller à certaines pratique du process. Attention cependant, à ne pas faire un retour au cycle en V.
• Le multiprojet : Quand certaines personnes travaillent sur plusieurs projet avec différents client. Scrum nous dit qu'on ne doit pas perturber un sprint. Il serait donc possible de faire des sprint plus court et de voir comment s'adapter pour traiter les urgences.
• Distribution géographique : 60% des développements logiciels se font avec des équipes réparties. Dans ce cas, la vidéo conf peut être une solution
• Forfait : Comment gérer le problème du product owner ? On peut par exemple, faire des mise en place spéciale et prévoir de voir fréquement le client.
• Gros projet : comment diviser les équipes ? On peut par exemple mettre un product owner général et un scrum master par sous projet.

C'est à chaque organisation se trouver en tenant compte du contexte et en s'améliorant. Il leur faudra acquérir une culture de l'agile, connaitre le contexte, adapter les pratiques de ce contexte, former l'équipe à ces pratiques, les mettre en oeuvre, ajouster à chaques sprint.
Il ne faut pas croire qu'il y ait un processus agile ultime. Il y a toujours les choses à améliorer. Si tout va bien, c'est louche.
Si on ne fait pas attention à la qualité logicielle, elle se dégrade, il faut la surveiller dans chaque sprint.
On en peut pas appliquer scrum sans tenir compte du compte. La plupart des pratiques sont utiles, mais ne s'appliquent as de la même façon partout.
Le développement logiciel n'est pas de la production comme dans un usine. On a besoin d'apprendre des choses. Dans les méthodes agiles, on considère qu'il est important de connaitre le coté métier de ce que l'on développe et qu'il faut savoir se former aux nouvelles technos.