Carnet d’un informaticien

Comme je savais depuis quelque temps que j’allais partir m’installer à Toulouse, je m’étais inscrit à l’étape locale de l’Agile Tour, découvert via Eric Lefèvre. Bien m’en a pris, puisque cela s’est révélé très intéressant.
Je n’ai pas pu rester jusqu’au bout, j’ai donc assisté aux conférences suivantes :

• Introduction aux méthodes agiles, par Olivier Azeau

• Présentation Scrum, par Claude Aubry

• Présentation XP, par Thierry Cros

• L’agilité en situation, par Claude Aubry et Philippe Kruchten

• Outils agiles, par Jean-Marie Damas et Stéphane Maldini

L’introduction aux méthodes agiles était un peu poussive, l’intervenant ayant du mal à faire une présentation. Je n’en ai pas retenu grand chose de nouveau.

Pour la présentation de Scrum, Claude Aubry s’est révélé très drôle, même si sa présentation manquait parfois de rythme, et s’il n’a pas su interpréter correctement les signaux que lui envoyaient les maîtres du temps. Le point important qu’il a souligné est que Scrum est une méthode de conduite de projet, quasiment un processus, qui n’est pas dédiée à l’informatique. De plus, Scrum offre un processus intéressant : la phase initiale est définie, la phase finale également, mais la transition d’une phase à l’autre ne l’est pas. Elle se compose de plusieurs itérations qui s’enchaînent jusqu’à ce que l’objectif ait été atteint. Chacune de ces itérations boucle façon roue de Demming, sauf que les 4 étapes sont nommées différemment.
Claude Aubry aurait pu expliquer plus en quoi Scrum est agile. J’ai surtout retenu la dimension itérative, mais pour l’agilité, j’avoue avoir moins retenu.

La présentation XP de Thierry Cros a été réduite à la portion congrue, même pas 10 minutes, puisque la présentation de Scrum a duré bien trop longtemps. C’est très dommage, car Thierry Cros s’est montré très bon connaisseur de son sujet — c’est bien le moins pour le fondateur de XP France — et capable de présenter de façon structurée et compréhensible une méthode XP qui semble trop souvent ad-hocquiste et fouillis. Heureusement, sa présentation est en ligne.

Le clou du spectacle était incontestablement la présentation conjointe de Claude Aubry et Philippe Kruchten sur l’agilité en situation. Philippe Kruchten est un des piliers de la méthode RUP (Rational Unified Process), et il s’est révélé très doué pour faire une présentation avec la dose d’humour adéquate.

J’ai été particulièrement satisfait de cette présentation. Premièrement parce qu’elle va à contre-courant de ce que j’ai souvent lu pour l’application des méthodes agiles, à savoir que la meilleure façon de mettre en place une méthode agile, c’est de commencer par appliquer toute la méthode, pour ensuite voir ce que l’on en retient (ainsi chez Craig Larman, dans “Agile and Iterative Development“). Aubry et Kruchten disent l’inverse. Et je dirai que c’est le bon sens même. Pour eux, il faut sélectionner les pratiques que l’on va mettre en place, en faisant une analyse de son contexte.

Et c’est là le second point qui m’a particulièrement intéressé : l’aspect méthodologique. Les deux intervenants ont expliqué qu’il fallait commencer par analyser l’environnement de l’entreprise, pour ensuite déterminer le contexte du projet, lequel permet alors de choisir les pratiques agiles à mettre en œuvre. Il faut retenir ces phrases fortes : “Les bonnes pratiques sont le pire ennemi du contexte.” et “La valeur de toute pratique dépend de son contexte.”. Elles résument les fondements de l’agilité.

L’application de l’ensemble des pratiques agiles n’est envisageable que pour des projets bien déterminés : des équipes de taille faible (5-12 personnes), travaillant en un même lieu, sur un nouveau projet, à temps plein, avec le client sur place, etc. Mais pour nous autres qui devons composer avec la réalité des personnels à temps partiels, des équipes réparties, des MOA distantes, des projets en maintenance, l’application systématique de chacune des pratiques mènerait au désastre. Alors il faut savoir bien prendre en compte ces contraintes pour ne sélectionner que les pratiques applicables.

Pour le reste, je renvoie à leur présentation, que je ne voudrais pas paraphraser plus. Une dernière citation : “Le contexte, le contexte, le contexte !” (à scander à la manière du fameux “location, location, location !” des agents immobiliers américains).

Dernière présentation : les outils agiles. J’avoue être resté sur ma faim. Les outils sont encore jeunes, et même si IceScrum semble plein de promesses, ses fonctionnalités sont encore insuffisantes. Mais peut-être que la solution est d’utiliser les outils existants en mettant en place les pratiques agiles !

Au total, une conférence très intéressante sur la partie “agilité en pratique”, un peu moins sur le reste. Pourvu qu’il y en ait d’autres !

Tous les métiers ont leur vocabulaire, et le droit n’y échappe pas, qui emploie des mots de la langue courante dans des contextes bien précis, et a ses mots que le commun des mortels n’oserait jamais utiliser au quotidien.

C’est toujours un grand moment de bonheur que de lire les documents juridiques d’un marché public d’informatique. Alors voici un peu d’aide pour y comprendre quelque chose.

Au commencement est le marché

Un marché public est un contrat administratif entre une administration et un titulaire du marché, généralement une entreprise. Le marché est attribué à la suite d’une procédure de passation qui peut revêtir plusieurs formes, les plus communes étant l’appel d’offres et la négociation.

La personne qui a le pouvoir de signer le marché, et donc d’engager l’administration, s’appelle le représentant du pouvoir adjudicateur (RPA) ; l’administration qu’il engage est le pouvoir adjudicateur. Avant 2006, on employait le terme “personne responsable du marché” pour désigner le RPA. Mais certains pontes ont décidé qu’il fallait mettre fin à des décennies d’emploi du mot, et résoudre les problèmes en appelant un chat un chien. Ça n’a rien résolu, mais ça a fait du travail en plus. Mais tous les textes qui ont été élaborés avant 2006 mentionnent la personne responsable du marché.

La famille des documents

Le marché se compose de plusieurs documents, rassemblés au sein du dossier de consultation des entreprises. Il s’agit de l’acte d’engagement, du règlement public de la consultation, du cahier des clauses administratives particulières, du cahier des clauses techniques particulières, et des différents cadres de réponses qui devront être remplis par le candidat.

L’acte d’engagement est le document qui est signé du représentant du titulaire (celui qui décroche le marché) et du représentant du pouvoir adjudicateur. Il présente l’offre du titulaire.

Le règlement public de la consultation indique les modalités selon lesquelles la consultation qui permet d’attribuer le marché se déroule.

Les deux documents les plus importants sont le cahier des clauses administratives particulières (CCAP) et le cahier des clauses techniques particulières (CCTP). Ils contiennent des informations essentielles pour toute la vie du marché.

Le CCTP décrit en détail le contenu attendu de la prestation. Par exemple, pour le développement d’un logiciel, il indique ce que le futur logiciel devra faire, les normes en vigueur, l’organisation du projet, l’organisation de l’administration, etc.

Le CCAP décrit toute la partie administrative du marché, c’est-à-dire les procédures qui seront mises en place, notamment pour la vérification des prestations, la détermination des prix, des pénalités de retard, le calcul des délais. Il mentionne aussi les documents contractuels ainsi que leur ordre de priorité, pour déterminer lequel a raison dans le cas où il y aurait des contradictions. Enfin, il peut faire référence à un cahier des clauses administratives générales (CCAG).

Dans le cas d’un marché de développement de logiciel, le CCAG qui est généralement mentionné est le CCAG relatif aux prestations intellectuelles, dit CCAG-PI. Il contient des clauses générales qui déterminent les délais, les pénalités (encore !), et surtout le régime de propriété intellectuelle des prestations. Il faut absolument noter que si le CCAP veut déroger à une clause du CCAG auquel il fait référence, cela doit être indiqué dans le CCAP. C’est souvent le cas pour les opérations de vérification

On trouve également le CCAG fournitures courantes et services, dit CCAG-FCS, particulièrement utilisé pour les achats de logiciels, progiciels et matériels informatiques.

Un point intéressant à noter : dans un futur proche, nous allons voir apparaître le CCAG-TIC (techniques de l’information et de la communication), qui est en cours de finalisation. Ce CCAG permettra de mieux prendre en compte la spécificité de l’informatique.

Bon, vous voilà maintenant armés avec un peu de vocabulaire général des marchés. A venir : un billet sur les opérations de vérification dans les marchés d’informatique.

De programmeur à chef de projet

La plupart des chefs de projets informatiques que je croise ont un passé de techniciens. J’entends par là que ce sont pour la plupart des ingénieurs de formation qui ont derrière eux une expérience de programmeurs ou développeurs. Les discussions avec eux prennent donc souvent un tour technique.

Mais le métier de chef de projet nécessite justement de savoir régulièrement dépasser la problématique technique. Au-delà des compétences dures, purement techniques et informatiques, qui forment le cœur du métier d’informaticien, le chef de projet informatique doit avoir deux types de compétences en plus : les compétences juridiques, et les compétences managériales.

Droit dans ses bottes

Pour les compétences juridiques, j’entends par là qu’il doit savoir lire un contrat, au sens large : qu’il s’agisse d’un contrat entre entreprises privées ou d’un marché public avec une administration. Ce point est essentiel. J’ai trop souvent vu des chefs de projets de SSII incapables de comprendre les contraintes contractuelles, et croire que l’on pourrait facilement s’arranger avec la procédure, pour ensuite se voir imposer des pénalités de retard. ¹

Des compétences douces ?

Pour les compétences managériales, j’en identifie deux sortes : les compétences managériales dures et les compétences relationnelles, qui complémentent les premières.

Les compétences managériales dures concernent essentiellement la fixation d’objectifs, le suivi (objectifs et budgétaire) et la planification. Ce sont des compétences qui restent techniques.

Pour ce qui est des compétences relationnelles, on y trouve surtout la gestion d’équipe, et les compétences en communication.

Autant on peut acquérir par des formations les compétences managériales dures, autant les compétences relationnelles nécessiteront beaucoup de pratique en plus des formations. En effet, dans ce dernier cas, les formations ne sont qu’un préalable. C’est avant tout par la pratique que les compétences relationnelles s’améliorent. Il faut en effet constamment se mettre à la place de l’autre et être à son écoute, alors que les compétences dures, qu’elles soient managériales ou techniques, peuvent s’exercer en solitaire.

Alors quand viendra la saison des entretiens de formation, n’oubliez pas de vous demander, avec votre responsable, quelle compétence non technique informatique vous allez pouvoir acquérir ou consolider !

1. Je fournirai ici quelques éléments de lecture des marchés publics. [↩]

Plutôt que de faire une longue présentation sur ce sujet qui fait maintenant partie du bloc de bonnes pratiques du développement, je vous renvoie à l’excellente interview d’Eric Lefèvre réalisée par Cyril Dhénin sur TV4IT, et référencée sur le blog d’Eric Lefèvre. En cinq minutes, la quasi-totalité du sujet est abordée. Chapeau l’artiste. Juste un petit point de traduction : “mock objects” me semblerait mieux traduit en “objets factices”.

Il semble que ce soit la saison du développement piloté par les tests, puisqu’on trouve un article sur le sujet dans le 01 Informatique du 1er mai 2008 : un article intéressant à lire pour tout chef de projet qui s’interroge sur cette pratique et sur sa mise en œuvre.

Bref, vous n’avez plus d’excuse pour ne pas le mettre en place sur vos projets !

La mise en place d’une démarche d’analyse des processus oblige à regarder ce que l’on fait. Et c’est parfois plus que salutaire. On se rend alors compte des dysfonctionnements de son processus, ou bien on se contente de révéler au grand jour ce que tout le monde se dit dans les couloirs sans jamais le dire en réunion.
Il est alors tentant de tenir le discours du grand soir, en décidant qu’à partir de demain, on va faire les choses correctement. Évidemment, c’est ce qu’il ne faut pas faire.

Pourquoi est-ce que ça ne marche pas, d’abord ? Premièrement, parce que quand on a décidé que l’on allait faire tout bien à partir d’une certaine date, cela veut généralement dire que l’on n’a pas défini dans le détail ce qu’était ce “tout bien”. En effet, si ce détail avait été défini, on aurait pris beaucoup de temps pour le faire, puisqu’il y aurait eu beaucoup de détails, et on ne se serait pas amélioré avant d’avoir décidé de tout ce qu’il fallait faire. De plus, on se serait rendu compte qu’il y avait beaucoup de changements à apporter au travail quotidien, et que cela allait passablement perturber tout le monde. Et c’est là la seconde raison pour laquelle le big bang ne fonctionne pas : il y a trop de choses à faire à la fois, et personne ne peut tout faire bien d’un seul coup.

La bonne solution est évidemment d’y aller par petites touches. Mais comment déterminer les améliorations à apporter en priorité ? Cela se fait en deux temps.

1. Tout d’abord, on fait une première liste des améliorations à apporter, sans viser à l’exhaustivité : soyez certains que les améliorations recensées lors de cette première passe seront des améliorations évidentes et prioritaires.
2. Ensuite, on les priorise en fonction du bénéfice qu’elles apporteront et de la durée nécessaire à leur mise en œuvre, et on décide de lancer celles qui seront réellement prioritaires au regard de ces deux critères.

Je précise évidemment : il faut absolument donner une date à laquelle ces améliorations auront été mises en place. Et leur affecter un responsable. C’est évident, mais je préfère le répéter.

Une fois que ces premières améliorations auront été mises en œuvre, ou du moins que leur mise en œuvre sera bien avancée, on répète l’opération. On élabore ainsi un plan d’actions d’amélioration que l’on actualise régulièrement. Dans notre cadre ISO 9001, ce plan est actualisé au moins tous les 6 mois avec les revues de processus : c’est l’occasion de souffler un peu, de faire le bilan du travail accompli, et de recharger la barque pour repartir de plus belle !

Qui n’a pas connu les affres d’une certification a de la chance. Imaginez les sueurs froides lors des journées d’audit, à se demander si les auditeurs vont venir vous voir, s’ils vont éplucher toute votre documentation, s’ils vont arpenter les bureaux en quête d’une proie dodue et naïve qui leur livrera innocemment l’argument qui leur permettra de vous atomiser. Imaginez aussi les mois qui précèdent l’audit, depuis la bonne nouvelle du “Je vous nomme pilote de la démarche pour votre processus” qui vous assomme un peu plus de travail, jusqu’aux réunions pour se demander ce que l’on fait et si on le fait comme il faut, assorties de leurs indispensables remarques réactionnaires du type “Mais on a toujours fait comme cela !” ou “On n’a pas attendu cette démarche pour savoir comment travailler !”. C’est épuisant. Même pour une simple certification ISO 9001 comme celle que nous avons décrochée fin 2007.

Alors pourquoi se lancer dedans ? D’aucuns pensent que ces démarches tiennent de la foutaise, et qu’elles servent surtout à engraisser des myriades de cabinets de conseil et d’organismes certificateurs.
Certes, le second point a du vrai, mais c’est surtout une conséquence de l’engouement des entreprises pour la certification. Car ces démarches ont du bon.

Premièrement, elles donnent à l’entreprise une visibilité et lui permettent de se positionner dans un référentiel indépendant et reconnu. Lorsque l’entreprise s’adresse à ses clients, elle leur envoie un message disant “nous appliquons ce référentiel de bonnes pratiques”. C’est un peu l’équivalent du diplôme, mais pour les entreprises : ce n’est en aucun cas une garantie, mais c’est un signal qui permet au client de faire un premier tri parmi ses potentiels vendeurs ou fournisseurs : on sait que ceux qui sont certifiés ISO 9001 savent au moins ce qu’ils font, puisqu’ils ont analysé tous leurs processus.

Deuxièmement, elles obligent à se poser des questions. C’est particulièrement le cas de ISO 9001. Beaucoup ironisent en disant que l’on n’a pas attendu cette norme pour faire du travail de qualité. Certes. Mais aujourd’hui, alors que les cadres sont pris dans la spirale de l’urgence, le lancement d’une démarche de certification ISO 9001 oblige tous les cadres à se demander ce qui est fait dans leurs services, et si le travail est fait comme il devrait l’être. C’est souvent l’occasion de grosses surprises : alors que l’on pensait naïvement que certaines tâches étaient faites d’une certaine façon, il ressort que ce n’est pas le cas, car les personnels d’exécution ont mis au point une autre façon de travailler pour contourner certains problèmes. Et évidemment, cette façon de travailler a elle-même ses problèmes. Donc la remise à plat induite par ISO 9001 est plus que salutaire.

Accessoirement, un avantage de ces certifications est qu’elles peuvent conduire à obliger le management à prendre certaines décisions, en rendant visibles certains dysfonctionnements dont les acteurs de terrain sont bien conscients. Des doublons entre services, des activités qui ne sont pas conformes mais que l’on laisse en l’état pour ne pas déplaire à un manager particulier : ces éléments sont autant de non conformités potentielles qui peuvent mettre en péril l’obtention du précieux sésame.

On l’aura compris, je suis un défenseur des certifications, même si j’en connais bien leurs limites : ce n’est pas parce que l’on est certifié ISO 9001 que le travail est bien fait, cela signifie juste que l’on fait ce que l’on a écrit et que l’on a écrit ce que l’on fait. C’est un premier pas essentiel, mais ça ne remplace pas la compétence des managers.

Je ne compte plus le nombre de fois où je lis “assurance qualité” là où il devrait y avoir écrit “contrôle qualité”. La confusion est d’ailleurs très répandue chez les anglo-saxons, plus que chez nous. Je lis régulièrement des articles qui mentionnent un bureau d’assurance qualité qui a la responsabilité des tests logiciels.

Qu’est-ce que l’assurance qualité ? C’est l’ensemble des structures et des processus mis en oeuvre pour garantir que le produit sera élaboré dans le respect de normes de qualité. Et qu’est-ce que le contrôle qualité ? C’est l’ensemble des tests qui sont effectués tout au long de l’élaboration du produit. Donc l’assurance qualité définit la mise en oeuvre du contrôle qualité.

Prenons un exemple un peu plus parlant. Imaginons que vous êtes en train de mettre au point une plateforme d’intégration continue. Vous définissez la procédure suivante :

1. le développeur développe son code, il écrit ses tests unitaires, il les exécute et vérifie qu’ils sont corrects, puis il enregistre son code dans l’outil de gestion de configuration.
2. périodiquement, l’outil d’intégration continue extrait une copie intégrale de la dernière version des codes sources, il la compile, il lance les tests unitaires, et il la déploie sur un environnement d’intégration. Si jamais une erreur survient lors de la compilation ou de l’exécution des tests unitaires, il envoie un message électronique au fautif, aux développeurs du projet et au chef de projet.

Dans cet exemple, l’assurance qualité, c’est la procédure complète, constituée de deux étapes. Le contrôle qualité, ce sont les contrôles effectués dans les deux étapes.
Voilà, vous n’avez maintenant plus d’excuse pour vous mélanger les pinceaux !

Vu sur l’indispensable blog IT Leadership, cet article de Tom Mochal : Use these interviewing techniques to gather project requirements. Je vais me permettre de le reformuler pour donner quelques conseils pour les séances d’analyse des besoins et d’élaboration des spécifications. En effet, il n’est pas toujours évident pour l’analyste de savoir comment procéder pour obtenir des experts métier les informations nécessaires à la rédaction des spécifications détaillées.

Premier principe : partir du général pour aller au particulier.

Le principe est clair. Il ne faut pas céder à la tentation d’aller tout de suite dans les détails. Il faut au contraire commencer par demander aux experts de décrire ce qu’ils veulent en termes généraux. Si les experts sont dans une démarche de maîtrise d’ouvrage et qu’ils savent exprimer leur besoin en partant du général, c’est tant mieux. Sinon, il faut biaiser : commencez par demander à vos interlocuteurs de décrire leur métier. Si nécessaire, prenez un exemple : “Lorsqu’un dossier arrive dans votre bureau, que faites-vous avec ? Quel chemin ce dossier suit-il ? Quelles sont les personnes qui vont intervenir dans son traitement ?” En effet, certains experts ne sont pas toujours capables de conceptualiser leur travail : il faut dès lors leur permettre de se situer sur un terrain concret, pour qu’ils s’y retrouvent.

Il en découle donc qu’il faut proscrire au départ les questions fermées : “Alors vous avez besoin d’une application qui traite les dossiers d’accidents pour déterminer s’il faut les indemniser ou non ?” Ce genre de question peut limiter l’expert dans son expression : l’analyste peut ainsi passer à côté de tout un pan des besoins, par exemple oublier l’aspect pilotage dans l’exemple donné. (cf. troisième principe)

Second principe : insister et en mettre plusieurs couches.

Une fois que la partie générale a été abordée, il faut rentrer dans les détails. Pour cela, il faut prendre chacun des éléments généraux précédemment relevés, et poser des questions qui demandent des précisions sur ces éléments : “Vous m’avez dit que vous allez déterminer s’il faut ou non indemniser. Comment allez-vous faire ?” Ces questions peuvent être ouvertes ou fermées : “Vous envoyez un inspecteur pour déterminer la responsabilité. Est-ce que vous l’envoyez toujours ou pas ?”

Pour mener à bien ce “forage”, il faut avoir recours à différentes techniques.
Il faut poser des questions directes pour obtenir des informations sur le contexte, par exemple comprendre la philosophie générale qui préside à la conception de l’application : cela permet de comprendre dans quel cadre les experts s’inscrivent, et donc de mieux cerner les sous-entendus dans leurs propos.
Il faut aussi reformuler. La reformulation permet de vérifier auprès de son interlocuteur qu’on l’a bien compris, et en même temps de s’approprier le sujet. Elle peut être très simple : “Donc vous envoyez toujours un inspecteur, parce que la réglementation vous l’impose ?” Elle peut aussi avoir pour objectif de synthétiser tout un pan d’une discussion : “Les étapes de l’instruction d’une déclaration sont donc 1, puis 2, puis 3, et enfin 4 si nécessaire ?”
Enfin, il faut également avoir recours à des exemples. Cela permet de redescendre sur terre et de fournir un support concret à la discussion. Cela va aussi aider l’analyste à préparer ses plans de tests.

Pour terminer avec ce principe, un point important : savoir garder le cap. Il arrive que certains experts partent à parler d’autre chose que de ce qui concerne l’analyste : “C’est d’ailleurs la grande différence avec l’assurance vie. En effet, dans ce cas blablabla…” Cela peut arriver du fait que la question aura été mal interprétée par l’expert, mais aussi du fait qu’il n’est pas suffisamment intéressé ou concentré sur le sujet. Dans ce cas, il appartient à l’analyste de recentrer la discussion : “C’est intéressant. Et quelles en sont les conséquences sur (la question initiale) ?”

Troisième principe : être ouvert.

Les séances de questions ne sont pas des moments de pure technicité : il n’y a pas de méthode magique qui permettrait de dérouler la séance d’un bout à l’autre en étant certain d’avoir tout examiné. Il faut donc que l’analyste se montre ouvert et attentif.

L’ouverture vient de la formulation retenue dans les questions : comme mentionné pour le premier principe, il faut de façon générale préférer les questions ouvertes. Il vaut mieux demander “Que faites-vous dans ce cas ?” que “Et dans ce cas, vous faites ceci ou cela ?” En effet, dans le second cas, l’expert se sentira sur un chemin balisé, sur lequel l’analyste aura déjà fait le travail pour lui, et il n’aura pas tendance à aller voir ailleurs, au risque d’oublier des éléments importants. Alors que dans le premier cas, l’expert est obligé de se poser les questions et de lister les différentes options.

L’attention découle de l’ouverture. Sans questions ouvertes, l’analyste pourra être aussi attentif qu’il le voudra, il passera à côté de beaucoup d’éléments. En posant des questions ouvertes, l’analyste va devoir faire attention aux éléments qui sortent du cadre de la réponse qu’il attend. Ces éléments peuvent être le signe que certains points qui ont été abordés précédemment n’ont pas été complètement traités. Ainsi, si l’expert indique que le module de pilotage devra calculer un indicateur pour lequel une donnée n’a pas été prévue, c’est probablement le signe qu’il y a eu un oubli lors de l’analyse des autres modules.

Pour résumer, l’analyse des besoins pour la rédaction des spécifications détaillées nécessite à la fois de la méthode et des qualités d’écoute et d’ouverture : si l’un des trois manque, c’est la porte ouverte aux spécifications mal taillées, et la préparation de week-ends laborieux pour rattraper tout cela !

Certains semblent penser que l’agilité, c’est fournir des élements à recetter au client au fur et à mesure qu’ils sont produits. C’est là un manque fondamental d’écoute et d’attention au client.

Un ami me racontait que lui et son équipe rencontraient d’énormes difficultés sur son projet. En effet, il avait été décidé que les développeurs fournissaient leurs corrections au fil de l’eau. Ces corrections étaient intégrées, et elles passaient tout de suite en recette.
Mais le problème, c’est que le client, chargé de la recette, ne parvenait plus à suivre. A la suite d’un changement dans l’équipe de recette, il n’y avait plus qu’une personne à temps partiel.
Du coup, il devenait impossible de passer en production aucune livraison. En effet, avant même qu’une livraison n’ait commencé d’être recettée, une seconde arrivait qui devait être prise en compte.

Pour pallier la difficulté, mon ami avait choisi de passer en production des morceaux, en fonction des anomalies corrigées. Le résultat était que la charge de travail était importante pour l’intégrateur chargé de recoller les morceaux, et que la visibilité sur les anomalies non encore passées en production devenait difficile.

Je lui fis remarquer deux points.

Premièrement, c’est au client de dire les anomalies qu’il veut recetter. Cela signifie qu’il faut demander au client de prioriser les demandes de correction. Pour chaque demande, l’informaticien – et de préférence le développeur plutôt que le chef de projet – doit fournir une estimation de la charge que la correction représente. Ensuite, on regroupe les demandes par paquets et on détermine des dates de passage en recette des paquets de correction. On aboutit ainsi à une planification qui permet au client de planifier son travail en prenant en compte la contrainte de la recette.

Deuxièmement, il ne faut pas confondre intégration continue et passage en recette continu. Ce n’est pas parce qu’un développeur a fait sa correction qu’elle doit tout de suite passer en recette. La correction peut être livrée, mais ce n’est pas avant que le chef de projet donne son feu vert qu’elle ne passe en recette. Cela signifie donc que le chef de projet doit suivre de près le travail effectué par les développeurs afin de demander le passage en recette au moment adéquat. Il ne faut surtout pas considérer que le client est à disposition des développeurs, pas plus que le contraire. Dans la plupart des environnements de travail, un minimum de planification est nécessaire pour coordonner le travail des différents intervenants. Ce n’est que rarement que tout le monde travaille en équipe sur un même plateau, comme dans le monde merveilleux des livres sur XP. La dure réalité, c’est que les développeurs sont souvent dans un bâtiment, les experts-métiers et les recetteurs dans un autre, que ces derniers doivent assumer leur travail habituel en plus de la recette, et qu’il faut donc coordonner tout ce monde. C’est à cela que servent les chefs de projet. Et s’il n’est pas possible de faire respecter cette coordination par certains trublions, alors il faut en faire une procédure et l’écrire.

Mon ami tira les conclusions de mes remarques et il imposa qu’il serait le décisionnaire des passages en recette, que les anomalies seraient priorisées avec le client, que l’on ferait une planification indicative, et que l’on parlerait délais. Le projet ne s’en porta que mieux.

Je viens de finir Coder to Developer: Tools and Strategies for Delivering Your Software.

L’ouvrage s’adresse au programmeur pour lui permettre de devenir un développeur, voire un chef de projet junior. Il aborde notamment la planification, l’organisation, l’utilisation des gestionnaires de codes sources, les tests unitaires, le traitement des bugs, le suivi de l’activité des applications, la documentation, et la construction du logiciel. Il n’est pas le premier livre à parler de ces sujets. Mais ce livre a le mérite de présenter ces sujets ensemble, dans un ordre logique, en s’adressant à des programmeurs peu expérimentés.

J’ai particulièrement apprécié le chapitre sur la programmation défensive : les assertions ont toute ma faveur, et la gestion des exceptions, quoique ardue, est indispensable dans les langages à objets. Et un auteur qui insiste sur la nécessité de mettre des commentaires utiles, en donnant des exemples de mauvais et bons commentaires ne peut que me plaire.
A lire également le chapitre sur les tests unitaires, qui en profite pour présenter le développement piloté par les tests, et l’indispensable refactoring, pour lesquels les tests unitaires sont un préalable !

Je regrette évidemment que l’ouvrage se base sur .NET, car je ne suis pas du tout familier de la plateforme. J’aurais préféré Java. Mais l’auteur prend de nombreux exemples issus du monde Java, pour amener leur contrepartie .NET : ainsi Ant et son équivalent Nant, ou Log4j et son équivalent Log4net.
Autre regret, le fait que comme dans la plupart des ouvrages, on ne décrive que le monde merveilleux où tout est bien fait, sans indication sur la transition du quotidien au monde merveilleux. Mais l’ouvrage est déjà assez épais comme cela.
Un dernier point : l’auteur parle d’assurance qualité là où il faudrait parler de contrôle qualité : le test du logiciel est du domaine du contrôle, pas de l’assurance.

Pour finir, je recommande l’ouvrage à tous les développeurs : les jeunes qui découvrent la programmation pour qu’ils se familiarisent avec l’univers du développement, et les seniors pour se remettre en tête les bonnes pratiques. Je le recommande également pour les chefs de projets côté informatique, afin d’avoir un aperçu des bonnes pratiques en matière d’organisation des développements.

Et maintenant, il n’y a plus de raison technique de ne pas faire de bons développements !