Quelles histoires !

user-storyCe ne sont que des histoires ! De toutes petites histoires, qui pourtant vont permettre de faire de grandes choses ! Je parle de « User Stories », et je ne suis pas le seul à m’interroger (depuis un certain temps déjà) sur la traduction adéquate de ces histoires d’utilisateurs [ Comment traduire User Story en français ? et Des histoires d’utilisateurs].

Scénario idéal (qui se renouvelle en ce moment pour mon plus grand plaisir !) : Un client appelle ayeba, il veut sortir un nouveau site Internet dans 5 mois, il commence à avoir une bonne idée de ce qu’il veut, il a eu le « go » pour le budget avec un peu de retard, le cahier des charges n’est pas encore commencé… Et… Cela commence a être un peu serré en terme de délai pour pouvoir profiter du prochain évènement idéal pour le lancement du site…

Après analyse, c’est tout à fait faisable en méthode classique (waterfall) : 1 mois pour le cahier des charges, quelques propositions de prestataires, sélection, un peu de temps de validation interne, 1 mois pour faire des spécifications, un peu de temps de validation, on attaque le développement, réception du développement, mise en production… et GO, c’est lancé ! Si tout se passe bien alors cela devrait marcher… Humm… Même mon client, me fait remarquer que le dernier mois… eh bien… il faudra gérer la crise…

En regardant de plus près, les personnes qui me présentent le projet lors de la réunion de lancement ne me parlent pas exactement du même projet… Ils n’emploient pas les mêmes mots, n’ont pas exactement les mêmes références sur Internet… La rédaction d’un cahier des charges avec une approche classique risque fortement de conduire à des déceptions de certains des acteurs du projet (avant même d’avoir commencé) et peut-être même de tous lorsque le développement sera engagé, ou terminé, et qu’ils ne pourront plus modifier leur demande initiale…

L’approche « user story » : « en tant qu’utilisateur, je veux … ainsi j’obtiens… » va permettre de faire converger l’équipe client vers le même projet, de tirer partie de toutes les idées… Et bien sur d’obtenir des propositions des prestataires plus ajustées au besoin réel. Chaque histoire, indépendante des autres, peut-être priorisée en fonction du bénéfice que l’utilisateur va en tirer et ainsi déterminer plus facilement un plan de sortie général des prochaines livraisons du site, avec en premier ce qu’il faut, puis ce qu’il faudrait, puis ce que l’on pourrait avoir… et évitant de passer du temps sur ce qu’il n’est pas nécessaire d’avoir cette fois.

La suite ? Je vous la raconte bientôt !

En attendant je vous recommande la lecture de : User Stories Applied et/ou Agile Estimating and Planning de Mike Cohn pour débuter dans l’utilisation de petites histoires qui vous feront réussir à avoir un bon produit.

Publié sur ayeba.fr : http://ayeba.fr/2009/08/16/user-story-stories-quelles-histoires/

Dans la Dèche au Royaume Enchanté

Dans la Dèche au Royaume Enchanté est une livre de Cory Doctorow (boingboing). Ce roman m’a été recommandé par Julien Dorra lors d’une soirée des Explorateurs Du Web consacrée au monnaies complémentaires. Pour cela un très grand merci !

Le livre est sorti depuis longtemps, aussi je me bornerais à vous dire : « lisez le et vous comprendrez la puissance des monnaies complémentaires dites d’appréciation et vous aurez vous aussi envie de les adopter ! ».

Une anecdote malgré tout, la description en une page de l’intérêt de dépasser l’approche classique des projets (cascade, cycle en V) pour aller vers l’agilité est excellente ! La voici en anglais :

“Okay, so tell me, if we came to you with this plan and asked you to pull together a production schedule—one that didn’t have any review, just take the idea and run with it—and then pull it off, how long would it take you to execute it?”
Lil smiled primly. She’d dealt with Imagineering before.
“About five years,” he said, almost instantly.
“Five years?” I squawked. “Why five years? Debra’s people overhauled the Hall in a month!”
“Oh, wait,” he said. “No review at all?”
“No review. Just come up with the best way you can to do this, and do it. And we can provide you with unlimited, skilled labor, three shifts around the clock.”
He rolled his eyes back and ticked off days on his fingers while muttering under his breath. He was a tall, thin man with a shock of curly dark hair that he smoothed unconsciously with surprisingly stubby fingers while he thought.
“About eight weeks,” he said. “Barring accidents, assuming off-the-shelf parts, unlimited labor, capable management, material availability . . .”
He trailed off again, and his short fingers waggled as he pulled up a HUD and started making a list.
“Wait,” Lil said, alarmed. “How do you get from five years to eight weeks?”
Now it was my turn to smirk. I’d seen how Imagineering worked when they were on their own, building prototypes and conceptual mockups—I knew that the real bottleneck was the constant review and revisions, the ever-fluctuating groupmind consensus of the ad-hoc that commissioned their work.
Suneep looked sheepish. “Well, if all I have to do is satisfy myself that my plans are good and my buildings won’t fall down, I can make it happen very fast. Of course, my plans aren’t perfect. Sometimes, I’ll be halfway through a project when someone suggests a new flourish or approach that makes the whole thing immeasurably better. Then it’s back to the drawing board . . . So I stay at the drawing board for a long time at the start, get feedback from other Imagineers, from the ad-hocs, from focus groups and the Net. Then we do reviews at every stage of construction, check to see if anyone has had a great idea we haven’t thought of and incorporate it, sometimes rolling back the work.
“It’s slow, but it works.”
Lil was flustered. “But if you can do a complete revision in eight weeks, why not just finish it, then plan another revision, do that one in eight weeks, and so on? Why take five years before anyone can ride the thing?”
“Because that’s how it’s done,” I said to Lil. “But that’s not how it has to be done. That’s how we’ll save the Mansion.”

La source est ici : http://craphound.com/down/download.php

En français et en poche, c’est ici : Dans la Dèche au Royaume Enchanté

Pour retrouver le goût du développement

Pour retrouver le goût du développement, c’est le sous-titre du dossier consacré au développement agile par le mensuel PROgrammez ! pour son numéro de juin 2009.

Implication de l’équipe, amélioration de la qualité des produits, amélioration de la satisfaction des utilisateurs, limitation des développements aux fonctionnalités utiles, choix des méthodes (avec évidement un passage par SCRUM et XP), le récit d’une journée d’un développeur agile,  les pratiques issues du LEAN, l’adoption de l’agilité dans les équipes habituées aux approches classiques, passez à l’agile en cours de projet… sont les thèmes abordés dans ce dossier très complet qui a permi aux experts de quelques sociétés de s’exprimer sur l’agilité.

Un numéro que je vous recommande (un peu tard, le numéro de juillet est déjà sorti) mais que vous pouvez trouver en pdf sur le site du magazine : http://www.programmez.com/magazine_articles.php?titre=Le-developpeur-devient-AGILE&id_article=1232&magazine=120

Scrumy

scrumyScrumy est une outil en ligne permettant de représenter le tableau et les post-it typiques d’un projet piloté avec une méthode agile (comme SCRUM).

En trois minutes pour jouer cela donne cela : http://scrumy.com/ayeba

Evidement, il y a une version PRO qui fait tout… Et que je n’ai pas testé… Si quelqu’un à un retour cela m’intéresse !

Une soirée agile avec le French Scrum User Group

Pour sa deuxième réunion, le groupe des utilisateurs français de SCRUM (le French Scrum User Group) avait choisi d’organiser un WorldCafé dans les locaux de l’EPITA.

Une quarantaine de participants pour cette soirée en deux parties.

Une première partie de restitution de l’enquête sur l’utilisation des méthodes agiles (vous pouvez consulter le questionnaire ici) dont les résultats seront publiés prochainement. Si les données statistiques ne sont probablement pas représentatives des entreprises dans leur totalité, les motivations pour aller vers l’agile et les difficultés sont des données qualitatives intéressantes. Au chapitre motivations pour aller vers l’agile, on trouve dans l’ordre : les possibilités d’intégrer le changement, la réduction des délais et des livraisons plus fréquentes, l’amélioration de la qualité, la motivation d’équipes. Pour les difficultés : les interactions avec d’autres entités de l’organisation, l’implication du management, les estimations et le planning, l’identification du Product Owner (tout en anglais…).

La deuxième partie était donc un WorldCafe consacré à SCRUM. Pour les familiers du BarCamp, le format est ressemblant avec des plus et des moins…

Contrairement à un BarCamp, nous n’avons pas fait de session de présentation « en trois tags » et c’est bien dommage… (chacun se présente par son nom suivi de trois mots en guise d’introduction)

La session de définition des sujets et leurs sélections est légèrement différente, puisqu’il y a eu tout d’abord proposition par la salle d’une quinzaine de sujets puis vote pour conserver les 4 sujets qui seraient abordés par quatre tables : Mieux que SCRUM ?, Contractualisation et SCRUM, Self-Organised Team et pour terminer Product Owner.

Sur chaque table une nappe en papier, des stylos pour écrire directement sur la nappe (et des petites choses à grignotées qui étaient bienvenues vu l’heure !) et trois-quart d’heure pour échanger sur le sujet.

Lors de la restitution à l’ensemble du groupe, on affiche la nappe au mur, un des groupes avait d’ailleurs dessiné une MindMap, pratique qui pourrait être suggérée pour les prochains événements (et reprise dans les barcamps ?). Les retours des différents groupes montraient des pratiques assez différentes de SCRUM et en particulier des rôles.

Une solution à la crise ?

Un petit quizz pour l’été proposé par l’excellente équipe de la société In Principo !

L’intelligence collaborative, solution à la crise ?

Bonnes vacances à tous !