Scrum vs XP le retour
Par Jean-Baptiste le vendredi 30 janvier 2009, 10:52 - Agilité - Lien permanent
Il y a quelque temps déjà, j'avais écrit un billet concercnant Scrum Vs XP. Peut-être l'avez vous lu, peut-être pas, mais l'essence de ce que je disais alors entre autre, était que je me méfiais de Scrum car il passait sous silence toutes les techniques d'ingénierie en se concentrant sur la gestion de projet. C'était un danger pour moi, car il me semblait, et me semble toujours, qu'il est impossible de réussir un projet agile sans les pratiques d'ingénierie qui vont bien. Comment travailler en itération si à chaque passage on ne fait que grossir la dette technique n'est-ce pas?
Je vous reparle de tout ça car il se trouve que Martin Fowler en parle aujourd'hui . Alors oui je vous link ça car vous vous en doutez, je suis fier d'avoir obtenu les mêmes concluions que Fowler 
Ceci dit, je vous le fait passer également car j'aime bien montrer que je ne parlais pas dans le vent, et que le phénomène que j'avais anticipé existe réellement.
Fowler est plus dans le consensus que moi, et ne démonte pas Scrum. Mais personnellement, je maintiens ce que je disais: pourquoi choisir Scrum quand XP est complet et n'induit pas le risque d'oublier ou le planning ou l'ingénierie?
Commentaires
J'adore la conclusion de Fowler :
"Cels nous rappelle juste que les individus et leurs interactions ont plus de valeur que les processus et les outils"
Science sans conscience n'est que ruine de l'ame. Idem pour Scrum ou n'importe quelle méthode, y compris XP, qui appliquée aveuglément sans prendre en compte la sensibilité des gens mène à la chute.
Il ne faut pas prendre les gens pour des abrutis, les gens qui choisissent scrum ne sont pas tous des dogmatiques aveugles au contexte. Par ailleurs l'application stricte de scrum ne donne aucune indication sur les pratiques techniques à mettre en place.
Fowler nous dit "oui mais les bonnes pratiques techniques dans tout ca ?". Effectivement, pas de technique dans scrum puisque c'est une méthode de gestion. C'est pour ca que scrum a besoin d'XP ou d'autre chose en complément pour fournir ces bonnes pratiques. Avec tout le respect qui lui est du, avant de râler parce que Scrum ne couvre pas les aspects techniques il faudrait qu'il comprenne que c'est bien le but de scrum de ne pas les couvrir.
Mais si Jean-Baptiste tu es lu !
Je dois moi aussi avouer ne pas imaginer possible de construire du logiciel de manière incrémentale, just-in-time, sans de solides pratiques d'ingénierie, et sans une capacité d'apprentissage et d'évolution de l'équipe.
Je crois que l'agilité en générale demande une nouvelle culture de qualité logicielle : sauf des cas de figures simplissimes, produire du logiciel ne peut pas être un processus routinier.
De mon point de vue, le gros problème avec Scrum est sa capacité à être récupéré par des organismes gérant la construction de logiciels de manière routinière. Je pense aux grandes SSII par exemple. Elles achètent des certifications Scrum comme on achète des licences logicielles, ce qui leurs permet parader commercialement.
Si les équipes montées dans ces structures étaient réellement auto-organisées, on pourrait parier qu'elles passeraient alors aux pratiques d'ingénierie XP pour se donner les moyens de leurs ambitions. Scrum ne serait qu'un point de départ. Mais ce n'est pas le cas.
Je crois, c'est une hypothèse, que les organisations comme les grandes SSII sont malheureusement des lieux où l'individualisme est roi et où le niveau de confiance est tellement bas, que l'auto-organisation préalable à tout apprentissage n'est pas rendue possible.
S'il y a un espoir tout de même, c'est que la percée de Scrum dans les entreprises aura montrer à quelques-uns que l'on pouvait faire du logiciel de bien meilleure qualité en redonnant toute sa place à l'Homme. Si si
Si Scrum a été pour ma part un bon point de départ. C'est vrai que c'est maintenant XP que je retiens.
je sais qu'avec le nombre d'adeptes de scrum, je ne me fais pas des amis avec de genre de billet
Pour reprendre ce que je disais dans mon billet précédent, je ne reproche pas aux Scrumistes d'avoir choisi scrum et d'appliquer à côté les bonne pratiques. Je parlais du danger que dans un avenir plus ou moins proche, certains nouveaux arrivant du coup oublieraient ou ne verraient pas la nécessité des bonnes pratiques. Cet avenir est là, c'est pour ça que j'ai écrit ce billet aujourd'hui.
Très personnellement ensuite, oui je me méfie d'une méthode qui veut tellement perpétuer la séparation forte entre gestion de projet et développement. C'est juste à mon sens très faux et encore plus dans un contexte agile.
De toute manière, il ne faut pas faire de l'agilité mais être agile; de plus, la réelle agilité je pense est une agilité "générique", piochant en fonction de ce qui a de mieux dans différentes approches à la lumière de ses valeurs. Ceci dit, sur ce chemin, il y a beaucoup d'embuches, et oui je reproche à Scrum d'ajouter un gros caillou sur la route et permettant cet oubli que la technique est indispensable et indissociable. Mais je suis curieux de connaître les raisons qui font que Scrum ne veut pas couvrir la technique.
EDIT:
Colin:
Merci de me lire alors ^^ Et je plussoie ton analyse de la situation en SSII, qui finalement réussi mieux que moi à exprimer mes doutes.
Je ne sais pas pourquoi les grands manitous de scrum ne veulent pas couvrir les aspects techniques. Mais c'est ce qui me séduit dans scrum, tout comme dans les applis bien codées : faible couplage, forte cohésion, loi de déméter et ce genre de choses. Scrum ne dicte pas les bonne pratiques techniques mais est assez souple (ou je prends assez de liberté avec scrum) pour s'intégrer tres naturellement avec celles que je met en place.
Et il y a besoin de cette souplesse, parce que justement les individus et leurs interactions ont plus de valeur que les processus et les outils, donc les pratiques techniques à mettre en place (mais tout comme les méthodes de gestion de projet) se décident en négociation avec les individus.
J'ai un peu de mal a comprendre comment on peut proner l'adaptation d'un processus à un contexte humain quand on vend l'application d'un monolithe comme XP qui cadenasse les méthodes depuis l'interaction avec l'utilisateur jusqu'a la ligne de code. On prone l'adaptabilité des méthodes et consort, mais on n'hesite pas a taxer de "rotten apple" celui qui ne s'y plie pas et à l'ejecter plutot que d'infléchir le dogme agile (notons l'oxymore). Je pense être agile, et je crois suffisamment dans ses valeurs pour etre convaincu que l'agilité s'applique à tout y compris à elle même, et que l'on peut être agile dans la mise en place de l'agilité, pour peu que les méthodes soient assez agiles elles mêmes.
Comme on disait plus haut, tant mieux si tu as bien saisi la nécessité de la mise en place des pratiques techniques, mais ce n'est pas le cas de toute le monde. La réalité est là pour nous rappeler que l'agilité/scrum/xp etc etc sont en train de faire un énorme buzz, et que certaines équipes piochent scrum comme méthode mais ne mettent pas en place les pratiques techniques qui vont bien. Dans ce genre de cas je me répète, je jette la pierre à cette équipe, qui met en place sans comprendre, mais je jette également la pierre à la méthode, qui ne met pas assez/pas du tout en avant cette nécessité.
Les bonnes phrases du "soyons agiles, prenons que ce qui nous intéresse", je les ai trop vu servir d'excuses pour se concentrer uniquement sur les pratiques faciles, et laissez tomber ce qui était réellement important. Je ne suis pas dogmatique, je dis qu'avant d'essayer d'adapter ou changer un méthode, il faudrait d'abord la maîtriser. De combien de jeunes équipes peut-on dire ça? Le chemin doit être balisé pour amener au succès. Je trouve ça incroyablement plus simple pour une équipe démarrant de se concentrer sur UNE approche exhaustive avant d'essayer d'en mixer plusieurs.
Ces techniques que tu mets en place, je suis à peu prêt convaincu que la plupart sont dans xp... De plus, je ne considère pas comme étant de la souplesse le fait de ne rien dire du tout.
J'aimerais bien savoir les différences qu'il y a entre Scrum et XP au niveau de la gestion de projet. J'entends dire parfois "ouais, t'as vu nous on fait du Scrum/XP", mais si XP couvre déja les pratiques de gestion de projets, ce genre d'affirmation deviens ridicule.
Les différences vont se situer essentiellement dans le vocablulaire, mais fondamentalement, on va trouver les mêmes notions. Pour s'en convaincre, il suffit d'aller regarder le site officiel, ou bien se commander ce livre.
Bonjour ! Avez vous démarché une agence référencement google pour le référencement google ?
Je suis 100% d accord, j'apprécie votre style. En tout cas, je vais revenir vous rendre visite très prochainement. J'en profite également pour lancer un peu de promo sur mon blog sur la formation via le jeu. Bonne journée