Newsroom

Du code et des hommes- Stratégies de suivi de projet

J'ai terminé un livre formidable, intitulé "Du code et des hommes- Stratégies de suivi de projet" de Steve Maguire. Ce livre explique de façon simple et extrêmement pratique quelles règles mettre en place pour gérer les projets de façon plus efficace. Et "étonnamment", cette gestion plus efficace rejoint aussi une gestion plus humaine.

Steve Maguire, il faut le préciser, a lui-même été développeur puis chef d'équipe chevronné chez Microsoft. Il a donc été pour ainsi dire des deux côtés de la barrière et cherche systématiquement à alléger le travail du développeur et lui faire retrouver sa passion pour son métier tout en donnant une nouvelle vie au projet. Son livre est ponctué d'anecdotes puisées dans son expérience personnelle, qui participent à sa richesse et sa facilité de lecture.

Je vais essayer, plus pour mémo j'avoue, d'en faire un petit résumé, mais croyez-moi: achetez-le et lisez-le, c'est passionnant.

Le livre est séparé en 8 chapitres, le résumé global serait quelque chose comme: ce n'est pas avec plus d'heures de travail qu'on résout des problèmes de délai, c'est avec plus d'efficacité, donnez à vos développeurs le temps bien travailler, de l'entrain pour leur travail, et ils redeviendront les moteurs du projet.

Mais c'est un résumé extrêmement fade, et Steve Maguire rentre bien plus dans les détails, j’ai donc regroupé plusieurs règles par sujet pour tenter de retenir quelques règles indispensables:

 

Préparation du projet :

  • établir des objectifs spécifiques au projet
  • établir de priorités de code (maintenance, portabilité, sécurité)
  • utiliser les rapports d’autopsie des rapports précédents pour ne pas faire les mêmes erreurs

 

Pendant le projet :

Le développement :

  • corriger les bugs au fur et à mesure
  • que chaque programmeur corrige ses propres bugs
  • il est difficile d’écrire du code sans bugs : donc tester le code dès le début, mettre en place tous les dispositifs d’alerte mis à disposition
  • voir le produit sous l’angle de l’utilisateur, qui voit l’ensemble du produit, et ne se soucie pas du fait que des équipes différentes aient travaillé aux différentes fonctionnalités
  • prendre en compte le bien-être de l’utilisateur, ne jamais sous-estimer l’exigence de l’utilisateur. Si problème il y a,  c’est du côté du programme, pas de l’utilisateur qui n’avait qu’à comprendre, ou être plus patient

 

La direction de projet :

  • supprimer au maximum toutes les tâches qui ne sont pas du dev, limiter les rapports, les réunions d'avancement, trouver dans la mesure du possible des palliatifs à ces dernières
  • affiner les questions lors de la recherche d'un problème
  • prendre le temps tous les jours d'interroger l'avenir pour éviter les catastrophes futures
  • avant d'attaquer un problème toujours se demander si on s'attaque au vrai problème
  • toujours vérifier la nécessité d'une tâche
  • savoir dire non si la requête est irrecevable dans les délais impartis
  • se méfier des « c’est trop difficile », « ça représente trop de travail » : toujours recadrer la demande par rapport aux objectifs du projet
  • tendre l’oreille aux idées nouvelles, les trop rapides « c’est impossible » n’ont souvent pas d’arguments
  • utiliser les effets de levier au maximum : du code réutilisable, des membres formés à un développement plus large que celui du seul projet, etc

 

Les réunions :

  • avant les réunions : toujours vérifier la nécessité de ces participants, et s’il n’est pas possible d’éviter la réunion par un échange de mails
  • plage horaire de la réunion : qu’elle ne coupe pas trop les plages de travail
  • réunion avec objet de la réunion : question précises et décision conditionnelle si besoin, mais décision

 

Le planning :

  • planning tenable, sinon démoralisant
  • jalons de projet : un jalon doit représenter un aboutissement qui participera à l’enthousiasme des développeurs, très différent d’une liste de tâches

 

Les développeurs :

  • ne pas laisser un membre de l’équipe stagner dans un domaine particulier, pour qu’il puisse agrandir ses compétences
  • chercher à agrandir les compétences d’un développeur plus par rapport à l’entreprise que par rapport au projet
  • ne pas garder un développeur qui n’apprend plus rien : ce sera meilleur pour le développeur et pour l’équipe (souvent la place laissée libre permet à d’autres membres de l’équipe de progresser)
  • veiller à la croissance régulière de l’équipe en fixant des objectifs de croissance, liés aux projets, afin de garantir qu’ils soient faits et ne restent pas lettre morte
  • établir un objectif de croissance lors du repérage d’une mauvaise pratique

 

Les horaires :

  • le chef d’équipe doit vérifier la manière dont les développeurs utilisent leur temps pour cibler où se font les pertes, aider chaque membre à disposer de larges plages horaires doit être l’une des priorités
  • la nécessité d’horaires rallongés indique qu’il ya un problème dans la direction du projet : réalisation de tâches dépourvues d’importance stratégique, ou planning irréaliste. Quelque soit la raison : il faut isoler le problème, le traiter et arrêter les heures supplémentaires
  • contrairement à l’idée répandue « longues heures » ne signifie pas « équipe dynamique qui s’investit » : un travail bien fait est un travail fait dans les temps impartis, sans nécessiter d’heures supplémentaires, les heures supplémentaires indique un manque d’efficacité ou un problème de gestion
  • les heures passées sur le lieu de travail ne sont bien souvent pas des heures de travail si les horaires sont trop allongés, les développeurs en viennent à « faire leur vie » au travail et donc à perdre en efficacité.
  • le bien-être joue un grand rôle dans l’efficacité, l’entrain des développeurs a donc un impact direct sur le projet : veillez à ce que les membres de votre équipe puissent profiter de leur vie hors des heures de boulot, afin qu’ils soient plus efficaces pendant ces derniers

 

Après le projet :

  • établir des rapports d'autopsie précis et proposant des solutions
 

Commentaires

Pas encore de commentaire
avatar du commentateur
Guest
lundi 27 septembre 2021

Image Captcha

captcha

By accepting you will be accessing a service provided by a third-party external to https://www.pulsar-agency.com/