Java Bien!

Presque un an que je donne des formations Scrum pour le compte de Valtech Training. Chaque formation, je tente d’améliorer le contenu et la forme afin que les stagiaires puissent mettre en oeuvre dès le lendemain.

Doux rêve du formateur…

Il est clair que deux jours de formation, en dehors de tout contexte projet, ne remplacent pas l’apprentissage, à la dure, sur le terrain. Toutefois, si l’on compare une équipe qui a suivi la formation, à une équipe qui a pris connaissance de Scrum “Just In Time”, l’impact positif de la formation est flagrant.

A condition de passer “les” bons messages. Ou plutôt les messages qui, avec toute ma subjectivité, doivent faire partie de la mallette qu’un stagiaire ramène dans la vraie vie.

Laissez moi partager quelques messages avec vous (les critiques sont les bienvenues) :

1/ Mettre en place Scrum, c’est tenter l’aventure de l’amélioration continue. Sprint après Sprint l’équipe sera plus performante. A une condition : viser haut, être idéaliste.
Je m’explique : Scrum offre un cadre méthodologique difficile à adapter totalement à nos organisations sédimentarisées. Pourtant, l’important est de viser continuellement ce cadre idéal plutôt que de vite s’arrêter en cours de chemin à une mise en oeuvre partielle de Scrum. Le risque est de mettre en place le plus facile et de laisser tomber le plus important.

Je constate par exemple que la rétrospective est souvent vite abandonnée. J’insiste donc en formation sur le fait que si l’on doit ne garder qu’un principe, cela doit être “Inspect and Adapt”, donc les rétrospectives. La dernière heure de la formation prend d’ailleurs la forme d’une rétrospective.

2/ La complexité de la plupart des projets de développement logiciel n’est pas technique. Les problèmes viennent de notre incapacité à travailler de ensemble dans un but commun. Les compromis et les consensus sont pénibles et la transparence de Scrum ne pardonne pas les erreurs individuelles. Il faut transcender cet état de fait si l’on veut s’améliorer. Cela ne se fait pas sans douleur et le binômage, par exemple, est un choc pour presque tout le monde.

En formation, les exercices démontrent que la collaboration en timebox est ultra efficace. L’excellence individuelle est la bienvenue au service d’une équipe.

Blog Coaching, Formation, Retrospectives, Scrum

http://martine.logeek.com/index.php

Blog Jokes, Retrospectives, Scrum

Je viens de démarrer un nouveau projet en tant que Scrum Master. Je me trouve au sein d’une équipe éditique. Nous devons produire une batteries de documents destinés à des clients (courriers, contrats, …). La qualité des documents est notre préoccupation première.

Pour valider le contenu et la forme de nos documetns, Scrum va nous permettre de vite avoir du feedback. Par contre, il existe de nombreuses règles à respecter pour qu’un document soit complet et satisfaisant. Par exemple, nous sommes limités à une liste de polices et à certaines couleurs. Nous devons vérifier que les blocs de texte ne se chevauchent pas dans des cas limites. Les marques de pliage et les adresses postales doivent être positionnées très précisément… Dans ce domaine, il n’est pas certain qu’un oeil humain puisse nous aider. Plus le nombre de règles est important, plus difficile il sera de valider un document.

Mes réflexes de développeur Java me poussent à chercher des outils de tests automatisés. Un peu comme un checkstyle permet de vérifier le respect de quelques normes de codage, il faudrait un outil capable de décortiquer un document pdf et à même de vérifier certaines règles communes à tous les documents.

Mes recherches sur Google n’ont rien donné pour l’instant. Il semble exister un marché pour les outils vérifiant si un pdf respecte les normes d’accessibilité mais rien pour le domaine éditique pur. On doit se contenter d’un outil qui prend un fichier xml en entrée, lance la génération de pdf et compare avec un document cible. Cela permet juste d’évacuer la plupart des régressions.

Si l’on parvient à lire le contenu d’un pdf en Java (peut-être avec iText), il est théoriquement possible de coder certaines de ces règles, mais cela reste complexe.

 Avez-vous des expériences similaires ou de idées à me soumettre ?

Blog Coaching, Scrum, Testing