De la gestion de projet à la gestion de workflow

Il y a une chose qui me chiffonne lorsqu’on s’intéresse aux méthodologies agiles, telle qu’elles sont définies « by the book », ou telle qu’elles sont enseignées. On y décrit un fonctionnement à base de sprints de développement, qui s’enchaînent les uns après les autres, avec une durée de l’ordre de la quinzaine de jours. Même en décrivant la partie qui se situe en amont du développement (écriture de user stories, gestion du backlog), et celle qui se situe en aval (tests, validation, mise en production), tout reste centré sur le développement.

Au final, dans la vraie vie, ces périodes de conception et de validation finissent par manger sur la période de 2 semaines qui devrait être consacrée au développement. On se rend compte assez vite des limites du système…

De mon point de vue, il faut prendre la gestion de projet à un plus haut niveau. Et il faut définir un workflow global, qui va permettre à tous les intervenants du projet de savoir ce qu’ils ont à faire et pour quand. Je vais illustrer cela en expliquant ce qui est mis en place dan mon entreprise ; c’est le fruit d’un process dérivé de la méthode Scrum, qui est affiné sans cesse depuis plus de 5 ans. Continuer la lecture de « De la gestion de projet à la gestion de workflow »

Manymoon

Manymoon est un web-logiciel de gestion de projet. Il a fait un peu parler de lui ces derniers jours, suite à l’ouverture de la plateforme Google Apps à des applications tiers ; Manymoon y est montré en exemple d’application très utile pour les entreprises qui utilisent Google Apps.

Il n’en reste pas moins que Manymoon peut s’utiliser directement, sans passer par la plate-forme de Google.

Fonctionnalités

Manymoon est à la base assez classique dans son approche : On y crée des projets, auxquels on peut ensuite ajouter des éléments.

Tâches : Chaque tâche possède au minimum un titre, et on peut y ajouter une pièce-jointe (voir plus loin), un ordre de priorité, une date limite (voir plus loin), des tags, et un commentaire. Les tâches sont ensuite listée de manière à pouvoir facilement ajouter des commentaires, réassigner la tâche ou la remettre à plus tard. L’édition d’une tâche se fait en cliquant sur son titre, ce qui fait apparaître une pop-up contenant tous les champs modifiables.

Manymoon - Tâches

(image © Manymoon)

Jalons : Il est possible de créer des jalons, constitués d’un titre et d’une date limite. Ils agissent comme des groupes de tâches, permettant de voir d’un coup d’œil les grandes étapes d’un projet. On déplace les tâches d’un jalon à l’autre (ou en-dehors de tout jalon) par drag’n drop.

Manymoon - Jalons

(image © Manymoon)

Micro-blogging : C’est à la mode, et c’est au centre de l’utilisation de l’outil. Il est possible d’ajouter facilement des messages, en y ajoutant une pièce-jointe, un lien ou un événement. Il est aussi possible de juste signifier que l’on travaille sur un projet, voire une tâche. Ces messages s’affichent dans le “bulletin” du projet, qui affiche en plus toutes les actions effectuées (ajout ou modification de tâche, création de jalon, etc.).

Manymoon - MicroBlog

(image © Manymoon)

Continuer la lecture de « Manymoon »

Lancement du projet Skriv

J’en parlais récemment dans le post concernant l’avenir de ce blog : Je réfléchis à l’idée de développer un outil de gestion de projet ouvert à tous.

Quasiment depuis que je travaille, j’ai développé des outils pour suivre les projets ou traiter les bugs. Comme j’ai souvent bossé dans des entreprises de petite taille, pour ne pas dire des start-ups, ces outils comblaient des manques évidents et étaient adoptés rapidement.

  • Il y a maintenant un paquet d’années, j’avais fait un gestionnaire de buglist. Doté d’une interface web, il était écrit en C et stockait ses données dans un fichier XML. Technologiquement, ce n’était pas une très bonne idée, mais c’était l’occasion de tester des librairies XML et CGI que j’avais écrites en C. Au niveau des fonctionnalités, je ne me souviens plus trop. Je crois que c’était assez simple, avec pour chaque bug le niveau de criticité, une description, et le projet affecté.
  • J’avais par la suite repris le même genre d’outil, mais écrit en PHP/MySQL. Pus facile à faire évoluer, je n’ai pas souvenir qu’on l’ait utilisé à son plein potentiel.
  • Dans mon entreprise actuelle, j’ai dès le début mis en place des outils open-source, les plus important étant Flyspray pour la buglist et MediaWiki pour le wiki. Depuis, j’ai développé des extensions MediaWiki qui nous servent à gérer les projets. Ainsi, chaque projet a une page dédiée sur laquelle apparaissent : la liste des bugs du projet, une liste de tâches, des pages wiki liées au projet, et des fichiers en « pièce-jointe ».

Cette extension est clairement inspirée par Backpack. J’aime vraiment ce logiciel. Par rapport à d’autres outils plus orientés « projet », comme Basecamp par exemple (pour reprendre un autre logiciel développé par 37signals), j’apprécie le fait que toutes les informations soient regroupées sur une seule page.
Habituellement, les logiciels de gestion de projets offrent plusieurs vues différentes, chacune pour un type d’information. Il y a un onglet pour les tâches, un onglet pour le calendrier, un onglet pour les bugs (si l’outil les gère), un onglet pour les pages de wiki (si c’est disponible), un onglet pour les fichiers, et ainsi de suite.
Pour ma part, je préfère avoir la vue la plus « intégrée » possible. Cela implique de penser l’interface en conséquence, ce qui peut s’avérer plus délicat qu’il n’y paraît.

Je cherche donc maintenant à définir un outil que je pourrais utiliser aussi bien pour mes besoins en entreprise, que pour gérer mes projets personnels. Je vais donc m’intéresser à chaque aspect d’un tel logiciel dans une série de billets sur le blog. Je ferais appel aux avis des lecteurs du blog, en espérant réussir à dégager des principes clairs de fonctionnement. J’espère aussi trouver le temps de développer ce logiciel, pour que tout cela ne reste pas théorique (d’un autre côté, si un autre outil est développé à partir de spécifications dérivées de mes idées, je n’y verrais aucun problème, bien au contraire).

Ah, au fait, pourquoi appeler ce projet «Skriv» ? C’est un nom que j’affectionne, que j’ai donné par le passé à plusieurs logiciels que j’ai développé. Le plus important était une interface web qui intégrait un webmail, un gestionnaire de bookmarks, un bloc-notes, un carnet d’adresses, une gestion de compte bancaire. Je l’utilisais tous les jours pour centraliser ma vie numérique. De nos jours, c’est assez commun ; mais à l’époque où je l’ai développé (en 2002), c’était assez novateur.
Pour le nom lui-même, il signifie « écrire » dans plusieurs langues comme le breton et le suédois. Ça va bien dans l’idée d’un outil qui sert principalement à communiquer.

Les premiers enseignements de Rework

J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.

“Dès que possible” est un poison

Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

  • La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
  • À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
  • À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».

Continuer la lecture de « Les premiers enseignements de Rework »

Simple GTD

Je vous ai déjà fait une introduction à la méthode GTD (Getting Things Done) de David Allen. C’est une méthode d’organisation personnelle très efficace, mais qui réclame une discipline et une rigueur constantes, qui peuvent être usantes à la longue.

Je suis tombé il y a quelques temps sur un article très intéressant du site WebWorkerDaily, qui présente une alternative simplifiée. Cette alternative ne concerne que la partie de « tri » des tâches. Il semblerait qu’elle soit extraite du livre Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent de Stephen R. Covey.

Le tri de tâches GTD

Souvenez-vous, voici les étapes imposées par le GTD, pour trier les informations entrantes (et j’ai déjà pas mal simplifié les choses) : Getting Things Done - déroulement

Le tri de tâches simplifié

Maintenant, l’alternative évoquée sur WebWorkerDaily propose de trier les tâches suivant 4 possibilités simples :

  • UI : Urgent – Important
  • NUI : Non Urgent – Important
  • UNI : Urgent – Non Important
  • NUNI : Non Urgent – Non Important

Continuer la lecture de « Simple GTD »

La refactorisation

La refactorisation est un exercice qui devrait être maîtrisé par tous les développeurs, encadré par tous les chefs de projets et encouragé par tous les directeurs techniques.

Le refactoring, qu’est-ce que c’est ?

Derrière cet affreux anglicisme se cache le fait de réécrire du code qui a déjà été développé. Le but n’est donc pas d’ajouter de nouvelles fonctionnalités, mais plutôt d’assurer un suivi de l’existant, de faire un ménage qui en facilitera la maintenance.

Nous nous sommes tous retrouvés un jour ou l’autre devant des bouts de code sans queue ni tête, manifestement écrits à la va-vite, ne respectant aucune norme, avec une documentation périmée, sans commentaire, ou truffés de code mort. À chaque fois, nous sommes horrifiés. Dans le meilleur des cas, on se souvient des raisons historiques qui ont conduit à cela (« Ah oui, ça date du projet X, qu’on avait dû faire à toute vitesse il y a 2 ans ») ; dans le pire des cas, on va retrouver le responsable de cette horreur pour lui passer un savon.

Mais la bonne attitude, c’est d’organiser l’amélioration de ce code. Il faut garder en tête qu’on ne travaille pas continuellement sur les mêmes fichiers. Ce qu’on est en train de développer un jour sera utilisé pendant des mois voire des années sans qu’on revienne dessus. Mais au fil du temps, le code ancien devient « friable » : chaque correction de bug devient plus délicate et sujette aux bugs de régression ; chaque ajout de fonctionnalité prend de plus en plus de temps et devient plus difficile.

Je vais faire un parallèle avec la construction immobilière. Quand on construit une maison, on commence par faire les fondations, puis on monte les murs extérieurs, puis le toit et enfin les cloisons intérieures. Quand on développe un logiciel, c’est un peu la même chose ; chaque développement, chaque ajout de fonctionnalité, s’appuie sur des objets ou des librairies qui doivent rester fiables dans le temps. Il faut donc pouvoir revenir à tout moment sur n’importe quel bout de code, accéder à sa documentation, lui ajouter de nouvelles capacités, voire résoudre des bugs qui ne s’étaient encore jamais déclarés.
Parce que le jour où vous faites tomber des cloisons, vous ne devez pas devoir refaire les murs extérieurs ; et si vous ajoutez une étage à votre maison, vous devez pouvoir faire confiance à la chape de béton de vos fondations.

Comment s’y prendre

On peut découper un refactoring en 4 étapes précises. Les trois premières sont importantes et nécessaires, alors que la dernière est à mettre en oeuvre si le besoin s’en fait sentir uniquement.

Continuer la lecture de « La refactorisation »

Gantter

Gantter est un logiciel de gestion de projets très étrange. C’est un outil web, mais il offre les fonctionnalités basiques (les plus utiles) de Microsoft Project. Il ne faut pas y chercher la moindre capacité de travail collaboratif. En plus de cela, il n’y a pas besoin de se créer un compte pour l’utiliser : connectez-vous sur le site, et vous tombez immédiatement sur l’interface du logiciel. Quand vous avez terminé, vous sauvegardez et enregistrez en local un fichier que vous pourrez réimporter par la suite.

(image © Gantter.com)

Les fonctions sont celles qu’on attend :

  • Créer des tâches et gérer leur état d’avancement.
  • Créer des ressources (humaines et matérielles), les affecter aux tâches et gérer leurs calendriers.
  • Gérer les priorités des tâches et leurs dépendances les unes par rapport aux autres.
  • Définir des jalons et des deadlines.
  • Afficher le planning sous forme de diagramme de Gantt.

À cela s’ajoutent un import/export au format Microsoft Project, qui facilite la transition pour les équipes qui l’utilisent et qui souhaitent changer. Il faut noter que l’interface est traduite en français ; si votre navigateur est correctement configuré, tout s’affichera automatiquement dans votre langue.

Au premier abord, Gantter semble être un outil très sympatique. On ajoute des tâches, on les ordonne, on les trie, en gère leur avancement. Et l’affichage du Gantt est facilement compréhensible par tout le monde. Cela paraît être le complément idéal pour des outils qui n’offrent pas de visualisation graphique des tâches, comme Basecamp, Taskii ou Collabtive.

Mais après l’avoir utilisé un peu, on finit par y trouver plus d’inconvénients que d’avantages. Principalement, je lui reproche le manque d’édition « à la souris ». Chaque fois que l’on veut modifier une tâche, il faut cliquer dessus et éditer des valeurs au clavier. C’est affreux, alors qu’on voudrait pouvoir déplacer les tâches à la souris ; on voudrait changer leur durée ou leur ordre en un simple cliqué-déplacé. Ce serait facile et rapide ; mais là, on est sans cesse freiné.

Sans parler de quelques bugs mineurs. Je n’ai pas réussi à créer de résumé de tâches (pourtant indiqué dans la documentation)

En l’état actuel des choses, il est donc difficile d’utiliser Gantter pour un réel usage professionnel. Mais c’est un service encore assez jeune, qui a le potentiel pour s’améliorer rapidement. L’idée initiale est assez bien trouvée, reste à voir vers quoi elle va conduire

Edit du 26 mai

Après avoir échangé quelques emails avec Volodymyr Mazepa, le créateur de Gantter, il apparaît que la création de résumés de tâches est très simple. Il suffit d’indenter les sous-tâches. La tâche « parente » devient alors un résumé.

Scrum : introduction

Scrum est une méthode de gestion de projet très intéressante. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l’un de ses concepts-clés : les sprints.

Scrum est une méthode agile qui ne se focalise pas spécialement sur les techniques de développement, mais plutôt sur l’organisation de projet et la gestion d’équipe. C’est une méthode moderne qui a fait ses preuves dans de nombreuses circonstances.

Présentation des rôles

L’image suivante présente d’une manière assez synthétique les différents rôles qui interviennent dans une équipe Scrum :

Scrum

(image © Avangel, Wikipedia)

  • Le directeur de produit : (aussi appelé Product Owner) Je préfère utiliser le terme de chef de projet fonctionnel. Son rôle est de présenter à l’équipe les fonctionnalités qu’elle devra développer, et de transmettre l’ordre de priorités. Il opère un suivi régulier avec l’équipe de développement, et remonte régulièrement les informations d’avancement au client.
  • Le Scrum Master : C’est un personnage très spécial qui prend en charge tous les aspects non techniques pour « protéger » l’équipe, particulièrement pendant les périodes de sprint (voir plus bas). Toutes les requêtes doivent passer par lui, pour s’assurer du respect de la méthode. C’est un rôle qu’on pourrait approcher de celui que je tiens – en tant que directeur technique – vis-à-vis de mes développeurs (hormis que je gère en plus des aspects techniques comme la validation des spécifications techniques).
  • L’équipe de développement : La théorie voudrait que l’équipe soit auto-gérée, et que ses membres prennent eux-mêmes leurs décisions de manière collégiale. D’expérience, j’ai rarement vu une équipe fonctionner correctement quand on la laisse faire ce qu’elle veut. Pour que ça fonctionne, il faut avoir des développeurs très compétents, avec de l’expérience, et surtout qui apprécie les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes…

Les sprints

Au coeur de Scrum, il y a la notion de sprint. Le principe est de définir un lot de fonctionnalités à développer, puis de partir dans une phase de développement de durée « raisonnable » (2 à 4 semaines). Évidemment, l’ensemble des fonctionnalités doit avoir été prévu pour pouvoir être développé dans ce laps de temps.

L’important dans cet exercice, c’est de bien comprendre – et surtout faire comprendre aux autres acteurs – qu’une fois qu’on a défini la liste des fonctionnalités et qu’on a écrit les spécifications fonctionnelles, on entre dans une phase de quelques semaines pendant laquelle il est absolument interdit de changer les objectifs de développement. Cela a pour effet de pousser les clients à bien spécifier leurs besoins, car une fois que le sprint est lancé, il n’est pas possible d’ajouter de nouvelles fonctionnalités ni de changer l’ordre de priorité.

Continuer la lecture de « Scrum : introduction »

5pm

Dans le groupe des logiciels de gestion de projet qui font parler d’eux actuellement, et qui tentent de dépasser Basecamp, 5pm fait partie du groupe de tête et sa notoriété semble croître.

Interface principale

L’interface de 5pm est à la fois impressionnante et déroutante. Contrairement aux autres outils du même genre, elle fait un grand usage du Flash pour proposer un dynamisme et une réactivité améliorés.

La fenêtre principale est séparée en 2 parties :

  • À gauche, la liste des projets (et des tâches « autonomes », non attachées à un projet).
  • À droite, les informations concernant le projet sélectionné, ses activités (toutes les actions qui ont été effectuées sur le projet), et les fichiers qui y sont liés.

5pm - écran principal

L’affichage dans le panneau de gauche permet de voir rapidement les projets et leurs tâches, dans une vue arborescente à 2 niveaux facile à comprendre. On y voit par défaut l’état de progression des tâches et le nombre de jours qui reste pour les accomplir.

Continuer la lecture de « 5pm »

L’estimation du travail

Quand on veut planifier son travail ou celui de son équipe, il faut obligatoirement commencer par faire une estimation du temps nécessaire pour réaliser chacune des tâches qui sont listées. Et c’est souvent un casse-tête, car on ne sait jamais par quel bout s’y prendre.

Nous allons voir les raisons qui doivent vous pousser à réaliser des estimations, les réactions les plus récurrentes, et les pistes à suivre pour y arriver.

À noter : J’avais commencé à écrire ce texte au sein d’un article consacré à la planification et aux approches top-down et bottom-up. Mais un article présent dans le dernier numéro du magazine PHP Architect (très bon magazine canadien, en anglais) m’a convaincu d’y consacrer un billet à part entière. Le sujet est intéressant.

Les motivations

On peut voir plusieurs aspects qui conduisent à la nécessité d’estimer préalablement la durée d’une tâche ou d’un projet :

Continuer la lecture de « L’estimation du travail »