Placer la barre plus haut avec le TDD

Thibauld Nion — Sun, 09 Jun 2013 17:54:37 GMT

Histoire de jouer un peu plus avec les outils que j'ai essayé pour Yapsy et aussi pour expérimenter avec le TDD, je me suis lancé dans un mini projet, entièrement hébergé sur github et pour lequel j'ai essayé de respecter les principes du TDD dans les grandes lignes (plus ci-dessous). Le projet en lui même s'appelle baciphacs et n'est rien d'autre qu'un re-développement d'un petit bout de code que j'ai l'impression d'écrire à chaque poste où je suis passé: générer du code HTML (avec un peu de CSS dans les tags en plus) représentant un diagramme en barre. Ce genre "d'astuce" est rarement la "meilleure solution" mais permet de générer des visualisations à peu de frais et sans se soucier d'éventuels problèmes de réseaux ou de licences. Concernant le TDD, baciphacs en est sans doute un très mauvais exemple vu que ce n'est qu'un premier essai mais ça m'a permis de confirmer l'impression que j'avais sur cette méthode: elle est effectivement (et c'est connu je crois) complètement contre-intuitive mais elle met en avant des principes de design qui me semblent importants et vont bien plus loin que le fait de tester un logiciel.

Lire la suite… (Il reste encore 2 min. de lecture)

Revue: Individuals and interactions

Thibauld Nion — Fri, 28 Dec 2012 17:40:05 GMT

Dans mon élan actuel d'exploration de la littérature sur la gestion de projets informatiques, j'ai voulu chercher des réponses à une question que je me pose depuis quelques temps à propos des méthodes Agiles: le Manifeste Agile m'avait particulièrement plu parce qu'il met en avant les "individus et interactions devant les processus et les outils" et pourtant la quasi totalité des ressources que j'ai pu lire sur le sujet tournent autour des carcans de tests, de l'intégration continue, des sprints, itérations, daily scrums et autres kanban... En bref: toutes ces ressources se focalisent sur les processus et les outils ! Il y a une explication simple à cela: les procédures sont plus faciles à décrire, critiquer et raffiner pour des gens avec un penchant technique comme les ingénieurs tels que moi, et après tout, les "processus agiles" sont conçus pour encourager les interactions et soulager les gens des problèmes inhérents au développement informatique (bugs, changement des spécifications etc). Cela-dit ça revient tout de même à mettre les processus en avant en supposant que les personnes en bénéficieront automatiquement par la suite. Et c'est cette petite contradiction qui m'a motivée pour rechercher un livre qui traite explicitement des aspects "humains" des méthodes agiles et finalement de lire Individuals and interactions: An Agile Guide par Ken Howard, Barry Rogers .

Lire la suite… (Il reste encore 3 min. de lecture)

tlog (Articles sur software development)

Placer la barre plus haut avec le TDD

Revue: Individuals and interactions