A la Poursuite du Code en Rouge - Le blog de Guillaume Rams sur le génie logiciel

Revue de RSS

10 février 2008 Guillaume Commentaires désactivés

Norman Walsh nous annonce la sortie de DocBook version 5.0. Ça ne fera probablement pas grand bruit… Je suis un fervent défenseur de DocBook pour produire la documentation technique, mais on ne doit pas être assez nombreux, en tout cas l’utilisation de DocBook me semble confidentielle. C’est bien beau le « voici les DTD et les XSLT, démerdez-vous vous avez tout ce qui vous faut », mais l’adoption de DocBook serait facilitée par une chaîne d’édition DocBook libre, facilement installable et utilisable. Faut reconnaitre que le premier « bonjour, monde ! » en DocBook se fait pas en cinq minutes.

Finalisée également la cinquième édition de XML 1.0. Eric Van der Vlist nous explique en quoi cela augure la mort de XML 1.1 et en quoi c’est pas si grave. Les autres annonces de ce déjà fertile mois de Février, PostgreSQL 8.3, WordPress 2.3.3 (un correctif de sécurité avant tout, la mise-à-jour est fortement recommandée si comme moi comme ce site vous êtes sous WordPress) ainsi que les branches 5.5 et 6.0 de Tomcat.

Génie Logiciel, Sauf cross-post DocBook, Revue de RSS, Wordpress, XML

La gestion de projet Scrum

14 novembre 2007 Guillaume Commentaires désactivés

Après les cycles en V, en cascade ou en escargot, voici venu la gestion en ballon ovale : scrum (ou mêlée de ce côté-ci de la Manche).

Scrum (vu de super-loin)

Scrum est une méthode « agile », légère, adaptative, itérative – je suis à court d’adjectifs – plutôt pour les petites équipes et les projets de taille modérée.

Résumé des règles du jeu (vu de loin)

Une particularité de Scrum est une gestion très légère. Les quelques grandes lignes exposées ici constituent 80% de la méthode. L’art de scrum insiste sur la bonne conduite de réunions, qui vont rythmer le projet.

Le démarrage de sprint

Scrum est une méthode itérative, dans laquelle chaque itération, de longueur fixe et plutôt courte (30 jours par exemple), est appelée un sprint. Le but d’un sprint est de produire un ensemble de fonctions démontrables et livrables à la fin du sprint.

La réunion de démarrage de sprint permet de choisir parmi la liste des développements souhaités ceux qui seront réalisés lors du prochain sprint. Une fois ce choix effectué, on essaiera dans la mesure du possible de « protéger » l’équipe de réalisation des aléas de planning et avant-ventes, et on ne tiendra compte des changements de priorités que lors du démarrage du prochain sprint.

Le daily scrum (mêlée quotidienne)

Les développements prévus pour ce sprint sont découpés par l’équipe de réalisation en tâches, à la granularité de moins d’une journée, sans entrer dans le micro-détail de la demi-heure. Chaque jour, toute l’équipe se réunit pour une réunion de coordination très courte (par exemple 20 minutes maximum, montre en main) : la mêlée quotidienne. Chacun doit répondre à ces trois questions :

Ce que j’ai réalisé depuis la dernière mêlée :!:
Ce que je projette de faire jusqu’à la prochaine mêlée
Les difficultés potentielles pour cette tâche, que la hiérarchie ou l’équipe doit essayer de lever

Fin de sprint et rétrospective

A la fin du sprint, l’équipe organise une séance de démonstration interne et surtout externe (hiérarchie, support, commerciaux, end-users…) des fonctions ajoutées ou modifiées lors du sprint. L’équipe procède ensuite, éventuellement à une auto-congratulation et un restau buffet-à-volonté, mais surtout à une rétrospective :

Qu’est-ce qui a bien fonctionné lors de ce sprint ? 8)
Qu’est-ce que l’on pourrait améliorer pour les prochains sprints ?

La méthode est un guide, pas un carcan : les équipes vont adapter la méthode et optimiser leur processus de sprint en sprint.

Glop

prise en main rapide et ludique de la méthode par les gens impliqués
insiste sur l’importance de la conduite de réunion
prévoit des démonstrations et des livrables afin de limiter l’effet tunnel lors du sprint

Pas glop

Difficile à mettre en place dans des environnements bureaucratiques
Demande beaucoup d’autonomie de chaque membre de l’équipe…
… et de l’équipe dans son ensemble
Demande à ce que l’on laisse de l’autonomie à l’équipe

Verdict

Cette méthode n’est sûrement pas applicable à tous les environnements ni une bonne méthode pour gérer de la production intensive bien balisée.

Scrum est une très bonne méthode pour gérer des projets plutôt R&D, de prototypage par exemple, ou de développement XP de taille modérée. Elle permet à une équipe expérimentée de s’auto-organiser en souplesse. Les démonstrations de fin de sprint sont très importantes (des fois vitales ) particulièrement dans une optique de R&D mais souhaitables dans tout environnement.

Une richesse méconnue de scrum est la possibilité de gérer un projet très transverse, de créer une organisation de projet ad-hoc virtuelle. Prenons l’exemple de la mise en place d’un intranet, le scrum pourra permettre aux différents acteurs de coordonner leurs efforts, sans pour autant qu’il y ait de hiérarchie bien définie entre les acteurs du projet. Etant légère, la gestion scrum ne vient pas exagérément alourdir la gestion de projet existante de chacun. C’est dans cet optique qu’un prochain billet montrera comment on peut créer une infrastructure ad-hoc de projet scrum légère et efficace, en se basant sur l’offre d’applications en ligne google apps. Bref, Scrum en SaaS, c’est pour bientôt (et buzzword-compliant ).

Restez à l’écoute.

Le lien Wikipédia du jour : Scrum

Informatique en général, Sauf cross-post Agilité, Google Apps, Scrum

ohmerde4j

6 novembre 2007 Guillaume Commentaires désactivés

Alors, prenons le prochain ticket d’incident… voilà. bla bla bla… mmmh. OK. Ça doit pas être bien compliqué ça devrait se trouver quelque part dans cette classe, là. Tiens, je l’ai jamais ouverte celle-là. Allons-y, Ctrl+Shift+T, OK, de quoi ça a l’air ? 8O Oh meeerde…

C’est précisément l’effet « rôh merde » qu’essaie de mesurer l’outil Crap4j, via la métrique CRAP (Change Risk Analysis and Predictions), ou bien, en français, l’ohmerditude. Cette traduction en vaut une autre, et puis j’aime bien le suffixe « -itude » .

Ce qui me plaît dans cette métrique, c’est que, pour une fois, on part de la question avant de parler de chiffres. Je n’aime pas l’approche qui consiste à constituer des tableaux de chiffres sans fin, qui certes donnent un air très savant, mais qu’on est bien en peine d’exploiter . A travers l’ohmerditude, dans le but de vérifier qu’un code est maintenable, on essaie de répondre à la question « un développeur va-t’il trouver risqué de modifier ce code lors d’une maintenance ? ». Si oui, on prend le risque que personne ne touche plus à ce code qu’entre deux doigts, le bras tendu et en se pinçant le nez de l’autre main (voir fig. 2 ). Les développeurs vont ajouter tout autour de cette boîte noire des couches et des couches de rustines et contournements de moins en moins maintenables .

Maintenant que vous touchez du doigt tout l’intérêt potentiel de cette métrique, intéressons-nous à son calcul. La formule est un dosage pifométrique de complexité cyclomatique et de couverture de tests. En gros, un code sera « crappy » (ou « ohmerdique » si vous préférez) si il est (1) très complexe et (2) très peu testé. Un code très simple sans test ou un code complexe mais très bien testé seront considérés comme acceptables.

Crap4j mélange donc le nombre de conditions à tester avec la couverture de lignes des tests… mmmmh. bon, on a vu pire. Plus exactement, Crap utilise le taux de lignes non couvertes. Si l’on pose l’hypothèse que les décisions sont uniformément réparties dans les lignes de code, alors cette mesure serait une sorte d’estimation de la quantité de décisions non testées. Malheureusement je ne connais pas d’éléments qui viendraient confirmer cette hypothèse, et ça serait quand même peu fiable.

Quel usage ?

Prise en tant que métrique isolée, cette mesure ne serait pas passionnante. Par contre, je l’utiliserais comme indicateur de testabilité et de possibilité de changement. Selon l’ISO-9126, testability et changeability sont bien des sous-caractéristiques de maintainability, on est bien en élément de réponse à la question initiale. Et comme la norme laisse complètement libre la façon de calculer des indicateurs pour les sous-caractéristiques qualité (ce qui est la façon normative de dire « démerdez-vous on vous donnera pas la formule »), Crap peut être utilisé comme formule de calcul de testabilité « sur étagère », qui présente l’avantage d’être simple à expliquer, rapide à mettre en oeuvre et déjà outillée.

A condition que vous n’ayez pas déjà d’outil de mesure qualité qui vous permette de consolider différentes mesures, et à condition également de calibrer crap4j en fonction de vos exigences, celui-ci peut constituer un premier niveau d’outillage qui vous incitera peut-être à aller plus loin.

On préférera peut-être la version produisant des rapports (via ant, à intégrer à son build continu, donc) que la version plug-in eclipse : le public visé pour cet indicateur de risque qu’un changement soit non testé me semble plutôt le gestionnaire (chef de projet par exemple) que le développeur, qui va probablement garder sous les yeux dans son IDE des règles de codage plus immédiatement « actionnables ».

Génie Logiciel, Sauf cross-post crap4j, Java, Métrique, Qualité de code

Le monde merveilleux de la mercatique

3 novembre 2007 Guillaume Commentaires désactivés

Mybooo (http://mybooo.com/) est un webtop, tout nouveau tout beau. Je ne vais pas vous causer technique, car ce qui me frappe chez eux, c’est plutôt l’inflation de ‘o’, qui n’est pas sans rappeler l’époque pas si lointaine de l’explosion des startups en point-com. Rappelez-vous, le double-o était de rigueur, presque une règle de la grammaire de la mercatique (on dit également marketing ) façon hiboo, genoo, choo, cailloo, poo.

Seulement, voilà, on est passé de deux ‘o’ à trois ‘o’, et ça c’est pas anodin. Un peu comme les rasoirs, quand on est passé de deux à trois lames. Et puis ça s’accélère, fatalement. Si trois lames c’est mieux que deux, alors quatre c’est forcément encore mieux. Déjà qu’à deux lames on coupait au plus près de la peau, on se demandait à quoi servait la troisième ; à cinq lames on commence à racler l’os… Dans la même veine, si le web 2.0 c’est vachement mieux que le web (implicitement 1.0), le web 3.0 (que l’on nous prédit sémantique) sera forcément vachement mieux encore. Le web 3.0 sera plein de ‘Oooooo’ lui aussi. Les startups seront toutes baptisées par le bibliothécaire de l’université de l’invisible (Oooook ).

Au buzzwordopifomètre, le web 2.0 atteint des sommets. C’est rigolo comme tout de suggérer l’idée de version, comme pour un logiciel, deux point zéro, ah ah. Est-ce que pour autant quelqu’un aura le courage de créer le premier site web 2.0.2 (Service Release 2 - build 348) (stable) ?

See yooooo soooooon.

Le reste, Sauf cross-post Mercatique, WebTop

Page n° 7 sur 8
Prev
1
...
5
6
7
8
Suivant