themetest

Voilà un sujet rarement traité dans les ouvrages sur l'Agilité : la mise en oeuvre d'un progiciel. Cette nouvelle traduction de l'article "Agile Package Implementations" de Scott Ambler pour le Doctor Dobb's Journal donne les différentes étapes à suivre pour apporter le maximum de valeur et réduire les risques d'un déploiement de progiciel de manière Agile.
DDJ - Architecture & Design - Agile Package Implementations

Sinon le document est disponible chez GoogleDocs ici ainsi que sur Slideshare.

Le célèbre Agile Manifesto s'est enrichi depuis cet été d'une cinquième phrase : "Craftsmanship Over Execution".
Pour rester dans cet esprit un nouveau manifeste est disponible pour les codeurs fous que nous sommes : "Craftmanship Manifesto".

Je vous engage donc à aller le signer et surtout à le respecter :o)
Bonne journée

Bonne année et bonne santé.
Pour bien commencer cette nouvelle année je vous propose la traduction de l'article de Scott Ambler pour le Doctor Dobb's Journal sur le retour d'expérience d'IBM concernant les équipes agiles distribuées. L'agilité ne se résume pas à une petite équipe regroupée géographiquement et isolée sur son projet, Scott nous présente ici les problèmes liés à la distribution géographique et des pistes pour y remédier.
Scott animera d'ailleurs une web conférence gratuite le 27/01/2009 à ce sujet. Pouir s'inscrire ça se passe ici.

Pour ceux qui n'aiment pas slideshare, il est aussi disponible sur Google Docs ici.

Dans le cadre du CARA, nous organisons un Coding Dojo à Grenoble.
Mais qu'est ce donc que cela: il s'agit d'un lieu d'entrainement (d'où le terme de dojo) pour pouvoir étudier, tester et apprendre des techniques et des langages de code. Fini la prise de risque sur un projet, venez vous entrainer dans un lieu sûr, sans risque, entouré des meilleurs professionnels de la région (c'est à dire vous ;o) ).
Attention il ne s'agit pas d'une formation 'classique' avec un professeur et des élèves attentifs, ici tout le monde participe et tout le monde s'enrichit !!!

• Vous rêvez d'apprendre Ruby sous Linux mais vous codez votre projet en C#.
• Si vous parlez de langage fonctionnel à votre chef de projet il va vous regarder avec des yeux comme des soucoupes.
• Si TDD vous évoque T'es Dans la Déprime sur un projet en cycle en V.
• Si vous voulez vivre des sensations eXtrem Programming.

Bref, si ces phrases vous interpellent c'est qu'il est temps de venir nous rejoindre.

Les informations et l'inscription se passent ici.

Dans cet entretien Floyd Marinescu,responsable éditorial d'InfoQ, interroge Scott Ambler, Responsable de l'équipe pour la Mise en oeuvre des Developpements Agiles à IBM, sur l'état actuel des choses dans la communauté Agile, notamment en ce qui concerne sa mise en oeuvre, et sur les perspectives de l'Agilité.

L'entretien est disponible ici: Scott Ambler On Agile’s Present and Future (38 min.)

La société Net Objectives propose une série de webinaires gratuits sur le Lean présentés par Alan Shalloway.

Il s'agit d'une série de 6 session d'environ 90 minutes dont voici les sujets :

• Session 1
  Introduction to Lean Software Development
  * Lean as fast-flexible-flow
  * Lean principles of software development
  * The importance of value stream mapping
  * Exercise: Value Stream Mapping
  


• Session 2
  Five Reasons for Agility
  * Add business value quickly
  * Clarify needs of the customer
  * Better project management
  * Quick wins, quick learning
  * Better for development
  Product Portfolio Management
  * Driving from business value
  * Minimizing work in progress
  * Smaller projects add more value
  


• Session 3
  Lean as a Guide for Agile Methods
  * Just In Time
  * Contrasting Waterfall with Agility
  


• Session 4
  QA's role in Lean Agile Software Development
  


• Session 5
  How Business Analysts can help their teams
  


• Session 6
  Lean Anti-Patterns
  

pour s'inscrire ça se passe ici.

Je viens de lire un post de Mike Cohn sur la gestion des exigences non-fonctionnelles. Son contenu ainsi que ses réponses aux commentaires ne sont pas sans rappeler les articles de Scott que j'ai traduits :

• Gestion des exigences complexes
• Dépasser les exigences fonctionnelles

On voit bien qu'après la première phase d'adoption des méthodes agile, arrive le temps de la maturité et le passage à des 'gros' projets et les questions que cela soulève. En gardant l'esprit ouvert et en restant souple on passera ce cap lui aussi alors soyons Agiles.

NdT: Sinon j'ai apprécié le terme contrainte plutôt qu'exigence non-fonctionnelle que je trouve un peu pataud.

La traduction du mois est de retour avec un nouvel article de Scott dans le Doctor Dobb's Journal sur la gestion des exigences complexes. Scott nous expose ici la limitation des simples histoires d'utilisateur et les différents cas qui peuvent se produire pour lesquels il faut avoir une vision plus macroscopique du projet. La mise en œuvre des épopées ("epics")est l'une des premières solution qu'il propose mais cela ne suffit pas toujours surtout lorsque les projets grossissent.
Bref un bon article sur le passage à l'échelle des méthodes agiles ;o)
Bonne lecture.

Pour ceux qui n'aiment pas slideshare, il est aussi disponible sur Google Docs ici.

Depuis le temps que l'on en parle, David Anderson avait laissé entendre que c'était à l'étude mais je ne pensais pas que ça sortirait si vite. Et oui agilistes en herbe et papys des NTIC c'est fait fait, c'est officiel !!!Le SEI dans un rapport technique intitulé CMMI® or Agile: Why Not Embrace Both!, Technical Note (CMU/SEI-2008-TN-003 clarifie la position du CMMI par rapport aux pratiques Agiles: travaillons ensemble vers un meilleur développement logiciel !!!!
Merci à
Hillel Glazer (Entinex, Inc.)
Jeff Dalton (Broadsword Solutions Corporation)
David Anderson (David J. Anderson & Associates, Inc.)
Mike Konrad
Sandy Shrum

PS : si vous voulez le retour d'Alex ou les commentaires de QualityStreet

L'article de Scott Ambler intitulé Newsflash: Agilists Write Documentation! sur Dr. Dobb's Journal remet en cause les idées reçues autour de l'Agilité:
Oui lorsqu'on est Agile on écrit de la documentation.
Oui une équipe agile modèlise.
Oui un projet agile est structuré autour d'une architecture.
Je tiens à remercier Scott Ambler et Jon Erickson (du Dr. Dobb's Journal) qui ont gracieusement accepté ma requête pour pouvoir publier cette traduction.
La voici donc :

Pour ceux qui n'ont pas un compte slideshare, vous pouvez le voir ici.

Vendredi soir je surfais tranquillement sur Infoq lorsque j'ai vu une présentation intitulée The Lego Hypothesis. Les lego ayant bercés mon enfance, j'ai commencé à regarder la présentation du néo-zélandais James Noble. La présentation était intéressante sur plusieurs points : tout d'abord il nous présentait la naissance de l'ingénierie logiciel en 1968, puis la structure de gros programmes dans différents langages. Ce qu'il démontre c'est que nos programmes sont structurés comme des romans. Et là je ne peux m'empêcher de penser à cette notion qui me taraude depuis longtemps sur le processus de création et cette intuition qui fait que je pense depuis longtemps qu'un bon développeur est avant tout un artiste (ou un bâtisseur de cathédrales). De nombreux articles ont été écrits à ce sujet mais là on avait une 'preuve' formelle.
Finalement quand on écrit un programme on est le 'nègre' du notre client, essayant d'écrire sa biographie avec ses histoires (d'utilisateur). Or on n'imagine pas qu'une telle écriture se fasse d'un seul jet, que l'auteur après quelques heures de discussion se mette à écrire le roman qui sera lu une seule fois juste avant la publication.
Si on poursuit la métaphore on voit bien qu'il va falloir écrire des chapitres que l'on va faire relire au fur et à mesure à notre client pour vérifier qu'on reste bien conforme à ce qu'il attend. Qui a prononcé le mot 'itérations' ? ;o).
On peut surement améliorer le parallèle mais tout ceci montre avec évidence, s'il en fallait encore, la pertinence des méthodes agiles.

Hier j'ai eu la chance de participer à un webinaire: "Are Agilists the Bonobos of Software Development?" animé par Linda Rising et organisé par l'ITMPI. Ce séminaire avait été présenté à Agile 2006 et on trouve une interview qui en reprend les principaux points sur InfoQ.

Elle y compare la culture des Chimpanzés (patriarcale, avec un mâle dominant organisée autour du rapport de force) et celle des Bonobos (plus douce et plus communautaire). Elle montre ensuite comment les pratiques agiles (notamment le pair-programming) relèvent plus de la culture Bonobo alors que les systèmes hiérarchiques eux sont plus chimpanzés. Il semblerait qu'appliquer les techniques bonobo permette un meilleur flot d'informations et une meilleure confiance en soi. Éléments qui manquent pour une féminisation du développement informatique.

Une présentation bien rafraichissante en ces temps de pluie et de brouillard.

Un petit billet que m'a inspiré l'article suivant:
Who plays the role of technical producer on Agile teams?.

Ce n'est pas sans rappeler la conversation que j'avais eue avec Hervé. Lorsque je lis de nombreux articles sur l'Agilité et ses corolaires je me pose souvent la question "Mais qui s'occupe de l'aspect technique de l'introduction de l'Agilité dans l'équipe ?". On a des coaches agiles, des scrum masters, ... mais qui valide que l'équipe applique correctement le TDD ? Qui vérifie la qualité du code ?
Certains me répondront surement que c'est là la responsabilité de l'équipe et j'en conviens tout à fait. Mais si l'équipe doit, en plus d'apprendre à se gérer elle-même, mettre en oeuvre des bonnes pratiques qui sont tout sauf évidentes (le tests first par exemple, l'intégration continue, les mesures de qualité de code, l'analyse statique, etc.) elle ne s'en sortira pas bien. C'était d'ailleurs la conclusion d'Hervé (et je suis bien d'accord avec lui) : il faut un leader technique, pendant du coach agile, sur les projets agiles surtout dans les premières mises en oeuvre de l'agilité par une équipe.

En bref, pour paraphraser l'article du début, avoir le meilleur groupe de musique du monde ne suffit pas, il faut aussi un bon producteur.

J'ai pu participer à 3 des présentations de l'Agile Tour 2008 à Grenoble.
Tout d'abord :

• eXtrem Programming – Retour d'expérience après 6 années de pratiques - J-M. Voisin, Allianz Global Investor : un retour d'expérience fort intéressant où j'ai pu m'apercevoir qu'Allianz était dans la même ligne qu'Orange Labs sur le choix des outils et des pratiques. Le chiffre du jour : un projet en XP entraine un surcoût de 15% à la réalisation mais l'équipe qui passait de 50% de son temps en maintenance en est à moins de 10% (environ 1 bug par mois).


• Senteurs Agiles - T.Lissajoux, Octo : un atelier vraiment enrichissant et un jeu de cartes tout simplement génial. J'ai hâte de pouvoir en obtenir une version :o)).


• Agilité et Avionique – E. Chenu, Thales Avionics : depuis le temps que je voulais voir Emmanuel en vrai. C'est là qu'on voit le gouffre entre le monde de l'avionique et celui du SI. L'expression 'application critique' prend tout son sens. Une expérience intéressante car elle donne des clefs pour convaincre nos chers décideurs.

Voici quelques photos prises par Alexandre Boutin, dont ces deux là où nous sommes en pleine action avec Rémy ;o) :



Devinez qui travaille chez Orange Labs et qui travaille chez Silverpeas ;o)

L'article de Scott Ambler intituléBeyond Functional Requirements On Agile Projects sur Dr. Dobb's Journal est très intéressant car il ne se contente pas de s'occuper de la partie réalisation au jour le jour d'un projet mais le prend dans sa globalité et présente différentes stratégies pour prendre en compte les exigences non fonctionnelles.
J'ai donc décidé de le traduire afin qu'il soit relayé auprès des communautés francophones.
Je tiens à remercier Scott Ambler et Jon Erickson (du Dr. Dobb's Journal) qui ont gracieusement accepté ma requête pour pouvoir publier cette traduction.
La voici donc : Dépasser les exigences fonctionnelles sur les projets de développement Agile

Suite au commentaire de Miguel :
Pour ceux qui n'ont pas un compte slideshare, vous pouvez le voir ici.

Il passera à Grenoble cette année : pour une fois qu'on n'a pas un évènement uniquement parisien. J'ai la grande chance de présenter avec Rémy nos expériences à Orange Labs pour mettre en place des outils facilitant le développement Agile.
Pour les horaires ça se trouve ici. Nous serons à la séance de 17h15 à 18h00 dans l'Amphi Simplicité.
Pour venir suivez le guide ici.
@jeudi donc.

Etre professionnel c'est faire du bon code quitte à tricher et à ne pas en avertir son chef. Voilà une philosophie qui me parle :o))

Our industry is plagued by an epidemic of very bad code.

Robert Martin (known as Uncle Bob), founder of ObjectMentor.
Uncle Bob rulezzzzzzzzzzzzz :o)

La source JAOO.

C'était une tendance que l'on a observé à l'Agile 2008 dont voici les commentaires de ceux qui ont eu la chance d'y participer : agilethinking et Lyssa Adkins.
Lors de ma discussion post-présentation, j'ai été surpris de constater que chez nous cela se pratique aussi (déjà devrais je dire vu que l'on a souvent plusieurs années de retard sur les USA). J'y ai rencontré un chef de projet qui essayait de mettre l'Agilité en oeuvre dans le monde du BTP. Bien sûr moyennant une adaptation du vocabulaire ;o)