9h15 : Présentation et introduction de l’Open Space Technology
Eric Lefevre présente pour la seconde année, les concepts de l’Open Space Technology. Pour faire simple, c’est un moyen de partager autour de sujets définis et votés par tous les participants. Cet Open Space est le plus grand organisé jusqu’à aujourd’hui en France.
Il s’en est suivi un défilé de personne qui annonçait leur sujet au micro pour ensuite le déposer sous forme de post-it sur le mur. Après un vote chaotique, la journée a pu réellement commencé …

10h45 : Session Coding Dojo Randory
J’ai commencé par me rendre à une session de Coding Dojo qui diffère de celle présentée hier dans le fait que les personnes qui sont devant le clavier tournent toutes les 5 minutes. Tout le monde peut donc participer. Le sujet était de réfactorer du code legacy pour le rendre plus lisible. L’exercice fut soldé par un échec du aux divergences de “philosophie” des intervenants. J’ai été horrifié surpris que certaines personnes proposent de mettre des commentaires pour rendre plus lisible des noms de variables incompréhensibles … (et je ne parle pas de la valeur de certains tests)
Vous pourrez trouver sur ce lien les notes prises au fur et à mesure de la session.
Nous pouvons retenir que pour réfactorer du Code Legacy, il faut :

• Bien lire le code avant d’écrire une seule ligne !
• Écrire des tests pour faire la recette
• Réfactorer par les tests (= Filet de sécurité)

Après, j’ai fait un peu le “papillon” et j’ai échangé avec des connaissances de Valtech. J’ai pu voir/discuter sur :

Traçabilité des exigences
Je suis resté quelques instants dans cette session et j’en ai retenu :

• Qu’il y a souvent un problème de glossaire entre les développeurs et les clients, il est donc nécessaire d’écrire un glossaire
• Qu’il est intéressant de mettre en place le TDR et d’avoir des spécifications éxecutables

J’ai installé Fit & Fitnesse dans mon projet actuel, mais malheureusement, la partie fonctionnelle de l’équipe n’a pas voulu s’y faire Il faut que je trouve la présentation de GreenPepper faite aux Xp Days car d’après les échos elle est intéressante et donnes de bons “arguments” pour intéresser les “clients”.

Cloud computing
Cette session a eu lieu la veille mais a été élu pour être rejouer cette journée. Les concepts autour du PaaS et IaaS sont maintenant plus claires pour moi et l’idée d’héberger une spreadsheet Scrum sur Google Docs me plait beaucoup, affaire à suivre

Planning Poker
Petite discussion en début d’après midi autour du planning poker, j’ai même pu récupérer un jeu (Merci à Laurent Bossavit ). Je vais tenté l’expérience au prochain scrum planning

Briques de développements .NET
On peut dire que .NET n’est pas très représenté aux Valtech Days, que ce soit dans les sessions ou les participants. J’ai quand même pu discuter autour d’une petite table dans le hall des briques .net. La question de départ était simple : “Qu’est-ce que vous installez sur votre machine pour réaliser vos développements .NET ?” Nous avons donc lister une multitude d’outils et de frameworks. La liste devrait normalement apparaître sur le wiki Valtech !

Discussion autour de Scrum, l’intégration continue, …
Toujours dans le hall, j’ai pu échangé autour de mes expériences autour de Scrum avec mon ancien chef, avec une démo de Google Docs pour gérer le sprint backlog, c’est tellement plus souple que RallyDev … il faut que je teste sur mon prochain projet !

Ensuite, je me suis fait convaincre de tester Hudson (intégration continue) sur un projet .NET, chose que j’ai faite aujourd’hui mais j’en parlerai dans un autre article.

Programmation Post-Moderne
Alors, je suis arrivé au milieu de cette session et je dois avouer que je n’ai pas tout saisi mais le sujet a éveillé ma curiosité, si comme moi, rien que le nom vous titille, google remonte quelques liens intéressants

La journée arrivant à sa fin, une rétrospective a été faite pour faire un constat des deux journées et trouver des axes d’amélioration. Les Valtech days se terminant sur une conclusion et un ensemble de remerciements des différents acteurs de ces deux jours. Une soirée était proposée mais je ne m’y suis pas rendu faute de fatigue.

Normalement les slides et les vidéos seront disponibles début novembre sur le site des Valtech Days.

Pour ma part, j’ai trouvé ces deux journées enrichissantes et je serai présent l’année prochaine

Il fallait donc faire son choix parmi 4 sessions en parallèle, voici le parcours que j’ai réalisé avec un petit résumé/avis :

9h00 : Introduction annonçant que les sessions seront filmés et disponible début novembre en ligne, on pourra donc suivre ce que l’on a raté. C’est une bonne chose
Cette introduction fut suivi par une Keynote par Jeff McKenna de chez Serena, qui est un vieux de la vieille en agile. Il a participé à de nombreux projets agiles et nous a rapidement décrit son expérience et sur le fait que l’agilité est de plus en plus mise en place.
Il a également fait une analogie entre la conduite automobile et l’adaptabilité aux changements que je vais me faire un plaisir de réutiliser

10h00 : Rétrospectives
Une session animée de concert par deux personnes qui décrivait en parallèle les rétrospectives d’itération et les rétrospectives de projets, en énumérant les points communs comme les différences.
J’ai récupéré quelques exercices à mettre en place à la fin de mes itérations, sachant que, comme noté dans la présentation, les rétrospectives sont une habitude à prendre et que chaque intervenant doit en respecter les règles.

11h15 : Coding Dojo TDD en ruby
Cette session a mis en application une pratique que je ne connaissais pas : le CodingDojo. Cela consiste à réaliser en “temps réel” un exercice simple de programmation dans un temps imparti. Ici, ils ont mis en place un algo pour vérifier des propositions de Mastermind, le tout piloté en TDD en ruby et aidé via Autotest
C’est un exercice sympathique et je vais voir pour me rendre un soir à l’une de leur réunion !

14h30 : Lean Software Development
Cette présentation était simplement une définition de Lean et les concepts à mettre en place dans le développement de logiciel. Faut vraiment que je prenne le temps de lire le livre …

15h30 : Êtes-vous prêt pour la production ?
Alors ici, un sujet très intéressant pour moi car mon projet au forfait va “bientôt” passer en production chez le client et comment dire … grâce à la présentation, je me pose plein de bonnes questions !
Julien Delhomme a souligné des faits que l’on connait malheureusement :

• Les développeurs ne se soucient pas de la mise en production
• Très peu de communication entre les développeurs qui ont la connaissance du logiciel et l’équipe de production qui a la connaissance de l’infrastructure
• Agile met en avant le fait qu’il faut livrer fréquemment, mais ne dis pas vraiment comment …
• etc.

16h45 : Faciliter l’adoption de l’agilité
Présentation rapide de la mise en place de l’agilité dans une équipe/entreprise et introduction du livre blanc sur l’agilité rédigé par les équipes Valtech.
Il faudra que je récupère ces slides, je pense que ça va me servir pour certaines missions ^^

17h00 : Qu’avez-vous testé aujourd’hui ?
Une autre présentation rapide de 15 minutes sur l’évolution des concepts autour des tests :

Valeurs modernes

• Tester pour spécifier
• Tester en permanence
• Partager la responsabilité des tests

17h15 : Hudson
Dernière présentation de 15 minutes de cette session qui a tenté de présenter l’outil d’intégration continue Hudson… euh rien à dire, présentation bof

17h45 : Useability : Not just a pretty interface
Pour terminer la journée, j’ai assisté à cette session qui mettait en avant les différences de représentation/conception entre l’utilisateur avec sa vision de l’interface (IHM, ergonomie) et sa mise en application dans le logiciel. Certaines pratiques ont été décrite pour tenter d’améliorer ce souci.
Seule session en anglais que j’ai suivi de la journée, j’espère que j’ai bien tout compris :p

Conclusion
Ce fut une journée intéressante, qui m’a permis de (re)voir certains sujets et donner envie d’en approfondir d’autres. Mais surtout j’ai pu revoir certaines personnes !
Vivement demain pour l’Open Space Technology

J’ai amélioré ma macro pour lancer les tests unitaires via TestDriven.net

L’ancienne version contenait en dur le nom de la solution et du projet contenant les tests, ce qui n’est pas très optimal quand on a plusieurs projets en parallèle. Cette nouvelle version lance les tests sur le premier projet contenant le mot “Test” dans son nom, voici son code :

Bons tests !

Quels sont les avantages d’utiliser Twitter :

• Messages plus fréquents : étant légèrement overbooké, je n’accorde pas de temps à la rédaction d’article pour mon blog, la rédaction d’un message limité à 140 caractères dans twitter est beaucoup plus rapide
• De l’info rapide : Je ne suis pas partisan des billets “liens du jour”, par contre je trouve que twitter convient parfaitement pour communiquer un lien que je trouve intéressant
• Partage d’info : twitter permet facilement de communiquer et d’échanger des infos entre utilisateurs, de suivre certaines personnes pour avoir les dernières news ou scoop

Donc si vous souhaitez me suivre via twitter, voici le lien : http://twitter.com/mpli

J’ai également rajouter un widget sur le blog reprenant mes derniers messages.

A tout de suite sur twitter

Mais je dois avouer que j’étais fatigué de :

1. saisir la souris pour faire un clic droit “Run Test(s)” dans mon code
2. avant chaque archivage de modification, prendre la souris, trouver le projet de test dans la solution, faire un clic droit et “Run Test(s)” pour lancer tous les tests unitaires…

Après quelques petites recherches, on peut facilement résoudre le premier point en assignant une combinaison de touche à la commande “TestDriven.NET.RunTests” qui s’occupe de lancer le(s) test(s) suivant ou on se trouve.

Pour résoudre le second point, j’ai du faire une macro qui sélectionne le bon projet dans la solution et éxécute la commande magique dessus.

Voici donc la macro qui m’épargne des mouvements inutiles :

Il suffit de modifier “NomSolution\NomProjet” avec les bonnes informations et d’assigner la macro à un raccourci clavier (ou au pire de la placer dans la barre d’outils pour gagner quelques clics).

Si vous avez d’autres astuces pour améliorer la productivité, je suis preneur

Voici mes pré-requis pour un environnement de travail agréable :

1. Deux écrans : Je pense que le gain de productivité n’est plus à démontrer, par exemple : Visual studio d’un coté, le browser de l’autre, fini les alt-tab dans tous les sens après une compilation ou une modification de css …

2. Un clavier et une souris correcte : Ce sont les deux périphériques que nous utilisons le plus toute la journée, donc la vieille souris à boule qu’il faut nettoyer régulièrement et le clavier au toucher et bruit désagréable, non merci … mais contrairement aux deux écrans qui sont fourni par la société après quelques arguments, j’ai remarqué que pour être satisfait de son clavier et de sa souris, il vaut mieux se les acheter soi-même

3. Un bureau assez grand : Qu’est-ce que c’est désagréable de devoir pousser ses affaires à chaque tâche … le minimum syndical est de pouvoir poser le café et la doc/cahier des charges en dehors de l’espace clavier/souris.

4. Une bonne chaise : Je pense qu’il n’y a pas d’arguments à donner, on est assis dessus toute la journée, mais c’est assez dur de trouver de bonnes chaises, il faudrait que je teste un jour les fauteuils Aeron qui sont souvent vantés outre-Atlantique

5. Un pc performant : Et oui, contrairement à l’utilisateur, nous ne lançons pas que l’application mais aussi l’IDE (Visual Studio 2008 dans mon cas), le serveur SQL, différents outils assez gourmand, etc … donc il faut contredire l’argument de certains “chefs” qui donnent une machine aux capacités limitées avec comme excuse d’être dans la même configuration que l’utilisateur pour optimiser notre développement…

6. Internet “rapide” et sans bridage débile (MSN etc …) : Personnellement, en tant que développeur, je passe un certain temps sur le net, pour vérifier que si ce que je cherche n’a pas déjà été fait, faire un peu de veille techno (même si il faut éviter de faire ca au boulot), consulter de la documentation, etc… et MSN est très pratique pour passer un bout de code au développeur d’à coté …

7. Environnement calme : Nous faisons un “travail cérébral”, donc nous n’avons pas besoin d’avoir les commerciaux, la hotline ou ce #ù*^! de téléphone qui sonne toute la journée. Surtout si les casques audio ne sont pas autorisés … :’(

Je ne pense pas que mes demandes soient exagérées et j’ai la chance d’avoir la plupart de ces points dans ma compagnie actuelle.

Et vous, quelles sont vos pré-requis pour un bon environnement de travail ?

On verra par rapport à mes bonnes résolutions 2008.

Dans tous les cas, bonnes fêtes !!

• 08h30 - 09h30 Accueil Petit Déjeuner
• 09h30 - 10h20
  • UML est-il soluble dans les méthodes agiles?
  • Développement RIA avec Adobe Flex
  • Achieving Success in e-Commerce
  • Test Driven Requirements: Introduction et perspectives
• 10h35 - 11h25
  • Agile & Offshore : Rétrospective d’un projet à 1 million d’euros
  • Comment maintenir la qualité de service de vos applications JEE?
  • Think Service : Comment aborder SOA dans son système d’information
  • Le Refactoring : la solution agile pour conserver un code évolutif
• 11h25 - 11h50 Pause café
• 11h50 - 12h40
  • Rally Case Study: Integrated Agile Lifecycle Management for Heterogeneous Tooling Environments
  • Simplifiez vos développements JEE avec JBoss Seam
  • XForms: nouveaux concepts pour repenser une interface dans un contexte Web 2.0
  • Agilité: à monter soi-même…
• 12h40 - 14h20 Pause Déjeuner
• 14h20 - 15h10
  • Agile & Offshore : Techniques de survie dans le milieu bancaire
  • Web 8.3 ou l’avenir du web
  • Industrialiser vos développements avec Team System
  • From “Fragile to Agile”
• 15h25 - 16h15
  • Contractualisation des projets agiles
  • Intégrer les APIs Google Maps dans une application WinForm .NET
  • Spring, le framework à «tout» faire?
  • De la différence entre «2 personnes devant un PC» et «binômage»
• 16h15 - 16h40 Pause café
• 16h40 - 17h30
• Valtech Cockpit, une plateforme intégrée pour projets distribués
• Le wiki de deuxième génération: une alternative pour développer des applications webs
• Language Oriented Programming: Using DSLs as a new Agile abstraction and modeling mechanism
• LEIRIOS Smart Testing™, Clé de voûte de l’Usine à Tests

Pour la deuxième journée, c’est Open Space Technology, ca sera une première pour moi

J’espère que la conférence sera mieux organisée que les TechDays de l’an dernier, ou il fallait courrir si on souhaitait avoir la chance d’avoir une place dans les sessions désirées.

Ce livre de 120 pages au format compact, est très pratique à lire dans le métro, il décrit rapidement les points essentiels de la gestion de projet ainsi que les erreurs fréquentes. Il s’adresse surtout aux futurs chefs de projet mais pourra également servir à rafraichir la mémoire aux personnes déjà initiées à l’art de la conduite de projet.

Je vous renvoie sur le site de l’éditeur pour découvrir le sommaire de l’ouvrage, mais pour résumer, le livre décrit :

• La nature d’un projet
• La qualité nécessaire à la réussite d’un projet
• Le déroulement d’un projet
• Les erreurs fréquentes à ne pas commettre

Ce livre n’explique pas une méthode pas à pas pour réussir les projets mais sensibilise plus sur le rôle et les actions que doit connaitre un chef de projet, de toute manière, il n’y a pas de méthode miracle qui permet de réussir à coup sûr un projet, ou tout le monde l’appliquerait

J’ai apprécié la lecture de ce livre, qui m’a permis d’éclaircir certains points. J’ai bien aimé son passage sur les méthodes agiles qu’il confronte à la réalité ainsi que certains passages qui m’ont rappelé des cas vécus.
Je pense que c’est un livre concis à petit prix qui se lit rapidement et que je conseille à toutes personnes intéressées par le sujet.

Rating: 3.5 out of 5 stars

Ps : En bonus, il fournit des documents type à télécharger sur le site d’Eyrolles

Faut bien passer le temps le week end ….

via Christophe Lauer