InfoQ a échangé avec Mike Hugues, senior directeur des solutions innovantes chez iRise, sur l'Enterprise Visualization Platform, une plateforme de prototypages et de rédactions d'exigences.
Hugues explique les évolutions récentes dans la définition des besoins et sa gestion, la manière dont les équipes agiles peuvent les utiliser et les problèmes qu'elles rencontrent au quotidien, et explique l'intérêt des diagrammes et prototypes interactifs pour valider des exigences. Il revient aussi sur l'usage du prototypage interactif dans une démarche lean startup, et ce que le futur pourrait apporter dans la gestion et définition des exigences.
InfoQ : Pourriez-vous nous renseigner sur l'état de l'art dans la définition et la gestion des exigences ? Comment se comporte l'industrie du logiciel ?
Hughes : Pendant des années, l'attrait pour les outils de gestion et de définition des exigences s'est réduit avec l'adoption d'approches Agile avec une transformation culturelle. Je pense que nous voyons un renouveau dans les outils d'exigences enrichissant les méthodes Agiles et aidant les organisations à étendre (scale) leur agilité. La plupart des grandes entreprises ont des équipes dispersées de par le monde, et ces équipes ont un besoin croissant d'outils de gestion et de définition des exigences pour réduire la fracture de communication entre les zones géographiques et fuseaux horaires.
De plus, les organisations commencent à comprendre que l'indicateur principale d'avancement n'est pas du "logiciel qui marche", mais du logiciel à valeur ajoutée. L'Agile et DevOps ont aidé les équipes à développer et mettre en production plus vite, mais elles sentent que le résultat ne correspond pas au besoin client. C'est la raison pour laquelle nous nous focalisons sur la construction, dès le début, d'un ensemble d'exigences qui apportera une véritable valeur métier.
InfoQ : Comment les équipes agile traitent traditionnellement les besoins, et quels sont leurs problèmes quotidiens ?
Hughes : La plupart des équipes agiles emploient des user story pour exprimer les besoins client - c'est à dire les exigences. Généralement, une user story est une phrase, ce qui laisse la part belle à l'interprétation - surtout dans les équipes distribuées. Une simple user story est souvent trop vague et incomplète pour servir à l'implémentation, surtout si tout le monde n'est pas installé dans la même pièce. Le résultat est un rejet en fin de sprint ou impliquant une réécriture importante des user stories.
Tandis que l'Agile apporte bien plus que les cycles en cascade, nous pensons qu'il y a largement de la place pour améliorer ce problème de communication fondamental. En tant que product owner, comment exprimez-vous efficacement l'intention d'une user story ? Comment vérifiez-vous l'adéquation de la solution avec le business quand ils sont sur deux continents distincts ? Comment expliquez-vous ce qu'il faut aux développeurs ? Comment garantissez-vous que les feedbacks ne se perdent pas dans les mails ?
InfoQ : Pourriez-vous expliquer l'utilisation des diagrammes et prototypes interactifs pour transmettre les besoins entre clients et développeurs ?
Hughes : Le meilleur retour vient des clients utilisant en propre les logiciels. Les interactions sont clé. Montrer l'image d'un écran est bien moins efficace que laisser quelqu'un cliquer sur les boutons, entrer les données, naviguer entre les pages, le faire sur son téléphone. C'est ce qui rend les méthodes Agiles puissantes - les clients expérimentent le logiciel plus tôt et font un feedback.
C'est un point clé car les clients peuvent rarement exprimer leurs propres besoins. Il n'y a que dans l'interaction entre l'individu et le produit - ou mieux, un prototype immersif - que vous pouvez découvrir des défauts de design ou d'utilisation, et des erreurs de besoin.
Donc, être capable de créer rapidement et partager des prototypes réalistes, et inclure les retours, permet de valider les user stories. En le couplant avec des diagrammes interactifs pour fournir un contexte, vous arrivez à une compréhension bien plus profonde des besoins et de la valeur métier. Faire tout cela avant de commencer à coder est une manière plus rapide et moins dispendieuse pour construire la bonne solution.
InfoQ : Avec DevOps, les équipes du développement des opérations et les clients travaillent fortement ensemble. Auriez-vous des exemples montrant l'apport de la suite iRise pour la collaboration ?
Hughes : Tandis que DevOps se concentre sur l'intégration continue - build automatique, vérification et déploiement de code - il est important de souligner que le périmètre de DevOps est bien toute la chaîne logiciel. DevOps intègre toutes les personnes impliquées dans la transformation d'une idée IT à de la valeur métier.
iRise permet de prototyper, créer des diagrammes interactifs et de capturer des user stories et de les partager entre l'équipe et les clients avant de commencer à coder. L'intégration avec des plateformes ALM garantit ensuite que l'information capturée dans la plateforme iRise redescend automatiquement dans les systèmes dépendants. Que ce soit pour la planification des tâches, le code ou les scripts de tests, tous les membres de l'équipe devraient non seulement comprendre facilement les user story grâce à des prototypes réalistes, mais aussi comprendre l'intention métier associée.
InfoQ : Peut-on utiliser les prototypes interactifs avec une approche lean startup ? Avez-vous des exemples d'usage dans les organisations ?
Hughes : Au coeur du lean startup, vous avez la boucle build-measure-learn (construire, mesurer, apprendre, NdT). Un prototype réaliste ou du vrai code peuvent servir à cela pour présenter aux clients l'idée d'un minimum viable produit et apprendre de leur retour. Comme les prototypes peuvent se construire et se partager en quelques heures, de nouvelles idées peuvent être testées dans des temporalités plus courtes.
C'est par exemple exactement ce que nous faisons chez iRise quand nous explorons de nouvelles fonctionnalités. En dévoilant de nouvelles idées aux clients avec un prototype, nous sommes capables d'apprendre et d'adapter notre approche pour garantir que l'équipe de développement se concentre sur la construction d'éléments, qui nous le savons, apportent de la valeur aux clients.
InfoQ : Qu'attendez-vous comme évolution sur la définition et la gestion des exigences ?
Hughes : La multiplication des produits SaaS ont fourni aux responsables de la définition des logiciels beaucoup d'options pour poser les problèmes métier, les décrire et vérifier les solutions, et dès lors planifier et suivre les travaux. En comparaison avec les plateformes installables de gestion des besoins avec beaucoup de fonctionnalités, les nouvelles solutions se concentrent sur la facilité d'usage et sont dans les nuages pour éviter les problèmes d'installation de logiciels.
Cependant, la plupart des produits se concentrent sur une partie des fonctions du développement de produits, ce qui signifie qu'en tant que responsable de produits, vous avez toujours besoin d'utiliser plusieurs produits différents pour bien faire votre travail. Cette fragmentation des outils rend difficile une vision 360 degrés du produit en construction. Les outils de définition et de gestion des exigences doivent évoluer, pas seulement pour plus de facilité d'utilisation et de flexibilité dans le déploiement, mais aussi pour fournir toutes les fonctionnalités dont les responsables produits ont besoin, et pour échanger vite et facilement les informations avec les autres plateformes qui participent au flux de production des logiciels.