Étiquette : XP Programming

Comment se déroulent vos revues de code ?

En lisant l’excellent article « What should a good code review look and feel like? » de l’auteur Roy Osherove, j’ai fait une réflexion sur la manière dont j’effectue des revues de code.

 Mon côté « Exteme Programming (XP) » irait de manière pragmatique avec seulement de la programmation en paire, ou « Pair Programming » pour la revue de code. Par contre, dans mon entreprise qui est dans le domaine de la finance, des audits de vérifications de qualité sont nécessaires. Donc, nous utilisons régulièrement une liste de vérifications de conformité que les programmeurs et analystes organiques remplissent lors de la revue de code.

Bien que ceci officialise cette validation, ce n’est pas complet comme exercice selon moi. J’aime bien, en plus de compléter notre liste de vérification, m’assoir quelques minutes avec le programmeur et regarder le code ensemble. Surtout si on parle d’un développement d’un nouveau composant. C’est plus « humain » et je constate qu’il se produit alors un meilleur transfert de connaissance et qu’il s’en suit de bonnes discussions au sujet de code.

Je me demande un peu comment ailleurs on procède lors d’une revue de code, en particulier dans les entreprises où la preuve de la vérification de la qualité du logiciel est requise. Des exemples  ?

Référence:

Publicité

Critique du livre Agile Samurai

The Agile Samurai: How Agile Masters Deliver Great SoftwareUn autre livre sur l’agilité ?

Bon, il parle de quoi ce livre, une autre méthodologie ?

Une autre manière différente d’appliquer l’agilité ?

Non, rien de tout cela.

Ce magnifique petit livre (250 pages environ) ne fait que nous réexpliquer les différentes facettes de l’agilité mais d’une manière un peu spéciale.

Tout est présentement de manière simple, abondamment illustré et drôle par moment.

Voici la description des différentes sections du livre :

  • Dans la première partie du livre, on commence avec la base, soit l’Introduction à l’agilité et la description d’une équipe agile et les rôles que l’on y retrouvre normalement.
  • Dans la deuxième partie, Agile Project Inception, j’ai particulièrement apprécié la section sur le début d’un nouveau projet et les choses à faire afin que l’équipe s’approprie davantage le projet. On y explique diverses activités telles que le Inception Deck, un Elevator Pitch et la conception d’un Product Box. Je vais sûrement tenter d’essayer ces techniques un jour au l’autre.
  • La troisième partie, Planification d’un projet Agile, on discute de User Stories, Estimation et comment être flexible avec le Scope d’un projet.
  • La quatrième partie, Exécution d’un projet Agile, le concept d’itération prend tout son sens et on aborde plusieurs notions pour aider à livrer régulièrement notre produit logiciel. On voit comment les notions des 3 premiers chapitres fonctionnent ensemble. Exemples:
    • Comme quoi faire à l’itération 0
    • Quand faire l’analyse fonctionnelle
    • Communiquer l’information à l’équipe
    • Faire un espace de travail visuel
  • Pour finir, la dernière partie, Création d’un logiciel Agile, on fait la revue des pratiques d’ingénierie Agile connues et éprouvées tels que les tests unitaires, le refactoring, le TDD et l’Intégration continue. Même si je connaissais très bien ces notions, c’était intéressant de les trouver résumé dans le livre en y mentionnant de bons arguments pour les pratiquer.

Donc, on revoit la plupart des notions de l’agilité, ses principes et ses pratiques. Mais remis au goût du jour avec plusieurs illustrations et de nouvelles manières d’expliquer l’agilité. Le livre est raconté de la manière étudiant-professeur (ou plutôt Maître Sensei et Aspirant Guerrier pour rester avec la thématique Samurai) afin de nous glisser de prodigieux conseils tout au long du livre. On sent que l’auteur, Jonathan Rasmusson, a fait plusieurs projets agiles et veux nous communiquer son savoir et ses trucs. Bref, on trouve ici un guide visuel sur l’agilité, rien de moins. Même si vous être expérimenté avec l’agilité, vous avez de quoi à apprendre que ce soit les conseils du maître Sensei ou certaines techniques moins couvertes ailleurs.

Certaines notions ne sont abordés qu’en surface, tels que les Users Stories et le Refactoring,  et pour bien les maîtriser, il faudra peut-être faire d’autre lectures.

Petit point à améliorer selon moi dans le chapitre 2 sur l’équipe Agile. Le rôle « Programmeur Agile » couvre un peu trop large. On aurait dû le diviser avec un autre rôle plus senior genre « Tech Lead » ou « Agile Architect ». C’est certain qu’à la base on veut effacer un peu les rôles traditionnels et rendre l’équipe multifonctionnelle. Sauf que cela prend quelqu’un qui se charge en autre du respect des normes, de coacher l’équipe, de faire le lien avec les autres systèmes de l’entreprise et d’avoir une vue globale de l’architecture.

Merci en passant Pragmatic Press de m’avoir donné une copie ebook du livre en version beta et finale afin que j’en fasse la revue.

Darts

Mes points clefs:

  • Avant de commencer un projet Agile, il a des activités à ne pas oublier
  • Toujours avoir en tête les principes du manifeste agile et comment les appliquer concrètement
  • Scrum et XP Programming y sont mélangés pour ne faire qu’un dans le livre.

Les références:

Scrum vs Scrum

Dans le coin droit, la ScrumAlliance et dans le coin gauche, la Scrum.org.

L’enjeu premier: La certification

Je trouve un peu déplorable ce qui se passe avec ces deux organisations dévouées à promouvoir l’approche Scrum. L’an passé, Ken Schwaber, fondateur de Scrum, quitte l’organisation qu’il a créée, la Scrum Alliance, pour des différents avec les autres organisateurs.

La raison de cette séparation ? Ken Schwaber mentionnait il n’y a pas très longtemps dans un webcast que la Scrum Alliance ne s’est pas bien comporté, tel un mauvais garnement, et s’est un peu égaré en devenant une entreprise voulant faire des profits.

Il fonde alors la Scrum.org et y propose aussi des cours certifiés pour de bonnes sommes d’argent. Bon, jusque là, on peu trouver cela un peu bonnet blanc et blanc bonnet malgré ce qu’en pense Ken Schwaber.

Pour les professionnels œuvrant dans le domaine de l’agilité, c’est un peu embêtant. Ceux qui détiennent déjà une certification avec la Scrum Alliance, comme moi, se demande s’il faut aussi aller chercher les nouvelles certifications de Scrum.org.

La compagnie Pyxis, dont les formations agiles sont une de leurs activités principales, n’ont pas trop le choix et offre les deux types de certifications.

D’une manière générale, on peut aussi se poser la question à savoir si les certifications en valent vraiment la peine ? Bob Martin a écrit un bon article là-dessus ici en questionnant la valeur d’une certification et son influence lors de l’embauche. À lire ici:

Pour moi, je trouve que la certification est un atout, sans plus. Cela prouve que l’on a soit :

  • Assisté à un cours (pour la certification ScrumMaster entre autre)
  • Passé un examen ou un questionnaire d’admissibilité

Il peut y avoir des tas de bonnes personnes avec des certifications et d’autres qui, bien que certifiés, sont moins compétentes.

Mais ce qui est le plus intéressant, n’est pas vraiment tout cette histoire de certification. Regardons de plus près un autre aspect qui est commun chez ces deux organisations:

  • Scrum Alliance: elle prépare une série de cours pour certifier des développeurs Scrum en y incluant les aspects d’ingénierie agile aux notions de Scrum.
  • Scrum.Org: Les premiers cours de Scrum Professionnal Developer sont déjà offert. Avec une alliance avec Microsoft, un cours de 5 jours a été développé pour faire la simulation d’un développement Agile de A à Z avec la nouvelle version de Visual Studio Team System 2010. Seront aussi inclus les notions du XP Programming dans le cours. On mentionne aussi qu’il y aura une version Java pour plus tard.

Ces deux formations semble des plus intéressantes de part leur contenu et la manière de les enseigner. 

Est-ce que vous remarquez quelque chose ? Moi je vois ici que les deux font la même chose et sont en train d’annexer le XP Programming à Scrum. On fait souvent mention effectivement que Scrum ne mentionne aucune technique d’ingénierie agile et qu’il est de bonne pratiques d’inclure des aspects du XP Programming au Scrum. Bob Martin y est même allé de la citation suivante:

XP + SCRUM = XP. SCRUM is a perfect subset of XP that wants to become XP.

Tandis que Ken Schwaber mentionne, dans le même webcast mentionné plus tôt, que XP est en train de disparaître malheureusement et que Scrum est un des seul processus les mieux définis.

Bref, au lieu de promouvoir l’agilité sous une seule bannière, on est divisé par cette petite guerre. Pourtant, le fait d’inclure les pratiques du XP Programming est en soi une évolution normale et souhaité selon moi. Mais de là à vouloir faire disparaître le XP Programming…

Qu’en pensez-vous ?

 

Références pour ce billet: