# Le Guide Agile par Wishtack
Après 5 ans de développement d'applications, d'animation de formations et d'accompagnement d'entreprises dans leurs développements, nous avons décidé de produire cet ouvrage gratuit afin de partager notre expérience.
## Nos objectifs
* Produire **rapidement** des applications **performantes**, **robustes** et **maintenables**.
* Privilégier le **pragmatisme** et mettre l'accent sur les **bonnes pratiques**.
* Partager le fruit de nos heures de **veille**, de **recherche** et de nos **retours d'expérience**.
* Produire un **guide** **gratuit**, **à jour** et **communautaire.**
* N'hésitez donc pas à nous envoyer vos Pull Requests sur :
## Copyright
Ce livre est l'oeuvre et la propriété de la société Wishtack.
Il ne peut être utilisé partiellement ou intégralement comme support de prestations rémunérées sauf par les employés de la société Wishtack.
En cas de doute, merci de contacter l'équipe Wishtack :
# Sans Agilité
## "Cycle" en Racine Carrée ou la Caricature à Éviter
### Le client exprime son besoin
avec une phrase...
> Je veux une application mobile pour un réseau social avec du rouge en couleur dominante.\
> Rendez-vous dans 6 mois.
... ou pire encore, avec un cahier des charges.
### 3 mois plus tard...
* Retards.
* Client déçu par la version beta.
* Trop tard pour tout remettre en question.
* Tensions avec le client et au sein de l'équipe.
* Le "lead developer" quitte l'entreprise.
* 3 nouveaux développeurs rejoignent l'équipe en renfort.
* Le renfort ralentit encore plus l'équipe.
## Coût du changement
Avec le cycle en V, le coût du changement augmente au fil du temps à travers le Software Development Life Cycle.
Il est donc plus difficile et plus cher de remédier à une erreur de conception à la livraison qu'au début des développements.
De même, sans méthode de développement, plus le développement avance, plus le code devient complexe et plus le changement est coûteux.
## Conséquences
### Conséquences Générales
* **🐢 *****Time to Market***** trop long**.
* **⌛️ Les délais ne sont pas respectés** et le retard est découvert tardivement car la vélocité de l'équipe est rarement mesurée.
* 😖 **Inadéquation** par rapport au besoin.
* 🐞 **Problèmes de qualité**.
### Conséquences Intermédiaires
* **🙈 Manque de visibilité** sur l'avancement.
* **🏓 Pas de feedback** des clients et utilisateurs.
* 😰 Décisions maladroites dans la panique et augmentation exponentielle du stress à l'approche des deadlines.
### Conséquences Intermédiaires Techniques
* 🙀 Peur du changement.
* 🤕 Développement empirique.
* 🤯 Complexité artificielle *(i.e. : développement inutile ou inutilisable)*.
* 👩🚒 L'équipe est débordée par la correction de bugs.
* La correction d'un bug en provoque un autre.
* 🚇 Effet tunnel: Plusieurs fonctionnalités en cours de développement mais aucune de finalisée.
* 👹 *Integration Hell*.
### Causes
* ⚽️Absence de [Collective Ownership](/extreme-programming/pratiques-de-l-extreme-programming#collective-ownership).
* **🗜**Absence d'[intégration continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/integration-continue).
* 📦Absence de [livraison continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/livraison-continue).
* 🎯Manque de propagation et de compréhension de la vision.
* 📝Manque de conventions et pratiques de développement.
* 📈**HiPPO** *(Highest Paid Person’s Opinion)*, **Ego-Driven** Decision et **Tradition-Driven** Decision au lieu de Data-Driven Decision.
## Le paradoxe des spécifications
L'objectif principal de la rédaction de spécifications est de réduire les risques.
Paradoxalement, dans la plupart des cas, cela finit par **augmenter le risque et le coût au lieu de les réduire**.
### Inconvénients de la rédaction de spécifications
* **⌛️ Perte de temps** avant l'implémentation de la première fonctionnalité.
* **🥊 Incompréhensions** et conflit à la livraison / validation.
* **🤷♂️ Déresponsabilisation** de l'équipe de développement car de nombreux choix sont figés par les spécifications.
* 💰 Le **rapport valeur vs. coût** de chaque fonctionnalité est rarement *(ou difficilement)* pris en compte.
* **📜 Péremption des spécifications** : Les besoins et contraintes ne sont probablement plus les mêmes entre le moment de la rédaction des spécifications et lors du développement de l'application.
* 🥇 Problèmes de priorisation.
* **🤯 *****Over-thinking***** et *****Analysis Paralysis***.
###
# Bottom-up vs Top-down
### Bottom-up
La tradition académique veut que l'on conçoive et que l'on développe les applications de bas en haut.
1. On développe une couche générique.
2. On essaie de répondre à tous les besoins que l'on peut imaginer et qui finissent souvent par être surréalistes.
3. On perd donc beaucoup de temps pour du développement superflu.
4. On se retrouve avec une interface inutilisable.
```python
SocialNetworkMessage(
recipient_group_list=[
RecipientGroup(
can_edit=False,
can_reply=False,
is_anonymous=False,
private=True,
recipient_list=[user1, user2]
),
RecipientGroup(
can_edit=True,
can_reply=True,
is_anonymous=True,
private=False,
recipient_list=[user3, user4]
)
],
is_embeddable=False,
message_expiration=datetime(2025, 10, 1),
show_thumbnail=True,
...
)
```
... ou sans named parameters
```python
SocialNetworkMessage(
[
RecipientGroup(
False,
False,
False,
True,
[user1, user2]
),
RecipientGroup(
True,
True,
True,
False,
[user3, user4]
)
],
False,
datetime(2025, 10, 1),
True,
...
)
```
{% hint style="danger" %}
Attention à l'"Over-Thinking"
{% endhint %}
### Top-down
Dans le bâtiment, il n'est pas évident de construire des escaliers de haut en bas mais dans l'univers virtuel du développement, on peut.
Peu importe le point de départ de l'escalier, ce qui compte est que celui-ci arrive au 1er étage. Dans ce cas, il est préférable de commencer par le point d'arrivée c'est à dire l'étage; ainsi nous sommes sûrs que l'escalier arrivera bien au bon niveau et non quelques centimètres plus bas ou plus haut car nous avons oublié de prendre en compte l'épaisseur du carrelage.
L'approche **top-down** permet de garantir que le développement répond au besoin et uniquement au besoin, évitant ainsi le développement superflu.
# Exemple de Régression Naturelle
## La régression naturelle et l'approche Code & Fix
{% tabs %}
{% tab title="Day 1" %}
```python
class User:
def message_list():
return DataSource().message_list(user_id=self.id)
```
{% endtab %}
{% tab title="Day 2" %}
```python
class User:
def message_list():
if os.environ.ENV == "stage":
data_source = DataSource(host="10.45.23.10")
else:
data_source = DataSource()
return data_source.message_list(user_id=self.id)
```
{% endtab %}
{% tab title="Day 3" %}
```python
class User:
def message_list():
if os.environ.ENV in ["stage", "STAYGE"]:
data_source = DataSource(host="10.45.23.10")
else if int(os.environ.HOST_NAME[-1]) % 2:
data_source = DataSource(host="10.33.35.15")
else:
data_source = DataSource()
return data_source.message_list(user_id=self.id)
```
{% endtab %}
{% tab title="Day 4" %}
```python
class User:
def message_list():
if os.environ.ENV in ["stage", "STAYGE"]:
data_source = DataSource(host="10.45.23.10")
else if os.environ.HOST_NAME[-1] % 2:
data_source = DataSource(host="10.33.35.15")
else:
data_source = DataSource()
if self.id.startswith("xft"):
if self.country == "FR":
if self.partner_id.startswith("RT")
self.xrb = 43
else:
self.xbe = 56
return data_source.message_list(user_id=self.id, xrb=self.xrb, xbe=self.xbe)
```
{% endtab %}
{% endtabs %}
# Agile Manifesto
En 2001, 17 développeurs au centre du mouvement agile se réunissent pour échanger librement autour des différentes méthodes agiles.
Cette rencontre s'achève avec la publication du manifeste agile.
> Manifesto for Agile Software Development
>
> We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
>
> **Individuals and interactions** over processes and tools\
> **Working software** over comprehensive documentation\
> **Customer collaboration** over contract negotiation\
> **Responding to change** over following a plan
>
> That is, while there is value in the items on the right, we value the items on the left more.
## Les 12 principes de l'Agile Manifesto
> *We follow these principles:*
>
> 1\. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
>
> 2\. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
>
> 3\. Deliver working software frequently, from a couple of weeks to a couple of months, with a \
> preference to the shorter timescale.
>
> 4\. Business people and developers must work together daily throughout the project.
>
> 5\. Build projects around motivated individuals. \
> Give them the environment and support they need, and trust them to get the job done.
>
> 6\. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
>
> 7\. Working software is the primary measure of progress.
>
> 8\. Agile processes promote sustainable development. \
> The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
>
> 9\. Continuous attention to technical excellence and good design enhances agility.
>
> 10\. Simplicity--the art of maximizing the amount of work not done--is essential.
>
> 11\. The best architectures, requirements, and designs emerge from self-organizing teams.
>
> 12\. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
# Scrum
Né dans les années 90, le Scrum est une stratégie de développement de produits qui se base sur une **approche itérative** au lieu d'une approche séquentielle et pyramidale "classique".
> Scrum: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
# Théorie et Piliers du Scrum
Comme la plupart des méthodes qui se veulent agiles, Scrum **adopte une approche empirique**.
Plutôt que des calculs savants *(ou plus généralement pifométriques)*, une approche empirique permet de **prendre des décisions** et définir les **objectifs** et **Deadlines** **en fonction du passé de l'équipe**.
Cette méthode empirique fonctionne en combinaison avec une approche itérative et incrémentale.
En livrant une nouvelle version du produit à **chaque itération** et en **améliorant continuellement** l'organisation de l'équipe, la **prédictibilité est optimisée** et le **risque contrôlé**.
{% hint style="success" %}
Plus les itérations sont courtes, plus les estimations seront fiables et les décisions précises.
{% endhint %}
## Les piliers du Scrum
Scrum se base sur les trois piliers suivants :
### Transparence
Tous les éléments significatifs du process doivent être visible et compréhensibles par tous les responsables *(c'est à dire du client au développeur)*.
Exemples :
* Les User Stories doivent être explicites pour tous.
* La notion de definition of "Done" doit être partagée avec tous.
* La progression est accessible à tous.
### Inspection
L'organisation de l'équipe, le produit, les Backlogs et les différentes métriques doivent être diagnostiqués afin d'améliorer continuellement les process. Cf. [Indicateurs](/indicateurs).
Toute la Scrum Team contribue à l'inspection et peut signaler des axes d'amélioration lors des différents événements Scrum : Sprint Planning, Daily Scrum, Sprint Review et particulièrement le Sprint Retrospective.
### Adaptation
Les axes d'amélioration remontés par l'inspection doivent aboutir le plus rapidement possible à des adaptations de l'organisation et du process.
# Valeurs du Scrum
### Engagement
*(ou garantie de moyens)*
Tout le monde doit s'engager et faire de son mieux pour accomplir les objectifs de la Scrum Team.
### Courage
Les membres de la Scrum Team doivent avoir le courage d'affronter la réalité et faire le nécessaire pour éviter les problèmes ou y remédier.
### Focus
Tout le monde doit se focaliser sur le Sprint Goal et les objectifs de la Scrum Team en général.
{% hint style="success" %}
Un Sprint Goal convergeant favorise naturellement la communication dans l'équipe et le [**Collective Ownership**](/extreme-programming/pratiques-de-l-extreme-programming#collective-ownership).
{% endhint %}
### Openness
Les membres de la Scrum Team et les responsables doivent rester ouverts au changement et aux nouveaux challenges.
### Respect
Les membres de la Scrum Team doivent se respecter mutuellement en tant qu'individus **compétents**, **différents** et **indépendants**.
# Scrum Team
La Scrum Team est composée des rôles suivants :
## Development Team
**Qualités attendues :** autonome et communicante.
Elle est responsable de livrer des PSIs *(Product Shippable Increment)*.
C'est une équipe **autonome** et **autogérée** composée généralement de 3 à 9 personnes *(développeurs / experts UX / graphic designer / expert sécurité etc...)*.
Elle doit être protégée au maximum de toutes distractions externes *(réunions superflues / interactions excessives avec le client ou d'autres équipes / téléphone / messagerie interne)*.
## Product Owner
**Qualités attendues :** vision et disponibilité.
Il est le représentant du "client".
Il décrit et priorise les fonctionnalités à implémenter.
Il est responsable de garantir que l'équipe de développement produit bien de la valeur business.
Il n'intervient pas sur les décisions techniques.
## Scrum Master
**Qualités attendues :** capacité d'écoute et de pédagogie.
Il facilite les interactions entre le Product Owner et les développeurs.
Il débarrasse la Development Team de tous les obstacles qui peuvent l'empêcher d'atteindre ses objectifs.
Il permet à la Development Team de rester concentrée, motivée et créative.
Il conseille le Product Owner pour améliorer l'efficacité de la Development Team.
**Il ne gère pas la Development Team mais la "coach"** pour livrer des fonctionnalités de qualité.
Il promeut l'autogestion au sein de la Development Team.
Il aide le client à mieux comprendre les principes Scrum.
{% hint style="danger" %}
Les rôles "**Product Owner**" et "**Scrum Master**" **ne sont pas cumulables**.
{% endhint %}
# Artefacts
Scrum définit trois artefacts : [Product Backlog](/scrum/artefacts/product-backlog), [Sprint Backlog](/scrum/artefacts/sprint-backlog) et [Increment](/scrum/artefacts/increment).
Les artifacts forment une représentation transparente *(accessible à tous)* et à jour des objectifs et de la progression de l'équipe.
# Product Backlog
Le Product Backlog est **la liste des besoins d'un produit** : les PBIs (Product Backlog Items). Fonctionnalités, bugs, besoins non-fonctionnels, etc...
**Le Product Owner priorise les items** en fonction de la valeur business, du risque, des dépendances et la date de disponibilité souhaitée.\
*Exemple : A valeurs business égales, il priorisera les items les plus "faciles" à implémenter.*
Les items sont généralement exprimés sous forme de User Story mais ce n'est pas une obligation. L'essentiel est que chaque item utilise un vocabulaire commun à tous les intervenants *(client / product owner / développeurs)* et que la plupart des items restent focalisés sur la valeur business du produit.
# Sprint Backlog
Le Sprint Backlog est la liste des Product Backlog Items sélectionnés pour le Sprint en cours.
# Increment
L'Increment est l'ensemble des Product Backlog Items finalisés lors du Sprint en cours.
# User Story
Une User Story est un item qui indique explicitement les informations suivantes :
* **Le rôle** : rôle de l'utilisateur du produit *(Exemple : pour une boutique en ligne : vendeur, acheteur etc...)*. *(A ne pas confondre avec les rôles Scrum : Scrum Master, Product Owner etc...)*,
* **Le but** : objectif de la User Story
* et idéalement l'intérêt business de la "user story".
*Exemple : As a **shop admin**, I want to **customize the "Add to Wishlist" button** in order to **improve the conversion rate**.*
## Personas
Une astuce pour faciliter l'écriture des User Stories et mieux comprendre le besoin consiste à créer des personnages qu'on appelle Personas.
Pour chaque Persona, nous décriront les 3 points suivants :
* Nom et photo,
* Détails,
* Objectifs.
Exemple :
* **Nom** : John
* **Détails** : John est un homme de 35 ans disposant d'une boutique de chaussures en ligne. Il est souvent en déplacement et utilise le navigateur de son téléphone avec une connexion 3G.
* **Objectifs** : Il souhaite faire parler de sa boutique et améliorer ses ventes en utilisant un service de liste de cadeaux.
# Epic
Pour alimenter le Product Backlog de User Stories, **il ne faut pas perdre de temps à détailler toutes les User Stories au départ**.
Les User Stories pouvant nécessiter **plusieurs jours, semaines ou mois** avant d'être finalisées sont appelées Epic.\
Elles seront donc décomposées le plus tard possible en petites User Stories. Cf. Sprint Planning.
Il faut décomposer l'Epic **le plus tard possible pour plusieurs raisons** :
* **Gain de temps** lors du remplissage du Product Backlog.
* Le besoin peut être amené à **disparaitre**.
* La décomposition de l'Epic peut **réutiliser** des fonctionnalités déjà implémentées **ou de nouvelles avancées technologiques**.
# Expression du Besoin
Il est recommandé de suivre les principes **I.N.V.E.S.T.** suivants pour exprimer le besoin :
### *Independant*
Les User Stories doivent être indépendantes les unes des autres.
Les User Stories interdépendantes complexifient la planification, la priorisation et l'estimation.
Cela encourage naturellement le découplage dans l'architecture du produit *(e.g. Microservices)*.
### *Negotiable*
Les détails des User Stories doivent être développés durant le Sprint Planning.
Décrire les détails d'une User Story à l'avance est difficile et peut induire en erreur.
### ***Valuable***
Les User Stories doivent avoir de la valeur pour le client.
### ***Estimable***
Une User Story doit contenir suffisamment d'informations pour pouvoir être estimée, priorisée et planifiée.
### ***Small***
Une User Story doit être granulaire.
### ***Testable***
Une User Story doit être suffisamment explicite pour être testable.
Exemple, la User Story "*L'application doit être facile d'utilisation*" n'est pas testable.
# Definition of Done
La Definition of Done est une Checklist d'éléments à valider pour s'assurer qu'une User Story est vraiment finie.
La Definition of Done est à définir par l'équipe en fonction du type de produit mais elle contient généralement les éléments suivants :
* [ ] Implémentation,
* [ ] Respect du style guide, des conventions de nommage et des bonnes pratiques,
* [ ] Refactoring si nécessaire,
* [ ] Implémentation d'unit-tests,
* [ ] End-to-end tests,
* [ ] La fonctionnalité est livrée,
* [ ] Privacy assessment,
* [ ] Security assessment,
* [ ] Documentation.
{% hint style="danger" %}
Une User Story **ne peut pas être livrée** tant que les règles de la Definition of Done ne sont pas respectées.
{% endhint %}
# Definition of Ready
Au delà du respect des principes [I.N.V.E.S.T.](/scrum/artefacts/expression-du-besoin) pour la définition d'une [User Story](/scrum/artefacts/user-story), avant que celle-ci ne soit estimée et décortiquée lors du [Sprint Planning](/scrum/evenements/sprint-planning) ou [Backlog Refinement](/scrum/evenements/backlog-refinement), **il est préférable de fournir toutes les informations nécessaires** pour améliorer l'efficacité de cet événement, estimer l'effort avec précision et éviter les allers-retours.
La liste de ces informations devant être fournies dans la description d'une [User Story](/scrum/artefacts/user-story) forme le *Definition of Ready.* Le *Definition of Ready* est donc une forme concrète et spécifique des principes [I.N.V.E.S.T.](/scrum/artefacts/expression-du-besoin)
Exemple de *Definition of Ready* :
* [ ] Scénarios.
* [ ] Si fonctionnalité visuelle, sketch ou screenshot d'une application similaire.
* [ ] Si formulaire, l'ordre d'importance des champs d'un formulaire.
* [ ] Si email, template de l'email à envoyer et traductions.
* [ ] Si bug, vidéo du bug, infos système, utilisateur et identifiant erreur.
* [ ] ...
{% hint style="warning" %}
Faites bien attention à ne pas tomber dans la rédaction de lourdes spécifications !
Une [User Story](/scrum/artefacts/user-story) doit rester [*négociable*](/scrum/artefacts/expression-du-besoin#negotiable).
{% endhint %}
# Evénements
# Sprint
Le Software Development Life Cycle est divisé en **plusieurs itérations** **(ou sprints)**.
Le **nombre** de sprints **à venir** est **indéfini**.
On arrête les **sprints** uniquement **quand on abandonne un produit**.
La **durée** d'un sprint **est fixée globalement** à une durée comprise entre 1 et 4 semaines.
La durée est généralement fixée à 2 semaines et **idéalement à 1 semaine**.
{% hint style="danger" %}
La durée ne varie pas d'un sprint à l'autre.
{% endhint %}
{% hint style="info" %}
Dans le cas des équipes travaillant sur plusieurs produits, il est recommandé d'appliquer la même durée.
{% endhint %}
# Sprint Planning
Chaque Sprint démarre avec un Sprint Planning lors duquel l'équipe doit définir :
* **what** : l'objectif du Sprint ou Spring Goal,
* **how** : puis comment atteindre cet objectif.
{% hint style="info" %}
Le Spring Planning **peut être divisé en deux parties** : Sprint Planning 1 et 2.
{% endhint %}
{% hint style="warning" %}
La durée maximum du Sprint Planning est de 2h pour un Sprint d'une semaine.
{% endhint %}
## What : Sprint Planning 1 et définition du Sprint Goal
La Scrum Team se réunit en entier *(Product Owner, Development Team et Scrum Master)* pour définir le Sprint Goal.
1. Le Product Owner **décrit les User Stories** qu'il souhaiterait assigner au Sprint.
2. La Development Team **peut interroger le Product Owner** pour mieux comprendre le besoin.
3. Si une User Story est de taille importante, il s'agit alors d'une Epic et la Scrum Team peut alors décider de la décomposer en User Stories plus fines.
4. La Development Team **évalue** et **sélectionne** **à elle seule** les User Stories qu'elle **pense être capable de finir** d'ici la fin du Sprint.
{% hint style="info" %}
Pour optimiser le Sprint Planning en respectant le Timeboxing, pensez à dérouler ces étapes story par story.\
Ainsi, en cas de "timeout", l'équipe pourra commencer à travailler sur les premières stories.\
Si l'équipe accomplit sa mission avant la fin de l'itération, on pourra alors planifier un [Backlog Refinement](/scrum/evenements/backlog-refinement) pour ajouter de nouvelles stories à l'itération.
{% endhint %}
### Décomposition des Epics
Durant le Sprint Planning, **les Epics seront décomposées** en User Stories plus fines.
## How : Sprint Planning 2
Suite au Sprint Planning 1, la Scrum Team peut libérer le Product Owner.
1. La Development Team **réfléchit et présente la conception / architecture / design de chaque User Story**.\
Cela peut se faire avec toute l'équipe ou par paire afin de paralléliser la réflexion si cela est vraiment nécessaire. Dans ce cas, la paire doit présenter le résultat de sa réflexion au reste de l'équipe.
2. Chaque User Story est ensuite **décomposée en tâches** techniques.
3. Les membres de la Development Team doivent ensuite **se répartir naturellement** ces tâches.
{% hint style="danger" %}
Personne *(ni le Product Owner, ni le Scrum Master, ni le Lead Super Hero Team Scrum Manager)* n'assigne les tâches aux membres de la Development Team.
{% endhint %}
{% hint style="warning" %}
L' effort nécessaire pour chacune des stories peut être estimé en heures mais il est préférable d'utiliser des points.
{% endhint %}
## Estimation de l'Effort
L'**effort** nécessaire pour réaliser chaque User Story est évalué avec un nombre de **points** suivant généralement une suite de Fibonacci *(1, 2, 3, 5, 8 du plus simple au plus complexe)*.\
En pratique, les valeurs 1, 2 et 3 suffisent et encouragent un découpage plus fin.
Cf. [Story Points vs Temps](/scrum/mesures-et-outils/story-points-vs-temps)
### Planning Poker
Pour encourager tous les membres de la Development Team à participer à l'estimation de l'effort associé aux User Stories, l'équipe peut utiliser un jeu de cartes grâce auquel chacun réfléchit à son estimation puis tout le monde dévoile sa carte simultanément.
## Répartition des Tâches
De nombreuses équipes ont le réflexe d'associer chaque tâche à l'expert du sujet.
Bien que cette approche puisse paraître optimale, cela :
* **décourage le partage** de connaissances au sein de l'équipe,
* **encourage le travail individuel** plutôt que l'appropriation du produit par l'équipe,
* **crée une dépendance forte** envers certaines personnes dans l'équipe,
* **n'encourage pas la remise en question** et aboutit souvent à de la **complexité artificielle**.
{% hint style="warning" %}
Le code le moins maintenable est souvent produits par les experts et non les débutants.
{% endhint %}
## Astuces
### Un Sprint Goal convergeant
{% hint style="success" %}
Définissez un Sprint Goal avec **des User Stories fortement liées techniquement et/ou fonctionnellement**.\
Avec des sujets techniques ou fonctionnels liés, proches ou similaires les membres de la Development Team s'intéresseront naturellement aux autres lors du Stand-Up Meeting mais également tout au long du Sprint.
{% endhint %}
# Stand-Up Meeting ou Daily Scrum
Le Stand-Up Meeting *(ou Daily Scrum)* est **un point informel** qui se tient tous les jours debout et à la même heure *(autour d'un café par exemple)*.
En présence du Scrum Master, durant le Stand-Up Meeting chaque membre de l'équipe aborde les points suivants :
1. Ce qu'il a fait depuis le dernier Stand-Up Meeting.
2. Ce qu'il prévoit de faire en attendant le prochain Stand-Up Meeting.
3. **Les difficultés rencontrées**.
{% hint style="warning" %}
La durée maximum du Stand-Up Meeting est de 15 minutes.
{% endhint %}
Les objectifs du Stand-Up Meeting est :
* d'encourager la **communication** dans l'équipe,
* **d'éviter l'isolement** des développeurs et donc les blocages et la complexité artificielle,
* de **déceler rapidement** des difficultés potentielles,
* de détecter **quand un membre de l'équipe à besoin d'aide**,
* de **décider de changer de paires** dans le cas du Pair Programming,
* de **propager la connaissance** dans l'équipe,
* de **réfléchir rapidement et en groupe** à des besoins de conception, d'architecture,
* d'éviter d'avoir à organiser des réunions supplémentaires dans la journée.
{% hint style="danger" %}
**Le Stand-Up Meeting n'est pas un compte-rendu.**
Malheureusement, de nombreux Stand-Up Meetings se déroulent sous forme de compte-rendu au Scrum Master ou Lead Developer ou autre.
Il faut absolument éviter cela et ne pas perdre de vue les objectifs du Stand-Up Meeting décrits ci-dessus.\
Le Stand-Up Meeting doit être un échange de groupe.
{% endhint %}
{% hint style="info" %}
Dans certaines équipes, les Stand-Up Meetings durent rarement plus de 5 minutes car grâce au **Pair Programming**, au **changement régulier des paires**, aux **outils de tracking**, il n'est plus nécessaire de rappeler *(ou à la rigueur cela se fait plus rapidement)* ce qui a été fait et ce qui est à faire car **tout le monde est déjà au courant**.
De même, **tout le monde n'est pas obligé de parler** et à tour de rôle car si le travail a été fait en Pair Programming, cela évite les phrases du type "euh, même chose que Michel".
{% endhint %}
## A éviter
* Evitez de dépasser la durée maximum *(15 minutes)* du Stand-Up Meeting !
* **N'annulez jamais** les Stand-Up Meeting !
* Dans le cas où les Stand-Up Meeting durent longtemps, il faut apprendre à les raccourcir plutôt que d'en organiser un tous les deux ou trois jours.
* Le Stand-Up Meeting à lieu au même endroit et à la même heure **même si seulement deux personnes sont présentes** et que les autres ont simplement du retard.
* **Ne rédigez pas de rapport** de Stand-Up Meeting !
* **Evitez les écrans** *(ordis, smartphones, tablets, projecteurs, etc...)* sauf peut-être un snapshot de l'état actuel de l'[Sprint Backlog](/scrum/artefacts/sprint-backlog).
* **Evitez le chronométrage individuel** !
Le Stand-Up Meeting doit rester informel et si certains sont plus bavards que d'autres, l'équipe peut décider de laisser les bavards parler à la fin tout en les encourageant à respecter le timeboxing.
* **Evitez le** "**totem**" de parole !\
Le token de parole est un objet que l'on passe d'une personne à l'autre pour indiquer qui a la parole.\
Cela permet à tous les membres de parler et d'éviter les interruptions or un bon Stand-Up Meeting est celui où il y a des quelques interruptions car cela signifie que les autres s'intéressent au sujet.\
D'autre part, comme indiqué plus loin, avec un Spring Goal convergeant, tout le monde n'est pas obligé de parler.
# Sprint Review
A la fin de chaque Sprint, la Development Team, le Product Owner et le Scrum Master se réunissent.
Le(s) client(s) et les développeurs d'autres équipes peuvent être invités.
Comme les autres évènements d'un Sprint, **le Sprint Review doit rester informel** *(pas de slides etc...)*.
{% hint style="warning" %}
La durée maximum du Sprint Review est d'1 heure pour une itération d'une semaine.
Cette durée est proportionnelle à celle des itérations.
{% endhint %}
## Objectifs du Sprint Review
* Présentation *(par le Product Owner)* des **User Stories finalisées** et **celles qui ne le sont pas**.
* Présentation *(par la Development Team)* des **difficultés rencontrées** et des solutions adoptées.
* Récolte de "feedback" de tout le monde *(membres de l'équipe, client, autres équipes etc...)*.
* Présentation du Backlog et des dates projetées des releases à venir si nécessaire *(Cf. vélocité)*.
* Reflexion et sélection des objectifs futurs.
* Les User Stories non finalisées ne sont jamais présentées pendant le Sprint Review.
L'une des principales raisons et que certaines personnes extérieures à l'équipe pourraient forcer la livraison ou "vendre" une User Story non finalisée.\
# Sprint Retrospective
Suite au Sprint Review, la Development Team se réunit avec le Scrum Master.
Le Sprint Retrospective est **une réflexion autour du Sprint passé**.
{% hint style="warning" %}
Le Sprint retrospective ne doit pas durer plus de 45 minutes pour des itérations d'une semaine.
Cette durée est proportionnelle à celle des itérations.
{% endhint %}
{% hint style="warning" %}
Le Sprint Retrospective est l'un des évènements les plus importants du Sprint.\
Ne l'ignorez pas !
{% endhint %}
## Objectifs du Sprint Retrospective
* Analyser le déroulement du Sprint passé avec un focus sur :
* les **personnes** *(e.g. : détecter la démotivation et en analyser l'origine)*,
* les **relations** *(e.g. : détecter les conflits, analyser les paires qui fonctionnent le mieux)*,
* les **process** *(e.g. : déceler les faiblesses des process actuels ou ceux qui nuisent à la Developer eXperience)*
* et les **outils** *(e.g. : est-ce que les outils utilisés sont adaptés et est-ce qu'ils sont utilisés convenablement ?).*
* **Analyser les indicateurs**, **identifier** et **ordonner** ce qui s'est bien déroulé et les axes d'amélioration.
* Définir un plan d'amélioration pour **réparer ce qui est cassé** dans le Scrum.
# Backlog Refinement
Le Backlog Refinement *(ou Backlog Grooming)* regroupe toute la Scrum Team *(Development Team, Scrum Master et Product Owner)* afin de donner de la visibilité sur les Sprints à venir et le travail restant.
Sans le Backlog Refinement, la décomposition des Epics se fait en début de Sprint durant le Sprint Planning et la visibilité est donc réduite au Sprint actuel.
## Objectifs du Backlog Refinement
* **Clarifier et décomposer les Epics.**
* **Evaluer ou réévaluer l'effort** nécessaire pour réaliser des User Stories.
* **Retirer** les User Stories superflues.
* **Ajouter** de nouvelles User Stories.
* Le Backlog Refinement peut avoir lieu une à deux fois par semaine *(et non par Sprint)*.
* Si la Development Team finalise toutes les User Stories avant la fin du Sprint, le Backlog Refinement permet d'ajouter de nouvelles User Stories au Sprint Goal du Sprint actuel.
{% hint style="warning" %}
Le Backlog Refinement ne doit pas durer plus d'une heure.
{% endhint %}
{% hint style="danger" %}
Les Epics ne doivent pas être décomposées en fonction du "process" comme dans un cycle en V mais plutôt en fonction de la valeur fonctionnelle.
{% endhint %}
{% hint style="info" %}
Il est souvent inutile d'affiner et décomposer des Epics trop à l'avance *(Cf. Epic)*.
{% endhint %}
# Timeboxing
Comme indiqué précédemment, les évènement et Sprints ont une durée strictement limitée *(timeboxed)*.
Pour les évènements, l'intérêt du Timeboxing est d'**améliorer l'efficacité des échanges** et de ne pas perturber le temps accordé à la réalisation des tâches.
Pour les Sprints, l'intérêt du Timeboxing est de garder une vélocité régulière et de **respecter les Deadlines** quitte à **reporter ou retirer des User Stories**.
# Mesures & Outils
# Story Points vs Temps
## Estimation de l'effort
L' **effort** nécessaire pour réaliser chaque User Story est évalué avec un nombre de **points** suivant généralement une suite de Fibonacci *(1, 2, 3, 5, 8 du plus simple au plus complexe)*.\
En pratique, les valeurs 1, 2 et 3 suffisent et **encouragent un découpage plus fin**.
L'objectif de l'estimation de l'effort est de permettre l'évaluation de l'avancement et la vélocité d'avancement d'un projet.
{% hint style="success" %}
L'effort nécessaire pour réaliser les tâches d'une User Story est parfois estimé en heures mais il est préférable de l'estimer en points.
Encore mieux, il est préférable de ne pas estimer les tâches mais de se contenter d'estimer les User Stories. Cela facile l'estimation et encourage également un découpage plus fin des User Stories.
{% endhint %}
## Story Points vs Temps
**L'heure** étant **une unité absolue,** l'estimation en heures est **souvent erronée** et nécessite une réévaluation régulière des autres User Stories.
En revanche, **le point** étant **une unité relative** à l'effort nécessaire pour réaliser le produit, **les erreurs d'estimations sont plus rares** et n'affectent que la tâche ou User Story en question.
### La métaphore du trajet en voiture
L'évaluation de **la durée d'un trajet en voiture est souvent erronée** à cause des paramètres inconnus et des imprévus : performances du véhicule, problèmes de circulation, pannes, grève SNCF etc...
**La distance du trajet quand à elle est fixe** ; combinée avec la vitesse moyenne du véhicule, elle permet de déduire la durée moyenne du trajet de façon plus précise.
OK, mais **comment évaluer le coût d'un produit et les dates de livraisons** sans jamais compter les heures de travail ? Cf. [Vélocité](/scrum/mesures-et-outils/velocite).
# Valeur, Bugs et Chores
Les User Stories de type Bug ou Chore *(corvée : mise à jour de dépendance, migration de technologie, setup etc...)* **ont une valeur de 0 points** car ils n'ajoutent pas directement de la valeur au produit.
Pour ne pas affecter la vélocité, on attribue également **un effort de 0 points** aux Bugs et Chores.
De cette façon, **si une équipe passe de plus en plus de temps** sur le traitement **des Bugs et Chores**, **sa vélocité baissera** progressivement et cet indicateur pourra **déclencher l'alerte**.
Autrement, l'équipe pourrait garder une vélocité importante sans jamais créer de valeur et en passant 100% de son temps sur du bugfix ou des développements inutiles dans le cadre de Chores.
# Vélocité
## Calcul de la vélocité
L'un des principaux intérêts des méthodes agiles est de pouvoir **évaluer l'avancement de la réalisation** d'un produit **pour mieux prévoir l'avenir**.
La vélocité d'un Sprint se calcule simplement en mesurant **le nombre de Story Points** réalisées lors de ce **Sprint**.
$$
vélocité = \sum(storypoints) / iterationCount
$$
## Workforce
Plus exactement, le calcul de la vélocité prend également en compte la notion de Workforce.
Lors de chaque Sprint, on évalue le Workforce qui est un pourcentage représentant la disponibilité de l'équipe.
$$
vélocité = \sum(iteration.storypoints / iteration.workforce) / iterationCount
$$
## Exemple de calcul de vélocité avec Workforce
Pour une équipe de développement de 5 personnes, si une personne est absente et qu'une autre travaille en parallèle à 50% sur un autre produit alors le Workforce sera de 85%.
A partir du calcul de vélocité et de Workforce des derniers Sprints *(3 ou 4 généralement)*, on prévoit la vélocité des itérations à venir ; ce qui permet de déduire les dates de livraison des User Stories à venir.
Sprint 1 : Workforce = 100%, Story Points = 14.
Sprint 2 : Workforce = 80%, Story Points = 8.
Sprint 3 : Workforce = 100%, Story Points = 12.
La vélocité des Sprints à venir sera estimée à :
$$
( 14 / 100% + 8 / 80% + 12 / 100% ) / 3 = 12
$$
# Scrum Board
Le Scrum Board est un outil visuel permettant de visualiser l'avancement d'un Sprint.
Il doit être mis à jour par l'équipe en temps réel.
Le Scrum Board est intéressant et "ludique" mais il a de nombreuses limitations. Cf. [Outils](/outils).
# Burn Down Chart
Le **Burn Down Chart** indique la **progression de l'effort nécessaire restant** *(en points)* pour accomplir un ensemble de User Stories **à travers le temps**.
Il est possible de produire un Burn Down Chart pour un **Sprint**, une **Release** ou **l'intégralité du produit**.
## Ligne idéale
La ligne tracée entre l'effort nécessaire initial et la date de fin souhaitée *(fin de Sprint ou Deadline)* est la ligne idéale.
Si la ligne de progression de l'effort est en dessous de la ligne idéale alors les délais seront respectés autrement il faut **retirer des User Stories** ou **repousser la Deadline** *(sauf dans le cas d'un Sprint car un Sprint est "timeboxed")*.
## **Ligne de projection**
Le Burn Down Chart peut également présenter une ligne de projection permettant **d'évaluer la date de fin de réalisation** à partir de la vélocité de l'équipe.
# Burn Up Chart
Le Burn Up Chart indique simultanément la progression de l'effort total nécessaire pour accomplir un ensemble de User Stories à travers le temps ainsi que la progression de l'effort effectué.
Le Burn Up Chart a pour avantage de **représenter l'ajout et la suppression de User Stories**.
## Burn Down vs Burn Up
Dans l'exemple ci-dessous, le Burn Up Chart donne l'impression que la progression a stagné puis accéléré alors que des User Stories ont été ajoutées en cours de route puis d'autres ont été retirées à la fin pour respecter les délais.
# Technical Debt
La Technical Debt *(ou dette technique)* est la différence entre ce qui est promis et ce qui a été implémenté *(bugs, implémentations temporaires, User Stories inachevées, ...)* ou autrement dit, les "todos" que l'on laisse traîner.
Il est donc important de mesurer la Technical Debt et de la réduire au maximum.
{% hint style="success" %}
En respectant la Definition of Done, la Technical Debt s'amoindrit.
{% endhint %}
{% hint style="warning" %}
Les **Technical Debts sont prioritaires**, autrement, ils ne feront que croître, l'équipe passera moins de temps sur les nouvelles User Stories et la vélocité diminuera.
{% endhint %}
# Priorisation & Planning
# Le Modèle de Kano
Le modèle de Kano définit cinq catégories pour les attributs d'un produit *(ou service)* :
### **Threshold Attributes *****(Basics)***
Ces attributs représentent les fonctionnalités basiques que **l'utilisateur attend absolument du produit.**
Exemple : un écran couleur.
### **Performance Attributes *****(Satisfiers)***
Les *Performance Attributes* regroupent les fonctionnalités dont on considère que **l'aboutissement est proportionnel à la satisfaction**.
Plus la fonctionnalité est aboutie, plus le client devrait être satisfait **et inversement**.
Exemple : performances de la batterie.
### **Excitement Attributes *****(Delighters)***
Ces fonctionnalités sont **inattendues** par l'utilisateur et **elles ne sont donc pas indispensables**.
En revanche, elles peuvent **facilement améliorer la satisfaction** de l'utilisateur **en le surprenant positivement**.
Exemple : fullscreen, split screen mode, flexible screen, built-in projector, etc...
### Indifferent Attributes
Cette zone regroupe les fonctionnalités dont l'absence ou la présence n'affectent en rien la satisfaction du consommateur.
### Reverse Attributes
Ces fonctionnalités sont un cas extrême où **la présence d'une fonctionnalité peut produit l'effet inverse** sur la satisfaction de l'utilisateur.
Exemple : Touchscreen, Face ID.
## Priorisation
La répartition des fonctionnalités au sein de ces catégories permet de faciliter leur priorisation.
{% hint style="info" %}
Au fil du temps, de l'évolution du produit et du marché, **les Excitement Attributes se transforment progressivement en Threshold Attributes**.
{% endhint %}
{% hint style="warning" %}
La catégorisation des fonctionnalités peut s'avérer très subjective dans certains cas.
Il faut donc bien définir la cible ou créer des produits différents pour les différentes cibles.
{% endhint %}
# La Méthode MoSCoW
La méthode MoSCoW permet de faciliter la priorisation en regroupement simplement les fonctionnalités à planifier en quatre catégories :
**Must Have** : Les fonctionnalités indispensables.
**Should Have** : Les fonctionnalités importantes mais non-essentielles.
**Could Have** : Les fonctionnalités à fournir si possible.
**Won't Have** : Les fonctionnalités à ne pas fournir pour le moment.
# Release Planning
## Objectifs du Release Planning
L'agilité n'empêche pas la planification à moyen ou long terme.
Le Release Planning est une **"macro" planification** *(ou planification haut niveau)* permettant de **définir une ligne directrice** en **se projetant sur plusieurs semaines ou plusieurs mois**.
Le Release Planning permet :
* ⏱D'estimer les **dates de disponibilité** des nouvelles fonctionnalités *(fixed scope)* ou inversement, les fonctionnalités disponibles à une certaine date *(fixed deadline)*.
* 🚨De **déceler les problèmes et retards** puis réagir le plus tôt possible.
* 🎯De **partager une vision d'ensemble**.
* 📦Synchroniser les équipes en cas d'interdépendance.
## Durée Couverte par le Release Planning
{% hint style="warning" %}
Plus la **durée couverte par le planning est longue**, plus la planification sera complexe et **moins elle sera précise**.
Une planification à plus de 6 mois est rarement rentable *(rapport : énergie de planification vs précision)*.
{% endhint %}
{% hint style="info" %}
**Le Release Planning n'est pas nécessaire.**
La plupart du temps, une planification à 3 ou 4 itérations *(avec des itérations d'une semaine)* suffit largement.
Cela est d'autant plus vrai dans le cadre d'une approche Lean Management.
{% endhint %}
## Release Planning vs Deployment
{% hint style="warning" %}
Contrairement à une idée communément reçue, le Release Planning **n'est pas lié au déploiement** des fonctionnalités implémentées.
Idéalement, l'équipe de développement devrait déployer ses changements en continu jusqu'à plusieurs fois par jour. Les fonctionnalités sont ensuite activées et déployées progressivement via des Feature Flags *(Cf.* [*Déploiement Continu*](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/deploiement-continu)*)*.
{% endhint %}
## Prérequis
* Un [*Product Backlog*](/scrum/artefacts/product-backlog) priorisé et estimé *(cette priorisation est généralement effectuée progressivement lors du* [*Backlog Refinement*](/scrum/evenements/backlog-refinement)*)*.
* La vélocité de l'équipe.
* La disponibilité de l'équipe *(i.e. : workforce)*.
## Release Planning
Grâce aux prérequis définis ci-dessus, il suffit de déduire les dates de livraison en distribuant les [User Stories](/scrum/artefacts/user-story) sur les itérations en fonction de la [vélocité](/scrum/mesures-et-outils/velocite) de l'équipe.
{% hint style="info" %}
Grâce au calcul de vélocité et l'estimation des *User Stories* à venir, on constate à l'avance qu'il ne sera pas possible d'inclure la fonctionnalité "...share wishlist" à la date du 5 mai.
Deux possibilités s'offrent à nous :\
\- Reporter la Release "v3" à la semaine suivante.\
\- Reporter la fonctionnalité à une autre Release.\
\- Reporter ou annuler une autre fonctionnalité.
{% endhint %}
# User Story Mapping
Le *User Story Mapping* est une **approche visuelle et pragmatique** pour **définir et prioriser** les besoins d'un produit.
Cette approche consiste à définir les [User Stories](/scrum/artefacts/user-story) en se **focalisant** sur les **principales interactions de l'utilisateur** avec le produit ainsi que son **parcours**.
{% hint style="success" %}
Le *User Story Mapping* doit se faire en présence de toutes les équipes impliquées dans la vie du produit *(Achats, Marketing, Support, IT, Finance, Légal)*.
{% endhint %}
{% hint style="danger" %}
La *User Story Map* n'est jamais figée ou "finalisée". Elle est le produit d'un travail incrémental et itératif.
{% endhint %}
## Intérêts du User Story Mapping
**Focalisation sur la valeur** apportée au produit d'un point de vue **utilisateur**.
**Priorisation pragmatique** grâce à la vision d'ensemble.
**Définition plus claire des besoins** grâce au focus sur le parcours utilisateur.
**Réduction du Time to Market** et **livraison rapide et fréquente** de valeur.
**Mise en évidence des risques** et dépendances.
**Consensus** grâce à l'implication de tous et au travail d'équipe.
## Le User Story Mapping Etape par Etape
1. Recueillir les **besoins** *(i.e. : use cases)*.
2. Définir les scénarios et **étapes** de chaque besoin.
3. Définir les [User Stories](/scrum/artefacts/user-story) pour chacune des **étapes à planifier.**
4. Identifier les prérequis, difficultés et informations manquantes.
5. Prioriser les [User Stories](/scrum/artefacts/user-story).
# eXtreme Programming
L'eXtreme Programming est une méthode agile conçue par **Kent BECK en 1996** *(également **initiateur de JUnit** qui inspire jusqu'à aujourd'hui tous les frameworks d'unit-test)* dans le cadre du développement de C3 *(Chrysler Comprehensive Compensation System)*, l'outil de gestion de paie de Chrysler *(avec actuellement plus de 77 000 salariés)*.
Contrairement donc aux idées reçues, l'eXtreme Programming n'est pas une méthode adaptée uniquement pour les petites startups.
En plus des principes communs avec le Scrum, l'eXtreme Programming **aborde d'autres aspects complémentaires** concernant la **qualité de développement** *(design, développement, pair programming, refactoring et testing)*.
Le nom eXtreme Programming vient de l'idée de **pousser toutes les bonnes pratiques de développement habituelles à l'extreme**. Cf. [Principes de l'eXtreme Programming](/extreme-programming/pratiques-de-l-extreme-programming).
Malheureusement, le nom de la méthode en a effrayé plus d'un et Kent BECK reconnait que le nom est mal choisi.
{% embed url="" %}
# Apprendre à Conduire
Dans son livre **eXtreme Programming Explained**, Kent BECK raconte comment il a appris à conduire pour expliquer les valeurs de l'eXtreme Programming.
*Tout commence avec le* [***courage***](/extreme-programming/valeurs-de-l-extreme-programming#courage) *de la mère de Kent BECK qui le laisse tenir le volant depuis son siège passager en lui indiquant simplement qu'il faut "**maintenir le véhicule au milieu de la voie**".*
*Au premier virage et dès le premier contact avec le gravier, la mère de Kent BECK met sa main sur le volant pour **remettre délicatement la voiture sur la voie** (Cf.* [*Pair Programming*](/extreme-programming/pratiques-de-l-extreme-programming#pair-programming)*) en lui expliquant que pour conduire, il ne s'agit pas de rouler tout droit mais plutôt **de*** ***rester attentif et de corriger la direction du véhicule en permanence** (Cf.* [*Feedback*](/extreme-programming/valeurs-de-l-extreme-programming#feedback)*).*
A cela, Kent BECK ajoute qu'il en est de même pour le développement d'un produit ; la ligne droite sans obstacle n'existe pas. Même quand la voiture semble avancer parfaitement au centre de la voie, nous ne sommes jamais à l'abris d'un changement. **Le changement est l'unique constante**.
## Cycle en V vs. eXtreme Programming
Le fantasme du Cycle en V est de calculer et de réfléchir pendant des années à comment pousser une voiture pour qu'elle roule toute seule jusqu'au bout de la route.
Cela a de moins en moins de sens dans un écosystème ou la durée de vie de certaines technologies est des quelques mois. On ne planifie pas le changement, on s'y adapte.
Selon Kent BECK, le rôle de l'équipe de développement est de **fournir au client un volant** et le **Feedback le plus proche du temps réel** de la position sur la route.
L'eXtreme Programming permet en quelque sorte d'optimiser la **manoeuvrabilité** de l'équipe.
# Valeurs de l'eXtreme Programming
### Communication
Les problèmes de communication forment l'une des principales menaces qui perturbent l'avancement du développement d'un produit de qualité.
Il n'existe pas de solution miracle face aux problèmes de communication mais l'eXtreme Programming essaie d'y remédier en encourageant naturellement les échanges grâce :
* au Planning Game,
* au Pair Programming,
* au Testing,
* à l'intégration continue,
* à la présence d'un Coach XP pour déceler les problèmes de communication.
### Simplicité
L'eXtreme Programming **parie sur la simplicité**.
Il s'avère en effet dans la pratique qu'**il est moins cher de concevoir des systèmes simples** et de les **adapter au besoin le jour venu** que d'essayer d'implémenter dès le premier jour le système qui répond aux besoins actuels et futurs.
### Feedback
Le Feedback rapide et permanent et l'une des valeurs fondamentales de l'eXtreme Programming autant sur un plan technique qu'organisationnel :
* Feedback de l'intégration continue concernant les tests.
* Intégration continue et retour de validation.
* Déployer le plus rapidement en production pour avoir un retour concret.
Seul un Feedback concret permet d'évaluer si une solution est bonne ou non.
Le Feedback rapide permet de retrouver plus facilement la source du problème, la corriger ou carrément la retirer immédiatement.
### Courage
Le courage est une valeur qui ne peut exister sans **communication** et **Feedback**.\
Sans ces deux valeurs, il est difficile d'avoir le courage de mener un changement radical dans l'organisation de l'équipe, le code ou l'architecture du produit.
Le courage permet également **d'abandonner des développements** ou **des choix** qui ne semblent finalement plus convenir.
Le courage favorise donc la simplicité en encourageant l'équipe à porter les modifications nécessaires pour simplifier le produit.
# Pratiques de l'eXtreme Programming
### Collective Ownership
N'importe quel développeur doit pouvoir modifier n'importe quelle partie du produit à n'importe quel moment.
**Le produit appartient à tous les membres** de l'équipe et **tout le monde est responsable** de l'ensemble.
### Pair Programming
Si le Code Review est une bonne pratique alors faisons du Code Review en permanence via du Pair Programming.
A minima, les parties les plus complexes du code doivent être développées en Pair Programming.
Le Pair Programming garantit une meilleure qualité de développement et encourage la propagation d'informations dans l'équipe.
### Testing
S'il est bien de tester le produit alors laissons tout le monde tester tout le temps via des tests unitaires automatisés, même les clients avec des tests fonctionnels.
### Refactoring
S'il est bien de concevoir avant de développer alors pourquoi en faire une tâche du quotidien pour tout le monde grâce au refactoring permanent.
Le Refactoring doit se faire dès que possible.
{% hint style="warning" %}
Le Refactoring n'est pas une tâche ou une User Story ; il fait partie de la réalisation de chaque tâche.
{% endhint %}
### Simplicité
Si les solutions les plus simples sont les plus séduisantes alors implémentons le système avec l'**architecture la plus simple** possible afin de répondre au **besoin actuel**.
L'équipe doit se concentrer sur le besoin actuel. Rien n'est implémenté à l'avance.\
Toutefois, le design du produit doit être extensible pour faciliter les enrichissements liés aux besoins futurs.
{% hint style="info" %}
Soyons visionnaires mais pas devins.
{% endhint %}
### Métaphore
Si l'architecture est importante alors tout le monde participera à la définition et l'adaptation de l'architecture en permanence.
L'équipe définit des métaphores simples et compréhensibles par tous.
C'est le principe précurseur du Domain Driven Design.
### Intégration Continue
Si le testing de l'environnement d'intégration *(ou staging ou qualification ou recette etc...)* est important alors nous intégrerons et testerons les changements plusieurs fois par jour.
Cela facilite entre autres, la traçabilité des effets de bord et erreurs etc... et évite les problèmes classique d'**Integration Hell**.
{% hint style="success" %}
L'intégration continue n'est pas suffisante, il faut intégrer les changements le plus fréquemment possible.
Commencez progressivement par vous imposer d'intégrer les changements au moins une fois par journée puis une fois par demi-journée jusqu'à atteindre des dizaines de changements par jour et par développeur.
On peut aller jusqu'à des centaines de changements par jour. Cf. *Test && Commit || Revert* et le *Limbo*.
{% endhint %}
### Small Releases & Planning Game
Si les itérations courtes sont préférables alors utilisons des itérations très très courtes se mesurant en secondes, en minutes et en heures plutôt qu'en semaines, mois ou années.
Le Planning Game est quelque peu similaire au Sprint Planning mais il peut être invoqué à n'importe quel moment tel un Backlog Refinement.
Lors du Planning Game, les Business Owners (Clients / Product Owner) présentent les User Stories, l'équipe de développement évalue les User Stories puis les Business Owners sélectionnent le périmètre (nombre de stories) ou la Deadline.
# Testing
{% hint style="info" %}
**ALL CODE IS GUILTY UNTIL PROVEN INNOCENT!**
{% endhint %}
Personne d'autre qu'un test automatisé ne peut garantir qu'un code fonctionne.
### Test-Driven Development
Les tests unitaires sont écrits en premiers.
### Tests are Specs
Les tests unitaires **définissent le comportement du code** à implémenter et non l'inverse.
### Tests are Documentation
Les tests unitaires ont l'avantage de fournir naturellement une documentation toujours à jour.
### **Tests MUST Pass**
Le code ne peut être livré tant que tous les tests unitaires ne fonctionnent pas.
Un test cassé doit être la priorité de toute l'équipe.
### Bugs Happen... but only Once!
Un bug est acceptable mais pas une régression.
A la découverte d'un bug, des tests unitaires doivent être ajoutés garantissant ainsi que le bug ne se reproduira plus jamais.
Les tests doivent être exécutés à chaque changement et les résultats doivent être publiés.
# Intégration Continue, Livraison Continue et Déploiement Continu
# Intégration Continue
L'intégration continue permet de **vérifier à chaque changement de code** que celui-ci **fonctionne correctement** sur une **environnement identique à celui de production** et sans perturber les autres fonctionnalités.
En eXtreme Programming, il est recommandé d'intégrer le plus fréquemment possible de petits changements afin d'en constater les conséquences le plus rapidement possible.
## Anecdote
Chez Wishtack, suite à un changement, nous avons constaté une fuite mémoire sur l'environnement d'intégration après quelques minutes.
Le diagnostic et la correction ont pris quelques secondes :
1. Récupération de l'identifiant du changement *(i.e. : commit git)* ayant introduit la fuite mémoire directement depuis l'outil de Monitoring.
2. Analyse du changement *(contenu du commit)*.
3. Il s'agissait d'un commit où seule une ligne avait changé pour intégrer une librairie externe victime de fuite mémoire.
4. Nous nous sommes débarrassé de la librairie pour trouver une solution alternative.
**Combien de temps et de claviers cassés cela aurait couté** si la fuite avait été découverte **à la livraison après plusieurs mois de développement** ?
Netflix raconte une fuite mémoire assez surprenante qui leur a couté une énergie considérable :
{% embed url="" %}
## Fonctionnement
1. A chaque modification, le développeur Check-In son code sur le Repository.
2. A chaque Check-In, le produit est rebuild automatiquement et les résultats sont publiés.\
Les résultats doivent être accessibles à toute l'équipe.
3. En cas de succès, les tests automatisés sont exécutés et les résultats publiés.
4. En cas de succès, les serveurs d'intégration sont mis à jour.
5. Toutes les parties prenantes *(développeurs, clients etc...)* peuvent évaluer la dernière version.
# Livraison Continue
En plus de tout ce que l'[Intégration Continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/integration-continue) propose, la **Livraison Continue** ajoute une dernière étape au process permettant aux parties prenantes autorisées de **déployer** la dernière version **en production par simple clic** mais également de **rollback** à la version précédente en cas de problème.
En plus de cette fonctionnalité, la livraison continue **implique surtout une façon de concevoir et de développer** les produits respectant les règles suivantes :
* Le code de l'environnement d'intégration doit fonctionner en production.
* L'intégralité du déploiement doit se faire automatiquement *(y compris les migrations de base de données par exemple)*.
* Le déploiement ne doit pas causer d'interruption de service.
* Le rollback doit être automatisable et se faire en un clic *(Pensez à la backward et forward compatibility ! e.g. : Le schéma de base de données est compatible avec la version précédente et la nouvelle version)*.
## Blue-Green Deployment
Le Blue-Green Deployment consiste à mettre en place **deux environnements identiques** : **Green** et **Blue** avec un Router en amont permettant de conduire le traffic vers Green ou Blue.
En supposant que **la version actuelle du produit tourne sur l'environnement Blue**, le Router conduit le traffic vers l'environnement Blue.
Au déploiement d'une nouvelle version du produit :
1. La nouvelle version est déployée sur l'environnement Green.
2. L'équipe de développement peut tester la nouvelle application en allant sur un nom de domaine particulier ou en modifiant leur configuration DNS ou en mettant un flag dans un header par exemple...
3. Une fois que le déploiement est validé, **l'intégralité du traffic de production est conduit vers l'environnement Green** plutôt que l'environnement Blue.
Le traffic est donc toujours conduit vers un seul environnement.
En cas de rollback, il suffit de reconduire le traffic vers l'environnement précédent.
## Feature Toggles
Une fonctionnalité finalisée doit être **livrée en production** le plus rapidement possible même si **celle-ci ne doit pas encore être accessible aux utilisateurs**.
L'activation de la fonctionnalité pourra se faire par configuration via des **Feature Toggles**.
{% hint style="success" %}
Les Feature Toggles peuvent également servir à déployer progressivement une fonctionnalité sur une population d'utilisateurs *(a.k.a. Canary Deployment).*
{% endhint %}
{% hint style="warning" %}
Evitez les mécanisme de configuration de Feature Flags trop complexes !\
Le déploiement de configuration devient alors "error-prone" et plus délicat que le déploiement de code.
{% endhint %}
### Exemple
Sur Wishtack, nous avons implémenté la fonctionnalité permettant de **participer à une cagnotte** **avant** la fonctionnalité permettant **de récupérer la somme cumulée sur la cagnotte**.
Il n'était bien sûr pas envisageable d'activer la première fonctionnalité sans la deuxième pour le grand public par contre, chez Wishtack, nous pouvions déjà expérimenter la première fonctionnalité en production avec des vraies transactions.
# Déploiement Continu
L'une des limitations de la [Livraison Continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/livraison-continue) est que la validation manuelle du déploiement **favorise la procrastination** et peut alors **encourager le déploiement par lot**. On retrouve alors les problèmes de l'Integration Hell en production ou alors des divergences de fonctionnement entre l'environnement de développement et la production.
Pour remédier à cela, le **Déploiement Continu** reprend exactement le même fonctionnement que la [Livraison Continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/livraison-continue) sauf que cette fois-ci le **déploiement est automatisé**. Chaque changement est donc automatiquement déployé jusqu'en production.
Le Déploiement Continu ne peut être efficace que si le produit dispose d'un jeu de tests automatisés largement suffisant pour garantir le bon fonctionnement de l'application.
La validation manuelle est toujours possible mais en utilisant une approche à base de [Review Apps](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/review-apps).
# Review Apps
Certains outils d'intégration continue combinés avec des plateformes de déploiement *(Cf.* [*GitLab Review Apps*](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/review-apps#gitlab-review-apps) *&* [*Heroku Review Apps*](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/review-apps#heroku-review-apps)*)* permettent de **créer dynamiquement des environnements de déploiement**.
Cela permet d'adopter l'approche de développement décrite ci-dessous.
Supposons que l'équipe de développement travaille sur deux fonctionnalités en parallèle **payin** *(pour le crowdfunding)* et **cashout** *(pour la récupération de la cagnotte)*.
1. Le code de production est sur la branche `master`.
2. L'équipe crée deux branches `payin` et `cashout` à partir de la branche `master`.
3. A chaque changement *(ou commit)* sur les branches `payin` ou `cashout` *(et si tout se passe bien)*, le produit **est déployé automatiquement sur un environnement créé dynamiquement et accessible depuis une URL** *(ou plusieurs)* créée dynamiquement ; par exemple, **`payin.review.wishtack.com`** et **`cashout.review.wishtack.com`**.
4. Les parties prenantes autorisées peuvent **valider 👍*****(ou rejeter 👎)*** le changement et **par simple clic**, le code est **"merged" dans la branche `master`**.
5. La branche `master` passe automatiquement par les process de "**build**" et "**test**" de l'[Intégration Continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/integration-continue).\
Dans le cas du [Déploiement Continu](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/deploiement-continu) : le produit est **automatiquement déployé en production**.\
Dans le cas de la [Livraison Continue](/extreme-programming/integration-continue-livraison-continue-et-deploiement-continu/livraison-continue) : le produit est **automatiquement déployé sur un environnement de validation** *(staging)* et prêt à être déployé en production par **simple clic**.
{% hint style="success" %}
De la même façon qu'il est idéal de définir les User Stories les plus granulaires possibles, il est recommandé de **réduire au minimum la durée de vie d'une branche et la quantité de changements**.
Il est intéressant de ne pas dépasser une **durée de vie d'un jour** pour chaque branche. Quitte à en recréer une nouvelle avec le même nom pour apporter de nouveaux changements.
Cela permet d'éviter le ***git spaghetti*** et les **conflits de merge**.
{% endhint %}
## Exemple
### Pipeline de build, deploy et test de l'Intégration Continue
### Validation d'une branche *(merge)*
### Déploiement manuel *(promote)*
### Rollback
## Heroku Review Apps
{% embed url="" %}
Heroku Review Apps
{% endembed %}
## GitLab Review Apps
{% embed url="" %}
GitLab Review Apps
{% endembed %}
# Indicateurs
Bien que le Scrum et l'eXtreme Programming ne définissent pas de liste d'indicateurs à mesurer pour analyser la santé de l'équipe, il est important d'établir une liste qui peut être optimisée régulièrement afin d'obtenir un résultat précis facilement.
Voici quelques exemples d'indicateurs :
### Vélocité de l'équipe
Si la vélocité baisse alors peut-être que l'équipe passe trop de temps sur du bugfix ou chore.
Cf. [Valeur, Bugs et Chores](/scrum/mesures-et-outils/valeur-bugs-et-chores).
### Volatilité de la vélocité
La volatilité de la vélocité indique la déviance de la vélocité par rapport à la vélocité moyenne.
Si la vélocité n'est pas stable alors il y a probablement un problème dans la façon dont l'effort est estimé ou alors les User Stories sont de taille trop importante.
### Gaspillage
Mesurez l'intérêt et le temps perdu dans les tâches "ingrates" ou celles qui semblent inutiles.\
Exemples : tâches manuelles, pointage, paperwork etc...
Cela peut révéler un "process" inutile ou l'absence d'outils adaptés.
{% hint style="info" %}
***Negativity Bias*** : Une heure sur une tâche "ingrate" est plus coûteuse qu'une heure sur une tâche utile.
{% endhint %}
### Moral de l'équipe
Pensez à mesurer l'humeur ou encore mieux le moral de l'équipe.
Cela peut se faire en proposant à chaque membre de répondre à ces questions à chaque Sprint Retrospective par exemple :
1. Je me sens adapté à mon équipe ;
2. Je suis fier du travail que je produis au sein de mon équipe ;
3. Je suis enthousiaste du travail que je dois produire ;
4. Notre travail a du sens.
{% hint style="warning" %}
Evitez le Niko Niko Calendar. Ce dernier peut nuire au moral de l'équipe.
{% endhint %}
### Isolement au sein de l'équipe
{% embed url="" %}
* Vos développeurs travaillent-ils avec des boucliers d’interaction sociale (A.K.A. casques audios) ?
* Entendez-vous du vocabulaire possessif au sein de l’équipe tel que “ton outil ne marche plus”; “mon code”; “j’ai fini ma story”; “ah non ! je ne toucherai pas à ça, c’est machin qui s’en occupe”; ”ce code/cette application/cet outil, c’est mon bébé !” 😱
* L’absence de certaines personnes clées peut-elle aboutir au blocage ou au ralentissement considérable de l’équipe ?
* Votre équipe peut-elle survivre avec 50% de l’effectif ?
* Est-ce que les développeurs sont capables de différencier le code qu’ils ont produits de celui des autres ?
### Qualité du produit
Nombre de bugs et satisfaction du ou des client(s).
### Code Smell
Qualité du code.
# Kanban
Le Kanban appliqué au développement est **inspiré de la méthode Kanban créée par Toyota** dans les années 50.
Le Kanban se focalise sur **l'amélioration continue** ainsi que la **production à la demande** afin de **réduire le stockage et la surproduction**.
Le Kanban appliqué au développement se base sur un système de Workflow similaire au Agile Board auquel **s'ajoute une limitation sur le nombre de User Stories** présentes simultanément dans la file de Work-In-Progress.
# Principes du Kanban
## Kanban, un complément
Le Kanban **ne définit pas de process**, il faut commencer avec un Process existant.
## Amélioration continue et incrémentale
Le Kanban encourage l'amélioration continue et incrémentale.
Un **changement radical** des méthodes d'organisation se soldera plus facilement par **un échec face à la résistance et la peur du changement**.
Le Kanban encourage de **petits changements réguliers**.
Respectez les Process actuels, rôles, responsabilités et titres !
Chaque organisation a probablement **des éléments qui fonctionnent** correctement et **méritent d'être préservés**.
Le Kanban **élimine le maximum de craintes** en maintenant les rôles, responsabilités et titres actuels.
## Leadership
Le Kanban encourage le Leadership à tous les niveaux, des contributeurs aux managers.
# Workflow
### Work-In-Progress limit
Chacune des étapes du Workflow a une **limite d'éléments simultanés par étape**.
### Lead time
Le Lead Time est **la durée moyenne entre l'entrée d'un élément dans le Workflow et sa sortie**.
### Lead time optimization
Le Process doit être amélioré régulièrement pour **réduire et stabiliser le Lead Time**.
# Indicateurs et Paramètres
## Les quatres indicateurs du Workflow
* Vélocité,
* Lead Time,
* Cycle Time,
* Qualité,
* Prédictibilité : régularité de la vélocité et des livraisons.
Le Kanban est une **méthode empirique**.\
Les indicateurs ci-dessus se règlent indirectement avec les paramètres ci-dessous.
## Quelques paramètres
Nombre de personnes dans l'équipe.
Taille vs nombre d'équipes.
Work-In-Progress limit.
Durée des itérations.
Planification court terme / long terme.
# Classes of Service
Dans la plupart des organisations, tous les éléments n'ont pas la même **notion de priorité ou d'échéance**.
Les éléments **ne peuvent donc pas être traitées de façon homogène** ; il faut appliquer **des contraintes de Workflow différentes** par catégorie d'éléments.
Les Classes of Service permettent de catégoriser les éléments afin de refléter la **priorisation en fonction des risques et de la valeur de l'élément.**
## Standard Class of Service
Cette classe regroupe les éléments qui ne sont pas associés aux classes décrites ci-dessous.
Après priorisation, ces éléments sont traités avec une approche "FIFO" *(First In / First Out)*.
## Expedite Class of Service
Cette classe est attribuée aux **éléments prioritaires**.
{% hint style="success" %}
Pour éviter de perturber l'avancement général du Workflow, il est recommandé d'**attribuer une limite de Work-In-Progress spécifique** pour les éléments de cette classe.
{% endhint %}
{% hint style="danger" %}
Un **nombre important d'éléments** dans cette classe révèle un **manque de confiance** en la capacité de livraison.
{% endhint %}
## Fixed Delivery Date Class of Service
Cette classe est attribuée aux éléments devant être **livrés à une date spécifique**.
Les éléments de cette classe doivent être mis dans la file Work-In-Progress **suffisamment en avance pour respecter l'échéance**.
{% hint style="success" %}
Les éléments de cette classe doivent avoir une **date d'échéance définie par une contrainte extérieure** *(e.g. : mise en conformité, migration ou compatibilité technique...)*.\
Autrement, le Kanban serait utilisé comme un diagramme de Gantt.
{% endhint %}
## Intangible Class of Service
Cette classe est attribuée aux éléments dont il est **difficile d'évaluer la valeur apportée à l'utilisateur** *(bug fixes, chores, optimisations, changement de design, etc...)*.
Cette classe a **la priorité la plus basse**.
# Transformation Agile
# Projet Pilote
# Plan de Passage à l'Agilité
## Engagement
L'équipe entière *(Business Owner, Product Owner, Coach, Scrum Master et l'équipe de développement)* doit **s'engager dans la transition** : **temps**, **budgets**, **formation**, **outils**, **communication** et **flexibilité**.
Les méthodes agiles nécessitent une implication importante du Business Owner. Il faut changer les habitudes et **réduire la distance avec le Business Owner**.
L'équipe doit être flexible et prête au changement *(repriorisation, ajout de nouveaux besoins etc...)*.
L'équipe de développement doit faire preuve de **créativité** et **d'imagination** pour **diviser les développements à réaliser leurs objectifs avec des incréments granulaires**.
L'agilité ne peut réussir que grâce à des **interactions directes et informelles entre tous les membres de l'équipe.**
## Formation et Accompagnement
L'ensemble des membres de l'équipe ***(y compris le Business Owner)*** doivent être formés à l'agilité le plus tôt possible.
Il est préférable de partir sur de bonnes bases agile pour réussir la transition. L'accompagnement d'un expert agile facilitera la transition.
## Préparation
On commence par créer l'équipe puis remplacer les anciens rôles par les rôles agiles ***(le Scrum Master n'est pas un chef de projet)***.
**L'équipe définit le Transition Point** qui peut être une nouvelle Release, un nouveau produit ou simplement une date. **L'intégration des pratiques agile ne peut pas se faire partiellement** ou progressivement.
L'équipe **définit ses paramètres agiles initiaux** *(durée des itérations, heure du Stand-Up Meeting etc...)*.
L'équipe peut enfin **préparer le Product Backlog** de façon rigoureuse.
# Le Changement
**Abandonner ou détourner** une pratique agile **peut empêcher la réussite** de la transition agile.
Il faut plutôt **régler les problèmes organisationnels** actuels qui empêchent la mise en place de la pratique agile en question.
**Mesurez le stress de l'équipe** et réagissez en avance et à la source.
**Stressée**, **l'équipe retombe dans le cycle en V**, abandonne l'autonomie de l'équipe de développement, réduit les estimations, ignore les contraintes du Definition of Done et abandonne les tests et la documentation.
Un chat stressé perd son équilibre et son agilité.
# Contractualisation
Les méthodes agiles sont principalement adaptées pour le développement en interne des produits d'une entreprise.
Il est difficile de mettre en place les méthodes agiles dans le cadre d'un contrat forfaitaire.
Dans le meilleur des cas, la modification du Scope est abandonnée mais les autres pratiques maintenues grâce à des interactions régulières avec le client ; autrement, ce n'est plus de l'agilité.
## La clause contractuelle du Changement Gratuit
Le contrat forfaitaire est défini avec un Scope de User Stories.
La clause du **Changement Gratuit** n'est valide que si le client s'engage à **interagir régulièrement avec l'équipe agile**.
Le client peut ainsi reprioriser les User Stories et les remplacer *(à estimation d'effort égale)*.
Si le client ne respecte pas cette clause alors une clause "**enveloppe supplémentaire en mode régie**" est déclenchée.
## La clause contractuelle Gagnant-Gagnant
Cette clause permet au client d'**interrompre le contrat à la fin de n'importe quelle itération**.
Le client peut ainsi abandonner les User Stories futures en considérant que la version actuelle est suffisante.
Le client paie au prorata des **User Stories livrées plus un pourcentage**.
L'interruption peut être violente mais le pourcentage supplémentaire permet à l'équipe de rebondir.
# Management
L'équipe agile doit disposer de **tous les moyens nécessaires** *(formation, outils et compétences)*.
L'équipe agile doit rester **autogérée** et idéalement sans hiérarchie.
Vue de l'extérieur, **l'équipe agile** n'est pas un ensemble d'individus mais **une seule entité**. Seuls les indicateurs agiles *(User Stories Backlog, vélocité, produit etc...)* sont donc visibles et discutables.
## Developer eXperience
Il faut préserver l'équipe agile des perturbations et blocages extérieures *(e.g. : réunions superflues, demandes manuelles / délais / négociations avec les autres équipes, bureaux communs avec d'autres équipes, etc...)*.
# Scrum of Scrums
Les organisations disposant de plusieurs équipes agiles organisent un regroupement des Scrum Masters au moins une fois par itération.
Le Scrum Master peut se faire accompagné *(ou remplacé)* par un expert de l'équipe.
L'objectif est d'améliorer les interactions entre les équipes, faire circuler l'information entre les équipes, réduire les obstacles et les dépendances entre les équipes.
# Agile at Scale
## Spotify Engineering Culture
{% embed url="" %}
Spotify Engineering Culture - Part 1
{% endembed %}
{% embed url="" %}
Spotify Engineering Culture - Part 2
{% endembed %}
{% embed url="" %}
{% embed url="" %}
## LeSS | Large Scale Scrum
{% embed url="" %}
## SAFe | Scaled Agile Framework
{% embed url="" %}
# Transformation Etape par Etape
## Choix des Paramètres
### Durée des Itérations
Il faut d'abord définir la **durée des itérations** et **le jour de la semaine où chaque itération démarre**.
En général, il **est préférable d'opter pour la durée la plus courte** *(une semaine)* pour les raisons suivantes :
* plus de transparence et réduction de l'effet tunnel,
* **feedback plus fréquent** du client,
* possibilité de **pivoter** et rectifier le tir plus **rapidement et fréquemment**,
* **favorisation d'un rythme régulier et durable** en évitant les coups de stress en fin d'itération,
* **calcul plus précis de la vélocité** et projection plus précise *(e.g. : avec des itérations de 3 semaines, il faut attendre plus de 2 mois avant d'avoir la vélocité moyenne sur les 3 dernières itérations)*,
* **si un membre de l'équipe rate un événement, cela devient problématique** car le prochain événement aura lieu dans plusieurs semaines,
* il est plus facile de **coordonner des équipes** qui démarrent **une nouvelle itération chaque lundi**. Autrement, les itérations s'enchevêtrent.
Si vous avez besoin d'itérations plus longues, posez-vous d'abord les questions suivantes :
* si vous constatez une volatilité importante de la vélocité ou effet tunnel *(i.e. : des itérations ne produisant aucune valeur suivies d'itérations produisant un nombre important de points)*, est-ce possible de **découper les User Stories encore plus finement** ?
* est-ce possible de **réduire le** [**Work-In-Progress Limit**](/kanban/workflow#work-in-progress-limit) ?
* si certains événements prennent trop de temps, est-ce que le Definition of Ready est bien respecté ? Est-ce possible d'améliorer le Collective Ownership pour raccourcir les discussions ?
{% hint style="warning" %}
**Des itérations plus longues nécessitent plus de préparation** et des [Sprint Planning](/scrum/evenements/sprint-planning) plus longs. Si lors du [Spring Planning](/scrum/evenements/sprint-planning), vous ne préparez qu'une partie de l'itération en attendant le prochain [Backlog Refinement](/scrum/evenements/backlog-refinement), vous êtes peut-être en train de créer une itération au sein de l'itération 😉
{% endhint %}
### Échelle de Points *(ou Point Scale)*
Il est nécessaire de sélectionner un *Point Scale* pour évaluer l'[effort](/scrum/mesures-et-outils/story-points-vs-temps) nécessaire pour chaque [User Story](/scrum/artefacts/user-story).
Nous vous recommandons les échelles :
* **1, 2, 3 & 8**
* ou **1, 3, 5 & 15**.
où la dernière valeur sert à estimer les [User Stories](/scrum/artefacts/user-story) qui nécessiteront d'être découpées ultérieurement. **On ne démarre donc pas le développement d'une** [**User Story**](/scrum/artefacts/user-story) **à 8 ou 15 points.**
Nous préférons ces échelles pour les raisons suivantes :
* en réduisant le nombre de valeurs possibles, vous réduisez également l'hésitation et la durée des [Spring Planning](/scrum/evenements/sprint-planning) et [Backlog Refinement](/scrum/evenements/backlog-refinement),
* ces échelles encouragent le découpage des [User Stories](/scrum/artefacts/user-story),
* l'échelle **S, M, L & XL** est également intéressante mais il faut reconvertir en points pour calculer la vélocité et la projection.
{% hint style="info" %}
**Astuce :** dans le cas de planification moyen ou long terme, n'hésitez pas à **réduire l'échelle** *(e.g. : 1, 3 & 8)* afin d'**accélérer le temps d'estimation** en sacrifiant légèrement la précision qui sera probablement erronée dans tous les cas.
{% endhint %}
### Work-In-Progress Limit
Définir un [WIP limit](/kanban/workflow#work-in-progress-limit) relativement bas encourage naturellement le Collective Ownership, le Pair Programming et favorise la communication.
A vous d'expérimenter, mesurer et trouver le WIP limit qui vous convient mais la formule suivante est généralement un bon point de départ :
$$
wiplimit = floor(teamsize / 2)
$$
## Definition of Done
L'équipe doit définir **son propre** [**Definition of Done**](/scrum/artefacts/definition-of-done) puis l'**enrichir en fonction de son expérience** et ses erreurs.
## Definition of Ready
De même que pour le [Definition of Done](/scrum/artefacts/definition-of-done), l'équipe doit définir et maintenir son [Definition of Ready](/scrum/artefacts/definition-of-ready).
## Préparation de la Première Itération
### Premières *User Stories*
Définissez les premières [User Stories](/scrum/artefacts/user-story) conformément au [Definition of Ready](/scrum/artefacts/definition-of-ready) ; lors d'une session de [User Story Mapping](/priorisation-and-planning/user-story-mapping) par exemple.
### Choix des Technologies et Outils *(si applicable)*
Si vous devez choisir les technologies et outils à utiliser, focalisez-vous sur la simplicité, la maintenabilité et la facilité de changer plus tard.
Pensez à vous faire accompagner dans ce choix.
### Recrutement *(si applicable)*
Recrutez progressivement !
Une **rencontre avec l'intégralité de l'équipe** pourrait être l'avant dernière étape de recrutement ; la dernière étant **une semaine d'essai au sein de l'équipe**.
### Indicateurs
Pensez à choisir et mesurer vos [indicateurs](/indicateurs) avant de démarrer !
## Rencontre Directe avec le Client et les Utilisateurs
### **Pas d'Intermédiaires**
Le *Product Owner* ne doit pas être un intermédiaire entre l'équipe et le client.
Généralement, il faut éviter les intermédiaires car inconsciemment **l'information sera toujours déformée et filtrée.**
Il est donc important que l'intégralité de l'équipe et le client puissent échanger au moins lors du [Sprint Review](/scrum/evenements/sprint-review).
Faites tout de même **attention aux clients envahissants** !
### **Rencontrez vos Utilisateurs !**
Organiser des rencontres et échanges directs entre une sélection d'utilisateurs finaux et l'équipe permet de démystifier de nombreux aspects concernant l'utilisation du produit.
La rencontre fournit donc un indicateur qualitatif supplémentaire.
## Sprint Review
Organisez des [Sprint Review](/scrum/evenements/sprint-review) même en l'absence du client et **invitez d'autres équipes** ou les curieux.
Certaines entreprises affichent les horaires de [Sprint Review](/scrum/evenements/sprint-review) des différentes équipes dans leurs couloirs.
## Transparence et Propagation
Soyez transparents et sincères !
Expliquez votre approche aux autres équipes et partagez votre expérience !
# Outils
## Les limitations sans logiciel
Il faut :
* gérer l'Agile Board manuellement sur un tableau par exemple,
* calculer la vélocité manuellement,
* calculer le total des estimations et les échéances manuellement,
* produire les Burn Down et Burn Up manuellement.
Toutes ces tâches sont fastidieuses et Error-Prone.
Autres inconvénients de l'Agile Board physique :
* post-it perdu,
* problème de confidentialité,
* Agile Board inaccessible de l'extérieur *(home office ou rendez-vous chez le client)*,
* problèmes de lisibilité,
* limitations d'espace sur l'Agile Board et sur les sticky notes pour partager des informations,
* pas de partage de liens, de fichiers joints etc... associés au tâches.
{% hint style="success" %}
Il est donc recommandé d'utiliser un outil web adapté.
{% endhint %}
## Choix des outils
Pour sélectionner l'outil adapté, en plus des fonctionnalités, il faut prendre en compte les critères suivants :
* **outils cloud** : souvent payants mais ne nécessitent aucune gestion ou administration.\
Ils ont aussi l'avantage d'être contrôlables par API et de pouvoir intéragir avec d'autres services cloud *(Code Repository, Continuous Integration, etc...).*
* **outils self-hosted** : plus économique mais nécessite gestion et administration.
* **outils open-source** : ces outils ont l'avantage d'être plus extensible et personnalisables.\
Sans oublier que vas cas particuliers ne sont pas assez particuliers pour mériter un traitement particulier.
## Quelques outils
### Planning Poker
{% embed url="" %}
### Pivotal Tracker
Cloud, accès direct aux Commits de code associés à la User Story, **répartition automatique** du backlog sur les itérations à venir, API, etc...
{% embed url="" %}
### Codeminer42 Central : Alternative open-source de Pivotal Tracker
{% embed url="" %}
### Agilefant
Self-hosted ou cloud, arborescence de User Stories, différentes vues par rôle.
{% embed url="" %}
### Autres
{% embed url="" %}
# Quelques Liens
## Scrum Guide
Scrum Guide by [Ken Schwaber](https://twitter.com/kschwaber) and [Jeff Sutherland](https://twitter.com/jeffsutherland).
{% embed url="" %}
## Semantic Diffusion
{% embed url="" %}
## Product Owner vs Product Manager
{% embed url="" %}
## Martin Fowler explaining Agile
{% embed url="" %}
## Kent Beck about Scrum & Facebook
{% embed url="" %}
# Agile Causal Relations
# Talks
{% embed url="" %}
Leaving Facebook - Kent Beck
{% endembed %}
{% embed url="" %}
{% embed url="" %}
Agile in 2018
{% endembed %}