mercredi 3 mars 2010

C# 4.0, et nouveautés à la BCL au MIC à Mons




C'est quand ? le jeudi 04 Mars 2010



Description de la session :


Alors que la sortie officielle de Visual Studio 2010 et du framework 4.0 est prévue pour le 12 Avril 2010, et que le langage arrive avec de nouvelles révolutions, il est temps d'en explorer les améliorations.


Au cours de cette conférence, nous aborderons donc les points suivants :



  • Co & Contra Variance des types génériques

  • Paramètres nommées et optionnels des méthodes

  • Types dynamiques

  • Simplification pour l'interopérabilité COM

  • Améliorations apportées à la BCL (Base Class Library)

    • Découverte de la classe Tuple

    • Quelques améliorations apportées à System.IO

    • Découverte des fichiers mappés en mémoire

    • Introduction à CodeContracts

    • Introduction à PFX (Parallel Framework Extensions)

    • Présentation du type BigInteger




Plus d'info : http://www.dotnethub.be/agenda/c-4-0-et-ameliorations-a-la-bcl-em-base-class-library-em

jeudi 14 janvier 2010

Nouveau Blog

Suivez le guide : http://www.methode-agile.org 


Vous pourrez suivre l'évolution de notre user group sur DotNetHub.

mardi 5 janvier 2010

Bientôt un événement agile en wallonie (Suite)

Premièrement, je voulais souhaiter aux millions de visiteurs mes meilleurs voeux pour cette année 2010 et même plus, je ne vois pas pourquoi on se limite à un an de bonheur.

Lors de ma première publication sur un événement agile en wallonie, j'étais un peu trop optimiste sur le "bientôt", néanmoins nous avons franchi un cap important. Nous avons créé le groupe d'experts qui organisera cet événement : www.dotnethub.be.

Ouille ouille Dot Net Hub, ça sonne plutôt mirosoft ça non? Et bien oui. Bon on va pas bouder nos origines, nous avons tous fait ou faisons encore du .net et donc nous voulions un peu de neuf dans les groupes technologiques. Nous n'allons pas proposer des super démos technologiques que personne ne comprend, mais bien une vitrine technologique .net saupoudrée de méthodologie Agile biensur.

Il y aura donc deux volets bien distincts dans le groupe
  • Le .net

  • L'agilité


Et nous ne voulions pas un nom à rallonge comme Agiledotnethub ou Dotnethubagile ou toute autre déclinaison.

Le but de ce groupe est donc d'aller chercher les experts francophones (belges, luxembourgeois, français, québecquois, mauritien,...) et de leur proposer conférences, ateliers, dojos, formations, support technique et/ou méthodologique.

Je concluerai là dessus, visitez le site et l'agenda : le 20 Janvier, notre première conférence sur les tests unitaires par Jonathan "Peli" de Halleux

samedi 17 octobre 2009

Le temps passe vite

Notre projet change à toute allure et je n'ai pas encore pris le temps d'en écrire une ligne.
En Bref :

  • une partie de l'équipe est allée s'enrichir et partager au CITCON, je n'ai malheureusement pas pu m'y rendre, mes collèges vous en parlerons mieux que moi

  • nous avons séparé l'équipe en 2, les 2 équipes ont donc maintenant des objectifs, des stand-up, des planning game, des rétrospectives différents

  • le pilotage a aussi évolué, nous testons, ça ne marche pas trop, mais on va rectifier cela au plus vite. En gros le client nous demande des estimations moyen terme sur base de l'existant sachant qu'on ne va pas faire le même ou sur base de simples phrases lachées par le client en comités de directions (auxquels nous assistons), l'erreur a été de leur donner des chiffres trop tôt

  • nous avons reçu une invitation à participer à l'Agile Tour à Lille le 30 octobre 2009, nous animerons, Pierre-emmanuel Dautreppe et moi deux sessions: une basée sur le retour d'expérience avec justement en primeur les derniers changements de pilotage et organisation de l'équipe, l'autre sur l'art du bon test : venez nous voir !

mardi 18 août 2009

Pratique N°2 : le planning game

Aïe Aïe Aïe, quelle pratique !

Arrivée tard chez nous, cette pratique n'a pas été comprise, ensuite mal utilisée. Le gros problème de notre projet c'est d'avoir commencé XP en mettant en œuvre les pratiques au compte-goutte.
Le planning game, enfin ce qu'on appelait un planning game au début, se résumait en une réunion entre le directeur informatique (MOA), le chef de projet (MOE) et l'architecte.
Bien évidemment les estimations étaient foireuses, du fait que les estimations étaient faites par un senior et réalisées parfois par des juniors, et toujours en binôme.

La notion de point est déjà une notion tellement incompréhensible la première fois qu'on se demande si ce n'est pas un cannular. L'effet ridicule passé, le noeud du problème émerge : un point = quoi? une heure pour un binome, une journée pour un binome. La réponse du coach n'est pas plus claire : c'est l'effort nécessaire à réaliser une tâche.
Effort (déf. Larousse) : Action énergétique du corps ou de l'esprit vers un objectif, un but.
Le souci a été de déterminer l'étalon, la tâche de référence.
Donc arbitrairement nous avons décidé de partir de 1/2 jusqu'à 8 en multipliant par 2. 1/2 - 1 - 2 - 4 - 8. Ceci nous a permis d'éliminer rapidement le 8 car chaque tâche estimée à 8 points débordait sans exception. Autre souci dans notre pondération, avec l'équipe notre vitesse était de 12 pt/itération. Donc impossible d'avoir un suivi fin et quotidien sur 12 points - 3 binômes et 10 jours de DEV. Sachant qu'il y avait au moins une tâche à 4 points dans chaque itération. Dessiner un burndownchart se serait révélé inutile.
Revenons au planning game, nous réunissons toute l'équipe, la notion de point assimilée (ou presque), les analystes expliquent une tâche ensuite, à main levée, estimation, débat, consensus : voilà on a estimé.
Que faire maintenant de ces points ? L'humain est accroché au temps, donc je m'attends à ce que l'équipe clôture 12/10 de point tous les jours. Oui mais ça c'est beau en théorie, mais en pratique c'est autre chose.
Avec des points qui sont purement imaginaires et du temps qui ne l'est pas, quand puis-je me rendre compte que je suis en retard ?

Bon changeons le format du planning game, je reviens des XP days Paris 2008, génial, ils ont édité des jeux de cartes 'spécial planning game'. Nous avions remarqué que l'équipe s'inspirait du premier qui estimait et donc les estimations s'harmonisaient pour autant que la personne n'ai pas envie de justifier pourquoi elle estimerait son temps double des autres. "Moi j'estime comme les autres comme ça on ne me pose pas de question". Donc Poker planning game, génial l'effet débat est lancé, la première carte en l'air et personne n'est d'accord et l'éternel question : "c'est quoi un point ?". Passons, le débat technico-fonctionnel est bcp plus intéressant, si poker PG n'a pas franchement permis de solutionner le problème des estimations, il éveille enfin des discussions intéressantes et donc les estimations sont un poil plus justes. Cela se traduit par moins de débordement.
Mais voilà, un truc qu'on pense bien rôdé ne marche toujours pas, les estimations ne sont pas correctes, encore des dépassements, on retire des tâches, on fini à l'arrache,...
Que se passe-t-il ? Lors du PG suivant, je pose la question et là la réponse vient des plus "forts" de l'équipe, on estime sur base de l'équipe et pas sur base de ce que je ferais moi. Donc on se retrouve avec beaucoup de tâches surestimées, et donc les tâches qu'on fini à l'arrache sont les tâches qu'on ajoute en cours d'itération qui déstabilisent tout (Ne pas inclure de tâche non planifiée).

Que fait-on ? Bon Deux choses, on a remarqué en parallèle que quand l'équipe bosse sur un "projet", elle est plus efficace. Alors modelons les itérations comme des projets, un but commun et non pas 10 tâches qui n'ont parfois aucun lien entre elles.
De plus il est important de recadrer le contexte dans lequel s'inscrit la tâche. N'oublions pas que nous créons une appli pour des utilisateurs qui ont un savoir-faire dans leur métier, et il est important de comprendre le métier pour le traduire dans le code, et en même temps ne pas se perdre en chemin, cela fait déjà 2 ans que le projet a démarré. Et donc petit effort pour les analystes ..payant.
Le fait de négocier avec le client non pas de micro-tâches que personnes ne remarque mais bien de blocs/modules fonctionnels augmente la valeur du produit et l'adhésion de l'équipe.

Néanmoins, le "POINT" est toujours incompris.
Début 2009, je reviens de ma formation "scrum master", génial, en passant cela ouvre les yeux sur beaucoup de choses. Cela reseemble furieusement à une uusine à fric, mais quand on sort de là, on a plus qu'un titre, on acquiert un savoir qu'il faut pratiquer. Scrum master certifié signifie qu'une personne a suivi une formation certifié scrum master et rien d'autre.
Lors de cette formation j'ai appris une nouvelle méthode d'estimation, toujours à exploiter par l'équipe pendant le planning game : le mur.

Alors simple : vous collez sur un mur des post-it représentant votre échelle de pondération en colonne, vous exposez le contenu de votre itération également sur post-it. Chaque membre de votre équipe prend 1 à plusieurs de ces post-it et le colle dans la colonne de son choix. Lorsque toute l'équipe a collé tous les post-it, il suffit de lancer le débat et repasser chaque post-it en s'assurant que personne ne s'oppose farouchement à la pondération choisie.
Donc nous avons un planning game plus court et chaque tâche est choisie et pondérée par une personne, mais validée par l'équipe.

En mettant en pratique cela nous avons modifié notre échelle et afin de couper court au débat sur les points, nous avons définit que 1 point = 1 heure/binôme. Nous avons fait cela pendant 2 planning game et ensuite nous n'avons plus pronnoncé le mot "Heure", mais "Point". A l'heure actuelle nous comptons +- 120 pts/itération. Ce qui nous permet de suivre un graphique d'avancement(burndownchart) tous les jours.

Autre chose, c'est à ce moment là que nous avons défini notre mot : "Terminé".
Il est important que l'équipe se définisse un contrat sur chaque tâche, quand est-ce-que je peux dire que ma tâche est terminée ?
  • Quand mes tests passent
  • J'ai fait mon refactoring ?
  • ...


Les effets : pondérations beaucoup plus justes, boost de l'équipe et adhésion des membres de l'équipe au système de planning game.

Résumons :
  • focaliser son équipe sur un objectif commun et éviter un panier(backlog) rempli de petites tâches disparates

  • Adopter une technique d'estimation adaptée à votre équipe : main levée, concertation, poker, mur,... Il en existe une multitude et le choix doit être concerté et testé

  • Choisir également une échelle de point assez grande afin de pouvoir suivre l'évolution quotidienne de l'équipe

mardi 4 août 2009

Pratique N°1 : Client sur site

Et bien nous sommes vernis, le client a demandé XP dans le "contrat" et connaissait déjà en partie les pratiques XP.
Le fait d'avoir le client sur site lui semblait une évidence autant que le choix de l' eXtreme Programming.
La société (client) est née à la suite d'une scission d'une plus grosse société, et donc la connaissance métier s'est partagée entre les deux nouvelles entités. Le choix d'une méthode agile, itérative a donc émergé. Il était difficile voire impossible pour la direction de l'époque de condenser dans un "cahier des charges" ce qu'elle attendait d'un développement aussi gros.

Difficulté à noter toutefois, le projet a commencé en fin 2005 avec une direction (Mr X), la direction a changé (Mr A). Mr A débarque et voit un projet qui dure depuis déjà 2 ans et ne voit pas où il s'arrêtera. La demande d'avoir un périmètre clair et identifié nous a été faite, le périmètre nous a été fournis sous la forme de procédure QUALIGRAM. Nous devons estimer la "charge" de ce périmètre. Nous avons utilisé COCOMOII (cocomo 2).
La fin du projet est prévue pour mi-2011. Donc nous sommes face à un projet agile complet (pas un ensemble de petits projets) de +- 6 ans?.

Revenons au client sur site :

les +


+ réponses rapides dans les 2 sens, nous vers le client et le client vers nous
+ transparence relative sur notre boulot
+ empreinte de l'ambiance qui reigne chez le client, sur un projet longue durée cela est assez important
+ impression de faire partie de la société cliente (impression partagée)
+ le client se familiarise avec notre façon de travailler
+ la proximité amène des questionnements plus profonds chez le client sur sa manière de travailler (le développement informatique participatif ou agile a souvent cet effet)

les -


- les crises internes de l'équipe de DEV sont directement perceptibles par le client
- l'équipe ne se sent pas toujours chez elle (à contrario du + faire partie du client), il existe toutefois bien une frontière, l'équipe ne peut pas toujours se "lâcher"
- l'équipe est parfois victime des petites vendetta côté client par la "priorisation" de tâches importantes

Conclusion : malgrès quelques points négatifs, qui sont là pour nous rappeler que l'agilité est une aventure humaine avant tout, le client sur site est plus que bénéfique pour un projet informatique. Il amène énormément de réflexions chez le client, une connaissance fine du métier client de la part de l'équipe, il nous arrive de participer à des réunions importantes et apporter un point de vue différent. Cela se traduit par une application très proche des désirs utilisateur/client.

Géographiquement, nos bureaux de développement sont dans les bâtiments du client.

Dans ce contexte de méconnaissance métier, sans être négatif, ou je dirais plutôt en période d'apprentissage de la part du client, nous avons créé des rôles qui ne sont pas tout à fait XP.

Il y a un chef de projet, désir du client et en même temps pratique automatique de la part de Thales.
Il y a 2 analystes dont le rôle et d'être le responsable client (product owner) et en même temps analyste fonctionnel, donc le principe est de dire quoi et plus ou moins comment le client veut ses fonctionnalités. Et le fait d'avoir le client à porter de main nous évite la dérive d'avoir des analystes dictateurs, mais bien messagers/décodeurs des exigences du client final.
Il y a également un architecte, qui est notre référence technique qui a comme rôle de penser à la structure de l'application, d'être en avance sur les technos qui vont être utilisées dans l'application et de ce fait, il nous a permis d'avoir dans la même équipe des profils senior et junior qui cohabitent dans un cadre XP. Nous étudierons ce sujet lorsque nous aborderons le binômage.

Voici une cartographie globale des interactions entre notre équipe et le client :


Quelles sont elles ?

Le comité de pilotage


Il réuni notre chef de projet, la direction générale du client, notre commercial. Il sert à passer en revue les différents indicateurs du projet (Bugs, Fonctionnalités,...), mais il sert surtout à donner les grandes priorités du client. Il se déroule toutes les 6 semaines, et donc il y a à chaque fois une livraison en production entre chaque comité de pilotage.

Les réunions fonctionnelles


Ces réunions rassemble les analystes, les décideurs fonctionnels et parfois les utilisateurs du système. Elles sont programmées toutes les deux semaines, donc à chaque itération. Cette réunion permet de définir les priorités de chaque service et donc les directeurs assistent également au comité de pilotage, et donc il sont conscient des priorités issues du comité de pilotage, ils doivent donc intercaler leur demande sans bousculer l'agenda du projet comité de pilotage. A la fin de la réunion nous obtenons le backlog des prochaines itérations.

Le planning game


Cette réunion nous permet d'estimer le backlog des réunions fonctionnelles. Cette réunion rassemble le chef de projet, les analystes, les développeurs client et fournisseur et un (des) représentant(s) du client afin d'apporter quelques précisions au besoin sur les spécifications des analystes. Le représentant du client est à 90 % assuré par les analystes. Et donc utilité de la réunion fonctionnelle préalable.

Stand-up


Réunion matinale qui permet à tout le monde de dire ce qu'il a clôturé la veille, ce qu'il va faire aujourd'hui et ce qui l'a bloqué ou le bloque encore.
Cette réunion rassemble toute l'équipe de DEV et parfois le client et donc comme souvent les analystes font office de représentant du client.

Binômage


Petit mot sur le binômage, dans ce contexte, il est un outil de communication entre les équipes (fournisseur/client). L'équipe du client doit également maintenir l'ancien système informatique. Les développeurs client ne sont donc pas disponible à plein temps. Le binômage leur permet donc de reprendre vite du service et se tenir à jour sur le code après une période d'inactivité sur le projet. Dernièrement un système alternatif a été mis en place, ils sont deux et donc une semaine sur deux il y en a un à temps plein dans le développement de l'application.

mardi 14 juillet 2009

Le principe de Peter

Petit livre sympa que je suis en train de lire : Le principe de Peter.

Il nous fait état d'une discipline qu'est la hiérarchologie.

En gros il résume en une phrase qui est d'ailleurs sur la couverture : tout le monde a tendance à s'élever (dans la hiérarchie) jusqu'à son premier niveau d'incompétence.

Le corollaire est que tous les gens qui nous entourent et nous y compris, sont des incompétents en puissance ou acquis.

Ce livre remue les idées reçues sur ce qu'on appelle la compétence.
Il est parfois radicale, mais évidemment à prendre au sens critique.

Voyez si vous êtes prêt pour vous réveiller !

Pour 4 €, il est rempli d'exemples et vous y retrouverez bon nombre de vos collègues et amis, vous rigolerez et/ou vous pleurerez, donc c'est un bon livre de chevet.