Une équipe SCRUM est composé d’un Product Owner (PO), d’un Scrum Master (SM) et l’équipe de dévs. L’équipe de dévs, selon moi, est le plus important dans SCRUM. C’est elle qui créé de la valeur ! C’est elle qui bâtit, c’est elle qui construit, c’est elle qui mets les mains dans le cambouis. Les architectes, les développeurs, les experts, … sont la force d’une équipe pour moi.

Une équipe doit être focus pendant tout le projet, avoir le sens de l’engagement, du courage, du respect, de l’ouverture et de l’humour.

equipe

La taille idéale pour une équipe est 7 (« dans les écrits anciens, Two pizzas team »).

L’équipe de dévs à une mission très simple, maintenir le code, l’améliorer et éviter au maximum la dette technique. Pour qu’une bonne équipe roule. Cette équipe doit être pluridisciplinaire, chaque membre doit pouvoir jouer au poste de tout le monde pour gagner en efficacité. Supposons que le latéral droit d’une équipe de foot se blesse et qu’il n’y a plus qu’un défenseur central de disponible sur le banc des remplacants, et  bien il va logiquement jouer à la place de son partenaire. Il aurait peut-être un peu plus de difficultés à prendre ses marques mais il va savoir jouer et connait les règles. C’est identique dans une équipe Scrum.

Une équipe doit être stable. On ne change pas les membre d’une équipe dans un projet. On verra plus tard que ca vient casser la vélocité de l’équipe.

Une équipe a une identité. Pour le bien de l’équipe et du projet, il faut que les membres soient dans un même espace. Proximité des bureaux si on se trouve dans un open-space. Le mieux reste une salle dédiée à l’équipe projet avec un ordinateur libre de tous où le projet tourne en permanence. Le scrumboard doit être affiché dans cette espace. La salle ou l’espace peut être customisé par l’équipe.

Un développeur doit être responsable vis à vis de son code source. Il doit avoir les compétences techniques nécessaires pour le projet. Il doit s’améliorer en permanence dans le rôle, il doit connaitre les bonnes pratiques du langage, améliorer son code, bref la vie d’un dév 😉

Je conseille un leader technique tout de même dans cette équipe Scrum. Quelqu’un sur qui on peut se reposer lorsqu’on a un gros problème technique pour éviter qu’un membre ne soit paralysé trop longtemps. Le Scrum Master n’est pas le leader technique (il peut l’être s’il a cette compétence.)

XP pour Extreme Programming est lui aussi une méthodologie issue du monde de l’agilité pour l’équipe. XP est orienté sur l’aspect réalisation d’une application, sans pour autant négliger l’aspect gestion de projet. XP est adapté aux équipes réduites avec des besoins changeants. XP pousse à l’extrême des principes simples. C’est une pratique de devs, voilà pourquoi j’ai mis ce chapitre à la fin de ce billet dédié à l’équipe.

Des pratiques autour du code comme :

  • Le TDD, les développements pilotés par les tests
    • On teste en premier
    • On remanie le code
    • On évite ainsi la dette technique
    • et on la rembourse à minima au fur et à mesure
  • L’intégration continue
    • Une pratique indispensable qui apporte beaucoup de bénéfices
    • Déploiement continu
    • Avoir les bonnes pratiques avec les bonnes règles de gestion
  • Le pair programming
    • Faire monter en compétences des juniors ou des non sachants sur la technologie par un expert
    • Un tape et code sur le clavier pendant que l’autre réfléchi et prend du recul. C’est démontré que deux cerveaux sur un problème valent mieux qu’un.
  • La conception collective est sur le devant de la scène
  • Il n’y a plus un super architecte qui fait tout dans sa tour d’ivoire
  • Ca donne naissance à des courants alternatifs comme le Craftmanship

Le sujet de XP est vaste. Je vous donne juste un aperçu avec les grands mots clefs afin que vous puissiez rechercher plus tard.