Scrum et Extreme Programming (XP) sont certainement très alignés. En fait, si vous êtes entré dans une équipe effectuant l’un de ces processus, vous pourriez avoir du mal à décider rapidement si vous étiez entré dans une équipe Scrum ou une équipe XP. Les différences sont souvent assez subtiles, mais elles sont importantes. Je pense qu’il y a quatre différences principales entre Scrum et XP:
- Les équipes Scrum travaillent généralement en itérations (appelées sprints) qui durent de deux semaines à un mois., Les équipes XP travaillent généralement en itérations d’une ou deux semaines.
- Les équipes Scrum n’autorisent pas les changements dans leurs sprints. Une fois la réunion de planification sprint terminée et l’engagement pris de livrer un ensemble d’éléments de backlog produit, Cet ensemble d’éléments reste inchangé jusqu’à la fin du sprint. Les équipes XP sont beaucoup plus susceptibles de changer au cours de leurs itérations. Tant que l’équipe n’a pas commencé à travailler sur une fonctionnalité particulière, une nouvelle fonctionnalité de taille équivalente peut être échangée dans L’itération de L’équipe XP en échange de la fonctionnalité non démarrée.,
- Les équipes de programmation Extreme travaillent dans un ordre de priorité strict. Les fonctionnalités à développer sont hiérarchisées par le client (le Product Owner de Scrum) et l’équipe est tenue de les travailler dans cet ordre. En revanche, le product owner Scrum donne la priorité au backlog produit, mais l’équipe détermine la séquence dans laquelle elle développera les éléments backlog. Je n’ai jamais vu une équipe Scrum ne pas choisir de travailler sur l’élément le plus prioritaire. Et une équipe Scrum choisira très probablement de travailler sur le deuxième plus important., Cependant, à un moment donné, l’un des éléments hautement prioritaires peut ne pas convenir au sprint en cours de planification—peut-être qu’une personne clé qui devrait y travailler sera submergée par le travail sur des éléments plus prioritaires. Ou peut-être qu’il est logique de travailler sur un élément de priorité légèrement inférieur (disons #10 sur le backlog produit au lieu de #6) car l’équipe travaillera dans le code où #10 serait implémenté.
- Scrum ne prescrit aucune pratique d’ingénierie; XP le fait., J’aime les pratiques D’ingénierie XP, en particulier des choses comme le développement piloté par les tests, l’accent mis sur les tests automatisés, la programmation par paires, la conception simple, le refactoring, etc. Cependant, je pense que c’est une erreur de dire à l’équipe « vous vous organisez vous-même, nous vous faisons confiance, mais vous devez faire ces pratiques d’ingénierie spécifiques…. »Cela envoie un message mitigé à l’équipe qui cause de la confusion. J’adore les pratiques XP mais je n’aime pas les rendre obligatoires. Je veux que les équipes découvrent la valeur par elles-mêmes.
Ce sont de petites différences souvent subtiles entre Scrum et XP., Cependant, ils peuvent avoir un impact profond sur l’équipe. Mon conseil typique aux équipes est » commencez par Scrum, puis inventez votre propre version de XP.” Les pratiques XP sont merveilleuses, mais elles fonctionnent le mieux et les équipes s’y engagent le plus vivement si elles les découvrent elles-mêmes plutôt que de les avoir mandatées. J’aide les équipes à le faire dans mon coaching en posant des questions telles que: « ce bug serait-il arrivé si nous avions fait du développement piloté par les tests?” et « aurions-nous fait cette erreur si nous étions liaison? »True je trouve que le vrai XP est une petite cible au loin., Si une équipe peut viser et frapper l’œil du taureau, merveilleux. Sinon, cependant, ils sont susceptibles de piratage (par exemple, refactoring sans test automatisé ou TDD). Scrum est un grand œil de taureau qui à lui seul apporte de grandes améliorations simplement grâce à la mise au point supplémentaire et aux itérations timeboxées. C’est un bon point de départ pour ajouter ensuite les pratiques XP.