Voici une analogie intéressante qui m'a été exposée il y a peu :

Si on considère une équipe projet comme une usine de transformation des besoins d'un client en un produit final, on peut lui appliquer la théorie des contraintes comme dans une usine traditionnelle.
Dans ce cas, on tente de réduire le volume des encours, c'est à dire les produits intermédiaires déjà réalisés mais qui n'ont pas encore été intégré dans le produit final : spécifications écrites, modèle de conception, et même morceaux de code... Ils représentent de l'argent investi stocké dans l'entrepôt du logiciel. Qui plus est ce stock est une denrée périssable, car les besoins évoluent souvent très vite.
Les méthodes agiles essaient donc de minimiser ce stock et permettre au client de changer d'idée facilement sans impacter la réussite du projet.

A quand la mise en oeuvre d'un kanban de Use Cases ?

Je ne saurais trop vous conseiller l'article de Martin Fowler qui détaille les grands principes de l'intégration continue :

• Maintenir un référentiel unique de source
• Automatiser la construction du projet
• Inclure les tests dans la construction du projet
• Tout le monde doit committer ses changements au moins une fois par jour
• Chaque commit lance la reconstruction du projet sur le serveur d'intégration
• La construction (avec les tests) du projet doit rester rapide
• Jouer les tests dans un environnement identique à celui de production
• N'importe qui doit pouvoir récupérer le dernier exécutable facilement
• Tout le monde doit savoir ce qui se passe
• Automatiser le déploiement du projet

Les avantages de l'intégration continue ne sont pas seulement techniques, mais aussi organisationnels. Et en plus vous avez là un nouveau canal de communication. Voici quelques points dans le désordre.

D'abord, vous devez concevoir un script pour construire votre projet en un clic, ce qui veut dire que tout le monde construit son projet de la même façon. Et comme le projet est construit uniquement à partir des données du référentiel sur une machine séparée, vous êtes sûr d'avoir tous les éléments du projet dans votre référentiel.

Les problèmes d'intégration sont minimes car tout le monde doit committer régulièrement.

Comme les tests sont joués après chaque commit, il est plus facile d'identifier un bug dans le code qui a été modifié.

Le test et le déploiement dans un environnement identique à celui de production minimisent les risques et le temps d'installation du projet dans son environnement final.

Le fait de construire le projet après chaque commit responsabilise les membres de l'équipe, car en cas d'échec on le voit tout de suite et on connait également les dernières personnes à avoir modifier le code... De plus, lorsque l'intégration est en échec, chacun sait qu'il est inutile de mettre à jour son projet en local au risque de se retrouver bloqué.

Autre avantage et non des moindres, vous disposez ainsi d'un version opérationnelle en permanence. Cette version peut servir à des démonstrations, et donc montrer l'avancement du projet directement au travers de l'application.

Enfin, on peut inclure dans la construction du projet des outils d'analyse du code. Ces métriques viennent compléter les rapports de builds et de tests, et peuvent être utilisées pour améliorer la qualité du code.


Toutes ces pratiques peuvent être adoptées progressivement. Elles améliorent incontestablement la productivité et la qualité d'un projet. Vous n'avez donc aucune excuse pour ne pas vous y mettre !

Suite à une pression incessante, je me suis enfin résolu à ouvrir cette nouvelle catégorie : le développement AGILE en .Net !

Vous devriez y trouver :

• des explications sur les outils qu'on utilise
• des retours d'expérience
• des liens vers d'autres articles intéressants
• ...

Et surtout, partagez avec nous vos découvertes, vos expériences et vos commentaires.

Enfin, si vous souhaitez vous lancer dans l'aventure, MCNEXT peut vous aider dans votre démarche.