Agile Tour Toulouse 2011

Message de la SigmaT, organisatrice de la session Toulousaine de l'Agile Tour :


Bonjour à tous,

La SigmaT est heureuse de vous annoncer la quatrième édition de
l'Agile Tour Toulouse qui se tiendra le mercredi 19 octobre 2011 au
Centre de Congrès Diagora, à Labège.
L'Agile Tour Toulouse a pour objectif d'être une journée de formation,
d'échange, de partage d'expérience, de réflexion et de rencontre
autour de l'agilité.

La manifestation est ouverte à un large public désireux de découvrir
les bénéfices ou de renforcer ses connaissances dans le domaine de
l'Agilité. La cohabitation des expériences et des compétences, la
convivialité de l'organisation favorise la discussion entre les
acteurs pour faire de cette journée un temps fort à vocation
applicative pour chacun. Managers, Enseignants, DSI, Responsables RH,
Architectes, Chefs de projet, Responsables qualité, Acheteurs,
Développeurs trouveront ainsi des réponses pratiques à des problèmes
concrets.

Cette année nous avons souhaité orienter le programme suivant trois
axes majeurs :
 * initiation : une série de présentation et d'ateliers permettant
d'appréhender l'agilité et l'intérêt que cela peut avoir. Ce parcours
s'adresse à tous les curieux qui veulent savoir ce qu'est cette
"agilité" dont on parle un peu partout en ce moment.
 * humain et social : mise en place des équipe et des projets,
retours d'expériences. Ce parcours s'adresse aux DSI, gestionnaires de
projet, managers ou chefs de projet.
 * ingénierie : les techniques pratiques qui permettent de bien
réaliser le bon produit. Un parcours riche qui intéressera autant les
développeurs que les responsables de produit.

Une quatrième série regroupe des sessions abordant des sujets très
divers comme les rapports entre agilité et CMMI ou un intéressant
retour sur des cas dans lesquels Scrum n'a pas marché.

Évidemment, vous pourrez, à votre guise, composer votre programme
personnel en mixant les sessions des différents parcours.
De larges pauses, entre chaque session, vous permettront d'échanger
plus longuement avec les orateurs et les autres participants.

Cette conférence sera aussi l’occasion de participer au lancement du
club des Utilisateurs de l’agilité en Midi-Pyrénées.
L'agilité est maintenant "mainstream" et questionne les Utilisateurs.
Ce club - commission de l'association indépendante SIGMAT - a pour but
de réunir toute personne engagée en agilité côté Utilisateur et ou
Manager. Pourquoi ? Pour échanger des expériences, travailler ensemble
à des sujets concrets tels que "contrat agile", "SSII et agilité" ou
"rôle du Client".
Le Club pourrait ensuite fonctionner sous forme de réunions régulières
dans le cadre de l'association SIGMAT.

Détails et inscription sur le site http://www.agiletoulouse.org

à bientôt
--
antoine, pour l'équipe d'organisation de l'agile tour toulouse

A-TDD avec Robot Framework

A-TDD with Robot Framework de Craig Larman et Bas Vodde.
Traduction disponible ici.
Original disponible sur le site de RobotFramework.

La racine carrée de la somme des carrés

Houa, ça fait peur!

C'est juste une méthode utilisée pour calculer les buffers de contingence. (Schedule buffer). La marge de temps couvrant les risques.

Ça ne date pas d'aujourd'hui, mais comme je n'avais rien trouvé sur le sujet en Français, alors voilà.

Apparu dans le livre "Agile Estimating and Planning" de Mike Cohn en 2005.

Le but étant de savoir comment garantir un planning avec suffisamment de fiabilité. Mike Cohn propose d'ajouter un buffer de temps (et aussi  un buffer de fonctions, Feature Buffer).

Question : Comment calculer ce buffer.
Réponse : La racine carrée de la somme des carrées des différences.

Mouais, pas trop avancé avec tout ça. C'est pourtant simple.

Imaginez une liste de fonctions à produire: F1, F2, ...
Vous estimez la charge moyenne de chaque fonction. En point fibonacci et planning poker bien entendu ;-). Cette estimation est considérée comme une valeur moyenne, fiable à 50%.
Ensuite, re-estimez le plus mauvais cas, en prenant en compte tous les risques éventuels. Lors du planning poker, on pourrait garder la valeur la plus forte votée. Vous pouvez considérer cette estimation fiable à 90%.

Ensuite, vous prenez votre excel préféré et :

Fonction	50% (a)	90% (w)	(w-a)²
F1	3	5	4
F2	5	8	9
F3	2	5	9
F4	5	13	64
F5	8	13	25
F6	1	1	0
Somme	24	45	111

(a) = average, moyenne, (w) = worst, plus mauvais cas


La somme des carrés des différences faisant 111, la racine carrée est égale à 11 (arrondie)
Le buffer à considérer est donc de 11.
Le total de l'estimation est donc de 24 + 11, soit 35. 10 points de moins que le total des estimations à 90% de fiabilité.

Tout ça c'est des mathématiques, et par définition les estimations étant fausses, ça n’empêche pas de continuer à réfléchir.

A la prochaine.

Intérêt de l'automatisation des tests

Suite à la lecture du billet sur l’intégration continu, un internaute voulait savoir comment vendre l’intérêt de l’automatisation de tests. Voici la réponse que je lui ai faite :

D'abord, on va parler argent, puisque c'est pour vendre!

Il faut voir pourquoi l'automatisation ne doit pas être vu comme un surcoût.

Dans un cycle de développement classique (V, cascade, RUP), il n'y a qu'une phase de livraison en fin de développement. De une à 4 par an, souvent.

Dans un cycle itératif (Agile, Lean), il y a un livraison possible au minimum à chaque fin d'itération : de 12 à 24 fois par an.

Le coût de l'automatisation est donc divisé de 6 à 24 fois.

Et de plus de 220 fois (nombre de jours ouvrés) pour ce qui est des tests unitaires passés au minimum 1 fois par jour.

Pas négligeable quand même.

Ensuite, les approches Test Driven (TDD, TDR, A-TDD) sont réputées pour diminuer le taux d'erreur et d'insatisfaction.

Taux d'erreur = bugs

Taux d'insatisfaction = incohérence aux réels besoins métiers, pas forcément à la spec

Leur automatisation garanti donc ce contrôle en continu. Et vous avez raison, aide au contrôle des effets de bords et à la fiabilisation.

Ces tests apportent aussi une "documentation" efficace du produit pour la maintenance de celui-ci:

Un nouveau développeur ou une nouvelle équipe sur un produit aura plus d'assurance de compréhension, de maintenabilité et de pérennité qu'en lisant la spec détaillée. Là aussi, gain économique si les charges sont favorisées sur les tests unitaires plutôt que sur de la doc inutile.

Côté fonctionnel, c'est un peu différent:

Pour moi, les tests fonctionnels sont là pour valider le produit au sens métier.

Si vous utilisez les pratiques TDR et/ou A-TDD, c'est extrêmement efficace et souvent peu coûteux de les automatiser.

Pour faire court, en A-TDD la spécification fonctionnelle est remplacée par des scénarios de tests. Leur automatisation est supportée par de nombreux outils (QTP, robotframework, ...).

Sinon, il est tout à fait possible d'automatiser des scénarios de tests "standards", mais leur maintenance peut s’avérer plus coûteuse, s'ils n'ont pas été pensés pour : Factorisation des cas de tests, double écriture des tests, par le métier dans un outil, puis par les développeurs dans l'automate de test.

Je conseille fortement dans ce cas l'utilisation d'outils dit "keyword driven", tels que robotframework, qui permettent d'utiliser le même outil pour les deux mondes.

Leur automatisation favorise donc effectivement la non régression et peuvent être utilisés sur des tests de performances et de montée en charge.

Le jour où le word s’arrêtera de tourner

Ras le bol des documents. 

On se surcharge de travail pour simplement fournir une preuve en cas de contrôle. Les plans projets, les doc de specs détaillées, les plans de gestion de conf, .... Quel développeur a déjà lu ces types de documents, non pas parce qu’il le devait, mais qu’il en avait besoin, pensait y trouver l’information.

L’information est nécessaire.
La capitalisation de l’information est nécessaire et indispensable, bien sûr. Je ne remets cela en cause d’aucune manière. C’est juste l’outil qui me hérisse le poil. Word c’est pour écrire des bouquins, pas des logiciels. Seul derrière son écran, pas en collaboration avec les collègues.

Ne pas confondre la réflexion et la persistance de la réflexion.

Un document a un propriétaire : l’auteur. Si le lecteur y trouve des incohérences, des erreurs ou seulement veut l’amender de sa propre expérience, il ne le fera pas, sauf contraint bien sûr.

On me rétorque à chaque fois qu’il faut documenter pour les générations futures. D’abord, il n’y a cas ne pas changer d’équipe à chaque fois qu’on fait une nouvelle version du produit, ça c’est dit ! Penser produit pas projet. Et puis, quand je reprends une application développée par d’autres, je préfère de loin avoir des tests unitaires me garantissant que je ne vais rien casser qu’une documentation dont je ne sais même pas si elle est à jour.

Moi je préfère le wiki !

Avec des pages courtes, un sujet par page.

Une organisation par liens, comme le net. Pas d’organisation au format document (chapitre, sous chapitre…), préférer des pages organisant les liens par séquence d’exécution ou de lecture, d’apprentissage … Utiliser les balises pour simplifier la recherche et l’organisation.

Autoriser et favoriser toute l’équipe à participer, modifier, commenter, amender.

Tout comme le code, refactoriser vos pages de temps en temps.  Si vous avez peur de supprimer une page, baliser la « obsolète » quelque temps.

Et pour ce qui est des « générations futures », le wiki a tout ce qu’il faut, export, sauvegarde, impression…

Amis agilistes, à vos wiki!

Lean Primer

Lean Primer de Craig Larman et Bas Vodde.
Traduction de Fabrice Aimetti et moi même.
Disponible ici ou sur le wiki de Fabrice.

AgileTour Toulouse 2011 : Inscriptions ouvertes

Ça y est, c'est parti.

L'inscription en ligne pour l'Agile Tour Toulouse 2011 est ouverte.

Cette année c'est 20€ pour les frais de repas (entre autre).

Paiement par carte bancaire.



Valtech est sponsor Gold sur cette édition locale.

J'y présenterai avec mon collègue Lionel Molas, un retour d'expérience sur "Agile à l'échelle".
Comment démarrer un projet en Agile, avec 70 personnes au début, 9 équipes, 3 sites, en 1 semaine et faut que ça tienne 2 ans quand même.