PlanZone

AmauryOutils6 commentaires sur PlanZone

Augeo est un éditeur de logiciels parisien, spécialisé depuis plus de 15 ans dans les logiciels de gestion de projets et de portefeuilles de projets. En 2008, cette entreprise a lancé PlanZone, qui est un outil de gestion de projet collaborative sur le Web. Évidemment, ce logiciel entre en concurrence avec la référence du secteur (Basecamp), mais aussi avec les autres challengers (tel que Taskii). Nous allons voir comment il se défend.

Création de projet

La découverte de PlanZone est facilitée par un assistant qui vous guide dans la création d’un premier projet. C’est le premier logiciel de ce type qui me propose de choisir parmi plusieurs modèles de projet, ce qui a une influence sur les étapes de réalisation et le type de tâches à gérer.

Bizarrement, chaque projet doit avoir une date de début et une date de fin.

Information importante : Il est possible de créer un projet en important un fichier Microsoft Project. Je n’ai pas essayé cette fonctionnalité, mais j’imagine que cela doit être pratique pour les équipes qui veulent migrer vers une solution plus agile et collaborative.

Notions et fonctionnalités

Il y a plusieurs aspects qui interviennent dans l’utilisation de PlanZone :

  • L’unité de base est le projet. Comme je le disais plus haut, un projet a un titre, une description, une date de début et une date de fin. Le terme activité est aussi utilisé comme synonyme (c’est assez déstabilisant au début).
  • Un projet peut contenir des sous-activités, qui peuvent elles-mêmes avoir des sous-activités (le tout organisé de manière hiérarchique). On se retrouve donc à gérer des « activités » au sens large, qu’on peut assimiler à des projets et des sous-projets.
  • Une activité peut contenir :
    • des sous-activités (je viens de le dire) ;
    • des ressources, c’est-à-dire des personnes qui vont pouvoir intervenir sur les tâches, avec éventuellement un décompte du temps passé ;
    • des jalons, qui comportent un titre, une description, et une date prévue d’accomplissement ;
    • des tâches, qui comportent un titre, une description, une date butoir, une priorité (basse/normale/haute), et peuvent être affectées à des utilisateurs ou des groupes d’utilisateurs ;
    • des discussions, qui affichent les messages en ordre inversement chronologique (les plus récents en premier).

Affichages des informations

Une vue synthétique présente les principaux aspects d’un projet : le pourcentage de sa réalisation et de celles de ses différents jalons, et la liste des discussions qui s’y rapportent.

La grande force de PlanZone, c’est la vue par diagramme de Gantt. C’est une fonctionnalité très rare dans les logiciels de ce type, ce qui est bien dommage.

(image © planzone.com)

Sus aux emails

AmauryOrganisation d'équipeLaissez un commentaire sur Sus aux emails

Il existe plusieurs méthodes de travail qui s’intéressent à la relation que nous avons avec nos boîtes aux lettres électroniques. Pour n’en citer que deux, je dirais GTD et Zero Inbox, dont le but est d’améliorer le traitement des messages que nous recevons, pour être certain de traiter convenablement les informations reçues. Ce sont des approches très intéressantes, dont je vous parlerai dans de futurs posts.

Pour le moment, je vais vous parler de quelque chose d’autre, qui concerne aussi la manière dont nous utilisons les emails en entreprise. Plus particulièrement, je vais vous expliquer pourquoi il ne faudrait jamais – jamais – échanger de documents de travail par email.

Très souvent, les gens ont tendance à s’échanger les documents (spécifications fonctionnelles, spécifications techniques, listes de choses à faire, relevés de bugs, …) par email. Ça commence par un petit document rédigé par quelqu’un sur son traitement de texte ou son tableur. Voulant que ce document soit lu et utilisé par les autres intervenants du projet, cette personne va donc le leur envoyer par email. Les destinataires vont recevoir le document, le lire, et éventuellement le modifier. Les modifications seront elles-mêmes envoyées par email à toutes les personnes impliquées. Jusque-là, c’est assez clair.

Pourtant, malgré cette clarté apparente, le vers est déjà dans la pomme. Plusieurs pièges classiques peuvent apparaître :

  • Plusieurs personnes modifient le même document, puis le renvoient. Vous vous retrouvez avec autant de versions différentes du même document. Tant que personne n’aura fait le travail de « réconciliation » pour fusionner ces versions, vous allez devoir jongler tel un acrobate.
  • Le premier document aura certainement été nommé en respectant une norme, incluant le numéro de version du document et/ou sa date de création. Mais il y a de fortes chances pour que ceux qui l’éditeront ne pensent pas à modifier le nom du fichier avant de le renvoyer.

Taskii

AmauryOutils3 commentaires sur Taskii

Taskii est un logiciel créé par une entreprise belge, qui surfe sur la mouvance des outils de collaboration en ligne (dont le fer de lance est Basecamp). Dès la première page du site, la couleur est annoncée : « Taskii importe le concept de Basecamp en français » (extrait d’une revue du service effectuée par TechCrunch).

Et c’est vrai qu’on pourrait rapidement synthétiser Taskii en 2 points :

  • Globalement la même ergonomie que Basecamp, mais en français.
  • Globalement les mêmes fonctionnalités que Basecamp, mais moins cher.

L’outil propose 5 fonctionnalités principales :

  • Les todo-lists.
  • La vue calendaire.
  • La messagerie partagée.
  • Le partage de fichiers.
  • Les feuilles de temps.

Le prix

Commençons par le premier facteur différenciant (en dehors de la langue). Taskii est disponible en 5 formules différentes :

  • L’accès gratuit permet de créer 2 projets et offre un espace de 10 MO.
  • L’offre Basic (12 € par mois) permet de gérer 15 projets, apporte 4 GO de stockage et le support par email.
  • L’offre Premium (45 € par mois) monte à 50 projets et 10 GO.
  • L’offre Secure (65 € par mois) ajoute à la précédente l’encryption SSL.
  • L’offre No limit (145 € par mois) offre un nombre illimité de projets, 100 GO d’espace de stockage, l’encryption SSL et le support par email et téléphone.

Comme on peut le voir, les tarifs sont plus bas que ceux auxquels on est habitué. Et même si je persiste à trouver ridicule de faire payer l’encryption SSL, je salue l’effort qui est fait pour rendre accessibles toutes les fonctionnalités dès la création d’un compte gratuit.

Les todo-lists


(image © Taskii.com)

La création de tâches se fait d’une manière très souple. On peut facilement les affecter à un utilisateur, et leur définir une date d’échéance. Il n’est malheureusement pas possible de définir une priorité aux tâches. On peut les réorganiser par drag ‘n drop, mais il est impossible de changer l’apparence d’un titre (même pas de syntaxe wiki pour mettre du texte en gras, par exemple).

Livre : Getting Real

AmauryOrganisation d'équipe4 commentaires sur Livre : Getting Real

Je vous ai déjà parlé de la société 37signals, au travers de ses outils Backpack et Basecamp. Je vais maintenant vous parler du livre qu’elle a publié en 2006 et qui contient toutes les règles de création et de gestion de projets web qu’elle applique en interne : Getting Real, The smarter, faster, easier way to build a successful web application.

Ce livre est disponible :

Le titre du livre est sûrement un gentil jeu de mots avec la très connue méthode Getting Things Done. Ce clin d’œil est une manière à peine déguisée de dire qu’il faut oublier toutes les méthodes existantes, faire table rase et suivre leur direction. Le livre décrit leur propre méthode agile, qui est censée s’appliquer à la réalisation d’applications web, mais peut être utilisée – au moins partiellement – pour d’autres types de projets ou d’organisations.

37signals

37signals a été fondée en 1999, exerçant une activité de web agency. Au cours des années, elle s’est fait connaître en publiant tout d’abord Basecamp, l’outil de gestion de projet utilisé en interne, puis le framework Ruby on Rails sur lequel Basecamp est basé. Depuis, 37signals a sorti plusieurs services en ligne, allant de la gestion de données jusqu’à la relation client, en passant par la messagerie de groupe. Leur blog d’entreprise, Signal vs Noise, qui parle aussi bien des outils édités par la société que de design et de développement web, est très connu et visité.

Flyspray

AmauryOutilsLaissez un commentaire sur Flyspray

J’en parlais dans mon billet consacré aux listes, les buglists sont un élément essentiel dans la gestion des développements informatiques. Impossible de créer un logiciel, quel qu’il soit, sans y introduire des effets indésirables imprévus. Et il faut trouver un moyen efficace de lister ces bugs et de suivre leur résolution.

Je vais vous parler d’un logiciel open-source entièrement dédié à cela : Flyspray

Flyspray - page principale

Présentation

Flyspray est un logiciel développé en PHP, proposé gratuitement sous licence libre. Il est très facile à installer sur un serveur Linux, avec une base de données MySQL ou Postgresql. Ce n’est donc pas un logiciel qui s’utilise à distance sur les serveurs de son éditeur ; pas besoin de payer un abonnement mensuel. Par contre, il faut avoir un serveur à disposition (mais c’est souvent le cas en entreprise).

Basecamp

AmauryOutilsUn commentaire sur Basecamp

Je vais vous présenter aujourd’hui le logiciel Basecamp, qui est développé par 37Signals. C’est un peu le grand frère de Backpack dont je vous parlais la semaine dernière.

Là où Backpack visait à faciliter le stockage et l’échange d’information autour de projets, Bascamp va plus loin et propose des outils pour gérer plus finement le travail de groupe. On peut distinguer 5 fonctionnalités principales :

  • Les todo-lists.
  • La messagerie partagée.
  • Le partage de fichiers.
  • Les objectifs calendaires.
  • « Reporting » du temps passé sur chaque projet.

Auxquelles s’ajoutent des panneaux de vues globales sur un projet ou sur tous les projets.

Les todo-lists

(image © 37signals.com)

Je vous ai déjà expliqué pourquoi les listes sont à la base de toute organisation. Basecamp permet de créer facilement des listes et de les organiser comme on le souhaite. Très similaires à celles de Backpack, on peut éditer leurs titres en utilisant la syntaxe Textile (syntaxe wiki-like simplifiée), et leur affecter un état fait/à faire simplement en cochant ou décochant une case. Par contre, elles offrent la possibilité d’affecter une tâche à un utilisateur, ce qui était un des manques que je pointais du doigt sur Backpack.

Il est aussi possible de créer des listes privées, qu’on est le seul à pouvoir voir. C’est une bonne idée, qui permet d’avoir au même endroit les todo-lists générales et celles qui nous concernent ; cela évite d’avoir à gérer plusieurs systèmes de listes en parallèle.

La messagerie partagée

(image © 37signals.com)

On a beau classer nos emails dans des dossiers, il est toujours pénible d’y rechercher une information intéressante. On est souvent obligé d’ouvrir une demi-douzaine de messages – de quelques lignes chacun – avant de retrouver ce qu’on veut.

Livre : Managing Humans

AmauryOrganisation d'équipe5 commentaires sur Livre : Managing Humans

Je vais vous parler un peu d’un très bon livre, nommé Managing Humans, écrit par Michael Lopp et publié par Apress en 2007. Depuis 2002, il tient sous le pseudonyme de Rands le blog Rands in repose, dans lequel il parle de ses expériences en tant que manager d’équipes techniques. Et il en a des choses à dire, le bougre, après avoir travaillé pour Symantec et Netscape, entre autres.

Managing Humans - couverture

Le sous-titre du livre est assez explicite : « Biting and humorous tales of a software engineering manager ». Le livre est truffé d’anecdotes amusantes, de mises en situation réelles ou imaginaires, qui en font un ouvrage à part dans l’univers très fourni des livres dédiés à la gestion de projet et au management.
Personnellement, j’ai une affection particulière pour ce livre. Je l’ai acheté à sa sortie en 2007, alors que j’étais en train de créer mon entreprise. Je n’y ai pas trouvé de recette miracle, mais plein d’exemples de choses à faire ou ne pas faire ; je pense avoir évité plusieurs pièges dans la création de mon équipe grâce à ce livre.

Ne pas être un con

Le premier chapitre du livre se nomme « Don’t be a prick ». L’ensemble des 209 pages pourrait être résumé dans cette simple phrase. Ça paraît débile tellement c’est simple. Mais au cours de ma carrière, j’ai franchement rencontré tellement de personnes qui agissaient comme des gros cons, que ça mérite d’être souligné. Que ce soit par bêtise, inexpérience, indélicatesse, fainéantise, vanité ou parce qu’ils n’avaient rien à faire à ce poste, il est sidérant de voir combien de dirigeants sont inaptes à gérer les hommes et les femmes qui composent leurs équipes.

Le carquois du management

Rands utilise une métaphore assez intéressante. Il dit que nos compétences en management sont comme des flèches dans un carquois. Quand on rencontre un problème, on peut prendre la flèche appropriée, prendre un peu de recul, viser et tirer. C’est le titre qu’il a donné à la première partie du livre.

Les méthodes agiles

AmauryOrganisation d'équipe26 commentaires sur Les méthodes agiles

Cet article fait suite à ceux consacrés au cycle en V et au cycle itératif. Dans l’histoire des méthodes de gestion de projets informatiques, les méthodes agiles sont une évolution relativement récente qui tente de résoudre certains défauts des pratiques qui étaient en usage jusque-là.

Le manifeste agile

La définition de toutes les méthodes agiles est synthétisée par le Manifeste agile, qui a été rédigé en 2001 par plusieurs acteurs de ce domaine. Il distingue 4 valeurs fondamentales et 12 principes.

Les 4 valeurs

(traduction © Wikipedia et al)

  • L’interaction avec les personnes plutôt que les processus et les outils.
  • Un produit opérationnel plutôt qu’une documentation pléthorique.
  • La collaboration avec le client plutôt que la négociation de contrat.
  • La réactivité face au changement plutôt que le suivi d’un plan.
Les 12 principes

(traduction © Wikipedia et al)

  • Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  • Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  • Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
  • Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  • La méthode la plus efficace de transmettre l’information est une conversation en face à face.
  • Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  • Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Application concrète

Il existe plusieurs méthodes qui suivent l’esprit du manifeste. Elles ont chacune leurs spécificités, mais de manière globale elles œuvrent toutes dans les mêmes voies.

Action Method

AmauryOutils2 commentaires sur Action Method

Je vais vous parler aujourd’hui d’Action Method, qui est le nom d’un web-logiciel d’organisation et de gestion de projets, mais aussi celui de la méthode d’organisation qui y est préconisée et que le logiciel permet de suivre et appliquer.
Cet un bon exemple de la mouvance des nouveaux outils de gestion de projet, qui privilégient la communication et résolution de tâches plutôt que la gestion du temps et le flicage des gens.

Pour la petite histoire, l’entreprise qui est à l’origine de ce logiciel (Behance) a commencé par faire connaître la méthodologie Action Method en vendant des organiseurs papier. Jetez-y un oeil, certains produits pourraient vous intéresser si vous gérez vos projets « à l’ancienne ».

La méthode

Pour bien utiliser ce logiciel, il faut donc comprendre la méthode sous-jacente. Ses idées principales sont :

  • Réduire les échanges de communication (bannir les emails !) au profit de l’action et de la résolution des tâches. Les discussions importantes doivent pouvoir être suivies facilement et non être cachées dans des chaînes d’emails.
  • Partager uniquement les informations qui le nécessitent.
  • Les actions peuvent être déléguées et non assignées ; on ne s’en débarrasse pas.
  • Les fonctionnalités prouvent leur importance par « sélection naturelle ». Voir la notion de harcèlement plus bas.

Cette méthode définit 5 types d’éléments de base :

  • « Action steps » : Actions à réaliser. Devrait toujours commencer par un verbe (« Appeler machin », « Faire ceci », …).
  • Références : Toutes informations (notes, liens, fichiers) liées à un projet qui donne du contexte aux Action Steps.
  • « Backburners » : De simples idées qui ne génèrent pas encore d’action, mais sur lesquelles on veut revenir plus tard.
  • Discussions : Toutes les communications concernant un projet (documents partagés, décisions, solutions aux problèmes, feedbacks, …) sont regroupées au même endroit et sont accessibles aux personnes travaillant sur ce projet.
  • Evénements : Réunions, étapes, occasions particulières, dans le futur du projet. Peuvent servir de deadline aux Action steps.
Le logiciel

La vue globale de chaque projet récapitule tous ces éléments d’une manière assez réussie à mon goût. Les informations sont clairement affichée et facilement accessibles.

Action Method - Page projet (image © actionmethod.com)

Le cycle itératif

AmauryOrganisation d'équipe4 commentaires sur Le cycle itératif

Si vous avez lu mon billet sur le Cycle en V, vous savez pourquoi ce type de méthode de travail n’est pas adapté à la plupart des projets informatiques, qui réclament une plus grande souplesse. En l’appliquant de manière rigide, on finit par obtenir des logiciels mal adaptés (fonctionnalités sans priorités), livrés en retard (chaque étape bloque les suivantes) et souvent buggués (la technique se plie au fonctionnel).
C’est ainsi qu’est née la méthode du cycle itératif (ou incrémental), qui tente de formaliser une approche plus pragmatique et maniable.

Cycle itératif

Définition

Cette méthode se décompose en 6 étapes, dont 4 qui en constituent le « coeur » :

  • L’expression de besoin : Le client explique ce qu’il veut obtenir. On peut faire un parallèle avec l’étape de faisabilité du cycle en V, et dans une moindre mesure avec les spécifications fonctionnelles. L’idée reste que les informations en entrée peuvent être modifiées par la suite du processus.
  • Le coeur du processus itératif :
    • Spécification : C’est la traduction en langage technique des besoins fournis en entrée. C’est la réponse aux questions « qu’est-ce qu’on fait ? » et « comment on va le faire ? ».
    • Développement : Il s’agit de la réalisation concrète de ce qui a été défini.
    • Validation : C’est l’ensemble des tests qui permettent de s’assurer que le développement effectué correspond bien à ce qui était attendu.
    • Évaluation : Cette étape sert à effectuer un retour sur les écueils rencontrés et les fonctionnalités abandonnées pendant les 3 étapes précédentes, et l’utiliser comme informations d’entrée pour un nouveau cycle.
  • Déploiement : Les livrables qui ont été validés sont déployés pour que le client y ait accès.