Scrum est la méthodologie de gestion de projet la plus populaire au monde avec plus de 72% des équipes utilisant Scrum ou un scrum-hybride . Les chances sont bonnes que si vous travaillez dans le développement Web, vous utilisez Scrum sous une forme ou une autre.
Une tendance actuelle dans Scrum est le "Sprint 0" ou son cousin plus artistique le "Design Sprint". Beaucoup a été écrit sur la question de savoir si ce sont de vrais sprints ( ils ne le sont pas ), mais moins a été dit sur la raison pour laquelle ils existent en premier lieu, pourquoi ils persistent obstinément et quelles alternatives existent.
Personnellement, j'aime Scrum et je suis toujours à la recherche de moyens d'améliorer progressivement ma mise en œuvre. Dans cet article, j'aimerais partager les méthodes que j'ai incorporées dans mon flux de travail et celles que je trouve utiles lors de la fusion UX / UI et du développement, ainsi que pour créer des visions de projet plus solides.
Quelques définitions rapides avant de commencer :
- Sprint 0
L'effort initial d'une équipe pour créer les documents d'orientation requis pour les projets Scrum: une vision, un backlog de produit et des estimations de version de produit. - Design Sprint
L'effort initial d'un
Pourquoi Sprint 0 et le design Sprint existent
C'est bien beau de dire: «Le Sprint 0 n'est pas un vrai sprint, ne le faites pas. «Mais ces adaptations sprint-ish existent pour une raison. De nombreuses équipes les adoptent car leur projet a un besoin non satisfait au-delà de la portée immédiate de Scrum. Mon observation est que le sprint 0 et les sprints de conception sont le plus souvent utilisés pour traiter les situations suivantes:
- Manque d'une vision directrice solide;
- Manque d'intégration de la conception dans le flux de travail de développement.
Le processus Scrum suppose une une vision claire a été développée et communiquée par le propriétaire du produit. Mais levez la main si vous avez travaillé sur des projets où la vision est faible, fausse ou invisible. Moi aussi! Le sprint 0 est une tentative de l'équipe de développement de combler le vide de vision. Ce n'est pas la pire idée, alors quel est le problème? D'un point de vue agile, Sprint 0 n'est pas itératif, n'utilise pas les talents de toute l'équipe et fournit des résultats nébuleux. Et avant de souligner: «Hé, le vrai problème ici est que les équipes de mêlée ne devraient pas avoir à faire le travail du propriétaire du produit», je crois en fait qu'une équipe agile interdisciplinaire est l'un des meilleurs environnements pour développer un environnement solide et réaliste vision and buts.
Je propose une méthode plus agile de construction de la vision que j'ai utilisée avec succès dans des projets sans transfert. Je vais explorer les deux situations où ces adaptations de type sprint sont utilisées et décrire comment ce premier sprint alternatif prend mieux en charge le flux de travail agile.
Vision And The Prototype Sprint
Dans la première situation, où il y a un manque de vision forte , la documentation ou les idées directrices sont trop faibles pour vraiment démarrer un projet Scrum. Pour tout processus (Scrum inclus), vous avez besoin de directives avant de commencer le voyage. Agile est idéal pour trouver le meilleur moyen d'atteindre un objectif, mais générer la vision initiale n'est pas dans son champ d'application. En fait, il manque complètement à Scrum une description de la vision requise pour que le processus de développement commence. Que ce soit vraiment Scrum ou non, Sprint 0 n'est qu'une équipe Web en première ligne, utilisant les outils dont ils disposent, essayant de comprendre ce qu'ils doivent faire avant de commencer.
Le véritable inconvénient de Sprint 0 est que la construction du document d'orientation pour le projet au moment où vous avez le moins d'informations apporte peu de valeur au processus de développement qui suit.
Guider les visions du projet qui ne correspondent pas à la réalité itérative émergente soit doivent passer par le processus coûteux d'un autre Sprint 0, ou plus souvent simplement ignoré.
Une meilleure alternative est le sprint prototype: un premier sprint qui engage toute l'équipe tout en
Le processus de vision de prototype de sprint
Les idées de remue-méninges sont traduites en une faible fidélité visuelle, prototype de travail le plus rapidement possible. Le prototype est écrit dans un framework HTML et CSS frontal fonctionnel, c'est-à-dire le langage partagé de l'équipe. Tout le monde ne peut pas comprendre une fiche technique ou un énoncé de vision. Tout le monde peut comprendre un site Web et la communication est plus facile et intègre un plus large éventail de disciplines.
À la fin du premier sprint, le prototype est prêt pour les tests initiaux sur plusieurs fronts, notamment l'utilisabilité générale, l'accessibilité et la réactivité mobile. Dans mes équipes, il s'agit d'un incrément effectué valide et important. Le sprint prototype produit également un backlog de produit initial. À mesure que les éléments du carnet de commandes seront complétés dans les prochains sprints, le prototype gagnera en fidélité. Le prototype n'est pas du code jetable – il est fondamental.
Dans certains projets, une vision écrite est générée lors de la production du prototype. Mais dans de nombreux projets, le prototype est la vision. Il parle dans le langage commun de l'équipe et n'est bien sûr jamais en décalage avec le produit.
Exemple
L'exemple ci-dessous est un prototype fonctionnel pour une application de commerce électronique, complété à partir de l'esquisse dans la DP initiale. Aussi grossier soit-il, il a contribué à concentrer les énergies de l'équipe dans une direction productive, dépassant de nombreuses distractions et pièges potentiels pour se concentrer sur des critères fonctionnels.
Un prototype initial entraînera souvent des modifications des exigences, qui sont tout simplement les meilleures suppositions jusqu'à ce qu'elles soient tenues à la lumière de l'expérience utilisateur. À titre d'exemple, l'une des informations que nous avons tirées du sprint prototype présenté ci-dessus est que le prix et le bouton "Acheter" étaient à l'origine beaucoup trop bas sur la page. La demande initiale était de les placer en dessous des informations sur le produit et au-dessus des recommandations, mais un prototype fonctionnel a rapidement montré que la hiérarchie n'était pas très fonctionnelle.
Une autre fonctionnalité qui est apparue est que les images de la galerie devaient à l'origine être grandes et étirer le pleine largeur de la page. Plutôt que d'exposer des raisons hypothétiques aux parties prenantes pour lesquelles cela ne fonctionnerait pas, le prototype a pu démontrer les problèmes dans un langage commun que toute l'équipe comprend. Lors d'une session de pouvoir avec les parties prenantes, nous avons rapidement réorganisé cette page en une hiérarchie universellement acceptée.
Parce que le prototype est né accessible et réactif, nous pouvons commencer à tester immédiatement sur plusieurs appareils et technologies. Bien que la conception (si on peut même l'appeler ainsi à ce stade précoce) soit intentionnellement maintenue à une faible fidélité, il était immédiatement évident que la messagerie du commutateur d'année sur le bureau était trop grande sur le mobile et interférait avec la convivialité (à gauche). Nous avons rapidement mis à jour le prototype pour utiliser un commutateur plus petit dans l'en-tête (à droite).
Quelques autres problèmes sont rapidement apparus lors de ce prototype de sprint:
- Le client, après avoir cliqué sur la navigation fonctionnelle, s'est immédiatement rendu compte qu'il avait manqué un composant fonctionnel majeur dans sa spécification: un blog. Cela a affecté l'estimation et le calendrier, mais nous avons pu nous ajuster rapidement.
- Il était évident pour l'équipe de l'interface utilisateur que l'affichage des prix était trop complexe et déroutant. Nous avons exploré d'autres possibilités avec le client et avons pu rapidement prototyper et tester plusieurs solutions pendant le prototype de sprint.
Au lieu que la vision soit potentiellement un obstacle ou devienne obsolète dès le début du développement, dans un prototype sprint la vision et les critères fonctionnels sont élaborés ensemble et se soutiennent mutuellement. Et parce que la vision est générée par l'équipe, il n'y a pas de transfert à l'équipe et évite facilement cette période risquée dans le processus de développement.
Design And The Prototype Sprint
Dans la deuxième situation – un manque d'intégration de la conception avec le développement – c'est souvent lorsque vous verrez un "sprint de conception" utilisé. Je trouve cette direction encore plus contre-productive qu'un Sprint 0. Les défis de l'intégration de la conception dans un processus de développement complexe sont réels, mais un sprint de conception est une approche qui échoue. Le sprint de conception est une bandaid pour le symptôme – le défi de créer des équipes intégrées – mais ne résout pas le problème sous-jacent – le défi de comprendre et de répondre aux besoins des utilisateurs. La conception à chargement frontal en un seul sprint évite le défi de l'intégration, mais les avantages d'un processus de conception intégré et incrémentiel et la fenêtre qu'il ouvre pour comprendre et atteindre les utilisateurs sont entièrement perdus.
Le sprint prototype que j'utilise dans les projets sans transfert est une alternative productive et totalement agile au sprint design. Il est collaboratif et fusionne à la fois l'interface utilisateur / UX et le développement dès les premières étapes du projet. Même l'équipe de conception la plus expérimentée peut bénéficier de l'implication d'autres disciplines et, ce qui est essentiel, elle garantit que les objectifs de code et de conception ne sont pas à contre-courant.
Souvent, le sprint de conception est également censé étoffer la vision. Il s'agit d'une décision désespérée basée sur une compréhension vague mais perspicace que le processus de conception est mieux équipé pour générer une vision que le développement. Cependant, une vision générée par la conception n'est pas un bon substitut à un véritable effort collaboratif à l'échelle de l'équipe.
Les pauvres concepteurs sont contraints de générer un produit final pour démarrer le développement sans les informations interdisciplinaires nécessaires pour que cet effort soit vraiment de valeur. Bien qu'un concepteur ayant des connaissances techniques et plus d'expérience ait de meilleures chances de réussir, c'est toujours très risqué. Sans produit potentiellement livrable à la fin de la phase de test contre les hypothèses, le développement se poursuit. Si la conception n'a pas atteint le niveau souhaité ou si les spécifications changent, cela peut entraîner de longs retards lors du retour à l'équipe de conception. Agile est à la base un processus de gestion des risques, et nous pouvons faire mieux que de commencer nos projets agiles avec un sprint de conception intrinsèquement risqué.
Le processus de conception de Sprint de prototype
Le changement le plus important par rapport à un sprint de conception plus traditionnel est que pendant le sprint du prototype, l'équipe passe directement du papier au prototype et ignore l'utilisation de Sketch, InVision, Photoshop ou d'autres programmes de mise en page numérique. Ils agissent comme une béquille visuelle à ce stade, semblant introduire de la valeur très rapidement (car les bons designers font de belles choses), mais la valeur réelle d'une maquette haute fidélité aussi tôt est très faible, tandis que le danger potentiel qu'elle introduit –
Ces outils sont meilleurs dans les maquettes plates haute fidélité mais le prototype initial n'est ni haute fidélité ni plat. Le tableau blanc, le crayon et le papier permettent à l'équipe de travailler rapidement sur les idées sans y être attachés. Ensuite, intégrez cette réflexion dans un prototype fonctionnel dès que possible.
Chaque membre de l'équipe, y compris les concepteurs, devrait se familiariser avec le prototype et être capable de travailler directement sur lui pendant les phases de lo-fi. Mais si ce n'est pas possible (ou si c'est un objectif à plus long terme et que vous devez avancer maintenant), alors une approche jumelée où un concepteur et un développeur travaillent côte à côte est bonne. Les croquis peuvent être décrits par le concepteur et interprétés ensemble par le développeur, élargissant ainsi leur compréhension commune de chaque point de vue.
Exemple
L'exemple ci-dessous montre notre processus distillant une analyse approfondie d'un site Web existant directement dans un prototype fonctionnel . Il a permis d'évaluer les résultats du rapport dans un environnement Web natif, une expérience très différente de l'analyse intellectuelle des recommandations dans un document imprimé:
De plus, contrairement au document d'analyse approfondie (aussi utile soit-il), le prototype fonctionnel est exempt de jargon et utilise un langage verbal et visuel partagé que tout le monde peut comprendre. Cela ouvre la conversation sur l'affichage visuel à tous les membres de l'équipe et à toutes les disciplines.
Notre principale question lors de la création de ce modèle était la quantité de détails de conception à inclure. Parce que nous avions un riche document plein d'analyses à tirer, nous aurions pu pousser le prototype plus loin. Mais, en gardant à l'esprit que les visuels peuvent rapidement (et involontairement) passer du domaine de l'idée au domaine des faits, nous avons gardé la mise en page sans engagement et distillé le document à ses éléments essentiels et à sa signification.
Les tests internes ont été nous dans le stade d'une solution plus axée sur l'utilisateur, dépassant de nombreux problèmes potentiels, mais nous avons consciemment évité de prendre des décisions de conception raffinées si tôt dans le processus. Il est important de peser continuellement toutes les idées et suggestions, y compris celles du client, par rapport aux données connues et de se rappeler que notre réservoir de connaissances est plus petit à ce stade qu'il ne le sera à n'importe quelle autre étape du projet.
Une autre raison pour laquelle il est essentiel de garder le prototype initial lo-fi et ne pas inclure d'éléments de «conception» est que l'adhésion de l'équipe peut être déraillée par des éléments visuels non pertinents qui provoquent des réactions viscérales involontaires. Nous évitons la couleur et n'incluons même pas le logo du client (utilisez plutôt un espace vide ou une boîte gris clair comme espace réservé). La conversation doit être constamment orientée vers des critères fonctionnels tels que la hiérarchie du contenu, l'accessibilité, la convivialité, la langue et le sens. Rassurez l'équipe que les "trucs amusants" viendront mais pas à ce stade précoce.
En fait, un objectif important d'un sprint prototype réussi est de prendre le moins de décisions de conception initiales possible. Une conception réussie est alimentée par l'expérience utilisateur, donc laissez le temps aux connaissances émergentes du projet d'informer l'interface utilisateur.
Quand le sprint du prototype est-il terminé
Le sprint est terminé lorsque le prototype et les artefacts qui l'accompagnent sont approuvés par toute l'équipe (y compris le
Un prototype fonctionnel précoce donne vie à la vision du projet à travers l'échelle (nombre de pages, portée de la navigation et autres principaux éléments de l'interface utilisateur), la complexité future (espace réservé) contenu avec des descripteurs utiles, éventuellement certaines fonctionnalités précoces codées), et identification des besoins (technologies spécifiques nécessaires, où ils seront déployés, dépendances éventuelles). Les décisions concernant les outils, l'environnement de travail et la pile de codes seront prises avec la contribution de toute l'équipe.
Atteindre cet incrément fait peut prendre aussi peu qu'une journée pour une équipe chevronnée avec un client réactif, mais dure généralement environ une semaine et pas plus de deux semaines. Les sprints prototypes devraient se déplacer à un rythme rapide et le dépassement du délai de deux semaines peut être un drapeau rouge. Cela peut signifier qu'il y a d'autres problèmes en jeu.
Quelques problèmes courants à rechercher lors d'un sprint de prototype
Voici quelques problèmes courants à rechercher lors de la mise en œuvre du sprint prototype:
- Adoptez la valeur de faible fidélité et éviter de mettre l'accent sur les visuels. Soyez vigilant sur ce point, car les équipes qui sont nouvelles dans cette approche pourraient avoir besoin d'aide et de réconfort pour aller au-delà de «où est le logo» et se concentrer sur des questions plus profondes de fonctionnalité et de hiérarchie.
- Une autre facette de ce qui précède, également veillez à ne pas vous attacher à vos propres idées de conception / mise en page. Il est utile de se rappeler pendant les sprints prototypes que rien de précieux n'est généré et de rester détaché des résultats finaux. De plus, c'est une autre raison de garder les prototypes minimaux et, franchement, plutôt laids. Il sert à maintenir les utilisateurs détachés.
- L'adhésion précoce du processus au leadership est critique . Parce que toute l'équipe est impliquée, votre client, votre patron et les développeurs doivent tous soutenir et entretenir le processus avec leur engagement, leur créativité et leur temps. Ne soyez pas une seule pom-pom girl, toute votre équipe doit agiter ses pompons!
- La mauvaise communication est le talon d'Achille de tout travail d'équipe . Le sprint prototype ne résoudra pas les problèmes de communication persistants, mais il les mettra en évidence plus tôt, car toute l'équipe plongera dans un flux de travail collaboratif presque immédiatement. Tous les problèmes de communication déjà existants se présenteront tôt et souvent dans un sprint prototype pendant que vous travaillez vers le consensus et votre premier incrément. Saisissez l'opportunité d'améliorer la communication et engagez toute l'équipe à trouver des solutions.
- Choisissez le bon cadre frontal . Si vous n'en avez pas déjà un, vous devrez peut-être essayer différents cadres frontaux avant d'en trouver un qui clique avec le flux de travail de votre équipe. Je recommande de regarder dans des cadres minimaux comme Fomantic ou Bulma et de ne pas s'enliser dans les cloches et les sifflets. Cependant, le bon cadre est toujours celui qui fonctionne pour votre équipe.
- L'équipe UI / UX doit développer un niveau de confort avec et accéder au cadre frontal. Idéalement, ils travailleront directement sur le prototype, en évitant les transferts inutiles et le besoin de traduction d'un support à un autre (c'est-à-dire de Sketch au prototype). Si votre équipe front-end ne connaît pas le CSS et le HTML, une approche par paires (avec un concepteur et un programmeur travaillant ensemble sur le framework) fonctionne également bien.
- Enfin et surtout, n'oubliez pas que vous s'améliore et devient plus rapide en équipe ! L'exécution d'un sprint prototype productif est une compétence qui évolue avec la pratique. Avec un prototype d'utilisateur fonctionnel, les tests de convivialité, d'accessibilité et de réactivité peuvent commencer immédiatement, garantissant que les sprints futurs seront informés par UX.
Le sprint prototype est un excellent début pour tout processus Scrum, mais dans mes projets, notre prochaine étape est pour passer à un flux de travail à double piste où UI / UX fonctionne un demi-sprint ou un avant le développement en faisant la découverte et en mettant visuellement à jour le prototype pour refléter de nouvelles informations.
( Large preview ) Le prototype se développe organiquement et devient de plus en plus raffiné, alimenté par la recherche UX et les besoins fonctionnels réalistes. Ces informations, non disponibles lors du sprint prototype, n'apparaissent que progressivement au fur et à mesure de l'avancement du projet. L'interface utilisateur / UX et le développement se nourrissent mutuellement par le biais du processus agile à deux voies.
Il n'y a pas de transfert de conception au développement à construire, ni d'application développée à concevoir en fonction de la peau. Au lieu de cela, le sprint prototype engage l'ensemble du groupe depuis le début et forme une base solide pour un flux de travail agile collaboratif tout au long du projet.
La vision directrice qui résulte d'un sprint prototype ne sera pas parfaite et changera probablement à mesure que appris, mais la reconnaissance que nous en savons moins au début qu'à toute autre phase d'un projet est au cœur du flux de travail agile. Lorsque nous appliquons cette même philosophie à l'émergence de la vision et de la conception du projet à travers un sprint prototype, ce qui en résulte est un incrément fait exécutable, des artefacts véritablement utiles, une adhésion partagée et un modèle de travail d'équipe et de collaboration qui peut être maintenu tout au long du projet. .
Remarque sur les paramètres d'agence
Si vous travaillez dans une agence, vous pensez peut-être que cette approche sera difficile à vendre. Malheureusement, vous avez probablement raison. De nombreuses agences sont intrinsèquement peu agiles et s'efforcent activement de transférer totalement le projet, souvent avec une approbation officielle et des répercussions soigneusement documentées sur les changements à venir. Plaidoyer pour un sprint prototype dans une organisation non agile est un non-starter: ce n'est tout simplement pas dans leur ADN. Une fois qu'une organisation adopte des équipes agiles et interdisciplinaires, elle peut facilement déterminer si le sprint prototype sans transfert améliorera son processus.
Conclusion
Le sprint 0 et les sprints de conception répondent à de vrais défis auxquels de nombreuses équipes Scrum sont confrontées: manque de vision , manque de conception intégrée, ou les deux. Ce sont des réponses compréhensibles et logiques, mais elles n'apportent pas de valeur élevée ni ne contribuent à de solides équipes agiles.
Les remplacer par un prototype de sprint est un moyen pratique de remédier aux inconvénients du Sprint 0 et de concevoir des sprints tout en jetant les bases
Un sprint prototype utilise les talents de toute l'équipe, génère la vision nécessaire, se traduit par le premier incrément effectué de l'équipe et évite le transfert de projet. Grâce à ce processus, les équipes développent une appropriation partagée de la vision du projet et une base plus solide pour la coopération interdisciplinaire dans l'esprit agile.
Lectures complémentaires on SmashingMag:
Source link
