https://github.com/etd-framework/cheatsheet
Cheatsheet pour les bonnes pratiques Scrum, GitHub, Zenhub, ...
https://github.com/etd-framework/cheatsheet
Last synced: 4 months ago
JSON representation
Cheatsheet pour les bonnes pratiques Scrum, GitHub, Zenhub, ...
- Host: GitHub
- URL: https://github.com/etd-framework/cheatsheet
- Owner: etd-framework
- Created: 2016-12-08T13:26:21.000Z (over 9 years ago)
- Default Branch: master
- Last Pushed: 2017-05-18T08:46:27.000Z (about 9 years ago)
- Last Synced: 2025-01-14T05:43:20.058Z (over 1 year ago)
- Size: 22.5 KB
- Stars: 1
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Cheatsheet pour les bonnes pratiques chez ETD !
* [Préparation automatique](#préparation-automatique)
* [L'agilité dans GitHub](#lagilité-dans-github)
* [Pipelines](#pipelines)
* [Labels](#labels)
* [Bien remplir une issue](#bien-remplir-une-issue)
* [Un bon backlog](#un-bon-backlog)
* [Alors, Issue ou Epic ?](#alors-issue-ou-epic-)
* [Templates Issues / PR](#templates-issues--pr)
## Préparation automatique
Script PHP : [prepare_repo](https://github.etd-solutions.com/prepare_repo.php)
Pour créer :
- Labels
- Templates Issues / PR
- Issues de base pour un site vitrine
## Standards de code dans PHPStorm
Fichier de formatage du code PHP : [ETD Solutions.xml](https://www.dropbox.com/s/d8d6uqwdlg2v2sc/ETD%20Solutions.xml?dl=1)
## L'agilité dans GitHub
### Sprint ➙ Milestone (jalon)
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.
### User stories ➙ Issues
Les User Stories sont les descriptions (de haut-niveau) des fonctionnalités qui permettent de les définir d'un point de vue Client.
### Sub-tasks ➙ Markdown checklists
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.
### Epics ➙ Epics
Intégré avec ZenHub ⇒ https://www.zenhub.com
### Product backlog ➙ Issues ouvertes sans Milestone
Les issues y sont rangées verticalement par importance.
### Sprint backlog ➙ Issues avec un Milestone
Ici, les issues doivent être estimées, inclure du détail et avoir un Milestone.
## Pipelines
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.
## Labels
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 !
## Bien remplir une issue
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 \, je veux \ afin de \**.
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](#templates-issues--pr)
## Un bon backlog
### DEEP !
#### Detailed appropriately (détaillée correctement)
Plus l'issue est haut dans le backlog, plus elle doit être détaillée !
#### Estimated (estimé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é, ...
#### Emergent (plein d'avenir)
**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 l`icebox`, fermées, ajoutées ou modifiées dès qu'on en saura plus.
#### Prioritized (prioritisé)
Les issues doivent être rangées verticalement en fonction de leur valeur business (valeur pour le client).
## Alors, Issue ou Epic ?
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.**
## Templates Issues / PR
```md
## User Story
En tant que *rôle*, je veux *tâche* afin de *objectif*.
## Critères d'acceptation
- [ ]
- [ ]
## Définition de "Done"
```