Parallel Agile – faster delivery, fewer defects, lower cost

Depuis les débuts du logiciel, les gens se sont demandés pourquoi il n'est pas possible d'accélérer les projets logiciels en ajoutant simplement du personnel. C'est ce qu'on appelle parfois le problème " neuf femmes ne peuvent pas faire un bébé en un mois ". Le traité le plus célèbre déclarant que cela est impossible est le livre de Fred Brooks de 1975, The Mythical Man-Month, dans lequel il déclare que " l'ajout de programmeurs à un projet logiciel tardif le rend plus tardif ", et en effet cela s'est avéré largement vrai au cours des décennies.

Aidé par un générateur de code piloté par domaine qui crée rapidement du code de base de données et d'API, Parallel Agile (PA) permet d'obtenir une compression importante du calendrier en utilisant le parallélisme : autant de développeurs que nécessaire peuvent développer indépendamment et simultanément les scénarios, du prototype initial au code de production. Les projets peuvent s'étendre grâce à une dotation en personnel élastique, plutôt qu'en étirant les calendriers pour des efforts de développement plus importants. La compression des plannings avec une grande équipe de développeurs travaillant en parallèle est analogue à l'accélération matérielle des problèmes de calcul en utilisant des CPU parallèles.

L'AP présente des similitudes et des différences avec d'autres approches Agiles. Comme la plupart des méthodes Agiles, PA " codifie tôt " et utilise le feedback des logiciels exécutables pour piloter les exigences et la conception. PA utilise le prototypage technique comme stratégie d'atténuation des risques, pour aider à vérifier les exigences de faisabilité et pour évaluer différentes architectures et technologies techniques.

Contrairement à de nombreuses méthodes Agiles, PA ne prend pas en charge la " conception par refactoring " et ne pilote pas les conceptions à partir de tests unitaires. Au lieu de cela, PA utilise une approche de conception minimaliste basée sur UML (Agile/ICONIX) qui commence par un modèle de domaine pour faciliter la communication au sein de l'équipe de développement, et partitionne le système selon les limites des cas d'utilisation, ce qui permet un développement parallèle. Parallel Agile est entièrement compatible avec le modèle ICSM (Incremental Commitment Spiral Model), qui implique un effort simultané d'une équipe d'ingénierie système, d'une équipe de développement et d'une équipe de test travaillant aux côtés des développeurs.

Les auteurs ont fait des recherches et perfectionné le processus d'AP pendant plusieurs années sur de multiples projets d'essai auxquels ont participé plus de 200 développeurs. L'exemple de projet du livre détaille la conception de l'un de ces projets d'essai, un système de sécurité routière pour les foules.