Le blog d'un geek devenu directeur technique

Billets dans la catégorie Organisation d’équipe

Gestion des spécifications

oct23
2011 6 Commentaires Par Amaury

Je vous ai déjà parlé de différentes méthodes de gestion de projet. Entre autre, j’ai déjà écrit des articles sur le cycle en V et le cycle itératif, ainsi que sur les méthodes agiles. Ces méthodes, et plus particulièrement les méthodes agiles, sont globalement axées sur la gestion des développements. Comprenez par là que leur but est d’arriver à la création d’un produit fini avec le meilleur rapport qualité/coût/délai.

Bien souvent, quand on met en place une méthode de travail, on se focalise sur les phases de réalisation du travail. Puis on s’intéresse à ce qui a lieu en aval, le processus qualité et les étapes de livraison. Par contre, on aborde assez rarement la manière dont les spécifications sont réalisées et gérées.

C’est paradoxal : à quoi bon améliorer les processus de développement, si le travail à effectuer est mal défini ?

Spécifications agiles

Une − mauvaise − réponse est apportée par certaines personnes qui interprètent mal les principes agiles. Quand on applique les méthodes agiles, on cherche la satisfaction du client plutôt que l’accomplissement d’un cahier des charges figé. Malheureusement, cela se traduit parfois par la disparition de toute forme de spécification. Au lieu d’apporter une souplesse salutaire, cela peut conduire à un va-et-vient incessant entre le client et l’équipe technique en charge de la réalisation.

La mise en place de cycles itératifs a pour but évident de fluidifier le cheminement expression-de-besoin / spécification / réalisation. À chaque itération, le besoin du client est écouté, analysé, interprété, rediscuté. Les zones d’ombre sont identifiées et laissées de côté pour les prochaines itérations.

Le corollaire de cela, c’est que chaque itération doit pouvoir être réalisée dans des conditions essentielles de stabilité. La méthode Scrum prévoit d’ailleurs deux rôles bien spéciaux : le product owner représente le client et peut répondre aux questions concernant le produit ; le scrum master protège l’équipe des requêtes impromptues.

Mon expérience

J’ai déjà expliqué dans un précédent article comment nous appliquons les méthodes agiles dans mon entreprise. Pour résumer : des cycles de développement d’un mois, séparés en sprints hebdomadaires ; 2 ou 3 sprints de développement, un sprint de stabilisation (tests, débugs), un sprint de MEP (mise en pré-production, validation, mise en production).

La mise en place de ces cycles a eu des effets très positifs. Nous perdons moins de temps tout en augmentant la qualité de notre travail. Nous continuons à identifier les points qui peuvent être encore améliorés.

L’application de cette méthode de travail a toutefois mis en exergue les lacunes que nous avions au niveau de la gestion de nos spécifications fonctionnelles. C’est assez facile de s’en rendre compte : pour qu’un projet soit développé, il faut que sa spécification soit écrite et validée avant la fin du mois précédant le cycle de développement. Si la spec n’est pas prête ou si elle est incomplète, elle devrait être simplement refusée et repoussée au cycle d’après ; mais bien souvent, cela a amené à des négociations concernant les dates de livraison, le niveau de précision, ou la latitude de validation technique autorisée sur les spécifications fonctionnelles.

Ce qui m’a amené à réfléchir au processus global qui mène à l’élaboration des spécifications. PLUS »

Classé dans Organisation d'équipe - Libellé , ,

Citation : Paul Cuisset

août12
2011 1 Commentaire Par Amaury

Je ne sais pas si vous connaissez Paul Cuisset. À la tête de Delphine Software, il a créé quelques-unes des plus grandes réussites françaises dans le monde des jeux vidéos, le plus connu étant Flashback (qui a bercé mon adolescence).

J’ai récemment lu une interview qu’il a donné sur le site GameKult, dans laquelle il parle de ses nouveaux projets. Concernant sa manière d’aborder son travail, il explique qu’il est un touche-à-tout capable d’intervenir aussi bien au niveau du scénario, des dialogues, du design, de la programmation, …

Son message est simple : « Un chef d’orchestre doit pouvoir jouer de tous les instruments : la baguette ne suffit pas. »

Face aux évolutions des jeux vidéos modernes, il y a forcément besoin de personnes hyper-spécialisées dans certains domaines. Toutefois, pour diriger une équipe qui mixe des capacités très variées, il faut posséder des qualités qui permettent de guider les membres de cette équipe, de les challenger, de les faire avancer dans la même direction. Tout cela ne peut pas être fait par une simple délégation des pouvoirs, sans échange, car à un moment donné ou un autre on risque de se retrouver dans une situation où les divergences de vues ont entraîné un écart trop important dans la réalisation.

Donc, que vous soyez chef d’entreprise, directeur technique, chef de projet, ou développeur ayant la charge de stagiaires, retenez bien que vous devez jouer le rôle d’un chef d’orchestre. Et qu’un bon chef d’orchestre ne peut pas avoir une simple connaissance théorique de la musique, il doit être capable d’aider ses musiciens à se transcender. La légitimité se mérite, ce n’est pas la baguette qui la donne.

(j’espère avoir l’occasion de vous parler un de ces jours d’Eric Chahi et de Frédérick Raynal, deux autres monstres vidéoludiques français, que j’ai eu le plaisir de rencontrer il y a une dizaine d’années)

Classé dans Organisation d'équipe - Libellé , ,

Les spécifications à problème (3) Spécifications qui arrivent après le développement.

juin09
2011 Laisser un commentaire Par Amaury

Ce billet est le dernier d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Les deux précédents parlaient de l’absence de spécification et des spécifications qui changent en cours de développement.

En image

PLUS »

Classé dans Organisation d'équipe - Libellé ,

Les spécifications à problème (2) Spécifications qui changent en cours de développement

juin08
2011 Laisser un commentaire Par Amaury

Ce billet fait partie d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Le précédent portait sur les développements réalisés sans spécification. Je vous invite à le lire rapidement pour comprendre le contexte. Le troisième article porte sur les spécifications qui arrivent après le développement.

En image

PLUS »

Classé dans Organisation d'équipe - Libellé ,

Les spécifications à problème (1) Pas de spécification

juin07
2011 7 Commentaires Par Amaury

Il existe 3 grands types de problèmes avec les spécifications. Il y a quelques mois, j’ai préparé une présentation pour expliquer notre nouvelle organisation dans mon entreprise. Dans cette présentation, j’abordais les spécifications, en tentant d’expliquer les conséquences négatives qu’il peut y avoir lorsqu’elles ne sont pas préparées correctement.

Pour rendre mon propos immédiatement compréhensible, j’ai fait un parallèle avec l’architecture «classique», qui est souvent utilisée pour imager l’architecture informatique. Soyez indulgents quant à la qualité des dessins, ça a été fait avec OpenOffice Impress, qui n’est pas vraiment idéal pour ça (ni aidé par mes talents).

Je vous invite aussi à lire les deux articles suivants de cette série, consacrés aux spécifications qui changent en cours de développement et aux spécification qui arrivent après le développement.

En image

PLUS »

Classé dans Organisation d'équipe - Libellé ,

Qu’est-ce qui cloche avec le travail à distance ?

juin05
2011 6 Commentaires Par Amaury

Depuis plusieurs années, le travail à distance semble être une sorte de remède miracle à la plupart des maux rencontrés dans les entreprises high-tech. Si, comme moi, vous lisez des blogs de développeurs, freelancers, graphistes, créateurs d’entreprises et autres donneurs de bons conseils (en majorité anglo-saxons, mais pas seulement), vous pourriez avoir l’impression que la Terre entière a compris les avantages de faire travailler les gens de chez eux.

Pourtant, on assiste récemment à un lent glissement vers une perception un peu différente des choses, comme relaté récemment par Eli White sur son blog (Where has all the remote work gone?). J’aurais tendance à dire que les gens reviennent à la raison après une période d’euphorie irrationnelle.

Essayons d’analyser tout cela posément.

Les avantages du travail à distance

Il est indéniable que le fait de faire travailler ses salariés de chez eux comporte un certain nombre d’aspects positifs. Habituellement, les défenseurs de cette pratique en mettent trois en avant :

  • Productivité. En étant physiquement éloignés les uns des autres, les collaborateurs sont moins enclins à se déranger les uns les autres. Une fois la principale source de distraction éliminée, il est plus facile de se concentrer sur les tâches qui réclament de l’attention, et on abat plus de travail.
  • Organisation. À partir du moment où plusieurs personnes doivent travailler sans être physiquement au même endroit, il faut pallier à toutes les interactions non formelles qui servent habituellement à faire avancer le travail. En supprimant les fameuses «discussions à la machine à café», on est forcé de documenter correctement toutes les prises de décisions et on est obligé de mettre en place des outils de communication efficaces.
  • Flexibilité. Quand une entreprise s’organise de manière à permettre le travail à distance, ses employés peuvent adapter leurs horaires en fonction de leurs besoins et de ceux de l’entreprise. Peu importe quand le travail est fait tant que le résultat est là, non ? Les collaborateurs sont plus heureux, donc ils sont plus efficaces.

On peut toujours ajouter d’autres avantages, qui sont peut-être moins évidents au premier abord mais qui peuvent être importants dans certains contextes : Réduction (ou élimination) des locaux, simplification des questions de cantine/chèque-restaurant, économies sur les besoins matériels.

Les origines du travail à distance

Je n’ai aucunement la prétention d’avoir fait des recherches poussées au sujet des origines du travail à distance. Je ne livre ici que la perception − très très subjective − que j’en ai. PLUS »

Classé dans Organisation d'équipe - Libellé , , ,

Application concrète des méthodes agiles

mai12
2011 1 Commentaire Par Amaury

J’ai déjà parlé de plusieurs méthodes de travail sur ce blog, depuis le cycle en V jusqu’aux méthodes agiles en passant par les cycles itératifs. Pour illustrer tout ça, je vais vous parler de la manière dont nous gérons les projets dans mon entreprise.

Le contexte

Pour situer un peu les choses, il est nécessaire que je vous parle un peu de l’entreprise elle-même.

Fine Media est éditeur de sites Web ; ce n’est pas une «web agency», nous sommes notre propre client. L’entreprise a officiellement commencé son activité en septembre 2007, elle existe donc depuis plus de 3 ans et demi. Nous sommes actuellement une trentaine de personnes.

Les deux premières années se sont déroulées dans un climat classique de start-up à la française, dans un joyeux mélange d’élaboration de process, de développements itératifs rapides, de recrutements stratégiques et de bonne humeur. Le cap des deux ans d’existence et de la vingtaine de personne s’est passé naturellement, l’entreprise quittant d’ailleurs à ce moment ses premier locaux (sous les toits et un peu serrés) pour un immeuble plus confortable.

L’équipe technique a évolué lentement mais sûrement. J’ai immédiatement embauché un administrateur système et une infographiste. Au départ, je réalisais l’intégralité des développements. Avec l’arrivée successive de nos développeurs, j’ai pu me recentrer sur les projets cruciaux. Nous avons désormais une équipe constituée d’un administrateur, de trois développeurs, de deux infographistes/intégrateurs et de moi-même (directeur technique). Cela reste une équipe réduite, mais qui représente quand même un quart des effectifs. Le reste de l’entreprise est constitué de référenceurs, de rédacteurs, de community managers, et de commerciaux. Les référenceurs ne sont pas considérés comme faisant partie de l’équipe technique, car ils ont un rôle très transverse, à la fois actif au niveau de la technique et de la rédaction.

Comme je le dis plus haut, nous avons longtemps abordé les développements de la même manière que dans la plupart des start-ups. En privilégiant la réactivité, nous avons réussi à mettre en place des choses relativement complexes dans un laps de temps assez court. Quand il le fallait, j’avais l’autorité nécessaire pour faire des choix structurels, soit pour réclamer plus de stabilité dans les développements, soit pour lancer les refactoring qui s’imposaient.

Ceux qui suivent le blog savent que la fin de l’année dernière a été une période un peu mouvementée, avec un énorme refactoring. En 4 mois, on a remis à plat et recodé l’ensemble de tout ce qu’on avait développé en 4 ans sur notre plate-forme principale. Le problème avec ce genre de situation, c’est qu’il est très difficile d’établir un plan de marche : On a beau tronçonner les projets en tous petits bouts, il reste toujours des zones d’ombre. Les projets développés durant la «période start-up» manquaient évidemment de spécifications, et cela s’est fait sentir le jour où on a voulu lister toutes les fonctionnalités qu’il fallait remettre au propre.
Ces 4 mois de travail ont donc été réalisés sur un mode «best-effort» qui ne peut pas durer très longtemps. Cela consiste à faire de son mieux, donc à se mettre une pression relativement forte en continu, avec les horaires et le stress qui vont de paire. Au final, cela a généré beaucoup de frustrations dans l’entreprise ; chez les informaticiens qui en faisaient beaucoup sans jamais avoir l’impression que c’était suffisant ; chez les «fonctionnels» qui avaient peur que la refonte prenne un retard incommensurable.

Refonte organisationnelle

Une fois cette période passée, le risque était grand de «rester» sur le même rythme de travail… c’est-à-dire sans revenir à de vraies méthodes de travail. Il était donc important de mettre en place une organisation stable.

PLUS »

Classé dans Organisation d'équipe - Libellé , , , , ,

À propos du refactoring

fév21
2011 15 Commentaires Par Amaury

Je vous ai déjà parlé de refactorisation. Voici un retour d’expérience un peu atypique.

Ces derniers mois, nous avons procédé dans mon entreprise à un gros chantier de réécriture de code. Ce chantier a été lancé durant l’été, et s’est déroulé de septembre à décembre, avec une mise en production à Noël. J’ai voulu en parler sur le blog pendant qu’on bossait dessus, mais je me suis révisé, préférant attendre la fin de ce travail pour pouvoir faire un vrai retour sur expérience.

Les raisons initiales

Pour commencer, je voudrais vous parler du «combat interne» qui s’est livré dans mon crâne. Parce que je garde toujours à l’esprit une règle importante : Améliorer par évolutions et pas par révolution

Cette règle est un garde-fou salvateur. Quand on rencontre des difficultés pour faire évoluer un développement, il est souvent très tentant de tout effacer et de tout recommencer. Mais si cela est envisageable pour un projet personnel, c’est plus difficile à concilier avec les nécessités économiques d’une entreprise. Néanmoins, nous sommes quand même repartis d’une feuille quasi blanche. Comment est-ce arrivé ?

Plusieurs événements se sont additionnés les uns aux autres, sur un intervalle de temps d’à peine quelques semaines :

  • Nous avons rencontré des problèmes de performance sur les sites que nous éditons. Plusieurs passes d’optimisation avaient été nécessaires pour atteindre un niveau satisfaisant, mais cela restait inférieur à ce que j’estimais “normal”. Ces soucis provenaient pour la plupart de requêtes SQL mal fichues ; mais après avoir les avoir optimisées, nous nous sommes rendu compte que sur certains aspects nous avions atteint les limites de notre modèle.
  • Nous avions alors du code un peu ancien, qui avait vécu plusieurs évolutions, et qui avait survécu à plusieurs changements dans les choix fonctionnels. Malgré plusieurs refactorisations, le code contenait toujours des scories qui nuisaient à ses performances, mais surtout qui le rendaient de plus en plus difficile à maintenir et à faire évoluer.
  • De nouvelles fonctionnalités devaient être développées, certaines imposant des modifications du modèle de données, et non pas seulement des ajouts. À cela s’ajoutait une refonte graphique des sites, qui impliquait de toute manière de réécrire les «points de contact» entre le code pur et les templates de pages.

Chacune de ces raisons nous poussait à envisager une réécriture partielle de notre code.

J’ai lu un jour un article qui parlait des spécificités des développements open-source. Il contenait un conseil assez intéressant : Si vous voulez écrire un logiciel de bonne qualité − hors de toute notion de rentabilité − il vous suffit de l’écrire, puis de jeter le code et de tout réécrire. Le fait d’avoir été confronté aux problèmes une première fois fait que vous saurez la direction à prendre pour votre développement, en évitant les errements par lesquels vous serez passé la première fois.

Les raisons supplémentaires

Pendant la phase d’analyse technique, pendant laquelle nous réfléchissions aux différents moyens nous permettant d’atteindre nos objectifs, nous avons fini par converger vers une solution technique hybride. Nous avons choisi de mélanger l’utilisation d’une base de données relationnelle (MySQL) et d’une base de données non relationnelle (FineDB, développée en interne). Le but est de concilier le meilleur des 2 solutions : PLUS »

Classé dans Organisation d'équipe - Libellé , ,

Contre les extrémismes coûteux

fév11
2011 10 Commentaires Par Amaury

Ces derniers temps, j’ai eu plusieurs discussions avec d’autres informaticiens, orientées sur des sujets comme les méthodes agiles en général et plus particulièrement les tests unitaires. C’est toujours intéressant de confronter sa propre vision à celle des autres.

Une des choses qui m’a marqué, c’est que plus de la moitié des gens avec qui j’ai abordé le sujet avaient un raisonnement très binaire. C’est-à-dire que pour eux, 100% du code doit être couvert par des tests unitaires. C’est comme ça, ça ne doit pas être autrement. C’est simple et clair.

Sauf que… Cette vision des choses me gêne pour 3 raisons.

1. Le coût

Écrire des tests unitaires prend du temps. Cela a donc un coût. Tester l’intégralité du code oblige donc à y consacrer beaucoup de temps, ce qui augmente considérablement le budget en développement.

Le contre-argument habituel est de dire qu’en faisant appel au TDD (test driven development, dont je vous ai déjà parlé par le passé), ce coût est réduit. Ceci n’est pas complètement vrai : Le TDD force à commencer par écrire les tests, donc on est certains qu’ils existent. Au passage, on se creuse un peu la tête pour essayer d’imaginer les différents cas d’utilisation (légitimes ou générant des erreurs) dans lequel le code pourrait se retrouver. Mais le principe même des méthodes agiles, c’est de dire qu’on aura plus d’expérience demain ; donc il faudra forcément compléter ces tests au fil du temps. Ce qui ne pourra se faire qu’en cours de développement, voire même après les développements. Je connais beaucoup de développeurs qui utilisent la méthode TDD, et tous confessent devoir compléter leurs tests après coup.

Donc nous sommes d’accord, ça prend du temps, l’air de rien, et donc ça coûte cher. Il est inévitable de confronter ce coût à son utilité. C’est vrai, ça ; à quoi servent les tests unitaires ?

  1. Augmenter la stabilité des développements.
  2. Réduire les bugs de régression.
  3. Rendre le travail des développeurs plus confortable.

Le deuxième point découle du premier. Un code plus stable, qui se vérifie automatiquement, sera plus robuste face à des bugs de régression. Une fonctionnalité qui marche bien à un moment donné, mais qui se met à déconner à cause d’un effet de bord provoqué par un nouveau développement, ça arrive tous les jours. Les tests unitaires permettent de détecter cela au plus tôt et réduisent donc les risques.

Par contre, le troisième point me laisse un peu songeur. Je reste assez froid quand un informaticien me dit «Oui, mais avec 100% du code qui est testé, c’est beaucoup plus confortable pour nous !».
Certes, c’est vrai (encore que, voir plus bas). Mais sincèrement, même si je suis le premier à penser qu’une entreprise doit se soucier réellement du bien-être de ses employés, est-ce que le confort dont on parle vaut automatiquement le coût de l’écriture de tous ces tests ? Une entreprise a pour but de générer des bénéfices ; cela veut dire que chaque investissement doit être jugé à la lumière de ce qu’il va rapporter − ou de ce qu’il permettra de ne pas perdre (car si les tests unitaires ne font pas gagner d’argent, ils peuvent vous éviter d’en perdre beaucoup).

Tout ça pour dire qu’un développeur ne peut pas simplement dire que pour chaque heure de développement effectuée il lui faudra systématiquement une heure d’écriture de tests. Tout dépend du développement en question. En fait, c’est la même chose pour beaucoup d’autres points. Il y a des projets qui ne sont pas critiques pour l’entreprise, et pour lesquels on se permet tous les jours de faire l’impasse sur la qualité globale, la documentation, les tests ou autre chose. Tout simplement parce que l’important est de se confronter rapidement au marché, et que si le coût est élevé, le projet n’a alors plus lieu d’être.

2. La poudre aux yeux

Les tests unitaires ont toujours une part de “poudre aux yeux”. Ils peuvent donner un faux sentiment de sécurité. Le code est testé de manière automatique, alors on se repose sur la certitude que toute régression est impossible.

Oui, mais non. Il ne faut pas oublier que tester 100% du code ne veut pas dire que le code est testé à 100% (subtile nuance).

PLUS »

Classé dans Organisation d'équipe - Libellé , , ,

Les emails en entreprise… encore

fév09
2011 15 Commentaires Par Amaury

J’ai entendu ce matin à la radio une information qui m’a fait bondir (et un peu rigoler). Atos va arrêter l’usage des emails, pour privilégier la communication directe entre ses collaborateurs, tout en mettant en place des outils de communication instantanée. L’argument utilisé est que les collaborateurs reçoivent 200 emails par jour en moyenne, et qu’ils perdent un temps incroyable à les lire (je ne me souviens plus, mais quelque chose comme une vingtaine d’heures par semaine).

Bon, vous connaissez déjà un peu mon avis sur la question (voir aussi cet article).

Oui, devoir lire plusieurs centaines d’emails par jour empêche de travailler efficacement. Mais le problème vient de l’utilisation qui en est faite. Comme je le disais dans un précédent article, les emails ne doivent pas servir de support de gestion de projet, ni de partage de fichiers, ni de liste de tâches. Je ne peux pas concevoir de travailler correctement en étant noyé sous 200 emails quotidiens. Impossible. C’est pour ça qu’on utilise dans mon entreprise des outils correspondant à chaque usage (et c’est pour ça que ceux qui s’amuse à spammer inutilement se font rappeler à l’ordre).

À la radio ce matin, quelqu’un expliquait à un moment qu’il se retrouvait parfois à envoyer des emails à des gens qui sont dans le même bureau que lui, parfois qui sont assis en face de lui. Hum… Il faudrait peut-être commencer par là ? Non quand on a un truc à se dire, on commence par lever notre cul de notre chaise. Ça a l’air bête, hein, mais c’est tellement plus productif !

La réponse technologique m’étonne aussi. Vouloir remplacer les emails par des «outils sociaux» me laisse songeur. La messagerie électronique et la messagerie instantanée sont complémentaires, mais pas en concurrence ; ils correspondent à des usages et des besoins différents. Les forums de discussion peuvent être très utiles en entreprise, pour mener à bien des prises de décision par des équipes projet qui sont dispersées géographiquement. Est-ce pour autant qu’il faut abandonner les emails ?
En plus, j’espère que vous serez d’accord avec moi : la plupart du temps, il est plus rapide et efficace d’avoir une bonne discussion en face à face ou par téléphone, plutôt que de perdre du temps à taper au clavier. Cette remarque est valable aussi bien pour les emails que pour le “tchat” ou les forums de discussion.
Vouloir remplacer l’email, qui est non-intrusif, par de la visio-conférence ou par la messagerie instantanée  ? Cela restera un effort aussi vain que d’avoir voulu remplacer le téléphone par ces mêmes outils. Ils sont tous voués à se développer en parallèle, s’enrichissant les uns les autres sans pour autant se remplacer les uns les autres.

Je me pose une question : Comment les commerciaux et les chefs de projets d’Atos vont faire pour discuter avec leurs clients ? Ils vont systématiquement imposer leurs outils de communication ? Sans rire ?

Alors évidemment, il y a des choses à améliorer dans le courrier électronique. Aussi bien dans son aspect technique que dans son utilisation :

  • Le simple fait de voir les messages comme une discussion, tel que le fait Gmail, évite les redites inutiles.
  • Les entreprises peuvent définir des règles d’écriture des messages internes, avec des normes concernant les titres des messages, pour s’y retrouver plus facilement.
  • Et évidemment, il faut mettre en place des passerelles entre les différents moyens de communication, pour aider les utilisateurs à monter en compétence sur les outils les plus adaptés à chaque besoin.

Ça vaut ce que ça vaut, mais j’ai travaillé dans des entreprises qui ont fait des tentatives d’utilisation de messagerie instantanée. Le résultat était simplement que 80% des messages échangés n’avaient absolument rien de professionnels, et que ces outils étaient majoritairement utilisés pour prolonger les discussions entamées durant la pause-café sans se faire attraper par la hiérarchie. Un peu comme ceux qui gardent une fenêtre ouverte sur Facebook dans un coin pour discuter tout au long de la journée…

Classé dans Organisation d'équipe - Libellé , ,
« Billets plus anciens