logo
Populate the side area with widgets, images, navigation links and whatever else comes to your mind.
18 Northumberland Avenue, London, UK
(+44) 871.075.0336
ouroffice@vangard.com
Follow us
 

Click and learn

On ne va pas tourner autour du pot !

All | # A B C D E F G H I J K L M N O P Q R S T U V W X Y Z | Submit a name
There are 7 names in this directory beginning with the letter D.
DEEP LINK
les "liens profonds" vous permettent de diriger vos mobinautes "cible" directement à un contenu spécifique au sein d'une application mobile ou d'une page web. Si l'utilisateur touché ne détient pas votre application mobile, il atterit sur le store pour la télécharger. Le deep link est donc un moyen efficace pour renforcer l'acquisition et l'engagement sur vos produits numériques

DÉFINITION DU DONE (DOD)
la DOD résulte d’un accord commun au sein de l’équipe sur les conditions requises pour statuer qu’une user story est prête pour une livraison. La DOD peut être réalisée à différents niveaux : au niveau d’une user story, d’un sprint ou d’une livraison

DÉFINITION DU READY (DOR)
la DOR résulte d’un accord commun au sein de l’équipe sur les conditions requises pour statuer qu’une user story est prête à être intégrée dans un sprint. La DOR est définie habituellement en Grooming Session

DESIGN SPRINT
le design sprint condense sur une durée très courte (5 jours) un process généralement long qui consiste à définir une solution pour une problématique identifiée au démarrage, la prototyper et la tester

DESIGN SYSTEM
en traitant les 3 grandes composantes du design, à savoir, le visuel, les usages et le langage, ce référentiel UX et UI permet de designer et développer un produit numérique qui évolue dans le temps et de réduire la dette design

DETTE EMOTIONNELLE
elle apparait notamment lors de conflits d'idées et s’accumule dans le temps au sein d'une équipe. Elle est à privilégier tout autant que la dette technique puisqu'elle peut gravement impacter la motivation et l'efficacité des équipes

DETTE TECHNIQUE
développer consiste à produire de la dette. L'important est d'en prendre conscience et de la maîtriser afin d'avoir toujours un code évolutif et non bloquant pour de prochaines évolutions. La dette technique peut prendre la forme de versions non mises à jour, un mauvais refactoring, des patterns non renouvelés ... La liste peut être longue ! Allez mettez en place régulièrement des états de lieux


Submit a name