mathieu szablowski
Articles de mathieu :
- Bug
- Product Backlog Item
- Task
- réactivité
- Développement empirique
- gestion du changement
- collaboration
- ...
Les étoiles MLS VS Manchester United
Pour ceux qui l’ignoraient, ce soir avait lieu une rencontre à New-York opposant les étoiles de la MLS à l’équipe championne d’Angleterre en titre, finaliste de la ligue des champions : FC Manchester United. Etant moi-même un partisan inconditionnel de Manchester United (depuis Sir Eric « le King » Cantona), je ne pouvais manquer un tel évènement.
Mais pourquoi donc parler de foot (pardon de soccer) dans ce blog dédié à la technique et à l’agilité. Le fait est qu’il y a beaucoup à retenir de ces rencontres où la gestion d’équipe, discipline dans laquelle nous avons tous notre intérêt, atteint ici son paroxysme.
Deux équipes s’affrontent sur le terrain au moment où j’écris ce billet. L’une est formée des meilleurs acteurs d’un championnat, jouant ce soir pour la gloire de leur division, dirigés par l’un des meilleurs entraineurs de la MLS. Du côté opposé, une équipe rodée, expérimentée qui comporte certes quelques nouveaux acteurs (Ashley Young par exemple a été transféré d’Aston Villa à Manchester United depuis quelques semaines seulement) mais qui suit les directives de son coach historique : Sir Alex Fergusson.
Pour faire court, même si le score ne reflète pas mon propos (Manchester U 2 – 0 All Stars MLS), aucune équipe n’a fait l’erreur de prétendre à un autre rang.
Les étoiles MLS, en tant qu’équipe dont les acteurs ne sont se rejoins pour jouer ensemble que depuis quelques jours ont passé les 45 premières minutes de leur rencontre à se créer des opportunités de marquer un but. C’est avec un jeu simple et sans fioritures que ces joueurs affrontent leurs adversaires du jour. Ils savent que leur plus grande chance de remplir leur tâche (attiser la foule, proposer une résistance à la machine tactique et physique présente en face) est de rester concentré sur l’objectif formée de barres blanches entourant un personnage ganté : Le but adverse. A trois reprises, le gardien de but de Manchester a dû sortir ses plus belles parades pour détourner des tirs de Beckham (2 fois, David, tu aurais dû rester à Manchester)et de Davids.
En face, Manchester United a fait preuve durant la première période de la plus grande des patiences. On constatait très peu de déchets dans les passes, on se concentrait sur ce que l’on savait faire le mieux(maitriser le jeu et conserver la balle). Cette équipe expérimentée assume entièrement son rôle de favori et sait que répéter les gestes, les combinaisons et les tactiques identifiés par leur entraineur finira par payer et qu’un but viendra.
Le premier but est le parfait exemple de la différence entre ces deux équipes. 4 attaquants de Manchester United s’opposent à 6 défenseurs des étoiles de la MLS.
6 passes en moins 5 secondes auront raison de la volonté des étoiles de la MLS et offriront un but facile à Anderson.
6 passes en moins de 5 secondes !!!
A ce rythme, impossible de communiquer (règle de base pour toute défense dans le monde du soccer). Restent les automatismes et l’entrainement, au final l’expérience d’être ensemble dans une situation similaire. Que reprocher aux joueurs étoiles de la MLS ? RIEN. Le mérite revient aux joueurs de Manchester United, on ne peut pas attendre des miracles de cet équipe, pardonnez-moi le terme, un peu artificielle.
En conclusion, que retenir de cette rencontre ?
Qu’une jeune équipe, nouvellement formée, doit se concentrer sur ses objectifs primaires : livrer de la valeur. Elle peut faire confiance à ces talents (Henry, Beckham, Davids) pour atteindre le but.
Qu’une équipe expérimentée, dont les acteurs ont plus que l’habitude d’œuvrer ensemble, doit tirer profit de cette force. Chaque joueur de l’équipe sait que leur talent n’a aucune mesure face à l’efficacité de la réunion de chacun des talents de ses coéquipiers. Qu’il suffira de suivre les directives pour atteindre l’objectif final et que celui-ci pourrait être édulcoré par quelques menues surprises.
Pour les courageux ayant lu ce billet jusqu’au bout, ici au pays du hockey, je vous remercie et finalement au moment où j’écris ces dernières lignes : FC Manchester United 4 – 0 Etoiles MLS.
Nomination MVP Visual Studio ALM
C’est avec un grand plaisir que j’ai reçu aujourd’hui la confirmation de ma nomination MVP Visual Studio ALM.
J’aimerais donc remercier l’ensemble des personnes ayant participé à cette nomination.
En tout premier lieu, merci à mes référenceurs pour ma candidature :
Mario Cardinal
Vincent Grondin
Etienne Tremblay
ainsi qu’à la communauté .NET de Montréal (Dotnet Montréal), à tous ses membres qui m’ont si bien accueilli et plus particulièrement à son leader Guy Barrette.
En continuant sur la vague de l’accueil Québecois, je remercie également Microsoft Canada et ses représentants passés et actuels et notamment Joël Quimper et Stéphane d’Avril-Favreau.
Tout ceci n’aurait pu être possible sans le soutien de mes collègues à Pyxis Technologies. Un grand merci donc à François Beauregard de m’avoir permis de venir travailler ici et de profiter de l’aura et de l’energie qui se dégagent de chacun des collaborateurs de Pyxis.
Je n’oublierais pas non plus de saluer les collègues français qui ont eu beaucoup d’influence sur mon travail et ma passion. Plus particulièrement, un très grand merci à Florent Santin, Etienne Margraff, Michel Perfetti et Simon Ferquel.
Finallement, j’aimerais remercier les gestionnaires, les développeurs, les testeurs, les build masters, les directeurs… que j’ai pu rencontrer durant mes différents mandats et dans les différentes formations et séminaires que j’ai pu animer. Chacune de leurs questions, de leurs remarques ou de leurs besoins m’ont permis de m’améliorer. Merci à vous pour cette nomination aujourd’hui et sur ce que vous m’apporterez demain en travaillant ensemble autour de Visual Studio ALM.
Développeur agile, où est la switch?
Ce message est à destination des gestionnaires, architectes, conseillers, directeurs, ou de toute autre personne ayant une fonction lui octroyant l’assurance d’avoir l’écoute des développeurs.
Si vous accueillez pour la première fois dans votre équipe des développeurs agiles, si vous collaborez pour la première fois avec une équipe agile, il est des réactions qui peuvent vous surprendre.
Je parle des moments ou vous vous voyez répondre un :
Pourquoi?
Dans quel but?
Qu’est ce que ça apporte?
Afin de…?
Avec un collègue français, on aimait aussi caricaturer ces moments avec le “Eeeeeeeeeet donc?” de nos collègues québécois, mais je m’égare, veuillez donc excuser cet interlude inter-culturel.
Pourquoi cette réaction vous surprend-t-elle? Parce que vous étiez, de par votre position dans l’organisation, habitué à ne pas avoir à convaincre un développeur. Après tout, vous aviez plus de responsabilités que les développeurs dans la conduite du projet. “Votre équipe” reconnaissait cette prise de responsabilité qui pouvait à n’en pas douter se retourner contre vous à la rencontre du premier obstacle, du premier échec.
Maintenant que l’équipe s’engage, qu’elle est responsable du projet, il faut vous attendre à voir chacune de vos décisions discutées ou évaluées par cette même équipe.
L’insolence que l’on peut parfois ressentir d’un tel comportement peut fatiguer, on peut le trouver futile et chronophage. On aimerait bien trouver la switch et accélérer les choses, convaincre sans discuter, faire accepter sans confronter et finalement revenir comme AVANT. Il est pourtant garant d’une réussite partagée (entre chaque membre de l’équipe). Il est aussi synonyme de défi pour vous, pour votre position, et il permet aussi de s’améliorer en évitant de se reposer sur des préjugés, des reflexes et en prenant la bonne décision, en prodiguant le bon conseil, au bon moment.
J’aurais aimé avoir cette switch lors de certaines discussions, lors de certains projets. Je remercie aujourd’hui chaque personne qui l’a activée et qui me permet de m’améliorer.
Recycle bin feature in a MSF Agile project
That is to say that “under the hood”, Urban Turtle will never show any Bug, Product Backlog Item or Task in the Planning Board and in the Task Board if their state is equal to Removed.
In order to enable the Recycle Bin feature with another process template, you will have to define a common Cloaked state for every work item that could be recycled. In this post, we will update the MSF 5 for Agile Software development process template to be able to recycle useless items of type Task, Bug or User Story.
To add this common state to the targeted work items, we will use the Process Editor as we already did in the previous post describing how to activate the Proposal Feature.
Select the menu : Tools >> Process Editor >> Work Items Types >>Open WIT from Server
Connect to your Team Foundation Server and your Project Collection and select the User Story work item type in a project created with the MSF 5 for Agile Software Development process template.
In the work item type editor, select the Workflow tab. The initial workflow should appear :
Note : the present diagram has a Proposed state defined to activate the Approval feature in Urban Turtle.
Open the Toolbox and drag and drop a new state called Removed in the diagram. You can edit the name of the state by double clicking in the state box.
You now have to create the different transitions from existing states. In most cases, the Recycle bin will be used to cloak some items that do not give value anymore (duplicated, obsolete, misunderstanding…).
Select the Transition Link tool in the toolbox and create a link between the Proposed state box and the new added Removed state box. You can repeat this action to add a transition from the Active state box and the Removed state box.
The new workflow for this work item would enable you to remove work items of type User Story in the recycle bin but you probably want to be able to reactivate removed work items. To do so, add another transition fron the Removed state box to the Proposed state box (this will allow your Product Owner to reevaluate the relevance of the user story).
Your final workflow should look like this one below :
Do not forget to add any required reasons for all the added transitions and save your work item definition.
Your process template is now able to support the recycle bin feature. You can activate the feature in the urban turtle configuration file. On the Team Foundation Server Application Tier, find and edit the Urban Turtle configuration mapping file from your updated process template.
Once again, we strongly recommend to make a copy of this file before editing it.
%TFS INSTALL DIR%Application TierWeb AccessWebUrbanTurtleconfigurationproject
Add a new element in the Features Section, defining the cloaked state.
Finally, you will have to apply this new configuration file to your existing project in Urban Turtle. To do so, connect to your project in Urban Turtle and select Project >> Configuration in the urban turtle toolbar.
Select the updated configuration file (in this example the MSF 5 agile) and click Apply.
To test the feature, create a new user story in the updated team project. You can now hide this story from your backlog just by draging it in the recycle bin in the iteration and area toolbar.
In a soon coming article, we will configure our project to be able to consult the Burndown chart.
Approval feature with MSF Agile 5.0
This post is part of a series of blogs describing how to modify the process template MIcrosoft MSF 5 Agile to activate the advance features available with Microsoft Visual Studio Scrum 1.0 process template.
“Out of the box” with any project using the new Microsoft Visual Studio Scrum 1.0 process template, Urban Turtle provide a feature for story approval.
However, if your project is using another process template such as MIcrosoft MSF 5 Agile the approval feature is not activated. This post is a walk through describing how to activate this feature.
Approval
The approval feature is a transition helper, allowing user to click on a button to change the state of a work item. Some templates do not contain this concept because the functional items (user story, bugs…) are active just after creation. To be able to approve a work item with Urban Turtle, you have to: · Add a “Non-approved” state to the functional items · Create a transition from the non-approved state to the active state · Edit your Urban Turtle configuration to specify the approval transition Adding a state to a work item type could easily be done with the help of the Process Editor which is part of the Team Foundation Server Power Tools. The Team Foundation Power Tools are available at this url: http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f
After installation, Visual Studio 2010 has a new menu item in the Tools section. This tool will allow us to update the work item type definition of our project directly from the server.
Select the menu : Tools >> Process Editor >> Work Items Types >>Open WIT from Server
A dialog box appears, navigate through your project collections and project to open the work item type definition.
In this example, I have chosen to edit the User Story work item. Select the work item type and click OK.
The work item type definition file should now be loaded in Visual Studio. The editor contains 3 tabs: Fields, Layout and Workflow.
To add a new state, select the Workflow tab. The workflow editor is a visual designer where each red box is a state linked to others states by transitions (blue arrows).
The specific tool box will help you to change the work item type workflow.
Just drag and drop a new State box in the diagram and name it Proposed. You can edit the name of a state box by double clicking the current name box.
You now have to create the transitions from the creation to Proposed and from the Proposed state to the Active state. Just select the incoming transition already present in the Active state and press Del to delete it. We will replace the creation transition to our new Approved state.
Select the transition link tool in the toolbox and drag a link from an empty space (not from a state box) to the Approved state box. Double click the transition to edit it.
Select the Reasons tab and add a reason named Created.
Again, add a transition link between the Approved state box and the Active state box with a reason called Approved.
Save your changes by clicking the save button in the Visual Studio toolbar. You can now test your new work item types definitions by creating a new User Story.
Now that you have the required state in the type definition workflow, you just have to configure Urban Turtle to take advantages of it. On the Team Foundation Server Application Tier, find and edit the Urban Turtle configuration mapping file from your updated process template. In this example, we will update the MSF Agile 5.xml file located at:
%TFS INSTALL DIR%Application TierWeb AccessWebUrbanTurtleconfigurationproject
We highly recommend you to make a copy of this file.
Add a new element in the Features Section, defining the approval action for a User Story work item type as a transition from the Proposed to Active state.
Finally, you will have to apply this new configuration file to your existing project in Urban Turtle. To do so, connect to your project in Urban Turtle and select Project >> Configuration in the urban turtle toolbar.
Select the updated configuration file (in this example the MSF 5 agile) and click Apply.
To test the feature, create a new user story in the updated team project and verify that the initial state is equal to Proposed.
Save and close the editor to return to the planning board. In the planning board, the user story now has a new button at the right of the list item that allows users to approve the story.
If you click on this button, the user story will automatically pass from the state Proposed to Active.
In the next article, we will configure our projet in order to activate the recycle bin feature.
Urban Turtle : Des graphiques d’avancement dans vos projets
Aujourd ***, l’équipe Urban Turtle est fière de proposer une nouvelle version de son outil de gestion agile avec Team Foundation Server.
Cette dernière version propose aux équipes travaillant avec le dernier modèle de processus Visual Studio Scrum 1.0 un graphique d’avancement temps réel (donc pas de warehouse, d’analysis services etc…).
La dernière version est téléchargeable à l’endroit habituel : Download URBAN TURTLE
La dernière version est téléchargeable à l’endroit habituel : Download URBAN TURTLE
Urban Turtle 3.3 is now available! – Hour Burndown Chart
Une tortue flashée a 240!!!
Prise sur l’autoroute de la livraison, à la poursuite d’un modèle de processus qui venait de sortir. La tortue est désormais recherchée. Elle risque des années de travaux d’intérêts généraux, notamment dans le rôle d’accélératrice de solution pour les projets Scrum avec Team Foundation Server.
Source : Urban Turtle delivers a kick-ass experience for Scrum in Visual Studio Team Foundation Server
Pour télécharger la version compatible avec le tout chaud modèle de processus Microsoft Visual Studio Scrum : Urban Turtle
Scrum.org la révolution des développeurs
Si vous ne connaissez pas encore Scrum.org et que vous travaillez actuellement dans un contexte agile, je vous conseille fortement de faire une petite visite sur le site.
Il s'agit d'une nouvelle initiative visant à promouvoir Scrum et l'agilité et à former les acteurs d'un projet à ces nouveaux contextes.
Ken Schwaber, le papa de Scrum, est à l'origine du projet et a établi un programme spécifique pour les développeurs. Le programme comble ainsi un manque terrible dans bon nombres de cursus agiles : la formation des développeurs.
L'objectif est ici de fournir la connaissance des outils et des pratiques qui permettront à un développeur de répondre aux différentes contraintes des projets agiles :
Le modèle de Kano, une force dans vos projets agiles
Le modèle de Kano est un outil permettant la priorisation des éléments d’un projet en projetant la disponibilité d’une fonctionnalité sur la satisfaction que celle ci apporte. La grande force de ce modèle tient dans son postulat de base : La satisfaction ou l’insatisfaction d’un utilisateur pour un même point n’est pas une notion diamétralement opposée : «Ce n’est pas parce qu’une fonctionnalité livrée augmente la satisfaction de l’utilisateur que l’absence de cette même fonctionnalité aurait eu un impact négatif vis à vis de la satisfaction utilisateur».
De ce postulat, le modèle propose de sonder les utilisateurs en mesurant leur satisfaction du produit final dans le cas de la mise à disposition et dans le cas de l’absence de chacune des fonctionnalités.
Je vous laisse faire quelques recherches pour explorer plus en avant ce modèle car dans ce billet, j’aimerais m’attarder sur un point particulier, à savoir le recensement et la livraison des fonctionnalités de base.
Les fonctionnalités de base (basic needs) sont des points cruciaux pour la réussite de votre projet mais celles ci sont fourbes, elles ne sont pas clairement exprimées, on dit qu’elles sont implicites. Obligatoires et implicites, vous voyez ou je veux en venir...
Dans nos processus de développement agiles, la sollicitation des utilisateurs dans la définition des fonctionnalités est point essentiel. On tente ainsi de remédier à la dérive fonctionnelle des projets dont les spécifications ont été rédigés par des informaticiens.
Chaque fonctionnalité apportera un service, de la valeur ajoutée à l’utilisateur.
GOOD ENOUGH SOFTWARE
Dans un extrême caricatural, des équipes se laissent ainsi guider par des carnets de produits entièrement rédigé par un utilisateur. Ils vont forcement atteindre le GOOD ENOUGH SOFTWARE, pas de fioritures, pas de gadgets, jusque ce qu’il lui faut. Prétextant une volonté de ne pas vouloir influencer leur gestionnaire de produit, certaines équipes se refusent même à évoquer certaines fonctionnalités qu’elle trouve intéressantes.
Il faut pourtant se rendre à l’évidence, nos gestionnaires de produits ont rarement l’expérience ou les connaissances techniques qui leur permettent de déduire des fonctionnalités de base ou de mesurer l’impact de l’absence de certains points fonctionnels.
Comme toujours la solution réside dans la collaboration entre les membres de l’équipe et son gestionnaire de produit et le modèle de Kano offre ici un cadre de collaboration explicite :
L’équipe détecte une fonctionnalité basique, décrit la valeur ajoutée.
Le gestionnaire de produit mesure la satisfaction apportée par la livraison ou l’absence de cette fonctionnalité dans le produit final.
La fonctionnalité rentre dans le carnet de produit, ou pas!
C’est simple et ça devrait facilement pouvoir s’intégrer dans une maintenance de carnet (backlog maintenance).