Négociation salariale

La semaine dernière j'ai assisté à une conférence organisée par les Mines de Nantes et Mines Nantes Alumni, animée par Vincent Frey et ayant pour sujet "La négociation salariale".

En bref : 

1. Ne cherchez jamais à avoir raison. Évitez le oui mais… Ces échanges ne joueront pas en votre faveur ;
2. Ne jamais argumenter. Il n'y a pas de juste prix. Fermez le clapet à votre esprit d'ingénieur, fixer un salaire n'a rien de rationnel ;
3. Ne jamais se justifier ;
4. Ne pas isoler le salaire. Toujours encadrer le salaire. Exemple : « J'ai cinq ans d'expérience, je veux _ k€ et je suis disponible à l'international ». À éviter absolument : annoncer un chiffre puis chercher l'approbation de votre interlocuteur ;
5. Au contraire, si le montant annoncé par votre interlocuteur ne vous convient pas, isolez le salaire. Laissez un blanc, faites le répéter ;
6. Vous devez pouvoir répondre du tac au tac à la question du salaire durant un entretien ;
7. Si le salaire que vous avez demandé est revu à la baisse, négociez une concession, même hypothétique. Exemple : d'accord pour le moment, mais on en rediscute dans trois mois ;
8. Vous n'aurez jamais rien si vous ne demandez rien.

Merci encore à Vincent Frey pour s'être déplacer, à l'École des Mines de Nantes et Mines Nantes Alumni pour l'organisation et une autre fois à Mines Nantes Alumni pour les bières :)

Outils du Product Owner pour maximiser le ROI

Mercredi dernier, j'ai passé la soirée dans les bureaux de Zenika pour assister à la conférence "outils du Product Owner pour maximiser le ROI" animée par Michel Goldenberg.

Malheureusement, car le sujet m'intéresse beaucoup, la discussion a divergé vers l'intérêt des estimations.

Ci-dessous, les exercices que Michel Goldenberg a eu le temps de nous présenter.

Comment arriver à une vision commune et obtenir un consensus ?

1. définir le sujet de questionnement ;
   
2. demander à chaque participant d'écrire sa réponse sur un post-it ;
3. former des binômes ;
4. demander à chaque binôme d'échanger leurs points de vue ;
5. demander à chaque binôme de noter, d'un commun accord, leurs deux post-its pour arriver à une somme de cinq (cinq étant la meilleure note i.e. la définition remportant l'adhésion des deux membres du binôme) ;
6. demander à chaque binôme d'échanger leurs post-its ;
7. réitérer l'exercice à partir de l'étape trois jusqu'à ce que les post-its aient le même nombre de notes que de participants ;
8. additionner les notes pour donner une note globale à chaque post-it.

La note globale d'un post-it révèle le degré d'adhésion des participants à ce qui est écrit dessus.

Durant cet exercice, nous avons vue se dégager un post-it particulièrement bien noté. Il s'agit du consensus.
Puis un peloton de post-its un peu moins bien notés. Il s'agit de la vision commune.
Et pour finir, deux post-its avec des notes très faibles. Il s'agit des visions marginales.

Comment déterminer l'intérêt d'une vision marginale ?

Les visions marginales ne sont pas nécessairement inintéressantes. Il est possible qu'elles soient seulement mal comprises. Pour répondre à cette question, nous avons utilisé l'exercice suivant :

1. demander à chaque participant de marquer physiquement son adhésion ou non à la vision marginale, par exemple en divisant la salle de réunion en deux ;
2. demander à une personne du groupe minoritaire, ceux adhérant à la vision marginale, d'expliquer son point de vue ;
3. demander à chaque personne du groupe majoritaire si les éclaircissements apportés lui fait réviser sa position ;
4. réitérer l'exercice à partir de l'étape deux jusqu'à ce que toutes les personnes du groupe minoritaire se soient exprimées ;
5. conclure en fonction des migrations entre le groupe majoritaire et le groupe minoritaire.

Comment interviewer un client ?

L'objectif de l'interview est d'aider le client à définir et prioriser son besoin. Le client doit être acteur de l'interview. L'interviewer n'est là que pour aider le client à structurer son expression de besoin.

1. demander au client d'écrire sur des post-its jusqu'à 5 fonctionnalités essentielles de son produit ;
2. demander au client de prioriser les post-its en répartissant 15 points, une note élevée indiquant une priorité forte ;
3. réitérer l'exercice jusqu'à atteindre la granularité souhaitée.
   

L'étape deux n'est pas toujours évidente. J'en ai fait l'expérience en mettant cet exercice en pratique le vendredi suivant la conférence. Le rôle de l'interviewer est alors de challenger le client pour qu'il sépare son besoin entre l'essentiel et le facultatif à force de questionnement.

Dernier conseil

Le PO doit également pousser l'équipe de développement à lui expliquer les stories ayant une forte complexité. Il pourra ainsi détecter les tâches ayant une forte complexité à cause d'un détail technique (e.g. : drag and drop, …). Le cas échéant, ils pourront étudier ensemble les alternatives envisageables.

Maximiser le ROI, c'est minimiser le travail inutile !

Séance d'estimation

Suite à des séances d'estimation s'éternisant sur le projet sur lequel je travail actuellement je suis venu à me poser des question sur cet exercice.

Pour quelle raison faisons-nous des séances d'estimation ? Je pense que les objectifs sont doubles :

• échanger afin d'avoir une vision commune sur les items du backlog ;
• estimer la complexité des items afin d'avoir de la visibilité sur l'avancement du projet.

Une fois ces objectifs bien en tête, vient la question suivante : Qui est concerné par cette réunion ? Toutes les personnes apportant des éléments permettant de clarifier la vision des items du backlog et toutes les personnes qui auront à réaliser ces items.

Maintenant, nous connaissons les enjeux et les acteurs de cette réunion. C'est bien, mais pas top. Les séances d'estimation ne sont pas plus efficaces. Pourquoi ? Retour aux définitions :

Estimation : évaluation approximative fondée sur des données incomplètes ou de nature imprécise.

Une estimation est une évaluation approximative !

Si votre équipe prend plus de 10 minutes pour se décider entre une complexité de 5 ou 8, je vous propose d'essayer la méthode décrite ci-dessous.

Les objectifs de la réunion étant double, découpons la réunion en deux temps :

1. comprendre les nouveaux items ;
2. estimer les complexités.

La compréhension des nouveaux items passe par la discussion entre les acteurs du projet. C'est le temps fort d'une séance d'estimation. La vision commune du projet issue de ces échanges facilitera les communications futures.

L'estimation des complexités est plus pertinente et plus rapide une fois que les items sont compris. Pour faciliter encore la démarche, j'aime procéder de la manière suivante :

1. imprimer les intitulés des items sur des cartes en papier ;
2. disposer ces cartes sur une table en fonction des complexités relatives ;
3. associer chaque groupes d'items à une complexité chiffrée.

Révision Scrum : le backlog produit

Le backlog produit est la liste des fonctionnalités du produit à développer. Chaque élément de cette liste est composé au minimum de trois attributs :

• une description sous la forme d'une user story ;
  
• une valeur métier ;
  
• un effort ou une complexité.
  

La finalité du backlog produit est d'avoir de la visibilité sur l'état du projet et de prioriser les développements.

Le backlog produit est de la responsabilité du product owner.

Valeur métier

La valeur métier d'un item est estimée par le product owner.

C'est la valeur métier des items qui doit diriger la priorisation des développements. Pour aider à la mise en perspective entre l'accessoire et le fondamental, il est conseillé d'utiliser la suite de Fibonacci en s'efforçant d'utiliser des valeurs très disparates.

Effort ou complexité

L'effort nécessaire à la réalisation d'un item est estimé par les personnes qui seront en charge de la réalisation. Cette valeur est fixe dans le temps.

Plus un effort est important, plus son estimation est imprécise. C'est pourquoi il est conseillé d'utiliser la suite de Fibonnaci pour estimer les efforts.

Métriques

Les métriques issues des données du backlog produit donnent de la visibilité sur l'état actuel du projet et aide à définir les prochaines étapes.

Le backlog produit est un outil évolutif (ajout, suppression, modification d'items). Par conséquent, il est souvent intéressant de suivre ces métriques en points et en pourcentage.

Ci-dessous, deux exemples de métrique que nous pouvons extraire du backlog produit.

Vélocité

La vélocité est l'effort qu'une équipe peut adresser en un sprint. Cette mesure s'affine au fil des itérations.

La vélocité ne doit pas être utilisé pour assurer le suivi de la productivité d'une équipe mais pour réaliser des projections (e.g. estimer la date de fin du projet). Une mauvaise utilisation de cette métrique entraine une inflation des points d'effort et/ou une "course à la vélocité" au détriment de la qualité.

Il est également déconseillé de comparer les vélocités de deux équipes du fait des estimations réalisées sur des échelles différentes. Les estimations sont relatives, pas absolues.

Par contre, il est intéressant de suivre l'évolution de la vélocité d'une équipe. Une diminution de la vélocité traduit souvent un manque d'évolutivité du produit développé ou l'apparition de nombreux bugs.

Valeur métier acquise

Cette métrique détermine la valeur des développements réalisés.

Si le backlog est correctement priorisé, l'évolution de la valeur métier acquise doit diminuer au cours des itérations car les items de plus grande valeur sont traités en premier.

Quelques liens

Dans SCRUM mon backlog de produit est DEEP
Le backlog produit
Des user stories de qualité
Valeur métier en pratique
Comment mieux prioriser en agile
Suite de Fibonacci

Révision Agile : ScrumMaster ? C'est quoi déjà ?

Cette semaine prochaine, le ScrumMaster du projet sur lequel je travaille sera en vacance. Étant donné que je vais assurer son remplacement, j'en profite pour réviser le rôle du ScrumMaster.

Alors, qu'est-ce qu'un ScrumMaster ?

Un facilitateur

L'une des missions du ScrumMaster est de s'assurer que les autres membres de l'équipe restent concentrés sur le véritable objectif du projet : la livraison de valeur pour le client.
Il écarte les obstacles qui jonchent le parcours menant à la livraison et si possible avant même qu'ils ne surviennent.

Un coach

Dans le processus d'amélioration continue, le ScrumMaster joue le rôle du coach.
Il aide l'équipe à prendre conscience de ses qualités et faiblesses. Puis il fait en sorte de conserver les acquis tout en travaillant les points faibles.

Un animateur

Il organise et anime les activités Scrum tel que sprint planning, daily Scrum, sprint review et rétrospective.
Il fait en sorte que tous les membres de l'équipe se sentent impliqué et libre de s'exprimer.
Autant que faire se peut, le ScrumMaster s'assure que tous les membres de l'équipe sont contents de travailler.

Le garant des pratiques Scrum

Un ScumMaster, comme l'indique son nom, a une bonne connaissance de Scrum. De par cette connaissance, le ScrumMaster s'impose comme le garant de la bonne utilisation des pratiques de Scrum.

Quelques liens

Le rôle de ScrumMaster
Peut-on à la fois être ScrumMaster et développeur sur un même projet ?
Mon ScrumMaster en fait trop !

Bépo ou le Dvorak Français

Hello,

Comme d'une le blog est un foil mort d'une part, et comme d'autre part j'ai la flemme de faire un post sur un comparatif de la gestion de la mémoire en Java et en C++, voici un post un peu plus simple à suivre. Il va parler de la disposition des touches sur un clavier.

L'origine du Qwerty (ou de l'azerty, vu les différences absolument négligeables entre les deux claviers, ça s'applique à l'un comme à l'autre) vient des machines à écrire. Le principal objectif était de faire un clavier qui tenait la route mécaniquement :

• Les balais qui relient les touches au caractère doivent tous rentrer dans le clavier. Ça explique pourquoi les touches sont décalées verticalement : le centre d'une touche n'est jamais aligné avec celui d'une autre touche.
• Les balais mettent un certain temps à redescendre. Le risque est donc qu'en actionnant deux touches à un faible interval de temps, les balais se coincent. Demandez à mon père, il pourra vous en parler. C'est pour minimiser ce rique qu'on a une telle organisation
• La légende dit que si on peut écrire Typewriter (sur un qwerty) en utilisant que la rangée du haut, c'est pour que les commerciaux puissent plus facilement impressionner les pigeons

Bien évidemment avec un clavier informatique (et déjà avec les machines à écrire électriques), ce genre de considérations n'a plus vraiment raison d'être. D'où un certain monsieur Dvorak qui a eu l'idée d'optimiser la disposition des touches.

Il existe une version française du Dvorak qui est le Bépo (d'après les 4 premières lettres). Cette disposition optimise :

• Les lettres les plus utilisées sont sur la rangée centrale (position de repos en frappe à l'aveugle)
• Alternance de la frappe main droite — main gauche
• Digrammes et trigrammes : essayez de taper (sur un azerty) LKJ et JKL, vous verrez que dans un sens ça sera plus facile
• Possibilité d'écrire en français : les caractères œ, «, » et les accents en majuscules (ÉÀÇÈ) sont indispensables si on ne veut pas faire de faute d'ortho-typographie

L'intérêt de tout ça c'est

• Plus grand confort lorsqu'on frappe (ça a l'air con, mais c'est bluffant)
• Moindre risque de se faire mal (articulations qui font mal, tout ça)
• Moins de fautes de frappe
• Accessoirement, au bout d'un certain temps, pour certains, une plus grande vitesse de frappe
• Caractères plus accessibles pour le dev
• Gain même dans d'autres langues comme en anglais
  

Comment ça s'apprend ? Là il n'y a pas de solution miracle. Il faut s'y mettre exclusivement au Bépo, imprimer le layout et le mettre à coté de l'écran. On peut faire des exercices (y'a plein de programmes qui proposent de faire des gammes). La seule connerie à ne surtout pas faire c'est de mettre des étiquettes sur le clavier. En effet la méthode n'a d'intérêt que si on tappe à 10 doigts. Les étiquettes vont donc uniquement ralentir l'apprentissage. Si vous ne tapez pas à 10 doigts, c'est l'occasion rêvée de vous y mettre !

• Au bout d'une journée : vous connaissez la disposition de toutes les lettres
• Au bout d'une semaine : vous êtes suffisemment à l'aise pour dire des conneries sur irc
• Au bout d'un mois : vous n'avez pas encore rattrapé votre vitesse initiale en Azerty, mais vu le gain en confort, pour rien au monde vous voudriez y revenir
• Au bout d'un an : vous explosez votre vitesse de frappe en Azerty

Voilà ! Tout est dit :) pour plus d'informations, allez sur le site web officiel : http://www.clavier-dvorak.org/

Merci pour votre intérêt, et si vous avez des questions je me ferrai un plaisir d'y répondre. N'oubliez pas que le but est que tout le monde parle un peu de tout, y compris de conneries qui seraient arrivées au boulot, de trucs d'omtis, de trucs intéressants, etc.

Et pour vous convaincre de l'intérêt, regardez cette vidéo :

Azerty vs bépo
envoyé par tiot10

Le Paris JUG a 1 an

Ce soir le Paris JUG fêtait son premier anniversaire dans une ambiance chaleureuse.

Quelques chiffres sur l'année passée :

• Un public composé majoritairement de développeurs seniors et d'architectes ;
  
• Le site Web compte 15000 visites pour les 7 derniers mois (majoritairement d'île de France).
  

A suivi un quicky d'un quart d'heure sur Wicket parTarik Filali Ansary.
Wicket m'a semblé être un framework recherchant des objectifs similaires à GWT : simplifier la vie des développeurs Java pour la création d'application Web.
Rien n'est plus explicite que quelques exemples.
De plus Wicket semble jouir d'une communauté très active : Wicket Stuff, Wicket Library.

Par la suite, nous avons pu nous rendre compte combien les JUG florissent en France. En effet, cette session avait pour invités d'honneur des représentants de tous les JUG français : Christophe Jollivet (Tours JUG), Xavier Hanin (Bordeaux JUG), Nicolas Leroux et Stephane Epardaud (Riviera JUG), Nicolas de Loof (BreizhJug), Sebastien Roul (Nantes JUG), Christophe Meyer, JM Doudoux et Xavier Roy (Lorraine JUG), Gaël Blondelle (Toulouse JUG), Julien Ripault et Cédric Exbrayat (Lyon JUG).

Puis Christian Frei a présenté Jazoon09 de manière très dynamique.

Ce fut ensuite le tour de Stephan Janssen avec pour sujet Parleys.
J'avais déjà assisté à la présentation de la version Flex de Parleys durant JavaPolis07 mais je ne pense pas me tromper en disant que Stephan a eu beaucoup d'effet sur l'assemblée de Juggers en présentant les versions prototype JavaFX et surtout GWT !
Pour la partie moins fun, Parleys proposera bientôt des espaces professionnels pour poster des présentations. Ces espaces seront gratuits pour les JUGs.
Pour finir, Stephan a continué d'envoyer la purée en présentant l'outil de post-processing vidéo qu'il a développé (avec Adobe AIR) pour traiter les enregistrements des conférences Devoxx.

Pour la présentation de Java SE 7 Dolphin, ... et bien, j'étais en train de me faire masser donc je n'ai pas pu prendre de notes ! D'ailleurs merci aux masseurs et aux organisateurs du Paris JUG, c'était un très bonne idée, et toutes mes excuses à Thomas Chamas.
Par contre je me souviens en avoir entendu parler durant une keynote de Devoxx08.

Le dernier quicky traitait de l'état de l'art et de l'utilisation de Java dans les jeux vidéo par Julien Gouesse.
J'avoue qu'il m'a bluffé. Je ne savais pas que des jeux développés en Java était commercialisés même s'ils se comptes sur les doigts.
Pour les personnes intéressés par ce genre de développement, le code source du doom-like TUER développé par Julien est dispo ici.