SlideShare is now on Android. 15 million presentations at your fingertips.  Get the app

×
  • Partagez
  • E-mail
  • Intégrer
  • J'aime
  • Télécharger
  • Contenu privé
 

Du Manifeste Agile à Scrum

par Architect, Agile Coach, Speaker on Sep 25, 2009

  • 5,013 vues

 

Statistiques

Vues

Total des vues
5,013
Vues sur SlideShare
4,641
Vues externes
372

Actions

J'aime
5
Téléchargements
285
Commentaires
1

7 Ajouts 372

http://www.scoop.it 261
http://www.jroller.com 33
http://blogs.msdn.com 29
http://egz.hebergratuit.com 28
http://www.slideshare.net 17
http://jroller.com 3
http://www.linkedin.com 1
Plus...

Accessibilité

Catégories

Détails de l'import

Importé via SlideShare au format Microsoft PowerPoint

Droits d'utilisation

© Tous droits réservés

Report content

Signalé comme inapproprié Signaler comme inapproprié
Signaler comme inapproprié

Select your reason for flagging this presentation as inappropriate.

Annuler

11 sur 1 précédent suivant

  • dominicdanis Dominic Danis, Director and Partner at Pyxis Technologies Merci Xavier de citer Urban Turtle.

    Juste une petite note pour te dire que GreenHopper for TFS est maintenant nommé Urban Turtle
    www.urbanturtle.net

    Nous venons juste de livrer la version 2.0 qui prend en compte les AREA VIEW de TFS.

    Dominic Danis
    ddanis@pyxis-tech.com
    Il y a 4 ans
    Êtes-vous sûr de vouloir
    Votre message apparaîtra ici
    Traitement...
Poster un commentaire
Modifier votre commentaire

Du Manifeste Agile à Scrum Du Manifeste Agile à Scrum Presentation Transcript

  • Focus sur Scrum
  • Scrum
    “The New New Product Development Game” dans Harvard Business Review, 1986.
    “… L’approche ‘course de relais’ pour le développement de produits…peut être en conflit avec les objectifs de vitesse et de flexibilité maximum. A l’inverse, une approche holistique comme au ‘rugby’— quand une équipe essaie d’avancer en restant unie, en se passant le ballon de main en main— peut mieux servir les exigences de compétitivité d’aujourd’hui.”
    WickedProblems, Righteous Solutions par DeGrace et Stahl, 1990.
    Première mention de Scrum dans le contexte logiciel
  • Scrum
    24 heures
  • Représente le management du projet
    Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum
    Son job est de faciliter la résolution des problèmes
    Le ScrumMaster
  • Généralement composée de 5 à 10 personnes
    Regroupant toutes les fonctions nécessaires au développement
    Architecte, Concepteur, Développeur, Spécialiste IHM, Testeur, etc.
    Membres de préférence à plein temps
    Exceptions possibles (Administrateur, …)
    L’équipe s’auto-gère
    Normalement pas de titre mais c’est rarement possible
    La composition ne doit changer pendant un Sprint
    L’équipe Scrum
  • Les projets Scrum progressent à travers une série de Sprints
    Equivalents aux itérations XP
    La durée d’un Sprint est de 30 jours
    +/- une semaine ou 2
    Une durée constante apporte un meilleur rythme
    Le produit est conçu, codé et testé pendant le Sprint
    Sprints
  • Exigences
    Conception
    Code
    Test
    Plutôt que de faire toute une discipline d'un coup...
    ...Les équipes Scrum font un peu de tout tout le temps
    Source : “The New New Product Development Game” par Takeuchi et Nonaka. Harvard Business Review, Janvier 1986.
    Activités séquentielles vs. parallèles
  • La durée des Sprints doit permettre de différer la prise en compte d’un changement jusqu’au prochain Sprint
    Pas de changements pendant le sprint
    Changement
    Sprint
    Code testé
    Entrées
  • La liste de toutes les exigences demandées pour le produit à réaliser
    Souvent une combinaison
    D’exigences fonctionnelles, « stories » (chercher et remplacer du texte)
    De travail lié aux exigences non fonctionnelles (améliorer la gestion des exceptions)
    La liste est priorisée par le Propriétaire du produit
    Le représentant des clients, utilisateurs, marketing, chef de produit…
    Backlog du produit
  • Exemple de Backlog du produit
  • Réunion de planification du Sprint
    Backlog du Produit
    Capacité de l’équipe
    Conditions Business
    Technologie
    Produit actuel
    Propriétaire Produit
    Equipe Scrum
    Management
    Clients
    Réunion de
    planification
    du Sprint
    But du Sprint
    Backlog du Sprint
  • La description rapide du thème majeur du Sprint
    Le but du Sprint
    Sciences de la vie
    “Fournir les fonctionnalités nécessaires pour des études génétiques sur la population.”
    Application Base de données
    “Faire tourner l’application sur SQLServer”
    Services financiers
    “Support de plus d’indicateurs techniques que la société ABC pour les données de streaming en temps réel.”
  • L’équipe Scrum étudie le but du Sprint et décide quelles tâches sont nécessaires
    L’équipe s’auto-gère pour parvenir au but
    Il n’y a pas un chef de projet qui assigne les tâches aux personnes
    Les Managers ne prennent pas de décisions pour l’équipe
    Le Backlog du Sprint est créé
    Du but au Backlog du Sprint
  • Exemple de Backlog de Sprint
  • Changements pendant le Sprint
    L’équipe ajoute de nouvelles tâches quand elle juge que c’est nécessaire pour le but fixé
    L’équipe peut supprimer des tâches devenues inutiles
    Attention : Le Backlog du Sprint ne peut être mis à jour que par l’équipe elle-même
    Les estimations du reste à faire sur les tâches sont actualisées tous les jours
    Vie du Backlog du Sprint
  • Diagramme de « reste à faire » d’un Sprint (VS 2010)
  • Mêlées quotidiennes
    Paramètres
    Tous les jours
    Durée limitée à 15 minutes
    Tout le monde debout
    Pas de résolutions de problèmes
    Trois questions :
    Qu’as-tu fait hier ?
    Que vas-tu faire aujourd’hui ?
    Quels sont les obstacles pour y arriver ?
    Les poules et les cochons sont invités
    Permet d’éviter des réunions inutiles
    Seuls les cochons peuvent s’exprimer
  • Pourquoi tous les jours ?
    “Comment fait un projet pour avoir un an de retard ?”
    “Un jour à la fois.”
    Fred Brooks, The Mythical Man-Month.
    Est-ce que les réunions Scrum peuvent être remplacées par des rapports d’activité envoyés par mail ?
    Non
    L’équipe entière possède une vision complète actualisée quotidiennement
    Permet de créer de la pression poussant à faire ce qu’on a dit qu’on allait faire
    Questions sur les réunions Scrum
  • L’équipe présente ce qui a été réalisé pendant le Sprint
    La présentation comporte une démo des nouvelles fonctionnalités ou de l’architecture
    Revue du Sprint
    • Revue informelle
    • La règle est de ne pas dépasser 2 heures de préparation
    • Participants
    • Propriétaire du produit
    • Clients
    • Management
    • Experts du domaine
  • Dernier Sprint avant livraison
    Sprint 1
    Sprint 2
    Sprint 3
    Sprint 4
    Sprint 1
    Sprint 2
    Sprint 3
    Sprint de
    release
    Sprints normaux : l’objectif est une première utilisation amicale
    Bêta testeurs et assimilés pour utilisation juste après le Sprint
    Pour le dernier Sprint avant livraison (release)
    L’équipe prépare le produit à livrer
    Utile
    Si les bêta testeurs sont très nombreux
    Si une équipe débute avec Scrum
    Si la qualité n’est pas ce qu’elle devrait être
    Ne fait pas partie du standard Scrum (similaire à la phase de transition du RUP)
  • Synthèse A retenir
    L’agilité : une réalité chez Microsoft
    Scrum : une méthode supportée dans VS 2010
    Des partenaires déjà pratiquant de l’agilité !
  • Questions / Réponses
  • Autres sessions intéressantes, Stands, Sites Web, Livres
    Partenaires Visual Studio Team System :
    Pyxis (www.pyxis-tech.com) : GreenHopper for TFS
    Conhango (scrumforteamsystem.com)
    Site Web de l’Agilité chez Microsoft :
    http://www.microsoft.com/agile
    Livre de référence : « Agile Project Management withScrum », Microsoft Press
    http://www.microsoft.com/learning/en/us/Books/6916.aspx
  • Votre potentiel, notre passion TM
    © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
    The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
  • Back slides
  • Making Transparency Work
    Iteration Backlog
    Application Tier (AT)
    Data Tier (DT)
    Team Foundation Server
    Queries
    Team Project Collection DBs
    Adapters
    Common Store
    Test
    Burndown
    Build
    Version Control
    Warehouse
    Trends
    WIT
    Dashboards
    Queries
    Cube
    Trends
    Overview