Archives de catégorie : Team Leadership

image

Ce que SCRUM nous apporté : Gestion des problèmes

Qu’est-ce que t’as apporté SCRUM depuis que tu l’as mis en place ?

Cette question m’a été posé lors d’un des derniers évènements auquels j’ai pu participer et je dois bien avouer que j’ai eu du mal à formuler une réponse exhaustive tant le nombre d’avantages apporté par notre mise en place de SCRUM est important.

Au lieu de faire un post à rallonge indiquant tous les bénéfices que nous avons pu tirer de cette mise en place, je vous propose une série de posts sur différentes thématiques.

Première thématique abordée :

La gestion des problèmes

C’est une problèmatique simple qui doit être la base de toute démarche d’amélioration, mais qui m’a géné et ennuyé dans la plupart de mes expériences passées.

Chacun d’entre nous a probablement vécu le “syndrome du poisson pourri”. Tout le monde a consience qu’il y a un ou des problèmes bien puant(s) mais personne ne le(s) remonte.

image

Plusieurs raisons peuvent expliquer cela, je vais citer ici ceux qui m’ennuient le plus, le “c’est pas à moi de dire ça” autrement dit le “je ne veux surtout pas prendre la responsabilité de dire ce que je pense”, ou une autre raison (plus excusable sauf d’un point de vue management) le sentiment de ne pas avoir la parole.

SCRUM propose un artefact particulier pour cette gestion des problèmes : les obstacles.

Le principe est très simple : l’équipe doit durant chaque sprint lever les obstacles rencontrés qui empêchent le bon déroulement du projet (ou son meilleur déroulement).

Chaque création d’obstacle doit être signalée lors des scrum quotidiens et sont discutés avec toute l’équipe lors de la rétrospective.

D’un point de vue progression de l’équipe, et amélioration de son autonomie, on peut citer les phases de maturité suivantes : dans un premier temps, le ScrumMaster détecte les obstacles et trouve la solution à ces obstacles, l’objectif étant par la suite (et assez rapidement) que l’équipe lève elle-même les obstacles en les identifiant et en les formulant correctement pour arriver ensuite à à la fois identifier les obstacles mais également à les résoudre seule.

La gestion des obstacles dans TFS 2012

Depuis TFS 2012, Microsoft recommande l’utilisation de SCRUM (il s’agit en effet du process template par défaut des team projects), et propose une gestion d’obstacle simple mais efficace. Le plus compliqué est de trouver le point d’entrée de cette gestion :

image

Les obstacles (impediment en anglais) sont exposés sous la forme d’un type de Work Item particulier qui permet de gérer cette liste avec des obstacles ayant deux états (ouvert et résolu).

image

Conséquences sur l’équipe

Conséquence inattendue lors de la première rétrospective, un des membres de l’équipe avait préparé une liste longue comme le bras avec l’ensemble des problèmes non pas qu’il avait rencontré durant le sprint, mais plutôt des problèmes qui lui courraient sur le ciboulot depuis quelques temps.

Plus sérieusement, chaque membre de l’équipe se sent plus impliqué et sait qu’il a la parole pour remonter et discuter ouvertement des problèmes rencontrés.

Il ne reste plus qu’à arriver à trouver régulièrement ensemble les solutions à ces problèmes afin d’avoir une équipe qui progresse régulièrement et qui ne stagne pas.

image

Les vidéos de l’ALM Summit sont disponibles

image

Les vidéos de l’ALM Summit 3 qui a eu lieu du 28 Janvier au 1er février au conference center de Microsoft à Redmond sont disponibles sur Channel 9 :

http://channel9.msdn.com/Events/ALM-Summit/ALM-Summit-3

Les sessions de ce summit sont organisées autour de 4 tracks :

Je vous recommande de passer un peu de temps à consulter les enregistrements de certaines de ces sessions, elles sont très souvent d’excellente qualité.

Je n’ai pour ma part pas encore eu le temps d’en visionner la majorité d’entre elles, mais je reviendrais vers vous lorsque cela sera le cas afin de vous recommander celle que j’ai trouvé les plus pertinentes.

image_thumb.png

L’incompétence des développeurs

Il y a un peu plus d’un mois je m’étais décidé à répondre au post “On a besoin de stars pas de managers”.

Romain David, co-fondateur de la startup Balloon y explique son désarroi face au grand nombres de développeurs qui ont comme objectif de :

ne pas rester éternellement développeur, mais devenir chef de projet

 

Ce qui dans le cas d’une startup est pénalisant puisque la société recherche des profils techniques pointus, autonomes, capables d’apporter une vraie valeur ajoutée par rapport à des “pisseurs de code” classiques.

La raison de ce désamour du métier de développeur qui incite à devenir chef de projet est selon moi identique à la raison pour laquelle les développeurs ont une mauvaise image.

Et cette raison est simple :

une très grande majorité des développeurs est incompétente

 

Je vous parlais il y a peu des 3 stades de maturité d’une équipe de développement, le problème est que selon mon expérience environ 75% des équipes (et donc des développeurs et chefs de projets) sont dans la phase du chaos, 20% dans la phase intermédiaire, et 5% sont autonomes. (N’hésitez pas à confirmer ou infirmer cette estimation dans les commentaires).

Et pour illustrer cette incompétence je vais m’attarder sur le profil des développeurs .net. Une majorité n’a pas des connaissances de bases telles que :

  • Connaissances de bases sur la POO (expliquer clairement la différence entre une classe et un objet, les différences entre une classe abstraite et une interface, notions de base sur l’héritage, donner un exemple de design pattern, etc.)
  • Comment gérer les erreurs (définir les différentes stratégies de gestion des exceptions)
  • Savoir définir avec une phrase claire ce qu’est le framework .net et quels sont les services fournis par le CLR.
  • Maitriser ce qui n’a pas attrait à l’écriture de code et que Microsoft regroupe sur le terme d’ALM (gestion des sources, gestion des tâches/bugs, builds, tests, etc.)
  • etc., etc., etc.

Quand je parle d’incompétence je ne parle donc de non-maitrise de concepts et notions mais de non-maitrise des fondamentaux essentiels au bon déroulement d’un projet de développement.

Durant les entretiens techniques que je fais passer, j’en suis “réduit” à poser des questions ouvertes afin de juger du recul du candidat sur différentes technologies (compréhension des principes et de la philosophie d’une techno, description des avantages et des inconvénients de la techno), et de juger de sa compréhension du métier de développeur (recul par rapport au métier, description des difficultés du métier, et comment y pallier). Ceci pour estimer de sa capacité à rapidement arriver au 2eme stade de compétence décrit rapidement ci-dessus.

Le fabuleux destin du développeur

Fort de cette incompétence, le développeur tel un forçat va devoir s’efforcer d’essayer de rattraper (souvent en vain) ses propres erreurs, les erreurs de ses collèges développeurs, du chef de projet, et des commerciaux. Oublier la notion d’horaires de travail et prendre un soin particulier à bien entretenir sa nouvelle petite amie : la machine à café.

Le tout en devant :

  • expliquer pourquoi une fonctionnalité qui marchait correctement auparavant ne fonctionne plus à cause d’une modification qui n’a (en apparence) aucun rapport avec celle-ci
  • parvenir à justifier pourquoi il serait plus simple de refaire depuis zéro

qui pourrait être traduit par :

  • “ah bravo tu es tellement mauvais que quand tu touches une partie de l’application, tu en casses une autre“
  • “tu es tellement mauvais que pour faire une tâche tu dois t’y reprendre à plusieurs fois en recommençant à zéro“

image

Ainsi après avoir passé plusieurs mois à travailler sur des projets en sachant pertinemment que le développement réalisé était de très mauvaise qualité, et en se demandant pourquoi on lui avait explique que les frameworks et outils actuels rendaient la vie du développeur très simple (on m’aurait menti ?) il est compréhensible que celui-ci veuille prendre la responsabilité de chef de projet.

Une partie des développeurs voudront assumer cette responsabilité afin d’essayer d’améliorer les choses.
Bien évidemment, n’ayant pas reçu de formation de chef de projets, la probabilité d’arriver à réellement améliorer les choses est assez faible. Et ceux qui font l’investissement de faire une pause dans leur cursus professionnel afin de retourner à l’école et suivre une vraie formation de chef de projet suite à de mauvaises expériences vécues en tant que développeur, se font recaler pour leur manque d’expérience (cas d’un récent candidat qui recherche donc à présent de nouveau un poste de développeur…)

Une seconde partie de développeurs voudra devenir chef de projet non pas pour améliorer les choses mais pour ne pas à avoir subir toutes les erreurs du projet tout en ayant un meilleur salaire. Comme dans beaucoup de secteurs, c’est le salarié tout en bas de l’échelle qui subit le plus les conséquences des erreurs qui ont pu être commises. Il est donc plus confortable de monter d’un niveau, on ne sera pas plus compétent mais au moins on se tuera moins à la tâche. Et oui, dans le domaine du développement le développeur est considéré comme l’ouvrier préposé aux tâches répétitives. Après tout, du code ça reste du code non ?

Pour les développeurs qui ne souhaitent pas ou ne peuvent pas devenir chef de projet, plusieurs attitudes sont possibles. La plus courante est la résignation. Quand on a pleinement conscience de faire un travail de mauvaise qualité, soit on se rend malade en s’apitoyant sur son sort soit on prend du recul, de la distance, et on se détache petit à petit de son travail, en ne cherchant pas à s’impliquer et en renonçant totalement à essayer de faire changer les choses.

Je vous recommande la lecture de le post de Romain Verdier “Dégage sale programmeur ! ” qui décrit le problème avec infiniment plus de talent que moi.

Le métier de développeur est très complexe

Ce tableau assez noir n’est pas dû à la stupidité des personnes qui endossent le rôle de développeur (je pense que la majorité des développeurs est incompétente, je ne pense pas qu’ils sont stupides…) mais à la complexité du métier de développeur.

Un développeur doit posséder les compétences suivantes :

  • Etre avant tout un très bon “informaticien”. J’entends par là qu’il doit maitriser les notions fondamentales indispensables à la bonne utilisation et à la bonne exploitation de l’outil informatique. Maitrise d’un grand nombre de connaissances qui ne sont pas directement lié au développement (exemples : maitrise du fonctionnement d’un OS, de sa conception, de son architecture, sa gestion de la mémoire, maitriser la sécurité, savoir ce qu’est un process, un thread, maitriser la différence entre le 32 bits et le 64 bits, savoir ce qu’est une partition, savoir ce qu’est la virtualisation, connaitre les fondamentaux liés aux réseaux (ARP, DNS, IPV4, IPV6, MAC, etc.) etc., etc.)
  • Et après avoir acquis toutes ces connaissances “de base” sur l’informatique, le développeur pourra commencer à apprivoiser l’écriture de code et ceci via plusieurs langages puisqu’un seul ne suffira pas pour faire son métier (C#, VB, T-SQL, PL-SQL, XPath, Javascript, etc.). Il devra pour cela maitriser tous les fondamentaux de la programmation orientée objets, et découvrir par lui-même quelques bonnes pratiques qu’il n’a pas forcément ou pas correctement acquises durant sa formation. Puis au fil de son expérience devra comprendre en quoi consiste vraiment l’écriture de code (un code n’est pas figé et doit évoluer dans le temps = être maintenable, refactorisé et donc être testé, il doit de plus être géré via un source control (avec maitrise des concepts associés, checkin/checkout/label/shelve/merge, etc.).
  • Il devra également réellement comprendre en quoi consiste un projet de développement, le rôle et l’impact de chacun, et bien comprendre que développer ce n’est pas uniquement écrire du code.
  • Et bien évidemment comme l’informatique évolue très vite, une fois l’ensemble de ces connaissances acquises, le développeur doit être capable de les tenir à jour semaines après semaines en effectuant une veille technologique appropriée.

Bref, à mon avis un bon développeur se fait seul et n’apprends pas l’ensemble des concepts et notions qui feront de lui un développeur correct durant ses études (même après une école d’ingénieur). Cela nécessite un auto-apprentissage important (et donc un investissement personnel important) ce qui explique l’incompétence généralisée décrite au travers de ce post.

L’essentiel de la compétence d’un développeur s’acquiert via son expérience, il est nécessaire de réaliser que malgré toutes les compétences techniques qui ont pu (ou pas) être acquises durant les études, le métier de développeur nécessite de ne pas laisser tomber et de vraiment débuter à apprendre son métier lorsque l’on débute son expérience professionnelle le tout dans un contexte professionnel souvent très mauvais (mauvaise équipe de dév, mauvais chefs de projets, etc.)

Bon et bien évidemment, si vous pensez être dans les 5% évoqué ci-dessus ou même dans les autres 20%, je vous rappelle que je recherche du monde ! Clignement d'œil
(et maintenant vous connaissez certaines des questions que je pose durant les entretiens techniques…)

image

Les 3 stades de maturité d’une équipe de développement

Avec mon changement de métier en début d’année, j’ai naturellement enrichi ma liste de lectures avec des sites/blogs non techniques traitant du leadership d’équipes de développement.

Un des mes sites préférés dans ce domaine est le blog Five Whys de Roy Osherove et celui-ci identifie 3 stades de maturité d’une équipe de développement :

  • Le chaos : l’équipe ne possède pas les connaissances techniques fondamentales/de base/minimales nécessaires pour débuter à faire correctement les choses.
  • L’apprentissage : l’équipe possède certaines connaissances techniques ET non-techniques qui lui permettent de voir son niveau régulièrement s’améliorer
  • L’autonomie : l’équipe est quasiment autonome, et possède les connaissances nécessaires au bon déroulement d’un projet.

Vous pouvez vous référer à ce post ou encore à ces slides pour plus de détails sur ces stades de maturité.

image

Je n’avais jamais formalisé mon point de vue sur le niveau des équipes de dév. de cette manière avant d’avoir lu le blog de Roy Osherove, mais je suis entièrement d’accord avec ce découpage.

Et je trouve de plus qu’il permet d’expliquer énormément de choses concernant le monde du développement, et je vais m’attacher cette semaine à rédiger différents posts à ce sujet.

Stay tuned !