Manage it!

Manage it! est un livre de Johanna Rothman édité chez Pragmatic Programmers. Vous connaissez sans doute cet éditeur qui a publié par exemple Agile Retrospectives de Esther Derby et Diana Larsen, ou Agile Coaching de Rachel Davies et Liz Sedley que mon ami Fabrice Aimetti a traduit en français. Si vous ne connaissez par Pragmatic Programmers, je vous recommande d’aller jeter un coup d’œil à leur étagère.

Lorsque j’ai parcouru les premières pages du livre, j’ai été surpris, voir rebuté, par le ton « gestion de projet classique » et finalement c’est ce qui me plait dans cet ouvrage. Pourquoi ? Parce que c’est un ouvrage que vous pouvez faire lire à des chefs de projets, ou des managers habitués aux méthodes et aux environnements traditionnels, sans qu’ils aient l’impression que vous cherchiez à les faire entrer dans une secte.

Alors certes, cet ouvrage n’aborde pas les valeurs et principes qui sont constitutif de la culture d’une organisation, ces valeurs et principes qui peuvent être renforcées ou bousculées par l’adoption de l’ « agile ».

Cet ouvrage aborde la gestion de projet, vue de la fenêtre du chef de projet, du chef de programme, des managers, et parfois des équipiers. Il s’intéresse au démarrage du projet, planifier un projet, il s’intéresse aux cycles relatifs à la vie du projet, à la priorisation, à l’estimation, à la constitution d’équipes, au pilotage, au rythme, aux réunions, au tableau de bord, à la question de la gestion de plusieurs projets en parallèle, des équipes distribuées, à l’intégration des tests, aux programmes et portfolio, et bien sur à la terminaison des projets. J’ai repris ici l’ensemble des chapitres pour vous donner une vue globale de ce à quoi vous pouvez vous attendre. Les recommandations sont simples à comprendre, et l’argumentaire utilisé peut vous être utile pour enrichir votre palette d’arguments.

J’ai particulièrement apprécié la façon d’introduire l’importance de poser des questions utiles comme :

  • à quoi ressemble le succès ?
  • pourquoi ces résultats sont souhaités ?
  • quel est la valeur de cette solution pour vous ?
  • quels problèmes ce système cherche à résoudre ?
  • quels problèmes ce système pourrait créer ?

J’ai apprécié la recommandation et la façon d’introduire des rétrospectives dans les cycles du projet (ainsi que la façon d’insister à ne pas appeler cela post-mortem en fin de projet, en espérant que personne ne soit mort au court de ce projet).

La lecture de l’ouvrage peut-être rapide (je l’ai lu dans l’avion qui me ramenait du Red Hat Tech Exchange) et j’imagine qu’il sera une référence utile lorsque vous êtes prêt à démarrer un nouveau projet, ou à intervenir sur un projet en cours.

The Dream Team Nightmare

ptdream-smallÊtes-vous prêt à vivre une aventure agile ?

C’est la promesse du dernier livre de Portia Tung : The Dream Team Nightmare !
Le livre est publié par les « Pragmatic Programmers » ce qui est un gage de qualité. La prise de contact avec l’ouvrage (et avec l’aventure) est simple et rapide.

Je me pose encore bien sur quelques questions sur les parties de l’ouvrage que je n’ai pas exploré… Et oui en fonction de vos choix, vous serez amené vers la page correspondante !

Le livre est rempli d’enseignements pour ceux qui veulent aider leur équipe à aller vers l’agile !

Bravo et merci à Portia !

Vous pouvez retrouver Portia Tung sur Agile Adventures

 

L’agilité sur Orange-innovation.tv

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 !

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/

Le facteur humain… au coeur de l’industrie du logiciel libre

OWF 2009

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 !


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