Tag Archives: methodologie

Intelligent Reaction

Google fait le décompte des touches les plus utilisées par les utilisateurs de google reader. Le côté big brother peut faire peur mais il y a aussi un intérêt pour les utilisateurs. C’est en analysant ces données que google décide des évolutions à donner à son service.

Adam Bosworth ex-google explique le concept qu’il a nommé intelligent reaction. Un site web ne s’arrête pas à l’interface visible par les internautes, une “shadow app” qui analyse le comportement de ces utilisateurs peut se révéler très utile.

Client feedback

Trouvé sur fffound ( merci Franck, si quelqu’un connait la source originale…)

projet.jpg

Le fournisseur met toute son énergie dans la réalisation de l’idée initiale. Comme le client n’est pas dans la même équipe, le feedback est parfois douleureux! Qu’on ne se trompe pas, sur l’action suivante c’est le fournisseur qui fera un passage en force.

Que faire? Sortir du carcan de la relation client/fournisseur, MOA/MOE , soyez agile... Une bonne intro à Scrum et XP chez Xebia.

Tetris et le développement logiciel

tetris1.pngFaire évoluer un logiciel c’est comme jouer à Tetris.

Au début c’est facile. Les nouvelles pièces qui tombent représentent les fonctionnalités demandés par le client. Il n’y a pas encore trop de code, c’est propre, on peut facilement intégrer les nouveaux blocks.

tetris2.png

Mais au fil du temps la quantité de code à maintenir augmente, sa qualité se dégrade, il y a des trous dans vos lignes de Tetris.

Vous y arrivez encore, il vous reste un peu de marge de manoeuvre, vous faites tourner les pièces pour adapter la demande du client à votre existant.

En anticipant un peu vous auriez pu prévoir un emplacement pour accueillir la prochaine pièce à venir sans la faire tourner.

tetris3.png

Malheureseument vous n’avez pas refactoré votre code à temps. Votre client à un nouveau besoin. Bien qu’il soit simple, c’est la modification de trop, votre code explose: GAME OVER

La métaphore est de Régis Medina lors des rencontres agiles de mardi dernier.

Peopleware

peopleware_m.jpgJ’ai enfin lu ce grand classique, ce n’est pas un hazard si sur Amazon PeopleWare est vendu avec The mythical man-month. Les deux sont des lectures impératives pour les chefs de projets et le management en général.

Quelques extraits des passages qui ont le plus retenu mon attention.

“When you automate a previously all-human system, it becomes entirely deterministic. The new system is capable of making only those responses planned explicitly by the builders.”

Pour moi ça résume bien l’un des principaux problèmes de la relation MOA/MOE. La MOA exprime le besoin des utilisateurs, qui fonctionnent de manière non déterministe, tout n’est pas prévu à l’avance, il y a beaucoup d’implicite. La MOE doit traduire ce besoin en programme informatique, un monde exclusivement déterministe, où l’implicite n’existe pas, tout doit y être explicite.
A propos de CMM (l’ancêtre de CMMI)

“The projects most worth doing are the ones that will move you DOWN one full level on your process scale.”

“Process isn’t worth a rip unless it’s applied to projects that are worth doing”

Je n’ais jamais été très convaincu par l’approche CMMI, maintenant je sais pourquoi.scrumandxpfromthetrenches.jpg

Dans la foulé de Peopleware j’ai lu Scrum and XP from the Trenches un retour d’expérience de Henrik Kniberg sur les méthodes agiles. En le lisant j’ai tout simplement eu le sentiment que Scrum était l’implémentation des théories exposées dans Peopleware. Si vous ne devez lire qu’un seul document cette année, c’est celui-ci.

Cas d’utilisation : sans objet

“Cas d’utilisation : sans objet”

C’est fort dans un document de spécification,  non? Par contre le document décrit en détail les paramètres en entrée et en sortie de toutes les fonctions attendues. La personne qui a rédigé ce document (et on ne parle même pas de celle qui l’a validé) sait comment elle veut faire, mais elle est incapable d’exprimer ce qu’elle veut faire, le quoi. Je vais pouvoir rajouter une ligne à comment rater un projet.