Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

10 juin 2010

La bataille du Kanban et de Scrum

Wow! Quelle expérience! La présentation de Jean Tabaka intitulé "The Battle of Scrum vs Kanban" était super-interactive. Dans la salle on avait une discussion, où, pour participer, il fallait aller dans le "fishbowl", le bocal à poissons, c'est-à-dire, 4 chaises devant l'audience, où on allait pour participer à la discussion (une personne faisait la rotation au besoin). Parallèlement, on twittait en direct (http://twitter.com/search?q=%23bsk2010) et c'était afficher à l'écran. Certains étaient dans la salle, Jean Tabaka (RallySoftware), Allan Shalloway (NetObjectives), et moi-même, les autres (e.g. Joshua Kerievshy) étaient ailleurs dans le monde.

L'expérience de twitter en direct et de suivre la discussion dans la salle était passablement intense. Ça m'a pris 20 minutes pour revenir à un rythme cardiaque normal. En plus, le contenu était très pertinent.

Premier constat, le kanban est encore mal connu, donc une comparaison par le public présent était biaisée. Ce fut quand même un bon moyen d'en apprendre plus sur la méthode. Je résume : visibilité et limite du "work in progress", le wip. C'est un peu simple, mais pour faire une comparaison avec scrum, c'est un bon point de départ. Je trouve que ça peut être un bon point de départ pour une équipe de maintenance par exemple.

On a débuté par une présentation par les personnes dans le fishbowl de chacune des approches et ensuite une discussion sur les différences et les similitudes. Est-ce que ce sont des outils, ou plutôt, comme le mentionne Allan Shalloway, un état d'esprit, un mindset. Personnellement, je crois que chacune des approches a son utilité. Scrum étant une méthodologie simple et bien documentée, elle est relativement facile à adopter. Scrum est une approche agile, une approche Lean, out-of-the-box. Avec Kanban, c'est probablement moins dérangeant au départ, car on peut partir du processus actuel et évoluer.

Au final, il ne faut pas considérer kanban versus scrum, mais plutôt utiliser les forces de chacune des approches selon le contexte. On est réellement du même côté. Le kanban a certainement à gagner à se faire connaître.

Comme le dit Alistair Cockburn : "Different methodologies are needed on different projects" (dans Agile Software Development).

 

 

 

 

Linchpin et la pensée créatrice

En lisant Linchpin de Seth Godin (page 50) je me suis souvenu d'une vielle histoire (30 ans+) lorsque je suis passé sur un passage sur la pensée créative et le conformisme. Un professeur fait passer un test en physique et les étudiants doivent indiquer comment mesurer la hauteur d'un édifice si on leur donne un baromètre. Un étudiant répond qu'il existe plusieurs façons d'obtenir la hauteur de l'édifice (du point de vue du professeur, ça démarre mal…).

 

On peut, par exemple, monter en haut de l'édifice et laisser tomber le baromètre en mesurant le temps qu'il met à s'écraser au sol, qui permet d'obtenir la hauteur (h=0.5at^2 si ma mémoire est bonne, où a est g la constante d'accélération gravitationnelle de la terre, soit 9.8 m/s^2).

 

On pourrait aussi monter au sommet de l'édifice, attacher le baromètre à un corde, et faire descendre le baromètre pour ensuite mesurer la longueur de la corde.

 

Le professeur donne un gros zéro à l'étudiant! Mais il donne à l'étudiant la chance de se reprendre. L'étudiant repasse son test et répond :

 

On pourrait aussi mesurer la distance entre notre œil et le baromètre lorsqu'on place le baromètre devant l'édifice à l'endroit où il apparaît aussi grand que l'édifice. En mesurant la hauteur du baromètre et la distance entre notre œil et l'édifice, il est possible de déduire la hauteur de l'édifice par la loi des triangles semblable (a/b = a'/b').

 

Dans le même ordre d'idée, on pourrait mesurer la longueur de l'ombre que fait le baromètre à midi et mesurer celle de l'édifice. Connaissant la hauteur du baromètre on en déduit celle de l'édifice.

 

On pourrait encore mesurer la hauteur d'un étage en se servant du baromètre comme unité de mesure (un étage = n baromètres empilés les uns sur les autres), multiplier par le nombre d'étages et obtenir la hauteur en "unité barométrique". Mesurer la hauteur du baromètre en cm permettrait d'obtenir la hauteur de l'édifice en mètre assez facilement.

 

On pourrait aussi demander au concierge la hauteur de l'édifice en échange du baromètre.

 

Le professeur donne fait venir l'étudiant en entrevue et lui explique que ce n'est pas la réponse attendue et qu'il doit donner une note de zéro. L'étudiant explique qu'il connaît la réponse attendue (la connaissez vous?) mais qu'il croit que ses réponses ont plus de valeur (et valent le maximum de points) car elles démontrent qu'il est en mesure de solutionner le problème de diverses façons, dont certaines sont inédites alors que n'importe qui peut le faire de la façon attendue (surtout avec Google maintenant).

 

Quel genre d'étudiants voulez-vous embaucher? Celui qui connaît la réponse du livre ou celui qui est en mesure de vous fournir un nouveau point de vue sur la situation?

 

Pour terminer, cela me rappel un professeur que j'ai eu dans un cours de physique nucléaire à l'université. Professeur Shogy, un hongrois, si mon souvenir est bon (il disait que la physique nucléaire était plus facile que le hongrois et que des enfants de 4 ans parlait hongrois!). Si vous lui donniez la réponse attendue il vous donnait 100%. Si vous étiez créatif, vous obteniez des points. Il y avait aussi des points pour l'effort, si vous vous amélioriez de test en test, il était plus généreux. Mon premier test : 125%, je me suis dis que ce serait difficile de faire mieux. Je garde encore un excellent souvenir de M. Shogy.

P.S. En y pensant bien, j'en ai trouvé au quelques autres :

- si le baromètre est au mercure, on pourrait le casser au pied de l'édifice (dans un bol pour éviter la pollution) et du haut de l'édifice envoyer une impulsion laser s'y réfléchir, mesurer le temps entre le départ de l'impulsion et son retour, diviser par 2 et par la vitesse de la lumière pour obtenir la hauteur.

- toujour s'il s'agit d'un baromètre au mercure, le casser légèrement, afin que le mercure s'écoule goutte à goutte de façon régulière. En calculant le temps entre les gouttes, et en comptant le nombre de goutte qui s'écoulent on peut en déduire la hauteur. Je dois admettre que cette méthode me semble plus compliquée à mettre en oeuvre.

- on pourrait lancer le baromètre du haut de l'édifice, et compter le temps entre le moment où on le voie s'écrasser et le moment où on entend le bruit. Avec la vitesse du son dans l'air (720 m/s si ma mémoire me sert bien) on peut calculer la hauteur.

- on pourrait aussi essayer de troquer avec le concierge le baromètre pour un ruban à mesurer.

- on pourrait aussi prendre ma montre altimètre, pas besoin du baromètre!

- aussi certain édifice annonce leur hauteur, surtout si elles ont une plate-forme d'observation ou un restaurant.

06 juin 2010

I am in Vegas baby!

Je suis, cette semaine, au "Better Software Conference 2010" à Las Vegas. Ce que j'aimes de ces conférences, longue et à l'extérieur du pays, c'est qu'elles me donnent l'occasion de prendre du recul par rapport au métier. Bien sûr, les conférenciers nous présentent des sujets à la fine pointe des pratiques et des techniques et je fais l'éponge, mais au-delà de ce que l'on reçoit et apprend, c'est le moment de réflexion entourant la conférence qui me procure le plus de valeur.

A l'aéroport je m'achète un bon livre pour le vol et du moment où je monte dans l'avion, j'entre dans un bulle. Lentement, je me laisse pénétrer par la conférence. Les sujets pop dans ma tête, les réflexions, les idées, les préoccupations aussi.

Déjà, hier, en vol, j'ai joué avec quelques pistes de réflexions en lisant "Linchpin" de Seth Godin, en écoutant un reportage sur Georges Eastman (Kodak) et un film percutant "Manufactured landscape". En vrac: la passion ou plus souvent le manque de passion, le "je fais ma job" dans le sens de, je fais ce qu'on me demande, la satisfaction au travail, ce qui m'anime au travail. Aussi, le travail à la chaine, la notion de "fabrique de code", de contrôle de qualité, les personnes remplaçables comme des toaters. L'excellence. L'éducation. L'avenir que ma fille aura et combien il sera à la fois différent et tristement similaire.

En débarquant à Las Vegas, ma première visite ici, une fois le choc de la chaleur intense passé (38 Celsius à l'ombre) je suis aller marché sur le "strip" et je me suis mis à penser au thème de l'authenticité. Pas très difficile comme rapprochement! Il n'y a pas grand-chose d'authentique à Las Vegas et je vous épargne les images qui nous viennent facilement à l'esprit. L'authenticité. L'authenticité. Suis-je authentique? Pourrais-je l'être plus? Qu'en est-il de nos organisations? Des gestionnaires? De nos produits et solutions? J'ai le sentiment que l'authenticité se cache, qu'on la voie rarement.

17 avril 2010

screen scraping en groovy

Je viens de m'amuser à aller chercher la température sur le site de météoMédia avec un simple script groovy:

 

import

 

org.ccil.cowan.tagsoup.Parser;

slurper =

new XmlSlurper(new org.ccil.cowan.tagsoup.Parser())

url =

new URL(http://www.meteomedia.com/weather/caqc0257)

 

url.

withReader { reader ->

 

 html = slurper.parse(reader)

 

 

  println  html.body.div.div.div.div.div.div.div.div.p

}