Pages

mardi 8 novembre 2011

Motiver des équipes agiles (et les autres...)


Préambule : Ce post est la traduction d’un autre post d'Aaron Bjork Principal PM chez Microsoft.
Merci à Visual Studio Magazine de m'avoir autorisé à traduire cet article

Article original : Motivating an Agile Team


Aaron Bjork nous  parle de la façon de motiver vos équipes agiles sans les entraver.

La première, et probablement la plus importante déclaration dans le Manifeste Agile, parle directement aux équipes de développement: 
Les individus et leurs interactions sont plus important que les processus et les outils.
En résumé, les gens sont plus importants que toute autre chose.

Etrange introduction de la part d'un 'tools guy', puisque je travaille chez Microsoft en tant que Program Manager sur Team Foundation Server et Visual Studio. Il ne fait aucun doute que je veux que les équipes de développement utilisent ces outils que je fabrique.
Toutefois, il serait idiot de suggérer que les équipes vont réussir grâce aux outils à leur disposition.
Comme le Manifeste Agile l’indique clairement, le succès de l'équipe est d'abord assuré par la valorisation des membres de l'équipe et par leurs interactions. Les  outils et processus sont importants, mais ils ne sont pas plus importants que l'équipe elle-même.
 
Cet accent mis sur les gens est une raison majeur pourquoi j'aime la méthode Agile.
Elle nous dit de sortir les outils de nos esprits et de regarder l'équipe qui nous entoure.
Elle nous dit que si nous voulons trouver ce trésor au pied de l’arc en ciel du développement de logiciels, nous devons travailler ensemble et valoriser chacun d’entre nous.
Elle nous dit que le succès dépend de l'équipe.

L'année dernière, j'ai lu un livre écrit par Dan Pink intitulé "Drive: The Surprising Truth About What Motivates Us".
Ce fut une lecture fascinante, un de ces livres que l’on ne peut pas refermer; je le recommande à tous. Je me souviens de nombreuses soirées où je m'arrêtais mi-chapitre pour dire à ma femme: "Ecoute ça", avant de lui lire à haute voix une partie de l'ouvrage. Elle m’a finalement dit qu'elle le lira quand je l’aurai terminé, et m'a donc demandé d'économiser ma salive.
Ce livre m'a captivé, et il m'a ouvert les yeux sur certaines vérités concernant la motivation.

Dans Drive, Pink met en opposition les techniques de motivations traditionnelles (récompenses et punitions), avec trois nouveaux principes essentiels à la motivation dans les industries innovantes : autonomie, maitrise et objectif.
L'idée, c’est que les gens recherchent ces trois caractéristiques dans tout ce qu'ils font, et quand ils les trouvent, des bonnes choses se réalisent.
Dans ce post, je veux expliquer rapidement pourquoi  l'autonomie, la maîtrise et l'objectif sont essentiels à la  constitution d’une équipe agile saine.

Autonomie.
Le premier principe présenté par Pink est l'autonomie: la capacité de chacun à prendre ses propres décisions.
Pour une équipe de développement de logiciels, c’est essentiel.

Une équipe a besoin de se sentir responsable, et une équipe a besoin d'être responsabilisés. Pourquoi? Parce Agile nous enseigne que le changement est inévitable lors du processus de développement logiciel.

Dès le moment où l’équipe a démarré, elle va apprendre sur le produit,  sur l'architecture, et sur les clients. L'équipe doit se sentir habilitée à réagir au changement et à communiquer sur ce qu'elle est en train d’apprendre.
Cela ne signifie pas que l'équipe doit pouvoir faire ce qu'elle veut, mais plutôt, qu’elle a la liberté de faire ce qui est juste.

Une équipe manquant d'autonomie est plus susceptible de suivre aveuglément un plan transmis par le haut, tout en ignorant la réflexion critique.

Maîtrise.
Le concept de maîtrise est assez simple: les gens veulent apprendre à mieux faire ce qu'ils font.
Nous trouvons cela dans tous les domaines de la vie.

Une partie de notre ADN nous donne l’envie de nous améliorer. Les tout-petits travaillent sans relâche pour maîtriser l'art de la marche. Ils n’ont, généralement, besoin que d’un peu d'encouragements. Par nature, ils ont un réel désir de maîtriser la marche, et ils y travaillent jusqu'à ce que ça devienne une seconde nature.

Cela ne change pas en vieillissant. J'aime jouer au golf, et j'aimerais être un meilleur golfeur, année après année. Cette amélioration est une partie de mon amour pour ce jeu. Je ne suis certainement pas un maître (ma carrière sur le PGA Tour ne s’est pas encore concrétisée), mais je continue à m'entrainer pour m’améliorer, trou après trou, tour après tour, et année après année. Le processus et les résultats sont tous deux exaltants.

Les équipes de développement ne sont pas différentes.
Toute équipe dispose d'un goût naturel pour trouver des nouvelles et meilleures façons pour accomplir son objectif.
Les membres de l'équipe aiment écrire des logiciels et ils aiment résoudre des problèmes difficiles. S’ils n’aimaient pas cela, ils ne travailleraient pas dans un secteur difficile.
Ils sont motivés par le défi et l'art de bâtir une solution élégante et fonctionnelle.

Cependant, trop souvent, nous traitons les équipes et leurs membres comme s'ils étaient des pions sur un échiquier qui peuvent être déplacés, décalés et changés sans conséquences. Nous remanions les ressources, nous changeons les objectifs et nous chamboulons leurs priorités. En faisant cela, nous enlevons leur capacité à devenir maîtres. C'est un modèle que je vois répété encore et encore dans notre industrie.

Objectif.
Ce dernier principe énoncé par Pink est l’Objectif.
Les équipes ont un profond désir de comprendre comment leur travail s'inscrit dans une vue d’ensemble. En tant qu'ingénieur, je veux comprendre à quoi le logiciel que je vais construire va servir.
Nous avons besoin d'une raison et d’un objectif.

En tant que leader dans votre organisation, trouver des façons de vous assurer que votre équipe sait que ce qu'elle produit est de contribuer au business.
Communiquer à propos de l'importance des nouvelles fonctionnalités livrées dans le dernier sprint. Montrez-leur les clients ravis utilisant leurs solutions. 

Trop souvent, nous déconnectons  nos équipes de développement du business et des clients.
Nous le faisons parce que nous pensons cela ne les intéresse pas, ou nous ne voulons les distraire avec ça.
Mais, le plus souvent, nous finissons par les aliéner et par détruire leur sens de l’objectif.

Conclusion
A mesure que vos équipes grandissent, mûrissent et s'efforcent d'être plus agile,  travaillez pour créer un environnement « autonomie, maîtrise et objectif ».
Je n'ai aucun doute que vous témoignerez, à mesure que vous avancerez, d’améliorations sur le moral, dans l’innovation et l'efficacité.

mercredi 14 septembre 2011

Data is like gold

Is your gold safer at home or in a bank?

Logically, your banker is a monetary security specialist and security deposit box or vault should resist intrusion better than a simple home security method.
The defensive measures applied to prevent burglary are much more stringent, more efficient and more consistent than yours. And the more gold a bank secures, the more significant its defensive measures..

Data is like gold. Your data is safer in a professional cloud datacenter than in your server room.
The defense measure implemented by the cloud datacenter professional are tougher, more resilient, and rightly so because it's part of their investment. The monitoring of professional cloud datacenters is constant, 24 hours a day/ seven days a week, and   incident management handled rapidly and often by a more qualified staff.

Entrusting your data (and apps) to a professional cloud operator, is like entrusting your gold to a banker, it’s in good hands. Your data is less likely to be stolen in a cloud datacenter, where it’s their job to care for data, rather than concern yourself with its constant protection.

Les données, c’est comme l’or

L’or que vous possédez est-il plus en sécurité chez vous? Ou dans une banque ?
 
En toute logique, chez votre banquier, il est un spécialiste de la sécurité, et son coffre résistera bien plus longtemps que le vôtre.
 
Les contre-mesures appliquées lors des tentatives de cambriolage sont bien plus nombreuses, plus efficientes et plus constantes que les vôtres.
 
Plus un banquier détient d'or, plus ces mesures de défenses sont importantes.
Il en va des données comme de l’or. Vos données sont bien plus en sécurité dans un datacenter que dans votre salle serveur.
 
Les défenses mises en œuvre par les datacenters sont plus fortes, plus nombreuses, cela fait partie de leurs investissements de bases. Le monitoring des datacenters est contant, 24heures sur 24, 7jours sur7, avec une réactivité bien plus rapide et plus qualifié.
 
Confier ses données (et ces programmes) à un opérateur du cloud , c’est comme confier son or à son banquier, une forme de tranquillité.
 
Vos données ont moins de chance d’être volé chez quelqu’un dont le métier est la garde de ses dites données  que chez vous, de même que votre or a moins de chance d’être volé chez un banquier que chez vous dans votre coffre.

vendredi 2 septembre 2011

Why MSFT let’s me down?

Just a quick, humorous post to talk about my frustrations with MSFT and to express my doubts in words. 
There’s no Windows 7 tablet OS on the horizon and there are just vague rumors around Windows 8.

So what’s up with MSFT?

I google greedily at articles and videos on the Cisco "Cius" and on the Samsung tablets, and I can't offer anything to my clients, nothing more than some HTML5 pages.
Not bad, but even so, when you see Microsoft’s videos
'ENVISIONING' and 'Microsoft Sustainability : Productivity, future vision', HTML5 will not do everything.

There is such a gap between these very exciting “marketing video” vision and the application of real vision.

My dream is simply to offer Windows Metro-native applications to my clients on a tablet.  The leap from Windows Phone 7 to such a tablet OS shouldn’t be so difficult, and an agreement with tablet manufacturers is not so hard to obtain.
I dream about having a tablet with a native Office 365, and in particular, Lync & Outlook, plus my own native “tablet” applications.

There is such a potential for professional tablets!

Okay, dream over.   I plunge back into reality with the Android SDK and I revise my Java.

Pourquoi MS me laisse tomber ?

Juste un petit billet d’humeur pour dire ma frustration, mettre  des mots sur mes doutes.
Pas de tablette Windows 7 à l’horizon, juste de vagues soupçons et rumeurs autours de Windows 8.
 
Mais qu’est-ce qu’il leurs est arrivé ?
 
Je regarde avidement  les articles et vidéos sur le « Cius » de Cisco, sur les tablettes Samsung, et je ne peux rien proposer à mes clients, rien d’autre que des pages HTML5.

Pas si mal, mais tout de même, quand on voit les vidéos 'ENVISIONING' et 'Microsoft Sustainability : Productivity, future vision', l’HTML5 ne pourra pas tout faire…

Il y a un tel écart entre cette vision très enthousiasmante et le manque de vision dans les faits.

Je rêve juste de pouvoir proposer des applications Windows / Metro / native à mes clients, le delta entre le Windows Phone 7 et un OS pour tablette n’est pas si grand, l’accord avec des constructeurs de tablettes pas si difficile.
J’imagine Office 365 notamment Lync, Outlook et mes applications en mode ‘tablette’.

Il y a un tel potentiel pour des tablettes professionnelles.

Rêve terminé : je me replonge dans le SDK d’Android et je révise mon Java.
 
Qu’est-ce qu’il leurs est arrivé ?

vendredi 29 juillet 2011

Documentation des principaux scénarii de déploiement avec WebDeploy

Préambule : Ce post est la traduction d’un autre post de Vishal Joshi Senior PM chez MSFT, à qui l’on doit le web-deploy et qui, dans cet article, nous expose les différents scénarii que son équipe vont traiter dans les tutoriaux et procédures à venir sur le sujet.

Le « Nous » employé dans la suite les concernent donc, et pas moi ;)

L'outil IIS Web Deployment (Déploiement Web) et le déploiement de fonctionnalités introduites dans Visual Studio 2010 permettent d'automatiser de nombreuses tâches de déploiement, mais nous savons que de nombreux scénarios courants ne sont pas encore pleinement documentés.
Nous nous attaquons à ce besoin en créant  une procédure pas-à-pas qui vous guidera du début à la fin, par des scénarios qui couvrent des besoins du monde réel.
Notez-bien que ce blog n'est pas une documentation proprement dite mais une aide sur des problèmes réels.
Ce post présente une première série de scénarios que nous avons identifiés et nous sollicitons vos commentaires pour nous aider à déterminer qu'elles sont assez représentatives ou non.
Si vous avez des commentaires, vous pouvez les poster sur le blog de Vishal  ou n'hésitez pas à lui envoyer un email à Vishal.Joshi @ Microsoft.com (in English of course).
Let’s go

Scénario 1: déploiement en entreprise avec l'intégration continue
Dans ce scénario, il y a une solution, qui comprend de multiples projets d'application Web, est déployée sur  des environnements de  test, de staging et de production, en utilisant un processus d'intégration continue pour la staging et la production.

Environnements cibles
L'environnement de test  (TEST) se compose d'un serveur avec IIS 7.5 et un serveur avec  SQL Server 2008 R2. Les développeurs disposent d’un accès vers les serveurs de test, et les développeurs utilisent one-click pour déployer dans l’environnement de test.

L’environnement de pré-production (STAGING) consiste en une ferme de serveurs web (2 serveurs exécutant IIS 7.5) et un serveur de base faisant tourner SQL Server 2008 R2.
Le PC type des développeurs dispose d'une connexion  à accès à un serveur TFS qui sert de référentiel de code source, et ce serveur TFS a accès aux serveurs de pré-production (Les développeurs n'ont pas un accès direct à STAGING, et le développeur n'a pas de droits administratifs sur les serveurs de mise en scène).
Team Build génère la solution Visual Studio, exécute les tests unitaires, et publie sur le STAGING.
Chaque fois que Team Build effectue le  build et le déploiement, il crée simultanément un package de déploiement (un fichier web deploy .zip) qui est utilisé pour le déploiement en production.

L’environnement de production (PROD) est le clone du STAGING, sauf qu’un pare-feu (ou dans domaine différent) empêche l'accès direct pour la publication depuis le serveur TFS. Quand un build  est approuvé, le département IT utilise le package créé par le TFS.

Le schéma ci-dessous illustre ce scénario



Note : Certaines entreprises peuvent, en plus,  avoir un environnement ‘Assurance Qualité’  équivalent au STAGING, toutefois, pour les besoins de cette démonstration, nous n’inclurons pas cet environnement qui, de fait, est très similaire dans son déploiement au STAGING.

Solution ‘Visual Studio’
La solution Visual Studio  devant être déployée,  est constitué de plusieurs projets d'application Web, un projet de bibliothèque de classe, et un projet de test unitaire. Le déploiement doit prendre en compte les considérations suivantes:
  • Un des projets utilise la fonctionnalité ASP.NET membership, et la base de données ‘Membership’ doit être déployée. Ceci ne concerne que le TEST, il ne sera pas déployé sur le STAGING et le PROD.
  • Un des projets utilise une base de données SQL Server qui est accédée via l'Entity Framework (Méthode « Database first », en utilisant un fichier. Edmx). Pour le déploiement initial, pour n'importe quel environnement, seule la structure de la base de données doit être déployée. Pour les suivants, les données déjà saisies en ligne dans cet environnement doivent être préservé.
  • Le projet de bibliothèque de classe crée un assembly pour un contrôle personnalisé qui est utilisé dans l'un des projets. Cette assembly doit être installée dans le GAC dans le cadre du processus de déploiement.
  • Le contrôle personnalisé récupéré une valeur par défaut dans un registre Windows. La valeur de Registre est différente pour chaque environnement et elle est mise à jour lorsque la solution est déployée (Cette utilisation particulière des paramètres de registre n'est pas commune, mais la mise à jour d’un registre est un assez commune, et cela fournit un moyen simple d'intégrer une mise à jour du registre dans le scénario).
  • Le fichier Web.config contient des paramètres qui doivent être différents pour les versions debug et release, et les paramètres doivent être différents pour chaque environnement cible.
  • Un des projets web contient un dossier pour les fichiers Logs. Le processus de déploiement ne doit pas copier ces fichiers et ne doit pas supprimer ces fichiers du dossier sur le serveur cible.
  • Les paramètres IIS de la  gestion d’erreurs et d'authentification doit être mis en place sur le serveur cible pendant le déploiement. Ces paramètres peuvent être identiques pour TEST et sur l'ordinateur du développeur, mais ils sont différents pour STAGING et PROD.

Quelques considérations supplémentaires sur le déploiement s'appliquent uniquement au déploiement automatisé de TFS pour STAGING et PROD :
  • Le déploiement ne devra se produire que si les tests unitaires sont réussis.
  • Les projets Web doivent être précompilés avant le déploiement.
  • Les paramètres IIS pour STAGING et PROD sont issus de l'IIS du serveur TFS. (Ceci est une limitation de la version actuelle de Visual Studio et Web Deploy; quand ce problème sera réglé pour la prochaine version du logiciel, nous espérons nous passer du TFS pour la config IIS (croisons les doigts)
  • App_offline.htm doit être mis en place au début du déploiement et retiré à la fin.
  • Le déploiement doit être loggé (journalisé). Lorsque le déploiement se termine ou échoue, les notifications doivent être envoyées par courriel aux destinataires désignés.
  • Si le déploiement échoue, le package précédent doit être redéployé, ou le déploiement actuel devrait être réessayé.
Illustrations
Les  procédures pour ce scénario se font au travers des tâches suivantes : 
  • Téléchargement de la solution Visual Studio à déployer.
  • Mettre en place le serveur de test.
  • Utilisation de publication en un clic à déployer des serveurs de test:
  • Le déploiement initial.
  • Redéploiement sans un changement de bases de données (par exemple, une mise à jour du code dans une page Web).
  • Redéploiement après avoir fait un changement de schéma de bases de données.
  • Mise en place des serveurs STAGING  et de PROD.
  • Mise en place du serveur de build.
  • Trois déploiements sur STAGING (initial, avec  changement de page web, avec  changement de bases de données).
  • Trois des déploiements sur PROD (initial, avec changement de page web, avec changement de bases de données)
Pour la version de Visual Studio 2010, les mises à jour de bases de données impliquent d’exécuter des scripts SQL dans le cadre du déploiement.

Ces scripts seront créés manuellement; outils tels que TSData et Red Gate (pour les français : PowerAMC) peuvent être utilisés pour générer ces scripts, mais ces outils ne seront pas couverts dans ces procédures. Eventuellement, nous nous pencherons sur ce flux également.

Scénario 2: déploiement en entreprise pour MVC et Entity Framework Code First
Ceci est une variante du premier scénario qui diffère sur :
     
  • Les projets web sont MVC lieu de l’asp.net standard.
  • Entity Framework Code First est utilisé au  lieu du « Database first » (pas de fichier .Edmx).
  • TeamCity  est utilisé en lieu et place de TFS.

Scénario 3: déploiement en entreprise pour les projets de site Web
Une autre variante du premier scénario avec comme différence :

  • Les projets Web  sont des sites web (dans le sens du type de projet VS2010) au lieu d’être des applications web ou MVC.
  • Web Deployment Projects (WDP 2010) sont utilisés.
  • One-click n'est pas disponible pour des projets de site web, donc nous utiliserons  un package de déploiement pour le déploiement sur TEST.
Conclusion
Pour ceux d'entre vous qui travaillez dans des entreprises, ces scénarios vous semblent-ils bien représenter le genre de challenge que vous rencontrez lors des déploiements des applications ASP.NET Web?  Y a-t-il des éléments qui manquent ?
Nous ne pouvons pas répondre à toutes les questions dans ces procédures, mais s'il y a d'autres problèmes que vos équipes rencontrent couramment, nous pouvons les ajouter dans ces procédures.
Vos suggestions et vos commentaires sont les bienvenus.

jeudi 28 avril 2011

My method : a Task driven and scored method


Pragmatic Task-driven & scored method

Historic

For years, I have used a pragmatic method for producing software in small companies with small teams.

In this context, I always wore many hats: product manager, project manager, R&D manager and lead senior programmer. In this post, I resume these roles as a "manager", a multi-hats manager, capable of multitasking...

Without a lightweight and self-propelled system, it would have been very difficult to do my job.

More than an "innovative and revolutionary" method, it's rather a blend of good practice and pragmatism. It is mainly based on the classic "Agile Methodology", but adapted to very versatile "mini-teams".

With a lot of different roles tp juggle, I had to make choices and fix priorities.
It is not the quantity of work that determines the success of a project: it’s the quality of the work, the organization, the commitment of its team and passions for the product.

In various management roles, I overlooked features kept only the essentials:
·         Product manager: inspired by Agile Method, no big and formal requirement, just short and explicit specifications, the famous "user stories"
·         Product manager: no planning, just cutouts of "user stories» in tasks, and priority estimations. These tasks allow a self-management by the team, headed by the tasks and priorities, but without imposed order.

Task-driven & Task-centric

The Tasks

My method is based on tasks and autonomy of the team and its members.

The key is the possibility or rather, the duty of developers to choose the tasks they want to realize, according to their inspirations, their skills, their moods or their ambitions.

Having a choice in the selection of tasks gives great autonomy to team members and allows them to adjust their efforts and aspirations in order to achieve greater productivity.

When developer choses his own job, he does it according to some criteria:
·         Its relevance to the topic of the task:
"Look, this task looks interesting; it's really in my skills"
Example +: good expertise on the topic => good productivity and satisfaction
Example -: challenge may fail=> poor productivity and loss of confidence

·         The state of fatigue and motivation:
« I am very tired this week, I'll do all spelling corrections and forms alignment »
Example +: choice of short and fast tasks => remaining productivity
Example -: confinement in a long task without the requisite skills => decreased productivity

In order for a developement team to achieve the goal of delivering high quality software within the given delay. The ability of team member to express their free will within the organization can help preserve high productivity and positive motivation, despite long work hours or other organizational issues.

In this context, the manager can (I would even say should) assign himself tasks, and assign the score to the team, thus the manager plays a support role to his team.

Scheduling

It does not exist as such. Only a few milestones are fixed.
As I use Agile principles, my milestones are end sprint and end of the release dates.

I don't know whahat project respects its deadline just because it was scheduled, but rather because the project team was mobilized on a clear and shared goal: the deadline.
The detailed planning of all tasks is often a way for all stakeholders in the project to reassure themselves.
To borrow a citation from Reworks: « Planning is guessing ».

The manager's role is to lead and motivate the team to keep those deadlines.
But above all, its role is to properly quantify the number of tasks and difficulties in order to "fit" in the sprint or release.
The realism in the estimation of labor to provide is a key point of the job of manager of development team.

«I think I know what I'll do this week, but what imponderables will fall on me and change my beautiful schedule? »

Let's move on, since I'd much rather talk about targets, and goal dates.

The Goal: Little Reminders

The goal of every development team is:

To deliver high quality software within a set period of time

Only reach the goal, reach objective, and for that alone the motivation, mobilization around the goal are the keys.

Even though autonomy via choice and the exercising of free will are the basis of this method, the manager must be able to assign and impose choices and decisions to team members to benefit the project, and especially with the objective of achieving the goal.

How do you reach the goal? Finishing and testing all tasks. Everything evolves around the tasks.

So despite a form of self-management for developers, the manager is still the manager.

New feature: the Score

Why a Score?

My idea is that the motivation of team members can be animated and boosted by providing them with a score per a given period (week, month, release, sprint, etc... according with the organization).

"My method" has its limitations, particularly due to the lack of measures of performance and evaluation of team members. And without indicators, there are no axes for improvement, thus no proactive detection of malfunctions.

The idea of scoring induces a small degree of competitivity that can stimulate a team, help it to advance.

Score using

By team

A minimum average score (MAS) per team member is given. A minimum score to be achieved should also be set to encourage teamwork.

The ideal is to set a reward for each MAS reached, individual and collective, thus rewarding individual effort and collective efforts. This difference between "individual" and "collective" is important; a member who provides great efforts and obtains a good score shouldn't to be penalized by the poor performance of the team.

On the other hand, if the overall, team productivity was good, everyone should be rewarded so that nobody feels excluded, even if an individuals on the team wasn't as involved as other in the effort achieved.

At the end of each period, an analysis of the worst score should be made ​​in a positive spirit.
It is necessary to rule out "bad scores”, low scores obtained because of personal or external factors (eg sick = bad score)
.

By the manager

It helps to estimate tasks.
The score is very similar to the velocity (based on points of Agile user-stories), and therefore allows its use for planning sprints and releases.

Score Definition

The score of a task is the result of a calculation based on criteria. It is used to tell developers how many points they will win in performing those tasks.
There are three criteria with three values ​​that determine the score of the task.


Expert level:

Easy= 1, Normal=3, Hard=5

Task duration:

Short=1, Normal=3, Long=5

Task priority:

Low=1, Normal=3, High=5

Subjectivity in the evaluation.

Though it exists it is limited due to the low number of choices and task choice's transparency. In case of disagreement, the choices should be debatable by all team members and at any time of the process, even when it is completed. Most important thing is that this disagreement is motivated.
Exceptionally, like the "planning poker", the "scoring" can be collective, by imitating the same method as the "planning poker".

What’s next

Some tools

I haven't found a tool for management based on the scores. For the task-driven management, a number of tools are avalaible and I've only used or evaluated:
TFS, Mantis, Jira and the very promising Asana

My Choice  : TFS

I find that the integration of TFS and Visual Studio on the wholes makes a formidable platform for productivity and efficiency.
What I also like in the TFS is the idea of being able to relate the code "WorkItems" including archiving (check-out), which is an aspect I beleive is lacking in Mantis.

TFS is a very good source controller but the management of "WorkItems"is not adapted to managing with task-driven method and it does not handle scoring, so I'm working on a web interface and a "process template" which will correlate well with my method of work.

That’s what the project ScrumPilot is about

ScrumPilot

ScrumPilot's initial idea was to create a simple, more user-friendly dashboard than those that exist.
Stitches in time, I have added read-only "workitems, projects and users" features.
At this point, with my best understanding of the TFS API facetious and with a little elbow grease, I should be able to make a mix between Mantis and Asana, TFS, my method and my scoring to give a "small agile teams focused on tasks" varnish to the TFS



There will be another more detailed article when I will make progress on it.

Ma méthode : un exemple de "Task-Driven"


Historique

Depuis des années, j’utilise une méthode pragmatique pour la réalisation de logiciel, au sein et à destination de petites entreprises et avec des petites équipes.

Dans ces contextes, j’avais toujours plusieurs casquettes : chef de produit, chef de projet, responsable R&D, programmeur senior.
Dans la suite de ce document, je résumerai ces rôles au titre de « manager », un manager multi-casquettes, multitâches…

Sans un système léger et automoteur, il m’aurait été très difficile de m’en sortir.

Plus qu’une méthode « innovante et révolutionnaire », il s’agit plutôt d’un assemblage de bonnes pratiques et de pragmatisme. Elle a comme base principale la classique « Méthode agile » mais adapté à des « mini-équipes » très polyvalentes.

Ayant beaucoup de rôles différents, il m’a fallu faire des choix, établir des priorités.
Ce n’est pas la quantité de travail qui détermine la réussite d’un projet mais plutôt sa qualité, son organisation, l’engagement de son équipe et sa passion pour le produit.

Dans les différents rôles de management, j’ai fait l’impasse sur un certain nombre de fonctions pour n’en garder que l’essentiel.
·         Chef de produit : inspiré par l’agile, pas de cahier des charges à rallonge, juste des spécifications explicites courtes, les fameuses « user stories » (au final, leur addition donne un cahier des charges, mais à postériori).
·         Chef de projet : pas de planification, juste des découpages de « User stories » en tâche et des estimations de priorités dans celle-ci. Ces tâches permettent une autogestion de l’équipe de développement, dirigée par les tâches et leurs priorités, mais d’ordre imposé.

Tasks-Driven & Task-Centric

Les tâches

Ma méthode est basée sur les tâches et sur l’autonomie de l’équipe et de ses membres.

Le point principal est la possibilité, ou plutôt l’obligation des développeurs de choisir eux-mêmes les tâches qu’ils souhaitent réaliser, selon leurs inspirations, leurs compétences, leurs humeurs ou leurs ambitions.

Le libre choix des tâches donne une grande autonomie aux membres de l’équipe et leur permet de moduler leurs efforts et aspirations dans un but d’obtenir une plus grande productivité.

Lorsqu’un développeur choisi lui-même sa tâche, il va le faire selon certains critères principaux:

·         Son intérêt pour le sujet de la tâche :
« Tiens cette tâche à l’air intéressante, c’est vraiment dans mes cordes »
Exemple + : bonne expertise sur le sujet => bonne productivité et satisfaction
Exemple - : Challenge qui peut rater => mauvaise productivité et perte de confiance

·         Son état de fatigue et/ou de motivation :
« Je suis crevé cette semaine, je vais me faire toutes les corrections d’orthographe et d’alignement »
Exemple + : choix de tâches courtes et rapide => maintien de la productivité
Exemple - : Enfermement dans une tâche longue (défaut du concept ‘longue’) => baisse de la productivité

Dans l’optique d’atteindre le but de toute équipe de développement : Livrer un logiciel de qualité dans le délai fixé, le libre-arbitre dans l’organisation individuelle permet de conserver une bonne productivité et une bonne motivation quelque que soit l’état d’esprit et de fatigue du développeur.

Dans ce contexte, le manager peut (je dirais même : doit) lui-même réaliser des tâches, son  score est affecté à l’équipe.
Le manager joue un rôle de support auprès de son équipe.

Planification

Elle n’existe pas en tant que tel. Seuls quelques jalons peuvent être posés.
Comme j’utilise les grands principes de la méthode Agile, mes jalons sont les dates de fin de sprint et de fin de release.

Je ne connais pas de projet qui respecte son délai parce qu’il a été planifié, mais parce que son équipe s’est mobilisé sur un objectif clair et collectif : le délai.
La planification détaillée de toutes les tâches est souvent une façon pour tous les acteurs autour du projet de se rassurer.
Pour reprendre une citation de Rework : « Planifier, c’est deviner ».

Philippe Limantour, en lisant ce document m’a fait les remarques suivantes :
« Sur des projets de développement plus lourds je ne partage pas trop l’avis tranché sur le fait qu’un projet planifié ne tient pas ses délais.
La clef selon moi – expérimentée sur des projets de développement avec des équipes de plusieurs dizaines de développeurs, et des roadmaps de 6 mois avec un maximum de 5 jours de retard – réside dans le travail de préparation. Une très bonne analyse marketing détaillée dans un livrable de: ‘que veut le client’, ‘comment le fait-on technologiquement’, ‘quels choix in/out dans la prochaine roadmap’ est une clef du succès Ce travail est mené par une personne dédiée, en collaboration avec le chef de projet en charge de l’équipe de développement, et avec l’équipe commerciale. Une fois calé ce document, on n’en sort pas. Et un responsable qualité à temps plein a contribué à mettre en place, et à suivre, les processus qui permettent de suivre ce cadre qui a pour but de délivrer les fonctionnalités majeures attendues par les clients, en temps et en heure. »

Le rôle du manager est d’animer et motiver l’équipe pour tenir ces dates.
Mais, surtout, son rôle est de bien quantifier le nombre de tâches et leurs difficultés pour qu’elles « rentrent » dans le sprint ou release.
Le réalisme dans l’estimation du travail à fournir est l’un des point-clefs du métier de manager d’équipe de développement.

« Je pense savoir ce que je vais faire cette semaine, mais quels impondérables vont me tomber dessus et changer tout mon beau planning ? »

Je préfère largement parler d’objectif, et de dates d’objectif.

Le but : petits rappels

Le but de toute équipe de développement est de:

Livrer un logiciel de qualité dans le délai fixé

Seule l’obtention du but, de l’objectif compte, et pour cela, seule la motivation, la mobilisation autour du but compte.

Même si, le choix, l’autonomie et le libre-arbitre sont les bases de cette méthode, le manager doit pouvoir assigner et imposer ses choix et décisions aux membres de l’équipe dans l’intérêt du projet et, surtout, dans l’objectif d’atteindre le but.

Comment atteint-on le but : en terminant et en testant toutes les tâches. Tout tourne autour des tâches.

Malgré une forme d’autogestion des développeurs, le manager reste le manager, il est le garant du résultat final.

Nouvelle notion : le score

Pourquoi un score

Mon idée est que la motivation des membres de l’équipe peut être animée et aiguillonnée par le score qu’ils réalisent sur une période donnée (semaine, mois, release, sprint, etc… selon l’organisation choisie).

« Ma méthode » a ses limites, notamment dû au manque de mesure et d’évaluation des membres de l’équipe. Et sans indicateur, il n’y a pas d’axes d’amélioration, pas de détection proactive des dysfonctionnements.

Cerise sur le gâteau, l’idée de score induit un petit esprit de compétition que peut émuler une équipe, la faire progresser et être, par exemple, le support à de mini évènements.

Utilisation du score

Par l’équipe

Un score minimum moyen (SMM) par membre de l’équipe est fixé. Il faut également fixer un score minimum pour l’équipe afin de créer un esprit d’équipe.

L’idéal est de fixer une récompense pour SMM atteint, individuels et collectifs, récompensant en cela l’effort individuel et les efforts collectifs. Cette différence « individuel/collectif » est importante, un membre qui fournit de gros efforts et obtient un bon score n’a pas à être pénalisé par le piètre résultat de l’équipe.
A l’inverse, si globalement, l’équipe a été bonne, tout le monde doit être récompensé afin que personne ne se sente exclu, même s’il n’a pas vraiment  participé à l’effort collectif.

A chaque fin de période, une analyse du plus mauvais score doit être faite, dans un esprit positif, afin d’aider le membre de l’équipe qui l’a obtenu. Pourquoi ne pas utiliser la technique des 5 pourquoi pour faire cette analyse ?
Il est nécessaire d’écarter des « mauvais scores », les scores bas obtenus à cause d’éléments extérieurs ou personnels  (ex : absence pour maladie = mauvais score, mais l’équipe n’y peut pas grand-chose).

Pour le manager

Il aide à l’estimation simple des tâches.
Le score est très comparable à la vélocité (basée sur les points des user-stories), et permet donc son utilisation pour la planification des sprints et des releases.

Définition d’un score

Le score d’une tâche est le résultat d’un calcul basé sur des critères prédéfinis. Il sert à indiquer aux développeurs le nombre de points qu’il va gagner en réalisant cette tâche.
Pour rester simple, il n’y a que trois critères avec trois valeurs qui déterminent le score de la tâche.

L’expertise :

Facile= 1, Normal=3, Expert=5

La longueur de la tâche :

Courte=1, Normal=3, Longue=5

La priorité :

Non-urgent=1, Normal=3, Urgent=5

Subjectivité de l’évaluation.

Elle est réelle, mais elle est limitée par le faible nombre de choix et la transparence des choix. Les choix doivent être discutables par n’importe quel membre de l’équipe en cas de désaccord, et à n’importe quel moment du process, même quand il est fini. L’important est que ce désaccord soit motivé.
Dans de rares cas, à l’instar du « planning poker », le « scoring » peut-être collectif, en reprenant la même méthode que le « planning poker », mais cette méthode doit rester l’exception.

Le futur en conclusion

Les outils utilisables

Ils n’existent pas encore d’outil utilisable tel quel pour la gestion basée sur les scores. Pour le task-driven, beaucoup d’outils sont utilisables, je ne vais citer que ceux que j’ai utilisés ou évalués.
Team Foundation Server, Mantis, Jira et le très prometteur Asana

Le choix de TFS

Je trouve que l’intégration TFS/Visual Studio qui fait de l’ensemble une plateforme redoutable de productivité et d’efficacité.
Ce que j’aime également dans TFS, c’est l’idée de pouvoir lié le code aux « Workitems » et notamment les archivages (check-out), c’est ce qui me manque dans Mantis, une ou des références sur des bouts de code pour mieux expliquer des spécificités/tâches techniques.

TFS est un très bon contrôleur de source mais la gestion des « Workitems » n’est trop adaptée à une gestion Task-driven et ne gère pas les scores, c’est pourquoi je travaille sur une interface web et un « process template » qui va bien coller avec ma méthode de travail.

D’où le projet ScrumPilot.



ScrumPilot

L’idée initiale de ScrumPilot était un simple tableau de bord plus vivant et plus visuel que celui qui est offert.
De fil en aiguille, j’en suis venu à lui ajouter des fonctions de lecture de « workitems », projets, utilisateurs.
Et de me dire, qu’avec tout cela, ma meilleure connaissance de la facétieuse API de TFS et un peu d’huile de coude, je devrais pouvoir faire un mix entre Mantis/Asana, TFS, ma méthode et mes scores, pour donner un vernis « petite équipes agiles centrées sur les tâches »

Il fera l’objet d’un autre article plus détaillé quand je l’aurais peaufiné.