Au cours des quatre premiers volets de notre étude, nous avons vu que les solutions propriétaires sont aujourd’hui concurrencées par les solutions Open Source, quel que soit le secteur.
En se basant sur une série d’études menée dans les domaines les plus représentatifs de l’informatique d’entreprise, Clever Age propose un décryptage des principales tendances du marché, des retours d’expériences significatifs, une présentation d’architectures types, ainsi qu’une sélection de critères permettant de se poser les bonnes questions au moment de choisir une solution.
Ce volet concernera les outils de suivi de projet. Le sixième volet de notre analyse se penchera lui sur les frameworks de développement PHP.
Les tendances du marché
Au sein de la vaste famille des outils collaboratifs (qui comprend en outre les outils de gestion électronique de documents, les outils de Workflow, les outils de messagerie, les agendas partagés, etc.), les outils de suivi de projet occupent une bonne place. Entre le simple planificateur de tâches et l’extranet projet rassemblant tous les éléments utiles au pilotage d’un projet, l’éventail des applications est large. Parmi les fonctionnalités les plus intéressantes, citons :
- la gestion de tâches (dépendances, diagramme de Gantt),
- le partage de documents,
- les espaces de discussion,
- la gestion des anomalies et demandes d’évolution,
- la gestion des droits d’accès, afin de permettre à tous les acteurs du projets d’avoir accès à l’application.
Il est rare de voir des outils proposant l’ensemble de ces fonctionnalités ; généralement, chaque outil est plus centré sur un aspect particulier (planification ; remontée d’anomalies ; espace de partage documentaire ; etc.). Les outils intégrés souffrent pour la plupart d’une certaine pauvreté fonctionnelle comparés aux outils spécialisés.
Les méthodes de développement dites « agiles » (Scrum, eXtreme Programming, etc.) ont favorisé l’émergence d’une nouvelle gamme d’outils, dans lesquels la priorité n’est plus donnée à la planification globale du projet, mais à la gestion de tâches élémentaires. Ces tâches peuvent représenter aussi bien des fonctionnalités à implémenter, des anomalies à fixer ou des actions à réaliser. Articulés autour du concept central de « ticket« , ces outils misent sur la simplicité et la flexibilité (les tickets disposent d’un certain nombre de propriétés paramétrables, comme la personne responsable, la date de création, la date limite prévue, le statut, etc.). Ce type d’outil a vocation a être utilisé à la fois par la maîtrise d’ouvrage et la maîtrise d’œuvre. En Open Source, les deux principaux représentants de cette catégorie sont Bugzilla et Mantis.
Notons enfin les nombreux apports de la mouvance « Web 2.0 » au domaine du suivi de projets. Par exemple, les Wikis sont très utiles pour rédiger en ligne les comptes rendus de réunion, la documentation du projet, etc., tout en s’affranchissant des contraintes liées à l’envoi de fichiers bureautiques et à la consolidation des modifications. De même, un blog peut être un support efficace pour communiquer autour d’un projet (explication des choix techniques, problématiques rencontrées, annonces, etc.).
Un projet Open Source se démarque aujourd’hui par son approche intégrée et sa simplicité : Trac. Outre une gestion de tickets performante, il propose notamment un Wiki ainsi qu’un lien direct avec l’entrepôt de code (au format CVS ou SVN). Une vue permet également de mesurer l’avancement d’un projet au regard de jalons prédéfinis.
Exemples de projets réussis
Clever Age s’appuie sur Trac pour faciliter les échanges avec ses clients
Après avoir utilisé Dotproject (qui souffre de nombreuses limitations, tant sur le plan ergonomique que fonctionnel) pendant plusieurs années, Clever Age a choisi de s’appuyer sur Trac pour faciliter les échanges avec ses clients, que ce soit en mission de conseil ou de réalisation. Un projet interne, baptisé « Clever Box« , a été initié afin de permettre le déploiement rapide d’un extranet dédié à chaque projet. Outre une personnalisation de l’interface, la Clever Box permet de déployer automatiquement une instance de Trac contenant le squelette de toute nouvelle mission (grandes phases, livrables types, etc.).
L’utilisation du Wiki pour la capitalisation tout au long du projet et du gestionnaire de tickets pour le suivi des actions en cours permettent de retracer tout l’historique d’un projet et de faciliter sa reprise en main par une autre équipe le cas échéant (on parle d’intégration « réversible »). Si généralement l’instance est hébergée chez Clever Age (grâce aux scripts d’automatisation, un nouveau déploiement prend à peine quelques secondes), il est possible de l’installer chez un client (les pré-requis sont un simple serveur Web avec un interpréteur Python).
Trac est un projet relativement jeune, il souffre de quelques imperfections (l’interface est en anglais, il n’est pas possible de protéger l’accès à seulement certaines pages du Wiki, etc.) mais constitue néanmoins un outil idéal pour favoriser le travail collaboratif autour d’un projet.
Mantis favorise le dialogue MOA / MOE chez un grand voyagiste
Dans le cadre de la refonte des ses sites internet et intranet, un voyagiste a choisi d’utiliser l’outil Mantis pour gérer toutes les remontées d’anomalies ainsi que les demandes d’évolutions. Grâce à un paramétrage fin, chaque testeur de l’application n’a accès qu’aux parties qui le concernent dans Mantis (Front Office, Back Office, etc.).
Les tickets suivent le cycle de vie suivant (paramétré dans l’outil) :
- Un rapporteur créée un nouveau ticket.
- Le chef de projet qualifie le ticket (anomalie, évolution ou non reproductible).
- Le chef de projet assigne le ticket à un développeur pour prise en charge.
- Pendant toute la phase de correction, des échanges peuvent avoir lieu grâce à l’espace d’échange associé au ticket.
- Lorsque le développeur a terminé la correction, il réassigne le ticket au rapporteur.
- Le rapporteur vérifie que l’anomalie a été corrigée et ferme le ticket.
En outre, Mantis permet d’attacher des fichiers aux tickets, ce qui se révèle très utile pour les captures d’écran.
Architectures types
Architecture fonctionnelle d’un extranet projet
Un extranet projet se compose essentiellement de modules relativement indépendants les uns des autres (tout dépend du degré d’intégration de la solution). Chaque module peut disposer de son propre protocole d’accès (client Web HTTP, client serveur, iCal pour les agendas, Jabber pour la messagerie instantanée, WebDAV pour le partage de fichiers, etc.).
L’architecture de Trac
Un utilisateur se connecte habituellement à Trac via l’interface Web, mais il peut également suivre le déroulement du projet en s’abonnant au flux RSS de la timeline, qui récapitule toutes les actions. Trac s’exécute dans un environnement python (mod_python pour Apache, par exemple). L’authentification peut se faire en utilisant le protocole Basic Authentication, branché sur un annuaire LDAP par exemple. Trac utilise une base de données SQLLite pour stocker les données, et se branche sur un entrepôt Subversion (SVN) au moyen du protocole HTTP ou HTTPS.
Les critères de choix
Le choix d’une solution de suivi de projet dépend principalement du type d’application recherché : s’agit-il d’un outil de planification (une alternative à MS Project par exemple) ? d’un espace de partage de documents ? d’un outil de remontée d’anomalie ? En fonction de l’orientation choisie, un certain nombre de points restent à examiner :
- Modules disponibles : Quels sont les modules proposés avec l’outil ? Ces modules répondent-ils aux besoins exprimés ? Va-t-on devoir ajouter des modules développés en spécifique ? Etc.
- Ergonomie : L’application est-elle facile à prendre en main ? Permet-elle d’être productif ? Convient-elle à la cible des utilisateurs ? Etc.
- Accès en ligne : Peut-on accéder à l’application au moyen d’un simple navigateur Web ? Nécessite-t-elle l’installation de composants spécifiques (plug-ins) ? Etc.
- Paramétrage / personnalisation : La solution offre-elle suffisamment de souplesse au niveau du paramétrage ? Peut-on personnaliser l’interface (changement du logo, application d’une charte graphique maison, disposition des modules, etc.) ? Etc.
- Gestion des droits d’accès : Est-il possible de restreindre l’accès à certains modules ? Peut-on gérer la distinction entre droits en consultation et droits en modification ? Au sein d’un même module, est-il possible de définir des droits d’accès (pages d’un Wiki, catégories de tickets, etc.) ? Etc.
- Multi-projets : La solution permet-elle de gérer plusieurs projets ? Peut-on définir des dépendances entre projets ? Etc.
- Langues : L’interface est-elle disponible en plusieurs langues ? Tous les modules sont-ils traduits dans la langue désirée ? Etc.