...et Scrum
Contractualisation via : un Cahier des Charges
le client rédige un cahier des charges décrivant TOUT
l'équipe s'isole pendant des mois pour déchiffrer le CdC et produire ce qu'ils ont compris
le client réceptionne le produit et s'étonne de la non conformité de ses attentes
plus on attend pour trouver un problème, plus il est onéreux de le corriger...
(Réalisée en 1994, puis renouvelée en 2008)
speed up !
slow down !
ok for me.
courant
paradigme
état d'esprit
philosophie
mouvement
culture
1986 : première tentative de réalisation itérative
1993 : première mise en oeuvre de Scrum
2000 : eXtreme Programming : l'agilité pour le développement
2001 : naissance du Manifeste Agile, et du terme Agile
2010 : Devops : dépasse les frontières du développement
Scrum, eXtreme Programming, Kanban, FDD, RAD, Crystal Clear...
le produit ne s'arrête pas à la fin d'un projet
réaliser un projet : quid de la remise en question de celui-ci ? les fameux 80% / 20% qui coûtent 20% / 80%
réaliser le bon produit
accomplir une liste de tâches
Suppression/réduction de "l'effet Tunnel" :
- donner de la visibilité
- impliquer le client du début à la fin du projet
Approche prédictive (cycle en V) : spécifier et planifier dans les détails l’intégralité d’un produit avant de le développer
Oubliez le Cahier des Charges :
- l'approche prédictive est contre productive
temps perdu à tout spécifier : obsolescence du CdC
prendre les (bonnes) décisions au plus tard
- un besoin ne peut pas être figé
s'adapter au changement (en le régulant)
survivre aux imprévus... qui n'existent plus !
Nous découvrons comment mieux développer des logiciels
par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :
Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments,
mais privilégions les premiers.
12 principes sous-jacents
Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
Un logiciel opérationnel est la principale mesure d’avancement.
La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.
La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
portion de temps courte (< 4 semaines)
L'activité de réalisation inclut des travaux de conception, de spécification fonctionnelle/technique si nécessaire, de développement et de test, voire plus...
le client final peut rapidement émettre des feedback qui pourraient se révéler cruciaux pour la suite
cette transparence soude la relation entre l'équipe et le client qui connait et comprend les complexités rencontrées.
Détection / levée des risques très tôt
responsabilisation et implication de l'équipe et du client pour "bien" réaliser le "bon" produit
speed up !
slow down !
ok for me.
Product Owner
Scrum Master
Sprint
Sprint Planning
User Story
Story Points
Product Backlog
Daily Scrum meeting
Démo
Retrospective
porte la vision du produit, représente le client
est garant de l'application de la méthodologie
conçoit le produit : elle est habilitée par l'organisation pour gérer sa manière de travailler, est auto-organisée, pluridisciplinaire, personne n'est dédié à un domaine particulier.
Les personnes impactées par le produit.
prescrites pour pousser l'inspection et l'adaptation
prescrites pour pousser l'inspection et l'adaptation
lister ce qui a été terminé ou pas
expliquer les problèmes rencontrés
démontrer les fonctionnalités terminées
le PO discute de sa vision produit, des MAJ de jalons/dates...
discuter les prochains items qui pourront être faits
dans la suite : US = User Story
l'équipe "raffine" le Product Backlog :
suppression d'US plus pertinentes
ajustement de la priorité des US
correction de la complexité de certaines US
estimation de la complexité des US "prêtes"
création de nouvelles US liées à de nouveaux besoins
split / merge d'US en fonction des besoins (INVEST)
le PO transmet à l'équipe de réalisation la connaissance métier, et par là même, sa vision produit.
et autres définitions...
User Story : l'élément de base de construction d'un produit. Décrit une fonctionnalité, son contexte, ses adhérences etc... Elle est le langage commun entre toutes les parties en rapport avec le produit.
Story Point : unité de coût des US : quantifie leur complexité, ou mieux, leur effort. Souligne le fait qu’il ne s’agit que d’une estimation (par définition fausse) et non pas un chiffrage.
Poker Planning : une méthode d'estimation des US en SP.
Product Backlog : liste des exigences et fonctionnalités éventuelles du produit. Se matérialise sous la forme d'une liste d'US, d'Epic etc...
Sprint Backlog : périmètre du Sprint sur lequel s'est engagée l'équipe de réalisation
de 2 à 4 semaines
PDCA de 24h + PDCA de 2/4 semaines
les spécifications fonctionnelles de l'agilité
Independent : The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable : User stories, up until they are part of an iteration, can always be changed and rewritten.
Valuable : A user story must deliver value to the end user.
Estimable : You must always be able to estimate the size of a user story.
Sized appropriately or Small : User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
Testable : The user story or its related description must provide the necessary information to make test development possible.
Ce n'est pas travailler "à l'arrache". Scrum ne pose que quelques règles de base, mais qui doivent être appliquées avec discipline et rigueur.
Ce n'est pas entamer de la réalisation sans avoir spécifié. Tout comme dans les anciennes méthodes il est indispensable de spécifier, mais au fur et a mesure.
Ce n'est pas une excuse pour ne pas écrire de documentation. Mais au contraire se focaliser sur les documentations vraiment pertinentes.
speed up !
slow down !
ok for me.
écrites par le PO
IN ORDER TO souscrire une offre
AS utilisateur web (Utilisateurs autorisés à réaliser cet acte)
I WANT TO voir la liste des offres auxquelles je suis éligible
à l'aide de scénarios avec le formalisme BDD :
GIVEN je suis sur l'interface d'inscription
AND je me suis authentifié
WHEN je clique sur « Voir les offres »
THEN j'ai accès à la liste des offres auxquelles je suis éligible
ou comment maturer vos US
cf blog de Claude Aubry
A faire | En cours | Fait | Clos
Organisation classique du board de travail :
A faire | En cours | A valider| Validé
ou :
empruntée à l'eXtreme Programming
Enquête Standish Group :
https://cs.nmt.edu/~cs328/reading/Standish.pdf
Introduction au Méthodes agiles et Scrum :
http://www.agiliste.fr/fiches/introduction-methodes-agiles/
Manifeste Agile :
http://agilemanifesto.org/iso/fr/ (et les 12 principes agiles)
Guide Scrum :
https://www.scrum.org/Portals/0/Documents/Scrum...FR.pdf
Gartner 2012 :
https://www.gartner.com/doc/1837016
Claude Aubry et les Bacs :
http://www.aubryconseil.com/post/Passer-des-colonnes-aux-bacs
Blog Novédia et l'écriture des US :