Essais

Qu’est-ce que c’est qu’une “user story” ? Dans les projets agiles, on ne commence pas par écrire un document de spécification dans une phase initiale qui serait ensuite suivie par une phase de réalisation et enfin de validation. Non. A la place, on initialise une liste de “user story”, ou “histoires utilisateur”. Dans la stratégie SCRUM, cette liste s’appelle un “product backlog”. Ces “histoires utilisateur” sont de petites descriptions très courtes d’un besoin utilisateur.

Qu’est-ce qu’on apprend en lisant du code ? Il existe 5 raisons qui font que le code est ce qu’il est : - limitation de la machine - limitation du langage - limitation du programmeur - historique - specification (at last!) «There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at the code from the outside rather than by reading it.

Java bean Spring bean Hibernate bean web bean service bean backing bean … Ça y est, j’ai une métaphore pour mon application : c’est un cassoulet !

A votre avis, qui est le plus agile ? Le chevalier avec ses 90 kg d’armure ou le paladin en tunique avec sa hache ? Supposons qu’au cours de l’écriture de mon programme je rencontre soudainement le besoin d’une fonction d’affichage. def affiche (a, b) Supposons, dans un premier temps, que je sois sûr que cette fonction n’est jamais appelée avec des paramètres nuls. Deux tactiques sont possibles ici: -* Programmation défensive: -** J’écris un test unitaire pour vérifier que ma méthode affiche bien a et b dans le cas où ils sont tous les deux non nuls -** J’ajoute immédiatement dans le corps de ma fonction, au début, quelques lignes de code pour retourner une exception si l’un des deux paramètres est nul1.

Ce soir, je lisais un livre très intéressant à mon petit bonhomme : “Tous différents” par Todd Parr. Je me suis en particulier arrêté sur la page suivante: On peut parler de ce qu'on ressent Voila quelque chose qu’on oublie trop facilement dans les projets professionnels. Par exemple, que penser d’un chef de projet qui insisterait pour être vouvoyé ? Ne serait-ce pas le meilleur moyen de fermer ce type de communication ?

L'agilité à ses balbutiements, avant même que le manifeste agile ne soit écrit, c'est à dire avant que le terme "agile" ne soit inventé, était identifiée par l'intitulé "processus légers" (lightweight processes) par opposition aux processus classiques de type cascade ou cycle en V qui se trouvaient de fait qualifié de "lourd" the founding of the agile alliance. Connaissez vous l’histoire de Galilée telle qu’on la raconte aux élèves de collège ?

Quand on se fait agent du changement vers des pratiques de développement agiles, on se fait rapidement traiter de fanatique et c’est effectivement ce que l’on a l’air d’être. Je ne sais pas comment font les autres, mais personnellement j’utilise l’idéal comme une référence et une vision de l’objectif à atteindre. Il n’est pas si facile de garder le cap quand on est plongé dans la réalité. Voici ce qu’un client a pu dire de moi dernièrement :

Voici quelques remarques générales sur les commentaires de programme. Cet essai a été écrit suite à la lecture du poste de Christian Faure sur la litterature de code. Comme le fait remarquer Christian Faure dans une réponse à ce message, il s'agit ici du point de vue d'un développeur professionnel. D’une manière générale, je réduis les commentaires au minimum car ils constituent une forme de duplication d’avec le code écrit juste à coté.

Non ! Encore cette étiquette d’extrémistes ! Comment Schumacher aurait-il pu gagner un championnat de formule 1 s’il n’appuyait pas au maximum sur l’accélérateur ? Voila l’idée de l’eXtreme Programming. Il ne s’agit pas d’aller trop loin, mais de rechercher la performance optimum des pratiques qui la constituent. Il ne faut pas croire que eXtreme Programming signifie extrême effort, ou horaires extrêmes. Il s’agit en fait d’optimiser la méthode de travail. Quel effort y-a-t’il à pousser sur l’accélérateur jusqu’à sa position idéale ?

J’ai eu l’occasion, il y a déjà quelque temps, de participer à une réunion avec un client. Il s’agissait de nous présenter le projet pour nous permettre de bâtir notre réponse à appel d’offre. Le client avait eu une expérience de projet réussi ayant utilisé la méthode Extreme Programming, et nous espérions pouvoir vendre notre capacité à monter ce nouveau projet en utilisant cette méthode. L’ordre du jour de la réunion était en partie de déterminer si nous présenterions un projet “Full XP”, “partiellement XP” ou simplement “standard” (Cycle en V).