SlideShare une entreprise Scribd logo
L'adoption de Scrum : Défis et retour d'expérience
Sondage à main levée Utilisez-vous une approche Agile  dans votre organisation?
Déroulement Historique, valeurs et principes Pratiques Agiles : impacts et défis Transition vers l’Agilité Questions
1945 à 1965 – Les débuts 1965 à 1985 – La crise Années 80 et 90 – On veut passer de l’artisanat à l’ingénierie logicielle, on cherche le  silver bullet Fin des années 90 – On commence à utiliser des méthodes dites légères Septembre 2000 – Pyxis est née Février 2001 – Le manifeste Agile Septembre 2002 – Le groupe d’utilisateurs Agile de Montréal est créé 2003 – 2005 – On cherche à convaincre 2006 – On s’intéresse de plus en plus à l’Agilité 2007 – Le nombre de participants à la conférence Agile double pour une troisième année consécutive 2008 – On en parle trop? Un peu d’histoire
Nous découvrons de meilleures manières de développer des logiciels en aidant les autres et en en développant nous-mêmes. Par ce travail, nous en sommes venus à valoriser ce qui suit : les   individus et les interactions  davantage que les processus et les outils; les logiciels fonctionnels  davantage que la documentation exhaustive; la collaboration avec le client  davantage que la négociation de contrat; l’ouverture au changement  davantage que le suivi d’un plan. En fait, bien que les éléments de droite soient importants, nous considérons que les éléments de gauche le sont encore plus. Manifeste pour le développement Agile de logiciel
Principes Agiles (un sous-ensemble) ‏ La priorité est de satisfaire le client par la  livraison rapide  et  continue  de solutions logicielles utiles.  Il faut intégrer les  changements , même ceux de dernière minute, car ils offriront un  avantage compétitif  à votre client.  Il faut élaborer des projets autour d’individus  motivés . Il faut leur fournir le  soutien  nécessaire et leur faire confiance.  Les meilleures solutions émergent des  équipes autoorganisées .  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.  Il faut porter une attention continue à  l’excellence  technique; un bon design améliore l’Agilité.  La  simplicité  est essentielle.
Pourquoi Agile?
Nos projets sont-ils des succès? 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é.
Gaspillons-nous nos investissements? Jim Johnson, Standish Group, XP 2002
Peut-on livrer plus rapidement? d'après les travaux d'Hakan Herdogmus, GUAM 2005
Que faire face à la complexité? La dimension humaine ajoute un autre niveau de complexité.  Le dernier projet simple  date de 1969. Complexité des projets Strategic Management and Organisational Dynamics: The Challenge of Complexity Ralph D. Stacey
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?
Pratiques Agiles et leurs impacts
Principes vs pratiques Principe Vérité qui  ne change pas  dans le temps ou l’espace Pratique Application d’un principe à une  situation particulière La  compréhension  des principes est essentielle pour en réussir  l’implantation  par un ensemble de pratiques
Processus empirique Lorsque la  complexité croît , les systèmes de gestion et de contrôle centralisés montrent leurs limites. La solution est d'établir un ensemble de  règles simples  et de laisser l'application de ces règles à des agents indépendants. Un processus empirique utilise  l’inspection et une adaptation  subséquente afin d’optimiser l’atteinte des buts.  L’inspection et l’adaptation nécessitent la  transparence . La transparence nécessite du  courage  et des changements au niveau des systèmes de récompense.
Processus empirique : le squelette de Scrum
Itération : le sprint
Démarrage d’un projet Agile Portée et limites du projet Vision du produit Plan de livraison
Mise en production d’un projet Agile
Impacts et défis La mise en place d’un processus empirique est  plutôt simple  sauf que… Pièges à éviter  Récupération de tous les requis avant de commencer à « sprinter » Itérations trop longues Mêlée quotidienne inefficace Rétrospectives inefficaces Impacts possibles Le fait de démarrer rapidement =  chèque en blanc ? Je dois parler de mes obstacles  devant tous le monde ? Qu’arrivera-t-il si on est  pas prêt pour la démo ? Une journée de planification par 3 semaines, ce n’est pas  trop ?
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écoule les 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écoule les estimations relatives aux fonctionnnalités.
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.
Suivi de l’avancement La courbe du travail restant à faire permet de déterminer la date probable de livraison
Impacts et défis Mettre la valeur d’affaires du logiciel à l’avant-plan ça semble logique  sauf que… Pièges à éviter Avoir un responsable de produit  non imputable Négliger la  maintenance du carnet  du produit Analyser  trop rapidement  les exigences non prioritaires Ne pas établir les  conditions de succès  liés à chaque exigence Impacts possibles Peut-on  clairement identifier  un responsable de produit? Ça veut dire quoi pour nos  analystes d’affaires ? Que fait-on des  demandes de changement? Qu’est-ce qu’on fait avec notre gabarit pour la  documentation fonctionnelle ? Ça veut dire quoi pour mes  mesures ( metrics ) de suivi ?
Comment faire du développement incrémental?
La prévisibilité de Scrum C’est un processus  prévisible , ce qui aide à prendre des décisions éclairées.  La date est fixée. Quelles sont les caractéristiques à livrer? Une livraison de  qualité production  doit avoir lieu à la fin de chaque sprint.
Étendre la définition de  ‘terminé’
Ingénierie Agile Une attention continue à  l’excellence technique  améliore l’Agilité. La majorité des pratiques d’ingénierie Agiles proviennent de  XP . Conception pilotée par les tests, intégration continue, programmation en binôme, remaniement du code  ( refactoring ) ,… Faites la conception et  les tests tout au long  du projet... Il faut garder un  œil sur le futur  tout en retardant nos décisions le plus longtemps possible. (« You ain’t gonna need it! » - YAGNI) Développez les compétences requises.  Augmentez vos connaissances  techniques.  On pense à tort que les programmeurs Agiles sont des ‘cowboys’ .
Impacts et défis Construire un logiciel de façon incrémentale peut représenter  tout un défi ! Pièges à éviter Établir une  grosse architecture  tôt dans le projet Créer de l’ inventaire  (trop de code pour nos besoins présents) Accumuler une  dette technique  (négliger le remaniement de code, code non testé) Ne pas  exécuter régulièrement  la suite de tests automatisés Impacts possibles Qu’arrivera-t-il des  architectes ? Que vont penser les gestionnaires du  coût  associé aux tests unitaires et au remaniement de code? Pourra-t-on  déployer  le résultat des itérations?
Équipe Scrum Une équipe Scrum comprend uniquement les personnes suivantes : des développeurs (pluridisciplinaires), un responsable de produit et un ScrumMaster.
ONE TEAM!!!! L’équipe provient des organisations coopératives. La composition des équipes n’est pas limitée aux titres (généralistes-spécialistes). Les communications sont fluides. Le responsable de produit est à l’avant-plan. Équipe de développement Équipe de gestion de produit  Analyste d’affaires Utilisateurs Développeurs Chef de produit Représentant ou agent de commercialisation Architecte Responsable des tests Administrateur de bases de données Direction ScrumMaster Gestionnaire de produit
Équipe de développement Comprend de  6 à 10 membres Idéalement est  colocalisée Comprend l’ensemble de  l’expertise nécessaire  pour réaliser le projet Choisit le but de l’itération et spécifie les résultats à produire  A la latitude voulue  pour déterminer ce qui doit être fait afin d’atteindre le but fixé pour l’itération sans enfreindre les directives du projet  S’organise de façon autonome  et planifie ses propres travaux Présente des résultats de  qualité  au responsable de produit Communique son avancement et ses obstacles de façon  transparente
ScrumMaster :  un leader et un facilitateur À titre de ScrumMaster, vous êtes responsable de ce qui suit : Éliminer les barrières  entre l’équipe de développement et le client pour permettre à ce dernier d’orienter directement les travaux de développement  Montrer au client  comment maximiser le taux de rendement des investissements et atteindre ses objectifs au moyen de Scrum Améliorer le quotidien de l’équipe  de développement en mettant l’accent sur la créativité et la gestion autonome des membres Accroître la productivité de l’équipe  de développement par tous les moyens imaginables Améliorer les outils et les pratiques d’ingénierie  de manière à ce que chaque incrément de fonctionnalité puisse être livré au client
Faites confiance aux gens!
Impacts et défis Obtenir le bon niveau d’engagement de tous est essentiel à la création d’une véritable  équipe performante Pièges à éviter Se  rapporter  au ScrumMaster lors de la mêlée quotidienne Avoir un ScrumMaster qui  assigne lui-même les tâches Ne pas adapter son  style de leadership  à la maturité de l’équipe Avoir l’attitude « moi j’ai fini » Impacts possibles Comment intégrer les  spécialistes  aux équipes Scrum? Les gestionnaires sauront-ils faire  confiance  à l’équipe? L’équipe saura-t-elle  s’approprier son Scrum ? Quels sont les impacts sur le  système de rémunération ? Quels sont les impacts sur notre processus d’ embauche ?
Transition vers l’Agilité
Des questions importantes Nos organisations sont-elles prêtes à changer? …  et les individus eux?
Analyse d’impact Impacts sur l’organisation Structure organisationnelle Système de rémunération Relation avec les clients et les fournisseurs Impacts sur le processus Pilotage des projets Flux du travail Flux d’information Impacts sur les technologies Nouveaux outils pour soutenir les pratiques XP Impacts physiques Configuration des locaux
Analyse d’impact Impacts sur les individus Nouveaux rôles, nouvelles tâches Pertes de pouvoir Compétences Mentalité, façon de penser, valeurs, attitudes Motivation et engagement
Quels sont les changements requis
Autres éléments à considérer Avoir une  forme contractuelle  qui reconnaît qu’il n’est pas optimal (désiré) de chercher à connaître précisément l’ensemble des exigences au départ Mettre en place des processus qui conservent un  niveau de gouvernance adéquat , mais qui permettent les changements rapides Avoir une  forme documentaire simplifiée  qui permette l’évolutivité de la documentation Créer une culture de  collaboration
En haut….. En bas! Mode descendant  Les leaders de haut niveau partagent une vision quant à l’utilisation de Scrum. Mode ascendant Quelques équipes commencent à utiliser Scrum. Les gens voient les avantages de cette nouvelle approche et décident de l’adopter. Pour assurer le succès, le changement doit se faire  à la fois de bas en haut et de haut en bas , simultanément.
Le passage à une approche Agile  ne se fait pas du jour au lendemain  La période de transition sera longue et parfois délicate (inconfortable) avant que tous les intervenants des projets adoptent une approche axée sur la collaboration et l’autonomie.
Gestion du changement
Approche pour le passage à l’Agilité
C’est possible! Transparence!
C’est possible! 9 livraisons en 6 mois!
Conclusion Le capital humain est votre plus gros actif. L’adoption d’une approche Agile demande des changements significatifs, et la nature des préoccupations des gens doit changer. Tout changement nécessite du temps, du courage et de la persévérance.
Courage et persévérance
Merci! Des questions?

Contenu connexe

Tendances

Methode Agile
Methode Agile Methode Agile
Methode Agile
JEAN-GUILLAUME DUJARDIN
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
Valentin Bourgoin
 
Introduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jourIntroduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jour
Renaud BROSSE
 
Scrum Guide
Scrum GuideScrum Guide
Scrum Guide
Denis Voituron
 
La Gestion de Projet Agile
La Gestion de Projet AgileLa Gestion de Projet Agile
La Gestion de Projet Agile
bcollet
 
Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Introduction aux méthodes agiles
Introduction aux méthodes agilesIntroduction aux méthodes agiles
Introduction aux méthodes agiles
Guillaume Collic
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slides
Nicolas Deverge
 
La gestion de projet agile
La gestion de projet agileLa gestion de projet agile
La gestion de projet agile
Eugène ZENGOMONA
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
Mohammed Amine Mostefai
 
Présentation scrum pour cours leeaarn
Présentation scrum pour cours leeaarnPrésentation scrum pour cours leeaarn
Présentation scrum pour cours leeaarn
Gautier Pialat
 
Method XP
Method XP Method XP
Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base
Sirine Barguaoui
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
Youness Boukouchi
 
Scrum
ScrumScrum
La méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdfLa méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdf
anwermannai
 
20mn scrum
20mn scrum20mn scrum
20mn scrum
Olivier Patou
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master I
Guillaume LAURIE
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
Pierre E. NEIS
 

Tendances (20)

Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
Methodes agile
Methodes agileMethodes agile
Methodes agile
 
Introduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jourIntroduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jour
 
Scrum Guide
Scrum GuideScrum Guide
Scrum Guide
 
La Gestion de Projet Agile
La Gestion de Projet AgileLa Gestion de Projet Agile
La Gestion de Projet Agile
 
Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Les pratiques Scrum
 
Introduction aux méthodes agiles
Introduction aux méthodes agilesIntroduction aux méthodes agiles
Introduction aux méthodes agiles
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slides
 
La gestion de projet agile
La gestion de projet agileLa gestion de projet agile
La gestion de projet agile
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
 
Présentation scrum pour cours leeaarn
Présentation scrum pour cours leeaarnPrésentation scrum pour cours leeaarn
Présentation scrum pour cours leeaarn
 
Method XP
Method XP Method XP
Method XP
 
Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
 
Scrum
ScrumScrum
Scrum
 
La méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdfLa méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdf
 
20mn scrum
20mn scrum20mn scrum
20mn scrum
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master I
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
 

En vedette

Agile expliqué aux managers
Agile expliqué aux managersAgile expliqué aux managers
Agile expliqué aux managers
Pyxis Technologies
 
Scrum : from basic to scaling
Scrum : from basic to scalingScrum : from basic to scaling
Scrum : from basic to scaling
antony_guilloteau
 
10 Years of My Scrum Experience
10 Years of My Scrum Experience10 Years of My Scrum Experience
10 Years of My Scrum Experience
Stephan Schmidt
 
Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...
Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...
Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...
François Bachmann
 
Relation client-fournisseur
Relation client-fournisseurRelation client-fournisseur
Relation client-fournisseur
Christophe Keromen
 
Les risques associés aux transitions agile scrum breakfast
Les risques associés aux transitions agile   scrum breakfastLes risques associés aux transitions agile   scrum breakfast
Les risques associés aux transitions agile scrum breakfast
Yves Zieba
 
Present Continous Tense Part 2
Present Continous Tense Part 2Present Continous Tense Part 2
Present Continous Tense Part 2
Vivemo
 
Scrum is not enough
Scrum is not enoughScrum is not enough
Scrum is not enough
Christophe Keromen
 
Agile 91
Agile 91Agile 91
No scrum no win atbx 2015 v1.0
No scrum no win   atbx 2015 v1.0No scrum no win   atbx 2015 v1.0
No scrum no win atbx 2015 v1.0
Olivier Patou
 
Ecrire de bonnes user stories - en 5 minutes - scrum wine v1.0
Ecrire de bonnes user stories - en 5 minutes -  scrum wine v1.0Ecrire de bonnes user stories - en 5 minutes -  scrum wine v1.0
Ecrire de bonnes user stories - en 5 minutes - scrum wine v1.0
Olivier Patou
 
Lync - Conduite du changement
Lync - Conduite du changementLync - Conduite du changement
Lync - Conduite du changement
Microsoft Décideurs IT
 
Le Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand DourLe Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand Dour
Xavier Warzee
 
Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...
Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...
Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...
Jean-François Palmier
 
Carla bruni et sarkozy
Carla bruni et sarkozyCarla bruni et sarkozy
Carla bruni et sarkozy
rociosito
 
Proxu Product Owner - Enrichit ou dénature Scrum
Proxu Product Owner - Enrichit ou dénature ScrumProxu Product Owner - Enrichit ou dénature Scrum
Proxu Product Owner - Enrichit ou dénature Scrum
French Scrum User Group
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Sébastien Bourguignon
 
E-Commerce et cross canal
E-Commerce et cross canalE-Commerce et cross canal
E-Commerce et cross canal
Fabien Gasser
 
Les Rôles du Scrum Product Owner
Les Rôles du Scrum Product OwnerLes Rôles du Scrum Product Owner
Les Rôles du Scrum Product Owner
Fabrice Aimetti
 
Introduction à l'agilité
Introduction à l'agilitéIntroduction à l'agilité
Introduction à l'agilité
Romain Vignes
 

En vedette (20)

Agile expliqué aux managers
Agile expliqué aux managersAgile expliqué aux managers
Agile expliqué aux managers
 
Scrum : from basic to scaling
Scrum : from basic to scalingScrum : from basic to scaling
Scrum : from basic to scaling
 
10 Years of My Scrum Experience
10 Years of My Scrum Experience10 Years of My Scrum Experience
10 Years of My Scrum Experience
 
Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...
Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...
Mythes, légendes et monstres: Obstacles sur le chemin vers le Graal de l'Entr...
 
Relation client-fournisseur
Relation client-fournisseurRelation client-fournisseur
Relation client-fournisseur
 
Les risques associés aux transitions agile scrum breakfast
Les risques associés aux transitions agile   scrum breakfastLes risques associés aux transitions agile   scrum breakfast
Les risques associés aux transitions agile scrum breakfast
 
Present Continous Tense Part 2
Present Continous Tense Part 2Present Continous Tense Part 2
Present Continous Tense Part 2
 
Scrum is not enough
Scrum is not enoughScrum is not enough
Scrum is not enough
 
Agile 91
Agile 91Agile 91
Agile 91
 
No scrum no win atbx 2015 v1.0
No scrum no win   atbx 2015 v1.0No scrum no win   atbx 2015 v1.0
No scrum no win atbx 2015 v1.0
 
Ecrire de bonnes user stories - en 5 minutes - scrum wine v1.0
Ecrire de bonnes user stories - en 5 minutes -  scrum wine v1.0Ecrire de bonnes user stories - en 5 minutes -  scrum wine v1.0
Ecrire de bonnes user stories - en 5 minutes - scrum wine v1.0
 
Lync - Conduite du changement
Lync - Conduite du changementLync - Conduite du changement
Lync - Conduite du changement
 
Le Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand DourLe Product Owner proxy, Bertrand Dour
Le Product Owner proxy, Bertrand Dour
 
Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...
Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...
Comment nous sommes devenus plus Agile - De l’implémentation de Scrum dans un...
 
Carla bruni et sarkozy
Carla bruni et sarkozyCarla bruni et sarkozy
Carla bruni et sarkozy
 
Proxu Product Owner - Enrichit ou dénature Scrum
Proxu Product Owner - Enrichit ou dénature ScrumProxu Product Owner - Enrichit ou dénature Scrum
Proxu Product Owner - Enrichit ou dénature Scrum
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI ! v2
 
E-Commerce et cross canal
E-Commerce et cross canalE-Commerce et cross canal
E-Commerce et cross canal
 
Les Rôles du Scrum Product Owner
Les Rôles du Scrum Product OwnerLes Rôles du Scrum Product Owner
Les Rôles du Scrum Product Owner
 
Introduction à l'agilité
Introduction à l'agilitéIntroduction à l'agilité
Introduction à l'agilité
 

Similaire à Impacts de l'adoption de Scrum

Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
Dominic Danis
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
Pyxis Technologies
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
guestaaee88d
 
Adoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défisAdoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défis
Pyxis Technologies
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Pyxis Technologies
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
agnes_crepet
 
Management agile des projets
Management agile des projetsManagement agile des projets
Management agile des projets
Jean-François Jagodzinski
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
agnes_crepet
 
Webinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilitéWebinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilité
AdrienMusserotte1
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques Agiles
Eric Le Merdy
 
Psp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 FrPsp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 Fr
Frederick Lussier
 
Agilite Scrum
Agilite Scrum Agilite Scrum
Agilite Scrum
Skander Hamza
 
Meetup #3 tout ce que vous avez toujours voulu savoir sur safe - presentat...
Meetup #3    tout ce que vous avez toujours voulu savoir sur safe - presentat...Meetup #3    tout ce que vous avez toujours voulu savoir sur safe - presentat...
Meetup #3 tout ce que vous avez toujours voulu savoir sur safe - presentat...
Pierre Medina
 
lean development
lean developmentlean development
lean development
Rima Jamli Faidi
 
Méthodes agiles j certif Abidjan
Méthodes agiles j certif AbidjanMéthodes agiles j certif Abidjan
Méthodes agiles j certif Abidjan
Henri-Damien LAURENT
 
Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...
Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...
Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...
Microsoft Ideas
 
Le scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheurLe scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheur
sebastien_fournel
 
Presentation Kantree et Méthodologies
Presentation Kantree et MéthodologiesPresentation Kantree et Méthodologies
Presentation Kantree et Méthodologies
Maxime Bouroumeau-Fuseau
 
Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
agnes_crepet
 
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise AgileBrochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
OCTO Technology Suisse
 

Similaire à Impacts de l'adoption de Scrum (20)

Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
 
Adoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défisAdoption de l'Agilité : principes et défis
Adoption de l'Agilité : principes et défis
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Management agile des projets
Management agile des projetsManagement agile des projets
Management agile des projets
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
 
Webinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilitéWebinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilité
 
Lean Software Development et pratiques Agiles
Lean Software Development et pratiques AgilesLean Software Development et pratiques Agiles
Lean Software Development et pratiques Agiles
 
Psp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 FrPsp Tsp Agile 3 1 Fr
Psp Tsp Agile 3 1 Fr
 
Agilite Scrum
Agilite Scrum Agilite Scrum
Agilite Scrum
 
Meetup #3 tout ce que vous avez toujours voulu savoir sur safe - presentat...
Meetup #3    tout ce que vous avez toujours voulu savoir sur safe - presentat...Meetup #3    tout ce que vous avez toujours voulu savoir sur safe - presentat...
Meetup #3 tout ce que vous avez toujours voulu savoir sur safe - presentat...
 
lean development
lean developmentlean development
lean development
 
Méthodes agiles j certif Abidjan
Méthodes agiles j certif AbidjanMéthodes agiles j certif Abidjan
Méthodes agiles j certif Abidjan
 
Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...
Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...
Plus vite et plus de valeur : plus d'agilité pour vos développements d'applic...
 
Le scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheurLe scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheur
 
Presentation Kantree et Méthodologies
Presentation Kantree et MéthodologiesPresentation Kantree et Méthodologies
Presentation Kantree et Méthodologies
 
Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
 
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise AgileBrochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
 

Plus de Pyxis Technologies

Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pyxis Technologies
 
Sorry, the new Champlain Bridge can’t be built using Agile...
Sorry, the new Champlain Bridge can’t be built using Agile...Sorry, the new Champlain Bridge can’t be built using Agile...
Sorry, the new Champlain Bridge can’t be built using Agile...
Pyxis Technologies
 
Développer votre logiciel interne : comment y parvenir sans investir une fort...
Développer votre logiciel interne : comment y parvenir sans investir une fort...Développer votre logiciel interne : comment y parvenir sans investir une fort...
Développer votre logiciel interne : comment y parvenir sans investir une fort...
Pyxis Technologies
 
Agilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernanceAgilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernance
Pyxis Technologies
 
La gestion de portefeuille Agile - c'est pas compliqué!
La gestion de portefeuille Agile - c'est pas compliqué! La gestion de portefeuille Agile - c'est pas compliqué!
La gestion de portefeuille Agile - c'est pas compliqué!
Pyxis Technologies
 
Introduction à Agile Lean
Introduction à Agile LeanIntroduction à Agile Lean
Introduction à Agile Lean
Pyxis Technologies
 
La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...
La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...
La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...
Pyxis Technologies
 
Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve
Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve
Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve
Pyxis Technologies
 
Estimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu BoisvertEstimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu Boisvert
Pyxis Technologies
 
Les attitudes doxiques dans les équipes et le syndrome du Titanic!
Les attitudes doxiques dans les équipes et le syndrome du Titanic!Les attitudes doxiques dans les équipes et le syndrome du Titanic!
Les attitudes doxiques dans les équipes et le syndrome du Titanic!
Pyxis Technologies
 
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projetsLa valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
Pyxis Technologies
 
Le rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu BoisvertLe rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu Boisvert
Pyxis Technologies
 
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Agilité et la gestion du changement   mboisvert - 15 octobre 2013Agilité et la gestion du changement   mboisvert - 15 octobre 2013
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Pyxis Technologies
 
Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?
Pyxis Technologies
 
La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...
La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...
La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...
Pyxis Technologies
 
Choisir ses priorités: le développement incrémental de produit
Choisir ses priorités: le développement incrémental de produitChoisir ses priorités: le développement incrémental de produit
Choisir ses priorités: le développement incrémental de produit
Pyxis Technologies
 
Apprendre pour la performance et le bien-être
Apprendre pour la performance et le bien-êtreApprendre pour la performance et le bien-être
Apprendre pour la performance et le bien-être
Pyxis Technologies
 
L'agilité : de l'individu à l'organisation en passant par l'équipe
L'agilité : de l'individu à l'organisation en passant par l'équipeL'agilité : de l'individu à l'organisation en passant par l'équipe
L'agilité : de l'individu à l'organisation en passant par l'équipe
Pyxis Technologies
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
Pyxis Technologies
 

Plus de Pyxis Technologies (20)

Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
 
Sorry, the new Champlain Bridge can’t be built using Agile...
Sorry, the new Champlain Bridge can’t be built using Agile...Sorry, the new Champlain Bridge can’t be built using Agile...
Sorry, the new Champlain Bridge can’t be built using Agile...
 
Développer votre logiciel interne : comment y parvenir sans investir une fort...
Développer votre logiciel interne : comment y parvenir sans investir une fort...Développer votre logiciel interne : comment y parvenir sans investir une fort...
Développer votre logiciel interne : comment y parvenir sans investir une fort...
 
Agilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernanceAgilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernance
 
La gestion de portefeuille Agile - c'est pas compliqué!
La gestion de portefeuille Agile - c'est pas compliqué! La gestion de portefeuille Agile - c'est pas compliqué!
La gestion de portefeuille Agile - c'est pas compliqué!
 
Introduction à Agile Lean
Introduction à Agile LeanIntroduction à Agile Lean
Introduction à Agile Lean
 
La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...
La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...
La valeur d'affaires comme indicateur de la gestion de projet - IIBA Montréal...
 
Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve
Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve
Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve
 
Estimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu BoisvertEstimation initiale dun projet agile de Mathieu Boisvert
Estimation initiale dun projet agile de Mathieu Boisvert
 
Les attitudes doxiques dans les équipes et le syndrome du Titanic!
Les attitudes doxiques dans les équipes et le syndrome du Titanic!Les attitudes doxiques dans les équipes et le syndrome du Titanic!
Les attitudes doxiques dans les équipes et le syndrome du Titanic!
 
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projetsLa valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
 
Danser avec les polarités
Danser avec les polaritésDanser avec les polarités
Danser avec les polarités
 
Le rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu BoisvertLe rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu Boisvert
 
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Agilité et la gestion du changement   mboisvert - 15 octobre 2013Agilité et la gestion du changement   mboisvert - 15 octobre 2013
Agilité et la gestion du changement mboisvert - 15 octobre 2013
 
Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?
 
La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...
La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...
La revue d'itération intégrée… Et autres fabuleuses pratiques Agiles adaptées...
 
Choisir ses priorités: le développement incrémental de produit
Choisir ses priorités: le développement incrémental de produitChoisir ses priorités: le développement incrémental de produit
Choisir ses priorités: le développement incrémental de produit
 
Apprendre pour la performance et le bien-être
Apprendre pour la performance et le bien-êtreApprendre pour la performance et le bien-être
Apprendre pour la performance et le bien-être
 
L'agilité : de l'individu à l'organisation en passant par l'équipe
L'agilité : de l'individu à l'organisation en passant par l'équipeL'agilité : de l'individu à l'organisation en passant par l'équipe
L'agilité : de l'individu à l'organisation en passant par l'équipe
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
 

Impacts de l'adoption de Scrum

  • 1. L'adoption de Scrum : Défis et retour d'expérience
  • 2. Sondage à main levée Utilisez-vous une approche Agile dans votre organisation?
  • 3. Déroulement Historique, valeurs et principes Pratiques Agiles : impacts et défis Transition vers l’Agilité Questions
  • 4. 1945 à 1965 – Les débuts 1965 à 1985 – La crise Années 80 et 90 – On veut passer de l’artisanat à l’ingénierie logicielle, on cherche le silver bullet Fin des années 90 – On commence à utiliser des méthodes dites légères Septembre 2000 – Pyxis est née Février 2001 – Le manifeste Agile Septembre 2002 – Le groupe d’utilisateurs Agile de Montréal est créé 2003 – 2005 – On cherche à convaincre 2006 – On s’intéresse de plus en plus à l’Agilité 2007 – Le nombre de participants à la conférence Agile double pour une troisième année consécutive 2008 – On en parle trop? Un peu d’histoire
  • 5. Nous découvrons de meilleures manières de développer des logiciels en aidant les autres et en en développant nous-mêmes. Par ce travail, nous en sommes venus à valoriser ce qui suit : les individus et les interactions davantage que les processus et les outils; les logiciels fonctionnels davantage que la documentation exhaustive; la collaboration avec le client davantage que la négociation de contrat; l’ouverture au changement davantage que le suivi d’un plan. En fait, bien que les éléments de droite soient importants, nous considérons que les éléments de gauche le sont encore plus. Manifeste pour le développement Agile de logiciel
  • 6. Principes Agiles (un sous-ensemble) ‏ La priorité est de satisfaire le client par la livraison rapide et continue de solutions logicielles utiles. Il faut intégrer les changements , même ceux de dernière minute, car ils offriront un avantage compétitif à votre client. Il faut élaborer des projets autour d’individus motivés . Il faut leur fournir le soutien nécessaire et leur faire confiance. Les meilleures solutions émergent des équipes autoorganisées . 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. Il faut porter une attention continue à l’excellence technique; un bon design améliore l’Agilité. La simplicité  est essentielle.
  • 8. Nos projets sont-ils des succès? 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é.
  • 9. Gaspillons-nous nos investissements? Jim Johnson, Standish Group, XP 2002
  • 10. Peut-on livrer plus rapidement? d'après les travaux d'Hakan Herdogmus, GUAM 2005
  • 11. Que faire face à la complexité? La dimension humaine ajoute un autre niveau de complexité. Le dernier projet simple date de 1969. Complexité des projets Strategic Management and Organisational Dynamics: The Challenge of Complexity Ralph D. Stacey
  • 12. 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?
  • 13. Pratiques Agiles et leurs impacts
  • 14. Principes vs pratiques Principe Vérité qui ne change pas dans le temps ou l’espace Pratique Application d’un principe à une situation particulière La compréhension des principes est essentielle pour en réussir l’implantation par un ensemble de pratiques
  • 15. Processus empirique Lorsque la complexité croît , les systèmes de gestion et de contrôle centralisés montrent leurs limites. La solution est d'établir un ensemble de règles simples et de laisser l'application de ces règles à des agents indépendants. Un processus empirique utilise l’inspection et une adaptation subséquente afin d’optimiser l’atteinte des buts. L’inspection et l’adaptation nécessitent la transparence . La transparence nécessite du courage et des changements au niveau des systèmes de récompense.
  • 16. Processus empirique : le squelette de Scrum
  • 17. Itération : le sprint
  • 18. Démarrage d’un projet Agile Portée et limites du projet Vision du produit Plan de livraison
  • 19. Mise en production d’un projet Agile
  • 20. Impacts et défis La mise en place d’un processus empirique est plutôt simple sauf que… Pièges à éviter Récupération de tous les requis avant de commencer à « sprinter » Itérations trop longues Mêlée quotidienne inefficace Rétrospectives inefficaces Impacts possibles Le fait de démarrer rapidement = chèque en blanc ? Je dois parler de mes obstacles devant tous le monde ? Qu’arrivera-t-il si on est pas prêt pour la démo ? Une journée de planification par 3 semaines, ce n’est pas trop ?
  • 21. 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écoule les 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écoule les estimations relatives aux fonctionnnalités.
  • 22. 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)
  • 23. 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.
  • 24. Suivi de l’avancement La courbe du travail restant à faire permet de déterminer la date probable de livraison
  • 25. Impacts et défis Mettre la valeur d’affaires du logiciel à l’avant-plan ça semble logique sauf que… Pièges à éviter Avoir un responsable de produit non imputable Négliger la maintenance du carnet du produit Analyser trop rapidement les exigences non prioritaires Ne pas établir les conditions de succès liés à chaque exigence Impacts possibles Peut-on clairement identifier un responsable de produit? Ça veut dire quoi pour nos analystes d’affaires ? Que fait-on des demandes de changement? Qu’est-ce qu’on fait avec notre gabarit pour la documentation fonctionnelle ? Ça veut dire quoi pour mes mesures ( metrics ) de suivi ?
  • 26. Comment faire du développement incrémental?
  • 27. La prévisibilité de Scrum C’est un processus prévisible , ce qui aide à prendre des décisions éclairées. La date est fixée. Quelles sont les caractéristiques à livrer? Une livraison de qualité production doit avoir lieu à la fin de chaque sprint.
  • 28. Étendre la définition de ‘terminé’
  • 29. Ingénierie Agile Une attention continue à l’excellence technique améliore l’Agilité. La majorité des pratiques d’ingénierie Agiles proviennent de XP . Conception pilotée par les tests, intégration continue, programmation en binôme, remaniement du code ( refactoring ) ,… Faites la conception et les tests tout au long du projet... Il faut garder un œil sur le futur tout en retardant nos décisions le plus longtemps possible. (« You ain’t gonna need it! » - YAGNI) Développez les compétences requises. Augmentez vos connaissances techniques. On pense à tort que les programmeurs Agiles sont des ‘cowboys’ .
  • 30. Impacts et défis Construire un logiciel de façon incrémentale peut représenter tout un défi ! Pièges à éviter Établir une grosse architecture tôt dans le projet Créer de l’ inventaire (trop de code pour nos besoins présents) Accumuler une dette technique (négliger le remaniement de code, code non testé) Ne pas exécuter régulièrement la suite de tests automatisés Impacts possibles Qu’arrivera-t-il des architectes ? Que vont penser les gestionnaires du coût associé aux tests unitaires et au remaniement de code? Pourra-t-on déployer le résultat des itérations?
  • 31. Équipe Scrum Une équipe Scrum comprend uniquement les personnes suivantes : des développeurs (pluridisciplinaires), un responsable de produit et un ScrumMaster.
  • 32. ONE TEAM!!!! L’équipe provient des organisations coopératives. La composition des équipes n’est pas limitée aux titres (généralistes-spécialistes). Les communications sont fluides. Le responsable de produit est à l’avant-plan. Équipe de développement Équipe de gestion de produit Analyste d’affaires Utilisateurs Développeurs Chef de produit Représentant ou agent de commercialisation Architecte Responsable des tests Administrateur de bases de données Direction ScrumMaster Gestionnaire de produit
  • 33. Équipe de développement Comprend de 6 à 10 membres Idéalement est colocalisée Comprend l’ensemble de l’expertise nécessaire pour réaliser le projet Choisit le but de l’itération et spécifie les résultats à produire A la latitude voulue pour déterminer ce qui doit être fait afin d’atteindre le but fixé pour l’itération sans enfreindre les directives du projet S’organise de façon autonome et planifie ses propres travaux Présente des résultats de qualité au responsable de produit Communique son avancement et ses obstacles de façon transparente
  • 34. ScrumMaster : un leader et un facilitateur À titre de ScrumMaster, vous êtes responsable de ce qui suit : Éliminer les barrières entre l’équipe de développement et le client pour permettre à ce dernier d’orienter directement les travaux de développement Montrer au client comment maximiser le taux de rendement des investissements et atteindre ses objectifs au moyen de Scrum Améliorer le quotidien de l’équipe de développement en mettant l’accent sur la créativité et la gestion autonome des membres Accroître la productivité de l’équipe de développement par tous les moyens imaginables Améliorer les outils et les pratiques d’ingénierie de manière à ce que chaque incrément de fonctionnalité puisse être livré au client
  • 36. Impacts et défis Obtenir le bon niveau d’engagement de tous est essentiel à la création d’une véritable équipe performante Pièges à éviter Se rapporter au ScrumMaster lors de la mêlée quotidienne Avoir un ScrumMaster qui assigne lui-même les tâches Ne pas adapter son style de leadership à la maturité de l’équipe Avoir l’attitude « moi j’ai fini » Impacts possibles Comment intégrer les spécialistes aux équipes Scrum? Les gestionnaires sauront-ils faire confiance à l’équipe? L’équipe saura-t-elle s’approprier son Scrum ? Quels sont les impacts sur le système de rémunération ? Quels sont les impacts sur notre processus d’ embauche ?
  • 38. Des questions importantes Nos organisations sont-elles prêtes à changer? … et les individus eux?
  • 39. Analyse d’impact Impacts sur l’organisation Structure organisationnelle Système de rémunération Relation avec les clients et les fournisseurs Impacts sur le processus Pilotage des projets Flux du travail Flux d’information Impacts sur les technologies Nouveaux outils pour soutenir les pratiques XP Impacts physiques Configuration des locaux
  • 40. Analyse d’impact Impacts sur les individus Nouveaux rôles, nouvelles tâches Pertes de pouvoir Compétences Mentalité, façon de penser, valeurs, attitudes Motivation et engagement
  • 41. Quels sont les changements requis
  • 42. Autres éléments à considérer Avoir une forme contractuelle qui reconnaît qu’il n’est pas optimal (désiré) de chercher à connaître précisément l’ensemble des exigences au départ Mettre en place des processus qui conservent un niveau de gouvernance adéquat , mais qui permettent les changements rapides Avoir une forme documentaire simplifiée qui permette l’évolutivité de la documentation Créer une culture de collaboration
  • 43. En haut….. En bas! Mode descendant Les leaders de haut niveau partagent une vision quant à l’utilisation de Scrum. Mode ascendant Quelques équipes commencent à utiliser Scrum. Les gens voient les avantages de cette nouvelle approche et décident de l’adopter. Pour assurer le succès, le changement doit se faire à la fois de bas en haut et de haut en bas , simultanément.
  • 44. Le passage à une approche Agile ne se fait pas du jour au lendemain La période de transition sera longue et parfois délicate (inconfortable) avant que tous les intervenants des projets adoptent une approche axée sur la collaboration et l’autonomie.
  • 46. Approche pour le passage à l’Agilité
  • 48. C’est possible! 9 livraisons en 6 mois!
  • 49. Conclusion Le capital humain est votre plus gros actif. L’adoption d’une approche Agile demande des changements significatifs, et la nature des préoccupations des gens doit changer. Tout changement nécessite du temps, du courage et de la persévérance.