Scrum-In-Depth est la première mise à jour importante du cours « Certification ScrumMaster » (CSM), préparé par Ken Schwaber en 2002.

Au travers d’apports théoriques et d’exercices en équipe, l’objectif est de donner aux participants de solides bases sur Scrum et ses principes fondamentaux afin de pouvoir en tirer un profit maximum dans leur environnement de travail quotidien.

Cours animé par Eric Mignot, formateur de notre partenaire Pyxis-Tech.

Inscription via le site: scrum.org

Pour obtenir le maximum de Scrum, il faut bien comprendre comment et pourquoi Scrum fonctionne.
Le cours « Scrum approfondi » explore la mécanique de Scrum et les raisons de son efficacité ainsi que des sujets avancés, comme la gestion des risques et l’optimisation du coût total de possession d’un système, qui exploitent les principes sous-jacents de Scrum.

Comme dans le cours d’origine, nous couvrirons le framework et les rôles de Scrum.
Nous étudierons aussi l’utilisation de Scrum pour maximiser la valeur, la productivité et le coût total d’un logiciel.

Public visé:
Ce cours est destiné en premier lieu à ceux qui sont responsables de la bonne utilisation ou du déploiement de Scrum dans un projet ou une entreprise.

Durée: 2 jours

Lieu: Geneva Business Center (GBC)
Avenue des Morgines, 12 – 1213 Petit-Lancy GE

Tarif: 1′500 €

Examen:
Suite à ce cours, les participants auront la possibilité de passer un examen pour évaluer leurs connaissances et ainsi commencer à dresser la “carte radar” de leur savoir-faire. L’examen est optionnel mais fortement recommandé pour continuer l’apprentissage de Scrum au-delà de la durée du cours. Les participants qui réussissent l’examen reçoivent un document de certification.

Lors de l’édition de cette année des ex-XP Days désormais nommés “Conférence Agile France“, qui auront lieu les 31 mai et 1er juin 2010, notre collègue Michel Baldellon décrira ce qu’est le Lean Office, ce que cela peut apporter, comment l’appliquer etc… Tout ceci exemples et anecdotes à l’appui car Michel conseille plusieurs grandes entreprises à ce sujet. Intéressés? C’est ici que vous pourrez vous inscrire.

]]> http://social.hortis.ch/2010/05/06/hortis-intervient-sur-le-lean-office-a-la-conference-agile-france-ex-xp-day/feed/ 0 http://social.hortis.ch/2010/03/16/xpday-geneve-le-29-mars-2010-pas-encore-inscrits/ http://social.hortis.ch/2010/03/16/xpday-geneve-le-29-mars-2010-pas-encore-inscrits/#comments Tue, 16 Mar 2010 10:16:32 +0000 Jérôme LAYAT http://social.hortis.ch/?p=1248 Forte du succès de l’édition de l’an passé, l’équipe organisatrice de l’XPDay Genève réitère l’expérience et Hortis est fière d’être de la partie en tant que sponsor. Le programme est disponible ici et vous pouvez vous inscrire via cette page.

Je pense que nous pouvons dire que le temps où les évènements de ce type sur l’agilité ne se déroulaient que dans les grandes capitales est révolu. Désormais, les méthodes agiles suscitent assez d’intérêt pour fédérer les équipes locales de développements et de gestions de projets. Nous aimons croire qu’Hortis y est aussi pour quelque chose en faisant la promotion de ces méthodes dans la région depuis 2005

J’ai 140 charactères (ah non là c’est plus ) pour vous dire que

• l’Agile Tour 2009 Genève (le 12 octobre) a été une belle réussite. Des présentations de qualité, avec un public intéressé . Sans l’élitisme qui commence à être habituel dans ce genre de confs…
• Les slides sont dispos ici (honneur aux hortisiens dont je donne les URLs en 1er) :
  Remboursez votre dette technique
  Specs et Planning dans un monde Agile
  L’art de la rétrospective
  
  tous les slides : http://www.slideshare.net/AgiletourGeneve

L’Agile Tour poursuit sa route ! Vérifiez si elle ne passe près de chez vous http://www.agiletour.org/ …

L’édition européenne 2009 de la CITCON a eu lieu les vendredi 18 et samedi 19 Septembre à Paris, j’ai eu la chance de pouvoir y assister et je vous livre aujourd’hui mon compte-rendu.

Vendredi après midi, arrivée dans les locaux de l’ISEP, Paul Julius et Jeffrey Fredrick nous accueille avec un mot de bienvenue et des explications sur le fonctionnement d’une conférence Open Space, puis un tour de table pour une présentation rapide des personnes présentes: environ 120 ! Un peu longuet, mais cela me permet de mettre enfin des visages sur les différents blogueurs et twitters que je suis régulièrement.

Arrive les choses sérieuses: la préparation du programme de lendemain, en effet dans le cadre d’une conférence Open Space, tous les participants sont acteurs: chaque personne souhaitant animer une session s’arme d’un stylo, d’un post-it, présente son sujet en quelques mots et l’ajoute au tableau blanc. Libre à chacun de voter, regrouper les propositions équivalentes, modifier le planning.

Et voici le résultat

Nous avons bien travaillé, il est maintenant l’heure de manger et de partager une bière en parlant d’intégration continue, de testing et de nos différentes expériences.

~~~~~~~~

Tout bon Samedi commence par un bon petit déjeuner, la CITCON ne déroge pas à cette règle et nous commençons donc la journée par des discussions informelles autour d’une montagne de croissants. Le choix des sessions n’est pas évident, il y en a 5 programmées à la fois !

A 10 heures, je commence donc la matinée par la session “Better builds“, intéressante mais qui se focalise uniquement sur Ant, du besoin de refactoring des scripts, de l’utilisation des macros et une présentation de Ant Script Library, qui comme son nom l’indique est une bibliothèaue de scipts génériques permettant de gérer les dépendances (avec Ivy), compiler, packager, lancer des tests unitaires ou d’intégration, faire du reporting, … bref tout ce qu’offre nativement Maven ! J’ai toujours du mal à comprendre pourquoi certaines personnes s’obstinent avec Ant pour cette utilisation … J’applique donc “the Law ot two feet” : je change donc de session discrètement et je rejoins “Hudson plugins“.

Lorsque j’arrive Douglas Squirrel a déjà présenté un plugin qu’il a développé et la discussion continue donc sur les points forts et faibles de la création de plugins. Du côté négatif l’utilisation particulière de jelly pour la création des vues, le wiki dont certaines pages ne sont pas mise à jour, du côté positif, kohsuke kawagushi et la communauté qui sont très actifs et l’utilisation de Maven qui permet de démarrer et déboguer un plugin extrêmement simplement via les commandes mvn hpi:create et mvn hpi:run. Nous avons ensuite évoqué les plugins existants qui pourraient être améliorés (Promoted builds par exemple) et de nouvelles idées: graph de dépendance entre builds, distribution des tests unitaires avec GridGain …

~~~~~~~~

11h15, 2ème session de la matinée (enfin 2ème et demi pour moi): “Continuous Deployment” animée par Chris Read. Tout d’abord qu’est ce que le déploiement continu ? L’idée est que chaque fois que du code est committé, il est automatiquement déployé en production ! Impossible ? Regardez donc le bas de cette page chez Flickr: http://code.flickr.com/, la dernière fois que j’y suis allé, on pouvait lire : ”Flickr was last deployed 25 hours ago, including 3 changes by 1 person. In the last week there were 46 deploys of 967 changes by 17 people.” Évidemment les contraintes pour faire du déploiement continu sont énormes, il faut être capable d’automatiser toute les étapes du commit du code jusqu’au déploiement en production: compilation, packaging, tests unitaires, d’intégration, d’acceptance, de performance et évidemment le retour à une version précédente en cas d’erreur.

Nous sommes d’ores et déjà capable de le faire avec les outils d’intégration continue, mais pour le faire de façon plus optimale, Chris introduit la notion de build pipeline c’est-à-dire le découpage en étape du processus de déploiement. Malheureusement cela sert également de support pour une promotion commerciale de Cruise, outil d’intégration continue de ThoughtWorks qui supporte nativement les pipelines … Malgré tout la discussion reste intéressante car le concept de déploiement continu permet d’avoir une vision plus globale du développement d’une application: on ne construit plus seulement un logiciel mais un environnement complet car les contraintes de la production (OS, patch, …) sont pris en compte dès le début du processus. nous dépassons alors le concept cher à XP de “Collective Code Ownership” pour arriver au “Collective Environment Ownership”.

~~~~~~~~

La pause repas est l’occasion de discuter, notamment avec Remy Sanlanville, qui présentera avec Freddy Mallet de SonarSource la session “Pour passer la crise, remboursez votre dette technique !” à l’occasion de l’agile tour 2009 à Grenoble le 20 Octobre prochain et très probablement à Genève le 12 Octobre

~~~~~~~~

14 heures, je commence l’après-midi par la session “Acceptance Testing” animée par Gojko Adzic et Antony Marcano. L’objectif de la session est de faire le top 5 (ou plus) des raisons pour lesquelles une équipe échoue à mettre en place des tests d’acceptance et de donner des pistes pour ne pas tomber dans ces travers. Lors de l’écriture de son livre “Bridging the Communication Gap, Specification by Example and Agile Acceptance Testing“, Gojko avait identifié 5 principales raisons:

• No collaboration
• Focusing on “how” not on “what”
• Tests unusable as live documentation
• Expecting acceptance tests to be a full regression suite
• Focusing on tool

• Acceptance testing is not considered as “value-adding” activity
• “test code” is not maintained with love
• Objectives of team members not aligned
• No management buy-in
• Underestimating the skill required to do this well

Alors que faire pour ne pas tomber dans le panneau:

1. Les tests d’acceptance s’écrivent en équipe: vous et votre client, ce sont des spécifications !
2. L’important n’est pas “comment” faire mais “quoi” faire et ce n’est pas si évident.
3. Vos tests d’acceptance doivent être expressifs et exhaustifs car ils seront alors la vraie documentation du projet, n’oubliez pas ce sont les spécifications !
4. Ces tests ne sont pas des tests de régression, il y a d’autres outils pour cela, ce sont des spécifications !
5. Ne venez pas voir votre client avec un outil, Fitnesse est très bien, mais vous venez écrire des spécifications ! Un tableau blanc et des crayons sont bien plus appropriés, vous aurez tout le temps de traduire ces spécifications dans votre outil préféré après.
6. L’écriture des tests d’acceptance est considérée souvent comme secondaire alors que nous parlons des spécifications !
7. Le code des tests est considérés comme moins important que le code métier, pourtant si vous n’êtes pas capable de valider votre code au regard des spécifications …
8. L’objectif des différents membres de l’équipe doit être le même: délivrer la meilleure application possible pour le client et pas le développeur code et pas plus, le testeur teste et pas plus, …
9. Le management doit percevoir les tests différemment car ce sont les spécifications !
10. Ne sous estimez pas le niveau requis pour écrire ces tests d’acceptance !

~~~~~~~~

15h15, un sujet qui m’intéresse au plus haut point: “CI in the Cloud” car j’avais commencé à écrire un plugin Hudson pour démarrer des esclaves sur EC2, le cloud d’Amazon. Malheureusement pour moi, un certain kohsuke l’a développé bien plus vite que moi (voir ici) ! Mais revenons au sujet, pourquoi les différents outils d’intégration continue lorgne du côté du cloud computing ? Les raisons sont multiples et nous les énumérons:

• réduire les coûts d’infrastructure et de maintenance
• optimiser le coût d’utilisation par CPU (chez Amazon, la tarification se fait sur le uptime)
• absorber facilement les pics de charge.

• le gros point noir: la sécurité, bien que des solutions existent (on peut monter un VPN avec des serveurs chez Amazon), peu de sociétés sont actuellement prêtes à voir leur code source partir en dehors de leur infrastructure propre.
• la confiance envers le fournisseur du cloud.  Le touilleur a d’ailleurs posé une question pertinente: “à qui faites vous le plus confiance: votre équipe d’admin système ou celle d’Amazon ?”. Personnellement je connais la réponse !
• les problèmes réseaux peuvent rendre le système quasi inopérant
• la maintenance de système complexe sera aussi difficile

~~~~~~~~

Rendez-vous pour la prochaine édition dans l’une de ces villes: Zürich, Copenhage, Belgrade, Dublin ou Prague. Je vote Dublin !

Nous sommes quelques hortissiens à avoir eu la chance d’assister à cette conférence au mois de mai (mieux vaut tard que jamais). Les sessions étant dans l’ensemble de très bonne qualité, nous avons dû faire un choix. Voici donc celles qui nous ont particulièrement impressionnés: le compte-rendu

bonne lecture

Bonnes sessions de planning!

Alchimiste-Agile.com > “Le Mardi-Gras”

Encore merci pour votre présence et votre feedback !

Rendez-vous aux prochains XP Day Paris 2009 ;o)

Bonne journée

j.