J’ai participé pour ayeba à la présentation de StarAfrica.com pour la chaine Orange-Innovation.tv ! Une description de la démarche agile retenue pour développer le site dans un temps très court et pour continuer à l’enrichir dans l’avenir ! Merci encore à cette excellente équipe !

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/

Le FLOSS, l’OpenSource, le logiciel libre… Un truc de geek, de techos, de chevelus… Cette image est bien sur erronée et les Directeurs des Systèmes d’Information qui ont adoptés des solutions sous licences libres se sont également fait les farouches partisants d’un modèle qui leur permet de reprendre la maîtrise de leur système d’information.

Et d’ailleurs, lorsque l’on lit quel est le public attendu lors du forum mondial du libre qui se tiendra à Paris, les 1er et 2 octobre 2009, il n’y a pas de doute possible : ”

L’Open World Forum est au croisement des diverses communautés qui composent l’univers du Libre. Il est destiné à tous les acteurs et décideurs de l’Open Source : des membres des communauté aux responsables politiques, en passant par les dirigeants d’entreprises, les chercheurs et les universitaires. Lieu de rencontre, il permet à toutes les parties prenantes de se rencontrer et favorise le lancement de nouvelles initiatives. Rendez-vous international, il donne de la visibilité aux acteurs, aux technologies et aux nouvelles tendances. Il offre ainsi un lieu idéal pour faire des annonces et dévoiler de nouveaux projets. Avec un large éventail de conférences et d’ateliers, qui couvrent tout le spectre, de la stratégie aux technologies et aux tendances sociétales, l’Open World Forum s’adresse ainsi :

• Aux décideurs
• Aux investisseurs
• Aux responsables informatiques et architectes
• Aux chercheurs et universitaires
• Aux experts technologiques

Mais alors, que sont-ils devenus ces hommes (au sens large, quoique lors de certains rassemblements… je me demande ) qui ont fait le succès de ce mode de diffusion et d’enrichissement des meilleures solutions logicielles ? Comment leurs méthodes, leurs organisations se sont diffusés ? De quelles approches se sont-elles inspirées ?

La conférence “Le facteur humain… au coeur de l’industrie du logiciel libre” abordera ces différents sujets :

• Lean, agilité et organisation cellulaire – Alexis Monville – Confirmé
• Collective Intelligence – JF Noubel – Confirmé
• Andi Gutmans – CEO, Zend – à confirmer
• Florence Devouard – former Chair of the Board of Trustees of the Wikimedia Foundation (2006-2008) – à confirmer
• Marie Vorgan le Barzic – Silicon Sentier / la cantine
• Table-ronde : Entreprises et communautés : Xavier Boileau – Generali (Confirmé), Emmanuel Faber – Danone Communities (à confirmer), Christophe Aguiton – Orange Labs (à confirmer) – Olivier Réaud – In Principo (Confirmé)
• Laurent Bouffies – Blue Child Foundation – confirmé
• Echanges avec la salle

Rendez-vous le 2 octobre de 14h à 16h à l’Open World Forum !

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é

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

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 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.

Cette conférence est organisée par l’association Drupal (http://association.drupal.org).

Le programme est conçu pour intéresser les initiés et les néophytes, les programmeurs, les designers, les managers… etc… qui trouveront tous une réponse aux questions qu’ils peuvent se poser sur cette solution qui va bien au-delà du CMS !

Au plaisir de vous voir la-bas !

Quelles sont ces 5 stratégies pour que votre projet ne fasse pas parti des 2/3 de projets qui vont échouer ?

1- Répondre aux besoins métiers : En engageant une véritable conversation avec les métiers pour y chercher les orientations pour le programme d’actions IT.

2- Innover : En travaillant main dans la main avec les métiers, il faut savoir être prêt à accepter le changement, et adopter une culture d’amélioration continue.

3- Être honnête : Accepter ses faiblesses pour pouvoir mener des actions correctives. Le déni est la marque de fabrique des échecs.

4- Aligner les fournisseurs : Les projets informatique mettent en scène trois catégories d’acteurs, les clients, les fournisseurs de technologies et les sociétés de services. Leurs feuilles de route sont probablement divergentes, assurez-vous de mettre en place les relations qui vous permettront de maintenir vos fournisseurs dans le sens de votre projet.

5- Avoir un sponsor : Avoir un sponsor passionné par les résultats du projet, positionné au top de la hiérarchie.

Il me semble que tout le monde verra facilement l’intérêt de ces 5 stratégies… La question qui subsiste (et qui n’est pas traité dans l’article original) est bien sur : “Comment mettre en œuvre ces stratégies pour mon projet ?” et pour cela je suis prêt à vous aider ! (oui c’est de la pub )

Je vous recommande bien sur de lire la suite de celle représentée ci-contre, et toutes les illustrations du mercredi !