Vidéo de retours sur le ScrumDay 2011

Le FrenchSUG (French Scrum User Group = Groupe des Utilisateurs Français de Scrum) a mis en ligne une vidéo de compilation de retours sur le Scrum Day qui a eu lieu le 31 mars dernier.

La vidéo et le montage sont sympas et dynamiques, mais au delà de la forme, les retours collectés me semblent très significatifs de la situation de l'agilité actuellement, avec un gros engouement, un intérêt montant avec une popularité grandissante, mais également une mise en garde et donc une prise de conscience intéressante sur la dualité suivante : la simplicité de l'approche et la difficulté de sa mise en oeuvre au quotidien, "tout n'est pas si simple, mais ça vaut le coup", d'où la nécessité de se renseigner, se préparer et se faire accompagner !

La vidéo est là : http://www.facebook.com/video/video.php?v=10150198547436366

[Agilité] Estimation relatives des histoires

Je viens de lire l'article "90 stories en 45 minutes" publié par Benoit Gantaume, et ça me rappelle un atelier que j'avais animé, j'en profite donc pour partager cette expérience ...

Tout comme Benoit, le besoin était d'estimer une bonne quantité d'histoires, pour dégrossir les estimations et se donner une idée globale d'effort à fournir. Je m'étais inspiré de lectures ici et là pour proposer à l'équipe un atelier d'estimations relatives en mélangeant différentes idées, avec une grosse influence du Story Mapping.

Déroulement

L'atelier s'est déroulé en présence du Product Owner, de 3 équipiers (développeurs) et moi en tant que ScrumMaster. Nous nous sommes installés dans une salle tranquille en alignant 2 tables rectangulaires de façon à pouvoir circuler autour. Nous avons préparé un post-it pour chaque histoire.

Pour débuter, nous avons chercher très rapidement l'histoire qui nous semblait la plus petite (en terme d'effort à fournir, je ne parle ici que de cela) et nous l'avons positionné sur la gauche.

Ensuite, nous avons pris les histoires 1 par 1 et les avons positionné sur la table, à gauche ou à droite les unes des autres selon leurs efforts relatifs. Pour des efforts identiques, nous avons placé les histoires les unes en dessous des autres. Les histoires trop floues et ne pouvant pas être estimées ont été placées dans un coin identifié de la table.

Constats

Les histoires ont été rapidement placées les unes après les autres, quitte à décaler certains "paquets" pour en insérer certaines. Très vite, certaines histoires ont été placées très loin sur la droite, instinctivement pour un effort conséquent mais flou. D'ailleurs, une 3ième table a due être ajoutée ... Ces histoires ne peuvent donc pas être sélectionnées pour un backlog de sprint sans être re-découpées.

Nous avons également placé 1 ou 2 histoires à gauche de celle initialement estimée comme étant la plus petite, comme quoi ça n'était pas le cas, mais ça n'a absolument pas gêné le déroulement de l'atelier, l'essentiel étant d'avoir un point de départ de faible poids (effort).

Il était intéressant de constater que certaines histoires ont été déplacées plusieurs fois, dans un sens ou dans l'autre, surtout en fonction des questions posées au Product Owner pour mieux comprendre les besoins, les questions pour une histoire venant parfois lors du placement d'une autre histoire. En effet, le positionnement proche entre 2 histoires faisait parfois émerger des questions sur l'une ou l'autre pour bien évaluer les différences.

Tout comme Benoit, nous avons consigné au fur et à mesure les précisions données par le Product Owner, mais également des éléments de solutions techniques émergeant des discussions entre développeurs. Ce point est souvent négligé. Je l'ai souvent constaté, ces moments d'échanges amènent naturellement l'équipe vers un début de réflexions techniques et il est souvent dommage de perdre ces informations qui feront gagner du temps par la suite ...

Une fois toute les histoires en place, nous les avons passé en revue 1 par 1, de gauche à droite, pour vérifier leurs positionnement relatifs. Ensuite nous avons mis des chiffres, en partant de 1, et tout comme dans l'atelier de Benoit, naturellement, les écarts se sont creusés pour être proche de la suite de Fibonacci ( 1, 2, 3, 5, 8, 13, ... ?).

Bilan

En très peu de temps, nous avons pu estimer une bonne quantité d'histoires, avec un résultat recevant un bon indice de confiance de toute l'équipe ("Give me five") et permettant d'avoir une certaine visibilité sur le projet.

Les plus :

• rapidité
• aspect ludique
• participation collaborative de tous, naturelle et immédiate
• échanges riches et constructifs

A améliorer :

• mise en évidence des valeurs métiers de chaque histoire : nous n'avions rien mis en place pour cela, le Product Owner connaissant très bien son backlog et le ROI de chaque histoire, mais l'idée de Benoit (bandes de couleurs) est intéressante
• ... certainement plein d'autres choses dont je ne me souviens plus à ce jour ... ;-)

Git et les branches : super pratique !

Introduction

Pour un projet d'application WEB, j'avais besoin d'utiliser un éditeur HTML en ligne WYSIWYG en lieu et place d'un TextArea :

Après une petite recherche sur internet, j'ai trouvé 4-5 librairies et j'en ai retenu 3 d'après les premières informations collectées (licence, rendu, intégration, ...). Restait alors à les tester pour vérifier l'intégration technique dans mon application et les résultats visuels dans mes pages.

La solution est venue immédiatement : faire des branches avec Git, surtout que j'avais déjà mis mon projet sous Git !

Déroulement

Voilà en résumé l'enchainement des opérations réalisées ...

Je vérifie mes branches actuelles :

$ git branch
* master

Aucune branche, donc j'en crée une pour tester la librairie "truc" et je bascule dessus :

$ git branch html_editor_truc
$ git checkout html_editor_truc
Switched to branch 'html_editor_truc'

J'installe la librairie, je modifie mon application, je mets au point, et je vérifie le résultat (rendu et utilisabilité de l'éditeur HTML). Une fois que j'ai pu évaluer la librairie "truc", je peux ajouter les nouveaux fichiers à Git et je commit :

$ git add libs/
...
$ git commit -a -m "Essaie avec l'editeur HTML truc"
...

Je reviens à ma branche principale :

$ git checkout master
Switched to branch 'master'

Et je vérifie l'état courant :

$ git status
# On branch master
nothing to commit (working directory clean)

Rien ... bon ...
Je regarde dans mon arborescence de fichiers et le répertoire que j'avais ajouté avec la librairie "truc" a disparu : magique !

Je refais les mêmes opérations pour la librairie "toto". Le résultat est moins satisfaisant, au final, je préfère la librairie "truc" : mon choix est fait ! En étant sur la branche "master", je commence par supprimer la branche pour les tests avec la librairie "toto", je n'en ai plus besoin (mais je pourrais la garder) :

$ git branch -D html_editor_toto
Deleted branch html_editor_toto (was fa84cec).

Ensuite, je demande la fusion avec la branche d'essai de la librairie "truc" :

$ git merge html_editor_truc
Updating 77cd7dc..7c0a0f6
Fast-forward
...
 21 files changed, 19 insertions(+), 2 deletions(-)

Et voilà ! La librairie précédemment testée est intégrée à la branche principal.

Play! framework

J'en ai déjà parlé, et l'article est toujours en prévision : pour ce projet, j'utilise Play! Framework,un framework de développement WEB écrit en Java : on écrit les contrôleurs et les beans de données en Java, et les template de vue en Groovy. Ce framework est très simple d'utilisation, et extrêmement productif, notamment par sa compilation en ligne : pas besoin de recompiler ou de relancer le serveur à chaque modifications, un simple rafraichissement dans la page WEB suffit pour voir les modifications apportées aussi bien dans le modèle de données, dans les contrôleurs ou dans les vues.

Donc, en utilisant Git et les branches, il suffit de basculer d'une branche à l'autre, et là encore, un simple rafraichissement de la page suffit à nous remettre dans le contexte de la branche choisie.

Dans mon cas, ça m'a permis de tester les différentes librairies pour mon éditeur HTML très rapidement. Sans compter la facilité pour comparer chaque solution en basculant de l'une à l'autre par une simple ligne de commande (git checkout ...) !

Seul bémol : j'ai été un peu embêté par la base de donnée H2, de type file, utilisé pour ma version test de mon appli sur mon poste. Par défaut, j'ai initialement ajouté à Git tous les fichiers de Play!, y compris la base de données :

$ git add .

Du coup, à chaque changement de branche, Git me signale un problème car la base a été modifiée. Il suffira donc que je l'enlève de la gestion par Git.

Corrections sur la branche principale

Même si mes tests pour choisir ma librairie ont été rapides, j'ai été interrompue pendant ces tests pour une correction mineure sur la branche principale. Qu'à cela ne tienne, je suis revenu sur cette branche, j'ai fait mes modifications (+tests bien sûr), j'ai commité et livré, et je suis revenu à ma branche de test :

$ git checkout master
Switched to branch 'master'
... // modifications
$ git commit -a -m "..."
... // livraison
$ git checkout html_editor_truc
Switched to branch 'html_editor_truc'

Aucune interférence entre les 2, vraiment super pratique !

Une galère

Durant cette expérimentation, j'ai eu essentiellement une galère. Lors de mes opérations avec Git, il me signalait un problème, assez incompréhensible, sur un dossier d'un plug-in d'une des librairies testées. J'ai longtemps pensé que j'avais raté ou mal fait quelque chose. Je me suis retrouvé bloqué !

Au final, pas de chance, mais en fait, c'est l'archive de la librairie qui contenait, dans ce dossier là, un fichier .gitignore et un dosser .git : Git était perdu, y'avait de quoi ... J'ai signalé le problème aux développeurs de la librairie, bien contents de ce feedback !

Conclusion

J'avais pas mal entendu parler de Git, et notamment pour ses avantages pour les (nombreux) commits "locaux", mais aussi pour sa gestion des branches permettant de travailler sur plusieurs sujets à la fois.

L'idée en utilisant Git est de faire une branche pour chaque modification entamée.

Lorsque j'avais lu cela, avec mon expérience Subversion (et la gestion des branches parfois lourde), j'avais été surpris. Mais l'expérience, même de faible ampleur (pas énormément de modifications sur plusieurs branches à la fois), est vraiment concluante : ces possibilités offerte par Git et sa gestion des branches est vraiment génial !

Et vous ?

Quelle est votre point de vue, expérimenté ou non, sur Git ?
Qu'en pensez-vous ?

Première demande de "pull" sous Github

A y est !! Enfin ! ....

Il y a presque 1 an, pour un développement WEB perso, j'avais récupéré une librairie Javascript sur Github. J'avais d'ailleurs eu quelques échanges sympa avec le nouveau "propriétaire" de la librairie (officiellement forké d'une version officiellement non maintenue par l'auteur initiale de la librairie).

Pour les besoins de mon appli, j'avais fait une petite modif pour ajouter une petite fonctionnalité sympa à la librairie. J'avais promis à l'auteur de soumettre ma modif, mais ... le temps a passé ... et je ne l'avais jamais fait ...

Maintenant, le projet est réouvert pour quelques temps, et j'en profite pour tenir ma promesse.

J'ai donc "forké" la librairie de référence sur mon compte Github en suivant cette page d'aide simple et claire : github:help : Fork A Repo.

Note : Pour faire des commits, voir plus bas ... ;-)

Ensuite, comme j'ai changé de machine et que je suis (pour l'instant ...) sous Wnidows, j'ai installé Git (msysgit) en suivant ce tutoriel pour débuter avec Git et GitHub sous Windows, simple et efficace, avec un petit rappel de ce qu'est un SCM décentralisé. On peut zapper la fin du tutoriel, les infos seront vus dans un autre tutoriel ...

Attention : chez moi, la génération de la clé dans une console "bash" ne fonctionnait pas, mais j'ai pu l'obtenir avec Git GUI.

Ensuite, pour compléter ma configuration de git et rentrer plus en détails dans les principes de fonctionnement et les commandes, je recommande ce tutoriel vraiment excellent : Gérez vos codes source avec Git !

Attention : pour la création du dépôt local et l'envoi de commits ("push"), se référer plutôt à l'aide Github citée plus haut.

Avec tout ça, j'ai réussit à faire un commit et à la pousser sur mon dépôt Github, donc sur mon fork du projet. Ensuite, en 1 clic dans l'interface de Github, j'ai fait une "Demande de pull" pour demander à l'auteur principal (de référence) d'intégrer mes modifs dans la branche principal de la librairie.

Reste plus qu'à attendre qu'il l'accepte ....

En tout cas, les principes mis en avant par Github sont vraiment très sympas pour les aspects collaborations, et l'apprentissage de git (j'y avais déjà touché) n'est finalement pas si compliqué que cela.

Et toi, lecteur de passage, que penses-tu de Git ? Es-tu plutôt SVN ?

Scrum Day France (Part 3)

"ScrumMasters, devenez le coach de votre équipe agile" par Véronique Messager

(Type : vidéo et diaporama mixés)

En introduction, Véronique évoque une révélation que j'ai eu moi aussi : la réponse que les méthodes agiles apportent lorsqu'on cherche (cherchait) une approche plus "humaine" dans la gestion de projet. J'ai pris conscience de cela au bout de pas mal de temps : l'approche et l'organisation qui m'étaient proposées pendant des années ne me convenaient pas, l'agilité a pointé ce qui manquait : l'aspect humain ...

Véronique rappel quelques points importants avec des variantes ou point de vue qui m'ont intéressé :

• Le ScrumMaster protège l'équipe, de l'extérieur bien sûr, mais également des siens, des membres de l'équipe
• Parmi les valeurs poussées par l'agilité, le droit à l'erreur, pas assez mis en avant
• L'équipe s'engage sur les résultats, le ScrumMaster s'engage sur les moyens (moyens pour l'équipe de tenir ses engagements, notamment moyens techniques)

Comme souvent, la question : le ScrumMaster peut-il être un responsable hiérarchique ?

Véronique précise que c'est un débat, mais n'y répond pas. Personnellement, malgré mon pragmatisme, je suis assez formel : par expérience, il faut absolument éviter que le ScrumMaster soit un responsable hiérarchique. Pour obtenir la concrétisation de valeurs comme Transparence, Confiance, Ouverture, etc ..., pour obtenir l'affichage par les équipiers de leurs faiblesses pour qu'ils expriment leurs difficultés du moment lors de la mêlée quotidienne, il ne faut pas que le ScrumMaster soit hiérarchique !

Autre sujet abordé, pendant la présentation, mais également, pendant les Questions/Réponses : le ScrumMaster est-il un ancien chef de projet. Véronique dit qu'elle constate que c'est souvent le cas. Je pense que c'est possible, il n'y a rien qui s'y oppose, mais ça ne doit pas être systématique : un chef de projet peut très bien devenir (Proxy) Product Owner, notamment s'il a une bonne compétence métier et relationnel avec le client. L'important est que le ScrumMaster soit à l'écoute des équipiers et dans la communication, un chef de projet trop habitué à un rôle directif aura du mal avec cette approche très humaine, en "position basse" comme dit Véronique. J'y reviendrai dans un autre billet ...

Véronique a un point de vue intéressant sur le rôle de ScrumMaster : qu'il adopte une posture de "coach". Je pense que le rôle de "coach agile", comme je peux le faire en indépendant extérieur à l'entreprise, est une mission bien spécifique et différente de ScrumMaster. Mais en écoutant la suite de la présentation, je comprends ce que Véronique veut illustrer à l'auditoire pour lui faire sentir ce rôle de ScrumMaster :

• Faire en sorte que chacun (individu ou l'équipe) trouve lui-même la solution à ses problèmes
• Non pas intervenir sur une problématique mais plutôt sur la façon dont l'équipe appréhende et traite cette problématique

Véronique insiste ensuite sur ce que cet aspect humain implique pour le ScrumMaster :

• Connaissance de soi et contrôle de soi-même
• Connaissance (humaine et non privée) des autres
• Relations entre les personnes
• Prise en compte des émotions de chacun

Selon les situations et les contextes, une "charte" au sein de l'équipe peut-être intéressante comme cadre, notamment en cas de relations difficiles.

Obligé d'accélérer sur la fin de sa présentation, Véronique aborde rapidement des points souvent délaissés, voir inconnus, et pourtant très importants à intégrer pour le ScrumMaster (et finalement tous les acteurs) :

• La notion de deuil qui accompagne souvent les changements nécessaires pour chacun (développeurs, managers, ...), la prise en compte du cycle de deuil, et l'accompagnement au changement nécessaire (coaching)
• La notion de cycle de vie d'une équipe (Création, Turbulence, Harmonisation, Performance, Séparation) impliquant une équipe stable où les acteurs apprennent à travailler ensemble

Dernier point noté qui ouvre le rôle de ScrumMaster : ce dernier intervient à différents niveaux :

• Individu : accompagnement au changement, adaptation individuelle à l'agilité de chacun
• Équipe : permettre la meilleure transformation "de groupe" vers l'agilité
• Organisation : dynamique globale nécessaire, évangélisation dans l'entreprise

Scrum Day France (Part 2)

Retour sur une autre présentation que j'ai visionné

Pratiques avancées des tests avec Nathaniel Richand

(Type : audio sur diaporama sous forme de video)

Nathianel attaque fort avec 2 qestions qui interpellent (tests des messages dans les exceptions et des messages dans les logs), en rappellant qu'il faut rester pragmatique selon le contexte !

Outre le TDD evidemment très intéressant, Nathianel évoque les tests qui vieillisent mal (notamment par la mise en commentaire des vérifications "assert"), et le fait que le TDD peut devenir un frein en augmentant la rigidité du code.

Il propose donc 2 axes pour éviter cela :

• augmenter la lisibilité
• diminuer la fragilité

Pour augmenter la lisibilité :

• choisir des noms explicites pour les méthodes de tests en donnant le contexte et l'intention
• ne pas masquer les informations utiles, qui peuvent par exemple venir de fichiers XML non visibles dans le code de test (cf DBUnit ou Unitils)
• masquer tout ce qui est inutile en utilisant les Setup, les Teardown, les import static, du code "Fluent interface" avec le pattern builder, etc ...
• éviter les "try/catch" avec "fail()" en remontant simplement les potentiels exceptions (throws sur les méthodes de tests) idem pour les "if/else" avec "fail()"
• éviter les messages explicites en début d'assert en utilisant des tests natifs ou des bibliothèques favorisant l'affichage les messages d'erreur (cf FestAssert)
• éviter des nombres et textes dans le code de test, utiliser des constantes, y compris pour des paramètres à null
• garder la même structure pour tous les tests, comme par exemple "Given/when/then" proposé par Nathianel, ou plus perso pour moi, "Préparations/Tests/Vérifications", ce qui a en autre l'avantage de pousser le développeur à ne faire qu'un test par méthode
• soigner ses assertions, notamment en utilisant les bons assert ("assertEquals" plutot que "assertTrue") et les librairies comme Festassert ou armcrest
• utiliser Spock, dont j'ai déjà parlé dans un précédent poste et qu'il va vraiement falloir que je teste !

Remarque "évidente" (...) en passant : si les tests sont compliqués, c'est que potentiellement, le code est ... compliqué ! A méditer ...

Pour rendre les tests plus robustes :

• pas de duplication de code (utiliser des fixtures, des builders, des assertions "maison", ...)
• tester un comportement à un seul endroit
• éviter la réflexion (reflect java pour tester des méthodes privées ..... bahhhhhhhh)

[NDLA] Sur ce point, je n'approuve pas l'idée de changer la portée "private" d'une méthode pour la tester, il y a d'autre solutions, notamment un changement d'architecture pour extraire cette méthode dans une autre classe testée unitairement ... éternet débat ? ...

• adapter ses tests selon que le code est bas niveau (basique) ou haut niveau (interaction entre plusieurs collaborateurs), utiliser des mocks pour vérifier le comportement global de la méthode

Je note l'idées intéressante consistant à ajouter au TDD un étape après l'étape "rouge" pour vérifier les messages d'erreurs et les rendre explicites.

Je recommande moi aussi le livre "Clean code" de Robert C. Martin traduit en Français sous le titre "Coder proprement" dont la première moitié est tout simplement pleine de bon sens !

S'en est suivi une séance de Questions/Réponses sur différents sujets :

• tests sur environnement de prod : plutôt éviter (selon contexte) !
• tests des classes abstraites : Nathianel évoque la possibilité pour le code de test d'hériter du code de test de la classe abstraite

[NDLA] Perso, j'utlise de moins en moins l'héritage et les classes abstraites, et de plus en plus l'aggrégation ;-) donc la question ne se pose plus ...

• alternatives à DBUnit : mocker les DAO, ou sur-couche DBUnit pour éviter les fichiers XML (DBUnit et Unitils n'étant plus maintenus)

Sur l'utilisation de mocks, mon approche est très différente de Nathianel qui dit les utiliser peu. Je développe depuis pas mal de temps de façon très découpée pour respecter le principe "1 classe - 1 role", et beaucoup de base d'interfaces et de collaborateurs. J'utilise donc énormément les mocks pour simuler et maitriser le comportement de chaque collaborateur pour que le test ait tout son sens, et je n'ai jamais rencontré de grandes difficultés lors d'évolutions et refactorings de code, du moins rien à voir avec l'apport d'une telle architecture !

En tout cas, une présentation intéressante, efficace, et que j'approuve entièrement, aux détails près mentionnés précédemment ;-)

2011 nri-pratiques tests-avancees

View more presentations from Nathaniel Richand

Scrum Day France - Les présentations sont en lignes !

Je n'ai malheureusement pas pu me rendre au Scrum Day France le 31 mars dernier. Mais bon nombre des présentations sont en lignes sur le site du French Scrum User Group. Merci au groupe et à Xavier Warzee !

J'avais commencé à regarder quelques présentations dès leurs mises en ligne. Voici quelques retours sur :

• Automatisation des tests : le mythe du ROI avec Gilles Mantel
• Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin
• Le Product Owner « Proxy », Bertrand Dour

Automatisation des tests : le mythe du ROI avec Gilles Mantel

(Type : vidéo et diaporama en parallèle)

En début de présentation, Gilles rappelle les différents types de tests. J'y ai découvert les Tests fonctionnels exploratoires, non automatisables, mais sujet certainement d'avenir.

Ensuite, Gilles présente la formule du ROI (=Coût des tests manuels - coût des tests automatisés) en détaillant le contenu de chaque terme. La courbe présentée ensuite montre, sans surprise, un ROI positif au bout d'un certain nombre de cycles d'exécution, le point de début de rentabilité pouvant être atteint au bout de 2 à 3 ans (période d'investissement au bout de laquelle on ne gagne rien !). Pas motivant ...

Gilles met donc ensuite le doigt sur le fait que dans cette approche très mathématique et financière, on oublie bon nombre d'intérêts des tests automatisés comme par exemple :

• la possibilité de lancer les tests plus souvent, y compris la nuit, sans nécessité de disponibilité de ressources humaines
• des retours (feedbacks) plus rapides
• le coût des anomalies

Gilles détaille ce dernier point avec des graphes très intéressants mettant en évidence que plus une anomalie est découverte tard, plus elle coûte chère, évidemment. Mais un critère supplémentaire très important est la phase à laquelle l'anomalie a été créée : plus une anomalie a été introduite tôt dans le process (par exemple architecture, design, ...), plus elle va coûter chère, le tout étant accentué si elle est découverte tard !

La suite de la présentation reste très théorique en se basant sur le modèle de gain d'une option d'achat. Mais cette approche m'a enfin permis de comprendre pourquoi, en contexte agile, j'ai souvent été moins motivé à mettre en place des tests sur le GUI (par exemple) : tout simplement parce que par expérience, il y avait peu d'anomalies dans cette partie des logiciels, donc un ROI pressenti moins intéressant !

Gilles présente également un graphe très intéressant, de Scott Ambler, qui a fait une projection des pratiques, agiles ou non, sur la courbe de coût d'une anomalie, excellent ! Avec là aussi une mise en évidence d'un ROI, pour l'automatisation des tests, moins intéressant en contexte agile.

Conclusion : commençons par passer à des pratiques agiles, et les tests, ça vaut le coup à bon escient.

Une présentation que j'ai beaucoup apprécié, à voir !

Automatisation des tests: le mythe du ROI

View more presentations from gmantel

Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin

(Type : audio sur diaporama sous forme de video)

Après une introduction sur une première raison d'échec, Alex anime sa présentation sur base du serious game "Buy a feature" (cf Innovation Game), en proposant 12 raisons d'échec de Scrum à acheter par les participants, raisons basées sur des exemples concrets vécus.

Parmi les sessions présentées :

• Une seule personne ! : cas d'une personne malhonnête et méchante, ayant beaucoup de pouvoir
• Casting du PO : une situation où tout semble parfait sauf que le PO n'était pas le bon, plus gestionnaire que visionnaire (pas impliqué), et non maitre des aspects financiers
• Contrat agile : j'en retiens trop de contractualisation, trop d'adaptations de Scrum, trop de difficultés liés aux distances, aux mélanges d'équipes agiles ou pas, ...
• Mission impossible : avec la blague de Ken Schwaber qui conseille à un ami, ayant un projet impossible, d'opter pour ..... la méthode Waterfall ! Scrum mettrait "trop" vite en évidence l'aspect impossible du projet
• Les Geeks : échec d'un projet à cause des geeks, excellent techniquement, qui se font plaisir, mais pas du tout ouvert sur le métier. Personnellement, je me considère comme geek, par l'aspect passion, ou du moins, je me sens proche des geeks. Et je les perçois plus comme une réserve d'énergie et d'innovations. Je ne partage donc pas le point de vue d'Alexandre. Mais je comprends bien la raison d'échec de ce projet, plus dû à des développeurs renfermés sur leur focus technique, sans intérêt pour le métier. Et cela m'amène une question : quel est le rôle du coach agile et/ou du ScrumMaster dans une telle situation, intéressant ...
• Micro management : présence d'un manager hiérarchique trop présent sur l'équipe, avec des pratiques incompatibles avec Scrum (déplacement des post-its, affectation des tâches, suivi du consommé, ...) et donc un ScrumMaster avec un rôle très réduit. Bilan : passivité et désengagement de l'équipe, Scrum devient impossible !
• Multiples PO : présence réelle de plusieurs PO avec une répartition officielle (documentée) des rôles de chacun, rôles très répartis, aboutissant à un auto-blocage dans les décisions

Un rappel important au passage : l'agilité, avant tout, c'est un état d'esprit !

Une présentation intéressante (même si j'ai des différences de points de vue sur les geeks et les ScrumMaster qu'il est bon de faire "ramer"), avec une forme agile à différents points de vue. Évidemment, Scrum, ça fonctionne "presque" tout le temps, et il est intéressant et enrichissant de se repencher sur les raisons d'échec pour les comprendre et les éviter à l'avenir. Ce que j'ai pas mal fait personnellement ces derniers temps.

La conclusion est importante,puisqu'en général, ce n'est pas la méthode qui ne marche pas, mais son application, les limites de l'organisation, et les personnes concernées.

Le Product Owner « Proxy », Bertrand Dour

(Type : audio sur diaporama sous forme de video)

Une présentation rapide suivant d'une longue séance de questions/réponses. Malheureusement, difficile d'entendre toutes les questions, mais les réponses restent intéressantes ...

Bertrand présente le contexte de la mise en place,  chez PMU, pour 3 métiers différents, d'une structure agile sur base de 2 équipes de 4-5 personnes (permet de répondre à 2 thématiques à chaque sprint), travaillant sur 1 seul product backlog multi-activités, avec la présence d'un Product Owner Proxy dont Bertrand rappelle l'intérêt :

• Un interlocuteur unique
• Une gestion des priorités consolidées
• Une planification de release cohérente

Bertrand lisse les problèmes et solutions :

• Expertise métier : mise en place d'implication forte des experts métiers, vocabulaire commun et granularité similaires entre les métiers
• Gestion des priorités : 
• vrais jetons de pocker pour les valeurs métier (Business values)
• augmentation de la transversalité entre métiers : fédération et collaboration
• créations d'événements : démos au PO et aux personnes avec qui le PO est en contact, ateliers (écritures d'histoire, gestion du backlog, ...)

Bertrand dresse ensuite un bilan sur la mise en place de ce Proxy PO, que je complète avec les questions/réponses :

• Avantages : gestion du besoin consolidé et interlocuteur unique, échanges transversaux entre métiers (ouverture)
• Difficultés : connaissance métier (atelier indispensables), légitimité du PO, complexité du processus, Proxy PO avec pouvoir d'arbitrage mais sans pouvoir de décision (obligation de consulter la hiérarchie)

Les questions/réponses ont également permis de couvrir d'autres points plus généralistes sur l'agilité et Scrum : open space, évangélisation de l'agiliité au sein de toute l'entreprise (pas facile, comme souvent), etc ...

Une conclusion intéressante : un PO Proxy ça marche, mais commencer par essayer d'améliorer d'abord l'organisation ...

Le Product Owner proxy, Bertrand Dour

View more presentations from Xavier Warzee

Tests unitaires - Spock : à tester de toute urgence !

Je viens de lire le retour de Nicolas Martignole, alias le Touilleur Express, sur la présentation de Spock par Mathile Lemée à Mix-It :
http://www.touilleur-express.fr/2011/04/06/mix-it-le-framework-spock-par-mathilde-lemee/

Mathilde en a d'ailleurs fait 3 articles sur son blog :

• Spock (1/3) – Spock, JUnit et le Data Driven Testing
• Spock-(2/X) – Spock, EasyMock et Mockito sont sur un bateau
• Spock-(3/X) – Spock, EasyMock, Mockito et les arguments

Je découvre donc ce framework de tests que je ne connaissais pas, à tester de toute urgence pour se faire son propre avis !

Android : premiers contacts (Partie 1)

Enfin un article pour partager mes premiers contacts avec Android...

Rappel avec la définition de Wikipedia :

Android (prononcé androïde) est un système d'exploitation open source pour smartphones, PDA et terminaux mobiles conçu par Android, une startup rachetée par Google, et annoncé officiellement le 5 novembre 2007. D'autres types d'appareils possédant ce système d'exploitation existent, par exemple des téléviseurs et des tablettes.

Passionné par les nouvelles technologies, expert Java, intéressé par les développements mobiles en plein expansion, c'est tout naturellement que je me suis tourné vers Android.

Je me suis donc lancé, il y a quelques temps, avec un projet (que je présenterai plus tard) personnel et ludique, le principal objectif étant l'exploration des développements mobiles et notamment Android.

Travaillant sous Linux et avec Eclipse, j'ai consulté quelques tutoriaux pour installer mon environnement de développement, et je me suis notamment inspiré de Introduction au SDK Android de Yann D'ISANTO, tutoriel efficace et bien fait.

Pour l'étape suivante, j'ai un peu galéré pour l'installation des packages de plateformes (Android 2.2), y compris avec le Android SDK and AVD Manager :

Mais un peu de recherche sur internet, quelques commandes magiques, et c'est bon. On a alors un environnement de développement prêt, avec un Android Virtual Device pour simuler un téléphone :

J'ai alors pu compiler, lancer et tester mon premier HelloWorld :

J'ai alors avancé sur mon projet, en découvrant les spécificités du développement Android (Activity, Layout, ...) dont je vous parlerai dans une prochaine partie ...

Pour finir cet article de "permiers contacts", et pour être complet sur la mise en route, je souhaite partager un dernier point qui m'a posé un peu problème, c'est le déploiement et les tests sur mon appareil (HTC Desire). Etant sous Linux, j'ai à nouveau un peu galéré, mais je me suis inspiré de cette page, et finalement, mon téléphone a été reconnu et Eclipse me l'a proposé dans les périphériques de tests du projet :

J'ai alors pu tester mon HelloWorld ou mon projet sur mon téléphone (capture réalisée avec tools/ddms du SDK, so simple ...) :

Dans une prochaine partie, je partagerai avec vous mes avis sur les spécificités du développement Android, mais je vous l'annonce déjà, c'est vraiment sympa ! ;-)

Et vous ? Quelles sont vos premières impressions concernant Android, en tant qu'utilisateur ou développeur ? J'attends vos commentaires .... ;-)

IE6 ou IE7 sous Linux

Et oui, IE6 toujours et encore, malheureusement incontournable lorsqu'on fait du développement WEB, mais ça fait partie de notre métier !

Etant sous Linux Ubuntu 10.04 LTS, j'ai cherché une solution pour pouvoir faire des tests de rendu avec IE6, et toutes mes recherches m'ont d'abord amené vers ies4linux. La doc est bien faite, l'installation également, y compris celle de Wine. Malheureusement pour moi, impossible de lancer IE6. En lançant ies4linux, j'ai bien ça :

Mais ensuite, j'ai une erreur dans la console :

The program 'ies4linux-gtk.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 3210 error_code 1 request_code 0 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


Beurk ....
Et apparemment, pas vraiment de solution, ies4linux semble être un projet obsolète.


De nouvelles recherches m'ont alors amené vers PlayOnLinux. Là encore, documentation bien faite et installation rapide. Une fois la "console" POL ouverte, on peut facilement choisir les programmes à installer, comme par exemple IE6, IE7, etc ... :

Attention, pour IE7, il ne faut pas installer gecko (choisir "Annuler" lors de la proposition d'installation).

Le résultat est exactement celui attendu avec un Internet Explorer 6 ou 7 aussi vrai que nature, et posant les mêmes problèmes qu'il ne reste plus qu'à résoudre ;-) :

Et vous, comment faites-vous pour tester vos sites et développements WEB sous différents navigateurs ?