A la Poursuite du Code en Rouge

Zoho Creator permet d’éditer en ligne une appli type MsAccess très simple, à base de formulaires. Pourquoi je vous en parle ? Eh bien ça faisait quelque temps que je cherchais ma liste de tâches en ligne, multi-utilisateurs, un peu inspirée GTD, mais le plus simple possible à utiliser. J’ai essayé pas mal d’options, utilisé un temps google bloc-notes et ses étiquettes (ça marche plutôt bien en solo mais le partage d’étiquettes ne fonctionne pas ).

Développer moi-même ? Bof, je voulais pas non plus investir trop de temps là-dessus. Mon hébergeur supporte pas le Java, faut se mettre à PHP. Autant je veux bien bidouiller la skin pour WordPress de ce blog, mais de là à faire une appli de zéro… Entre chercher les plugins ad-hoc pour eclipse, installer MySQL, un débuggeur zend, y a-t’il des frameworks PHP ? quelque chose genre PEAR-machin-truc ? Pfiou, pas le temps, tant pis, va pour le bloc-notes…

Et puis, un peu par hasard, pour essayer Zoho Creator, j’ai créé un formulaire « A Faire », pour voir. Et là… magie Deux heures après mon appli était « en prod » : hébergée par zoho, multi-utilisateur, je pouvais saisir mes contextes, projets, tâches, et avoir sur mon onglet d’accueil un calendrier auto des deadlines à venir et des tâches urgentes.

Alors bien sûr, ce n’est pas votre IDE. Vous ne trouverez qu’un langage de script très limité et une palette restreinte de composants. Ils n’ont pas inventé le principe de ce genre d’outils, mais ce que je trouve très bien fait chez eux est leur application du 80/20 (80% de votre code couvre les 20% de cas particuliers). Et bien en avançant dans mon appli, leur outil étant assez minimaliste, je pensais tomber sur une limitation toutes les 10 minutes pour découvrir que non, c’est prévu. Tous les besoins de base de mon appli, pas très originale, certes, sont couverts par l’outil. Les 80% de cas général dans lesquels je tombe ont été très bien choisis par les gens de Zoho.

J’utilise maintenant mon appli au quotidien comme liste des tâches principales, avec ces petites modifs que l’on découvre par l’usage. Si l’appli intéresse quelqu’un je pourrai la libérer en GPL.

Glop

• prise en main rapide, développement simple et rapide
• hébergement de l’appli, pour autant d’utilisateurs que l’on veut, gratuit
• formulaires embarquables dans tout site web, avec gestion des droits, captchas…

Pas glop

• les applis ne sont disponibles qu’en anglais (c’est très pénible le calendrier qui démarre les semaines le Sunday )
• pas de solution d’import/export automatique de l’ensemble des données saisies
• documentation minimale, suivi des bugs dans un forum au lieu d’un issue tracker digne de ce nom. En respectant le « eat your own dog food« , l’issue tracker devrait être une appli zoho creator, non ?

Verdict

Mon application web bête comme chou déployée en moins de temps qu’il n’en faut pour configurer un environnement de dév PHP.

---

Les liens Wikipédia du jour Getting Things Done 80/20 captcha

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 ?
• 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

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 ? 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 ».

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.