insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

lundi 29 mars 2010

Outils du Product Owner pour maximiser le ROI

Mercredi dernier, j'ai passé la soirée dans les bureaux de Zenika pour assister à la conférence "outils du Product Owner pour maximiser le ROI" animée par Michel Goldenberg.

Malheureusement, car le sujet m'intéresse beaucoup, la discussion a divergé vers l'intérêt des estimations.

Ci-dessous, les exercices que Michel Goldenberg a eu le temps de nous présenter.

Comment arriver à une vision commune et obtenir un consensus ?

  1. définir le sujet de questionnement ;
  2. demander à chaque participant d'écrire sa réponse sur un post-it ;
  3. former des binômes ;
  4. demander à chaque binôme d'échanger leurs points de vue ;
  5. demander à chaque binôme de noter, d'un commun accord, leurs deux post-its pour arriver à une somme de cinq (cinq étant la meilleure note i.e. la définition remportant l'adhésion des deux membres du binôme) ;
  6. demander à chaque binôme d'échanger leurs post-its ;
  7. réitérer l'exercice à partir de l'étape trois jusqu'à ce que les post-its aient le même nombre de notes que de participants ;
  8. additionner les notes pour donner une note globale à chaque post-it.

La note globale d'un post-it révèle le degré d'adhésion des participants à ce qui est écrit dessus.

Durant cet exercice, nous avons vue se dégager un post-it particulièrement bien noté. Il s'agit du consensus. Puis un peloton de post-its un peu moins bien notés. Il s'agit de la vision commune. Et pour finir, deux post-its avec des notes très faibles. Il s'agit des visions marginales.

Comment déterminer l'intérêt d'une vision marginale ?

Les visions marginales ne sont pas nécessairement inintéressantes. Il est possible qu'elles soient seulement mal comprises. Pour répondre à cette question, nous avons utilisé l'exercice suivant :

  1. demander à chaque participant de marquer physiquement son adhésion ou non à la vision marginale, par exemple en divisant la salle de réunion en deux ;
  2. demander à une personne du groupe minoritaire, ceux adhérant à la vision marginale, d'expliquer son point de vue ;
  3. demander à chaque personne du groupe majoritaire si les éclaircissements apportés lui fait réviser sa position ;
  4. réitérer l'exercice à partir de l'étape deux jusqu'à ce que toutes les personnes du groupe minoritaire se soient exprimées ;
  5. conclure en fonction des migrations entre le groupe majoritaire et le groupe minoritaire.

Comment interviewer un client ?

L'objectif de l'interview est d'aider le client à définir et prioriser son besoin. Le client doit être acteur de l'interview. L'interviewer n'est là que pour aider le client à structurer son expression de besoin.

  1. demander au client d'écrire sur des post-its jusqu'à 5 fonctionnalités essentielles de son produit ;
  2. demander au client de prioriser les post-its en répartissant 15 points, une note élevée indiquant une priorité forte ;
  3. réitérer l'exercice jusqu'à atteindre la granularité souhaitée.

L'étape deux n'est pas toujours évidente. J'en ai fait l'expérience en mettant cet exercice en pratique le vendredi suivant la conférence. Le rôle de l'interviewer est alors de challenger le client pour qu'il sépare son besoin entre l'essentiel et le facultatif à force de questionnement.

Dernier conseil

Le PO doit également pousser l'équipe de développement à lui expliquer les stories ayant une forte complexité. Il pourra ainsi détecter les tâches ayant une forte complexité à cause d'un détail technique (e.g. : drag and drop, …). Le cas échéant, ils pourront étudier ensemble les alternatives envisageables.

Maximiser le ROI, c'est minimiser le travail inutile !

lundi 15 mars 2010

Séance d'estimation

Suite à des séances d'estimation s'éternisant sur le projet sur lequel je travail actuellement je suis venu à me poser des question sur cet exercice.

Pour quelle raison faisons-nous des séances d'estimation ? Je pense que les objectifs sont doubles :

  • échanger afin d'avoir une vision commune sur les items du backlog ;
  • estimer la complexité des items afin d'avoir de la visibilité sur l'avancement du projet.

Une fois ces objectifs bien en tête, vient la question suivante : Qui est concerné par cette réunion ? Toutes les personnes apportant des éléments permettant de clarifier la vision des items du backlog et toutes les personnes qui auront à réaliser ces items.

Maintenant, nous connaissons les enjeux et les acteurs de cette réunion. C'est bien, mais pas top. Les séances d'estimation ne sont pas plus efficaces. Pourquoi ? Retour aux définitions :

Estimation : évaluation approximative fondée sur des données incomplètes ou de nature imprécise.

Une estimation est une évaluation approximative !

Si votre équipe prend plus de 10 minutes pour se décider entre une complexité de 5 ou 8, je vous propose d'essayer la méthode décrite ci-dessous.

Les objectifs de la réunion étant double, découpons la réunion en deux temps

  • comprendre les nouveaux items ;
  • estimer les complexités.

La compréhension des nouveaux items passe par la discussion entre les acteurs du projet. C'est le temps fort d'une séance d'estimation. La vision commune du projet issue de ces échanges facilitera les communications futures.

L'estimation des complexités est plus pertinente et plus rapide une fois que les items sont compris. Pour faciliter encore la démarche, j'aime procéder de la manière suivante :

  • imprimer les intitulés des items sur des cartes en papier ;
  • disposer ces cartes sur une table en fonction des complexités relatives ;
  • associer chaque groupes d'items à une complexité chiffrée.

lundi 8 mars 2010

Révision Scrum : le backlog produit

Le backlog produit est la liste des fonctionnalités du produit à développer. Chaque élément de cette liste est composé au minimum de trois attributs :

La finalité du backlog produit est d'avoir de la visibilité sur l'état du projet et de prioriser les développements.

Le backlog produit est de la responsabilité du product owner.

Valeur métier

La valeur métier d'un item est estimée par le product owner.

C'est la valeur métier des items qui doit diriger la priorisation des développements. Pour aider à la mise en perspective entre l'accessoire et le fondamental, il est conseillé d'utiliser la suite de Fibonacci en s'efforçant d'utiliser des valeurs très disparates.

Effort ou complexité

L'effort nécessaire à la réalisation d'un item est estimé par les personnes qui seront en charge de la réalisation. Cette valeur est fixe dans le temps.

Plus un effort est important, plus son estimation est imprécise. C'est pourquoi il est conseillé d'utiliser la suite de Fibonnaci pour estimer les efforts.

Métriques

Les métriques issues des données du backlog produit donnent de la visibilité sur l'état actuel du projet et aide à définir les prochaines étapes.

Le backlog produit est un outil évolutif (ajout, suppression, modification d'items). Par conséquent, il est souvent intéressant de suivre ces métriques en points et en pourcentage.

Ci-dessous, deux exemples de métrique que nous pouvons extraire du backlog produit.

Vélocité

La vélocité est l'effort qu'une équipe peut adresser en un sprint. Cette mesure s'affine au fil des itérations.

La vélocité ne doit pas être utilisé pour assurer le suivi de la productivité d'une équipe mais pour réaliser des projections (e.g. estimer la date de fin du projet). Une mauvaise utilisation de cette métrique entraine une inflation des points d'effort et/ou une "course à la vélocité" au détriment de la qualité.

Il est également déconseillé de comparer les vélocités de deux équipes du fait des estimations réalisées sur des échelles différentes. Les estimations sont relatives, pas absolues.

Par contre, il est intéressant de suivre l'évolution de la vélocité d'une équipe. Une diminution de la vélocité traduit souvent un manque d'évolutivité du produit développé ou l'apparition de nombreux bugs.

Valeur métier acquise

Cette métrique détermine la valeur des développements réalisés.

Si le backlog est correctement priorisé, l'évolution de la valeur métier acquise doit diminuer au cours des itérations car les items de plus grande valeur sont traités en premier.

Quelques liens

Dans SCRUM mon backlog de produit est DEEP
Le backlog produit
Des user stories de qualité
Valeur métier en pratique
Comment mieux prioriser en agile
Suite de Fibonacci

vendredi 26 février 2010

Révision Agile : ScrumMaster ? C'est quoi déjà ?

La semaine prochaine, le ScrumMaster du projet sur lequel je travaille sera en vacance. Étant donné que je vais assurer son remplacement, j'en profite pour réviser le rôle du ScrumMaster.

Alors, qu'est-ce qu'un ScrumMaster ?

Un facilitateur

L'une des missions du ScrumMaster est de s'assurer que les autres membres de l'équipe restent concentrés sur le véritable objectif du projet : la livraison de valeur pour le client.
Il écarte les obstacles qui jonchent le parcours menant à la livraison et si possible avant même qu'ils ne surviennent.

Un coach

Dans le processus d'amélioration continue, le ScrumMaster joue le rôle du coach.
Il aide l'équipe à prendre conscience de ses qualités et faiblesses. Puis il fait en sorte de conserver les acquis tout en travaillant les points faibles.

Un animateur

Il organise et anime les activités Scrum tel que sprint planning, daily Scrum, sprint review et rétrospective.
Il fait en sorte que tous les membres de l'équipe se sentent impliqué et libre de s'exprimer.
Autant que faire se peut, le ScrumMaster s'assure que tous les membres de l'équipe sont contents de travailler.

Le garant des pratiques Scrum

Un ScumMaster, comme l'indique son nom, a une bonne connaissance de Scrum. De par cette connaissance, le ScrumMaster s'impose comme le garant de la bonne utilisation des pratiques de Scrum.

Quelques liens

Le rôle de ScrumMaster
Peut-on à la fois être ScrumMaster et développeur sur un même projet ?
Mon ScrumMaster en fait trop !

jeudi 19 novembre 2009

Devoxx 2009 : Agile Mythbusters

Scott W. Ambler, Chief Agile Methodologist chez IBM, a présenté les résultats des sondages réalisés par Ambysoft et Dr. Dobb's Journal pour faire ressortir les pratiques réelles des équipes agiles à ce jour.

Les conclusions qui ont retenu mon attention :

  • les pratiques agiles restent principalement concentrées sur la technique (Continuous Integration) ;
  • l'obtention de la certification "SCRUM Master" après seulement deux jours de formation est dépourvue de sens ;
  • des équipes de plus de 200 personnes pratiquent l'agilité ;
  • les pratiques agiles ne changent pas les besoins de chiffrage, de spécification, de modélisation, d'architecture durant l'initialisation d'un projet ;
  • la majorité des développeurs agiles suivent des conventions de codage même s'il reste une marge de progrès dans ce domaine ;
  • les équipes agiles et traditionnelles écrivent autant de documentation et cette documentation est de qualité similaire ;
  • les projets agiles connaissent plus de succès que les projets classiques.

L'intérêt principal de cette présentation a été de fournir des réponses chiffrées aux questions que peuvent se poser les personnes s'intéressant aux méthodes agiles. Cependant, il convient de considérer ces chiffres dans leur contexte avec les limitations que ça implique. Par exemple, les conditions de succès d'un projet restent sujet à discussion.

Pour la liste complète des "Mythes Agiles" et les résultats des sondages associés, se référer au post de Jevgeni Kabanov.

Pour la liste des sondages, suivre ce lien.

jeudi 28 mai 2009

Les XP days 2009

Cet évênement de 2 jours a rassemblé près de 250 personnes au chalet de la porte Jaune, un cadre idylique, et a fourni un contenu de qualité encadré par une organisation sans faille. Bravo aux organisateurs.

L'assemblée générale de l'association XP France  qui propose cet évênement, a eu lieu pendant le soir du premier jour, avec le vote du renommage de l'association en Agile France.

Le plus difficile dans cet évênement, c'est de choisir la prochaine session, alors on s'y est mis à plusieurs, et on vous propose de vous donner des petits bouts de XP days :)

Soigner sa schizophrénie projet MOA/MOE : voyage autour des exigences fonctionnelles exécutables


 

Durant cette présentation Emmanuel HugonnetRémy Sanlaville, et Hervé Lourdin ont traité une maladie grave qui touche encore de nos jours une grande partie des projets informatiques : la schizophrénie.

Cette maladie dont le principal symptôme est le fractionnement de l’esprit est diagnostiquée par la relation ‘conflictuelle’ entre la MOA et la MOE. Cette relation particulière de ces deux ‘collègues ennemies’ qui auraient dû formait une seule et unique équipe du projet (ou patient), se matérialise justement par leur séparation. La MOA commence par rédiger les spécifications ‘détaillées’, mais peu compréhensibles ! La MOE, les traduit ensuite aussi bien que mal en logiciel. Le résultat est un produit qui repend peu aux attentes et aux besoins, et qui a dépassé son budget.

 

Heureusement, les remèdes existent ! Et nos médecins du jour, prescrivent a cet effet, la ‘Acceptance Test Driven Development’.

En effet, cette méthode agile présente un cycle de développement qui fait intervenir les deux parties, jadis ennemies, d'une manière a ce que les MOA et les MOE agissent en étroite collaboration pour discuter en premier temps des 'exemples d'utilisation' du système à produire. Un langage métier commun aux différents membres de l'équipe va émergé, et permettra une meilleure communication entre eux malgré leur différence de casquette (techniciens/métier). De ces discussions des 'cas d'utilisation' vont naitre des spécifications exécutables. Ces spécifications, ont en effet l'avantage, par rapport a celles produites au cours d'un cycle en V, d'être déterministes et donc non sujettes a l'interprétation des développeurs qui auront pour but ultime de les faire passer du rouge au vert. Après quoi, a lieu la démonstration en présence notamment de membre de la MOA/testeur/utilisateurs. Tout ceci, se fait dans la bonne tradition agile, d'une manière itérative.

Une panoplie d'outils, existe pour répondre a l'implémentation de cette méthode dont ont été cité Jbehave, Rspec et EasyBehave; Toutefois ces frameworks faillent par leur manque de 'maturité' qui se manifesté surtout par:

·         leur difficulté a être géré par les SCM en parallèle du code source des scenarii, 

·         leur difficulté de manipulation par les MOA,

·         leur aspect 'refactoring unfriendly'.

Enfin, on a rappelé que cette méthode proche de la BDD et de la DDD, met l'accent sur le pilotage des développement par les experts métiers, qu'il faut faire intervenir activement au le cycle du développement, dans un esprit de respect et d'étroite collaboration.

Slim Tebourbi

Le développement Hédoniste


 

Dans cette session 'originale', Dominic Williams, a fait un rapprochement entre l'Hédonisme et l'Agilité.

Tout d'abord, on a eu droit a un petit cours de philosophie dans le but de présenter le courant hédoniste qui se présente comme une 'idéologie' considérant le plaisir comme étant le bien ultime.(et si j'ai bien compris ;) ) .

Ensuite, Willams, a commencé a faire sortir les traits d'analogie entre les deux courants. En effet, tout comme l'hédonisme, « qui a traversé les siècles mais a toujours été dominé, dénigré et occulté par le courant dominant: l'idéalisme»; les méthodes agiles 'peinent' encore a passer devant les «les méthodes prédictives (cycle en V, CMMI, RUP)»; ce point commun met aussi en avant une autre particularité partagé qu'est leur esprit rebelle; cet esprit engendrant un mouvement d'anarchie libertaire' qui nie les structures rigides et l'idealisme.

Enfin, Willams, a itéré les piliers de l'hédonisme en faisant, a chaque fois, le rapprochement avec un aspect de l'agilité .

 

 

Hédonisme

Agilité

Le matérialisme

favorise la matière (le concret) sur les idées (l'abstrait).

Favorise le logiciel (le livrable) sur les spécifications parfaites (représentation d'un idéal utopique).

Le jardin d'épicure (un jardin ouvert au public de tout genre, espace d'échange et d'amitié)

Favorise les rapports humains, les communauté ouverte, l'amitié, l'anti-élitisme.

Insiste sur l'importance des rapports humains et la communication au sein de l'équipe. (Open space)

Dieu

«pas de croyance inhibitrice», insoumission.

Délégation des responsabilité, moins de 'chefs', autonomie.

Le plaisir

Le plaisir est un but noble. Il faut à la fois augmenter ce plaisir et éliminer les sources de déplaisir.

Le but ultime est un produit de qualité, livré a temps et qui répond aux besoins. Ces besoins qu'on n'hésite pas revoir a la baisse ou a reporté la réalisation dans le but de garantir ladite qualité et la date de livraison.

 

Slim Tebourbi

La parabole du trafic urbain – l'Agilité expliquée autrement

 

Après celle avec l'hédonisme, on a eu droit a une autre analogie, aussi originale et réussie que la première, entre l'Agilité et le trafic urbain.

En fait, François Bachmann, a habilement projeter le domaine familier du trafic routier a celui du développement logiciel où les voies étaient assimilées aux ressources humaines du projet, les véhicules (voitures, motos, vélos, piétons...) aux livrables, et les signalisations aux méthodes de gestion. En effet, il a mis en avant l'impact qu'ont ces dernières sur la vitesse moyenne de circulation d'une part, et le débit de production de l'autre. Ainsi, et pour le trafic urbain, les méthodes classiques 'prédictives' ou orienté 'command and control' comme les feux tricolores, donnaient des résultats assez aléatoires et une vitesse moyenne très faible. Par exemple a Tokyo cette moyenne se situe au alentours de 15 km/h, une valeur digne de l'age 'des déplacements a cheval'! Cela est bien sûr, assimilable à la manière waterfall, qui mise aussi sur la prédiction. Ensuite, il a mis en évidence l'intérêt et l'importance de valeurs prônées par l'Agilité telles la communication, la réactivité et l'autogestion dans la fluidité du trafic. Et comme exemple de méthode 'agile-like' au problème du trafic, il a pris le sens giratoire qui incarne :

·         Communication : observer les autres

·         Simplicité : un seul de circulation

·         Rétroaction : aucun flux privilégié

·         Courage : délégation de responsabilité

·         Respect :  responsabilité des conducteurs

 

Cette présentation, a donnée une vision assez simple et concrète des valeurs de l'Agilité avec des concepts aussi banales que ceux du trafic urbain; Cette vision pourrait servir à faire l'initiation de personnes peu familiarisé et constituée le premier pas de les convaincre de son adoption.

Slim Tebourbi

Au delà de l'intégration continue traditionnelle : l'intégration de la production

 

Cette présentation traitait le fait que notre vision 'traditionnelle' de l'intégration continue exclue les opérations de déploiement à la production de leur périmètre d'action. Cette exclusion était même considérée 'selon' nos orateurs, dans la littérature du web, comme étant une bonne pratique.

L'un des centre d'intérêt de cette session était le fait qu'elle fut dirigée par deux ingénieurs de production, ce qui permettait de redécouvrir les problématiques liés et traités par l'IC sous un autre angle. Bien conscient de cet aspect, ils ont insister sur le fait que les équipes de production était souvent mis a coté par leur collègues du développement; Cette exclusion se projette par exemple dans la définition du 'terminé' qui se suffit d'un travail livrable; alors qu'il serait plus adéquat d'élargir cette définition jusqu'à la mise en production du produit!

Et c'est la que réside la clé de l'intégration des opérations de production dans le processus du développement agile. En effet, cette modification de la définition de ce concept du 'terminé', va faire inclure celles ci dans le spectre des pratiques agiles et en particulier l'itérativité et l'IC. D'autant plus que les opérations en questions possèdent les caractéristiques requise pour rentrer dans le processus appliqué au code source:

·         gestion du versionning des configurations système, script d'installation des paquets...

·         automatiquement générable par des scripts

·         testable

 

Ces considérations, nécessitent une nouvelle vision du dépôt de code qui sera désormais le dépôt système; ce dernier regroupera le code source ainsi que les fichiers de configuration  et script d'installation et autres artefacts qui représentent le système en entier et pas seulement le logiciel produit par l'équipe de développement. Désormais, l'IC traitera de nouvelles problématiques orienté système (performance, infrastructure), et sera plus efficace car on elle sera une vrai projection de l'environnement réel de déploiement sous tous ces angles. Choses qui devrait facilité et fiabilisé les déploiements.

Toutefois, les outils nécessitent à cette extension de l'IC sont encore peu nombreux et immatures pour ceux existant sur le marché; contrairement a ceux de l'IC sous sa forme traditionnelle.

Slim Tebourbi

   Blanche Neige et les 7 nains

Pascal Van Cauwenberghe et Portia Tung nous proposent une version Tarantino du célèbre conte pour enfants.

Des protagonistes, ils déclinent des comportements:

  • Prof: Savant, axé sur les solutions, arrogant
  • Timide: attentif aux besoins des autres, calme, n'aime pas les conflits
  • Dormeur: distrayant, facilement distrait, difficile à motiver
  • Atchoum: amical, créatif dans la prévention du travail, allergique au travail
  • Joyeux: positif, motivé, peut ignorer les problèmes
  • Simplet: enthousiaste, manque de discipline, porte peu d'attention aux détails
  • Grincheux: analytique, critique, mauvais communicateur
  • Chasseur: discipliné, pragmatique, mercenaire
  • La Méchante Reine: arrive à ses fins, a soif de pouvoir, manipulatrice
  • Blanche Neige: bonne équipière, travaille dur, naïve

 En découvrant les personnages, je me suis reconnu plusieurs fois.

Après une séance de networking organisé, le premier exercice proposé était de se poser les questions suivantes: 

Pour un personnage tiré au hasard, à quelle personne de mon entourage je l'associe?

Ensuite, qu'est-ce que ce choix peut m'apprendre sur ma relation avec lui et sur moi-même?

Quelle action action pourais-je mener afin de changer cette relation et m'améliorer?

Le second exercice etait de définir un projet ambition capable d'attirer les pièces (en chocolat bien sûr) des investisseurs.

Les membres de cette équipe étaient bien sûr des personnage de l'histoire dont 3 sont tirés au hasard, et 2 choisis.

Notre groupe est partie sur des robots 'nains' qui font de la micro chirurgie du coeur.

Et cela nous fait poser la question de "C'est quoi une équipe qui déchirre?", cela donne quelque réflexions amusantes du genre

"Prof est indispensable pour ce sujet très pointu, ce sera notre TechLead", "Grincheux sera un bon testeur", "et simplet...

ce sera notre cobaille", "Grincheux risque de ne pas s'entendre avec Prof", "il faut quand même des chasseur ou des blanches neige qui bossent",

"La méchante reine aussi est utile".

Bref, hors contexte c'est encore plus drôle.

La conclusion est que l'on ne peut changer que soi même.

Je conseille de réaliser ce genre de jeux dans votre équipe.

Si cela vous intéresse, le jeux est disponnible en licence creative commons sur le site http://www.agilefairytales.com/

François Wauquier

Le coaching

Ce n'est pas de coaching agile dont il est question, mais de coaching individuel pour les professionnels. Luc Bizeul a invité Pierre Carnicelli , le père de l'école No Limit Coaching.

Le coaching traditionnel existe en effet depuis longtemps, nous apprennons qu'il se décline sous plusieurs formes:

  • Psychanalyse
  • Consultant
  • Modèle
  • Formateur
  • Entraîneur
  • Tuteur
  • Coach
  • Mentor

 

Les principaux enseignements de cette courte session sont que le coach ne doit pas forcement connaître le métier du coaché (Pierre coache dans le secteur du batiment), que seul le coaché peut trouver une solution à son problème, et que le coaching ne peut être qu'une étape transitoire.

François Wauquier

A Quand la première mise en production?

Le Duo Eric Mignot et Hervé Naudin a tenté de regrouper les préoccupations de communication PO/équipe, du niveau de créativité de l'équipe et de l'attente (ou pas) de la première mise en production.

Le lien ne vient qu'à la fin: l'équipe, si elle est impliquée, doit donner envie au Product Owner de mettre en poduction la "dernière story qui déchirre tout".

François Wauquier

Styles Sociaux en action

Jean François Helie  et Bernard Notariani nous présentent le modèle Herrmann, qui permet de nommer une préférence de fonctionnement d'une personne ou d'un groupe à un moment donné dans un contexte donné.

 

  • Analytique
  • Explorateur (imaginatif)
  • Organisé (séquentiel)
  • Emotif (interpersonnel)

 

Le jeu central se présentait sous la forme d'un débat sur une question (Comment être heureux au travail?, Comment faire de l'architecture dans un projet Agile?)

Les enseignements important nous sont faits:

Deux personnes qui ne sont pas dans la même position auront plus de mal à se comprendre.

La position dans laquelle nous pensons être à un moment n'est pas forcement celui qui est perçu par l'entourage.

Il est difficile de changer de position de manière volontaire.

François Wauquier

 

 

Le Planning game

 

L’objectif de François été de familiariser les quelques quarante personnes présentes au principe du travail en groupe pour l’estimation par l’utilisation de la technique du planning poker. Après une rapide présentation , les personnes se divise en trois groupes, chaque groupe doit mettre en pratique les quelques notions théoriques présentées pour réaliser le backlog d'un projet. Dans mon groupe on s’est vu assigné la tâche d’organiser un mariage, mon équipe été composée principalement de développeur et d’un scrum master, post-it en main, on décide très vite de crée des user stories puis de les estimer une à une.

 

 Abderrazac Bouadma 

Mon JavaScript est aussi Agile

 

L’objectif de cet atelier était la réalisation d’un mini langage de validation de formulaire sur la base de l’API JQuery, le mode opération été bien adapté aux besoins de la session « kata », la notion de DSL  (Domain Specific Language) a été exposée pendant la session.

Abderrazac Bouadma 

 

Dojo TDR

 

L’objectif été d’établir des spécifications fonctionnelles sur la base de tests fonctionnels. La session a commencé par une présentation rapide de la technique et l’ordre dans lequel se déroulera le Dojo, le choix du domaine fonctionnel s’est avéré intéressant « le black jack », deux personnes sensées représenter les référents fonctionnels se sont présenté volontaires, le présentateur a pris la casquette du scrum master, l’outil sur lequel on introduisait notre contenu été fitnesse, le processus se décompose d’une part par une discussion entre la personne qui veut rédiger la spécification exécutable ou au moins une partie car chaque personne été limité dans le temps « cinq minutes » maximum, et les référents fonctionnels, l’objectif est crée un test suivant le formalisme « Given, When, Then ».

A la fin de la session, on a procédés à une rétrospective qui nous a révélé que la rédaction de spécifications fonctionnelles est une tâches très ardue et stratégique et qui se base essentiellement sur la focalisation de l’ensemble des intervenant sur le cœur du métier en question.

Abderrazac Bouadma 

 

 

Le stand recrutement

 

Durant ces 2 jours, l'équipe de recrutement était présente sur un stand aux couleurs de SFEIR. Cela nous a permis d'être visible et de communiquer sur notre groupe et notre activité. Nous avons pu échanger avec une trentaine de personnes. En majorité, il s'agissait de personnes curieuses mais pas réellement à l'écoute du marché.

Nous avons bien conscience que la plupart des participants n'était pas là dans le cadre d'une démarche de recrutement.

En revanche, cela nous a permis de créer du réseau et de travailler sur du long terme. Nous réfléchissons déjà à  la prochaine édition pour mettre en place un stand un peu différent, et oui n'oublions pas : "amélioration continue"!

 

Myriam JOURDAIN

Chargée de recrutement.

 

 

 

 

mercredi 13 février 2008

Concordiagile, la vision

« Concordiagile » est une alliance de personnes morales motivées par la promotion commune des méthodes agiles en France. Si vous voulez en savoir plus sur cette alliance, je vous invite à consulter le blog que vient de publier David Gageot de Valtech.

La Vision de Concordiagile

mardi 12 février 2008

[TechDays 2008 - J2] GreenPepper.Net

greenpepper_1 Une présentation très vivante, avec deux super speakers qui n'ont juste pas eu le temps de présenter concrètement le produit GreenPepper à notre grand regret. Mais le sujet qui amène la démo était très riche et très dense (trop ?).

D'abord un tour d'horizon sur les tests de non régression et les pratiques agiles.

La problématique principale: la communication entre utilisateurs et développeurs. Et dans ce cadre, le rôle de l'analyste d'affaire.

Un petit tour pour rire sur le cycle en V: série de documents passés de personnes à personnes, beaucoup de documents transmis et de plus en plus volumineux. Communication par documents écrits qui rend difficile le passage de tous les messages. Formalisme spécialisé, sources d'information multiples, difficile à maintenir, avec une traçabilité faible. On ne peut pas tester des documents. A cela se rajoute le fait que les gestions des exigences et de projet sont souvent mal intégrées.

Une petite présentation de Scrum mais aussi du Manifeste Agile et ses 4 règles d'or.

Insiste bien sur l'importance des tests. Et le côté contradictoire de la plupart des projets: quand toutes les phases du projet décalent, on compresse ce qui vient en dernier: les tests. Donc quand on code plus, on teste moins! Et c'est quasiment inévitable quand on garde l'écriture des tests pour la fin.greenpepper_2

De l'importance d'écrire les tests avec l'utilisateur comme les exigences elles-mêmes. C'est une partie très itérative, un peu de test écrit, un peu de code, on teste et on recommence. L'idée est de créer un environnement collaboratif.

Très concrètement, les tests sont là pour aider plutôt que contraindre et ennuyer le développeur.

Donc ils n'ont pas présenté leur produit, mais... il y a des présentations en ligne sur leur site: http://greenpeppersoftware.com