Scrum pour un progiciel

Les entreprises utilisent fréquemment des progiciels pour 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 nécessite d'écrire pas ou peu de code et de faire ce qu'on appelle du paramétrage pour adapter le progiciel aux besoins des utilisateurs[1]

Evidemment 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 les 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 : le feedback, en les impliquant très régulièrement.

Notes

[1] quand j'interviens dans des projets avec progiciel, le choix de ce progiciel est déjà fait. Il me semble que ce choix soit 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. Je pense que 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...