jouvenot.com

Méthodes agiles : 50 conseils pratiques (épisode V)

Elections présidentielles ou pas, les projets développés en mode agile ne s’interrompent pas.

Voici donc le cinquième article de la série Méthodes agiles : 50 conseils pratiques. Plusieurs milliers de lecteurs ont déjà lu les épisodes précédents. Près d’un millier les ont likés. L’occasion pour nous de les remercier, avec notamment une surprise à la fin de cet article, qui clos cette série que nous avons adoré partager avec vous.

 

41.      Payer les développeurs à supprimer du code

Un geste doublement difficile à faire. Difficile pour l’entreprise de payer quelqu’un pour détruire des lignes de codes alors qu’elle le paye aussi pour en écrire. Difficile pour un codeur de supprimer son travail ou celui de quelqu’un d’autre. Pourtant c’est un très bon moyen de garantir que le code sera simple, court, compréhensible, évolutif…

42.      Utiliser le texte pour réduire les développements inutiles

Un exemple, lorsqu’il est demandé à un utilisateur de se créer un compte sur un site web, la possibilité de personnaliser son compte avec une photo lui est le plus souvent proposée. L’air de rien, une fonctionnalité aussi basique peut générer beaucoup de développement. La très grande variété des formats d’images qui seront téléchargées (.png, .tif, .gif, .jpg, etc.) ainsi que leurs différences de tailles qui nécessitera un système de redimensionnement automatisé, consommeront des ressources au niveau des serveurs non seulement, mais demanderons des développements spécifiques. En revanche, simplement préciser à cet endroit du site : Téléchargez votre photo (format .jpeg, 250 X 250 px) ne coûte rien, prend moins d’une minute et peut économiser beaucoup d’heures de développement.

43.      Ayez un ton

Soyez techniques, drôles, officiels, enthousiastes… peu importe. Ayez un ton ! Les textes d’un service web, d’un site, d’une application mobile, contribueront grandement à la perception que s’en feront les utilisateurs. Des sites comme GitHub ou Algorithmiaqui s’adressent à de purs développeurs se doivent d’avoir un style et un ton différent de ceux de sites de services grand public comme AirBnb ou Uber, ou de sites d’aides aux devoirs scolaires, ou bien encore de services en lignes proposés par des banques.

44.      Soyez écolo et pensez à la pollution

Les phénomènes de natures à pénaliser, retarder ou gêner le bon avancement d’un projet sont multiples. Mis tous ensemble, ils forment un phénomène de pollution : un changement de process dans l’entreprise qui remet en question un développement déjà finalisé, la démotivation des équipes liées à la dé priorisation du projet, la rumeur d’une nouvelle réorganisation, les coupes budgétaires, le départ de ressources clés… Veillez à endiguer cette pollution, à mettre l’équipe sous une « cloche psychologique » afin qu’elle reste dans sa bulle (dans le bon sens du terme) tout en continuant à avoir un œil sur l’extérieur (via les parois transparentes de la cloche de verre), tout en entendant moins le bruit alentour.

45.      Privilégiez le soft management

Parce qu’ils sont mal compris, aspirés par ce qu’ils font, très concentrés et donc silencieux et loin des conversations de la machine à café, ou simplement rivés sur leur Playstation pendant leurs pauses, les codeurs sont souvent taxés d’autistes. N’oubliez jamais qu’en dépit de leur retenue, leur discrétion, leur timidité parfois, leur hyper-concentration… les développeurs informatiques n’en sont pas moins des collaborateurs qui peuvent être très motivés ou tout au contraire démotivés, être impliqués ou démobilisés… Ils sont souvent sensibles. Il importe de savoir les entourer d’une dose de management appropriée.

46.      Pensez à acheter un duvet

La communication verbale compte. Les développeurs se trouvent souvent bien seuls lorsqu’à 21 : 30, leur open space est le seul encore allumé dans l’immeuble impersonnel, perdu au milieu d’une zone d’activité que la nuit, le froid et la pluie d’hiver ont englobée depuis maintenant quelques heures. Arriver le lendemain matin à la première heure avec des croissants en disant « Salut, comme vous avez apparemment passé la nuit ici, je me disais que des pains au chocolat vous ferez plaisir » peut permettre de marquer des points (ou être mal pris). A vous de voir.

Sinon, si vous êtes client et que vous sentez que votre prestataire ne mobilise pas assez ou pas complètement les ressources qu’il vous facture pour votre projet, débarquez à l’improviste chez lui en fin de journée avec un duvet sous le bras en disant : « Salut, comme le projet commence a sérieusement prendre du retard, je me suis dit que vous alliez certainement travailler cette nuit, alors par solidarité je suis venu vous soutenir et j’ai même pris mon duvet pour pouvoir dormir ici. Au fait, ou sont les vôtres pour que je puisse ranger le mien avec eux. » Généralement, la stupéfaction passée, la conversation s’engage et votre prestataire comprend qu’il lui faut mettre un coup d’accélérateur, remonter votre projet dans ses priorités des prochains jours, avant que vous ne rentriez chez vous pour de bon.

47.      Devenez accro du LIFO

LIFO signifie Last In First Out. Pour un développeur, cette technique consiste à regarder et traiter d’abord les demandes les plus récentes et non de les aborder dans l’ordre chronologique (de la plus ancienne à la plus récente). Ce faisant, il s’assure de ne pas travailler à la réalisation d’une tâche, demandée il y a trois jours et qui entre temps a peut-être été annulée, reportée à plus tard, ou modifiée.

48.      Multipliez les démos

Montrer le site, le service ou l’application tourner sur un ordinateur ou un smart phone ont pour vertu de permettre de révéler au grand jour des incohérences, des manques, des imperfections, des erreurs ergonomiques. Ne vous privez pas de cette aubaine. Faites des démos en interne, le plus souvent possible, dès que l’avancée du projet le permet et très régulièrement. Multipliez les démos.

49.      Recrutez des beta testeurs nés

Par-delà l’interne, des amateurs de technologies, de nouveauté et d’innovation pourront se voir offrir ce qu’ils perçoivent comme un privilège. Celui d’être beta testeurs de votre solution. Là encore, les retours et les feedbacks vous seront profitables.

50.  Trouvez votre grand-mère interne

Nous avons tous un grand parent qui ne comprend rien à tout ça (Internet, les applications mobiles, le digital et toutes ces choses). Repérez en interne la personne la moins à l’aise avec le digitale et faites-lui tester votre site, votre produit, votre application ou votre service. Si elle joue le jeu vous ne pourrez qu’apprendre énormément. Seul problème, cette grand-mère est parfois le PDG himself.

BONUS

51. Ne remettez pas à demain, ce que vous pourriez faire… après demain

Ne remettez pas à demain ce que vous pourriez faire aujourd’hui. Et ne suivez surtout pas le malicieux conseil de Pierre Dac : « Remettez à demain ce que vous pourriez faire… après-demain ». Au contraire, résolvez les beugs tout de suite. Ne les laissez pas traîner. Plus vous vous astreindrez à faire disparaître les beugs tôt, dés leur apparition, mieux votre projet s’en portera. Les bugs aiment se reproduire, aiment muter, aiment réapparaître après avoir disparu, aiment migrer, aiment rescuciter… Ceux qui ont l’habitude de les chasser ont même toute une terminologie pour parler d’eux : beugs furtifs, beugs fugitifs, bugs mutants, bugs alliens, bugs joueurs, beugs noctambules, beugs fantômes, beugs insolents, beugs immortels… Ne laisser pas aux bugs le temps de s’épanouir ou de venir rallonger cette liste.

52. Faites du rangement

Une solution de gestion de projet agile peut rapidement devenir un véritable foutoir. Organisez scrupuleusement les tickets en dossier et sous dossiers. Aligner l’arborescence des dossiers sur les lots du projet, sur les sprints planifiés… Si vous devez la faire évoluer en cours de projet pour vous aligner sur une réorganisation plus globale des développements, de grâce faites-le, mais surtout informez tout le monde.

53. Faites le ménage

L’outil de gestion de projets agiles que vous utilisez peut également devenir le véritable entrepôt d’une multitude d’anciennes demandes, d’anciens tickets en tous genres (RFC, tickets destinés au service support, demandes de corrections, demandes de résolutions de bugs…) dont on se sait plus bien quoi faire. Ils polluent bien plus qu’on ne le pense. Faites le ménage. Recontacter leurs auteurs et validez avec eux la possibilité de détruite ces anciens tickets lorsque c’est possible.

54. Ne confondez plus MVP et PMF

Ne confondez plus MVP et PMF. La notion de MVP (Minimal Viable Product) a largement été popularisée et est désormais bien ancrée dans les esprits. Certes, avoir un produit qui tourne dans sa version la plus minimaliste (un Minimal Viable Product) est une étape importante de la méthode agile. Cependant, avoir le strict minimum ne garantit aucunement de permettre ensuite au produit, au service ou à la plateforme en cours de développement de connaître un essor commercial ou à défaut, de recruter des utilisateurs en masse. Très vite, après avoir atteint le stade de MVP, qui permettra notamment de ferrer le marché et de détecter qui seront les utilisateurs, il importe de continuer à développer pour aboutir cette fois-ci au PMF (Product Market Fit), c’est à dire à une version du produit, du service, ou de la plateforme en cours de développement, désormais capable de répondre de manière satisfaisante aux attentes et aux besoins desdits utilisateurs.

55. N’idéalisez pas vos utilisateurs

Les hommes sont loin d’être parfaits et les utilisateurs… sont des hommes. Leurs faiblesses et leurs défauts impacteront grandement vos choix en termes de fonctionnalités, de règles de gestion, de niveau de service. Un exemple. Un article récent de Ray Fisman et Michael Luca, paru dans la Harvard Business Review et intitulé Fixing Digital Discrimination expliquait qu’Airbnb voyait certains des propriétaires, ayant mis en location leurs appartements ou leurs maisons, refuser de louer à certaines personnes, après avoir vu la photo de leur profile utilisateur (révélant leur ethnie par exemple). Autant dire que dans ce cas, le choix visant à déterminer s’il faut rendre obligatoire ou non la publication de sa photo sur son profile devient déterminant. En autorisant les utilisateurs à ne pas afficher leurs photos on peut d’autant plus attirés celles et ceux susceptibles de subir un délit de faciès, mais en même temps faire fuir une partie des propriétaires. Et inversement. Or Airbnb a besoin des deux populations, les propriétaires et les locataires. Garder à l’esprit que le caractère apparemment universel du digital n’efface pas encore les travers des hommes.

56. Préférez les quintets aux big bands

Pour fermer la boucle de cette série de cinquante conseils pratiques, dont le tout premier faisait écho au jazz, réduisez au maximum le nombre d’utilisateurs, côté client, habilités à loguer (écrire, publier, poster) des demandes dans vote logiciel de gestion de projet agiles. Un trop grand nombre de donneurs d’ordres, même si le Product Owner est un chef d’orchestre aguerri, conduira fatalement à de la désorganisation, de la confusion, de la frustration. Contentez-vous d’accorder les violons de quelques musiciens, plutôt que de faire jouer tout un orchestre.