NASHVILLE me voilà

Ca bouge dans le monde de l’Agile Alliance pour la préparation de l’évènement Agile 2010 prévu à Nashville du 9 au 13 août 2010.

La métaphore pour la conférence 2010 est « Learn, Practice, Explore » en référence au Shu-Ha-Ri des arts martiaux et l’engagement de James Newkirk (Agile 2010 Conference Chiarman) est de proposer plus de sessions pour les agilistes expérimentés … YEAH !!!

3 communautés sont identifiées :

  • Business : animée par Lowell Lindstrom
  • Leadership & organization : animée par Pollyanna Pixton (que j’avais vraiment aimé l’année dernière)
  • Technical : Brian Button

Les soumissions seront ouvertes à partir de Janvier et si vous souhaitez en savoir plus … suivez le lien du blog de la conférence 🙂

A titre personnel, j’adore ce type de conférence alors j’y serais en août car mon chef vient d’accepter le déplacement … qu’est ce qu’il est bien mon chef 🙂

Scrum en Vidéo

Un article vraiment enrichissant posté par Florent Lothon (Blog L’agiliste) avec une vidéo de la mise en œuvre de Scrum sur un projet complexe et un retour d’expérience personnel très intéressant sur les difficultés de la mise en place de certaines pratiques (ne regardez pas que la vidéo et allez lire ce que Florent écrit plus bas dans son article 🙂 )

Le KANBAN pour réduire la dette technique

Dette techniqueLe sujet de la dette technique est vaste et a même suscité l’écriture de quelques très bons livres comme celui de Michael Feathers « Working effectively with legacy Code » qui explique comment travailler par petites étapes et surtout la nécessité d’arrêter d’augmenter systématiquement cette dette (« Stop Digging! »).

Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.

Alors comment faire ?
Continuer la lecture de « Le KANBAN pour réduire la dette technique »

Valeur métier en pratique

Valeur metierLes méthodes agiles mettent en avant la production de valeur pour le client communément appelé « Valeur Métier » ou « Business Value » en anglais. Lors des formations de Scrum Master, il est clairement dit que le Product Backlog doit être priorisé en fonction de cette valeur métier, mais la façon de le faire est rarement abordé lors de ces formations, alors comment faire ?

La première chose à comprendre est que la valeur métier n’est pas un chiffre (euros ou dollars) mais bien un modèle, c’est à dire une sorte de standard qui définit et évalue ce qui apporte de la valeur à l’entreprise.

Chez un de mes clients Grenoblois nous avons travaillé sur le sujet afin d’aider les équipes produit à comprendre quels étaient les points importants pour l’entreprise et à partir de là de pouvoir définir les bonnes priorités pour les équipes de réalisation.

Continuer la lecture de « Valeur métier en pratique »

Bilan 3ème Soirée Agile à Lyon

cucumber_logoUne vingtaine de personnes étaient présentes ce soir pour la 3ème soirée Agile sur Lyon … soit 3 fois plus qu’il y a 2 mois
… YEAH !!!

Le thème du jour était les TESTS, sous toutes leurs formes.

L’introduction est assurée par Franck qui nous présente la problématique générale des tests et des problèmes récurrents rencontrés par les différentes entreprises, de la perte de la vision de ce que veut le client aux gaspillages générés tout au long du développement du projet. La présentation s’appuie sur les travaux de Brian Marick (Carré des tests) et ceux de Mike Cohn (Triangle des tests).

Ensuite, Manu nous a présenté le TDD (Test Driven Development) et le fait que ce n’est pas une pratique de test mais bien une façon d’obtenir du code propre lorsque le refactoring est correctement réalisé (à l’image de ce qu’écrit Robert Martin, alias Oncle Bob, dans son dernier livre « Clean Code »).

Enfin, Jean-Michel à clos la soirée en nous parlant de l’ATDD avec Cucumber donc la dynamique est réellement en route depuis 1 an et qui, malgré son jeune age, peut s’utiliser avec quasiment tous les langages de développement. Il paraît que Aslak Hellesøy, le créateur de Cucumber, parle français … et je me dis qu’il ferait bien comme keynote à la prochaine conférence de Grenpoble 🙂

La soirée s’est terminée par un petit verre pour délier les langues et networker un peu, prochaine soirée dans 2 mois, soyez attentif, nous communiquerons la date bientôt.

Ensuite ca a été le sprint avec Manu pour prendre le train de 21h45, mais nous avons réussi à nous jeter dedans 1 minute avant le départ – un conseil Franck, ne devient pas chauffeur de taxi 🙂

AGILE évalue CMMI

La semaine dernière je me suis fait un petit plaisir en m’offrant une formation CMMi pour moi tout seul 🙂

Pourquoi ? Simplement par curiosité intellectuelle et envie d’ouverture, et surtout parceque je voulais faire une évaluation agile de CMMi (Lire plus bas) pour essayer une approche inverse à ce que l’on peut lire un peu partout, c’est à dire la traditionnelle évaluation CMMi de l’Agilité qui démontre que l’Agilité est pas mal … mais doit mieux faire pour être au niveau de CMMI … grrrr …..

CONTEXTE

Il s’agissait plutôt d’une journée de discussion ouverte à 4 sur le thème CMMi et Agilité et le groupe était constitué d’un assesseur CMMi certifié, de 2 préconisateurs de l’approche CMMi et moi-même.
Je connais ces personnes depuis plusieurs années et j’apprécie leur ouverture d’esprit, leur capacité de dialogue et leur intérêt pour l’agilité … même si c’est par le bout de la lorgnette CMMi 🙂

ORIGINES

Coté approches, pas de révélation, elles sont différentes.

CMMi part du principe que les projets sont répétables et qu’il est donc possible de définir un process formel qui, s’il est suivi à la lettre, contribue fortement au succès du projet. D’où l’émergence de CMMi dans les grandes structures institutionnelles avec beaucoup de projets similaires.

AGILE considère que chaque projet est unique ou presque et que l’approche empirique est la meilleure façon d’atteindre l’objectif qui n’est généralement pas connu avec précision au début du projet. Si un cadre structurant existe bien, l’équipe doit se l’approprier et l’améliorer en permanence sans avoir besoin de justifier les décisions proses auprès de directions méthode ou qualité.

SURPRISE

A ma grande surprise, j’ai appris que selon Humphrey Watts, grand ponte du CMMI, cette approche est déjà AGILE puisque, en complément de l’approche organisationnelle (Les Process Area du CMMI), elle dispose du TSP (Team Software Process) pour le fonctionnement en équipe et du PSP (Personal Software Process) pour l’amélioration de l’efficacité personnelle.

En y regardant de plus près, le TSP comporte de nombreuses caractéristiques communes avec l’agilité (But commun pour l’équipe, Implication de toute l’équipe sur les décisions, Négociation des activités, Coopération, Feedbacks …) mais doit s’appliquer, selon l’approche de Watts, dans un process traditionnel par étapes qui n’est donc pas du tout agile.

Pour ce qui est du PSP, j’avoue ne pas avoir vraiment tout compris mais ce que je garde en mémoire c’est qu’il faut une discipline de fer pour le mettre en œuvre (pour soi même) et qu’il s’inscrit également dans une démarche traditionnelle par étape.

EVALUATION

L’évaluation Agile de CMMI a été conduite en utilisant les 4 valeurs et les 12 principes décrit dans le manifeste agile et n’engage que les 4 personnes qui ont fait l’exercice.

Agile evalue Cmmi

BILAN

Donc au bilan, sur 16 points AGILES évalués :

  • 4 points en opposition totale
  • 6 points non traités par CMMi
  • 2 points partiellement traités par CMMi
  • 4 points couverts correctement par CMMi

Et vous, qu’en pensez-vous ?