Agile Tour 2012: Des gens passionnés au rendez-vous

Nous étions plus de 400 participants, bénévoles, présentateurs et organisateurs à l’Agile Tour Québec 2012 cette année. 400 passionnés, curieux et avides d’information et d’échanges avec ses pairs.

Ce fut une belle journée et un plaisir de côtoyer tous ces gens pour cette 4e édition (!) pour la ville de Québec de cette journée de conférences consacrées au développement Agile.

(Cette photo a été prise par Isabelle Therrien, Coach Agile chez Agile Partnership)

J’ai bien aimé la conférence principale, ou « Keynote », de cette année à l’Agile Tour 2012. Le conférencier, Jonathan Rasmusson, nous a servi une plénière forte intéressante. Il nous a partagé son expérience avec les deux histoires suivantes:

« Who moved my Agile cheese ? / Qui a déplacé mon fromage Agile »

En s’inspirant un peu du livre « Who moved my cheese ? », Jonathan abordait le thème du changement. Même les gens « Agiles » peuvent être confrontés à celui-ci et parfois, l’agilité n’est pas toujours la solution. En écrivant son livre, Agile Samurai, il a tenté de le faire à la sauce Agile, en itérations, « User Stories » et autres artéfacts de l’agilité. Mais, ce qui a marché le mieux, c’est d’aller à son café de 6h00 à 8h00 et de travailler sur son livre avant de se rendre au travail. Il a du changé sa manière de faire « Agile » pour y aller d’une autre manière plus efficace pour lui. Pourquoi cela a marché ? Selon lui, c’était tellement une idée personnelle, que ce n’était pas pour lui vraiment du travail. Le travail avait arrêté d’être du travail est était devenu une forme d’art pour lui.

Le changement est un phénomène naturel et cela va nous arriver un jour ou l’autre. Même l’agilité risque changer dans les années à venir.

« Tests unitaires = Qualité. Vraiment ? »

JonRasmussonEst-ce que les tests unitaires sont les seules garanties de qualité ? En s’introduisant dans la communauté des développeurs d’applications avec iOS, Jonathan a découvert que les tests unitaires et l’intégration continue n’étaient pas pratiqués régulièrement. Seul le « refactoring » semble être présent. Pourtant, la qualité du travail était au rendez-vous, et ce, sans tests unitaires… Comment est-ce possible ? L’attention et le souci du détail de Apple dans ses produits ainsi que sa communauté de développeurs attentionnés y est pour quelque chose selon lui.

Bien qu’il croit toujours à l’importance des tests unitaires dans certains contextes, un autre aspect vient influencer davantage la qualité: La passion et l’attention des « artisans » à faire le meilleur produit qui soit.  Bref, la qualité est plus que des tests unitaires (mais ces derniers sont toujours très important). Il a mentionné aussi quelque chose d’intéressant. La communauté Agile et la communauté des développeurs de logiciels Apple (ou iOS) pourraient s’échanger un truc ou deux pour que chacun s’améliore.

En conclusion, c’était moins flamboyant que l’an passé avec Robert C. Martin, mais la conférence m’a touchée davantage. C’est bien beau parfois d’avoir des gourous qui nous montre leur savoir et la bonne manière de faire les choses, mais c’est bien aussi de faire changement dans le type de présentation. Jonathan nous a plutôt ramené à la base en nous parlant de ses récentes expériences professionnelles. Et je résume cette base à retenir de cette manière:

Avoir des gens passionnés et qui veulent prendre soin de leur travail, c’est un pas de plus pour obtenir un résultat de qualité. On peut apprendre toute sorte de notions sur l’agilité à pratiquement n’importe qui. Mais on ne peut pas leur apprendre à prendre soin de leur travail.

Références :

Publicité

La pause est terminée

PlayMon dernier billet remonte à quelques mois déjà…

L’été a passé vite, puis la rentrée scolaire des enfants, des rénovations à la maison, un bébé chien à éduquer. L’habitude d’écrire s’est perdue un peu.  C’est un de mes vieux amis, Laurent, qui me le fait remarqué l’autre jour:

Heille Karl, je me suis abonné à ton blogue, mais je trouve qu’il n’y pas trop de publications ces temps-ci…

Ouch, cela m’a réveillé d’un coup. Mais, au lieu de repartir rapidement, je voulais prendre le temps d’avoir plusieurs idées de billets. C’est là que je suis rendu.

Donc, vous verrez dans les prochaines semaines de nouveaux billets. Je vais aussi faire un sondage sur les sujets de mon blogue qui vous intéressent le plus, histoire de mieux cibler mes efforts.

Mon objectif est de publier environ une dizaine de billets d’ici le reste de l’année.

Les habitudes viennent et repartent. C’est à nous d’être vigilant et voir lesquelles garder, reprendre ou abandonner.  C’est donc important de revoir régulièrement ses objectifs.

Refonte de mon blogue

OpenPour commencer, quelques statistiques sur mon blogue:

  • 72 billets rédigés, quelques pages et plusieurs commentaires
  • 2 ans sur WordPress et six années au total pour mon blogue.

Après tout cela, une petite refonte s’imposait…

Alors, je vous souhaite la bienvenue dans mon nouveau blogue !

Voici en gros les quelques changements

Et voilà !

Qu’en pensez-vous ?

Référence :

Quelques lectures gratuites

J’ai fait quelques lectures intéressantes dans le dernier mois et je voulais vous en parler. Les petits documents mentionnés dans le tableau plus bas sont à mi-chemin entre un article et un petit e-book. Donc, assez facile à lire.  Les trois couvrent des sujets totalement différents, mais qui peuvent intéresser plusieurs. De plus, ils sont tous gratuits et téléchargeables. Les voici donc:

Getting Started with Kanban par Paul Kipp

Get started with Kanban, a free eBook by Paul Klipp

Petit document qui résume bien ce qu’est l’outil ou la technique Kanban. Utile si vous ne connaissez rien au Kanban ou pour le résumer à quelqu’un d’autre.Issue de la méthodologie « Lean », le Kanban peut être appliqué dans plusieurs domaines: informatique, ingénierie, vente, tâches familiales, études, gestion, etc.

En gros, le Kanban consiste à suivre les 3 règles suivantes:

  • Visualize Workflow
  • Limit Work in Progress (WIP)
  • Measure and Improve Flow

 

The New Time Management

par Francis Wade

45

Intéressante lecture qui nous suggère de revoir les 7 principes fondamentaux de la gestion du temps. Malgré les outils et techniques, si on ne maîtrise et si on ne pratique pas la base, on risque d’être davantage stressé et plus ou moins productif.L’auteur mentionne qu’il est normal d’essayer de nouvelles techniques, de se mesurer et de s’ajuster régulièrement. Tout cela dans le but de trouver la bonne solution selon notre style de vie professionnelle et personnelle.

Donc, pas de recette unique pour tout le monde.

The Accountability Effect

par Basam Tarazi

image

Introspection pertinente sur qui nous sommes, nos buts dans la vie et l’importance de prendre soin de nous même. Sinon, la vie passe vite et on risque d’accumuler plusieurs regrets.Aucun « timming » n’est parfait pour faire les choses dont on parle souvent. L’auteur nous montre ce qu’il faut être « présent » et prendre les responsabilités de nos actions ou le manque de celles-ci.

Lecture très intéressante qui amène des réflexions que nous n’avons malheureusement pas assez souvent.

 

Bonne Lecture !

 

Notes de Lecture: The Art of Unit Testing

J’ai lu ce livre il y a un an ou deux, mais il est toujours d’actualité et je trouvais important de vous en parler. D’une certaine manière c’est toujours bon de revoir ses bases de temps à autre. Ce livre est en quelque sorte un « must » pour tout développeur, notamment ceux qui font du .Net. Il existe aussi une version inspirée de ce livre chez le même éditeur avec les exemples en Java intitulé « Unit Testing in Java » qui sera publié cette année.

Premièrement, pour bien situer ce livre, ce dernier se concentre surtout sur l’aspect « Test unitaire » et non le TDD (Développement piloté par les tests). Ce dernier y est mentionné un peu, mais l’accent de ce livre n’est pas tout simplement pas sur cet aspect.

L’auteur, Roy Osherove,  nous fait découvrir de manière pédagogique plusieurs notions essentielles lorsque l’on veut progresser dans les tests unitaires, notamment vers des cas plus complexes. Et ce, dans l’environnement de développement .Net, malgré que la plupart des notions peuvent être adaptées pour un autre environnement de développement orienté-objet.

Le TDD avec des cas simples c’est bien beau et facile, mais cela peut se corser assez vite merci. On y voit alors dans ce livre plusieurs trucs, notions et techniques tels que:

  • Les techniques de base
    • Les Stubs
    • Les Mocks
    • Les différents frameworks d’isolation
  • Le code de test
    • L’organisation et la hiérarchie des tests…
    • Les bonnes pratiques pour les tests
  • Processus et conception
    • Intégrer les tests dans l’organisation
    • Travailler avec du « Legacy Code »

J’aime le fait que l’auteur dans les premiers chapitres s’occupe de bien définir les termes essentiels qui seront utilisés tout au long du livre tel que:

  • Test Unitaire
  • Test d’intégration
  • State-based testing / vérification d’état
  • Interaction testing / vérification de l’interaction avec d’autres objets
  • Système sous test
  • La régression
  • C’est quoi du « Legacy Code » ? (en fait c’est du code sans tests unitaires)
  • Refactoring
  • Seams
  • Fake
  • Dynamic Fake

Point que je trouve important et qui est aussi abordé dans ce livre, c’est comment nommer nos méthodes de tests. J’aime bien la formule que l’auteur suggère, soit de nommer en trois parties séparées par le caractère « _ »:

  • Nom de la Méthode
  • État du test
  • Comportement prévu

Ex.: IsValidFileName_ValideFile_ReturnsTrue()

Si vous avez beaucoup de tests dans votre projet, vous allez voir que ce type de nommage aidera le classement et permettra de facilement déduire le test d’après son nom.

Le Pattern AAA est aussi abordé dans le livrer et c’est un de mes préférés. Donc, je vais vous en parler un peu. Il s’agit en fait de faire notre méthode de test en trois « sections » fonctionnelles qui sont les suivantes:

  1. Arrange: On prépare les variables nécessaires et autres préalables.
  2. Act: Action sur l’objet ou la méthode que l’on teste
  3. Assert: On compare le résultat attendu versus celui obtenu.

Exemple:

[Test]
 public void CalculateSalesBonus_VendorWithSalesBonus_BonusMade()
 {
 // Arrange
 int salesNovember = 10000;
 var calculator = new BonusCalculator();

 // Act
 var result = calculator.CheckBonus(salesNovember);

 //Assert
 result.ShouldEqual(100);
 }

Un aspect important quand on établit notre code de test, c’est de commencer par l’assertion (et oui, on commence par la fin !). Cela rend plus clair par la suite la réalisation des étapes d’Arrange et d’Act. Ce conseil me vient de JR Rainsberger que j’ai eu l’occasion de rencontrer au Code Retreat à Québec en 2011.

Personnellement, je trouve que faire des mocks peut parfois être utile, mais il faut faire attention car cela peut nous amener à faire beaucoup de code. J’aime bien dans ces cas appliquer la règle de Pareto, ou celle du 80/20, c’est-à-dire qu’on ne fera pas du code 80% plus gros pour tester un 20% de notre application. Il faut y aller alors de manière pragmatique.

L’auteur parle aussi au chapitre 8 des manières d’introduire les tests unitaires automatisés dans une organisation, encore là, une bonne section du livre. Le facteur humain n’est pas à négliger ici, car le TDD et les tests unitaires, qui introduisent une nouvelle manière de concevoir notre code, peuvent provoquer des bouleversements au passage.

Bref, si vous faites du développement avec .Net ou Java, et que particulièrement vous trouvez que c’est dur de faire des tests unitaires (et vous avez raison, car ce n’est pas une mince tâche), ce livre peut vous aider.

J’ai fait un résumé des idées de ce livre (avec une certaine adaptation) dans le mind map suivant (cliquer pour l’agrandir) :

 

 

 

 

 

 

 

Mes points clefs:

  • C’est important de bien connaître les techniques de base (stub, mock et framework) afin de progresser dans la programmation des tests unitaires
  • Organiser les tests (nomenclature, projets), n’est pas à négliger pour établir un standard dans l’équipe de programmeurs
  • Pour implanter le TDD et les tests unitaires dans une organisation, il faut être prêt. Ex.: répondre aux questions, identifier les champions, gérer avec les « bloqueurs, avoir des buts spécifiques, etc.

 

Références:

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:

Est-ce que vous tenez à votre équipe ?

J’ai assisté mercredi soir dernier à la conférence de François Beauregard intitulé « De l’individu à l’organisation en passant par l’équipe« . C’était dans le cadre des conférences mensuelles organisées par Agile Québec.

J’ai été particulièrement interpellé lors du sujet de la structure d’équipe. François a cité ceci (sans les mots exacts toutefois):

Il arrive parfois qu’on saborde les bonnes équipes à la fin des projets. C’est comme si au hockey, on prenait l’équipe qui a gagné la coupe Stanley, et on la divisait en donnant un joueur à chaque autre équipe.

J’ai vécu cela souvent dans le passé lorsque j’étais consultant et je le vois malheureusement encore dans mon travail actuel en tant qu’employé permanent dans une entreprise privé.

Je me rappelle, lors d’un de mes anciens projets il y a quelques années, que l’on avait une des meilleures équipes. Elle était d’ailleurs qui était composé ainsi:

  • 3 Programmeurs
  • 1 Analyste fonctionnelle
  • 1 Architecte Logiciel /  Scrum Master
  • 1 Chargé de projet

Au besoin, on pouvait avoir accès à d’autres personnes pour nous aider dans un aspect où l’on était moins expérimenté. Par exemple avec les bases de données, on se débrouillait bien. Mais, si on avait quelque chose de plus corés à faire, on pouvait avoir accès à un DBA pour nous aider. Notre équipe se complétait bien ainsi.

Après plusieurs sprints où l’équipe a vécu des hauts et des bas, des rétrospectives, des apprentissages, des démos aux clients, l’équipe était rendue très unie et pouvait pratiquement affronter n’importe quel défi selon moi. Elle était devenue un peu comme une « super-équipe ». Mais le projet fut terminé, les personnes séparées dans différents projets selon les affectations et avec pour résultat: plus de super-équipe !

Je suis certain que si on avait fait des efforts pour la garder intacte et la déplacer de mandat ou de client, elle aurait été très performante, car plusieurs aspects étaient maintenant acquis. Les gens se connaissent bien, il y avait une chimie qui s’était créée. Mais pourquoi on ne veut pas tenir à ce genre d’équipe au sein de certaines entreprises ?

Je travaille maintenant pour une entreprise privée et je vis parfois la même chose. Avec le mélange de personnels permanents et de consultants, dont les contrats qui se termine à différents moments, c’est une belle jonglerie que de garder une bonne équipe intacte.

Comment régler ce problème ?

Je ne crois pas au « responsable unique » en général dans la vie et c’est le cas ici je crois. Les gestionnaires et directeurs ont des contraintes de budget et de ressources à gérer. Ils font de leur mieux en dépit des circonstances. Toutefois, si ce n’est pas le cas, ils ont peut-être à se à se rapprocher des équipes de temps en temps pour mieux comprendre ce qui se passe.

Du côté des équipes de projets, il faut qu’ils sensibilisent les gestionnaires au fait que l’équipe est très bien comme cela et qu’il faut la garder intacte autant que possible.

En bref, le facteur humain étant ce qu’il est, il ne doit pas être géré comme une ressource, mais plutôt de manière organique. J’aime bien la métaphore que Francçois Beauregard a utilisée pour illustré ceci:

La gestion d’une équipe, c’est comme faire grandir un beau jardin.

Ceux qui vivent parfois cette problématique, est-ce que vous voyez d’autres solutions ? N’hésitez-pas à laisser vos commentaires sur ce billet.

Références :

Sondage Développeurs Québec 2012

Quoi de mieux que de commencer l’année avec un petit sondage pour les programmeurs afin d’en savoir davantage sur le profil de notre profession !

L’idée de ce sondage m’est venue lors de la conférence principale de l’Agile Tour Québec 2011 par Robert C. Martin. Ce dernier, au début de sa présentation, avait fait un sondage éclair à main levée parmi les participants afin d’en savoir plus sur les technologies utilisées et les pratiques connues. La foule n’était pas composée à 100% de développeurs et donc les résultats peut-être un peu faux à ce moment.

Histoire d’en avoir le cœur net, j’ai préparé le court et simple sondage suivant:

Remplissez mon sondage !
Merci d’avance de participer à ce sondage, en particulier si vous avez un des profils suivants ou que vous programmer à l’occasion:

  • Développeur/Programmeur
  • Chef d’équipe
  • Architecte Logiciel
  • Testeur
  • Coach
  • Formateur
  • Entrepreneur

Les résultats du sondage seront publiés sur ce blogue dans quelques semaines. Merci d’y participer.

Mon Bilan 2011 et Mes objectifs 2012

1335434_new_year_3Je crois qu’il est bon de faire notre bilan une fois par année et de mettre nos objectifs en ligne. Cela nous donne une petite pression intérieure pour les accomplir. C’est le but du présent billet et j’espère que cela vous donnera aussi l’idée de vous fixer des objectifs et d’en parler à votre entourage ou de les énoncer publiquement dans votre blogue par exemple.

J’aime bien commencer par un petit bilan histoire de bien positionner mes objectifs. 2011 fut une grosse année, et épuisante par moment, sur plusieurs volets. Néanmoins, je suis fier des résultats et 2012 sera sûrement une bonne année aussi.

Mes réalisations en 2011:

Emploi actuel:

  • Dans mon emploi, j’ai participé à un bon projet de plus de 4000 j-p à titre d’analyste organique et qui regroupait plusieurs technologies dont VB6, VB.Net, TFS, SQL et Oracle. Ce fut un projet fort intéressant et j’ai beaucoup appris sur plusieurs aspects, humains et technologiques.

Communauté Agile de Québec:

  • Devenu président du CA.
  • Nous avons organisé avec brio la conférence Agile Tour 2011 avec Bob Martin comme conférencier principal et 400 participants, rien de moins ! Ce fut un bel effort d’équipe. D’ailleurs j’en ai déjà parlé dans un autre billet.
  • Nous avons aussi organisé des rencontres mensuelles et des “Code Retreat” ou Retraite du programmeyr.
  • Cela nous a pris beaucoup d’effort afin de bien s’organiser entre nous. À se doter de meilleurs outils en 2012.

Lectures:

  • 15 lus, 2 en cours.  Objectif de 12 atteint et dépassé. Super !

Mes objectifs en 2012


 

 

 

Professionnel

  • Écrire davantage de blogues (voir autre billet dans les références)
  • En m’inspirant de Frédéric Harper (voir liens dans les références), je vais sortir de sa zone de confort de temps à autre pour y apprendre les technologies suivantes:
    • Développement d’application pour iPhone et le langage Objective-C
    • Apprendre davantage le Ruby, RoR et ses amis (RSpec, Cucumber, …
    • Autres petits projets de code et me servir de Git comme gestionnaire de code source

Agile

  • Avec la Communauté Agile de Québec: continuer de m’impliquer pour une dernière année probablement
  • Aussi continuer de me mettre à jour dans l’agilité avec des lectures ou autre, notamment sur le Lean et le Kanban que je veux approfondir.

Lectures

  • Je hausse la barre à 20 livres à lire cette année. C’est 5 de plus, mais j’en ai quelques-uns à finaliser, donc c’est réaliste.
  • De plus, je me suis procuré un Kindle Touch, ce qui me permettra de traîner mes livres un peu partout. Je me sers du site « GoodReads » pour suivre mes progressions de lecture.

 

Références:

Blogue de Frédéric Harper:

Mon Blogue:

Autres:

Bilan 2011 avec WordPress

J’aime bien faire le bilan annuel de mon blogue, histoire de voir un peu ce qui s’est passé. WordPress est très aidant en nous faisant parvenir un beau sommaire des faits saillants au début de l’année. Voici donc les points forts de mon blogue :

  • 20 billets produits en 2011 au lieu de 52 souhaités. Malgré tout c’est une bonne progression par rapport à 2010 où j’en avais composés 13. Conclusion: j’aime bien écrire des billets, mais parfois avec beaucoup de travail au boulot et avec la famille, le temps est parfois difficile à trouver.
  • Les visites en hausse à 3600  (1400 l’an dernier). Très bonne progression. Autre fait intéressant et qui prouve qu’annoncer ses nouveaux billets sur les médias sociaux fonctionne, regardez qui se retrouve parmi les sites référents principaux :
    • twitter.com
    • linkedin.com
    • fr.wordpress.com
  • Les pays principaux des visiteurs sont la France, le Canada et la Suisse.
  • Certains visiteurs sont venus par des recherches, la plupart avec les mots clefs suivants: gtd, pomodoro logiciel, code retreat, gestion visuelle, et getting things done.

Autre point intéressant, ma série de billets sur les outils de productivité semble avoir été fort populaire. D’ailleurs, on en retrouve plusieurs dans mon top 5 des billets les plus lus et commentés en 2011:

  1. Outils de productivité partie 2: La Technique Pomodoro
        (le plus populaire en 2011 !!!)
  2. C’est quoi un Lean Startup ?
  3. Outils de productivité partie 1: GTD
  4. Outils de productivité partie 5: Les utilitaires
  5. Outils de productivité partie 4: Zen et Focus

Voici mes objectifs en 2012 en ce qui a trait à mon blogue:

  • Rédaction de 30 billets en 2011 (52 était un peu trop, on va y aller progressivement).
  • Refaire une légère refonte de mon blogue (thème et autre)
  • Faire page "À propos de moi"
  • Faire une série de billets sur un sujet en particulier

Référence: