View
182
Download
2
Category
Preview:
Citation preview
AGILE TOUR 2016Compte-Rendu
Freddie DEWALEYNEJean-Baptiste VIGNERON
Sommaire L’Agile Tour en quelques mots… Keynote : #NoEstimates 5 ans pour passer du Cycle en V aux Features Teams Où en est le contrat agile en 2016 ? Votre job sera remplacé par un indien ou un robot… Living Documentation Évitez la lassitude, créez vos propres formats de rétrospective Ce que la revue de code m’a apporté Mon processus de design en tant que PO sans UX designer J'anime une rétrospective productive L’agilité à 200 personnes
L’Agile Tour en quelques mots…Présentation Conférences, rencontres, ateliers et échanges autour des méthodes
agiles Evénement international, organisé dans plus de 80 villes dans le
monde Site officiel: http://www.agiletour.org
A Lille : Organisé par l’association Nord-Agile (http://www.nord-agile.org) 13 et 14 octobre 2016 à Euratechnologies de 8h30 à 17h Plus de 350 participants, 25 conférenciers
En France : 15 villes dont Paris, Aix-Marseille, Lyon, Sophia Antipolis,
Toulouse…
L’Agile TourPartenaires et sponsors lillois
Norsys
OCTO
OPEN
Proxiad
Zenika
AXA
Capgemini
Davidson Consulting
Décathlon
EFIDEV
Nordnet
KeyNoteMouvement #NoEstimates Stoppez les estimations
Utilisez les « story points » (1 / 3 / 5… ou S / M / L…) pour estimer les users stories Ne montez pas trop dans les « story points » (sinon découpez les stories)
Utilisez les métriques pour estimer le coût réel d’une fiche Se baser sur les métriques projets pour connaître votre vélocité (cycle time, etc.) Plutôt que de ramener les story points à des jours hommes Une fiche estimée « M » ne prend pas le même temps de réalisation selon le projet
Quand la story est trop grosse Ne pas hésiter à la découper Décider la partie à traiter aujourd’hui et celle qu’on fera demain
La compréhension du besoin sera plus claire après la première livraison La boucle de feedback est réduite
5 ans pour passer du Cycle en V aux Features TeamsAXA DSI AXA France : 2000 personnes, divisés en départements
2011 : Passage à Scrum 2013 : Passage à Kanban 2016 : Passage aux Features Teams
Nouvelle organisation : Tribus (Département)
Domaines (fonctionnel couvrant plusieurs produits) Squads (Product Owner + Scrum Master + développeurs + testeurs)
Equipes multi-transverses Chapters: communauté de pratiques transverses aux domaines par rôle (PO / SM / Dev…) Guildes: communauté de pratiques transverses (Archi, Sécurité, Tests, Dev, UX/UI…)
Equipes: co-localisées, compétentes et auto-organisées
5 ans pour passer du Cycle en V aux Features TeamsAXA Indicateurs de mesures :
OnTime / OnScope / OnBudget Le turnover / La qualité (de code, de tests) / La maturité au niveau des features
teams
Réorganisations au niveau : Localisation Outils Organisation avec les prestataires
Impacts au niveau communication, formations et recrutement (vu que les rôles ont changé)
Succès projet = satisfaction Client + satisfaction Equipe
Les contrats de prestations en informatique aujourd’hui en France Forfait (eng: « Fixed-price contract »)
3 CONTRAINTES : Périmètre (Scope) + Coût + Prix Les risques sont intégralement du côté FOURNISSEUR
Régie (eng: « Time and Materials ») 1 CONTRAINTE : Coût Les risques sont intégralement du côté CLIENT
http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile
Où en est le contrat agile en 2016 ?Zenika
Où en est le contrat agile en 2016 ?Zenika
Idée Créer un contrat agile Equilibrer les risques entre le client et le fournisseur
Engagement fort Pénalités partagées
Clauses miroirs (qu’on peut lire dans les deux sens, en inversant les termes « client » et « fournisseur »)
Lister ce qui est prévu en cas de défaillance Moins de spécifications écrites (par rapport au forfait, vu qu’on est en mode
agile)
http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile
Où en est le contrat agile en 2016 ?Zenika
Article 1 : Déclaration d’intention Coût fixé, Temps fixé Mais il est noté que le scope peut changer en cours de route, ou que le
fournisseur ait mal estimé la charge…
Article 2 : Engagements pour… Le client de fournir un PO qui connaît l’agilité et respecte les pratiques Le fournisseur de fournir une « force de frappe » avec la manière de
procéder détaillée On détaille alors le fonctionnement de la méthodo utilisée (Scrum, backlog,
sprints de 2 semaines, daily meetings, livraisons continues etc.)
http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile
Où en est le contrat agile en 2016 ?Zenika
Article 3 : Si le client veut modifier le scope On casse le sprint Les réalisations en cours ou déjà effectuées sont facturées en Régie
Article 4 : Facturation Imposer une partie fixe et une partie variable dans le tarif journalier La partie variable est facturée selon l’estimation faite et les réalisations
effectuées Si les réalisations sont terminées avant ou à temps, le client paie les 2 parties Si les réalisations prennent plus de temps, seule la partie fixe est facturée pour
les jours « en trop »
http://www.slideshare.net/Zenika/agile-wake-up-3-la-contractualisation-agile
Votre job sera remplacé par un indien ou un robotIsmael Hery La machine a dépassé l’homme dans certains domaines, et
cela ne devrait pas s’arrêter 1997 : La machine « Deep Blue » d’IBM bat Kasparov aux échecs 2014 : un ordinateur réussit le test de Turing
Ce qui attend les hommes… Chômage La multiplication des « bullshit jobs »
Des jobs aux responsabilités limitées Des jobs aux sens minimalistes
Votre job sera remplacé par un indien ou un robotIsmael Hery Ce que les robots ne font pas encore :
Créativité, Intuition Relationnel, Empathie, Communication Leadership Piloter d’autres machines ou des outils complexes Créer du « beau » et du « bon »
Machine > Homme mais… (Machine + Homme) > Machine seule Certains jobs ne sont pas prêts d’être remplacés par une machine
Les jobs où l’expérience client est meilleure avec un humain (ex: la cuisine)
Les jobs avec un très haut niveau d’expertise technologique
Votre job sera remplacé par un indien ou un robotIsmael Hery Le chemin pour ne pas atteindre le « bullshit job »
Focalisez-vous sur ce que les robots ne savent pas (bien) faire Produisez au niveau des meilleurs Apprenez en permanence, restez débutant
Qu’est-ce que j’ai appris ces six derniers mois ? Qu’est-ce que je peux apprendre dans les six prochains mois ?
Produisez au niveau des meilleurs Valeur économique Qualité Apprenez à créer aussi vite que les meilleurs
Living DocumentationArolla Documentation
Passer/Transmettre du savoir Trier les informations accessibles et utiles pour des personnes techniques et non
techniques
Meilleurs moyens pour transmettre du savoir Conversations Mob-programming (programmation en groupe) Pair-programming
La documentation est importante… Mais elle prend du temps et peut sembler contraignante à rédiger… Il ne faut pas mélanger la doc « toujours vraie » (def générales, doc d’installation…)
de celle pouvant changer dans le temps (doc technique, doc fonctionnelle…)
Living DocumentationArolla Il est possible de générer de la doc à partir du code (Le code EST la
documentation) En méthodo BDD, les scénarios peuvent être générés dans un format pour les utilisateurs et/ou le
métier Pickles, outil de génération pour Specflow / Cucumber à partir des scénarios (HTML / DOC / PDF…)
http://www.picklesdoc.com https://cucumber.io / http://www.specflow.org
Génération de diagrammes d’architecture depuis le code Découpez votre architecture par domaine fonctionnel (« Domain Driven Design ») et non plus
seulement par couche technique (3 tiers, MVC…) Les namespaces / packages et les classes deviennent de la doc (et aussi avec l’aide des
commentaires JavaDoc, balises XML C#...) Utilisation des « bounded context » (http://martinfowler.com/bliki/BoundedContext.html)
Le fonctionnel devient lisible et compréhensible à l’aider des diagrammes générés à partir du code
Évitez la lassitude, créez vos propres formats de rétrospectiveOCTO Une bonne retrospective est dynamique, fraîche et motivante
Le site “retromat" (http://plans-for-retrospectives.com) est une mine d’or, il permet de construire les retrospective en suivant 5 étapes : ouvrir la rétrospective, permettant de briser la glace et d’amorcer une
rétrospective dynamique récupérer les données, afin de récupérer les retours de chaque générer des idées, propositions d’amélioration décider des actions, engagement clore la rétrospective
Terminer positivement afin d’avoir toute la motivation nécessaire pour le prochain Sprint ! :-)
Évitez la lassitude, créez vos propres formats de rétrospectiveOCTO Quelques feedbacks de de Scrum Master :
utiliser des outils de chat tels que Slack irc-like permettant d’avoir des discussions dans des chatrooms : autour de projets, technologies, problématiques particulières.
utiliser des outils permettant de suivre les tâches d’un projet et de suivre les indicateurs générés automatiquement (suite Atlassian : Jira, Confluence …, Pivotal Tracker, Trello, Redmine …)
utiliser des outils de collaboration en ligne afin de travailler avec des équipes partagées (pluri-site, télétravail …) :
Padlet (https://fr.padlet.com/features) Google Hangout https://www.retrium.com Deekit (tableau blanc collaboratif https://www.deekit.com
organiser des événements en dehors du lieu de travail, particulièrement en début de projet : escape games … afin de créer au plus tôt un esprit d’équipe et booster la motivation
Ce que la revue de code m’a apportéAXA https://blog.axawebcenter.fr/methodologie/ce-que-la-revue-de-code-ma-apporte/
« Egoless programming » Présenter son code aux autres peut faire peur… On juge le CODE, et non la personne qui l’a écrit Principe respecté: « Dur avec le code, doux avec les gens »
Pour que la revue de code se passe bien Définissez des rôles : les lecteurs, le modérateur, le scribe et le time-keeper (gardien du temps) 1 minute maxi par point relevé Quand une discussion vient à s’éterniser…
Le time-keeper annonce que cela fait une minute que l’on parle du même sujet Le modérateur décide de continuer la conversation, de conclure, ou de réorganiser un point dédié plus tard
Unité de mesure pour une code review : Nombre de WTF / minutes
Mon processus de design en tant que PO sans UX designerOCTO UX Design : Pratique / méthodo pour apporter une réponse à un besoin donné
dans un contexte donné
Comment introduire les pratiques UX sans perdre en efficacité ? Rencontrer et échanger avec les utilisateurs
Un CP marketing Le client Vous Votre équipe Aucun d’entre eux n’est votre UTILISATEUR
Comment faire quand vous ne pouvez pas (officiellement) rencontrer les utilisateurs
Niveau 0 : Soyez « opportuniste » (mode pirate) Quand vous obtenez le nom d’un utilisateur, contactez-le
Niveau 1 : Rendez-vous réguliers Niveau 2 : Ritualiser (30min / 1h par semaine)
Mon processus de design en tant que PO sans UX designerOCTO Rencontrer les utilisateurs n’est pas une option / un privilège, c’est le métier du PO Designez le parcours avant de faire des maquettes N’hésitez pas à copier les autres
Reprendre les standards existants, intégrer des patterns auxquels l’utilisateur est déjà habitué Ex: Recherche LinkedIn, album photo Facebook, paniers Amazon / Fnac etc
Prototypez rapidement pour apprendre rapidement Construisez et documentez les patterns utilisés
Faire un émerger un toolkit standard à la société (ex: Bootstrap, Materials…) Montrez les maquettes aux utilisateurs au plus tôt (pour les feedbacks) Tout outil de design convient : stylo / papier, Powerpoint, Balsamiq… Résultats :
Utilisateurs qualitativement plus satisfaits Satisfaction de co-créer Meilleure vision de la « roadmap » pour les utilisateurs Moins de corrections / évolutions post-MEP Du temps gagné pour les équipes
J'anime une rétrospective productiveCGI Exercice régulier
Enoncer les Forces et les faiblesses Identifier des actions d’amélioration
Définir le cadre de sécurité Zone de sécurité
Rien ne sortira de la salle Pas de compte-rendu, mais un plan d’actions qui sort
Transparence Bienveillance
On se rend bien compte qu’il y a un soucis, mais on veut le résoudre
J'anime une rétrospective productiveCGI Déroulé type
« Ice-breaker » pour bien commencer (pour libérer l’esprit, destresser) Récupérer les données
Serious Game +/- Etoile de mer (Moins de…, Plus de…, A continuer, A améliorer, A arrêter)
https://leblogdumanagementdeprojet.com/2015/09/28/adoptez-une-etoile-de-mer-pour-des-retrospectives-agile-plus-amusantes-et-plus-productives/
4L (Like, Learn, Long for, Laked)https://agilamat.wordpress.com/2012/10/29/la-retrospective-4l
SWOT (Forces / Faiblesses / Opportunités / Menaces)http://agilelucero.com/agile/swot-retrospective/
Speedboathttp://coach-agile.com/speed-boat
Jouez avec la créativité Jouez avec les émotions
J'anime une rétrospective productiveCGI Autres formats
Rétrospective CNV (communication non violente) http://fr.slideshare.net/patriceboisieau/usages-de-la-cnv-en-agilit-25720840
Ce que j’observe (ex: la build est KO)
Ce que je ressens (ex: l’équipe n’est pas assez attentive)
Ce que je veux (ex: soyons plus attentifs)
Ce que je demande (faisons des revues de code pour éviter que celà ne se reproduise)
Méthode des « six chapeaux » https://fr.wikipedia.org/wiki/M%C3%A9thode_des_six_chapeaux Bleu : Organisation Blanc : Neutralité Noir : Pessimisme Jaune : Créativité Vert: Optimisme Rouge: Emotions
J'anime une rétrospective productiveCGI Sinon… jouez autrement !
Jeopardy : on part de la réponse et les personnes expriment la question
Bien choisir et maîtriser son activité Regrouper les idées Donner la priorité Trouver les actions
ROTI sur la rétrospective (une note de 1 – j’ai perdu mon temps à 5 – très efficace)
J'anime une rétrospective productiveCGI Participer ou animer ?
Il vaut mieux choisir, plutôt que de faire les deux Le mieux est de prendre un animateur externe
Si ce n’est pas possible Faîtes dire votre avis par quelqu’un d’autre Jouez avec des casquettes : une animateur et une participant
L’animateur… A une écoute active Gère la discussion et répartit la parole Gère les conflits (l’animateur n’est pas un sauveur, mais un facilitateur)
Quand c’est à distance Utilisez un tableau blanc Ayez un animateur de chaque côté Privilégiez la visio-conférence plutôt que le téléphone
L’agilité à 200 personnesDécathon Programme « CUBE » Seamless Expérience (expérience homogène)
Proposer la même expérience quel que soit le canal (Web, Mobile, magasin…)
Stratégie par feature et non plus par canal Search & Choose / Buy / Get / Connect-Interact Services /UI/UX
Au début… Features Teams orientées métier
Nouveaux silots avec obligation de résultats
Sprints de 3 semaines Cycles en V cachés
L’agilité à 200 personnesDécathon Etapes réalisées
Rendre les choses visibles Création d’une « Oobeya Room »
Tableaux visuels visibles de tous Backlogs des équipes Releases Pilotage Informations Transformation
Rituels Daily Scrum Daily Nexus (entre scrum masters à 11h) Démos communes Le planning est figé pour tout le monde
Les sprints commencent et finissent en même temps
NEXUS
FEATURESCRU
MTEAM
SCRUM
TEAM
Recommended