J'aime XP (programmation extrême), en particulier la partie où il y a 2 programmeurs sur le même écran, car une solution de problème est souvent trouvée plus rapidement si vous seul expliquez ce que vous faites et paire La programmation vous oblige à expliquer ce que vous faites.
Au cours des 10 dernières années environ, le XP = style de travail semble avoir disparu en faveur des méthodologies de travail: agile et/ou kanban. Pourquoi? Depuis XP Il me semble être un très bon moyen de travailler et est beaucoup sur la programmation alors que Agile et Kanban sont davantage sur les processus.
Il y a beaucoup de styles différents, de méthodes et de mentalités liées à l'ensemble du développement sur le terrain, et tout a son propre nom brillant.
Agile n'est qu'un état d'esprit qui s'éloigne des modèles de programmation habituels et statiques (comme des cascades) - son objectif principal est d'obtenir un développement plus flexible et (à la fin) de meilleurs logiciels et des clients heureux. Ci-dessous agile, il y a beaucoup de modèles différents comme Scrum, Kanban, XP.
Surtout Kanban ne provient pas du développement de logiciels à l'origine, il provient de la construction de voitures (je rappelle à Toyota l'introduisa pour la construction de voitures et certains développeurs de logiciels l'ont adopté et élargi)
La programmation de paires, les critiques de code et les autres choses sont des outils seulement - vous pouvez (et devrait-être) le faire toujours pendant un projet, quelle que soit la méthode que vous utilisez. C'est juste que ce genre de choses est plus originale d'agile qu'à la statique.
XP est plus ou moins introduit ces choses (ou au moins leur a donné un nom brillant) et toutes les choses suivantes les ont adoptées parce que cela a simplement fonctionné 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 remplacent pas mutuellement.
Dans notre projet Kanban, nous utilisons une programmation de paires (principalement pour des sections complexes et un débogage), TDD, CI. Il est donc encore utilisé mais la direction pousse le côté de la gestion de projet plus difficile.
J'ai des pensées sur la programmation par paire.
Pour moi, c'est quelque chose que vous faites quand vous êtes coincé avec quelque chose. À celles-ci, il peut être très efficace, il peut vous faire sortir d'une ornière. Mais il est également fatigant et une façon de travailler que le programmateur de type stéréo n'aime pas faire plus que de temps en temps.
Si vous creusez un trou, peu de gens m'inquiètent d'obtenir de l'aide d'un collègue. Mais dès qu'il y a une créativité impliquée, les gens préfèrent faire leurs choses plutôt que la voie de quelqu'un d'autre. La tension est donc toujours proche à moins que l'on ne se soucie pas d'une manière ou d'une autre ou si son rôle est clairement suggéré uniquement.
Lorsque je travaille, la programmation de paires n'est pas formalisée, mais nous avons des sessions ad hoc et elles sont généralement brimes. Ce ne sera pas comme "hey co-travailleur, que diriez-vous de certaines programmations extrêmes?" Cela commencerait plus souvent par "Pouvez-vous regarder mon écran?" et tirant une chaise pour eux.
Donc, je ne pense pas que la programmation par paire est morte ou moins populaire, ce n'est qu'un de ces outils que vous n'utilisez pas très souvent parce que cela coûte cher, et pas principalement parce que vous avez deux personnes payées travaillant sur une chose.
Agile est plus commercialisable car il implique différentes parties prenantes ayant des rôles et des responsabilités différents liés au processus de construction de logiciels.
Lorsque dans sa deuxième édition, Kent Beck a élargi la portée des participants au sein de XP, il était tard: les gens ont déjà embrassé d'autres méthodologies car la première XP Version cible les arbitres du code, et c'est ce que la Le public se souvient toujours d'inconsciemment ou non. XP non commercialisé à la naissance.