Introduction à l'agilité

Numélink - 24 mai 2012 

@Agnes_Crepet@GuillaumeEhret @AlfredAlmendra

Etapes du projet

Les jeux et les étapes du projet

Extrait du calendrier du CARA Lyon (OUI, c'est de la PUB !) 

La vision produit = le cadre du projet

Justifie l'existence du produit 

Ciblée, valeur ajoutée 

Simple, concise

L'essentiel : enjeu, objectifs

Une projection du futur

Permet de garder le focus

... et celle du projet 

... l'utilisateur, ses besoins

... fonctionnalités clé ... besoins / attentes / résultat ... mais sans aucune certitude ... aller vite ... mais bien !

La vision produit : fédératrice et partagée

 

Exemple de Roman Pichler

Quand et comment ?

Le test de l'ascenceur (elevator statement)POUR (les utilisateurs finaux du produit)QUI SOUHAITENT (leurs besoins)NOTRE PRODUIT EST (un résumé du produit)QUI (le bénéfice majeur et l’utilité du produit)A LA DIFFÉRENCE DE (produits concurrents)PERMET DE (éléments différenciateurs majeurs)

Vision produit

C'est l'étape la plus souvent oubliée, ou plutôt la moins souvent partagée

Elevator statementMindmapJeu de la product box

"I think every project should be considered to produce a product"Jim Highsmith

 

Des exemples ?

 

Source: http://www.agilex.fr/

Vision

But But But

Personna Personna

Epic 1

US 1

US 2

US 3

Epic 2

US 1

US 2

US 3

Vision vers Epic(~ fonction / UC)

Les personnas viennent de l'UX

Qu'est-ce qu'une User Story ?

Développeur

Marketing

Chef produit Client

Commercial

Ne pas oublier les critères d'acceptation !

© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com

time

necessity

• Le backbone de l’application est la liste des activités essentielles que l’application supporte

• Le “walking skeleton” est le logiciel que nous construisons qui supporte le nombre minimum et suffisant de tâches nécessaires sur le panel de fonctionnalités

The backbone

The walking skeleton

User Story Mapping

time

optionality

necessary

lessoptional

moreoptional

first release

second release

third release

User Story Mapping

Story mapping

Qu'est-ce que le backlog produit ?

Les stories du backlog

Chaque post-it doit être discuté avec tout le monde

Repérer les doublonsSi l’attente n’est pas tangible, il faut la rediscuter= formuler des critères d'acceptation (Criteria of Done)

Possibilité d'automatiser les tests d'acceptations    Behavior Driven Development

Ne pas hésiter à réécrire les post-its

Amaigrir le produit le plus possible

Valoriser et prioriser

MoSCoW• M - MUST have this• S - SHOULD have this if at all possible• C - COULD have this if it does not effect anything else• W - WON'T have this time but would like in the future

KanoQuestions fonctionnelles et dysfonctionnelles– Attractif– Une dimension linéaire– Obligatoire– Indifférent– Pénalisant

http://socious.com/ 

KanoChaque question est posée sous les 2 formes :Que pensez-vous ou comment vous sentez-vous ... ?

Formulation fonctionnelle :... si cette fonctionnalité est présente (et fonctionne bien)

Formulation dysfonctionnelle :... si cette fonctionnalité n'est pas présente ou ne fonctionne pas bien (ou pas du tout)

1. J'aime bien2. C'est la base, le minimum3. Sans avis, neutre4. Je peux vivre avec (ou sans)5. Je n'aime pas

http://cbigot.net/kano 

Prune the product tree

Façonner plutôt que couper

Au début du projet, mais aussi en début de sprint / release

"Livrer quelque chose de cohérent"

Photo de effectiveagiledev.com

Estimation

Le budget n'est pas une somme d'estimation

Estimation relative par comparaison• consensuelle, durable

Exemples de techniques de collaboration :• Consensus du groupe• Répartition de tâches• Combinaison des estimations individuelles

Exemples de jeux• Planning poker (1, 2, 3, 5, 8, 13, 20, 40, 100) (fibonacci)• T-Shirt sizing (XS, S, M, L, XL)• Zoo points (férocité), poids des chiens,...

Estimation

• Fourchettes pour les estimations. Nombres pour les faits• Toujours demander à quoi les estimations sont destinées• Une estimation n'est pas un engagement• Mesurer, compter et calculer avant d'estimer• Agréger les estimations indépendantes• Utiliser la loi des grands nombres (grand nombre de stories,

nombre constant de personnes qui estiment)• Calibrer les estimations avec les autres vélocités standards• Ne jamais négocier les estimations• Ne jamais négocier les engagements• Résoudre les problèmes ensemble

Estimation

Quelques exemples d'utilisation :

• planification d'itération

• ré-estimation : traduction en moyenne d'heures à partir de la vélocité (Scrum), voire en fonction du profil de la personne

• gestion du risque sur le périmètre fonctionnel d'un sprint, d'une release

Agile Grenoble 2011 : Stéphane Hanser (@tourix)Complexité / flou / niveau de connaissance / expérience

Planification

Les itérations : de quelques jours, semaines à 2 mois max

Les releases : toutes les X itérations    Idéalement toutes les itérations    Maximum : toutes les 3

Scrum : périmètre figé du sprint en coursKanban : pérmiètre flexible 

Gestion du risque, suivi et arbitrage au quotidien : daily meetings    ++ estimation du reste à faire    -- passer trop de temps sur un chiffrage trop fin 

Retropective

Bilan des itérationsObjectif : s'améliorer et non juger!  Toute l'équipe participe à la réunion En entrée • le plan d'actions de la rétrospective précédente• le backlog de problèmes

 Etapes• Créer un environnement propice à l'expression• Collecter les informations relatives au processus• Définir les priorités• Planifier des actions d'amélioration