Posts Tagged ‘Scrum’

Mon Release Plan est physique !

14/09/2011

Le projet Marguerite, le projet chardon, etc … Tous ces projets composent notre Système d’information. La plus grande contrainte dans le développement d’un S.I tient au fait qu’il n’existe pas de date de fin à la création du S.I. L’agilité nous propose différents outils permettant de revoir régulièrement nos priorités facilement, ce qui a été une révolution ! Il est cependant important pour l’équipe, le P.O mais aussi les stackholders d’avoir régulièrement une « vision » des prochaines étapes : le Release Plan.

Quel outil ? Comment construire / échanger / travailler cette définition du produit sur les mois à venir ?

L’idée toute simple m’a été soufflée par Jean Claude GROSJEAN, dans un article lu il y a quelques mois concerant son backlog D.E.E.P et physique.

(suite…)

L’expérience Pré-Mortem

4/07/2011

Nous venons de démarrer ce matin le dernier Sprint de la release 1 du projet Marguerite. Je voulais organiser un jeu/évènement afin que l’équipe reste focalisée sur la qualité du produit et qu’elle réflechisse à la gestion des risques. Ayant découvert récemment le jeu « Remember the Future« , je voulais organiser un jeu placant l’équipe 1 semaine après une mise en production « ratée » de notre produit et que l’on cherche les causes de cet échec.

Je partage cette idée avec notre « Super P.O » qui trouve cette approche « anxiogène » à quelques jours d’un évenement important. Je repars un peu frustré. Quelques jours plus tard, je tombe sur Alex qui se promenait dans notre entreprise et je lui raconte cette histoire.

Moi : « Ben, euh, il parait que c’est anxiogène comme idée, t’en penses quoi »

Alex : « Faut pas faire un Remember the Future, mais un Pré-Mortem ! »

 

(suite…)

Jouez avec la « definition of done »

25/05/2011

Validation fonctionnelleLors 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 :

Pour vous, est-ce que la validation fonctionnelle (par le P.O) doit être dans la "definition of done" ?

  • Oui (73%, 16 Votes)
  • Non (23%, 5 Votes)
  • Ca dépend : Cette réponse est réservée à Alex :) (4%, 1 Votes)

Total Voters: 22

Loading ... Loading ...

Fin du jeu Dimanche 29 à 23h59 :)

Scrum et le management

8/05/2011
Baleine et banc de poissons

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…)

Projet Marguerite : Comment aider un (nouveau) P.O à prioriser un backlog ?

13/04/2011


Lors du dernier Sprint du projet Marguerite, l’équipe avait l’impression de ne travailler que sur des User-Story peu importantes (d’un point de vue métier), pour ne pas dire cosmétique. Elle avait l’impression d’avoir perdu la « vision » du produit et ne comprenait plus les priorité métier.

En tant que ScrumMaster

Je veux que l’équipe projet ait le sentiment de produire de la valeur métier dans un logiciel utile

Afin que l’équipe reste mobilisée sur le projet !

Je suis donc allé voir le P.O pour parler avec lui du Backlog (et du manque de compréhension qu’en avait l’équipe). (suite…)

Projet / Maintenance : Comment être agile ?

31/01/2011

BalanceLe projet marguerite a commencé, mais nous devons toujours faire vivre le projet précédent : le projet Chardon (Oui, Marguerite et Chardon sont dans le même pré d’application :p) Comme son nom le sous-entend, le projet Chardon est un projet critique pour l’entreprise, mais c’est un aussi un projet épineux ;) Avec le P.O, nous nous sommes posés la question suivante : Le projet Marguerite va nous occuper pendant plusieurs mois. Il ne nous parait pas possible de ne rien livrer pendant cette période sur le projet Chardon : son Backlog contient une centaine d’item, certaines importantes d’un point de vue business ! Alors comment s’organiser ? (suite…)

Ca Scrum sur Twitter !

24/01/2011

Ca Scrum ! va essayer d’être moderne. On va pouvoir piailler en utilisant les outils à la mode. Pour moi, ce sera une découverte … Il n’est jamais trop tard ;) http://twitter.com/cascrum

Projet Marguerite : Fin du Sprint 0

21/01/2011

Aujourd’hui se termine le Sprint 0. (Durée du Sprint 1 semaine).

Quel était l’engagement de ce Sprint ? Obtenir 7 MindMap décrivant le projet Marguerite.

Quels étaient les critères d’acceptation ? Chaque MindMap devait être numérisé pour être projetable lors de la démo (ce matin) et imprimable afin de le mettre au mur pendant quelques jours encore.

Qu’avons nous livré ? Seulement 5 des 6 MindMap répondaient aux critères d’acceptation (pourtant très très simples :p). (suite…)

Projet « Marguerite » : jour 1

17/01/2011

Aujourd’hui, nous avons commencé le projet « Marquerite ». Comme je l’ai expliqué, ce projet commence par une phase de rencontre de nos utilisateurs sur leur lieu de travail. Objectif : découvrir leur manière de travailler et leur utilisation de l’outil actuel.

Sur le fond, la journée s’est bien déroulée. La première équipe était dans les Hautes-Alpes et nous dans la Drôme. Pour certains développeurs qui travaillent avec nous depuis plusieurs années, c’était leur première rencontre avec les utilisateurs ! Il était plus que temps !! (suite…)

MindMap / Carte heuristique : faire emerger les besoins métier

17/01/2011

Pour le nouveau projet (en cours de démarrage), les équipes techniques et les équipes métier vont ensemble se déplacer à la rencontre des utilisateurs pour faire émerger les besoins. Pour synthétiser ce que les équipes auront découvert, nous allons utiliser une MindMap.  L’objectif est d’obtenir rapidement (et visuellement) un retour, un échange construit dans le partage ! Cette démarche est une évidence pour nous car elle reprend quelques éléments de l’agilité :

  • Toute l’équipe est acteur à tous les moments du projet. En effet, pourquoi se limiter à seulement 2-3 cerveaux (uniquement l’équipe métier) alors que l’équipe entière en possède 7 !
  • MindMap : un outil visuel ! Le management visuel existe dans les pratiques agiles sous différentes formes : DashBoard, Kanban, Burndownchart, post-it, … Le MindMap paraît alors comme une évidence pour présenter et structurer de l’information … Mais surtout la communiquer ! (suite…)

Scrum : Dépendance des concepts

12/01/2011

Au démarrage d’un nouveau projet, il est toujours bon de se rappeler les dépendances des différents concepts et l’ordre dans lequel il faut les appréhender.
Pour cela, voici le schéma que j’ai en tête :

Que signifie cette roue ? (suite…)

Quels outils ?

11/01/2011

Ahhhh, les outils ! Voilà LE sujet qui fait le plus souvent discuter ! Entre les « geek », prêts à tester tous les derniers outils en version béta et les frileux — on peut aussi dire « puriste » :) — ; on est sur d’avoir des discutions animées dans l’équipe !
Nous développons des applications web, avec une technologie J2EE.

Mais quels sont les outils qui nous aident à être agile ?
Pour ce qui est de la partie « Suivi de projet » (backlog, burndownchart et autres indicateurs) nous utilisons pour le moment un joli fichier Excel : simple, efficace.

Pour ce qui est de la partie intégration continue (et déploiement automatisé en recette et production), nous utilisons Hudson et des scripts Ant. Dans un prochain article, je détaillerai notre organisation, les difficultés et les solutions que nous avons trouvés ! (Nous avons réduit de 90 % le temps passé à la construction et l’installation des applications et sensiblement amélioré notre qualité de livraison).

Enfin, ce qui est une nouveauté dans nos équipes, nous faisons des tests automatisés ! Pour cela, nous utilisons JUnit et Selenium pour la gestion des tests automatisés. Là aussi, différents articles sont prévus. Il existe de nombreux très bons tuto pour « installer » Sélenium and co. En revanche, peu de retour d’expérience sur la rédaction (et le lien avec les User Stories), la maintenance et l’organisation des tests ! Je vais modestement essayer d’apporter ma contribution :)

Construction de l’équipe

11/01/2011

EquipeLa construction d’une équipe est, pour moi, l’un des moments les plus intéressant mais aussi l’un des plus critiques.  J’ai toujours pensé qu’il y avait plus de chance qu’une équipe arrive à produire du logiciel si l’équipe « fonctionne » bien (même si elle manque de compétence) plutôt qu’une équipe d’expert ou de Geek mais qui sont incapables de travailler ensemble.

Dans notre entreprise, nous avions jusque là 2 équipes : une équipes MOE (une dizaine d’informaticien répartis sur différents projets) et une équipe MOA (5 experts métiers, eux aussi sur différents projet). Comment s’organiser lorsque l’on met Scrum en place ? Comment faciliter la transition ? Parmi les experts métier, un seul Product Owner (Facilement identifié, c’est déjà une très bonne nouvelle !). Mais que deviennent les autres membres de l’équipes ? Pour cela, j’ai proposé que l’on considère les anciens membres de la MOA comme des membre de la Team ! Certes, ils sont un peu spécialisés (ce qui est une entorse à Scrum, ce sera la seule). (suite…)

Pourquoi ce blog ?

20/12/2010

Pourquoi ce blog ?

Je suis ScrumMaster dans une entreprise « Client Final », c’est à dire que nous réalisons nous même les développements logiciel nécessaires à notre activité.

Lorsque j’ai commencé à m’intéresser à Scrum, j’ai tout de suite cherché des « retours d’expérience » de ScrumMaster qui n’avait rien à vendre ! J’ai rapidement trouvé le blog de Frédéric DOILLON que j’ai dévoré avec gourmandise.

Janvier 2011 : nouvelle année, nouvelle équipe et nouveau projet ! Je vais donc essayer, pendant quelques mois, de mettre à jour ce blog le plus régulièrement possible. 2 objectifs : Si je peux fournir une lecture agréable à de nouveaux / futurs ScrumMaster, je serai évidemment ravi ! Mais mon objectif principal reste de me fournir un outil me permettant de prendre du recul et de garder une trace du fonctionnement de Scrum sur un projet : du début à la fin :)