Communaute dot net Montreal juin2010

© Copyright Pyxis Technologies

Le développement Agile

Un aperçu


Qui suis-je

Dominic Danis

Directeur du produit Urban Turtle à Pyxis Technologies, firme spécialisée dans le développement, la formation, le coaching ainsi que le développement de produit agile.

[email protected]

2

© Copyright Pyxis Technologies3

Petite mise en garde

Scrum ne donne pas la recette secrète du développement logiciel

Scrum fournit simplement les mécanismes permettant de mettre en lumière les problèmes et difficultés que nous rencontrons dans nos projets de développement logiciel afin d’être en mesure de les régler

Une équipe Scrum apprend à s'améliorer continuellement


Quels problèmes rencontrons-nous ?

CHAOS Report du Standish Group, 2003

Succès: Le projet est réalisé selon le

budget et les délais convenus. Il

comporte les fonctions et

caractéristiques demandées.

Défi: Le projet est en retard, le budget a

été dépassé ou il manque certaines

fonctions et caractéristiques demandées.

Échec: Le projet a été arrêté avant sa

fin ou le logiciel développé a été livré

mais n’a jamais été utilisé.


Livrons-nous du logiciel de qualité?


Jim Johnson, Standish Group, XP 2002

Nos solutions sont-elles utiles? Statistiques de l’industrie


Peut-on livrer plus rapidement ?

d'après les travaux d'Hakan Herdogmus, GUAM 2005


Problèmes de communication?

Le développement logiciel est un jeu coopératif d’invention et de communication. Il est apparenté au développement de produit.

Les sources de problème dans

notre profession sont les gens

et les interactions

dysfonctionnelles plutôt que

les processus et les outils.

Comment communiquez-vous?


Alors pourquoi le développement Agile?

1. Pour satisfaire rapidement notre client avec des solutions logicielles utiles

2. Pour augmenter la qualité

3. Pour faire face à la complexité

4. Pour réduire les inefficacités5. Pour éviter les longues périodes de stabilisation en fin

de projet

6. Pour maximiser la collaboration7. Pour augmenter la motivation et l’engagement des

individus8. Pour avoir du plaisir au travail


Manifeste Agile

Nous sommes à découvrir de meilleures façons de développer des logiciels en aidant les autres et en développant nous aussi. Par ce travail, nous en sommes venu à valoriser ce qui suit :

Personnes et interactions plutôt que processus et outils

Logiciel fonctionnel plutôt que documentation complète

Collaboration avec le client plutôt que négociation de contrat

Réaction au changement plutôt que suivi d’un plan rigide

En fait, bien que les éléments de droite soient importants, ceux de gauche le sont encore plus.


Principes Agiles (1 de 2)

1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement du logiciel utile

2. Le changement est bienvenu, même tardivement dans le développement. Les processus Agiles exploitent le changement comme avantage compétitif pour le client

3. Le logiciel fonctionnel est la principale façon de mesurer le progrès

4. Les gens d’affaires et les développeurs doivent collaborer quotidiennement, et ce, tout au long du projet

5. La méthode la plus efficace de transmettre l’information est une conversation face-à-face


Principes Agiles (2 de 2)

6. Une attention continue à l’excellence technique et à la qualité de la conception améliore l’Agilité

7. La simplicité — l’art de maximiser la quantité de travail à ne pas faire — est essentielle

8. Les meilleures architectures, spécifications et conceptions émergent d’équipes qui s’auto-organisent

9. Agile favorise le développement à un rythme normal

10.Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus efficace, s’ajuste et modifie son comportement en conséquence


Méthodologies Agiles

ScrumExtreme Programming (XP)Adaptive Software DevelopmentCrystal ClearFeature Driven DevelopmentDynamic Systems Development Method (DSDM)MSF for Agile Software DevelopmentRUP (Agile RUP—AUP)


Pilier 1

Le processus empirique


Une question de bons sens


Processus empirique :le squelette de Scrum

ProductOwner

ScrumMaster Équipe Scrum

Vision

Utilisateurs


Itération : le sprint

Planification de sprint

(max. 1 jour)

Démo et rétrospective (max. 1 jour)

Sprint de 30 jours d’effort soutenu et ciblé (focused)

1 2 3 4 5 6 7 n

Mêlée quotidienne (max. 15 min.)

Développement : Conception, code, test, documentation


Pilier 2

La valeur d’affaire en avant plan


La valeur d’affaires au premier plan

Contraintes

Estimations

S'appuie sur le plan

Coût Calendrier

Exigences

Contraintes

Estimation

Processus en cascade

Du plan découleles estimations relatives au

coût et au calendrier.

S'appuie sur la valeur ou

vision

Coût Calendrier

Fonctionnalités

Processus Scrum

De la vision découleles estimations relatives

aux fonctionnalités.

19


Responsable de produit(product owner)

Un bon responsable de produit doit :• Connaître la valeur commerciale du produit

• Avoir le pouvoir de réunir des intérêts et désirs variés• Être disponible• Diriger une équipe de gestion de produit

Ses responsabilités sont :• Communiquer la vision

• S’approprier les spécifications

• Évaluer les incréments du produit

• Collaborer avec l’équipe de développement (le plus possible)

• Collaborer avec l’équipe de gestion du produit (le plus possible)


Gestion des exigences :le carnet du produit

Chaque itération met en œuvre les exigences prioritaires.

Chaque nouvelle exigence est insérée dans la liste selon sa priorité.

Il est possible en tout temps de changer l’ordre de priorité des exigences.

Les exigences peuvent être supprimées en tout temps.


Granularité des exigences

Sprint courant

1-2

sprints

Livraison

Produit

6 mois 2-3 mois 1 mois Implantation

Vis

ion

Épi

sode

s

Scé

nario

s

Tâches

Des détails sont ajoutés au fil du temps

Horizon de prévisibilité


Pilier 3

La livraison d’incréments de produit terminés


Comment faire du développement incrémental?


Processus en cascade

« Ça ne fonctionne jamais! » — Brian Marrick

C’est un processus imprévisible,

ce qui cause des surprises, donc

de l’insatisfaction.


Processus Scrum

C'est un processus prévisible, ce qui aide à prendre des décisions éclairées.

La date est fixée. Que doit-on inclure dans le produit ?

Le produit est en état d'être déployé à la fin de chaque sprint.


Définir « terminé »

La définition de « terminé » capture la capacité technique actuelle de l'équipe

Avec le temps, la définition de « terminé » devrait s'étendre à toutes les activités nécessaires à la livraison en productionLe travail qui n'est pas couvert pas la définition de « terminé » (travail « non terminé ») doit être identifié et porté au carnet de produitTout élément qui ne respecte pas la définition de « terminé » n'est pas présenté au directeur de produit en fin de sprint


Étendre la définition de « terminé »

Conception réviséeCode remaniéCode réviséTests unitairesTests intégrésTests de recetteTests de performanceTests d'ergonomieDocumentation utilisateurDéploiement en pré-productionAcceptation par les utilisateurs


La courbe du travail restant à faire permet de déterminer la date

probable de livraison

Suivi de l’avancement


Pilier 4

L'équipe autogérée


Équipe Scrum

Une équipe Scrum comprend uniquement les personnes suivantes :• un responsable de

produit

• un ScrumMaster

• des « équipiers »


Caractéristiques d’une équipe Scrum

S’auto-organise

Est pluridisciplinaire et ne comporte pas de rôles prédéterminés

Compte 7 membres (+/- 2)

Est responsable de son engagement

Possède l’autorité nécessaire pour agir de manière à respecter ses engagements

Travaille dans des locaux ouverts et avoisinants

Résout ses propres conflits

Observe des règles de base de fonctionnement et de comportement


Imposer

Contrôler

Diriger

Faire confiance

Faciliter

Accompagner

Le Scrum Master n'est pas un chef de projet


Mêlées quotidiennes

Paramètres :• Tous les jours• Durée limitée à 15 minutes• Tout le monde debout• Pas de résolution de problèmes

Trois questions :1. Qu’ai-je fait hier?2. Quels ont été les obstacles rencontrés?3. Qu’est-ce que je compte faire aujourd’hui?

Les membres d’équipes et personnes externes sont invités• Permet d’éviter des réunions inutiles

Seuls les membres d’équipe peuvent s’exprimer


Questions sur les mêlées quotidiennes

Pourquoi tous les jours?• “Comment un projet peut-il avoir un an de retard?”

• “Un jour à la fois.”

– Fred Brooks, The Mythical Man-Month.

Est-ce que les mêlées quotidiennes peuvent être remplacées par des rapports d’activité envoyés par courriel?• Non, non et NON!

• L’équipe entière possède une vision complète actualisée quotidiennement

• Une pression par les pairs incite à faire ce que nous avons dit que nous ferions


Revue du sprint

L’équipe présente ce qui a été réalisé pendant le sprint

La présentation comporte une démonstration des nouvelles fonctionnalités ou de l’architecture• Ce qui n’est pas complété n’est pas démontré!

Revue informelle• Ne pas dépasser 2 heures

de préparation

Participants• Propriétaire du produit• Clients• Management• Équipe


Rétrospectives du sprint

Le ScrumMaster établit la priorité des améliorations avec l’aide de l’équipe• L’équipe conçoit des solutions aux

éléments de haute priorité• 2-3 max!

• L’équipe met les solutions en œuvre

L’équipe s’approprie le processus

Dans le but d’améliorer le processus• À la fin de chaque sprint• Le ScrumMaster est facilitateur

Évaluation de ce qui a bien été et ce qui devrait être amélioré


La transition

Du traditionnel vers l’agilité


Erreurs communes

1. Faire de l’Agile « pour être dans le vent »

2. Faire du développement itératif et non incrémental

3. Commencer à sprinter seulement lorsque tous les besoins sont recueillis

4. Effectuer des « mini waterfall »

5. Laisser les spécialistes travailler en silo

6. Avoir un responsable de produit qui ne s’implique pas suffisamment

7. Ne pas partager une vision commune de « terminé »

8. Ne pas travailler en équipe


Références – Principes


Références – Gestion de projet Agile


Références – Collaboration


Références – Analyse et modélisation


Références – Rapport d’expérience

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Communaute dot net Montreal juin2010

Technology

Transcript of Communaute dot net Montreal juin2010