Pourquoi la programmation extrême (XP) est-elle dépassée au profit d'Agile, Kanban, etc.?

J'aime XP (programmation extrême), en particulier la partie où il y a 2 programmeurs sur le même écran, car la solution d'un problème est souvent trouvée plus rapidement si seulement vous expliquez ce que vous faites et la programmation par paire vous oblige à expliquer ce que vous êtes Faire.

Au cours des 10 dernières années environ, le style de travail XP semble être dépassé au profit des méthodologies de travail: Agile et / ou Kanban. Pourquoi? Depuis XP me semble être un très bon moyen de travailler et c'est beaucoup de programmation alors qu'Agile et Kanban sont plutôt des processus.

Il y a beaucoup de styles, de méthodes et de mentalités différents liés au développement du champ entier, et tout a son propre nom brillant.

Agile n'est qu'un état d'esprit qui s'éloigne des modèles de programmation statiques habituels (comme les cascades) - son objectif principal est de parvenir à un développement plus flexible et (à la toute fin) de meilleurs logiciels et des clients satisfaits. Sous agile, il existe de nombreux modèles différents comme Scrum, Kanban, XP.

En particulier, Kanban ne provient pas du développement de logiciels à l'origine, il provient de la construction de voitures (je rappelle que Toyota l'a introduit pour la construction de voitures et que certains développeurs de logiciels l'ont adopté et développé)

La programmation en binôme, les révisions de code et ce genre de choses ne sont que des outils - vous pouvez (et devriez) toujours le faire pendant un projet, quelle que soit la méthode que vous utilisez. C'est juste que ce truc est plus natif d'agile que de statique.

XP a plus ou moins introduit ces choses (ou du moins leur a donné un nom brillant) et toutes les choses suivantes les ont adoptées parce que cela fonctionnait simplement bien.

À mon avis, XP est une pratique de programmation, Scrum et Kanban sont des pratiques de gestion de projet. Ils ont une relation mais ne se remplacent pas.

Dans notre projet kanban, nous utilisons la programmation par paires (principalement pour les sections complexes et le débogage), TDD, CI. Donc, il est toujours utilisé, mais la direction pousse plus dur le côté gestion de projet.

Extreme Programming concerne la mécanique du développement, tandis qu'Agile concerne le SDLC (cycle de vie du développement logiciel).

La principale raison pour laquelle vous n'entendez plus parler de «programmation extrême» par son nom est l'utilisation du terme «extrême» comme adjectif positif. C'est surtout une victime du marketing. C'est pourquoi vous l'entendez presque exclusivement sous le nom de "XP", même verbalement.

J'ai quelques réflexions sur la programmation en binôme.

Pour moi, c'est quelque chose que vous faites lorsque vous êtes coincé avec quelque chose. À ces moments-là, cela peut être très efficace, cela peut vous sortir d'une ornière. Mais c'est aussi fatigant et une façon de travailler que le programmeur de type stéréo n'aime pas faire plus qu'occasionnellement.

Si vous creusez un trou, peu de gens voudraient obtenir l'aide d'un collègue. Mais dès qu'il y a de la créativité, les gens préfèrent faire les choses à leur place plutôt qu'à la manière de quelqu'un d'autre. La tension est donc toujours proche à moins que l’un ne s’en soucie dans un sens ou dans l’autre ou si son rôle est clairement de suggérer uniquement.

Là où je travaille, la programmation par paires n'est pas formalisée, mais nous avons des sessions ad hoc et elles sont généralement brèves. Ce ne sera pas comme "Hey collègue, que diriez-vous d'une programmation extrême?" Il commencerait plus souvent par "Pouvez-vous jeter un œil à mon écran?" et en tirant une chaise pour eux.

Je ne pense donc pas que la programmation en binôme soit morte ou moins populaire, ce n'est qu'un de ces outils que vous n'utilisez pas très souvent parce que c'est coûteux, et pas principalement parce que deux personnes rémunérées travaillent sur une chose.

Agile est plus commercialisable car il implique différentes parties prenantes avec différents rôles et responsabilités liés au processus de création de logiciels.

Quand, dans sa deuxième édition, Kent Beck a élargi le champ des participants au sein de XP, il était tard: les gens ont déjà adopté d'autres méthodologies parce que la première version XP cible les auteurs du code, et c'est ce dont le public se souvient encore inconsciemment ou non. XP n'était pas commercialisable à la naissance.

J'ai toujours pensé que Scrum était la version d'Agile la plus facile à vendre à la direction: les estimations déterministes, sa nature quelque peu doctrinaire et bien définie ("vous ne faites pas vraiment Scrum - culpabilisez-vous!") ...

Étirez vos sprints assez longtemps et prenez ces petites "cartes de poker" assez au sérieux, et Scrum peut chatouiller la même démangeaison que les méthodes Waterfall. Ce n'est pas nécessairement mauvais, mais ne nous cachons pas derrière la fumée et les miroirs ici.

Du côté XP, la programmation par paires ne fait généralement pas appel à la gestion, en particulier la gestion non technique.

Pour le mettre au format d'analogie SAT, Scrum: XP :: The Monkees: The Beatles