Auteur : Natacha

Birt 4.2 et la gestion des images

    Birt 4.2 ne veut que du 96 ?

birt 4.2 72dpi photoshopEn passant à Birt 4.2 pour l’édition de documents nous nous sommes rendu compte que la gestion des images était sensiblement différente d’avec les versions précédentes.

Birt 4.2 contrairement à ses prédécesseurs prend exactement la taille de l’image spécifiée en cm/pouces. Autrement dit pour la taille d’un logo standard de 450px de large, on se retrouve avec un logo imprimé avec une taille de 3,81cm pour une haute résolution de 300dpi (pixels par pouce), mais le même logo de 450px en résolution 72dpi (le standard du web) aura une largeur de 15,88cm une fois imprimé, là où avant Birt se servait de la taille en pixel en imprimant toujours avec la même résolution.

Lire plus

Texte défilant en css avec CSS3

Comment faire un Texte défilant en css ?

Texte défilant en css et l’utilisation de l’attribut data-text pour fournir un roulement continu

Le plus simple pour faire un texte qui défile, c’est d’utiliser la balise <marquee> pour encadrer la partie à faire défiler. C’est simple certes, mais marquee étant une balise propriétaire de Microsoft, elle n’est pas valide w3c (bien qu’elle soit correctement interprétée par tous les navigateurs) et quand on se soucie d’avoir un site valide elle est donc exclue.

Une autre solution, un peu plus complexe mais cependant accessible est d’utiliser javascript pour simuler le défilement. C’est d’ailleurs la solution qui est le plus proposée par les internautes. Mais comment faire si, pour une raison ou une autre on ne veut pas ou ne peut pas utiliser javascript ?

Lire plus

Scrum : retour aux fondamentaux

Retours sur la méthode Scrum après 6 ans d’utilisation

Les 10 et 11 Avril se déroulait la quatrième édition du ScrumDay. L’occasion pour nous de découvrir pas mal de nouveautés mais également de revenir par certains aspects sur les notions essentielles de l’agilité.

La keynote d’ouverture était assurée par Alistair Cockburn, signataire et co-auteur du manifeste agile. Les slides de la keynote se trouvent ici.

Il est revenu sur les 4 valeurs du manifeste et leur trop (souvent) mauvaises interprétations puis a introduit un concept issu de l’Aïkido qui décrit les 3 étapes de l’apprentissage :

  • Shu (守:しゅ?, « protéger », « obéïr ») — sagesse traditionnelle – apprendre les fondamentaux
  • Ha (破:は?, « se détacher », « digresser ») — casser avec la tradition — trouver les exceptions à la sagesse traditionnelle, trouver de nouvelles approches
  • Ri (離:り?, « quitter », « se séparer ») — transcender — il n’y a pas de technique ou de sagesse traditionnelle, tous les mouvements sont permis

(source wikipedia)

Ce concept est pour lui réplicable quelque soit le domaine d’application et en particulier l’agilité.

Il a ensuite zoomé sur Scrum et ce qu’il nomme le coeur de Scrum :

  1. Livrer à chaque sprint
  2. Laisser l’équipe décider
  3. Inspecter et s’adapter tous les jours, et à chaque sprint
  4. Un Scrum Master a du temps pour lever les obstacles
  5. Le métier ne s’exprime qu’à travers une seule voix (Product Owner)

Mais le plus intéressant est qu’il considère « tout le reste » comme « barnacles » (parasite) ou pire rumeur et ouï-dire :

  • Burn-down charts
  • Kanban (Not-started | Started | Done) boards
  • ScrumMaster is / is not the project manager / product owner / tech lead
  • Product Owner is / isn’t invited to the dailies
  • The “3 questions” at the daily stand-up
  • User stories
  • Planning Poker
  • Fibonacci numbers / hours / story points

Il ne veut pas dire par là que l’on doit jeter toutes ces pratiques à la poubelle mais bien qu’elles doivent être choisi par l’équipe elle même si celle-ci considère que telle ou telle pratique apporte un plus aux 5 points points qui constituent le coeur de Scrum.

Et nous dans tout ça ?

Cela fait presque 6 ans que nous « utilisons » Scrum. Nous avons mis en place toutes ces pratiques et plus, puis en avons abandonné car l’équipe ne les trouvait pas/plus adaptées :

  • Pas adaptée comme par exemple le planning poker : nous trouvions que cette pratique était trop fastidieuse et pas assez productive par rapport à la taille de notre backlog. Avec cette pratique, nous estimions environ 10 user stories en une heure alors que nous en avions 100 à chiffrer. Nous avons depuis mis en place une autre pratique qui nous correspond plus.
  • Plus adapté comme par exemple la revue de backlog : dans les premiers mois/années nous faisions une revue de backlog périodique avec l’équipe qui permettait à notre PO d’affiner les User Stories grâce au commentaires de l’équipe et de débuter une conception de haut niveau. L’expérience (culture) aidant, nous n’avons plus eu besoin de cette revue et si certains points ne sont pas clairs, nous avons la faculté de donner des réponses « à la volée » lors des démarrages de sprint (connaissance partagée).

Depuis quelques mois nous avons débuté de nouveaux produits et patatra… Nous nous sommes pris les pieds dans le tapis, sans vraiment s’en rendre compte. Nous avons adopté les mêmes pratiques et réflexes (nature) que pour notre produit principal, mais en omettant quelques détails :

  • Nouveautés produits (fonctionnel et conception)
  • Manque d’expérience de l’équipe : pas en terme d’années mais sur les produits, les rôles (PO) et l’architecture

Ces problèmes sont, bien entendu, remontés lors des rétrospectives de sprint, mais le diagnostic que nous en avons fait était assez parcellaire.

Un petit détour par la Coach Clinic du ScrumDay (merci à Fabrice Aimetti@fabriceaimetti) suite à la keynote, quelques échanges de tweets, et la lumière fut : le contexte dans lequel nous évoluons n’est plus le même, nous devons (ré)apprendre, (re)pratiquer (Shu) pour ensuite progresser dans le Ha et le Ri. L’équipe va donc devoir se réapproprier certaines pratiques qui lui permettront sur ces nouvelles bases d’acquérir l’expérience nécessaire à son évolution.

En conclusion et avec une vision plus « aérienne », nous devons constamment évoluer dans une spirale dynamique : pratique, culture, nature, pratique, culture, nature, … afin de nous permettre de revenir aux fondamentaux lorsque c’est nécessaire pour ensuite transcender et transgresser l’existant pour toujours être en mouvement. (Merci à Pablo Pernot @pablopernot)

« Notre nature est notre culture, et notre culture est notre nature » Edgar Morin. (Pablo, La Horde Agile)

Loading...
X