• Forums
  • Tutoriels
  • Magazine
  • FAQs
  • Blogs
  • Projets
  • Chat
  • Newsletter
  • Études
  • Emploi
  • Club
  • Contacts
 
  • Accueil Actualités IT Pro
  • ALM Cycle de vie du logiciel
    • ALM
    • UML
    • Merise
  • Java Plateforme et langage Java
    • Java
    • Spring
    • Dév. Web Java
    • Android
    • Eclipse
    • NetBeans
  • .NET Microsoft Framework .NET
    • Microsoft DotNET
    • Visual Studio
    • ASP.NET
    • C#
    • VB.NET
    • Windows Phone
    • Windows Azure
  • Dév. Web Développement Web et Webmarketing
    • Développement Web
    • AJAX
    • Apache
    • ASP
    • CSS
    • Flash / Flex
    • JavaScript
    • PHP
    • Ruby & Rails
    • Web sémantique
    • Webmarketing
    • (X)HTML
  • EDI Environnements de Développement Intégré
    • EDI
    • 4D
    • Delphi
    • Eclipse
    • LabVIEW
    • NetBeans
    • MATLAB
    • Visual Studio
    • WinDev
    • Visual Basic 6
    • Lazarus
    • Qt Creator
  • Langages Langages de programmation applicatifs
    • Langages
    • Assembleur
    • C
    • C++
    • C#
    • Pascal
    • Perl
    • Python
    • Visual Basic 6
    • VB.NET
    • XML
    • Autres
  • SGBD Systèmes de Gestion de Bases de Données
    • SGBD & SQL
    • 4D
    • Access
    • DB2
    • Firebird
    • InterBase
    • MySQL
    • NoSQL
    • Oracle
    • PostgreSQL
    • SQL-Server
    • Sybase
  • Office Bureautique pour l'entreprise
    • Microsoft Office
    • Access
    • Excel
    • Word
    • Outlook
    • PowerPoint
    • SharePoint
    • Microsoft Project
  • Solutions d'entreprise Autres logiciels pour l'entreprise
    • Solutions d'entreprise
    • Business Intelligence
    • ERP / PGI
    • CRM
    • SAS
    • Cloud Computing
    • SAP
    • Microsoft BizTalk Server
  • Applications Applications logicielles
    • Applications
    • 2D - 3D - Jeux
    • Projets
  • Mobiles Logiciels et matériels mobiles
    • Mobiles
    • Android
    • iOS
    • Windows Phone
  • Systèmes Logiciels et matériels systèmes
    • Systèmes
    • Windows
    • Linux Professionnel
    • Sécurité
    • PC
    • Mac
    • Réseau
    • Green IT
    • Virtualisation
 
  • ALM
  • UML
  • Merise
 
 
Facebook
Twitter
RSS
  • FORUMS ALM
  • TUTORIELS ALM
  • F.A.Qs ALM
  • LIVRES ALM

Scrum et XP depuis les Tranchées

Comment nous appliquons Scrum

Table des matièresPlier Déplier

  • Copyright
    • Copyright original
  • Preface
    • Remerciements
      • Préface de Jeff Sutherland
      • Préface de Mike Cohn
      • Préface - Hé, Scrum ca marche !
  • Intro
    • 1. Intro
      • 1.1. Avertissement
      • 1.2. Pourquoi j'ai écrit ceci
      • 1.3. Mais Scrum, qu'est ce que c'est ?
  • Comment nous faisons les backlogs de produit
    • 2. Comment nous faisons les backlogs de produit
      • 2.1. Champs d'histoire supplémentaires
      • 2.2. Comment nous gardons le backlog de produit à un niveau métier
  • Les sprints
    • 3. Comment nous préparons la réunion de planning du sprint
    • 4. Comment nous faisons les plannings de sprint
      • 4.1. Pourquoi le directeur de produit doit y assister
      • 4.2. Pourquoi la qualité n'est pas négociable
      • 4.3. Les réunions de planning de sprint qui s'éternisent...
      • 4.4. L'ordre du jour de la réunion de planning de sprint
      • 4.5. Le choix de la durée du sprint
      • 4.6. La définition du but du sprint
      • 4.7. Le choix des histoires à inclure dans le sprint
      • 4.8. Comment le directeur de produit peut-il exercer une influence sur les histoires qui iront dans le sprint ?
      • 4.9. Comment les équipes choisissent-elles les histoires à inclure dans le sprint ?
        • 4.9.1. Estimation en utilisant les calculs de vélocité
        • 4.9.2. Quelle technique d'estimation utilisons-nous ?
      • 4.10. Quelle technique d'estimation utilisons-nous ?
      • 4.11. Pourquoi nous utilisons des fiches
      • 4.12. Définition de "terminé"
      • 4.13. L'estimation de temps avec le poker de planning
      • 4.14. La clarification des histoires
      • 4.15. La décomposition des histoires en plus petites histoires
      • 4.16. La décomposition des histoires en tâches
      • 4.17. Le choix du lieu et l'heure pour la mêlée quotidienne
      • 4.18. Où tracer la limite ?
      • 4.19. Les histoires techniques
      • 4.20. Système de suivi de bug vs. backlog de produit
      • 4.21. La réunion de planning de sprint est finalement terminée !
    • 5. Comment nous communiquons sur les sprints
    • 6. Comment nous faisons les backlogs de sprint
      • 6.1. Format du backlog de sprint
      • 6.2. Comment le tableau des tâches fonctionne
      • 6.3. Exemple 1 - Après la première mêlée quotidienne
      • 6.4. Exemple 2 - après quelques jours
      • 6.5. Comment le burndown chart fonctionne
      • 6.6. Les signaux d'avertissement du tableau des tâches
      • 6.7. Hé, et la traçabilité ?!
      • 6.8. Estimations en jours vs. heures
  • Le bureau de l'équipe
    • 7. Comment nous organisons le bureau de l'équipe
      • 7.1. Le coin conception
      • 7.2. Installez l'équipe ensemble !
      • 7.3. Garder le directeur de produit à distance
      • 7.4. Garder les directeurs et les coachs à distance
  • Les mêlées quotidiennes
    • 8. Comment nous faisons les mêlées quotidiennes
      • 8.1. Comment nous mettons à jour le tableau des tâches
      • 8.2. Traiter avec les retardataires
      • 8.3. Traiter avec « je ne sais pas quoi faire aujourd'hui »
  • Les démos de sprint
    • 9. Comment nous faisons les démos de sprint
      • 9.1. Pourquoi nous insistons pour que tous les sprints finissent par une démo
      • 9.2. S'occuper des choses « indémontrables »
  • Les rétrospectives
    • 10. Comment nous faisons les rétrospectives de sprint
      • 10.1. Pourquoi nous insistons pour que toutes les équipes fassent des rétrospectives
      • 10.2. Comment nous organisons les rétrospectives
      • 10.3. La diffusion des enseignements tirés entre équipes
      • 10.4. Changer ou ne pas changer
      • 10.5. Exemples de choses qui peuvent remonter pendant les rétrospectives
        • 10.5.1. « Nous devrions passer plus de temps à décomposer les histoires en sous-éléments et tâches »
        • 10.5.2. « Trop de dérangements extérieurs »
        • 10.5.3. « Nous nous sommes trop engagés et nous n'avons terminé que la moitié du travail »
        • 10.5.4. « Notre bureau est trop bruyant et bordélique »
    • 11. Relâcher le rythme entre les sprints
  • Le contrat au forfait
    • 12. Comment nous faisons la planification de release et les contrats au forfait
      • 12.1. Définir vos seuils d'acceptation
      • 12.2. Estimation en temps des éléments les plus importants
      • 12.3. Estimer la vélocité
      • 12.4. Tout mettre ensemble dans un plan de release
      • 12.5. Adapter le plan de release
  • Scrum et XP
    • 13. Comment nous combinons Scrum avec XP
      • 13.1. La programmation en binôme
      • 13.2. Le Développement Dirigé par les Tests (DDT)
        • 13.2.1. Le DDT sur du nouveau code
        • 13.2.2. Le DDT sur du vieux code
      • 13.3. La conception incrémentale
      • 13.4. L'intégration continue
      • 13.5. La propriété collective du code
      • 13.6. Un espace de travail informatif
      • 13.7. Les normes de codage
      • 13.8. Le rythme soutenable / le travail énergisé
  • Les tests
    • 14. Comment nous faisons les tests
      • 14.1. Vous ne pouvez probablement pas éliminer la phase de tests d'acceptation
      • 14.2. Minimisez la phase de tests d'acceptation
      • 14.3. Augmenter la qualité en mettant des testeurs dans l'équipe Scrum
        • 14.3.1. Le testeur est le « gars qui signe officiellement »
        • 14.3.2. Que fait le testeur quand il n'y a rien à tester ?
      • 14.4. Augmenter la qualité en en faisant moins par sprint
      • 14.5. Est-ce que les tests d'acceptation devraient faire partie du sprint ?
      • 14.6. Des cycles de sprints vs. des cycles de test d'acceptation
      • 14.7. Ne distancez pas le maillon le plus lent de votre chaîne
      • 14.8. Retour à la réalité
  • Les équipes multi-Scrum
    • 15. Comment nous gérons les équipes multi-Scrum
      • 15.1. Combien d'équipes faut-il créer
        • 15.1.1. Equipes virtuelles
        • 15.1.2. La taille optimale de l'équipe
      • 15.2. Sprints synchronisés - ou non ?
      • 15.3. Pourquoi nous avons introduit le rôle du « meneur d'équipe »
      • 15.4. Comment nous affectons les personnes aux équipes
      • 15.5. Equipes spécialisées - ou non ?
        • 15.5.1. Approche n°1 : équipes spécialisées par composant
        • 15.5.2. Approche n°2 : équipes transversales aux composants
      • 15.6. Réarranger les équipes entre les sprints - ou pas ?
      • 15.7. Les membres d'équipe à temps partiel
      • 15.8. Comment nous faisons les Scrums-de-Scrums
        • 15.8.1. Scrum-de-Scrums de niveau produit
        • 15.8.2. Scrum-de-Scrums de niveau global
      • 15.9. Intercaler les mêlées quotidiennes
      • 15.10. Les équipes de pompiers
      • 15.11. Partager le backlog de produit - ou pas ?
        • 15.11.1. Stratégie 1 : un directeur de produit, un backlog
        • 15.11.2. Stratégie 2: un directeur de produit, plusieurs backlogs
        • 15.11.3. Stratégie 3 : plusieurs directeurs de produit, un backlog par directeur
      • 15.12. Branches de code
      • 15.13. Rétrospectives multi-équipes
  • Les équipes distribuées
    • 16. Comment nous gérons les équipes géographiquement dispersées
      • 16.1. Délocaliser Offshore
      • 16.2. Équipiers travaillant de la maison
  • Pense-bête
    • 17. Pense-bête du Scrum Master
      • 17.1. Début du Sprint
      • 17.2. Tous les jours
      • 17.3. Fin du Sprint
  • Conclusion
    • 18. Mot de la fin
      • 18.1. Lectures recommandées
      • 18.2. A propos de l'auteur

Ce livre fait partie de la collection de livres InfoQ "Enterprise Software Development". L'apport du livre d'Henrik est que, si vous suivez les pratiques décrites, vous aurez un Directeur de produit, des estimations pour votre Backlog de produit, une Courbe du reste à faire, et vous connaîtrez la vélocité de votre équipe ainsi que de nombreuses autres pratiques essentielles pour un Scrum dangereusement opérationnel. Vous passerez le test Nokia pour Scrum et serez digne de l'investissement dans votre travail. Si vous êtes une startup, vous pouvez même bénéficier du financement d'une société capital-risque. Vous serez peut-être le futur du développement logiciel et le créateur d'une nouvelle génération d'éminents logiciels.

Jeff Sutherland, Ph.D., Co-Créateur de Scrum


16 commentaires Donner une note à l'article (5)

Cette traduction de l'édition originale que vous pouvez trouver sur la page de l'ouvrage sur InfoQ (tout comme les autres traductions) a été faite bénévolement par les traducteurs français, et Henrik Kniberg et InfoQ en ont autorisé la publication.

Image non disponible

Henrik Kniberg
Préfaces de Jeff Sutherland, Mike Cohn

Image non disponible

Les deux auteurs

Henrik Kniberg Site personnel

Traduction par Guillaume Mathias, Bruno Orsier, Emmanuel Etasse, Christophe Bunn

L´article

Publié le 21 janvier 2009 - Mis à jour le 3 mai 2010 

Liens sociaux

Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 

suivant
Copyright © 2009 Henrik Kniberg. La copie, modification et/ou distribution par quelque moyen que ce soit, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Image non disponible
  
 
 

Responsable bénévole de la rubrique ALM : le Rédacteur en Chef - Contacter par email

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum ALM

Blogs

Hébergement

 
Partenaires

Hébergement Web

Copyright © 2000-2013 - www.developpez.com

Image 1 sur 2