Limawi - Feed https://blog.limawi.io/fr Fri, 09 Oct 2020 10:20:21 +0000 fr Chef Progress et Inspec https://blog.limawi.io/fr/chef-progress-et-inspec/ Fri, 09 Oct 2020 10:20:21 +0000 Michée Lengronne urn:uuid:421f2849-689e-44bb-947e-b481e42603fc Histoire

Chef a été racheté par Progress. Des vagues de licenciement ont lieu en ce moment chez Chef.

Chef publie des solutions de déploiement et tests d’infrastructure, dont Inspec, une solution de test système.

Chez Coppint, nous utilisons Inspec en version opensource pour tester l’état de nos systèmes.

Il y a un an, Chef a rendu ses binaires compilés propriétaires à partir du code source resté opensource. Pour ne pas être rendu dépendant de cette nouvelle licence, nous avons décidé de compiler notre propre Inspec.

Puis, nous avons migré vers cinc-auditor il y a quelques temps. Cinc-auditor est une compilation faite à partir du code source mais avec une licence opensource.

Pour l’instant cette solution dépend du code source d’Inspec. Ce n’est pas un fork.

Nous suivons donc de près cette affaire.

N’hésitez pas à suivre cinc sur Twitter.

Sources

]]>
Infos
Hacktoberfest/Shitoberfest https://blog.limawi.io/fr/hacktoberfest-shitoberfest/ Fri, 09 Oct 2020 10:10:43 +0000 Michée Lengronne urn:uuid:e8304835-0c9b-4599-926f-2b4e24e5004e Histoire

Mise en place par DigitalOcean, il y a 7 ans.

Les participants gagnent un T-shirt s’ils ont 4 PR(«push request») réussies sur le mois d’octobre au sein de projets opensource hébergés sur Github.

Cette année, le challenge a dérapé (plus que les années précédentes). Un youtubeur, qui dispose d’ une large communauté, a montré comment gagner un T-shirt en employant une technique s’apparentant à du spam.Le tout ressemblant à de l’attaque DDOS sur les projets visés. Les mainteneurs ont été débordés de requête d’ajout de code sans intérêt. Les infrastructures de test ont fait tourner des instances inutilement.

DigitalOcean a décidé d’y remédier en ne validant que les PR sur projet ayant opt-in (en mettant le label Hacktoberfest sur le repo Github.). Github a créé la faculté d’interdire les PR provenant de comptes créés trop récemment.

Les spammers ont alors imaginé une solution. Ils ont créé des repos Github opensource automatiquement et ont créé des PR dedans qu’ils validaient eux-mêmes.

Nous sommes le 8 octobre et comme son nom l’indique cela va continuer tous le mois. D’autres surprises ne manqueront pas de venir.

N’hésitez pas à suivre le compte shitoberfest sur Twitter pour vous délecter des perles de code pourri et pleurer avec les mainteneurs.

Sources

]]>
Méthode agile : Présentation générale https://blog.limawi.io/fr/methode-agile-presentation-generale/ Mon, 16 Mar 2020 15:13:42 +0000 Michée Lengronne urn:uuid:4938ec01-7b76-4c04-8f3c-4cd97f53fca0

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.

Ensuite, n’hésitez pas à explorer, les hyperliens ça sert à ça.

]]>
Infos Tutoriels
Les rôles dans une équipe agile https://blog.limawi.io/fr/les-roles-dans-une-equipe-agile/ Mon, 16 Mar 2020 15:13:28 +0000 Michée Lengronne urn:uuid:48109775-a09a-468f-91c0-896c1fecb14b

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

]]>
Infos Tutoriels
Le Backlog et le Scrum Board https://blog.limawi.io/fr/le-backlog-et-le-scrum-board/ Mon, 16 Mar 2020 15:13:14 +0000 Michée Lengronne urn:uuid:61ad2aef-c24d-46a2-b096-a19555c079f4

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
]]>
Infos Tutoriels
Méthode agile : La cérémonie https://blog.limawi.io/fr/methode-agile-la-ceremonie/ Mon, 16 Mar 2020 15:13:00 +0000 Michée Lengronne urn:uuid:5c0814b5-a226-4558-9bb2-65baf03f2119

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

]]>
Infos Tutoriels
Discovery & Framing https://blog.limawi.io/fr/discovery-framing/ Mon, 16 Mar 2020 15:12:47 +0000 Michée Lengronne urn:uuid:c27f0875-4e79-4140-a707-0a97cabe622d

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

]]>
Infos Tutoriels
Méthode agile : Les histoires https://blog.limawi.io/fr/methode-agile-les-histoires/ Mon, 16 Mar 2020 15:12:35 +0000 Michée Lengronne urn:uuid:a4a39b38-0fb6-498c-99dd-45c172eddaf8

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 :
    • Given a state (étant donné un état)
    • When an action (quand une action)
    • Then a result (alors un résultat)
  • 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.

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

]]>
Infos Tutoriels
Elevation of Privilege https://blog.limawi.io/fr/elevation-of-privilege/ Mon, 16 Mar 2020 15:12:08 +0000 Michée Lengronne urn:uuid:ad3a00c9-e407-4287-9e66-eaefb88c4c71

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

]]>
Infos Tutoriels
Le lean canvas https://blog.limawi.io/fr/le-lean-canvas/ Mon, 16 Mar 2020 15:11:53 +0000 Michée Lengronne urn:uuid:3d761a67-9451-419c-8a52-3ffe03e33f1f

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

]]>
Infos Tutoriels