- Préparation automatique
- L'agilité dans GitHub
- Pipelines
- Labels
- Bien remplir une issue
- Un bon backlog
- Alors, Issue ou Epic ?
- Templates Issues / PR
Script PHP : prepare_repo
Pour créer :
- Labels
- Templates Issues / PR
- Issues de base pour un site vitrine
Fichier de formatage du code PHP : ETD Solutions.xml
En Scrum, les sprints sont des durées fixes de temps dans lesquelles une part du travail préalablement acceptée a été terminée et prête à être livrée.
Les User Stories sont les descriptions (de haut-niveau) des fonctionnalités qui permettent de les définir d'un point de vue Client.
Les sous-tâches sont représentées dans l'issue sous forme de listes à puce avec une case à cocher pour déterminer leur validation.
Intégré avec ZenHub ⇒ https://www.zenhub.com
Les issues y sont rangées verticalement par importance.
Ici, les issues doivent être estimées, inclure du détail et avoir un Milestone.
| Nom | Description |
|---|---|
| New Issues | Toutes les nouvelles issues créées arrivent ici. On doit les envoyer dans un autre pipeline dès que possible. |
| Icebox | Les issues que l'on se garde pour plus tard : des idées, des choses que l'on ne fera pas tout de suite, ... |
| Backlog | On ne travaille pas sur ces issues pour l'instant, mais on agit quand même sur elles. Si elles n'ont pas de milestone elles font parties du Product Backlog sinon du Sprint Backlog. |
| To Do | Alimenté par les issues bien définies. Ce pipeline est le focus courant de l'équipe. Ces issues iront dans le pipeline In Progress, on les classe par priorité et on assigne les "garants" de la bonne réalisation. |
| In Progress | Ce pipeline répond à la question : "Sur quoi sommes-nous en train de travailler ?". Idéalement, chaque membre de l'équipe doit travailler sur une seule chose en même temps. |
| Done | Les issues sont prêtes pour être mise en production ou staging. |
| Closed | Ce sont les issues terminées. |
| Thème | Labels | Description |
|---|---|---|
| Plateforme | Si le repo couvre plusieurs parties, on affiche où les issues "vivent" (ex: framework etd, app) | |
| Problèmes | Issues qui font que le produit est dégradé. Haute priorité, d'autant plus si c'est présent en production. | |
| Ennuyeux | Remplir un site, réorganiser la structure des dossiers et autre tâche nécessaire (mais moins impactante). | |
| Expérience | Affecte la compréhension de l'utilisateur ou l'utilisation générale de l'appli. Cela peut être à la fois des changements ou des bugs UX. | |
| Environnement | Environnement serveur. Avec une bonne assurance qualité (QA), on identifira les bugs pendant les déploiement en tests et en staging. | |
| Feedback | A besoin de plus de discussion pour comprendre les étapes d'action. La plupart des nouveautés démarre ici. | |
| Améliorations | Itérations sur des fonctionnalités ou infrastructure déjà existantes. Généralement ce la améliore la rapidité ou la qualité des résultats. Par ex: ajouter un champ "Propriétaire" dans un model "Calendrier" existant. | |
| Ajouts | Nouvelles fonctionnalités. Nouvelles pages, workflows, ... | |
| En attente | Travail en cours, mais a besoin de quelques éléments avant. Une fonctionnalité qui a besoin d'une mise à jour d'une dépendency ou un bug qui nécessite plus de données. | |
| Inactive | Pas d'action requise ou possible. L'issue est soit corrigée, mieux définies dans une autre issue ou seulement en dehors du scope du projet. | |
| Quick Fixes! | Les issues qui peuvent être traitées rapidement ! |
On démarre toujours de la même façon. Les User Stories répondent aux questions qui, quoi et pourquoi ? d'une fonctionnalité.
En tant que <rôle>, je veux <tâche> afin de <objectif>.
Exemple : En tant que <Client Enregistré>, je veux <passer une commande en un seul clic> afin de <gagner du temps>.
Le but est de bien définir l'issue : on idenifie l'audience, l'action et les bénéfices (ou objectifs) le plus simplement possible.
On doit se demander si :
- c'est quelque chose de valeur pour le Client ;
- on a bien évité le jargon... Le client doit pouvoir comprendre ;
- elle est indépendante des autres issues si possible ;
- elle est négociable : plusieurs voies possibles pour atteindre l'objectif ;
- elle est petite et peut être facilement estimée en terme de temps et ressources requises ;
- elle est mesurable, on peut tester le résultat.
On a un template pré-défini : Templates Issues / PR
Plus l'issue est haut dans le backlog, plus elle doit être détaillée !
Le backlog est plus qu'une TO-DO list. On planifie avec ! Les issues en haute doivent être estimées correctement : en temps, en complexité, ...
Dans un backlog, le temps, le budget et la qualité sont toutes des variables fixes ! Le cadre, non.
C'est à dire que des issues seront "gelées" dans licebox, fermées, ajoutées ou modifiées dès qu'on en saura plus.
Les issues doivent être rangées verticalement en fonction de leur valeur business (valeur pour le client).
On doit considérer le temps et la complexité.
Les issues qui doivent être terminées dans un temps le plus court possible. Si elle prend des semaines ou des mois à faire, c'est sûrement une Epic. Dans le même esprit, si une issue devient trop complexe – s'il y a plusieurs tâches nécessaires pour la terminer – c'est mieux de la mettre en Epic.
## User Story
En tant que *rôle*, je veux *tâche* afin de *objectif*.
## Critères d'acceptation
- [ ]
- [ ]
## Définition de "Done"