Bonjour,
Je viens vous présenter une idée qui me trotte dans la tête depuis maintenant des années : trouver une solution de gestion de projets qui s'adapte bien aux petites structures : communautés, PME, startups, … A vocation "projet informatique" et surtout : qui soit utilisable et intéressante pour tous les acteurs du projet et pas seulement les développeurs.
Constats
Etat de l'art
Aujourd'hui, les développeurs disposent d'excellents outils de tracking, presque de gestion de projet. Je ne vais pas les énumérer mais entre Redmine, Jira, Bugzilla pour le bugtracking, github/gitlab qui permettent de partager des sources mais aussi de gérer des tâches et les assigner.
Ces outils sont excellents mais sont destinés à des développeurs. En marge de ça, les logiciels de management sont également nombreux : depuis MS Project jusqu'aux solutions de travail collaboratif en ligne en passant par les solutions très épurées et qui font ce qu'on leur demande, comme Trello.
Bref, l'état de l'art est vaste, mais il est souvent complexe de trouver la bonne solution pour gérer un projet collaboratif "naissant mais qui prend de l'ampleur" ou tout simplement dans une petite structure.
Il manque bien souvent aux outils orientés "dev" la vision "produit". Normal, le livrable est symboliquement du code, souvent ces outils ont été conçus pour gérer des bibliothèques open source, ou autres. Parfois pour un produit, mais "au chausse-pied".
Les faits
Dans les faits, bien souvent les entreprises mettent en place un système d'issue-tracking. C'est la base, c'est incontournable. Dans les petites entreprises, bien souvent cet outil est cantonné aux développeurs, voire à l'équipe "support technique", qui vont éventuellement remonter des bugs dedans.
Dans ces petites structures, le suivi des issues est donc très majoritairement assuré par les équipes de développement, voire de R&D. Et ça se comprend, on y discute technique, implémentation, l'outil n'est pas nécessairement utilisable par des gens d'autres métiers.
Pourtant, quand une réunion se profile, il n'est pas rare de voir des petits rapports imprimés en A4 provenant de l'issue-tracker. Et pour cause, ça permet d'avoir une vue sur le travail en cours.
En marge de cela, chaque "département" (si on peut dire ça pour une petite structure) va adopter ses propres outils pour s'organiser. De la feuille Excel à MS Project, en passant par Trello, la TODO list papier, le Google Doc pour les spécifications, Outlook/Google calendar pour les milestones.
C'est compréhensible, ça n'en reste pas moins un peu dommage.
L'objectif
L'idée est donc de concevoir un outil "méta", par-dessus un système d'issue-tracking, comme il en existe déjà. Avec pour objectif plutôt complexe (voire utopique) de contenter "tout le monde" (comprendre : tous les acteurs du projet)1.
Il est essentiel de fournir à qui que ce soit dans l'entreprise, le moyen de contribuer et surtout de mesurer ses tâches, sa charge de travail, son degré d'implication et l'état d'avancement du projet en fonction du rôle qui l'occupe dans l'entreprise.
Il me semble que c'est le point bloquant concernant le manque d'adoption de ces outils.
En marge de cela, on peut remarquer que même dans de petites structures ou des communautés comme ici sur ZdS, un workflow se détache souvent. Même pour les gens qui se veulent "agile voire bordélique" (c'est du "déja entendu"), un processus de release est nécessaire. Même pour un projet personnel.
Les éléments "fondateurs" du projet sont donc les suivants :
-
l'issue-tracking doit rester au niveau de ce qu'elle est dans d'autres outils type Redmine, JIRA, même si elle est plus simple, on ne doit pas perdre en fonctionnalité majeure
-
quel que soit mon rôle, je dois retrouver mes petits, et ne pas être submergé d'informations qui ne m'intéressent pas
-
je dois pouvoir échanger des documents provenant de sources externes. Sans aller jusqu'à la GED, je dois pouvoir importer des psd, des Google Docs, des wireframes, des fichiers Office
-
je dois pouvoir échanger au maximum dans l'outil afin d'éviter d'envoyer des emails que je devrai trier par la suite. Que je sois commercial, développeur, CEO, l'outil doit me permettre de centraliser les informations échangées dans un soucis de pérennité.
-
je dois être notifié quand quelque chose m'intéresse et uniquement par ce qui m'intéresse. Si je suis commercial, je suis intéressé de savoir qu'une fonctionnalité que mes clients attendent et que j'ai demandée est poussée en prod, pas qu'un bug mineur est résolu.
-
l'interaction avec d'autres outils (intégration continue, …) semble incontournable sur le long terme. Il est donc essentiel de reposer sur des APIs. Comme on s'adresse essentiellement à des gens de l'informatique, ils seront très certainement intéressés et à même de développer une multitude de plugins ou outils complémentaires si besoin est. L'API REST semble s'imposer pour développer l'interface "de base" et permettre des intégrations externes simples.
Bref, ce qui se détache de cela c'est une "vue à facettes" du projet.
Boule Vue à facettes
C'est le point de difficulté majeur. Déterminer qui intervient dans un projet et quand. Il faut rester évolutif (voire configurable) sur ce plan. Pour l'instant, voici les "rôles" identifiés :
-
Le "rapporteur" (comm', commerciaux) (ou carrément : le client final lui-même)
- en lien avec le client final
- intéressé par le fonctionnel uniquement et très grossièrement (les détails ne techniques ne l'intéressent pas, et même certains détails fonctionnels)
- en entrée : c'est l'entrée. demande des fonctionnalités, rapporte des bugs
- attentes : le produit fini, rien d'autre
-
la MOA ou, plus génériquement : L'équipe de spécification. Qui se charge de spécifier les nouvelles fonctionnalités ou les évolutions de l'existant. (cf. les ZEP ici, c'est exactement l'idée). + ergonomes + designers
- spécifie
- en sortie : cahier des charges, cahier de "recettes"
- (uniquement) intéressée par l'aspect fonctionnel
-
L'équipe R&D, équipe de développement + infra (équipe d'administration système&réseaux)
- en entrée : spécifications et cahier des charges
- recherche des solutions
- réalise
- en sortie : prototype, PoC, produit recettable
- intéressée par le fonctionnel pour l'implémenter, discussions techniques
-
L'équipe de QA
- en entrée : un produit recettable
- en entrée : une "grille de QA" adapté aux attentes (à granularité fine : on peut tester un bugFix, une nouvelle fonctionnalité, ou une release de façon globale avant qu'elle ne soit poussée en production).
- en sortie : un rapport de tests, Go/NoGo, Ship/NoShip et des notes de QA
Voilà pour les acteurs & rôles définis aujourd'hui. En l'état c'est jouable et ça me semble s'adapter à peu près (même si ce n'est évidemment pas la panacée) à ce qu'on peut trouver.
Vous noterez que bien qu'on ait défini des rôles, on voit déjà un workflow se dessiner.
Le modèle
Workflow
Dans l'exemple précédent, le workflow suivant se dégage :
Demande -> Spec' -> Réalisation -> QA -> Release -> Notification au demandeur
Workflow qui peut bien évidemment boucler à chaque étape.
"Par défaut" pour l'organisation qui j'ai définie plus haut (qui me semble convenir à une PME, un projet perso, une organisation comme ZdS), chaque "Feature" (ou "Issue") suivrait ledit workflow. A moins qu'on en définisse un spécifique à la feature en question. (sauter l'étape spec' si on parle d'un bugfix par ex.).
Milestones
A peu près tout le monde sait ce que sait, je ne m'étends pas là-dessus. Il est nécessaire qu'elles soient au centre du projet. dueDate optionnelle pour plus de flexibilité, l'objectif étant de les voir, de voir pourquoi elles sont bloquées, et pourquoi une milestone a avancé beaucoup plus vite qu'une autre…
Bref, objectifs : pour filtrer, pour agréger, pour avoir les bons reports (e.g. on fait des tests de non-regression sur une milestone en entier)
Issue
Terme générique (et mauvais, et à changer) pour désigner :
-
une correction de bug
-
une évolution de l'existant (enhancement proposal)
-
une nouvelle fonctionnalité
C'est l'élément central de Projuice. (au même titre que github par exemple).
Une issue est donc consultable par tous les acteurs, la vue est adaptée au rôle occupé.
Une issue possède un workflow, dans ce workflow on retrouve différentes tâches. Soit automatiques (QA, …) soit ajoutées manuellement (penser à modifier le fichier machin, il manque une icône bidule à designer, …). Chaque tâche est assignée.
Certaines tâches peuvent être effectuées en parallèle. Je ne rentre pas trop dans le détail (on va pas aller jusqu'à Gantt, Pertt ou autres représentation, l'objectif est KISS, même si ça se complique un peu).
Une issue peut être liée à une milestone.
Meetings
Dans toute structure, il existe des réunions.
Parfois elles se font sur le pouce, sans ordre du jour très bien établi, parfois comme dans le cas des ZestMeetings elles sont très cadrées.
Pourtant, il est souvent pénible de :
-
préparer l'ordre du jour (en allant pêcher les liens utiles à propos des sujets discutés) et norifier les participants (potentiels)
-
rédiger un compte-rendu et notifier les absents qui pourtant seraient intéressés par le contenu discuté.
L'idée ici est de référencer des issues depuis les meetings et vice-versa (les développeurs auront vu un ManyToMany
là-dedans). Afin de :
-
préparer très simplement l'ordre du jour : lorsque je prépare (crée) un meeting j'ai la liste des issues et je pioche dedans
-
inviter des participants automatiquement et les notifier (ceux qui travaillent sur les issues en question) + d'autres si besoin
-
rattacher automatiquement le compte-rendu au contenu discuté (depuis l'issue je sais qu'elle a été discutée dans le meeting X et je peux lire le compte-rendu) : l'information est pérennisée et accessible depuis plusieurs points d'entrée
Labels
Au même titre que ceux de github, ils sont là pour améliorer la recherche, ou pour repérer visuellement des issues ou des tâches.
Je passe rapidement : ce sont des tags, basiques, on peut rechercher / filtrer, y'a des couleurs, comme dans github. Pas la peine de s'étendre là-dessus.
NB : WIP mais si vous avez des remarques sur ce que vous attendriez d'un tel outil je prends tout (au risque de me noyer mais je le prends).
NB² : si vous êtes intéressés par l'aspect technique, je peux détailler certains choix dans le message suivant.
-
Pourquoi ne pas faire un plugin sur un issue-tracker existant ? (JIRA ? Github ?) Et bien c'est ce que j'ai cherché à faire dans un premier temps. Malheureusement, ce qui s'en dégage c'est qu'il faut revoir tout le modèle pour l'adapter à plusieurs entités (cf. plus bas). Ça devient mission impossible… ↩