Le blog d'un geek devenu directeur technique

Billets libellés projets

Skriv : Organisation de l’information

fév16
2011 2 Commentaires Par Amaury

(ce billet fait partie d’un ensemble consacré au projet Skriv)

Cela fait longtemps que je n’ai pas écrit d’article au sujet du projet Skriv.
En ce moment, je cherche un moyen permettant de gérer les projets en autorisant 2 visions différentes :

  • Une vision macro, pour suivre l’avancement global des projets et des sous-projets. Sans avoir le détail de toutes les tâches qui composent chaque sous -projet, il faut savoir quelles sont les deadlines des sous-projets, et éventuellement à quel pourcentage de complétion ils se situent.
  • Une vision micro, pour accéder à toutes les informations liées aux différents sous-projets, les tâches, la documentation, etc.

La vision macro est absolument nécessaire pour prendre des décisions à moyen terme, ou simplement pour avoir une vision synthétique du travail. La vision micro est nécessaire pour tout le travail au quotidien : définir les priorités des tâches, accéder à la documentation, etc.

Découpage des projets

Je me creuse la tête depuis un moment au sujet de la meilleure manière de découper les projets. Avoir un seul niveau d’organisation n’est pas satisfaisant ; on se retrouve à avoir une liste de tâches interminable, sans pouvoir faire de regroupements logiques.

J’aime bien l’idée d’offrir un deuxième niveau d’organisation. Cela semble assez naturel de pouvoir découper un projet en plusieurs sous-projets. Dans ma tête, chaque sous-projet est un ensemble logique pouvant comporter :

  • une ou plusieurs listes (par exemple une liste de tâches et une buglist)
  • une collection de « pages » de wiki (spécifications du sous-projet, documentation technique, checklist, …)
  • un espace de stockage pour des pièces-jointes, elles-mêmes éventuellement réparties dans des sous-dossiers
  • une liste de messages portant sur le sous-projet

Si on suit cette vision, il faut proposer une vision complète au niveau du projet, qui rassemble toutes ces informations de manière agrégée (une liste avec les tâches de tous les sous-projets, toutes les pages de wiki, toutes les pièce-jointe, et ainsi de suite).

Faut-il proposer une organisation plus complexe ? Certain logiciels permettent de créer autant de niveaux de sous-sous-projets que l’on veut. Mais personnellement je trouve ça inutilement complexe ; on s’y perd et la productivité n’y gagne rien.

Informations liées aux sous-projets

Avec ce découpage en sous-projets, il m’est venu naturellement une idée : on pourrait donner une date de début et une date de fin à chaque sous-projet. De cette manière, il serait très facile de représenter graphiquement les sous-projets sur une ligne de temps, de manière à faire une sorte de diagramme de Gantt simplifié. C’est parfait pour la vision macro dont je parlais plus haut.
On aurait donc deux informations très synthétiques associées à chaque sous projet : ses dates de début et de fin, et son pourcentage de complétion (qui serait calculé à partir du statut des tâches faisant partie du sous-projet).

PLUS »

Classé dans Skriv - Libellé ,

Manymoon

mar11
2010 2 Commentaires Par Amaury

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)

PLUS »

Classé dans Outils - Libellé , , , , ,

Lancement du projet Skriv

jan23
2010 11 Commentaires Par Amaury

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.

Classé dans Skriv - Libellé , , , , ,

Des nouvelles du blog pour 2010

jan12
2010 17 Commentaires Par Amaury

Ce blog a été ouvert il y a bientôt un an, c’est le moment de faire un petit bilan.

J’avais créé ce blog parce que je pensais avoir des choses intéressantes à partager. Au début je voulais écrire un livre, mais un blog me semblait finalement une meilleure solution ; plus simple à commencer, plus rapide à faire avancer. Les premiers temps, j’écrivais plusieurs articles par semaine, puis le rythme s’est stabilisé. Le blog a été plutôt bien référencé sur certaines expressions (tapez «cycle en v» ou «cycle itératif» sur Google pour voir), le nombre de visiteurs a augmenté continuellement.

Je tiens à remercier particulièrement toutes les personnes qui ont pris le temps de laisser des commentaires. Non seulement ça fait plaisir, mais cela débouche souvent sur des discussions intéressantes.

Vous avez pu remarquer que mon rythme d’écriture s’est fortement ralenti ces deniers temps. Il y a plusieurs raisons à cela. Les deux principales sont évidemment la naissance de ma fille il y a 3 mois (ça vous change la vie d’une manière qui dépasse tout ce qu’on peut imaginer), et mon implication dans mon entreprise (nous sommes passés de 13 à 22 personnes en l’espace d’un an, avons changé de locaux, je gère sans cesse plus de projets).

Mais il y a aussi d’autres raisons, qui ont un lien direct avec le blog : j’ai en préparation quelques projets qui me prennent du temps.

  • Je suis en train de reprendre le contenu publié sur le blog, pour en faire un livre. Oui, c’est un retour à l’idée initiale. En fait, la matière première du livre est présente sur le blog et il peut être intéressant de recompiler tout ça en une forme plus structurée, moins “bordélique” qu’un blog. C’est aussi une source d’inspiration, dans la mesure où j’identifie les contenus manquants pour le livre et que j’en profite pour écrire sur le blog les articles correspondant. Et je pense pouvoir faire un bouquin vraiment utile (les pavés de 500 pages dédiés à telle ou telle méthode de gestion de projet ou d’organisation personnelle sont majoritairement remplis de vide).
  • Je prépare une présentation «De geek à directeur technique», que je vais exposer dans des écoles d’ingénieur. Le but est de présenter les idées du blog (gestion de carrière, organisation personnelle, gestion de projet, création d’entreprise) d’une manière qui ne soit pas un cours magistral ni la vente d’un concept. La première présentation se tiendra le mois prochain, et j’espère renouveler l’expérience régulièrement.
  • Depuis le temps que je teste des outils de gestion de projet, et que j’en développe pour mes propres besoins professionnels (et pour les besoins des entreprises où j’ai travaillé), je commence à réfléchir à l’idée d’en développer un. En reprenant les fonctionnalités les plus intéressantes, en y injectant quelques principes originaux, je pense pouvoir faire quelque chose d’intéressant et utile. On en rediscutera très bientôt sur le blog, mais sachez que la gratuité d’utilisation et l’ouverture (d’une partie importante) du code sont au cœur de ma réflexion.

Ce blog va donc continuer à exister. Peut-être changera-t-il de forme au cours du temps. Je ne suis pas toujours à l’aise avec le principe même du blog.

  • Je pense avoir des choses à dire. Mais on m’a déjà dit que certains de mes articles avaient un ton un peu trop “professoral”. Cela se comprend si on remet en contexte le livre que je compte écrire. Mais je trouve difficile de garder un ton léger ou personnel lorsqu’il s’agit d’expliquer des concepts théoriques ou factuels.
  • Je suis parfois frustré par le manque d’échange. Très souvent, je souhaiterais discuter certaines idées et concepts ; savoir ce que les autres pensent d’un sujet donné, échanger des propos. Et un blog n’est pas du tout adapté à cela. Faut-il que je mette en place un forum ? (corollaire : connaissez-vous un bon forum sur la gestion de projet ?)
  • Pour partager les liens intéressants, j’utilise Google Reader et Twitter. D’ailleurs, ça m’énerve un peu de dupliquer les choses entre ces deux outils… Bref, n’hésitez pas à vous abonner à mes flux. Faites-moi signe si vous partagez des liens sur Google Reader.

Donc voilà où j’en suis. Il y a beaucoup de projets en cours, tous n’aboutiront peut-être pas, mais ce n’est pas grave. L’important est d’avancer.

Classé dans Sans catégorie - Libellé , , , ,

Les premiers enseignements de Rework

déc12
2009 4 Commentaires Par Amaury

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 !».

PLUS »

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

La R&D : pour ne pas confondre développement et veille techno

août31
2009 Laisser un commentaire Par Amaury

Il y a quelques temps, je vous ai parlé de la veille technologique. Je vous ai expliqué en quoi c’est un élément important de nos vies professionnelles.

Je voudrais cette fois-ci vous mettre en garde contre une dérive finalement assez commune chez les jeunes développeurs, qui est d’utiliser les projets professionnels comme un terrain de jeu pour réaliser leurs expérimentations. Ensuite nous réfléchirons aux moyens de canaliser la fougue qui conduit à ces dérapages.

Les expérimentations au boulot

Il y a quelques années, alors que j’étais chef de projet, un de mes développeurs – un prestataire externe, en fait – avait demandé une demi-journée de congé pour assister à une conférence organisée par Google France. J’étais content de voir qu’il prenait à coeur sa veille technologique.
À son retour, je lui ai évidemment demandé de me faire une présentation rapide de ce qu’il avait vu. Il s’agissait des premières versions des toolkits de Google, et ça avait l’air vraiment intéressant.

Nous étions alors en train de démarrer un nouveau projet, et ce développeur était en charge de certaines spécifications techniques. Quand j’ai vu dans ses specs qu’il envisageait d’utiliser les technologies Google qu’il venait d’entrapercevoir, j’ai eu une petite discussion avec lui.

Le message tient en 2 points :

  • Bien qu’absolument nécessaire, la veille technologie est une démarche personnelle. C’est à chacun de se trouver ses propres petits projets qui lui permettront de tester de nouvelles technos ou de nouveaux outils.
  • Un projet mené au sein de l’entreprise répond à des contraintes contractuelles et financières. Vouloir y glisser des technologies qui ne sont encore qu’à l’état de bêta, ou qu’on ne maîtrise absolument pas, est une erreur assez grave.

Canaliser et organiser

Il n’empêche qu’il n’est pas logique d’inciter à la veille tout en la réprimant dans le cadre de l’entreprise. L’entreprise a certains devoirs de formation vis-à-vis de ses employés, il faut s’en occuper de manière raisonnée et planifiée.

PLUS »

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

Le triangle Qualité, Coût, Délai

juil10
2009 13 Commentaires Par Amaury

Quand on doit choisir la manière d’aborder un projet, il existe 3 notions fondamentales qu’il faut connaître et évaluer : la qualité, le coût et le délai.

Triangle Qualité, Coût, Délai

Comprendre le triangle

  • Qualité : Il s’agit du soin qui est apporté à la réalisation fonctionnelle et technique du projet. Un projet de médiocre qualité remplira les besoins immédiats du client, en s’autorisant un certain nombre de raccourcis. Un projet de bonne qualité aura été spécifié pour couvrir certains besoins futurs identifiables, et offrira une ergonomie adaptée, des performances homogènes, une évolutivité étudiée, une documentation complète.
  • Coût : Un client est prêt à dépenser une certaine somme pour un projet donné. La valeur du projet peut éventuellement s’adapter à un certain nombre de critères, mais il y a forcément un seuil au-delà duquel il est impossible de le rentabiliser. La notion de coût englobe aussi bien les frais d’étude (en fonction du temps passé aux spécifications fonctionnelles et techniques) et de réalisation (suivant le nombre de développeurs nécessaires, le matériel mis à leur disposition, la présence d’une équipe de test et de validation, …), que les frais d’exploitation (matériel nécessaire pour faire tourner le projet en production, salaire de l’opérateur de maintenance, …).
  • Délai : Savoir combien de temps doit durer la réalisation d’un projet n’est pas aisé, même si cela fait partie du travail d’un ingénieur. Certains projets ne sont pas urgents, ni même importants, mais ils comportent forcément une deadline à partir de laquelle ils deviennent caducs.

PLUS »

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

Retrospectiva

mai30
2009 Laisser un commentaire Par Amaury

Retrospectiva est un web-logiciel de gestion de projets. Placé sous licence libre, il n’est pas possible de l’utiliser « directement » ; par contre, il est téléchargeable gratuitement et s’installe assez facilement sur n’importe quel système de type Unix (Linux, Mac OS X, BSD, …) pour peu que vous ayez un minimum de connaissances en administration de serveur.
Ce mode de fonctionnement est similaire à ce qu’on peut trouver du côté de Collabtive.

Fonctionnalités

Les fonctionnalités de Retrospectiva sont réparties en deux groupes : les fonctions de base, et celles qui sont apportées par des plug-ins.

Fonctions de base :

  • Gestion de tickets.
  • Revue de code.
  • Gestion de versions, avec deadlines et étapes d’avancement.

Fonctions additionnelles :

  • Wiki.
  • Blog.
  • Gestion de projet adaptée à la méthode Scrum.

On peut considérer que les fonctionnalités apportées par les plug-ins font parties intégrantes du logiciel. Parce que, de nos jours, un outil de gestion de projet qui ne contient même pas un wiki, c’est trop limité pour être intéressant.

Gestion de tickets

(image © retrospectiva.org)

Les tickets de Retrospectiva permettent de gérer aussi bien l’affectation de tâches (au sens classique du terme) que les relevés de bugs. C’est un des rares logiciels qui fournisse un système de gestion des tâches qui peut aussi convenir à la gestion des bugs, sans que l’ergonomie n’en souffre.

PLUS »

Classé dans Outils - Libellé , , , , , ,

5pm

mai16
2009 Laisser un commentaire Par Amaury

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.

PLUS »

Classé dans Outils - Libellé , , ,

L’estimation du travail

mai06
2009 Laisser un commentaire Par Amaury

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 :

PLUS »

Classé dans Organisation personnelle - Libellé , , , ,
« Billets plus anciens