A la demande gĂ©nĂ©rale de une personne, mais bon je l’avais promis et c’est demandĂ© gentiment…
Si vous aussi vous voulez installer l’appli chez Zoho, vous trouverez toutes les infos sur une page dĂ©diĂ©e. Ta-daaaah 
http://www.schwinl.net/liste-a-faire .
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.
) 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 ?
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.
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 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.
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.
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.
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 :
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 :
La méthode est un guide, pas un carcan : les équipes vont adapter la méthode et optimiser leur processus de sprint en sprint.
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.
Alors, prenons le prochain ticket d’incident… voilĂ . bla bla bla…
Ctrl+Shift+T, OK, de quoi ça a l’air ?
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.
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”.