Affichage des articles dont le libellé est Scrum Master. Afficher tous les articles
Affichage des articles dont le libellé est Scrum Master. Afficher tous les articles

mercredi 4 septembre 2013

Scrum de Scrum et autres pratiques

Scrum de Scrum

Notre équipe projet est constituée de 3 POs, un CP et de deux équipes Scrum (11 développeurs et 2 Scrum Masters). 

Les 2 équipes fonctionnement en mode Scrum de Scrum et nous réalisons des mêlées Scrum de Scrum 2 fois par semaine. Les deux équipes se trouvent dans le même espace et la collaboration quotidienne entre les Scrum Master quotidienne et très efficace. Du coup les mêlées Scrum Scrum restent très utiles mais certaines actions/décisions sont prises en dehors de l'instance avec une meilleure réactivité que ce que nous imaginions. Sur ce point nous ne pouvons que féliciter l'excellent travail réalisé par nos deux Scrum Masters et leurs Backups!


Nous avons aussi amélioré notre communication à destination des équipes Scrum notamment par voies d'affichage : 

  • La roadmap et la fiche de vision A3 du projet est affichée pour l'équipe et mise à jour régulièrement, 
  • Une charte projet a été réalisée conjointement par les Scrum Master, les équipiers, les POs et notre Chef de Projet. Elle décrit les rôles et responsabilité de chacun, le fonctionnement des équipes. 
  • Lorsque des compléments d'information sont demandés nous diffusions l'information à tous les membres de l'équipe et pas aux seul Scrum Masters qui devenaient des goulets d'étranglement.

Pratiques de développement 

Nous avions déjà mis en place une intégration continue et les pratiques agiles des équipes de développement continuent d'évoluer pour assurer une meilleur qualité du code.  :
  • Mise en place du Pair Programming (développement en binôme)  
  • Développement en TDD
Afin d'assurer la montée en compétence e tous les équipiers sur ces pratiques, nous avons un Expert eXtreme programmeur qui a intégré l'équipe. Merci et bravo à Mickael pour le sérieux et la qualité de son intervention. 

Organisation des POs

S'il est préconisé en Scrum d'avoir un et un seul PO pour un produit, ce n'est pas l'organisation que nous avons mise en oeuvre. Cela nous a exposé à plusieurs difficultés organisationnelles et de partage des documents. 
De ces difficultés est ressortie la nécessité de mettre en oeuvre des outils de travail collaboratif pour la gestion de la Backlog et des autres documents associés comme un wiki.

vendredi 8 juillet 2011

Être agile, c'est quoi?

Scrum et l'agilité :

Vous trouverez sur mon site un retour d'expérience sur Scrum, la méthode agile la plus connue en matière de
développement logiciel; une méthode:
  • qui organise le travail équipe
  • qui est une adaptation du Lean Management
  • qui favorise la collaboration au sein de l'équipe, ce qui permet d'avoir régulièrement et fréquement
    un logiciel qui fonctionne

Comment nous pratiquons Scrum ?

Contexte et dérogations à la méthode :
  • Nous pratiquons Scrum depuis un an et demi, chez le client, mais ne développons de logiciel
  • Nous décrivons des processus, apportons de l'assistance et de l'expertise aux différents projets
    (nous fabiquons tout de même des "artefact" et pouvons planifier nos travaux, mais pas en release)
  • Nous donnons des formations aux équipes de développement sur les outils et frameworks "maison";
  • Depuis peu, on forme aussi à Scrum, et c'est moi qui m'en charge - d'ou le site aussi un peu ;-)
  • Nous sommes une équipe mixte composée d'internes (client) et de prestataires (l'égalité entre
    équipiers en souffre, pas toujours évident à gérer)
  • Nous n'avons pas de Vrai Scrum Master (un et un seul). Nous sommes tous impliqués dans l'application de la méthode, nous participons tous à la production. Celà nous pose des soucis :
    • le rôle partagé mais pas clairement identifié
    • il est difficile d'être juge et partie, mais avec la plus forte des volonté
    • les intérêt du client, de l'équipe, et de notre société (Société de Services Informatiques) ne
      sont pas toujours en adéquation
  • Nous avons par contre un seul et unique Product Owner qui alimente et priorise sa Backlog et
    ça c'est bien
  • Nous avons des Sprint à durée fixe : 3 semainesChaque Sprint commence par un lancement de
    Sprint et la revue du Backlog est faite avant
  • Nous terminons toujours par un bilan du Sprint puis une rétrospective
  • Nous essayons de TimeBoxer le plus possible, mais on doit s'améliorer beaucoup en la matière
  • Toutes nos Stories d'un Sprint sont estimées par l'équipe (sans intervention intempestive du PO)
  • Toutes nos Stories sont découpées en tâches de réalisation, estimées en heure
  • Nous mettons à jour quotidiennement le BurnDown affiché dans le bureau Scrum

En quoi sommes nous agiles?

  • Nous concentrons nos efforts sur ce qui a le plus d'importance pour le client
  • Nous planifions nos travaux et nos tâches
  • Nous suivons quotidiennement nos indicateurs et les analysons lorsqu'ils semblent "étrange"
  • Nous améliorons notre manière de travailler à chaque fin d'itération (toutes les 3 semaines)
  • Nous échangeons beaucoup par oral pour clarifier certaines User Stories (ou tâches) avec le PO ou le
    reste de l'équipe