Scrum pour un progiciel

Une pratique de développement répandue, avec quel impact sur l'agilité ?

Les entreprises utilisent fréquemment des progiciels ou des plateformes pour développer des applications de leur système d’information. J’ai noté qu’elles considéraient ce type de développement comme bien adapté à une approche agile. Certes un progiciel facilite la livraison de versions à un rythme rapide, mais cela ne suffit pas pour être agile.

En principe, un développement basé sur un progiciel ou une plateforme low code nécessite d’écrire pas ou peu de code —d’où l’appellation low code ou no code — et de faire ce qu’on appelle du paramétrage pour adapter le progiciel aux besoins des utilisateurs1

Évidemment un développement basé sur un progiciel n’inclura pas les mêmes pratiques agiles qu’un développement normal, notamment en ce qui concerne les pratiques liées au code et au test unitaire.

C’est aussi dans la composition de l’équipe et dans son équilibre qu’il y a des impacts. En effet, le progiciel permet de produire plus rapidement (quand il ne s’agit que de paramétrer), mais ne réduit pas le besoin de faire des tests fonctionnels. Il faudrait donc que les ressources en testeurs soit supérieures à celle de développeurs afin d’éviter un goulet d’étranglement.

Globalement le travail fait par les spécialistes du progiciel ne représentera une part aussi importante que d’habitude des développeurs pour produire une user story.

Cela sera encore plus vrai si la définition de fini de l’équipe inclut l’écriture de documentation utilisateur.

Et le Product Owner va être occupé à comprendre ce qu’offre le progiciel et à essayer de faire rentrant les besoins des utilisateurs dedans.

L’objectif est de rester dans le paramétrable du progiciel pour ne pas développer du spécifique, mais le risque est grand de faire un produit qui ne convient pas aux utilisateurs. La solution : les boucles de feedback, en les impliquant très régulièrement.


  1. quand j’interviens dans des projets avec progiciel, le choix de ce progiciel est déjà fait. Il me semble que ce choix est parfois fait trop tôt, sans savoir vraiment ce que veulent les utilisateurs. Un des principes du Lean est de différer une décision le plus tard possible. C’est une notion qu’il faudrait introduire dans les entreprises qui ont des processus qui les poussent à faire très tôt un choix technique lourd de conséquences. D’autant plus que bien souvent ceux qui sont à l’origine de ces choix ne sont pas dans l’équipe de développement et n’auront pas à les assumer. ↩︎

Voir aussi