InfoQ 3: An Alternative to Certifications

Last but not least!

3ème article sur InfoQ


An Alternative to Certifications

Question chère à Claude Aubry et au SigmaT.

Une approche différente de la certification Agile, proposé par Ron Jeffries.
Un recentrage sur les compétences réelles nécessaires et acquises : Developer-Focused Certification (CSD)

Les objectifs sont fixés :

• Etablir une photo évolutive des compétences requises pour une équipe Agile (tient ! une certif d’équipe, bonne idée)
• Encourager la formation continue à long terme
• Etablir un réseau de confiance aidant les membres à se « retrouver » et identifier de nouveaux mentors dans la communauté

Le groupe propose un inventaire des compétences axé sur les points suivant :
Business Value, collaboration confiance, produit, self improvment (pas trouvé de traduction !), Supportive Culture (la non plus ! tellement explicite en Anglais), et excellence technique.

Ça ressemble un peu à notre outil GPS dont nous nous servons chez Valtech dans les phases de transformation ver l’Agilité.

Le projet est hébergé chez google : Agile Skills Project

C’est fortement connoté open source, en licence Creative Commons, mais je n’ai pas réussi à modifier une page ???

InfoQ 2 : Manifesto of done

2ème article sur InfoQ

A Manifesto of done

Alixx Skevington propose une "liste de critères", que je considère plus comme une liste de vœux ou de souhaits:

Je vais faire en sorte que mon code soit utilisable
Je vais faire en sorte d'écrire du code conforme au style défini par l’équipe
Je vais faire en sorte que mes méthodes soient de taille raisonnable
Je vais commenter tout mon code
Je suis d’accord pour tester mon code (Tests unitaires)
Je suis d’accord pour maintenir mes tests unitaires sur le code existant
Je suis d’accord d’essayer de maintenir une couverture de code à 80%
Je suis d’accord pour vérifier que mon code s’intègre correctement

S’en suivent quelques commentaires rajoutant ça et là de nouvelles règles.
De « Je vais repasser mes tests unitaires avant de commiter »
jusqu’à, à propos des commentaires de code « …, les commentaires mentent, … »

Mais ça veut dire quoi code utilisable ?
Conforme au style défini par l’équipe, c’est checkstyle ?
Les tests unitaires, quelle stratégie ? On teste tout, et on essaye de le maintenir.
La couverture à 80%, pourquoi ? Les 20% qui restent ne servent pas, n’ont pas de plus value au produit ? Le temps de définir quelles exigences font parties de ces 80%, n’aurait-on pas mieux fait de tout couvrir ?

Le fait que ces bons vœux ne sont pas précisément définis, va engendrer surcharge de travail pour essayer de contrôler la bonne tenue de ces critères.

Mais c’est pas du bon sens tout ça, voir même « nominal » pour tout développeur qui se respecte et respecte les autres membres de l’équipe avec qui il travaille.

Jay Packlick remet de l’ordre :
« Tout critère d’acceptance définissant le ‘done’ pour une feature doit être exprimé en tests et être passé ».

InfoQ 1 : Agile Documentation : Is there Clarity

Aujourd’hui 3 excellents articles sur InfoQ

Agile Documentation: Is There Clarity?
Réflexion sur la 2ème valeur Agile : « Working software over comprehensive documentation ». Agile Manifesto

L’auteur Amr Elssamadisy relate le process documentaire proposé sur le blog ZenAgile.

Ce blog défini le process suivant :

• Articuler le contexte via les personnes, des scénarios, et des diagrammes de contexte,
• décrire les exigences avec une cartographie des processus et des matrices de traçabilités,
• documenter les solutions avec des modèles de données, des plans de site, la conception de navigation, et d’IHM,
• valider les solutions à l’aide de prototypes, l’acceptation intervient ici, de manière itérative
• et documenter les builds incluant le code, la stratégie de test, et le modèle physique de données.

C’est très connoté UML et UP. Cela peut être une solution.

L'auteur en arrive à la conclusion suivante :
Avons-nous un consensus ou au moins un même courant de pensée sur le sujet de la documentation ? Difficile à dire sur un sujet sur lequel il y a peu d’écrits ? Le sujet est peut-être trop évident pour en parler ? Ou au contraire tellement complexe, que nous n’en avons aucune idée.

Mais la réponse vient en fait d’un commentaire posté par Markus W.

"Sometimes I feel that Product Owners are too distracted (or too lazy) to be fully involved in the development even though this is the fundament of the product's success. For them agile is just another tool like jira. So their backdoor is in the documentation:On one hand they can give account to customers and accountants about the project's progress and on the other they have a basis to be pedantic about variations which gives them the feeling to still have control of what's happening.The general problem is that most of the time decision makers are untrained and therefore not fully aware of the concepts of an agile development process. Under pressure they are unable to use and trust the benefits and then automatically fall back to, for them, well known concepts they have learned 20 years ago: The power and knowledge is in the documentation. "

En résumé, il estime que les clients ont du mal à s’adapter à leur nouveau rôle, le product owner, et qu’ils se retranchent par facilité derrière les bonnes vielles pratiques.
Je vois ça tous les jours avec les responsables « qualité », qui plutôt que de s’adapter, adapter leur process, innover, trouver les réponses « Agiles » aux exigences de la norme, nous ressortent les sempiternelles matrices de traçabilité, de conformité, sans même jamais aller vérifier le contenu en détail.

L’expérience, la formation, l’implication, la responsabilisation des product owner. Voilà la clé.

Prochain billet sur : A Manifesto of Done

SigmaT13, des cadeaux à gagner

Vendredi 19 mars prochain, à 16h aura lieu la 13ème édition du séminaire SigmaT

En plus d'avoir un excellent orateur, Hervé Desaunois, une superbe demo en live par David Gayerie, une guest star internationale en la personne de Bruno Sbille from Belgique et un apero offert par l'IUP ISI,

Vous aurez aussi la chance peut-être de repartir avec un exemplaire du livre de Claude Aubry(1) ou de Thierry Cros(2), offerts par leurs éditeurs à l'occasion de ce grand événement.

Un tirage au sort aura lieu.
Seules les personnes présentes au séminaire et préalablement inscrites pourront participer au tirage au sort.
Je vous incite donc vivement à vous inscrire sur le site : http://www.sigmat.fr/dotclear/index.php?form/inscription

(1) Scrum, le guide pratique de la méthode agile la plus populaire
(2) Maîtriser les Projets avec l'Extreme Programming

Agilité à Toulouse, Sigmat13

Le programme du SigmaT 13.

Le séminaire comportera trois sessions comme d'habitude[1], un retour d'expérience et deux autres exposés incluant aussi une part de retour d’expérience. Voici les présentations sélectionnées, dans l'ordre de passage le 19 mars :

• Refactorer votre Project Manager par Hervé Desaunois.

Hervé vous présentera une synthèse du changement opéré par 8 chefs de projets pour devenir de véritables ScrumMasters.
Résumé : En privilégiant l’aspect humain au processus, le ScrumMaster se démarque du chef de projet habituel. Cette présentation relate la métamorphose de 8 chefs de projet en véritables ScrumMasters. Par ailleurs, pour passer d’une organisation cloisonnée en silos à une véritable équipe Scrum, la conduite du changement ne doit pas être brutale. Il faudra peut-être plusieurs itérations, voire plusieurs projets. La clé de la réussite de cette transition réside dans l’accompagnement constant des leaders des projets.
Hervé est Directeur Opérationnel de Valtech Toulouse

• Automatiser les tests de validation avec Fitnesse par David Gayerie

David exposera les enjeux de l’automatisation des tests de validation, proposera une démo de l’outil FitNess, et vous fera part de son expérience de mise en œuvre sur deux projets.
Résumé : FitNesse est un outil dédié à l'automatisation des tests de validation. S'il peut sembler déroutant de prime abord, il se révèle extrêmement efficace dans le contexte d'un projet Agile. Il se présente comme un Wiki et permet donc à l'équipe de gérer le plus librement possible la base de connaissances du projet. Il intègre surtout un moteur capable d'exécuter des portions de code appelées Fixtures à partir du contenu d'une page. Il est donc possible d'automatiser des tests de validation tout en conservant un vocabulaire proche des besoins fonctionnels. Il y aura une démonstration de FitNesse. Sera évoqué également l'apport de cet outil dans sa mise en oeuvre sur deux projets différents au cours de l'année 2009.
David est consultant chez astek SO

• Retour d’expérience sur la création de deux portails Web avec Scrum par Bruno Sbille

Bruno présentera son expérience de transition d’un cycle de développement en cascade vers la mise en œuvre de Scrum pour l’administration publique Belge.
Résumé : En un an et demi nous avons réalisé 3 versions successives de deux portails Web pour l'administration publique Belge. Comment en partant d'un projet initialement de type Waterfall nous sommes passés en mode Agile Comment avons nous su faire du Scrum avec des fonctionnaires Comment d'une situation de méfiance du client nous sommes passés à une Success Story, avec en apothéose...un ministre à une Démo de sprint Quelles leçons pratiques tirons nous de tout ceci en ce qui concerne: le people management, Scrum/Agile, La gestion de projet, la dynamique d'équipe
Bruno est dans la consultance ICT & Business depuis plus de 10 ans.

Le séminaire aura lieu le 19 mars à 16h à l'amphi 3 de l'université Paul Sabatier à Toulouse, inscrivez-vous vite !

Notes
[1] ce qui est aussi devenu une habitude, c'est l'apéro après les présentations