Communaute dot net Montreal juin2010
Upcoming SlideShare
Loading in...5
×
 

Communaute dot net Montreal juin2010

on

  • 947 views

 

Statistics

Views

Total Views
947
Views on SlideShare
946
Embed Views
1

Actions

Likes
0
Downloads
11
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Dans le contexte d’une transition organisationnelle vers l’agilité, il est important que l’organisation est une vraie raison « business » de se lancer dans l’agilité ! Pas juste pour être dans le vent !!!
  • il faut redonner une fierté à notre profession Contrer l’outsourcing en étant plus productif Déjà une amélioration vs le rapport de 1994 (16% success, 53%, challenged, 31% echec)
  • Feature usage within deployed applications: Pourcentage d’utilisation des fonctions des applications déployées Never: Jamais 45 % Always: Toujours 7 % Often: Souvent 13 % Sometimes: Parfois 16 % Rarely: Rarement 19 % NE PAS OUBLIER DE METTRE UN ESPACE ENTRE LE NOMBRE ET LE SYMBOLE DE POURCENTAGE (%)
  • Take time to review the 3 parts No silver bullet (part 1) Practice (part 1) Discuss the balance Review the 13 Principles (not shown here)
  • DSDM (Dynamic Solutions Delivery Model) Formalization of RAD practices 3 timeboxed iteration models FDD Develop an overall model Build a feature lists Plan by feature Design by feature Build by feature
  • Piloter un projet au quotidien en fonction des fonctionnalités ca veut dire quoi pour une organisation??
  • Dans le contexte d’une transition organisationnelle vers l’agilité, il est important que l’organisation est une vraie raison « business » de se lancer dans l’agilité ! Pas juste pour être dans le vent !!!
  • Dans le contexte d’une transition organisationnelle vers l’agilité, il est important que l’organisation est une vraie raison « business » de se lancer dans l’agilité ! Pas juste pour être dans le vent !!!
  • Dans le contexte d’une transition organisationnelle vers l’agilité, il est important que l’organisation est une vraie raison « business » de se lancer dans l’agilité ! Pas juste pour être dans le vent !!!

Communaute dot net Montreal juin2010 Communaute dot net Montreal juin2010 Presentation Transcript

  • 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_address]
  • 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é?
  • Nos solutions sont-elles utiles? Statistiques de l’industrie Jim Johnson, Standish Group, XP 2002
  • 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?
    • Pour satisfaire rapidement notre client avec des solutions logicielles utiles
    • Pour augmenter la qualité
    • Pour faire face à la complexité
    • Pour réduire les inefficacités
    • Pour éviter les longues périodes de stabilisation en fin de projet
    • Pour maximiser la collaboration
    • Pour augmenter la motivation et l’engagement des individus
    • 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)
    • Notre première priorité est de satisfaire le client en livrant tôt et régulièrement du logiciel utile
    • Le changement est bienvenu, même tardivement dans le développement. Les processus Agiles exploitent le changement comme avantage compétitif pour le client
    • Le logiciel fonctionnel est la principale façon de mesurer le progrès
    • Les gens d’affaires et les développeurs doivent collaborer quotidiennement, et ce, tout au long du projet
    • La méthode la plus efficace de transmettre l’information est une conversation face-à-face
  • Principes Agiles (2 de 2)
    • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’Agilité
    • La simplicité — l’art de maximiser la quantité de travail à ne pas faire — est essentielle
    • Les meilleures architectures, spécifications et conceptions émergent d’équipes qui s’auto-organisent
    • Agile favorise le développement à un rythme normal
    • 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
    • Scrum
    • Extreme Programming (XP)
    • Adaptive Software Development
    • Crystal Clear
    • Feature Driven Development
    • Dynamic Systems Development Method (DSDM)
    • MSF for Agile Software Development
    • RUP (Agile RUP — AUP)
  • Pilier 1 Le processus empirique
  • Une question de bons sens
  • Processus empirique : le squelette de Scrum Vision
  • 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é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 fonctionnalité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.
  • Granularité des exigences Sprint courant 1-2 sprints Livraison Produit 6 mois 2-3 mois 1 mois Implantation Vision Épisodes Scénarios 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 production
    • Le travail qui n'est pas couvert pas la définition de « terminé » (travail « non terminé ») doit être identifié et porté au carnet de produit
    • Tout é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ée
    • Code remanié
    • Code révisé
    • Tests unitaires
    • Tests intégrés
    • Tests de recette
    • Tests de performance
    • Tests d'ergonomie
    • Documentation utilisateur
    • Déploiement en pré-production
    • Acceptation par les utilisateurs
  • Suivi de l’avancement
    • La courbe du travail restant à faire permet de déterminer la date probable de livraison
  • 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
  • Le Scrum Master n'est pas un chef de projet Imposer Contrôler Diriger Faire confiance Faciliter Accompagner
  • 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 :
      • Qu’ai-je fait hier?
      • Quels ont été les obstacles rencontrés?
      • 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
    • Faire de l’Agile « pour être dans le vent »
    • Faire du développement itératif et non incrémental
    • Commencer à sprinter seulement lorsque tous les besoins sont recueillis
    • Effectuer des « mini waterfall »
    • Laisser les spécialistes travailler en silo
    • Avoir un responsable de produit qui ne s’implique pas suffisamment
    • Ne pas partager une vision commune de « terminé »
    • 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