View
1.719
Download
5
Category
Preview:
Citation preview
Les méthodes agilesIntroduction à SCRUM
Blackbird est une agence de développement web spécialisée dans l’accompagnement et le développement de projets e-commerce sur la solution Magento.
http://black.bird.eu
About
Sommaire
● Introduction● Les principes fondamentaux● Présentation des Users Stories● 6 stratégies pour rédiger des US efficaces● Évaluer la taille des Users Stories● Prioriser les Users Stories● Plannifier les Sprints● Les cérémonies : des outils pour communiquer● Mesurer la vélocité de la production● Déroulement d’un sprint● Les signaux d’alertes, savoir interpréter le tableau de sprint● Traiter plusieurs projets en simultané● Aspects contractuels● Concepts et ressources pour aller plus loin
1980 1990 2000 2010
Gantt / PERT : Cascade ( Waterfall, V Model, etc.)
Méthodes Agiles
Origines des méthodes Agiles
19501900
Taylorisme
Lean
Toyota Production
System
Process focus
Peoplefocus
Des outils plus ou moins normatifsRUP XP SCRUM KANBAN Faites ce que
vous voulez
120+ 13 9 3 0plus
nor
mat
if plus adaptatif
RUP est assez normatif - avec plus de 30 rôles, plus de 20 activités et plus de 70 artefacts; une énorme quantité de choses à apprendre.
XP (eXtreme Programming) inclut une majorité des règles de Scrum plus un ensemble de pratiques d'ingénierie bien spécifiques comme le développement piloté par les tests et la programmation en binôme.
Scrum est moins normatif que XP puisqu'il ne recommande aucune pratique d'ingénierie particulière. Scrum est plus normatif que Kanban cependant, car il impose des choses comme les itérations et les équipes multidisciplinaires.
Kanban laisse tout ouvert. Les seules contraintes sont de Visualiser Votre Workflow et de Limiter Votre TAF. Tout près du "Faire N'importe Quoi", mais étonnamment puissant.
source : http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/
Les principales différences entre cycle en V et méthodes agiles
Personnes et interactions
Logiciel qui fonctionne
Collaboration avec le client
Adaptation au changement
Processus et outils
Documentation
Négociation sur le contrat
Suivi d’un plan pré-établi
vs
vs
vs
vs
Agile Cycle V
Le paradoxe de la gestion de projet
Capacité d’action
Temps
Connaissance du projet
Pourquoi ? ● Faciliter l’expression des besoins
● Aider à l’acceptation du changement
Comment ? ● Organiser l’expression des besoins
● Intégrer le client
● Démarche itérative
Le modèle Agile
Quels projets
favoriser ?
● Besoin rapide de mise à disposition du produit
● Imprévisibilité des besoins du client
● Nécessité de changements fréquents
● Besoin de visibilité du client sur l'avancement
des développements
● Présence de l'utilisateur assurant un feedback
immédiat
● Indisponibilité du client ou de l'utilisateur
● Dispersion géographique des ressources
humaines
● Inertie des acteurs du projet ou refus des
changements
● Gouvernance complexe de la DSI
Quels projets éviter ?
Les principes fondamentaux
Les 4 valeurs fondamentales
L'équipe « Les individus et leurs interactions, plus que
les processus et les outils »
L'application « Des logiciels opérationnels, plus qu'une
documentation exhaustive »
L'acceptation du changement« L'adaptation au changement, plus que le
suivi d'un plan »
La collaboration « La collaboration avec les clients, plus que la
négociation contractuelle »
source : Wikipedia
Les 12 principes généraux
User Focus
1. La plus haute priorité est de satisfaire le client (l’utilisateur final du produit) en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée.
source : Wikipedia
Un modèle itératif
2. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte.
3. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées).
4. Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage concurrentiel pour le client
source : Wikipedia
Un modèle Collaboratif
5. Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
6. Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet.
7. La méthode la plus efficace pour transmettre l'information est une conversation en face à face.
8. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence.
source : Wikipedia
Focus on quality
9. Les processus agiles promeuvent un rythme de développement soutenable
10. Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la conception.
11. La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels.
12. Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions.
source : Wikipedia
Structure opérationnelle et pratique du développement agile
… là on parle de SCRUM
Les rôles
Product Owner Scrum Master Team
Démarche itérative
Produit
Release 1 Release 2
Sprint 1 Sprint 2 Sprint 3
Story
Story
Story
Itérations Release
Chaque fin de release apporte de nouvelles fonctionnalités pour les utilisateurs
ROADMAP
Release 1 Release 2 ...
Itérations Sprint
Chaque fin de sprint apporte de nouvelles fonctionnalités pour les Product Owner
RELEASE
Sprint 1 Sprint 2 ...
Itérations Stories
Chaque fin de Story est une nouvelle liste de tâches terminées pour la team
SPRINT
Story 1 Story 2 ...
PlanningROADMAP
RELEASE ...
SPRINT SPRINT SPRINT
Story Story
Story Story
Sprint review Sprint review Sprint review
Sprint planning Sprint planning Release review
Le process Scrum
Le Backlogan accumulation of something
Définition du Backlog
Une liste des fonctionnalités à réaliser
Chaque fonctionnalité est décrite par une Story
Le backlog est défini en amont du projet puis actualisé tout au long du projet
Les stories y sont priorisées en fonction de leur taille (plus petites en premier) et de leur valeur (plus grande valeur en premier)
Backlog et planification
Backlog
Sprint 1
Sprint 2
Produit partiel
Produit partiel
Story Story
StoryStory
StoryStory
StoryStory
StoryStory
Story Sprint 3
...
Produit partielStory
...
Actualisation du backlog
Les Users StoriesTout projet est un ensemble de belles histoires
En tant qu’utilisateur je
veux ajouter un produit
à mes favoris afin de
pour le retrouver
facilement plus tard
User Story
En tant qu’utilisateur je veux ajouter un produit à mes favoris afin de pour le retrouver facilement plus tard
En tant que Sylvianne,
je veux ajouter un
produit à mes favoris afin
de le retrouver
facilement plus tard
Une user story est un élément fonctionnel qui apporte une valeur et qui peut être développée au cours d’un sprint.
Pourquoi User ? Pourquoi Story ?Pourquoi pas simplement une tâche ?
Format engageant du "Story Telling"
L’information est spécifique concise et précise.
L’accent est mis sur les buts et les comportements.
L’utilisateur est clairement défini, c’est le héro des petites "histoires". Ce n’est pas un panel (“80% des femmes,“ “entre 25 et 35 ans“, etc.)
Ouvre au dialogue, à l’échange.
Le format “User Voice”
En tant que < Rôle d’utilisateur >,Je veux < But >,Afin de < Justification >
Le format « User Voice » donne du sens à la fonctionnalité… pour qui et pourquoi l’équipe va la développer
Il permet de se rapprocher d’une démarche expérience utilisateur, donne une vision concrète, réaliste et partagée de l’utilisateur final.
Il est clairement orienté ACTION et BUT (démarche de conception le plus efficace). La valeur Business représente les bénéfices qui se dégagent de l’action : Il justifie toutes les fonctionnalités d’un point de vue Business, et oblige le Product Owner et les équipes à s’interroger systématiquement sur la valeur de chaque fonctionnalité
Attributs d’une U.S.Libellé court de la fonction. Une phrase d’action à l’infinitif.Exemples : «Voir les commandes», «Choisir un produit», «imprimer les factures», ... etc.
Numéro d’identification unique
Description libre ou structurée (“User Voice” ou liste d’actions élémentaires)
Titre
ID
Description
Type
Etat
Taille
Priorité
Attributs d’une U.S.
User (administrateur, utilisateur, etc.) ou Technique (vue développeur, bug, etc.)
Créee, Acceptée, Estimée, Planifiée, En cours, Terminée
Selon l’évaluation faîte lors du planning pocker
Classement selon taille / valeur
Titre
ID
Description
Type
Etat
Taille
Priorité
INVEST’ir dans une bonne histoire
Indépendante | éviter les dépendances
Négociable | elle peut être discutée avec l’équipe chargée de la réalisation. Il n’est pas nécessaire d’inclure tous les détails
Valeur | elle est source de valeur pour le client ou l’utilisateur.
Estimable | elle peut être estimée par l’équipe de réalisation avec un risque d’erreur faible.
Size (Taille) | Des petites histoires qui peuvent se combiner. Elle doit pouvoir être conçue, développée et testée au sein d’une itération.
Testable | Un test démontre que l’histoire correspond bien aux besoins du client
Quelques exemplesBon ? pas bon ?
Je suis un client,
je veux payer avec
ma MasterCard ...
INVEST ? not INVEST ?
Je suis un client, je veux
payer en ligne …
◻ avec ma CB
(Mastercard, Visa, etc.)
◻ avec Paypal
N’est pas Indépendante
Une boîte de dialogue permet aux
utilisateurs d’éditer la liste des
imprimantes. La boîte de dialogue
permet aux utilisateurs d’ajouter ou de
supprimer des imprimantes. Un
utilisateur peut ajouter une
imprimante par une recherche
automatique ou manuelle par le biais d’
une adresse DNS ou d’une adresse IP.
Une recherche avancée optionnelle
permet de filtrer les imprimantes par
adresse IP ou par le masque de réseau
INVEST ? not INVEST ?
Je suis un utilisateur, je peux
ajouter une imprimante afin d’y avoir
accès depuis n’importe quel logiciel de
mon système
◻ Recherche automatique
◻ Recherche manuelle (IP
ou DNS)
◻ Autres solutions ?
Difficilement négociable, manque de flexibilité
De la valeur pour le client
Je suis RH, je veux Qualifier la liste
des candidats afin de la réduire et y
retrouver facilement les profils
correspondants à différents critères
◻ Attribuer une note
◻ Associer un tag
◻ Marquer l’état (à
conserver, rejetté,
entretien, etc.)
De la valeur pour l’utilisateur
Je suis demandeur d’
emploi, je veux
rechercher un emploi par
poste et par région afin
de trouver une offre
correspondant à mes
besoins.
INVEST ? not INVEST ?
Non estimable, le développeur ne maîtrise pas le domaine technique
EPIC !
Non estimable, le développeur ne maîtrise pas le domaine fonctionnel
Je suis
Commercial, je
veux suivre la
marge net
mensuelle de mes
ventes afin de ...
INVEST ? not INVEST ?
Je suis Médecin, je veux accéder aux informations de mon patient sur DXCARE
Je suis Chômeur, je recherche un emploi ...
EPIC !
Je suis vendeur je
veux gérer mes
objets en vente ...
INVEST ? not INVEST ?
Découper en données opérationnelles
Je suis vendeur, je
veux créer une
fiche produit afin
de vendre un objet
Je suis vendeur, je
peux ajouter
plusieurs photos
afin d’améliorer la
visibilité de mon
produit
Je suis vendeur, je veux supprimer ma fiche afin de ne plus être contacté
une fois ma vente effectuée.
Détailler en données opérationnelles
EPIC !
Je suis Joueur je
veux jouer en ligne
contre un max d’
autres joueurs
INVEST ? not INVEST ?
Je suis joueur, je veux
lister les rooms
multiplayeurs et voir le
nombre de joueurs
connectés afin de
rejoindre la room la plus
fréquentée
Rédiger des informations Vérifiables
Je suis
utilisateur et je
ne veux pas
attendre ...
INVEST ? not INVEST ?
En tant qu’utilisateur je
veux recharger la page
en moins de 1 seconde 95%
du temps
6 stratégiesPour avoir des User Stories efficaces
1.)
Par étapes d’un Workflow
L’utilisateur accomplit une tâche selon un workflow bien établi. On découpe les stories par étapes qui seront développées de façon incrémentale.
source : http://www.qualitystreet.fr/
2.)
Par scénarios
On obtient une User Story pour le scénario principal, le cas où tout se passe bien, on en a d’autres pour les cas d’erreurs ou les scénarios alternatifs : quand il se passe A ; quand il se passe B
source : http://www.qualitystreet.fr/
3.)
Par opérations
Souvent le mode de décomposition le plus évident … Le CRUD (create, Retrieve, Update, Delete) est un bon exemple ; il est souvent utile de découper ou d’en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer.
source : http://www.qualitystreet.fr/
4.)
Par Format ou type de données
On joue sur le type d’objet (ex : compte titres, devises, images, messages en français, anglais, espagnol…)
source : http://www.qualitystreet.fr/
5.)
Par type d’entrée, de sortie ou de configuration
Des variations d’un point de vue matériel ou non, selon les configurations mais aussi en termes de moyens de saisie. Cela peut se jouer aussi au niveau de l’interface…
source : http://www.qualitystreet.fr/
6.)
Par persona
Cette fois-ci, on décompose les user stories en fonction du rôle et de celui qui va utiliser le produit, le fameux « en tant que… ». Pour cela, on peut s’appuyer le user story mapping, une activité menée au début du projet pour définir le backlog de produit et la roadmap produit.
source : http://www.qualitystreet.fr/
Évaluer la tailleComment juger de la compléxité d’une User Story
(avant de les plannifier)
Taille et répartition
Pour planifier les sprint, il faudra répartir l’effort nécessaire à la production en fonction de la capacité de l’équipe
Il faut donc connaître la taille de l’effort nécessaire pour chaque User Story "Ça dépend"... Oui, ça évidemment, on vous
demande de répondre par OUI ou par NON,
alors forcement : "ça dépend", ça dépasse !
La taille
Elle est exprimée en Story Point.
C’est une valeur arbitraire qui permet de calculer l’effort à fournir pour la réaliser et non le temps nécessaire à sa réalisation
Pour aller de Rome à Paris, la question de la durée
du voyage va dépendre de la vélocité du moyen de
transport choisi ... la distance, elle, ne change pas.
Une mesure relative ...
Pour démarrer : ● Prendre une User Story de référence, de préférence petite et connue ou déjà expérimentée par les développeurs; ● lui attribuer une valeur basse (1, 2 ou 3 Story Point)● Traiter les autres Users Stories en appliquant des valeurs relatives (-2, +1, etc.)
Comme il s’agit de déterminer la compléxité d’une User Story, il est plus simple de la calculer en valeur relative : “beaucoup plus simple, plus facile, plus difficile, beaucoup plus difficile”
… et exponentielle !
Nous cherchons à évaluer un ordre de complexité. plus le scénario est gros, moins l'évaluation est précise.
0.5 1 2 3 5 8
13 20 40
La méthode d’évaluation ...
Problème : le premier qui parle influence les autres ...
Je suis RH, je veux
Qualifier la liste des
candidats afin de la
réduire et y retrouver
facilement les profils
correspondants à
différents critères
Quelle taille ?
5 jours !Ha oui, 5 c’est bien
Pareil
Pas mieux
Peut-être 6 ...
… pour être sûr
… version Planning Pocker !
En utilisant des cartes, sorties en même temps, chacun donne librement sa propre estimation, basée sur sa propre compréhension de la story
Je suis RH, je veux
Qualifier la liste des
candidats afin de la
réduire et y retrouver
facilement les profils
correspondants à
différents critères
Quelle taille ?
5 3 8
5
13
ce qui permet la discussion
Si les écarts sont trop importants, on lance un débat autour des extrèmes pour comprendre les différents points de vu, puis un nouveau tour est lancé jusqu’au concensus.
Je suis RH, je veux
Qualifier la liste des
candidats afin de la
réduire et y retrouver
facilement les profils
correspondants à
différents critères3 et 13 : justifiez !
5 3 8
5
13
Blah blah blah blah blah blah blah
Blah blah blah blah blah blah blah
PrioriserOrdonner les Users Stories (avant de les plannifier)
Fixer les priorités
Fixer les priorités consiste généralement à classer les Users Stories selon la valeur apportée au projet
Nécessaire Souhaitable Si possible
Priorité
Critères objectifs de priorité
13 5
1313
Même taille
Valeur différente
Taille différente
Même Valeur
Priorité
PlannifierEnfin ! Lancer la production des sprints
1. Définir la durée d’un sprint
Les sprints doivent avoir une durée fixe. La durée est définie en fonction :
- de vos besoins en réactivité- des besoins en montée en
puissance de l’équipe
Les sprints peuvent avoir une durée de 1 à 5 semaines.
Comment choisir ? les sprints courts sont bénéfiques. Ils autorisent l'entreprise à être “agile”, c'est-à-dire à changer souvent de direction. Sprint court = cycle de feedback court = des livraisons plus fréquentes = plus de feedback des clients = moins de temps passé à courir dans la mauvaise direction = apprendre et améliorer plus rapidement, etc.
les longs sprints sont bien aussi. L'équipe a plus temps pour monter en puissance, ils ont plus de temps pour récupérer des problèmes et parvenir tout de même à atteindre le but du sprint, il y a moins de surcharge en terme de réunions de planning de sprint, de démonstrations, etc.
Conclusion : il n’y a pas de règles. faîtes des tests au début.
2. Définir la taille d’un sprint
La taille est déterminée en Story points et dépend de la capacité de production de l’équipe pour la durée du sprint fixé.
Ce calcul se résume ainsi :Jours-hommes disponibles multipliés par le facteur de focalisation (c’est à dire la capacité pleine de travail).
Comment calculer ? Exemple :
● Durée des sprint : 3 semaines, soit 15 jours.
● Taille de l’équipe : 3 développeurs dont 1 à ⅔ temps , soit : 15+15+10 = 40 jours hommes.
● Facteur de focalisation : Des perturbations externes et des réunions sont prévues pendant ce sprint, soit une estimation de 40% de capacité pleine de travail
Résultat : 40 Jours homme * 40% = 16 Jours
3. Créer le plan de Sprint
3 5
8
SPRINT 1 - 16 pts
5
32
SPRINT 2 - 15 pts
5
SPRINT 3 - 13 pts
85
2
Cette US dépasse la capacité du sprint 1, elle est reportée au sprint suivant
Les cérémoniesUn rythme qui “force” la communication...
Rythme des sprintsSPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4
Sprint backlog
Démo
Rétrospective
Production
Daily meeting
Daily meetingUne réunion courte, en début de journée (pendant le café ?), de préférence debout (appellée aussi standing meeting) ... c’est une réunion “informelle“ qui doit maintenir le lien au sein de l’équipe.Les membres de l’équipe ont la parole. L’objectif est de soulever les éventuels obstacles rencontrés et de les consigner dans le Backlog des problèmes.
Les 3 questions que chaque membre de l’équipe expose :
- Qu’ai-je fait hier ?
- Que vais-je faire aujourd’hui ?
- Quels sont les obstacles que j’ai rencontré ?
Sprint Review (démo)Une réunion importante puisqu’elle consiste à présenter le produit partiel réalisé pendant le sprint. Déroulement :
- Démo de ce qui a été fait (et fini)- Mise à jour du Backlog : revue des
priorités, ce qui permettra de définir le contenu du prochain sprint
L’équipe prépare la réunion et fait la présentation du
produit au Product Owner
Le scrumaster organise la mise à jour du Backlog
RétrospectiveCette réunion, en équipe uniquement, permet de faire le point sur le Backlog des problèmes rencontrés durant le sprint et de définir un plan d’action pour corriger ces problèmes.Objectif : Amélioration Continue
Le backlog des problèmes est consolidé
Un plan d’actions d’amélioration est défini et mis à jour
MesurerConnaître la vélocité pour améliorer
sa capacité à anticiper l’avenir
Estimation de la vélocité92
80
64
48
32
16
s1 s2 s3 s4 s5 s6 s7A faire
Sto
ry p
oint
s
Sprints
Vélocité idéale
Mesure de la vélocité92
80
64
48
32
16
s1 s2 s3 s4 s5 s6 s7A faire
Sto
ry p
oint
s
Sprints
Vélocité réellePlus lent
Plus rapide
Projection réelle
Déroulement d’un sprint
Le backlog de sprint
Début du sprint
TODO PROGRESS DONE :o)
5
3
3
1
8
52
5
15
55
ADMIN
11
FRONT 16
MIG
RATION
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
StoryTâches
Sprint en cours
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
15
55
ADMIN
11
FRONT 16
MIG
RATION
Les tâches, puis les stories migrent vers Done
Certaines tâches peuvent être remises à plus tard
De nouvelles tâches peuvent apparaître en cours de prod
Le Burndown chart est mis à jour quotidiennement
52
Fin du Sprint
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
15
55
ADMIN
11
FRONT 16
Cette Story n’est pas terminée, elle ne sera pas présentée lors de la démo
2
MIG
RATION
Les signaux d’alerteComprendre le Scrum Board
Trop de tâches
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
15
55
ADMIN
11
FRONT 16
MIG
RATION
2
Besoin de supprimer des éléments du Sprint Backlog
Trop d’imprévus
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
15
55
ADMIN
11
FRONT 16
MIG
RATION
2
Attention : l’accumulation de tâches non plannifiées peuvent tuer le Sprint
Manque de tâches
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
15
5 5
ADMIN
11
MIG
RATION
2
Besoin d’ajouter des éléments du Sprint Backlog
FRONT 16
Respect des priorités
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
15
55
ADMIN
11
FRONT 16
MIG
RATION
2
Attention : L’équipe néglige les tâches prioritaires
Vous avez 10 projets ?Peut-on travailler sur plusieurs projets en simultané ?
Oui !
Pour le backlog, aucun soucis : Mais attention : il faudra calculer de manière plus précise votre facteur de focalisation pour chaque projet, imputé nécessairement par la production sur les autres projets au sein d’un même Sprint !
Projet 1
Projet 2
… etc.
Exemple multi-projets
SPRINT 1 (44 points) SPRINT 2 (44 points) SPRINT 3 (44 points) SPRINT 4
Sprint backlog
Démo
Rétrospective
Production
Daily meeting
Projet 1
Projet 2
Projet 3
Focus = 15 %
Focus = 30 %
Focus = 15 %
Taille équipe : 3 développeurs
Focus équipe : 60%
Taille Sprint : 2 semaines
Capacité Sprint = 30jh * 60% = 18 jours, soit : 9 + 4,5 + 4,5
SI 1 sp = 3h, la capacité est donc de 22 + 11 + 11, soit 44 SP par sprint
CAPACITÉ :
Planning :
Et les contrats ?Est-ce que les méthodes agiles sont adaptées
aux prestataires de services ?
Les 2 types de contrats :
Au forfait
Le forfait est par nature antinomique avec les méthodes agiles … mais rien n’empêche de décomposer un forfait en lots, équivalent à vos incréments.
Attention à bien définir le périmètre fonctionnel en amont pour garantir au fournisseur (le développeur) qu’il ne rognera pas sa marge.
A la régie
C’est la méthode la plus naturelle, mais qui nécessite une relation de confiance forte.
Définir le périmètre peut également être une bonne idée pour garantir au client qu’il ne dépensera pas plus que nécessaire.
Paradoxes des contrats
En régie : plus le projet avance, moins la valeur perçue par le client est forte. Le développement devrait donc prendre fin lorsque le coût dépasse la valeur marginale acquise.
Avec le mode forfait, le coût est négocié d’avance. Ainsi, plus le développeur travaille (pour une valeur moindre), plus il rogne sa marge.
source : http://blog.xebia.fr/
Découpage par lots
C’est une alternative ... En définissant des budgets par lots on peut lier anticipation et engagement avec la flexibilité des méthodes agiles
Merci !That’s all Folks
Des concepts pour aller plus loin
Le Story Mapping :Il s’agit d’une représentation à 2 dimensions et plus riche de celle offerte par le Backlog de produit. En horizontal : les usages, en vertical : les priorités.
Kanban :Un outil plus souple que SCRUM … et pourquoi ne pas le mélanger avec SCRUM ?
Behaviour Driven Development : Compléter les stories en expliquant les comportements : Given When Then
Les Personas : Rédaction de fiches utilisateurs précises et détaillées. Les personas évitent de parler en terme de “panel” et permettent une approche plus personnifier des fonctions.
Definition of Done :Définition du “fini”, pour les stories, les sprint et les releases afin de s’assurer que toute l’équipe suive un même niveau de qualité.
RESSOURCES
Les méthodes Agiles expliquéeswww.qualitystreet.fr/www.agiliste.fr/henrik-kniberg.developpez.com/livre/scrum-xphenrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban
La culture Agilehttp://blog.xebia.fr/category/agilitewww.areyouagile.com/
Contrat Agilehttp://www.contrat-agile.org/
www.scrum.org
Recommended