Limawi français

Du cloud, du devops et des outils pour tout ça.

[limawifr]

Poker agile

Le poker agile est une façon ludique d’évaluer la complexité des Stories en méthode agile.

Méthode agile : Présentation générale

Le poker agile se présente sous la forme d’une suite de cartes dont chaque personne reçoit un paquet complet. Lors de la cérémonie de sprint, l’équipe se sert des cartes pour évaluer la complexité des histoires (User Stories, NFR ou Spike) envisagées.

Le point de complexité

Pour calculer la difficulté à réaliser une histoire, le premier réflexe serait de déterminer une durée.

Cette approche peut amener à un créer un environnement anxiogène. En effet, un développeur (marketeur ou autre) en charge de l’histoire pourrait se sentir piégé par le temps et réaliser l’histoire trop vite et mal.

Bien sûr, la phase de revue permet de pallier à ce problème en faisant refaire des parties de l’histoire encore et encore mais c’est une perte de temps, d’énergie et de ressources.

Alors, voilà le point de complexité.

Cet outil permet de déterminer une valeur de complexité de l’histoire. Cette valeur peut être définie en rapport avec les autres histoires ou en valeur absolue.

En développement logiciel, on peut calquer la valeur du point de complexité agile sur la complexité du code à réaliser. Par exemple :

une classe = 1 point, 3 classes = 3 points

1 point par méthode

via une complexité calculée (par exemple en PHP)

Chaque histoire se voit assigner des points de complexités par l’intermédiaire du Poker agile.

La vélocité

Le point de complexité n’est pas corrélé à une durée. Du moins dans un premier temps.

Lorsqu’une équipe agile commence à être bien rodée (c’est à dire après quelques Sprints), on peut commencer à voir le nombre de points de complexité moyen que l’équipe peut réaliser par Sprint.

C’est la vélocité.

C’est une approche par paquet mais il peut être problématique de vouloir trop détailler le temps moyen passé par point de complexité car on reviendrait à une situation trop anxiogène.

Une fois une vélocité moyenne estimée, l’idée est de pouvoir mesurer la performance de l’équipe et de chercher à maintenir cette vélocité.

Il n’est pas forcément avisé de chercher à l’accroître, pour éviter, encore une fois, de revenir à une situation anxiogène.

Les règles du Poker

À chaque histoire, chaque membre de l’équipe choisit une carte dans son paquet et la garde pour lui, face cachée. Cette carte représente son estimation de la complexité de l’histoire.

Quand tous les membres de l’équipe ont choisi leur carte, tout le monde retourne ses cartes en même temps.

Ceux qui jouent les cartes les plus éloignées de la moyenne expliquent plus particulièrement leur point de vue. Un consensus se forme alors sur la complexité estimée par l’équipe.

Les paquets de cartes disponibles, ci-dessous, sont au nombre de 7 (une équipe agile de taille standard). Ils sont différentiables par leur couleur.

Chaque paquet contient :

une suite de Fibonacci : pour des estimations précises ou des jours de travail (pour des Spikes) en utilisant la grille au centre (une colonne représente une semaine complète) ;

des tailles de T-shirt : pour des estimations moins précises ;

un positif et un négatif : pour approuver ou désapprouver ;

un point d’interrogation : quand on n’a aucune idée ;

un café : quand il est temps de faire une pause ;

un infini : quand l’histoire est trop grande et qu’il faut la décomposer.

Téléchargez le jeu complet ainsi que des dos de cartes.

Sources

L’expérience Limawi

Atlassian

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on May 20, 2020 at 2:12am PDT

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on May 20, 2020 at 2:13am PDT

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on May 20, 2020 at 2:15am PDT

[limawifr]

Le User persona

Le User persona est une méthode qui permet de décrire au mieux l’utilisateur en méthode agile.

Méthode agile : Présentation générale

Il est parfois compliqué de savoir par qui le résultat du projet sera utilisé. C’est là que le user persona intervient. Ils sont la représentation concrète des cibles utilisateurs du projet.

La fiche personnage

Un user persona ressemble à une fiche de personnage de jeu de rôle (pour les connaisseurs). Cette fiche permet d’avoir d’un coup d’œil l’ensemble des caractéristiques d’une personne.

À travers cette fiche, on cherche à connaître ses centres d’intérêt, son histoire, sa culture… On crée une personne physique de toute pièce.

Les ateliers du Discovery & Framing dédiés au user persona permettent de faire vivre cette personne, de lui donner de la consistance. N’hésitez pas à faire du jeu de rôle avec.

Il est par contre crucial de ne pas faire intervenir la relation éventuelle de la personne avec le résultat du projet. Cela risquerait de fausser les caractéristiques de la personne.

En marketing agile

Il est inutile de présenter ce concept en marketing car il est bien connu de tous. Cette fiche permet de définir les vecteurs d’acquisition, les moyens de toucher la cible.

C’est à elle que s’adresse les Stories (ou User stories). C’est cette cible qui effectue l’action décrite au sein de ces stories.

Il ne faut pas, par contre, avoir peur de la modifier, de l’affiner au cours des Sprints.

On peut même être amené à la remplacer totalement si on se rend compte que la cible du projet change.

En développement agile

Cette fiche est utile pour orienter l’ergonomie et la priorité des fonctionnalités demandées par le client.

En adéquation avec le Product Owner, les développeurs ont un sujet de discussion pour décrire au mieux les User stories.

Là aussi, cette fiche effectue l’action décrite dans les User stories.

Il est donc utile d’avoir plusieurs user persona selon les rôles des utilisateurs du projet. Un user persona pourra représenter un administrateur du projet, un autre un simple utilisateur.

En projet de développement pur (dans lequel c’est le client qui s’occupe du marketing), les user personas sont décrites en Discovery & Framing et validées par le client.

En projet incluant du marketing, les user personas peuvent être modifiées par les équipes marketing avec une validation des équipes de développement. Dans ce cas, le Buyer persona doit aussi être inclus (celui qui achète le résultat du projet mais ne l’utilise pas forcément).

On peut même imaginer qu’un représentant de l’équipe marketing devienne le Product Owner (ou un adjoint du Product Owner) auprès de l’équipe de développement, puisqu’il est sensé mieux connaître les user personas.

Téléchargez notre template de User persona (au format odg, LibreOffice et OpenOffice).

Sources

L’expérience Limawi

Ricoh

Just in Mind

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on May 27, 2020 at 5:39am PDT

[limawifr]

Le lean canvas

Le Lean Canvas permet d’avoir une vue globale et synthétique d’un projet agile.

Méthode agile : Présentation générale

Le Lean Canvas permet de décrire rapidement un projet sans oublier des éléments importants.

Il est utilisé par les startups pour démarrer leur projet mais peut être utilisé en méthode agile pour garder la cohérence du projet entre les multiples acteurs.

En effet, un bon Lean Canvas permet à l’équipe ou aux équipes agiles de prioriser les histoires ou de les réécrire, en accord avec le Product Owner, pour ne pas dévier d’objectifs à plus ou moins long terme voulus par les clients.

Présentation d’un Lean Canvas

La case « Problème » (Problem) permet de définir l’objectif du projet. Elle permet de maintenir le cap lors de la conception des Users Stories.

La case « Solution » permet de définir l’objectif minimum viable à atteindre avant une mise en production. Il faut prioriser les Users Stories de développement en fonction.

La case « Indicateurs de performances » (Key Metrics) permet de définir les NFR prioritaires.

La case « Proposition de valeur unique » (Unique Value Proposition) permet de définir les Users Stories de développement et NFR prioritaires dès la mise en production.

La case « Avantage compétitif » (Unfair Advantage) permet de définir les Spikes prioritaires dès la mise en production.

La case « Canaux » (Channels) permet de définir les Users Stories de marketing à prioriser.

La case « Segments de clientèle » (Customer Segment) permet de définir les user personas (dont les buyers personas si le projet inclut du marketing).

Les cases « Coûts » (Cost Structure) et « Sources de revenus » (Revenue Streams) peuvent faire l’objet de NFR. Leur analyse permet de prioriser certaines histoires (les histoires qui coûtent le plus dans les sprints au cours desquels les sources de revenu fonctionnent le mieux et inversement).

Si on regarde au niveau des histoires, le Lean Canvas est la représentation visuelle de la Saga.

Téléchargez notre template de Lean Canvas (au format odg, LibreOffice et OpenOffice).

Sources

L’expérience Limawi

L’inventeur du Lean Canvas

Business Builder

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on May 13, 2020 at 2:08am PDT

[limawifr]

Elevation of Privilege

Elevation of Privilege est un jeu de cartes qui permet de modéliser les menaces sur un système.

Méthode agile : Présentation générale

Modèle de menace

Un modèle de menace est un outil qui permet de déterminer à l’avance les fragilités d’un système et les moyens d’y remédier.

Dans la méthode agile, il est continuellement mis à jour. Il doit suivre le produit existant et s’adapter rapidement aux nouvelles évolutions.

Comment y parvenir ?

Schémas et diagrammes

Dans un premier temps, il est nécessaire de documenter votre projet. Il doit avoir des représentations visuelles de ses composants et des flux d’informations.

Une des manières de représenter ces données est le langage UML. Le problème est que ce langage est complexe à écrire et à mettre à jour pour un être humain.

Il est donc préférable d’automatiser au maximum la documentation et ses diagrammes (qu’ils soient en UML ou une autre représentation) pour pouvoir les produire facilement à chaque évolution du projet.

Si les diagrammes sont faits manuellement, des dessins de patates suffisent. Il faut juste qu’ils soient compréhensibles par tous les membres de l’équipe.

Une fois ces diagrammes faits, on va pouvoir les étudier pour en déceler les failles. Et ce, de façon ludique, grâce au jeu « Elevation of Privilege ».

Les règles du jeu

Pour cela, prévoyez une phase de la cérémonie de sprint dédiée à ça.

L’équipe est assise autour d’une table. Le diagramme de la partie du projet à analyser est étalé sur la table visible de tous.

Le jeu de carte « Elevation of Privilege » est disponible en dessous.

Distribuez toutes les cartes aux joueurs. La partie commence avec le « 3 of tampering ». Jouez dans le sens des aiguilles d’une montre.

Cela ressemble beaucoup aux règles du Tarot.

Chaque joueur continue dans la même suite s’il a une carte dans la suite. Sinon, il joue une carte d’une autre suite.

Chaque pli (un tour de table) est gagné par celui qui a la plus haute carte dans la suite demandée au départ, sauf si une carte « Elevation of Privilege » est jouée (dans ce cas c’est la plus forte de ces cartes qui l’emporte).

Pour jouer une carte, le joueur doit l’annoncer et essayer de trouver sa menace sur le diagramme. Le système peut être résistant à cette menace. Dans ce cas, il est impossible de trouver la menace sur le diagramme.

Le joueur doit annoncer clairement sa menace. Pour être valide, elle doit amener à la création d’une histoire (NFR d’ouverture de bug, User Story, …) dans le projet.

À la fin du pli (quand tous les joueurs ont posé une carte de leur main), tous ceux qui ont réussi à trouver leur menace sur le diagramme ont un point. Si celui qui a gagné le pli a réussi aussi à trouver sa menace sur le diagramme, il gagne un point supplémentaire.

Le gagnant du pli démarre le pli suivant et choisit la suite de départ. Prenez quelques minutes entre chaque pli pour étudier les menaces.

Les cartes « Elevation of privilege » gagnent sur toutes les autres. Elles ne peuvent être jouées que quand le joueur n’a pas de carte dans la suite demandée (ou si la suite demandée est elle-même « Elevation of privilege »).

Les « As » sont des cartes qui permettent de trouver des menaces non prévues dans la suite demandée. Le joueur doit expliquer la menace elle-même.

Quand toutes les cartes ont été jouées (tous les plis ont été faits), celui qui a le plus de points l’emporte.

Annotez votre diagramme en fonction des menaces trouvées.

Vous pouvez faire passer les mains d’un joueur à l’autre entre chaque pli. Cela permet que les joueurs spécialisés puissent jouer des cartes que des joueurs précédents ne comprenaient pas.

D’autres joueurs que celui qui annonce sa carte peuvent surenchérir sur sa carte en trouvant la menace annoncée à d’autres emplacements que ceux trouvés par celui qui joue. Ils gagnent un point supplémentaire.

Téléchargez « Elevation of Privilege » et son extension « Elevation of Privacy », avec les règles EoP et une planche de dos de cartes.

Sources

EoP, license Creative Commons attribution 3

Eop (extension privacy), licence Creative Commons

EoPrivacy, license Creative Commons attribution 4

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on May 6, 2020 at 1:57am PDT

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on May 6, 2020 at 1:59am PDT

[limawifr]

Discovery & Framing

Le Discovery & Framing est la phase initiale d’un projet agile et il est utilisé pour le dégrossir.

Méthode agile : Présentation générale

« Discovery and Framing » sont 2 termes associés (la découverte et l’encadrement) qui qualifient une phase initiale précédant les sprints.

Cette phase permet de dégrossir un projet et de le formaliser pour pouvoir le conduire en méthode agile. Elle s’étale généralement sur une semaine.

Cela s’articule en 2 parties, la découverte et l’encadrement (d’où le nom).

La découverte

Elle commence le lundi et s’arrête si possible le mercredi.

Chaque jour, on détaille des hypothèses sur le projet et on interroge les clients (beaucoup). Une réunion a lieu tous les matins pour rassembler les résultats et recommencer (ça s’apparente au scrum).

Ne cherchez pas à estimer des temps, c’est une phase de recherche. Si cette phase déborde trop au delà du mercredi, il faudra peut-être planifier une nouvelle semaine.

L’encadrement (la formalisation)

À partir du mercredi, vous pouvez commencer à créer des ateliers au sein des équipes. Ces ateliers ont pour objectifs de définir les grands identifiants du projet :

Les « buyers personas » et les « final users personas » : cette technique est souvent utilisée en marketing pour cibler les marchés. Dans le cas présent, il faut voir plus large et plus technique. Comment les utilisateurs finaux vont-ils se servir du système ? Quels sont leurs cultures, leurs histoires pour prévoir l’ergonomie du système ?

Déterminer quel est l’objectif minimum viable à atteindre. C’est à dire l’ensemble des fonctionnalités absolument nécessaires pour la première version du système. C’est le « Minimum viable product » (le produit minimum viable).

À partir des ces données, extraire un Lean Canvas qui servira de fiche globale du projet.

Déterminer l’environnement de développement nécessaire et les outils pour pouvoir développer, tester et mettre en production cette première version.

Commencer à détailler les epics, sagas, themes et initiatives du projet mais pas encore les stories, NFR et Spike. L’objectif est d’avoir une vision du projet à long terme.

Bouclage et suite

Cette semaine se boucle avec une réunion de rétrospective (rappelant la cérémonie) durant laquelle on fait le point. Bien sûr, cette réunion ne doit pas dépasser 2 heures pour être efficace.

Cette phase de Discovery&Framing peut se répéter (s’itérer) sur plusieurs semaines jusqu’à ce que l’ensemble des acteurs du projet soient satisfaits des grands identifiants.

Une fois cette phase finie, alors les Sprints démarrent. Selon le projet, on peut caler un Sprint 0 à ce moment-là, qui sert de Sprint de chauffe.

Sources

L’expérience Limawi

My Agile Partner

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Apr 29, 2020 at 6:53am PDT

[limawifr]

Méthode agile : La cérémonie

La cérémonie permet de rassembler tous les acteurs d’un projet agile et de redéfinir les objectifs.

Méthode agile : Présentation générale

La cérémonie est la réunion qui permet de rassembler l’équipe agile (l’équipe de développement), le Scrum Master (le « manager » de l’équipe) et le Product Owner (le représentant du client) et éventuellement les clients.

Elle intervient généralement entre les sprints, donc à intervalles réguliers.

Cet évènement est divisé en plusieurs phases. Certaines équipes choisissent de disjoindre ces phases pour alléger les réunions.

Phase 1, en début de projet (sprint planning meeting)

Maître de cérémonie : Le Product Owner assisté du Scrum Master

Durée : moins de 2 heures.

Cette phase permet de détailler une grande partie des histoires sous forme de stories, NFR ou Spike et de les répartir tous au long des sprints prévus.

Elle permet d’estimer les grandes lignes du projet. Elle se concentre aussi sur la cohésion d’équipe et la découverte de l’équipe avec les clients et le projet.

Le but est de lancer le premier sprint (Sprint 1 ou Sprint 0) dans des bonnes conditions.

Phase 1, en cours de projet (sprint review)

Maître de cérémonie : Le Product Owner assisté du Scrum Master

Durée : moins d’1 heure.

Cette phase permet de faire le point sur le sprint précédent. Au sein de cette phase, l’équipe agile explique à l’ensemble des acteurs du projet le résultat du sprint. Des démonstrations peuvent être effectuées durant cette phase auprès des clients, d’utilisateurs finaux, d’un panel représentatif…

Les clients à travers le Product Owner doivent avoir une idée de l’état du projet.

Lors de cette étape, l’ensemble des acteurs font leurs retours à l’équipe agile. Il ne faut pas hésiter, c’est là qu’on peut réorienter le projet et préparer la phase 2.

Petit bonus Limawi, entre les deux phases

Maître de cérémonie : Aucun, c’est un jeu de cartes

Cette inter-phase consiste à revoir les modèles de menaces grâce au jeu « Elevation of Privilege ». Cette méthode est expliquée dans un article dédié.

Phase 2, centrée sur le projet (product backlog refinement)

Maître de cérémonie : Le Product Owner assisté du Scrum Master

Durée : moins d’1 heure, peut être très rapide.

Cette phase permet de réorganiser les histoires (stories, NFR, Spike) pour le prochain sprint. L’équipe agile questionne le Product Owner sur les histoires afin qu’elles soient les plus claires possible. L’équipe, ensuite, estime la charge de travail de l’ensemble de ces histoires (sous forme de points de complexité ou de temps) en utilisant le Poker agile. Une fois les histoires estimées, le Product Owner les priorisent en fonction de la vélocité de l’équipe. Il les place en « TODO » et renvoie celles en trop dans le Backlog (en « POSTPONED »).

Cette phase peut intervenir par petites touches tout au long du sprint. Dans ce cas, le Product Owner peut affiner bien mieux et plus rapidement selon les difficultés rencontrées par l’équipe. Si cette façon de faire est préférée, alors la phase au sein de la cérémonie peut être très courte.

Phase 2, centrée sur l’équipe (sprint retrospective)

Maître de cérémonie : Le Scrum Master

Durée : moins d’1 heure.

Cette phase permet de se concentrer sur la santé de l’équipe. Elle peut se faire sous forme de jeux. Elle permet de renforcer la cohésion de l’équipe et une amélioration continue.

Le but de cette phase est que l’équipe soit remotivée, que les difficultés de relations sociales entre les membres de l’équipe soient considérées et que l’environnement de travail soit amélioré.

Sources

L’expérience Limawi

My Agile Partner

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Apr 8, 2020 at 2:20am PDT

[limawifr]

Le Backlog et le Scrum Board

Le Backlog est la liste organisée de l’ensemble des histoires d’un projet.

Méthode agile : Présentation générale

Le Backlog rassemble l’ensemble des histoires d’un projet. Cette liste est généralement numérique mais peut être présentée sous forme de postits.

Cette liste est maintenue par le Product Owner avec l’aide du Scrum Master.

Chaque histoire, au sein du Backlog a un label décrivant sa structure (NFR, Story, Spike…) et des labels d’avancement et de portée. Tous les acteurs du projet peuvent ajouter des histoires au Backlog car il rassemble toutes les sources d’actions du projet (Bug Tracker, User Feedback, retour d’intégration continue, retour éventuel de logs, rapports d’erreurs, discussions entre acteurs…).

À chaque cérémonie, le Product Owner extrait du Backlog un certain nombre d’histoires et leur spécifie un label d’avancement. Ces histoires extraites forment un sous-Backlog intitulé Sprint Backlog. Le Backlog général, dans ce cas, porte le nom de Product Backlog. Notez qu’on peut hiérarchiser des Backlogs comme on le souhaite afin d’affiner au mieux et de garder de l’efficacité.

Toutes les histoires du Sprint Backlog doivent être estimées par l’équipe et le Poker agile.

Le label de portée peut être défini par n’importe quel acteur du projet qui suit la stratégie de management du projet (membres de l’équipe ou uniquement le Scrum Master par exemple). Il définit aussi un sous-Backlog et permet de faire fonctionner plusieurs équipes en parallèle ou de diriger les histoires vers les membres de l’équipe qui peuvent y répondre le mieux.

Exemples de labels

Labels d’avancement utilisés chez Limawi :

DISCUSSION : Cette histoire n’a pas encore été étudiée. C’est un nouveau retour d’une source, une nouvelle idée…

TODO : Cette histoire a été estimée et extraite du Backlog par le Product Owner pour le Sprint backlog en cours. Elle n’a pas encore été commencée par l’équipe.

DOING : Après TODO, une fois que l’équipe a commencé l’histoire.

REVIEW : Après DOING, une fois que l’équipe a estimé avoir fini l’histoire. Un membre de l’équipe qui n’a pas participé dans cette histoire ou un membre extérieur estime si le développement effectué correspond bien à l’histoire. Il y a souvent un va-et-vient entre DOING et REVIEW pour affiner la correspondance entre l’histoire et son développement.

DONE : Après REVIEW, une fois que la personne en charge de la revue a donné un feu vert. L’histoire est réalisée. La définition du DONE est importante et peut varier suivant les types d’histoires et la définition initiale donnée en cours de Sprint 0 ou de Discovery & Framing. C’est, en général, le Product Owner qui déplace en DONE.

POSTPONED : Cette histoire a été mal estimée ou un problème a été rencontré en cours de Sprint. Elle est renvoyée à un Sprint suivant.

Labels de portée :

SECURITY : Cette histoire a une notion de sécurité. Elle est traitée par les membres spécialisés en sécurité.

PERFORMANCE : Cette histoire a une notion de performance. Elle est traitée par les membres spécialisés en performances.

DOC : Cette histoire a une notion de documentation. Elle est traitée par les membres spécialisés en documentation.

TEST : Cette histoire a une notion de test. Elle est traitée par les membres spécialisés en test.

Scrum Board

Les histoires du Sprint Backlog peuvent être présentées sur un Scrum Board.

C’est un tableau à colonnes. Chaque colonne représente un label d’avancement. Les colonnes sont organisées de gauche à droite selon l’ordre logique des labels d’avancement.

L’idée est de faire avancer les histoires de la gauche (TODO) vers la droite (DONE). Une équipe agile efficace a toutes les histoires en DONE à la fin du Sprint.

Sources

L’expérience Limawi

Unow

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Apr 15, 2020 at 2:15am PDT

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Apr 15, 2020 at 2:17am PDT

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Apr 15, 2020 at 2:21am PDT

[limawifr]

Les rôles dans une équipe agile

Il y a deux rôles importants en méthode agile, le Product Owner et le Scrum Master.

Méthode agile : Présentation générale

Le Product Owner

Le Product Owner est le représentant des clients et de leurs désirs. Il a en charge le bon déroulement du développement du produit, le résultat du projet.

Il ne participe pas au développement et ne fait pas partie de l’équipe agile car il doit rester neutre par rapport à l’esprit d’équipe qui se forme.

Il a la charge de prioriser les tâches au cours des cérémonies afin de conserver les objectifs. C’est le principal mainteneur du Backlog et du Lean Canvas.

Il est souvent assisté du Scrum Master.

Il a la décision ultime et il est le seul qui peut déplacer une histoire en DONE (à l’exception éventuelle de bots spécifiques à des NFR répétitifs comme les mises à jour).

Il est l’interface entre l’équipe et les autres acteurs du projet et bien sûr, les clients.

Les Product Owners peuvent se hiérarchiser entre eux avec un Product Manager gérant l’ensemble des équipes agiles d’un projet et le Backlog général. Dans ce cas, le Product Owner d’une équipe ne gère que les histoires du Backlog avec les labels dévolus à cette équipe.

Le Scrum Master

Le Scrum Master a en charge la bonne santé de l’équipe. Il est là pour s’assurer que l’équipe suit toujours la méthode agile « Scrum » et ses bonnes pratiques.

Au début, il anime les réunions quotidiennes « Scrum » de l’équipe.

Il est au service de l’équipe et fait en sorte qu’elle se sente bien et reste efficace. Il cherche à lever les obstacles rencontrées par celle-ci.

Il veille à ce que l’équipe gagne en autonomie. C’est lui qui insuffle des pratiques nouvelles, si nécessaire, en accord avec le Product Owner.

Il n’est en aucun cas une sorte de chef d’équipe.

Des types d’équipe agile

Une équipe agile est constituée au maximum de 7 personnes. Au delà, l’efficacité de l’équipe diminue rapidement.

L’environnement des ces équipes sera plus détaillé dans un futur dossier. Mais voici un avant-goût.

MarketOps

L’équipe de marketing opérationnelle a la faculté de déterminer des stratégies marketing de court terme et de les mettre en place rapidement.

DevSecOps

Hérité du DevOps. Cette équipe développe, met en production (opérationnel) et sécurise ses développements.

Elle peut être parfois scindée en 2, une équipe étant dédiée à la réalisation des tests dans l’optique de diminuer les biais humains dus au fonctionnement en équipe.

Blue Team / Red Team

Pour des projets avec plus de moyens, on peut dédier deux équipes à la sécurité du projet (informatique ou autre).

La Red Team représente l’agression, l’attaque. Elle a pour charge de penser comme un agresseur éventuel et de chercher toutes les failles du projet pour le mettre à mal.

La Blue Team représente la défense. Elle doit défendre le projet des agressions et mettre en place les outils pour y parvenir.

Cette façon de faire permet de prévenir plutôt que guérir.

Les Sprints de ces équipes peuvent être organisés autour d’objectifs :

Le CTF (Capture the Flag) consiste à récupérer une information au sein du système pour la Red Team et à l’empêcher pour la Blue Team ;

L’arène de destruction consiste à détruire des portions du système pour la Red Team et à l’empêcher pour la Blue Team ;

« Vous ne passerez pas ! » consiste à fermer des accès au système pour la Red Team et à les maintenir ouverts pour la Blue Team (utile pour les DDOS en informatique) ;

Sources

L’expérience Limawi

Scaled Agile Framework

Savoir Agile

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Apr 22, 2020 at 1:20am PDT

[limawifr]

Méthode agile : Les histoires

Méthode agile : Présentation générale

Il y a plusieurs types d’histoires mais elles ont en commun d’avoir un objectif, de pouvoir être estimées (ou décomposée en éléments estimables) et d’avoir une définition du « DONE » claire (une fin claire).

Ces unités permettent de décomposer un projet clairement afin de pouvoir être réalisé de la façon la plus efficace possible.

Voici un panel (non exhaustif) des différents types d’histoire

Tâche : Pas vraiment une histoire en tant que telle mais c’est l’unité atomique sur laquelle une histoire est construite. Elle doit être la plus simple possible. Par exemple, si l’histoire consiste à « rentrer dans une maison », la tâche est « poser la main sur la poignée de porte », la tâche suivante « tourner la poignée », etc.

Story : C’est le type d’histoire le plus connu en méthode agile. Elle est centrée sur l’interaction avec l’utilisateur final. Pour ne pas confondre histoire et Story en anglais, le terme « User Story » est préféré. Elle permet de réaliser une fonctionnalité.

NFR : C’est le type d’histoire le plus dur à définir. NFR veut dire « Non functional requirements« . Ce sont toutes les actions nécessaires à la bonne marche du projet mais qui n’affectent pas l’interaction de l’utilisateur final avec le projet. Par exemple, une refactorisation de code, un changement de licence, la mise en place d’un nouveau serveur de développement ou d’une machine à café pour l’équipe.

Spike : Cette histoire permet de formaliser les étapes de recherche. Elle a une définition du DONE différente des autres car le principe de la recherche est qu’on ne sait pas ce qu’on va trouver.

Epic : Cette définition varie suivant qui l’utilise. Généralement, elle définit une histoire dont l’estimation dépasse la possibilité d’un Sprint. Elle doit donc être découpée en histoires plus petites.

Initiative : Utilisée par JIRA. Elle regroupe un ensemble d’Epics qui sont liées par un but commun.

Thème : Cette histoire regroupe des Epics ou initiatives dont l’ensemble une fois fini forme un changement majeur pour une large portion de l’organisation (ou entreprise).

Saga : Ce terme est peu utilisé (mais je l’aime bien) et peut se confondre avec le thème ou l’initiative. Il donne une note plus dans la continuité du terme « épique ». Il peut permettre de définir la racine du projet, de l’arbre des histoires. Du coup, je propose « Yggdrasil » pour nommer l’arbre des histoires, pour rester consistant dans les termes.

Début et fin d’histoire

Chaque histoire doit avoir une définition claire du READY (ou TODO) et le plus souvent du DONE.

C’est à dire que le Product Owner et l’équipe agile doivent s’accorder sur les prérequis nécessaires au démarrage de l’histoire (le READY). Pour le DONE, ils doivent définir le cahier des charges qui permet de s’assurer qu’une histoire est réellement finie. À noter que des histoires comme l’epic, le thème, l’initiative ou la saga n’ont pas de définition de DONE si ce n’est le DONE de toutes les histoires qui les composent.

Certaines histoires en détail

La User Story

L’histoire la plus connue de la méthode agile. Ce type d’histoires permet de créer de la valeur fonctionnelle pour l’utilisateur final.

Une définition du READY : Une story doit avoir un départ clair selon l’acronyme INVEST ci-dessous :

Independent : Chaque story doit être indépendante de tout autre tâche.

Negociable : Chaque story doit pouvoir être discutée pour décrire au mieux le parcours utilisateur qu’elle fournit :

Valuable : Chaque story doit effectivement apporter de la valeur au produit du point de vue de l’utilisateur final.

Estimable : Chaque story doit pouvoir être estimée en tant que nombre de points de complexité qui aboutissent à une estimation du temps.

Small : Chaque story doit être suffisamment petite pour pouvoir être réalisée par une ou peu de personnes dans un sprint.

Testable : Chaque story doit pouvoir être testée dans un outil de test en intégration continue.

Given a state (étant donné un état)

When an action (quand une action)

Then a result (alors un résultat)

Une définition du DONE : Une story doit avoir une fin claire définie à l’avance avec un certain nombre d’objectifs à définir.

Exemple de DONE :

Documentation générée

Tests fonctionnels passés

Tests de sécurité passés

Le NFR

Le NFR est un type d’histoire agile qui ne s’occupe pas de l’utilisateur final.

Le NFR signifie « Non functional requirements » (requis non fonctionnels).

Il permet de résoudre les tâches nécessaires au bon déroulement du projet mais qui n’ont aucune visibilité pour l’utilisateur final.

Exemple :

Questions légales

Questions de sécurité

Questions d’organisation

Questions de performances

Questions d’infrastructures

Un NFR a peu de différence avec la story à l’exception de l’aspect centré sur l’utilisateur final.

Un NFR doit être SMART  :

Specific : compréhensible par tous

Mesurable : avec un DONE (un objectif) clairement défini

Achievable : réalisable

Relevant : pertinente

Time-Boxed : court dans le temps et estimable en points de complexité

Il doit avoir une claire définition du READY et du DONE.

Le Spike

Quand on veut faire de la recherche en méthode agile, on utilise ça.

Le Spike (la pointe) cherche à préciser les étapes, savoirs et temps nécessaires pour résoudre les stories et NFR.

Il doit être indépendant et testable ; mais il est, par essence, non estimable. En effet, quand on cherche on ne sait pas ce qu’on va trouver donc impossible d’estimer.

Pour pallier à ce manque d’estimation, il est time-boxé (avec un temps défini).

Exemple : Rechercher un remplacement pour CouchDB en 24 heures (3 jours)

Un Spike doit être SMART :

Specific : compréhensible par tous

Mesurable : avec un DONE (un objectif) clairement défini

Achievable : réalisable

Relevant : pertinente

Time-Boxed : court dans le temps

Il doit avoir une claire définition du READY et du DONE.

Le DONE, dans ce cas, définit l’objectif, la direction de la recherche. Il permet d’estimer si la recherche est valable.

En effet, si l’objectif est de rechercher une nouvelle méthode pour faire une tarte à la framboise et que le résultat de recherche est un ensemble de méthodes pour créer ses croquettes pour chat, et bien ce n’est pas DONE.

Sources

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Mar 25, 2020 at 3:48am PDT

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Apr 1, 2020 at 2:53am PDT

[limawifr]

Méthode agile : Le Sprint et le Scrum

Méthode agile : Présentation générale

L’unité de temps de la méthode agile « Scrum » est le Sprint. C’est une période qui se répète. Elle peut varier suivant les équipes, de 2 semaines à 1 mois..

C’est au cours de cette période que sont réalisées les histoires.

Elle est encadrée par une cérémonie de début, qui prépare le travail, et une cérémonie de fin, qui fait un bilan du travail accompli.

Au matin de chaque jour de travail de cette période a lieu la réunion journalière (ou Scrum) qui permet de maintenir les objectifs du Sprint.

Les objectifs d’un Sprint sont simples, faire passer de TODO à DONE toutes les histoires qui ont été prévues pour celui-ci.

Cas particulier, le Sprint 0

Le Sprint 0 est le tout premier Sprint qui arrive juste après la phase de Discovery & Framing. Ce Sprint là sert surtout de phase de rodage pour l’équipe.

Elle découvre l’environnement de travail, le déroulement des réunions journalières, l’ensemble des acteurs du projet, etc…

Contrairement à ce qu’on peut lire dans diverses sources, je ne conseille pas de décrire le produit et sa cible dans ce Sprint, la phase de Discovery & Framing est plus adaptée pour ça.

Ce Sprint doit ressembler au maximum à un Sprint normal tout en se rappelant que l’équipe découvre le sujet.

Ce Sprint n’étant pas efficace pour le développement brut du projet, il est compté à part.

La mêlée (le Scrum)

Le Scrum (« mêlée » en français) est la réunion journalière qui a lieu tous les matins. Elle donne son nom à cette forme de méthode agile.

Cette réunion doit se faire debout (on l’appelle aussi « Stand-up meeting« ). Elle ne concerne que l’équipe de développement. Elle est animée (mais pas « dirigée ») par le Scrum Master.

Chaque membre de l’équipe doit pouvoir s’exprimer. Il détaille ce qu’il a fait la veille et ce qu’il compte faire aujourd’hui. Si des obstacles apparaissent, le Scrum Master peut décider soit de les résoudre immédiatement (s’ils sont rapides à régler) soit de planifier une discussion à un autre moment.

La réunion ne doit pas dépasser un quart d’heure. Elle doit se dérouler à la même heure et au même endroit tous les jours (généralement avec un « Scrum Board » sous les yeux).

Cette réunion est aussi un point de rencontre sociale entre les membres de l’équipe. Peu à peu, le Scrum Master doit pouvoir s’effacer au profit d’une prise en main de la réunion par l’équipe (toute l’équipe), renforçant un esprit d’équipe.

L’idée est que les membres de l’équipe aient un moment pour s’entraider et retrouver une vision globale du projet. Ce n’est pas un reporting (ça, ça s’automatise et c’est face à face avec le Scrum Master si nécessaire).

Les 3 questions à laquelle répond cette réunion sont (pour rappel) :

Qu’est ce qui a été fait hier ?

Qu’est ce que vous comptez faire aujourd’hui ?

Quels sont les obstacles rencontrés ?

La mêlée de mêlées

Si un projet nécessite plusieurs équipes agiles, on peut envisager une mêlée constituée d’un représentant de chaque équipe agile (pas le Scrum Master). Cette mêlée de représentants se déroule après la mêlée d’équipe.

Sources

L’expérience Limawi

Nutcache

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Mar 18, 2020 at 4:33am PDT

[limawifr]

Méthode agile : Présentation générale

La méthode agile est une méthode de management d’équipe de développement (mais peut être adaptée à d’autres secteurs comme le marketing) qui s’axe sur l’adaptabilité et la réactivité de l’équipe à la demande du client.

La méthode que nous utilisons est une dérivée de la méthode agile appelée « Scrum ». Cette méthode doit son nom aux réunions matinales de l’équipe comparées à une mêlée de rugby (« Scrum » signifie mêlée).

Comment ça marche ?

Concrètement, on détaille le projet en un ensemble de tâches (qu’on appelle histoires) et on étale ces histoires sur des périodes de temps qui se répètent (qu’on appelle « Sprint »).

L’idée est d’impliquer les clients du projet à intervalles réguliers en fonctionnant par itération.

Un Sprint passe, le client voit le travail accompli et décide de modifier des choses ou de continuer le projet, un autre Sprint se forme alors. Et ainsi de suite.

Une équipe agile comporte généralement moins de 7 personnes. Au-delà, l’équipe perd en efficacité.

Dans la série d’articles de ce dossier, vous verrez comment formaliser les histoires pour répondre aux besoins spécifiques du projet et du client et comment structurer vos Sprints pour les garder efficaces.

La méthode agile est souvent associée à des techniques DevOps (et DevSecOps, MarketOps…) dont nous parlerons dans un futur dossier.

On commence par quoi ?

Et bien, commençons par le début d’un projet, la phase de « Discovery & Framing » .

Puis, je vous invite à lire les articles sur les histoires, la Cérémonie, le Backlog, le Scrum et le Sprint pour avoir une vue d’ensemble de cette méthode.

View this post on Instagram

A post shared by Limawi français (@limawi.official.fr) on Mar 17, 2020 at 9:42am PDT

[limawifr]

Règles de signalement des failles de sécurité

Règles de signalement des failles de sécurité

Si vous pensez avoir trouvé une faille de sécurité sur Limawi ou sur un de nos services, nous vous invitons à nous contacter immédiatement. Si vous souhaitez nous contacter pour toute autre chose, veuillez utiliser notre email (présent sur la page originale). Merci.

Nous sommes engagés dans un partenariat constant avec la communauté pour procéder aux vérifications, reproduire, et bien réagir aux failles de sécurité fondées.

Nous encourageons vivement la communauté à participer à notre programme de signalement.

Si vous désirez signaler une faille de sécurité, vous pouvez nous contacter sur l’email du DPO (présent sur la page originale). Voici la clé PGP/GPG du DPO. Vous pouvez l’utiliser pour envoyer directement votre signalement par courriel. Merci d’indiquer votre nom, vos informations de contact ainsi que le nom de votre entreprise (le cas échéant), avec chaque signalement. Si vous utilisez la clé PGP/GPG du DPO, n’oubliez pas de fournir également votre clé publique PGP/GPG avec votre signalement, si vous en avez une.

Règles de divulgation responsable

Nous examinerons attentivement tous les signalements et ferons tous nos efforts pour corriger rapidement toute vulnérabilité. Pour encourager le signalement responsable, nous nous engageons à ne jamais intenter d’action judiciaire contre vous ou demander aux autorités une quelconque enquête vous concernant, si vous vous conformez entièrement aux règles de divulgation responsable suivantes :

Indiquer tous les détails de la faille signalée, y compris les informations nécessaires pour reproduire et mettre en évidence la faille et sa « démonstration d’existence » (« Proof of Concept (POC) » ;

Faire, de bonne foi, tous efforts pour éviter les violations de la vie privée, la destruction de données et l’interruption ou la dégradation de nos services ;

Ne pas modifier, supprimer ou accéder aux données qui ne vous appartiennent pas ;

Nous laisser un délai raisonnable pour corriger la difficulté avant de délivrer la moindre information publique.

Nous nous efforcerons de répondre à votre signalement dans le délai d’un ou deux jours ouvrables.

Article original.