jeu de planification

XP planning répond à deux questions clés dans le développement de logiciels: prédire ce qui sera accompli à la date d’échéance et déterminer ce qu’il faut faire ensuite. L’accent est mis sur le pilotage du projet – qui est assez simple – plutôt que sur la prédiction exacte de ce qui sera nécessaire et combien de temps cela prendra – ce qui est assez difficile., Il y a deux étapes de planification clés dans XP, répondant à ces deux questions:

la planification des versions est une pratique où le client présente les fonctionnalités souhaitées aux programmeurs, et les programmeurs estiment leur difficulté. Avec les estimations de coûts en main, et avec la connaissance de l’importance des caractéristiques, le client établit un plan pour le projet. Les plans de lancement initiaux sont nécessairement imprécis: ni les priorités ni les estimations ne sont vraiment solides, et tant que l’équipe ne commencera pas à travailler, nous ne saurons pas à quelle vitesse ils iront., Cependant, même le premier plan de publication est suffisamment précis pour la prise de décision, et les équipes XP révisent régulièrement le plan de publication.

la planification itérative est la pratique par laquelle l’équipe reçoit une direction toutes les deux semaines. Les équipes XP construisent des logiciels en « itérations” de deux semaines, fournissant des logiciels utiles à la fin de chaque itération. Lors de la planification de L’itération, le client présente les fonctionnalités souhaitées pour les deux prochaines semaines. Les programmeurs les décomposent en tâches et estiment leur coût (à un niveau de détail plus fin que dans la planification des versions)., En fonction de la quantité de travail accompli dans l’itération précédente, l’équipe s’inscrit pour ce qui sera entrepris dans l’itération en cours.

ces étapes de planification sont très simples, mais elles fournissent de très bonnes informations et un excellent contrôle de la direction entre les mains du client. Toutes les deux semaines, la quantité de progrès est entièrement visible. Il n’y a pas de « quatre-vingt-dix pour cent terminé” dans XP: Une histoire de fonctionnalité a été terminée, ou ce n’était pas le cas., Cet accent mis sur la visibilité se traduit par un joli petit paradoxe: d’une part, avec autant de visibilité, le client est en mesure d’annuler le projet si l’avancement n’est pas suffisant. D’autre part, les progrès sont si visibles, et la capacité de décider ce qui sera fait ensuite est si complète, que les projets XP ont tendance à fournir plus de ce qui est nécessaire, avec moins de pression et de stress.

tests client

dans le cadre de la présentation de chaque fonctionnalité souhaitée, le client XP définit un ou plusieurs tests d’acceptation automatisés pour montrer que la fonctionnalité fonctionne., L’équipe construit ces tests et les utilise pour prouver à elle-même, et au client, que la fonctionnalité est implémentée correctement. L’automatisation est importante car dans la presse du temps, les tests manuels sont ignorés. C’est comme éteindre vos lumières quand la nuit devient plus sombre.

Les meilleures équipes XP traitent leurs tests clients de la même manière qu’elles le font pour les tests programmeurs: une fois le test exécuté, l’équipe le fait fonctionner correctement par la suite. Cela signifie que le système ne fait que s’améliorer, toujours en avant, jamais en arrière.,

petites versions

Les équipes XP pratiquent les petites versions de deux manières importantes:

Tout d’abord, l’équipe publie des logiciels en cours d’exécution, testés, offrant une valeur métier choisie par le client, à chaque itération. Le client peut utiliser ce logiciel à n’importe quelle fin, qu’il s’agisse d’une évaluation ou même d’une mise à disposition aux utilisateurs finaux (fortement recommandé). L’aspect le plus important est que le logiciel est visible, et remis au client, à la fin de chaque itération. Cela garde tout ouvert et tangible.

Deuxièmement, les équipes XP publient également fréquemment à leurs utilisateurs finaux., Les projets Web XP sortent aussi souvent que tous les jours, projets internes mensuels ou plus fréquemment. Même les produits emballés sous film rétractable sont expédiés aussi souvent que trimestriellement.

il peut sembler impossible de créer de bonnes versions aussi souvent, mais les équipes XP le font tout le temps. Voir Intégration Continue pour plus d’informations à ce sujet, et notez que ces versions fréquentes sont maintenues fiables par L’obsession de XP pour les tests, comme décrit ici dans customer Tests and Test-Driven Development.

conception Simple

Les équipes XP construisent des logiciels selon une conception simple mais toujours adéquate., Ils commencent simplement, et grâce aux tests de programmeur et à l’amélioration de la conception, ils le gardent de cette façon. Une équipe XP maintient la conception exactement adaptée aux fonctionnalités actuelles du système. Il n’y a pas de mouvement gaspillé, et le logiciel est toujours prêt pour la prochaine étape.

la conception dans XP n’est pas une chose unique, ou une chose initiale, c’est une chose tout le temps. Il y a des étapes de conception dans la planification des versions et la planification des itérations, et les équipes participent à des sessions de conception rapides et à des révisions de conception via le refactoring, tout au long du projet., Dans un processus incrémental et itératif comme la programmation extrême, une bonne conception est essentielle. C’est pourquoi l’accent est mis sur la conception tout au long du développement.

programmation par paires

tous les logiciels de production dans XP sont construits par deux programmeurs, assis côte à côte, sur la même machine. Cette pratique garantit que tout le code de production est examiné par au moins un autre programmeur, et se traduit par une meilleure conception, de meilleurs tests et un meilleur code.

Il peut sembler inefficace d’avoir deux programmeurs faisant « le travail d’un programmeur”, mais l’inverse est vrai., La recherche sur la programmation par paires montre que l’appariement produit un meilleur code à peu près en même temps que les programmeurs travaillant seuls. C’est vrai: deux têtes valent vraiment mieux qu’une!

certains programmeurs s’opposent à la programmation par paires sans jamais l’essayer. Il faut un peu de pratique pour bien faire, et vous devez le faire bien pendant quelques semaines pour voir les résultats. Quatre-vingt-dix pour cent des programmeurs qui apprennent la programmation par paires le préfèrent, nous le recommandons donc fortement à toutes les équipes.

L’appariement, en plus de fournir un meilleur code et des tests, sert également à communiquer les connaissances à l’ensemble de l’équipe., Au fur et à mesure que les paires changent, tout le monde bénéficie des connaissances spécialisées de chacun. Les programmeurs apprennent, leurs compétences s’améliorent, ils deviennent plus précieux pour l’équipe et pour l’entreprise. Le jumelage, même seul en dehors de XP, est une grande victoire pour tout le monde.

développement piloté par les tests

La programmation extrême est obsédée par la rétroaction, et dans le développement de logiciels, une bonne rétroaction nécessite de bons tests. Les meilleures équipes XP pratiquent le « développement piloté par les tests », travaillant dans des cycles très courts d’ajout d’un test, puis de le faire fonctionner., Presque sans effort, les équipes produisent du code avec une couverture de test de près de 100%, ce qui est un grand pas en avant dans la plupart des magasins. (Si vos programmeurs font déjà des tests encore plus sophistiqués, plus de puissance pour vous. Continuez, cela ne peut que vous aider!)

il ne suffit pas d’écrire des tests: vous devez les exécuter. Ici aussi, la programmation extrême est extrême. Ces « tests de programmeur », ou” tests unitaires  » sont tous collectés ensemble, et chaque fois qu’un programmeur libère un code dans le référentiel (et que les paires libèrent généralement deux fois par jour ou plus), chacun des tests de programmeur doit s’exécuter correctement., À cent pour cent, tout le temps! Cela signifie que les programmeurs obtiennent des commentaires immédiats sur leur façon de faire. De plus, ces tests fournissent un soutien inestimable à mesure que la conception du logiciel est améliorée.

amélioration de la conception (Refactoring)

Extreme Programming se concentre sur la création de valeur métier à chaque itération. Pour y parvenir tout au long du projet, le logiciel doit être bien conçu. L’alternative serait de ralentir et finalement coincé., XP utilise donc un processus d’amélioration continue de la conception appelé Refactoring, d’après le titre du livre de Martin Fowler, « Refactoring: Improving the Design of Existing Code”.

Le processus de refactorisation se concentre sur l’élimination de la duplication (un signe d’une mauvaise conception), et sur l’augmentation de la « cohésion” du code, tout en abaissant le « couplage”. Une cohésion élevée et un faible couplage sont reconnus comme les caractéristiques d’un code bien conçu depuis au moins trente ans. Le résultat est que les équipes XP commencent avec un bon design simple et ont toujours un bon design simple pour le logiciel., Cela leur permet de maintenir leur vitesse de développement, et en fait d’augmenter généralement la vitesse à mesure que le projet avance.

le Refactoring est, bien sûr, fortement soutenu par des tests complets pour être sûr que, à mesure que la conception évolue, rien n’est cassé. Ainsi, les tests client et les tests programmeur sont un facteur d’activation critique. Les pratiques XP se soutiennent mutuellement: elles sont plus fortes ensemble que séparément.

Intégration Continue

Les équipes de programmation Extreme maintiennent le système entièrement intégré à tout moment. Nous disons que les builds quotidiens sont pour les mauviettes: les équipes XP construisent plusieurs fois par jour., (Une équipe XP de quarante personnes construit au moins huit ou dix fois par jour!)

l’avantage de cette pratique peut être vu en repensant aux projets dont vous avez peut-être entendu parler (ou même fait partie) où le processus de construction était hebdomadaire ou moins fréquent, et conduisait généralement à « l’enfer de l’intégration”, où tout s’est cassé et personne ne savait pourquoi.

Une intégration peu fréquente entraîne de graves problèmes sur un projet logiciel., Tout d’abord, bien que l’intégration soit essentielle à l’expédition d’un bon code de travail, l’équipe n’y est pas pratiquée et elle est souvent déléguée à des personnes qui ne connaissent pas l’ensemble du système. Deuxièmement, le code rarement intégré est souvent – je dirais généralement-du code buggé. Des problèmes se glissent au moment de l’intégration qui ne sont détectés par aucun des tests effectués sur un système non intégré. Troisièmement, un processus d’intégration faible conduit à de longs gels de code., Les gels de Code signifient que vous avez de longues périodes de temps où les programmeurs pourraient travailler sur des fonctionnalités importantes pouvant être expédiées, mais que ces fonctionnalités doivent être retenues. Cela affaiblit votre position sur le marché ou auprès de vos utilisateurs finaux.

propriété Collective du Code

sur un projet de programmation extrême, n’importe quelle paire de programmeurs peut améliorer n’importe quel code à tout moment. Cela signifie que tout le code bénéficie de l’attention de nombreuses personnes, ce qui augmente la qualité du code et réduit les défauts., Il y a également un autre avantage important: lorsque le code appartient à des individus, les fonctionnalités requises sont souvent placées au mauvais endroit, car un programmeur découvre qu’il a besoin d’une fonctionnalité quelque part dans le code qu’il ne possède pas. Le propriétaire est trop occupé pour le faire, donc le programmeur place la fonctionnalité dans son propre code, où elle n’appartient pas. Cela conduit à un code laid, difficile à maintenir, plein de duplication et avec une faible (mauvaise) cohésion.

la propriété Collective pourrait être un problème si les gens travaillaient aveuglément sur du code qu’ils ne comprenaient pas., XP évite ces problèmes grâce à deux techniques clés: le programmeur teste les erreurs de capture, et la programmation par paires signifie que la meilleure façon de travailler sur du code inconnu est de coupler avec l’expert. En plus d’assurer de bonnes modifications en cas de besoin, cette pratique diffuse les connaissances dans toute l’équipe.

norme de codage

Les équipes XP suivent une norme de codage commune, de sorte que tout le code du système semble avoir été écrit par un seul individu – très compétent–., Les spécificités de la norme ne sont pas importantes: ce qui est important, c’est que tout le code semble familier, à l’appui de la propriété collective.

métaphore

Les équipes de programmation extrême développent une vision commune du fonctionnement du programme, que nous appelons la « métaphore”. À son meilleur, la métaphore est une description évocatrice simple de la façon dont le programme fonctionne, comme « ce programme fonctionne comme une ruche d’abeilles, sortir pour le pollen et le ramener à la ruche” comme une description pour un système de recherche d’informations basé sur l’agent.

parfois, une métaphore suffisamment poétique ne se pose pas., Dans tous les cas, avec ou sans imagerie vivante, les équipes XP utilisent un système commun de noms pour être sûr que tout le monde comprend comment le système fonctionne et où chercher pour trouver la fonctionnalité que vous recherchez, ou pour trouver le bon endroit pour mettre la fonctionnalité que vous êtes sur le point d’ajouter.

rythme durable

Les équipes de programmation extrême sont là pour le long terme. Ils travaillent dur, et à un rythme qui peut être maintenu indéfiniment. Cela signifie qu’ils font des heures supplémentaires quand c’est efficace, et qu’ils travaillent normalement de manière à maximiser la productivité semaine après semaine., Il est assez bien compris ces jours-ci que les projets de marche de la mort ne sont ni productifs ni produire des logiciels de qualité. XP équipes sont là pour gagner, pas pour mourir.

Conclusion

La programmation extrême est une discipline de développement logiciel basée sur des valeurs de simplicité, de communication, de rétroaction et de courage. Il fonctionne en réunissant toute l’équipe en présence de pratiques simples, avec suffisamment de retours pour permettre à l’équipe de voir où elle en est et d’adapter les pratiques à leur situation unique.