Agile Tour 2012: Les sessions Partie 2

Voici mon compte rendu des sessions de l’après-midi lors de l’Agile Tour Québec 2012. La partie 1 est ici.

Le Programmeur Lean Startup par Olivier Gourment

Olivier Gourment nous a offert une bonne présentation avec quelques touches d’humour. Parfait pour ne pas s’endormir après le repas du midi. Trois thèmes principaux étaient présentés. Les voici donc avec mes commentaires:

  • Lean Startup : Une introduction au Lean Startup est faite ici en expliquant le cycle « Construire – Mesurer – Apprendre ».  Le but dans un Lean Startup est d’apprendre le plus rapidement possible afin de construire le produit minimal viable. Très intéressante approche, que ce soit pour une entreprise en démarrage ou un projet interne dans une compagnie bien établie.
  • Code: Le code est souvent trop « gras » et nous ralentit. Il faut alors l’amincir avec du « Refactoring ». On fait la revue de quelques autres bonnes pratiques de programmation. Classique, mais toujours bon d’en faire le rappel.
  • Programmeur: On parle ici qu’il faut un peu du rôle de programmeur dans la vie de tous les jours. Olivier recommande d’adopter les pratiques d’ingénierie agile, prévoir la formation continue. Il a mentionné aussi un fait avec lequel je ne suis pas totalement d’accord: avoir des juniors dans notre équipe pour permettre l’innovation. Je crois davantage que l’on peut innover à tout âge. Pour favoriser l’innovation, j’irais en ayant simplement une équipe diversifiée et variée avec des gens différents, peu importe l’âge.

En conclusion, plusieurs sujets très intéressants ont été survolés. Mais je trouve que les sujets manquaient un peu de profondeur par moment. Aussi, les liens entre les trois thèmes principaux sont plus ou moins directs, mais bon ce n’est pas trop grave. Bonne prestation d’Olivier Gourment somme toute.

Références :

Le rôle de l’Architecte Agile par Jean-René Rousseau et Mathieu Boisvert

Sujet fort intéressant pour moi. Je ne pouvais me résoudre à aller voir toute autre présentation.

Question intéressante posée d’amblée: peut-on faire de l’architecture en amont en Agile ? Bien sûr que oui, on peut en faire un peu. L’architecture est quand même nécessaire afin d’avoir un aperçu des risques et complexités des problèmes à résoudre. Les approches Agiles occasionnent plusieurs impacts sur le rôle de l’architecte. Deux ont été ciblés et discutés lors de cette présentation:

  • Émergence et Incrémentalité: Il s’agit ici de bien balancer Anticipation et Adaptation afin de, sans trop tout détailler, avoir une architecture souple et ouverte aux changements.  On parle aussi d’établir des patrons de démarrage de projet. Aspect intéressant qui a été mentionné aussi: prévoir une stratégie pour gérer et planifier les considérations d’architecture.
  • Collaborer avec les équipes: L’architecte a son lot de responsabilité au sein d’une équipe. Il se doit de prévoir une stratégie de communication et accompagner son équipe. Il arrive souvent qu’il doive s’occuper de plusieurs projets en même temps. Mais, si la disponibilité le permet, la meilleure place pour lui est d’être équipier. Et je suis très en accord avec ce point. Ainsi, en étant équipier, il pourra davantage transmettre son savoir, guider l’équipe et aussi programmer à l’occasion. Ou mieux, faire de la programmation en paire histoire de se mettre à jour et faire un transfert de connaissance. Car un architecte qui ne code jamais risque de devenir un architecte dans sa tour d’ivoire.

Un problème que je remarque parfois dans les organisations, c’est que l’architecte logiciel est davantage un titre qu’un rôle.  Au lieu d’être un titre attribué, l’architecte logiciel ne devrait-il pas être un rôle, comme le ScrumMaster, qui est attribué selon le projet et peut changer à l’occasion ? J’imagine bien une équipe de programmeurs qui fait la rotation de ce rôle ou encore mieux, que ce rôle soit partagé par tous les membres de l’équipe. Cela ferait de très bons échanges de connaissances tout en permettant à tous de faire du code régulièrement. Bon, c’est peut-être une idée utopique, mais bon, cela fait du bien d’en parler.

Bref, malgré le fait qu’on dirait par moment que nous avons davantage le point de vue d’un architecte fonctionnel que d’un architecte logiciel, plusieurs points intéressants ont été amenés dans cette présentation. J’espère que d’autres présentations de ce genre suivront, car je crois que le sujet mérite d’être encore débattu, discuté et approfondi.

Références :

2 réflexions sur “Agile Tour 2012: Les sessions Partie 2

  1. Salut Karl ! Je découvre ton billet à l’instant … MERCI beaucoup pour cet élégant résumé !

    À propos de l’innovation et des « juniors », tu as tout à fait raison de mentionner la diversité. On peut être expérimenté dans d’autres domaines ou technologies pour voir les choses différemment d’un expert du domaine dans lequel on veut innover. Les lecteurs pourront se faire une idée par eux-même en lisant ma source de l’époque : http://www.nytimes.com/2007/12/30/business/30know.html
    Extrait : « As our knowledge and expertise increase, our creativity and ability to innovate tend to taper off. »

    Et à propos d’extrait, j’aimerais signaler que je m’étais permis de poster un bref extrait vidéo de ma présentation : https://www.youtube.com/watch?v=pGq2FfI6zdk&index=10&list=UU9IOO96NU86DGk2BAcFNovw

    Merci encore pour avoir assisté à cette présentation, avoir donné du feedback et à bientôt pour la prochaine🙂

  2. Salut Karl ! Je découvre ton billet à l’instant … MERCI beaucoup pour cet élégant résumé ! Tu soulèves des points très pertinents.

    À propos de l’innovation et des « juniors », tu as tout à fait raison de mentionner la diversité. On peut être expérimenté dans d’autres domaines ou technologies pour voir les choses différemment d’un expert du domaine dans lequel on veut innover. Les lecteurs pourront se faire une idée par eux-même en lisant ma source de l’époque : http://www.nytimes.com/2007/12/30/business/30know.html
    Extrait : « As our knowledge and expertise increase, our creativity and ability to innovate tend to taper off. »

    Et à propos d’extrait, j’aimerais signaler que je m’étais permis de poster un bref extrait vidéo de ma présentation : https://www.youtube.com/watch?v=pGq2FfI6zdk&index=10&list=UU9IOO96NU86DGk2BAcFNovw

    Une dernière chose, à propos du lien entre les trois parties. La première était un résumé de Lean Startup : le but est d’apprendre le plus rapidement possible comment construire un produit qui répond à un besoin réel. Pour ce faire, il faut du code qui soit facile à modifier – d’où le refactoring, les tests automatisés, l’intégration et même le déploiement en continu. Finalement, il faut des programmeurs qui sachent maîtriser ces techniques, pour éviter d’accumuler de la dette technique et ralentir l’apprentissage. Les techniques Agiles, et leur maîtrise – qui nécessitent elles-même un apprentissage continus. J’espère que c’est plus clair ?

    Merci encore pour avoir assisté à cette présentation, avoir donné du feedback et à bientôt pour la prochaine🙂

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s