Your SlideShare is downloading. ×
0
L'adoption de Scrum : Défis et retour d'expérience
Sondage à main levée <ul><li>Utilisez-vous une approche Agile  </li></ul><ul><li>dans votre organisation? </li></ul>
Déroulement <ul><li>Historique, valeurs et principes </li></ul><ul><li>Pratiques Agiles : impacts et défis </li></ul><ul><...
<ul><li>1945 à 1965 – Les débuts </li></ul><ul><li>1965 à 1985 – La crise </li></ul><ul><li>Années 80 et 90 – On veut pass...
<ul><li>Nous découvrons de meilleures manières de développer des logiciels en aidant les autres et en en développant nous-...
Principes Agiles (un sous-ensemble) ‏ <ul><li>La priorité est de satisfaire le client par la  livraison rapide  et  contin...
<ul><li>Pourquoi Agile? </li></ul>
Nos projets sont-ils des succès? CHAOS Report  du Standish Group, 2003  Succès :   Le projet est réalisé selon le budget e...
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é? <ul><li>La dimension humaine ajoute un autre niveau de complexité.  </li></ul><ul><li>Le d...
Problèmes de communication? <ul><li>Le développement logiciel est un  jeu coopératif  d’invention et de communication. Il ...
Pratiques Agiles et leurs impacts
Principes vs pratiques <ul><li>Principe </li></ul><ul><ul><li>Vérité qui  ne change pas  dans le temps ou l’espace </li></...
Processus empirique <ul><li>Lorsque la  complexité croît , les systèmes de gestion et de contrôle centralisés montrent leu...
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 <ul><li>La mise en place d’un processus empirique est  plutôt simple  sauf que… </li></ul><ul><li>Pièges ...
La valeur d’affaires au premier plan Contraintes Estimations S'appuie sur le  plan  Coût   Calendrier  Exigences Contraint...
Responsable de produit ( product owner ) <ul><li>Un bon responsable de produit doit : </li></ul><ul><ul><li>Connaître la  ...
Gestion des exigences : le carnet du produit Chaque itération met en œuvre les exigences  prioritaires . Chaque nouvelle e...
Suivi de l’avancement <ul><li>La courbe du travail restant à faire permet de déterminer la date probable de livraison </li...
Impacts et défis <ul><li>Mettre la valeur d’affaires du logiciel à l’avant-plan ça semble logique  sauf que… </li></ul><ul...
Comment faire du développement incrémental?
La prévisibilité de Scrum <ul><li>C’est un processus  prévisible , ce qui aide à prendre des décisions éclairées.  </li></...
Étendre la définition de  ‘terminé’
Ingénierie Agile <ul><li>Une attention continue à  l’excellence technique  améliore l’Agilité. </li></ul><ul><li>La majori...
Impacts et défis <ul><li>Construire un logiciel de façon incrémentale peut représenter  tout un défi ! </li></ul><ul><li>P...
Équipe Scrum <ul><li>Une équipe Scrum comprend uniquement les personnes suivantes : des développeurs (pluridisciplinaires)...
ONE TEAM!!!! <ul><li>L’équipe provient des organisations coopératives. </li></ul><ul><li>La composition des équipes n’est ...
Équipe de développement <ul><li>Comprend de  6 à 10 membres </li></ul><ul><li>Idéalement est  colocalisée </li></ul><ul><l...
ScrumMaster :  un leader et un facilitateur <ul><li>À titre de ScrumMaster, vous êtes responsable de ce qui suit : </li></...
Faites confiance aux gens!
Impacts et défis <ul><li>Obtenir le bon niveau d’engagement de tous est essentiel à la création d’une véritable  équipe pe...
Transition vers l’Agilité
Des questions importantes Nos organisations sont-elles prêtes à changer? …  et les individus eux?
Analyse d’impact <ul><li>Impacts sur l’organisation </li></ul><ul><ul><li>Structure organisationnelle </li></ul></ul><ul><...
Analyse d’impact <ul><li>Impacts sur les individus </li></ul><ul><ul><li>Nouveaux rôles, nouvelles tâches </li></ul></ul><...
Quels sont les changements requis
Autres éléments à considérer <ul><li>Avoir une  forme contractuelle  qui reconnaît qu’il n’est pas optimal (désiré) de che...
En haut….. En bas! <ul><li>Mode descendant  </li></ul><ul><ul><li>Les leaders de haut niveau partagent une vision quant à ...
Le passage à une approche Agile  ne se fait pas du jour au lendemain  <ul><li>La période de transition sera longue et parf...
Gestion du changement
Approche pour le passage à l’Agilité
C’est possible! Transparence!
C’est possible! 9 livraisons en 6 mois!
Conclusion <ul><li>Le capital humain est votre plus gros actif. </li></ul><ul><li>L’adoption d’une approche Agile demande ...
Courage et persévérance
<ul><li>Merci! </li></ul><ul><li>Des questions? </li></ul>
Upcoming SlideShare
Loading in...5
×

Impacts de l'adoption de Scrum

2,488

Published on

L'adoption de Scrum : défis et retours d'expérience

Présenté le 11 février 2009 à une midi-conférence du CRIM à Montréal

Published in: Business, Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,488
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
210
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Impacts de l'adoption de Scrum"

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

    Clipping is a handy way to collect important slides you want to go back to later.

×