Gestion de projets de développement logiciel

Un projet logiciel a deux traits qui le rendent difficile à mener : le travail est invisible (personne ne voit un module avancer avant qu’il soit montré) et le périmètre bouge (ce que le client imagine au départ n’est pas ce qu’il veut en voyant la première version). Bien le mener demande trois choses : un plan par phases que l’équipe et le client comprennent, un tableau de travail qui rend visible l’état de chaque élément, et un contrôle des heures et des changements qui ne dépende pas de la mémoire.

Les phases d’un projet logiciel

PjMan propose un modèle de projet « Développement logiciel » en six phases :

1. Discovery : comprendre le problème, les utilisateurs et le périmètre avant de construire quoi que ce soit.
2. Conception : décider de ce que sera la solution, de l’architecture à l’expérience d’usage.
3. Développement : construire le produit, généralement par incréments.
4. Tests : vérifier que cela fonctionne et fait ce qui a été convenu.
5. Déploiement : le mettre en production.
6. Support : maintenir, corriger et assurer le service une fois en usage.

À la création du projet, vous choisissez le modèle et ses phases sont copiées dans le projet, avec leur code (F001, F002…). Ce sont des copies indépendantes : vous pouvez les renommer, les réordonner, en ajouter d’autres (par exemple une phase par version ou par module) ou supprimer celles dont vous n’avez pas besoin, et chaque phase accepte des sous-phases jusqu’à trois niveaux. Si vous modifiez ensuite le modèle, les projets déjà créés ne sont pas touchés. (Créer un projet, Données de référence)

Si vous travaillez par itérations, le modèle n’est qu’un point de départ : vous pouvez créer une phase par itération et répéter votre propre séquence dans un modèle personnalisé.

Ce qui tourne souvent mal

• Le périmètre grandit sans que personne ne le décide. Chaque « pourrait-on ajouter… ? » semble petit ; ensemble, ils retardent la livraison.
• Les estimations sont optimistes. Et les écarts se découvrent à la fin, quand il n’y a plus de marge.
• Les anomalies se mélangent aux améliorations. Un défaut bloquant et une idée pour plus tard finissent dans la même liste.
• Le travail se bloque sans qu’on le remarque. Une tâche « en cours » depuis trois semaines est un signal que personne ne voit dans une liste à plat.
• Les décisions se perdent dans les messageries. Ce qui a été convenu, et pourquoi, se retrouve enfoui.
• Le support absorbe l’équipe qui devrait construire la suite.

Comment PjMan vous aide

• Un tableau Kanban des tâches. Chaque colonne est un statut et chaque carte une tâche, avec sa priorité, sa phase, son échéance, son avancement, ses heures et ses affectés. Glisser une carte change son statut, avec possibilité d’annuler, et l’on peut filtrer par phase, personne, priorité ou étiquettes. (Tableaux Kanban, Kanban et Gantt)
• Des étiquettes par projet. Marquez tâches et incidents avec ce dont vous avez besoin (un module, une version, « revue client ») et filtrez-les dans les tableaux et dans Requêtes. (Étiquettes)
• Heures par phase et écart. Chaque tâche porte des heures estimées, l’équipe saisit les siennes et chaque phase affiche saisies contre estimées ; l’en-tête du projet donne l’écart total. L’avancement est pondéré par les heures. (Guide sur la saisie des heures)
• Des incidents séparés des tâches. Les anomalies sont enregistrées comme incidents, avec gravité et priorité comme axes distincts, affectés, heures et statuts configurables ; ils ont leur propre tableau Kanban. (Incidents)
• Demandes de modification. Chaque demande hors périmètre est enregistrée avec son effort estimé et sa décision, au lieu d’être absorbée en silence. (Demandes de modification)
• Commentaires avec mentions. Chaque tâche, phase et incident a son fil, où @ prévient dans l’application celui qui peut voir cette fiche. Les commentaires forment un historique : ils ne se modifient ni ne se suppriment. (Commentaires et mentions)
• Plan et travail. Le diagramme de Gantt des phases (en lecture) et le tableau Kanban, sur les mêmes données.
• Assistant. Créer des tâches, saisir des heures ou changer des statuts en parlant ou en écrivant, avec une carte de confirmation, et analyse de l’état du projet. Il répond avec le modèle gratuit ou avec votre propre clé.
• Chaque rôle voit ce qui le concerne. Le PM mène le projet, la direction voit le portefeuille en lecture et chaque développeur voit ses tâches.

Un point de départ, pas un moule

Une équipe qui travaille en sprints, une qui livre par versions et une qui maintient un produit n’organisent pas leur travail de la même façon. Ajustez les phases à votre manière de livrer, créez votre propre modèle si vous répétez le même schéma, et gardez l’essentiel : peu de phases, des tâches estimables et un tableau tenu à jour. Le guide diviser un projet en phases et sous-phases donne des critères pratiques pour cela.

Essayez

Créez votre compte, créez un projet avec le modèle « Développement logiciel » et passez vos premières tâches sur le tableau. Ou explorez la démo, qui comprend des projets d’exemple.