Il y a quelque temps, j'ai été confronté au choix d'un outil de gestion de petits projets utilisant la méthodologie SCRUM. J'avais beaucoup d'expérience dans l'utilisation de divers outils dont Jira, Asana, Trello, etc., mais aucun d'entre eux ne convenait parfaitement à mon projet: certains étaient trop monstrueux et certains manquaient de fonctionnalités importantes pour moi. En conséquence, j'ai dû inventer l'outil moi-même, basé sur Google Sheets.
Les exigences que j'ai imposées à l'instrument étaient les suivantes:
- Faible consommation de temps: la saisie d'une nouvelle tâche, la priorisation d'un backlog ou la modification de l'état d'une tâche devrait prendre un minimum de temps.
- Seuil d'entrée bas pour tous les participants au processus.
- Visibilité et minimalisme: je voulais voir le backlog, les tâches de sprint et la progression actuelle sur un seul écran. Et sans rien voir de superflu.
- Construisez un graphique de burndown, par ailleurs, par heures (travail restant), et non par tâches fermées.
- Possibilité de contrôle clair et pratique: si toutes les heures sont apposées, si tous les statuts sont mis à jour.
Une partie des exigences était dictée par le fait que dans ce projet, je combinais deux rôles: chef de produit et chef de projet, donc je voulais que le temps consacré à la gestion de l'équipe soit minimal afin qu'il y ait du temps pour la gestion des produits.
En conséquence, il a été possible de créer un outil vraiment pratique et satisfaisant à mes exigences qui a résisté à l'épreuve du temps, a subi plusieurs modifications et est maintenant prêt à en informer le public. Je pense que quelqu'un pourrait bien le trouver utile.
Vue générale
La vue générale de l'outil est présentée dans la capture d'écran:
Les chiffres indiquent les principaux domaines suivants:
- Carnet de produit
- Carnet de sprint
- Heures restantes pour les tâches
- Graphique Burndown
Comme mentionné ci-dessus, l'une des exigences de l'outil était le minimalisme, cependant, le modèle a été conçu de sorte qu'il était possible d'ajouter des colonnes supplémentaires (par exemple, une colonne avec un lien vers un document décrivant une user story) et rien ne se briserait.
Comment l'utiliser
Les étapes de base de l'utilisation de l'outil sont décrites ci-dessous, toutes les captures d'écran sont cliquables.
Le début du projet. Remplir l'arriéré
Nous ouvrons un modèle vierge vierge et commençons à le remplir de tâches et de pages utilisateur. En conséquence, la feuille prendra approximativement la forme suivante:
La hiérarchisation du backlog se fait en organisant les tâches plus haut ou plus bas dans la liste. Et ici, un point important doit être noté: Google Sheets, contrairement à MS Excel, prend en charge le glisser-déposer des lignes de tableau avec un glisser-déposer régulier: il suffit de saisir le numéro de ligne avec la souris et de le déplacer si nécessaire. Cependant, il n'écrase pas les autres lignes, mais se situe entre elles. Sans cette fonctionnalité, rien ne serait arrivé.
Planification
Avant de planifier, définissez les paramètres de sprint: indiquez le nombre de jours (champ jours de sprint), et indiquez également les jours ouvrables du sprint dans l'en-tête du tableau. Au départ, il y avait une idée pour que les dates soient estampillées automatiquement, mais à la fin, je suis arrivé à la conclusion qu'il était plus facile de le remplir manuellement et de ne pas se soucier du traitement des jours fériés, des événements d'entreprise, etc.
Lors de la planification, nous évaluons et décomposons les tâches, les affectons aux interprètes et les faisons glisser vers le backlog de sprint, où nous contrôlons le chargement de chaque interprète.
Ici, il est nécessaire de faire quelques explications:
- La décomposition des tâches s'effectue par une convention de dénomination, lorsque la tâche et la sous-tâche sont séparées par deux points: " Tâche : sous - tâche ".
Une variante du modèle a été implémentée, où une colonne spéciale a été sélectionnée pour la hiérarchie, où l'on pouvait sélectionner la tâche racine dans la liste déroulante (formée automatiquement à partir du backlog), mais la pratique a montré qu'une telle complication n'est pas nécessaire.
- Bien sûr, pour contrôler le chargement des artistes, on pouvait faire un beau planning séparé, mais je ne voulais pas encombrer l'interface avec un planning qui n'est nécessaire qu'une seule fois par sprint. Par conséquent, j'ai choisi l'option indiquée dans la capture d'écran - elle s'est avérée assez pratique. S'il y a beaucoup de tâches et de développeurs, ils peuvent être sélectionnés à l'aide du filtre afin qu'il soit plus pratique de sélectionner avec la souris.
Performances de sprint et rapports quotidiens
À la fin de la journée de travail, chaque développeur inscrit le nombre d'heures restantes pour chacune de ses tâches. Une fois la tâche terminée, définissez-la sur zéro. Sur la base de ces données, un graphique de burndown est construit. À mon avis, il s'agit du type de rapport optimal: il ne nécessite pas beaucoup de temps et vous permet d'évaluer de manière beaucoup plus précise la progression des performances de sprint par rapport au moment où le burndown est construit sur des tâches fermées.
Je voudrais également attirer l'attention sur la commodité de contrôler la pertinence des données: un seul coup d'œil suffit pour comprendre pour quelles tâches les développeurs ont réglé l'horloge et pour lesquelles ils ont oublié.
Planifier un nouveau sprint
Lorsque le sprint est terminé, nous commençons à planifier un nouveau sprint. Pour ce faire:
- Créez une copie de la feuille avec le sprint qui vient de se terminer
- Supprimez-y toutes les tâches terminées.
- Pour les tâches inachevées, nous transférons le nombre d'heures restantes du dernier jour du sprint au jour de la colonne 0.
Ensuite, nous répétons toutes les actions décrites dans la section "Planification".
L'approche avec la copie des feuilles vous permet de minimiser le travail manuel et de conserver l'historique de tous les sprints précédents: il est parfois utile de voir ce qui s'est passé quelques sprints pour nous.
À propos des tests
Mais qu'en est-il des tests? - demandez-vous. Les tests ont été organisés comme suit: nous avons simplement créé une autre feuille blanche où tous les bogues trouvés ont été saisis. Et puis nous les avons soit corrigés dans le sprint actuel, soit entrés dans le backlog du projet et planifié leur mise en œuvre avec les tâches habituelles dans les sprints suivants.
Au lieu d'une conclusion
Vous pouvez télécharger le modèle ici . Il est complètement prêt à l'emploi: il suffit d'enregistrer une copie et de commencer à l'utiliser.
Juste au cas où: bien sûr, je n'invite pas tout le monde à quitter et à passer à la gestion de projet à l'aide de Google Sheets. Cependant, la vie est une chose diverse, et il est fort possible que quelqu'un rencontre un projet pour lequel cet outil sera le meilleur choix.