Développement d’Adobe XD – Redéfinition des bêtas

La création de logiciels et leur développement peuvent s’avérer très gratifiants. J’adore cette activité, c’est pour moi une vraie passion. J’ai la chance de diriger une équipe de développement très talentueuse pour mettre au point, chez Adobe, une nouvelle initiative appelée Adobe Experience Design CC (Adobe XD, pour faire court). L’un de nos principaux objectifs, lors des premières étapes du processus de développement d’Adobe XD, a été de repenser notre manière de créer et fournir de nouveaux logiciels : de veiller à entretenir un dialogue avec la communauté du design afin de créer un produit qui corresponde à ses besoins et à ses désirs. D’après mon expérience, établir ce genre de processus n’a pas toujours été facile.

À un moment de ma carrière, j’avais vraiment envie de passer à autre chose. Avant de confirmer ma passion pour la création de logiciels, j’ai dû lutter contre deux problèmes majeurs.

Le premier était que j’avais travaillé sur un trop grand nombre de projets de logiciels où il devenait vraiment difficile de faire quoi que ce soit : la résolution des bogues était pénible, l’ajout de fonctionnalités quasi impossible. Toucher à une ligne de code revenait à tenter de réparer ou d’ajouter des conduites d’eau et de vapeur dans une usine à gaz, sans le moindre plan de l’installation ni le moindre moyen de valider l’intervention. Seuls les développeurs initiaux (les héros ou les gourous) avaient le courage de tenter quoi que ce soit sur la base de code, parce qu’ils disposaient d’un contexte plus vaste que les autres programmeurs. La qualité ne cessait de se détériorer et la maintenance devenait extrêmement coûteuse. Ce n’était ni amusant, ni gratifiant, ni intéressant et surtout, c’était très mauvais pour les utilisateurs finaux qui ne recevaient qu’une solution très approximative.

Ce qui m’amène au second problème. De nombreux projets sur lesquels j’ai travaillés, malgré les intentions affirmées de répondre aux besoins des utilisateurs, étaient souvent conçus en expédiant les fonctionnalités. Les fonctionnalités étaient traitées de manière précipitée du côté de l’ingénierie (implémentation trop rapide) comme du côté de la conception et du produit (sans réelle validation par les utilisateurs). De ce fait, si le produit sortait bien au jour dit, c’était en réalité une version défectueuse qui ne correspondait pas aux souhaits initiaux des utilisateurs.

Pourquoi assiste-t-on à ce genre de phénomène indésirable ?

Le développement de logiciel est encadré par trois paramètres clés : la qualité, le temps (déterminé par la date de sortie) et le périmètre (pour les fonctionnalités). Au sein de notre équipe, nous appelons ça le « triangle de fer » (c’est notre version du triangle de gestion de projet). Quel que soit le projet, on ne peut jouer que sur deux de ces trois paramètres. Si on essaie d’imposer des contraintes aux trois, l’un cède. Par exemple, si l’on réduit le temps et le périmètre, la qualité en souffre. Si l’on privilégie la qualité et le périmètre, la date de sortie ne peut être respectée.

Trop souvent, le désir de multiplier les fonctionnalités (c’est-à-dire d’accroître le périmètre) dans un temps donné dégrade considérablement la qualité (et la performance).

https://blogsimages.adobe.com/creative/files/2016/06/Img-1-1.png

Compte tenu de tout cela, pourquoi continuer à travailler dans le développement de logiciels, me demanderez-vous ?

Eh bien, naturellement, d’autres ont été confrontés à ces problèmes, ont compris qu’il existait une meilleure voie et ont commencé à développer des méthodes et des solutions. Et de très bonnes.

De meilleures pratiques d’ingénierie sont apparues, telles que le développement agile ou la programmation extrême, axées sur l’intégration de la qualité au sein de l’effort d’ingénierie. L’objectif était de ne pas mettre en péril le paramètre « qualité » du triangle de fer, de livrer à une cadence régulière et d’ajouter des fonctionnalités au fil du temps. Ceci nous a permis une plus grande souplesse en matière de périmètre : nous pouvions dès lors développer des logiciels offrant une facilité de maintenance accrue parce que nous prenions le temps de construire non seulement les fonctionnalités dont nous avions besoin, mais aussi un ensemble complet de tests automatisés qui nous garantissaient de savoir en permanence, même à longue échéance, si telle fonctionnalité ou tel fragment de code continuait ou non à fonctionner.

J’ai commencé à mettre en œuvre ces pratiques pour un projet open source d’Apache, puis dans des projets commerciaux. L’adoption de ces pratiques améliorées a transformé ma vie d’ingénieur logiciel en facilitant et en améliorant considérablement le développement logiciel. Et j’ai recommencé à prendre plaisir à créer des logiciels !

Le deuxième grand changement a été une évolution majeure de la manière de gérer le développement de nos produits, de l’idée à l’implémentation. Avec des méthodologies telles que le Lean Product Development, l’accent est largement mis sur l’identification des problèmes réels des utilisateurs, ce qui permet d’émettre des hypothèses spécifiques que l’on peut confirmer (ou infirmer) par expérimentation, et sur l’emploi d’analyses de données au lieu d’opinions individuelles pour justifier les décisions. Ceci a abouti à des solutions mieux construites et à une meilleure adéquation entre les solutions et les problèmes qu’elles sont censées régler.

Des méthodologies comme le développement agile et le lean product development n’ont rien de nouveau, mais elles ont changé ma vie professionnelle lorsque, après les avoir découvertes et adoptées, j’ai réalisé qu’elles permettaient de fournir des systèmes logiciels plus robustes et répondant mieux aux attentes et aux besoins des utilisateurs.

Et aujourd’hui, j’ai le plaisir d’appliquer ces méthodes à un projet ambitieux : Adobe XD.

Il y a quelques mois, notre équipe a livré la première Preview d’Adobe XD, une solution de conception, de prototypage et de partage d’expériences pour les applications mobiles, les sites web et autres expériences sur écran. La Preview, que l’on peut traduire par « technologie d’aperçu » désigne la méthode où l’on commence doucement mais sûrement et où l’on augmente rapidement grâce à la communauté d’utilisateurs.

Le premier élément de cette solution est la version bureau Mac OS X d’Adobe XD. Vous pouvez voir ci-dessous une capture d’écran de cette application, avec son interface simple et axée sur l’utilisateur.

https://blog.adobe.com/media_f780a5e8e821aed336f139d1f13ac1c5875f1043.gif

Depuis le début, nous avons développé Adobe XD afin qu’il procure vitesse et qualité. Nous entendons par là qu’il doit permettre aux designers de concevoir à la vitesse de la pensée, sans la moindre friction. Les concepteurs nous ont indiqué qu’une performance ou une qualité médiocre est non seulement frustrante, mais interrompt en outre leur expression créative et leur capacité à produire et exécuter rapidement un volume de travail élevé. C’est extrêmement important car ils créent des expériences pour de nombreux écrans (par exemple applications, sites web et éléments portables).

En abordant ce projet, nous savions qu’il nous faudrait du temps pour parvenir au bon résultat. Nous savions aussi que nous voulions pouvoir présenter rapidement notre solution aux utilisateurs pour en tirer les enseignements et les mettre en application. Et nous savions que nous voulions fournir une expérience de grande qualité.

Comment avons-nous fait pour y parvenir ?

Nous avons commencé sur une base restreinte mais robuste. Ensuite, nous avons procédé à des itérations.

Nous avons tous connu des versions « bêta » de logiciels offrant de nombreuses fonctionnalités, mais qui manquaient de qualité, de performance, voire des deux. La première bêta cherche à montrer l’ensemble des fonctionnalités qui seront présentes dans le produit final, mais au détriment de la « profondeur des fonctionnalités » (parce que le travail et les détails nécessaires au développement complet d’une fonctionnalité réclament du temps) et au détriment de la qualité (parce qu’on n’a « pas le temps pour ça »). Elle est suivie de versions qui tentent d’améliorer la profondeur des fonctionnalités et la qualité. Mais dans la précipitation qui s’impose lorsque l’on cherche à intégrer de très nombreuses fonctionnalités à la première bêta, on prend des raccourcis qui hypothèquent la capacité à « rattraper les choses » ensuite. Tenter de stabiliser par la suite l’intégralité du produit sans disposer d’un ensemble robuste de tests automatisés et de points de contrôle de qualité est extrêmement difficile et chronophage. Cette approche est illustrée ci-dessous.

https://blogsimages.adobe.com/creative/files/2016/06/Img-2-1.png

Scénario non idéal : Création rapide de fonctionnalités superficielles et manque croissant de qualité

Elle est, pour de nombreuses raisons, loin d’être idéale. Les principales raisons dérivent des motifs mêmes de la sortie d’une version « bêta ». Il s’agit de présenter la vision de l’outil en cours de développement et les fonctionnalités spécifiques en cours de construction. On souhaite disposer de retours sur ces deux aspects à titre d’information pour l’orientation et l’implémentation du produit. L’objectif est alors d’accroître les probabilités de succès du produit.

Intégrer tôt un trop grand nombre de fonctionnalités introduit un risque majeur : la vision et l’ambition du produit peuvent être entachées par une réputation de mauvaise qualité ou de performance médiocre, et les retours risquent de se concentrer sur les bogues et le manque de performance plutôt que sur la vision et les fonctionnalités proprement dites. On passe ainsi à côté des enseignements les plus précieux que peuvent fournir les utilisateurs.

Pour augmenter nos chances d’apprendre et de connaître la réussite, nous avons décidé de commencer avec un ensemble minimal de fonctionnalités présentant les caractéristiques suivantes :

• profondeur, avec affinage des détails qui comptent le plus pour les utilisateurs
• conception solide et plan d’implémentation
• conformité avec nos normes de qualité

Ensuite, nous ajoutons de la valeur au fil du temps, en fonction des retours des utilisateurs, en accroissant la robustesse des fonctionnalités existantes et en dégageant des priorités d’introduction pour les fonctionnalités nouvelles, une étape à la fois.

Ce processus est illustré sur le diagramme ci-dessous.

https://blogsimages.adobe.com/creative/files/2016/06/Img-3-1.png

Adobe XD – Approche de la sortie des versions bêta et travail jusqu’à la version 1.0

Ce diagramme indique que dès la toute première version mise à la disposition du public nous avons cherché à fournir une expérience répondant, en termes de qualité et de performance, aux attentes qu’aurait un utilisateur vis-à-vis du produit fini. Pour revenir au « triangle de fer », nous fournissons dans les délais et avec une qualité digne d’un produit fini, en réduisant le périmètre selon les besoins. Avec une telle approche, chaque version Preview présente la performance et la qualité d’une version complète, mais avec moins de fonctionnalités. Nous pensons qu’ainsi, les utilisateurs peuvent aborder le produit de manière plus authentique, ce qui nous offre davantage d’occasions d’en tirer des enseignements.

Pour atteindre un tel degré de qualité, nous avons commencé par une base de code étroite mais robuste, et pour chaque fonctionnalité venant s’y ajouter, nous avons placé la barre très haut. Cette hauteur de barre prend la forme d’une définition du travail accompli (DoD, pour « definition of done ») très rigoureuse. Notre DoD comprend des éléments tels que l’examen du code, des tests unitaires ou une couverture du code afin que ces pratiques soient systématiquement mises en œuvre. Nous nous engageons à fournir à nos utilisateurs des mises à jour mensuelles (ce qui est élevé pour la plupart des logiciels d’ordinateurs de bureau). À moyen et long terme, nous pensons que ceci permet de fournir des fonctionnalités selon une vitesse, une cadence et une qualité plus élevées que si nous procédions à des sorties plus espacées. Et nous disposons d’une nouvelle occasion d’apprentissage à chacune des livraisons intermédiaires, comme illustré plus haut.

Ainsi, pour résumer, cette approche procure deux avantages majeurs :

• une validation rapide par les utilisateurs. Nous ne considérons pas la solution que nous sommes en train de construire comme parfaite. Mais en fournissant souvent de nouvelles versions, nous recevons un feedback constant qui nous permet de corriger le cap où et quand cela s’impose. Par exemple, nous avons modifié la pipette de couleur, l’outil plume et les fonctionnalités de partage en fonction des validations par les utilisateurs.
• l’implication des utilisateurs et l’itération. À la sortie d’une nouvelle version, les utilisateurs nous font part des éléments absents qui leur manquent le plus. Ceci nous permet d’ajuster nos priorités pour les sorties ultérieures afin de travailler en premier sur les points les plus importants. Il s’écoule parfois plusieurs versions avant que les commentaires des utilisateurs ne produisent des effets au sein du produit, tout simplement parce qu’au jour de la sortie d’une version, la suivante est déjà verrouillée. Cette approche en pipe-line nous permet d’offrir en permanence de la valeur aux utilisateurs tout en améliorant constamment le produit.

Conclusion

Jusqu’ici, les réactions de la communauté ont été excellentes. Nous avons pu sortir trois mises à jour mensuelles d’Adobe XD (Preview) et la quatrième respecte les prévisions. Les commentaires des utilisateurs se sont concentrés sur les fonctionnalités et non sur les aspects de qualité ou de performance, et je suis ravi de cette méthode de mise à disposition de versions Preview à nos utilisateurs.

J’ai hâte de découvrir ce que nous apprendrons de neuf en continuant à améliorer nos méthodes. Nous travaillons sur de nouvelles fonctionnalités passionnantes (voir « ce qui est encore à venir » dans cet article d’Andrew, directeur du management produit d’Adobe XD) et nous serions ravis de connaître votre avis. Essayez Adobe XD (Preview) pour Mac OS X (la version Win10 est dans les tuyaux !) et rejoignez les concepteurs sur UserVoice pour nous signaler des bogues, commenter les fonctionnalités ou en réclamer de nouvelles !