Pour cette conférence sur Scrum, c'est Claude Aubry qui vient nous en
parler. Claude Aubry est consultant Scrum et méthodes agiles, enseignant
en méthodes agiles à Toulouse; et aussi "product owner" de IceScrum, un
outil scrum open source. Il est l'auteur de
"SCRUM : Le guide pratique de la méthode agile la plus populaire" dont 2
exemplaires seront à gagner.
C'est ensuite au tout de Paul el Khoury, chercheur en sécurité chez SAP.
3 croyances erronées à propos de 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 lourds
-
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.
