Johnny Bunko - un manga Agile ?

J'ai lu l'excellent Johnny Bunko: le seul guide de carrière dont vous avez besoin. Daniel H. Pink, auteur du célèbre A Whole New Mind: Why Right-brainers Will Rule the Future, nous y donne les 6 clefs de la réussite :

1. Les plans ça n'existe pas.
2. Pense tes forces, pas tes faiblesses.
3. L'important ce n'est pas toi.
4. La persévérance l'emporte sur le talent.
5. Fais des erreurs mais fais les biens.
6. Laisse ton empreinte.

On y retrouve donc une partie des valeurs Agiles.
Le premier chapitre nous explique qu'il est illusoire de vouloir suivre un plan et qu'il faut s'en cesse s'adapter.
La troisième règle nous explique nous ne travaillons pas pour nous même mais pour satisfaire un client.
L'erreur est acceptée, si elle permet d'avancer, ce qui n'est pas sans rappeler le "fail fast" du développement agile.
L'humain reste au centre avec les trois autres règles puisqu'elles nous expliquent comment atteindre un certain épanouissement personnel.

Si vous voulez lire les 61 premières pages (en anglais) suivez le guide.
Mise à jour suite au commentaire d'Alexandre:
L'idée derrière tout ça est qu'il faut changer le monde. Tout le monde n'étant pas le Mahatma Gandhi, laisser son empreinte siginifie ici toucher et améliorer le monde autour de soi, à son échelle.

Bref, un manga bien sympathique qui aborde de vraies questions sous un angle original et ludique.
Pour vous mettre l'eau à la bouche, un petit trailer présentant le livre:

Agile Testing

Ce vendredi j'ai eu la chance de participer à un cours donné par Elisabeth Hendrickson sur ATDD. J'ai connu Elisabeth à travers sa vidéo chez Google et son blog. Venant du monde des testeurs et de la qualité elle apporte une nouvelle vision de l'agilité et réconcilie mon âme de développeur avec le monde du test.
Ce vendredi donc, nous étions 6 (un français, un danois, une indienne et deux anglais) pour un cours par internet avec webcam. Une fois tous les réglages effectués nous voilà embarqués pour un voyage dans le monde de l'ATDD.


L'un fut désigné " responsable du produit ", et nous avons commencé à définir notre histoire d'utilisateur et les différents éléments qui allaient nous permettre de la considérer comme " faite ". C'est la partie " discuss " de l'ATDD (ou les ateliers de spécification selon Gojko Adzik).
Puis nous sommes passés à l'étape " distill ", dans laquelle nous avons transposé le résultat de notre discussion dans une page HTML pour l'outil RobotFramework. Je dis nous car le cours n'était pas directif et nous pouvions facilement prendre le contrôle de la page pour écrire nos scénarii.
Enfin une fois cette étape réalisée, nous avons pu développer en étant dirigés par nos tests d'acceptance : comme aucun tests d'acceptance n'était écrit nous avons commencé par écrire le premier, puis une fois cela fait, comme pour du TDD, nous étions avec un test au rouge. Il nous a fallu commencer à écrire notre code. Comme nous sommes des développeurs consciencieux nous avons pris une approche TDD justement. Une fois que les tests unitaires sont passés au vert, nous avons vérifié que le test d'acceptance changeait lui aussi de couleur. Nous pouvions passer au test d'acceptance suivant. On se retrouve dans le cercle classique du .
Premières impressions sur ce cours en ligne.
Mise à part quelques soucis techniques, essentiellement sur le son dont le niveau changeait complètement d'un intervenant à l'autre, c'était vraiment très agréable. Elisabeth est une personne très dynamique et enthousiaste ce qui a permis de compenser l'aspect distribué des participants.
Sur le fond c'était vraiment super, en deux heures on a pu voir un cycle complet d'ATDD sur l'outil Robotframework. En tant que développeur je me suis vite senti à l'aise dans ce cycle de part sa proximité avec le TDD. J'ai pu voir la valeur ajoutée des tests exploratoires puisqu'en quelques minutes les testeurs purs ont réussi à mettre notre système à mal.

J'espère partager cette expérience enrichissante lors d'un futur kata au Coding Dojo de Grenoble.

Le prix Turing 2008 pour Barbara Liskov

Félicitations à Mme Liskov célèbre pour le principe de programmation objet qui porte son nom publié en 1987 :

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

• Voici la nouvelle originale en français publiée sur Linuxfr.org.


• Le principe de substitution de Liskov


• The Liskov Substitution Principle for "Duck-Typed" Languages

Pragmatic Thinking & Learning

Je viens de terminer ce livre livre écrit par /\ndy Hunt. Il y reprend ce qu'il présente lors de workshops et de conférences depuis des années. Il commence par nous décrire le modèle de Dreyfus qui va nous servir de fil rouge tout au long du livre. En effet /\ndy va nous donner 48 conseils argumentés pour nous améliorer et nous faciliter le voyage de novice à expert.
Le deuxième chapitre est consacré à notre cerveau et à son modèle de fonctionnement tel que décrit par les dernières avancées des neurosciences. Le schéma du cerveau comme étant un système à deux CPU partageant un bus pour accéder à la mémoire est vraiment excellent. On y retrouve les résultats sur la bilatéralisation du cerveau mais aussi le CPU à règles (Coté Gauche / L Brain) et le CPU à intuitions du modèle de Dreyfus (Coté Droit / R Brain).

Une fois ces bases posées on s'attaque au vif du sujet en analysant comment améliorer notre fonctionnement en ne se concentrant pas uniquement sur le CPU L mais en faisant fonctionner l'autre en parallèle.
Cependant nos processeurs sont buggés tant au niveau matériel que logiciel. Il faut apprendre à reconnaître ces défauts pour essayer de les dépasser tant que faire se peut. Au niveau logiciel il faut reconnaître nos principaux préjugés, l'affinité générationnelle, et au niveau matériel la partie reptilienne et primitive de notre cerveau qui a tendance à court-circuiter notre cortex.
Optimiser le fonctionnement de nos processeurs ne suffit pas, il faut maintenant les alimenter en informations pertinentes et donc apprendre à apprendre. On retrouve ici ce que j'avais exposé lors de la conférence sur le modèle de Dreyfus notamment le Pragmatic Investisment Plan.
Enfin les derniers chapitres donnent de bonnes pistes de réflexion pour rendre sa manière de travailler plus efficace tout en gardant l'aspect fun de notre métier (à savoir pour moi le CODE ;o) ).
J'ai vraiment adoré ce livre, il est très facile à lire et j'ai vraiment hâte de mettre en pratique les idées qu'on y retrouve. D'ailleurs pour faciliter cela les 48 maximes sont regroupées en dernière page et il ne reste plus qu'à choisir.
J'ai décidé de commencer par améliorer ma gestion de ma connaissance en intégrant un wiki à ma prise de note et en réalisant des mind-maps. Pour ces derniers j'utilisais des logiciels tels que Freemind cependant rapidement je n'avançais plus, par contre j'ai remarqué, grâce au livre d'ailleurs, que si je les fais à la min sur une feuille de papier j'étais nettement plus efficace.
Je vais mettre plus souvent en pratique le SEE IT, DO IT, TEACH IT et j'espère bien que les dojos vont me permettre d'évoluer à ce niveau là.

Enfin je vais m'acheter un canard en plastique, l'idée du TALK TO THE DUCK m'a vraiment séduit : expliquer à un canard en plastique le problème rencontré pour en avoir une approche différente et souvent une solution.
Bon, j'ai du pain sur la planche

Mise à jour des flux RSS

Bonjour,
J'ai décidé de passer par Feedburner pour les flux RSS/Atom aussi pouvez vous faire migrer vos pointeurs vers http://feeds2.feedburner.com/JavaInTheAlps.
Bonne journée

Déploiement de progiciel en mode Agile

Voilà un sujet rarement traité dans les ouvrages sur l'Agilité : la mise en oeuvre d'un progiciel. Cette nouvelle traduction de l'article "Agile Package Implementations" de Scott Ambler pour le Doctor Dobb's Journal donne les différentes étapes à suivre pour apporter le maximum de valeur et réduire les risques d'un déploiement de progiciel de manière Agile.
DDJ - Architecture & Design - Agile Package Implementations

Publish at Scribd or explore others: Academic Work agile progiciels

Sinon le document est disponible chez GoogleDocs ici ainsi que sur Slideshare.

Manifeste pour un Développement de Qualité

Le célèbre Agile Manifesto s'est enrichi depuis cet été d'une cinquième phrase : "Craftsmanship Over Execution".
Pour rester dans cet esprit un nouveau manifeste est disponible pour les codeurs fous que nous sommes : "Craftmanship Manifesto".

Je vous engage donc à aller le signer et surtout à le respecter :o)
Bonne journée

Test Driven Development améliore la qualité

Des études empiriques le prouvent le développement piloté par les tests (TDD pour les intimes) améliore notablement la qualité des logiciels. Cet article écrit par Nachiappan Nagappan (de chez Microsoft), E. Michael Maximilien (IBM), Thirumalesh Bhat (Microsoft), and Laurie Williams (North Carolina State University), et publié dans le journal Emperical Software Engineering Volume 13, Number 3.
L'article présente les résultats de quatre équipes variées(3 de Microsoft, 1 d'IBM) dans un contexte professionnel qui ont mis en œuvre les pratiques du TDD et ont observé une réduction du nombre de bugs par 1000 lignes de code de 40% à 90% pour une surcharge de développement de 15% à 35%.
Cette étude confirme les retours d'Allianz lors de l'Agile Tour 2008 qui annonçait une surcharge de développement de 15% à 20%.
Alors en attendant que mon patron m'offre une licence JUnitMax je vais aller écrire mes tests.