Extreme programming est une méthodologie qui s'inscrit dans le modèle agile, il tend à pousser des bonnes pratiques de conception logiciel et de management à l'extrème:
Les code review sont importantes, au lieu de le faire une fois qu'une fonctionnalité est développée, faisons le tout le temps: Pair Programming
Tester l'application permet de vérifier qu'elle est fonctionnel, autant autant automatiser les tests et tester l'application à chaque changement: Unittests
Une application n'est utile que lorsqu'elle est utilisée, autant mettre en production chaque fonctionnalité dès qu'elle est prête: Continuous delivery
Chaque fonctionnalité requise par le client peut cacher tout un ensemble de sous-fonctionnalités, il est important de pouvoir décomposer une fonctionnalité importante dans un ensemble de sous-fonctionnalité précises: Epics et User Stories
Avoir de la visibilité de l'avancement du projet ainsi que de chacune de ses fonctionnalités permet à l'équipe de d'être mieux coordonnée. Au lieu de multiplier les réunions et les diagrammes, il est préférable d'avoir un grand tableau blanc séparé en plusieurs colonne (To do, doing, done) où les user stories sont placées sur des post-it et déplacé de colonne en colonne.
Chaque développeur devrait être capable de pouvoir aider ou remplacer ses collègues sur une tâche. Les devs doivent donc être multi-rôle au lieu d'être expert: Collective code ownership. Pour être multirôle, il faut toucher à tout et donc changer régulièrement de place au sain de l'équipe.
Pour aider la collaboration, il est important de mettre en place des standarts de développement que l'équipe accepte de suivre: Coding rules. (Exemple de coding rules: Python PEP8, Java). Cependant respecter des conventions de code n'est pas suffisant pour avoir du "beau code" (Beyond PEP8, Python PEP20), il est important de retravailler un bout de code encore et encore pour le rendre plus simple, plus lisible, plus rapide et plus court: Code Refactoring (vrai exemple de l'évolution d'une fonction en python)
En plus de l'ensemble de ces bonnes pratique, on doit également à XP l'annalogie de la dette technique.
Dans la même logique que Scrum, XP se veut dynamique, il est de la responsabilité de l'équipe de faire évoluer ces pratiques; le client occupe aussi une part importante et se doit d'être disponible pour répondre aux questions.
La livraison continue est une méthodologie qui veut que chaque changement doit se retrouver en production. Pour y arriver, il faut mettre en place un pipeline de contrôle automatique qui va acheminer une nouvelle fonctionnalité du PC du développeur au serveur de production.
Cependant toujours mettre en ligne n'est pas l'idéal: la plupart des fonctionnalités ne peuvent pas être développées en un seul commit. Pour éviter de se retrouver avec des demi-fonctionnalités en ligne, on peut avoir recourt à deux techniques:
La première est le Blue-Green Deployment, deux environnements de production co-existent: le premier avec "l'ancienne" version qui n'est plus modifiée et le second avec la "nouvelle" version où les fonctionnalités sont ajoutées petit à petit. L'équipe décide du moment où la nouvelle version remplacera l'ancienne version dans l'autre environnement.
La seconde est le Feature Toggle Cette fois la "disponibilité" d'une fonctionnalité n'est plus lié à son environnement mais via du code, chaque fonctionnalité doit explicitement être décrite comme accessible aux utilisateurs.
Quelques commitstrips:
Toutes les boites ont un environnement de développement, puis quelques chanceux ont un environnement de production en plus. ~Lu quelque part sur internet
Gros changement de culture, les devs travaillent maintenant directement avec les ops (ce qui n'était pas le cas avant).
Lean est une méthodologie inventée par Toyota, LSD reprend les principes de Lean pour les appliquer au développement. Cette méthodologie s'inscrit dans le modèle agile.
Tout ce qui ralentit le déploiement de fonctionnalités utiles doit être retravaillé pour optimiser le processus de développement.
Développer une application demande de la créativité, il est crucial que les développeurs puissent s'améliorer en leur laissant le temps nécessaire pour experimenter et pour faire des recherches.
Prendre des décisions à priori (utiliser un SGBD plutôt qu'un autre, sql vs nosql) sans réellement savoir si c'est le bon choix peut cacher une terrible dette technique. Si il y a moyen de reporter une décision à plus tard, il est crucial de le faire.
Voir Continuous Delivery
Voir Extreme Programming
Voir Kanban
Méthodologie LSD qui reprend et renforce certains concepts d'XP.
En opposition à scrum/xp qui cassent la hiérarchie mise en place et forcent les gens à devenir multirôle, Kanban préconise de faire évoluer le processus en place (en maintenant rôles, titres et expertises) avec une succession de petit changement. Chaque individu de l'équipe est encourager à prendre des initiatives pour faire évoluer la méthodologie actuelle vers un mieux. Dans ce sens, kanban applique vraiment le 5e principe de LSD : Empower the Team.
Sur cette base, kanban ajoute quelques bonnes pratiques ayant pour but de renforcer le 7e principe de LSD : See the whole en reprenant le grand tableau blanc d'XP pour y ajouter les éléments suivant:
1) Enrichir le tableau avec de nouvelles colonnes pour que chacun, des analystes aux testeurs, puisse se rendre compte du travail des autres. 2) Limiter le travail en cours en inscrivant clairement le nombre maximal de carte qui peuvent se trouver dans une même colonne. 3) Donner des niveaux de priorités à chaque carte.
