Agile Tour Québec 2013

ATKiosk

Le 6 novembre dernier, a eu lieu la 5e édition du Agile Tour Québec. Étant bénévole, j’ai eu la chance d’assister à de belles conférences et aussi y faire de bons échanges avec les participants et présentateurs. Cette année, nous avons franchi le cap des 500 participants, ce qui est très bien pour la ville de Québec. Et encore une fois, de bons présentateurs sont venus donner leur temps pour nous parler de développement Agile.

Et voici le récapitulatif de ce que j’ai vu et entendu:

Rapid and Lasting Agile Adoption (conférenc principale)

J’ai été plus ou moins attentif à cette présentation étant donné l’effervescence du début de la journée et de l’inscription. Mais j’ai retenu quand même plusieurs points intéressants:

  • Passer d’une méthode de travail à une autre est comme un genre de deuil.
  • Un rite de passage est utile pour favoriser l’adoption « Agile » dans la culture d’entreprise.
  • Les gens doivent s’engager, idéalement, au lieu de se faire imposer une nouvelle manière de travailler.

Le conférencier a formalisé le tout autour du principe de « Open Agile Adoption ». Je trouve très intéressant tout cela et cela a plein de bon sens de faire des rencontres ouvertes ponctuelles pour discuter de l’adoption agile. On retrouve ici dans le schéma suivant l’essentiel de ce principe:

OAnA-fig1large1

Pour plus de détails, consulter les sites suivants:

À vos marques, prêts, codez!

Format un peu inusité pour cette présentation:

  • 2 développeurs programment avec sur un écran distinct.
  • Ils utilisent deux langages de programmation différents: le C# et le Python.
  • Un 3e présentateur est à l’arrière de la salle et fait l’animation.

Bien qu’inventif comme format, j’ai plus ou moins aimé. Malgré certains commentaires pertinents de l’animateur, il avait plutôt l’air de quelqu’un qui commente une game de hockey par moment.

Quand on présente un « Code Kata » dans une présentation, j’aime bien quand le développeur pense à haute voix et on peut ainsi comprendre son raisonnement et ses choix. Ce ne fut pas le cas ici. Seulement des interventions occasionnelles de l’animateur en questionnant les développeurs.

Aussi, l’introduction était un peu absente. Mettre le schéma du TDD au début aurait été utile pour certains.

Quelques points intéressants que j’ai notés:

  • Il y a de multiples chemins pour résoudre un Kata
  • Il est parfois utile de se mettre un minuteur pour nous rappeler à l’ordre afin de faire passer un test au « vert ».
  • Lors d’un refactoring ou perfectionnement du code, bien-être certain de l’intention.
  • Lors de l’étape « Rouge » ou faire un test qui échoue, au début il s’agit surtout d’améliorer le message d’erreur.
  • On est rarement assez agressif avec le refactoring.

Bref, un peu déçu, mais quand même bravo aux présentateurs, car ce n’est pas toujours facile de programmer « live » devant plusieurs personnes et d’essayer un nouveau genre de présentation.

Esclave de votre dette technique?

Présentation très dynamique de Pascal Roy et de Félix-Antoine Bourbonnais. Les deux gars sont des passionnés !

Les faits saillants:

  • Quadrant de la dette technique de Martin Fowler pour savoir quelle genre de dette technique on a affaire.
  • Des outils existent pour aider à identifier notre dette technique, comme la duplication par exemple.
  • Ne pas négocier votre dette
  • Faire du refactoring dans des endroits gagnants.
  • Prendre la responsabilité de cette dette.
  • Faire son bilan.
  • Chérissez votre code !

Voici la présentation intégrale sur Slideshare:

Javascript : Tester le code oublié

Bien que loin d’être un expert Javascript, j’ai fait à l’occasion, mais vraiment pas souvent, j’ai quand même aimé cette présentation.

L’interaction entre les deux présentateurs, Vincent Crépin (l’architecte) et Jean-Nicolas (le développeur) était intéressante. On voyait ainsi la réflexion de quelqu’un qui commence s’intéresser au Javascript avec l’aide d’un autre qui en mange tous les jours.

Les faits saillants:

  • Tester les fonctions qui sont au coeur du langage
  • Jasmine est le framework recommandé pour faire des tests style TDD/BDD. Il est assez simple de l’installer et de commencer à s’en servir.
  • Le concept de « closure » peut paraître complexe au premier abord, mais est très important à maîtriser.
  • Knockout.js est un framework Javascript intéressant pour faire une interface web avec le patron Model-View-ViewModel (MVVM).

Plus qu’une équipe : bâtir une entreprise Lean

George Saad a toujours des choses intéressantes à raconter. Cette fois-ci, c’est un peu plus personnel, car il nous explique le fonctionnement de sa boîte de développement web: Spektrum Media.

Avec une équipe réduite d’une dizaine de personnes où pratiquement tout le monde fait du code, il est possible d’être efficace outre les budgets.

En appliquant les principes Lean de bout en bout de son entreprise, il se permet de brasser la cage et de compléter des projets bien en deçà des budgets préliminaires. Comment fait-il exactement ?

  • Évite le gaspillage au maximum.
  • Se permettre de choisir les projets, car la demande est plus grande que l’offre de service de son entreprise.
  • Trouve le juste milieu entre le prix et la qualité
  • 1 seul développeur est nécessaire pour l’évaluation de la proposition. Par la suite, un analyste/chargé de projet y met son grain de sel.
  • Procède toujours en commençant petit, morceau par morceau, afin d’obtenir le feedback ou rétroaction le plus rapide du client. De cette manière, on valide régulièrement si on est sur la bonne voix et si cela vaut la peine de continuer.
  • Côté recrutement, cherche les meilleurs développeurs, le genre qui se foutent un peu du langage et de la technologie.

J’aime particulièrement le concept du « vendredi innovation ». À cette journée, les employés travaillent sur des projets personnels à moins qu’il y ait du retard dans un des projets pour des clients. Quand cela arrive, c’est une forme d’indicateur de gestion indiquant qu’il y’a peut-être des problèmes à l’horizon.

Référence:

Publicités

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 :