Impacts de l'adoption de Scrum

  • View
    2.393

  • Download
    0

Embed Size (px)

DESCRIPTION

L'adoption de Scrum : défis et retours d'expériencePrésenté le 11 février 2009 à une midi-conférence du CRIM à Montréal

Text of Impacts de l'adoption de Scrum

  • 1. L'adoption de Scrum : Dfis et retour d'exprience
  • 2. Sondage main leve
    • Utilisez-vous une approche Agile
    • dans votre organisation?
  • 3. Droulement
    • Historique, valeurs et principes
    • Pratiques Agiles : impacts et dfis
    • Transition vers lAgilit
    • Questions
  • 4.
    • 1945 1965 Les dbuts
    • 1965 1985 La crise
    • Annes 80 et 90 On veut passer de lartisanat lingnierie logicielle, on cherche le silver bullet
    • Fin des annes 90 On commence utiliser des mthodes dites lgres
    • Septembre 2000 Pyxis est ne
    • Fvrier 2001 Le manifeste Agile
    • Septembre 2002 Le groupe dutilisateurs Agile de Montral est cr
    • 2003 2005 On cherche convaincre
    • 2006 On sintresse de plus en plus lAgilit
    • 2007 Le nombre de participants la confrence Agile double pour une troisime anne conscutive
    • 2008 On en parle trop?
    Un peu dhistoire
  • 5.
    • Nous dcouvrons de meilleures manires de dvelopper des logiciels en aidant les autres et en en dveloppant nous-mmes.
    • 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 ngociation de contrat;
      • louverture au changement davantage que le suivi dun plan.
    • En fait, bien que les lments de droite soient importants, nous considrons que les lments de gauche le sont encore plus.
    Manifeste pour le dveloppement 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 intgrer les changements , mme ceux de dernire minute, car ils offriront un avantage comptitif votre client.
    • Il faut laborer des projets autour dindividus motivs . Il faut leur fournir le soutien ncessaire et leur faire confiance.
    • Les meilleures solutions mergent des quipes autoorganises .
    • Rgulirement, lquipe fait une rflexion sur les faons de devenir plus efficace , sajuste et modifie son comportement en consquence.
    • Il faut porter une attention continue lexcellence technique; un bon design amliore lAgilit.
    • La simplicit est essentielle.
  • 7.
    • Pourquoi Agile?
  • 8. Nos projets sont-ils des succs? CHAOS Report du Standish Group, 2003 Succs : Le projet est ralis selon le budget et les dlais convenus. Il comporte les fonctions et caractristiques demandes. Dfi : Le projet est en retard, le budget a t dpass ou il manque certaines fonctions et caractristiques demandes. chec : Le projet a t arrt avant sa fin ou le logiciel dvelopp a t livr mais na jamais t utilis.
  • 9. Gaspillons-nous nos investissements? Jim Johnson, Standish Group, XP 2002
  • 10. Peut-on livrer plus rapidement? d'aprs 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. Problmes de communication?
    • Le dveloppement logiciel est un jeu coopratif dinvention et de communication. Il est apparent au dveloppement de produit.
    • Les sources de problme dans notre profession sont les gens et les interactions dysfonctionnelles plutt que les processus et les outils.
    Comment communiquez-vous?
  • 13. Pratiques Agiles et leurs impacts
  • 14. Principes vs pratiques
    • Principe
      • Vrit qui ne change pas dans le temps ou lespace
    • Pratique
      • Application dun principe une situation particulire
    • La comprhension des principes est essentielle pour en russir limplantation par un ensemble de pratiques
  • 15. Processus empirique
    • Lorsque la complexit crot , les systmes de gestion et de contrle centraliss montrent leurs limites. La solution est d'tablir un ensemble de rgles simples et de laisser l'application de ces rgles des agents indpendants.
    • Un processus empirique utilise linspection et une adaptation subsquente afin doptimiser latteinte des buts.
    • Linspection et ladaptation ncessitent la transparence .
    • La transparence ncessite du courage et des changements au niveau des systmes de rcompense.
  • 16. Processus empirique : le squelette de Scrum
  • 17. Itration : le sprint
  • 18. Dmarrage dun projet Agile Porte et limites du projet Vision du produit Plan de livraison
  • 19. Mise en production dun projet Agile
  • 20. Impacts et dfis
    • La mise en place dun processus empirique est plutt simple sauf que
    • Piges viter
      • Rcupration de tous les requis avant de commencer sprinter
      • Itrations trop longues
      • Mle quotidienne inefficace
      • Rtrospectives inefficaces
    • Impacts possibles
      • Le fait de dmarrer rapidement = chque en blanc ?
      • Je dois parler de mes obstacles devant tous le monde ?
      • Quarrivera-t-il si on est pas prt pour la dmo ?
      • Une journe de planification par 3 semaines, ce nest pas trop ?
  • 21. La valeur daffaires au premier plan Contraintes Estimations S'appuie sur le plan Cot Calendrier Exigences Contraintes Estimation Processus en cascade Du plan dcoule les estimations relatives au cot et au calendrier. S'appuie sur la valeur ou vision Cot Calendrier Fonctionnalits Processus Scrum De la vision dcoule les estimations relatives aux fonctionnnalits.
  • 22. Responsable de produit ( product owner )
    • Un bon responsable de produit doit :
      • Connatre la valeur commerciale du produit
      • Avoir le pouvoir de runir des intrts et dsirs varis
      • tre disponible
      • Diriger une quipe de gestion de produit
    • Ses responsabilits sont :
      • Communiquer la vision
      • Sapproprier