Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Classique du développement logiciel: Working Effectively with Legacy Code

Publié par David Beaumier le jeudi 21 novembre 2013 à 13:19

Si on faisait une compilation des meilleurs livres de référence en développement logiciel il ne fait aucun doute pour moi que le livre de Michael C. Feathers en ferait partie. Intitulé Working Effectively with Legacy Code, ce bouquin explique comment approcher le développement dans une application existante afin d'en améliorer la maintenabilité. C'est un guide pratique pour quiconque travaille dans du code patrimonial.

J'entends déjà certaines personnes se dire: "Oh là David, je ne travaille pas dans du code patrimonial moi. Je développe une application en .NET". Lorsque Feathers parle de code patrimonial il fait en fait référence à tout code qui nous fait n'a pas de tests automatisés (idéalement unitaire). Peu importe que ce soit écrit en Cobol, en Delphi, en Java ou en Ruby. Si votre code n'est pas testé, c'est du code patrimonial! Désolé…

Couverture-WorkingEffectivlyWithLegacyCodeCode without test is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we don’t know if our code is getting better or worst.

Je possède ce livre depuis nombre d'années, mais ça faisait un bout de temps que je ne l'avais pas ouvert. Merci à mes collègues Félix-Antoine et Pascal pour l'avoir remis au goût du jour avec leur atelier sur la dette technique présenté à l'Agile Tour. La dette technique est, bien souvent, assez présente dans les logiciels patrimoniaux.

Comme l'ont souligné mes collègues durant leur conférence, ce livre regorge de trucs pratiques pour prendre (ou reprendre) le contrôle du code source d'une application qui manque cruellement de filets de sûreté (lire de tests). En plus, pas besoin de tout révolutionner d'un coup! Il est possible d'y aller graduellement, étape par étape. Feathers explique fort bien comment vous pouvez y prendre et réussir, espérons-le, à payer la dette qui s'accumule depuis plusieurs années.

J'en profite aussi pour souligner que Feathers présente régulièrement dans des conférences internationales. Je me permet de vous suggérer quelques apparitions disponibles en vidéo:

J'espère que le prochain livre de Michael sera aussi intéressant que son premier (il doit sentir une certaines pression). D'ici là, bon développement!

 

Références Agile et Lean pour les leaders d’organisation

Publié par Philippe Tremblay, FÉLIX-ANTOINE BOURBONNAIS le vendredi 13 septembre 2013 à 07:30

Lors de nos diverses interventions chez nos partenaires et clients, nous avons régulièrement à accompagner les leaders dans la transition agile réalisée par leur organisation.  Plusieurs sont surpris de constater que l’agilité est loin d’être une préoccupation touchant uniquement le développement logiciel.  Il existe souvent une préconception qu’Agile signifie un nouveau processus accompagné de quelques techniques pour l’équipe de développement.  Les concepts de gestion du changement, de nouveau style de leadership et de changement de culture sont souvent ignorés dans les attentes de la transition Agile.

Pour aider les leaders et propriétaires d’entreprises à maximiser les bénéfices de l’investissement et des efforts mis dans leur transition, nous offrons régulièrement des références à ces derniers pour compléter les notions et les principes transmis lors des séances d’accompagnement.  Afin d’aider un maximum de leaders et d’organisation, nous avons désormais cet article contenant les références pour les leaders désirant bien appuyer leur organisation vers l’approche agile des affaires.  Cet article sera mis à jour afin de refléter l’évolution de nos suggestions.

 

Articles

 

Livres

 

Vidéos

Mots-Clés :

TDD: Comment partir du bon pied?

Publié par Félix-Antoine Bourbonnais le jeudi 27 juin 2013 à 00:00

Suite à ma présentation sur le TDD Mockiste de la semaine dernière, plusieurs personnes m’ont demandé des références afin de bien débuter en TDD. D’autres m’ont demandé des liens sur le BDD.

Voici donc une série de billets sur le sujet: (1) comment débuter? (2) comment partir votre équipe en TDD? (3) des liens et des pistes pour les plus experts.

Comment débuter

Si votre premier objectif est de voir quelques professionnels à l’oeuvre pour vous donner une meilleure idée de ce que peut être le TDD, je vous recommande les vidéos de cleancoders.com.

Peut-être aurez-vous alors été impressionné par la vitesse et l’aisance avec laquelle il est possible de faire du TDD et vous ou votre équipe désirez faire de même.

La mauvaise nouvelle est que le TDD est une discipline et que les pros du TDD pratiquent depuis des années pour atteindre ce niveau d’aisance. Vous devrez donc, malheureusement, vous aussi pratiquer, pratiquer, vous tromper, perdre du temps, vous décourager, vouloir laisser tomber, changer d’idée, vous ressaisir, puis pratiquer encore, …

Il n’existe pas de chemin linéaire pour devenir un praticien du TDD, il n’y a que la pratique...

Premières lectures en TDD

Pour commencer, vous voudrez probablement avoir une référence vous permettant d’acquérir les bases.

Je vous recommande l’une des options suivantes:

  1. Les vidéos traitant de TDD de Robert C. Martin sur cleancoders.com ;

  2. Le livre Growing Object-Oriented Software Guided by Tests (GOOS) ;

  3. Le livre Test Driven: TDD and Acceptance TDD for Java Developers ;

  4. Le livre Test Driven Development: By Example ;

  5. Une formation TDD .

Pour les plus pressés, les vidéos sur cleancoders.com (1) sont idéaux, car ils présentent des exemples pas à pas, sont concis et permettent d’avoir rapidement l’information provenant de l’un des plus grands maîtres. Le tout, condensé dans des vidéos amusants que vous pouvez regarder dans le confort de votre salon. D’ailleurs, la qualité des derniers épisodes est nettement meilleure et ils peuvent être regardés en HD.

Ceux ou celles qui s’intéressent à l’école de Londres ou qui veulent en même temps améliorer leur architecture ou leurs pratiques OO voudront certainement lire GOOS (2). Un débutant en TDD peut cependant très bien lire cet excellent livre au 1er degré sans s'attarder à la trame de fond de l’école Mockiste. C’est un livre qui a changé ma pratique du TDD et qui est un point tournant pour moi.

Le livre de Lasse Koskela (3) est assez nouveau et présente simplement le TDD. À mon avis, son principal avantage est de parler du TDD au sens large, incluant l’ATDD. Il contient beaucoup de trucs et astuces, des odeurs et des difficultés communes. Les points abordés correspondent aux questions récurrentes lors des mes formations. Il traite à la fois de la base et de sujets avancés.

Finalement, le livre de Kent Beck (4) est un classique et reste toujours pertinent. Très bien écrit, il présente le TDD d’origine.

Malgré toutes ces lectures, vous ressentirez peut-être le besoin de valider votre compréhension ou de vous faire conseiller. Peut-être voulez-vous laisser un expert vous guider? Dans ce cas, il y a toujours nos formations ou notre mentorat virtuel. Oui, je sais que je suis en conflit d’intérêts ici, mais reste que si je donne ces formations, c’est que je crois qu’elles sont bénéfiques pour les participants...

Premières expériences en TDD

Bien. Maintenant que vous avez une vague compréhension du TDD et que vous rêvez de pouvoir coder le jeu de Bowling aussi rapidement que Bob Martin, la question reste: comment y parvenir?

En pratiquant... Mais quoi?

Commencez par des exercices très simples qui vous permettent de vous concentrer sur le TDD et non le problème. Choisissez des problèmes triviaux comme une pile, inverser une chaîne de caractères, etc.

Augmentez graduellement le niveau de difficulté. Par exemple, l’exercice du Jeu de la vie est un bon exercice de deuxième niveau. C’est le type de Kata très versatile que l’on peut faire et refaire toute notre vie et encore apprendre...

Plusieurs Katas sont disponibles et sont spécialement conçus pour pratiquer le TDD. Vous pouvez consulter ce catalogue ou encore celui-ci. D’autres problèmes sont disponibles ici. Une foule de solutions à ces Katas sont disponibles sur Internet (ex.: ce site).

Pourquoi est-ce difficile?

Rien ne sera facile, car vous devrez désapprendre à programmer... En termes plus scientifiques, vous devrez reconstruire un nouveau réseau neuronal...

Cela vous demandera de faire appel à toute la plasticité de votre cerveau pendant un petit moment en attendant que ce nouveau circuit soit le plus fort...

Je n’ai alors qu’un seul conseil: ne lâchez pas!

Lisez ce livre. Tout simplement.

Publié par Louis-Philippe Carignan le vendredi 29 mars 2013 à 16:00

Rare dans les dernières années où j’ai lu un livre aussi fascinant sur un sujet qui m’a si peu attiré dans ma vie, la psychologie. En décembre 2012, un collègue m’a mentionné le livre « Thinking, fast & slow » de Daniel Kahneman.

 ThinkingFastAndSlow

J’apprends littéralement quelque chose de nouveau à chaque page. L’auteur, psychologue et gagnant du prix Nobel en économie, explique comment notre cerveau est constitué de deux systèmes. Le système #1 fait souvent référence à notre côté instinctif tandis que le système #2 réfère au côté rationnel et logique de notre pensée. Mais contrairement à la psycho-pop où on entend souvent parler d’inconscient (système #1) et de conscience (système #2), l’auteur détaille chaque système à l’aide d’expériences scientifiques crédibles page, après page, après page.

On y apprend entre autre comment le système #1 est une véritable machine associative. Dès la première page du livre, l’auteur nous démontre ce fait à l’aide d’une image d’une femme choqué. En un clin d’œil, notre cerveau a associé une émotion à cette image. Et on tourne la page où l’auteur nous demande de multiplier 17 par 24. Le système #2 embarque et après avoir passée une trentaine de secondes à effectuer le calcul, on retourne à la lecture du livre pour y apprendre que notre système #2 est paresseux et qu’il nécessite un effort pour l’activer.

À tous les chapitres, l’auteur jongle entre le comportement de ces deux systèmes. On voit comment le système #2 vient valider (ou invalider) certaines décisions instantanées du système #1. On y apprend comment le système #1 amplifie des probabilités lorsqu'il l'associe à une histoire. On découvre la valeur de l'anchrage qui force notre cerveau à fixer notre opinion si un chiffre a été énoncé dès le départ. Tout au long du livre, on aborde des sujets comme les heuristiques qu'utilisent notre système #1 pour simplifier des questions complexes. Par exemple, notre système #1 ne peut répondre à la question "Êtes-vous très heureux ces derniers temps?" et la remplace par "Comment te sens-tu en ce moment?" puisque répondre à la première question lui demanderait de réfléchir pendant un p'tit bout de temps, chose qu'il est incapable de faire. Pour s'enlever ce souci, il préfère simplifier la question.

L'auteur utilise souvent l'acronyme WYSIATI pour "What You See Is All There Is" pour souligner comment le système #1 utilise seulement ce qu'il voit au moment présent. On y apprend comment notre système #2 est souvent paresseux, cherchant un état de repos cognitif le plus souvent possible. Il en coûte cher en énergie pour activer notre système #2. Par exemple, l'auteur rapporte une étude où des jugent étaient plus précis dans leur révision de sentences en début de journée, lorsqu'ils avaient déjeuné. Ils devenaient de moins en moins bon au cours de l'avant-midi puisque l'énergie nécessaire pour faire fonctionner leur système #2 était de plus en plus rare dans leur organisme.

Bien que je sois seulement rendu à la moitié du livre, je retiens fortement le thème de la statistique dans ce livre. Thème à la base des recherches de Kahneman dans les années 60. Thème qui nous rappelle à quel point nous ne sommes pas doués en statistique et pourtant, il faudrait l’inclure davantage dans nos réflexions qui sont souvent trompées par l’automaticité du système #1.

Je vous recommande fortement de lire ce livre pour mieux vous connaître. Moi-même d'ailleurs, je suis devenu beaucoup plus alerte lorsque mon système #1 embarque immédiatement pour m'imposer un jugement. Un jugement probablement trop rapide où je dois faire appel à mon système #2 pour valider ce qu'à conclu le système #1 en un instant.

Bonne lecture!

Mots-Clés :

Tester pour apprendre à Agile Montréal

Publié par Louis-Philippe Carignan le jeudi 18 octobre 2012 à 18:00

J'aimerais remercier les organisateurs de la communauté Agile de Montréal pour leur chaleureux accueil jeudi soir. Merci à Martin Goyette d'avoir pris le temps de bien m'orienter dans ma présentation et de m'avoir accueilli à la station de métro pour éviter que je tourne en rond.

Pour les personnes intéressées, vous retrouverez ci-joint la présentation que j'ai donné. Vous pouvez télécharger le fichier PDF en allant sur le site Slideshare d'Elapse Technologies.

Archive