Affichage des articles marqués Google Apps

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

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