A force d’utiliser gmail ou autres en version-beta-perpĂ©tuelle, on en oublie de vĂ©rifier la stabilitĂ© d’une application avant de l’utiliser.

Ceci est d’autant plus vrai que la frontière entre diffĂ©rents niveaux de stabilitĂ© estimĂ©s (alpha, beta, release-candidate, release, service pack, j’en passe et des meilleures) tend Ă  disparaĂ®tre pour le logiciel-service, oĂą une application n’est virtuellement dĂ©ployĂ©e qu’en un exemplaire globalisĂ©, mis Ă  jour en temps rĂ©el. Très rarement, le choix entre deux versions - la version “stable et moche je vous en prie, basculez” et la version “ouah trop belle vous serez heureux de l’utiliser” - est laissĂ© Ă  l’utilisateur : yahoo mail, ou le dashboard de google apps sont deux cas isolĂ©s. On en est arrivĂ© au point oĂą il faut s’abonner Ă  un blog pour suivre les Ă©volutions de son logiciel-service.

Bref, tout ça pour dire que google page creator, c’est simple, c’est sympa, mais c’est plutĂ´t bugguĂ©. Je ne jette pas le bĂ©bĂ© avec l’eau du bain : pour rendre l’Ă©dition de petites pages web en logiciel-service accessible Ă  un public non initiĂ©, c’est assez rĂ©ussi. Mais ça manque de try-catch. Les scripts Ă©chouent silencieusement pour des manipulations assez banales, et l’on se retrouve Ă  refaire la mĂŞme manipulation dix fois de suite avant de comprendre que cela n’aboutira jamais. Cruel dilemme entre afficher un message d’erreur incomprĂ©hensible qui n’intĂ©resse que les dĂ©buggueurs et se taire… Les dĂ©veloppeurs de page creator ont tranchĂ©, le silence est absolu, au point de laisser croire Ă  l’utilisateur que son action a abouti, ce qui est *mal*.

C’est Ă  ce moment de notre histoire que notre utilisateur se tourne vers l’informaticien pas loin : “oui-je-sais, c’est pas toi qui a Ă©crit ce logiciel, mais tu as l’habitude d’isoler les problèmes, s’il-te-plaiiiiiiit”. Ainsi, par essais-erreurs successifs on finit par trouver le contournement, en se disant que, tout-de-mĂŞme, il est bien Ă©vident ce bug, ils auraient pu le tester chez google, ça me donne une idĂ©e de billet Ă  Ă©crire lĂ -dessus (celui que vous ĂŞtes en train de le lire).

Pour vous faire gagner du temps, les contournements jusque ici :

Page non atteignable : le lien produit par creator n’est pas une URL correcte.

Par exemple, vous crĂ©ez une page, lui donnez le titre “Exemple :”, et les liens vers cette page gĂ©nĂ©rĂ© par creator sont de la forme “Exemple :” au lieu de “http://monserveur/Exemple%20:”.

Vous pourrez essayer de changer le titre autant que vous voudrez, le premier nom donnĂ© Ă  la page sera gardĂ© jusqu’Ă  la suppression de cette page.

Contournement : quand vous crĂ©ez une nouvelle page, donnez-lui toujours un titre URL-amical “exemple”, sauvez une première fois. Vous pourrez mettre le titre dĂ©sirĂ© par la suite, l’adresse de la page restera “exemple”.

Mon image n’affiche pas le menu contextuel quand je clique dessus

J’ai constatĂ© que des noms d’image avec des points inclus (exemple : “mon.image.05-04.fr.jpg”) fait que creator n’arrive plus Ă  manipuler l’image. Je vous conseille de supprimer l’image et de la recharger avec un nom plus basique “monimage0504fr.jpg”.

PostĂ© le 14 novembre 2007 dans 101010 par schwinlSans Commentaire »

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

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 :D

  • 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 :roll:

Verdict :idea:

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