Petit-déjeuner : Delivery agile, retrouvez le sommeil - mardi 30 mai
Retrouvez le sommeil
Compte-rendu réalisé par Priscille Faÿ.
Mardi 30 mai 2017. Après avoir passé une nuit difficile à ressasser les problèmes que vous rencontrez sur vos projets, vous vous rendez au petit-déjeuner d’OCTO Technology. Un café, un croissant et votre esprit s'éclaircit doucement. Ce matin, vous venez chercher des solutions pour retrouver le sommeil malgré la gestion de vos projets agiles.
Le speaker, Cyrille Deruel, Delivery Manager chez OCTO Technology, commence la présentation et donne le ton : “un projet delivery, ça doit rester fun. Ça ne doit pas être une souffrance”... Chiche ?
Cyrille Deruel est senior manager et responsable du Delivery Agile chez OCTO. Il n’est pas un super héros et ne détient pas la vérité sur tout, encore moins sur l’ensemble des projets agiles. Chaque projet est unique et demande une analyse et des solutions sur-mesure. Pour autant, depuis quelques années, il dort mieux. C’est grâce à son expérience et celle des membres de sa tribu “DLIVR” qu’il nous propose de partager l’expertise d’OCTO pour sécuriser le delivery agile.
QU’EST-CE-QUE LE DELIVERY AGILE?
Le delivery est un ensemble de pratiques qui permettent de mettre un produit en production. Les pratiques à l’intérieur de ce périmètre peuvent être très variées, du cycle en V ou “à La RACHE” (http://www.la-rache.com/). . Le delivery en agile est le fait d’aller chercher la mise en production d’un produit en utilisant les pratiques Agiles (Scrum par exemple). Après la mise en production, le projet s’arrête.
Le delivery agile est quant à lui “l’ensemble des pratiques pour mettre en production tout en gardant une capacité d’adaptation et une rapidité d’exécution au-delà de la mise en production.”
Avec le delivery agile, l’aventure commence vraiment après la mise en production.
Le modèle ACME met en exergue les 4 principales phases d’un delivery agile : aligner, construire, mettre en production, enrichir. Chacune de ces phases sera détaillée dans cet article.
UN CADRAGE POUR ALIGNER LES DIFFÉRENTS ACTEURS DU PRODUIT
La phase de cadrage est fondamentale pour lancer un projet correctement. En plus de clarifier le produit attendu et les méthodes à mettre en place pour le développer, cette phase va impacter l’efficacité de l’équipe sur l’ensemble du projet.
Pendant le cadrage, les personnes commencent à travailler ensemble et à se connaître. Cette étape est importante pour élaborer une vision commune sur laquelle tout le monde est aligné.
Chez OCTO, nous mettons en œuvre une série d’ateliers (le cadrage 360) pour arriver à un cadrage permettant de construire le produit avec l’ensemble des acteurs concernés. Ces ateliers permettent notamment d’identifier les utilisateurs et les différents interlocuteurs qui interviendront sur le projet. L’objectif avec ces rencontres est ensuite de s’aligner avec eux sur la vision du produit.
Liste et ordre des différents ateliers du cadrage 360 :
CONSTRUIRE LE PRODUIT
Un découpage du produit tourné vers la valeur pour l’utilisateur
Après le cadrage, nous avons une idée plus précise du produit que nous souhaitons obtenir. Mais si nous tentons de réaliser l’ensemble du produit dès le départ, le produit mettra du temps à sortir. Dans un premier temps, il est préférable de découper le produit pour identifier les fonctionnalités les plus importantes à développer. Nous ajouterons dans un second temps l’ensemble des fonctionnalités que nous souhaitons voir mais qui n’étaient pas prioritaires.
Avec l’exemple du découpage d’une page de détail d’un produit, nous voyons qu’en premier lieu on souhaite délivrer les fonctionnalités permettant de pouvoir acheter le produit. Les premières user story sont donc de voir le produit (via la photo), de connaître son nom, son prix et de pouvoir l’ajouter à notre panier. Une fois que le parcours de base est développé, nous pouvons rajouter à l’infini des éléments pour répondre aux attentes de l’utilisateur et valoriser le produit.
Afficher les écrans sur les murs pour avoir une vision globale du produit
Après avoir découpé les fonctionnalités, vous pouvez afficher les écrans et leur enchaînement sur les murs afin d’avoir une vision d’ensemble du produit et de s’assurer que vous n’oubliez rien lors du découpage (liaisons entre les pages, éléments manquants dans les user story existantes…). L’avantage de l’affichage mural est également de pouvoir apporter des modifications directement sur la feuille avec un simple feutre. Ces écrans sont aussi utiles pour l’équipe. Tout le monde peut savoir en un coup d’œil le produit attendu et le parcours pour l’utiliser.
Si vous ne possédez pas de storyboard, vous pouvez les réaliser avec des feuilles A4 et des feutres. Visualiser les grosses fonctionnalités avec des blocs permet a minima de vérifier les enchaînements des écrans, le type de fonctionnalités attendues et de partager concrètement le produit final.
Rédiger des user stories explicites à l’aide de check listes
L’un des principaux enjeux d’un projet est d’assurer la communication entre les personnes. Si le fonctionnel et la technique ne se comprennent pas, le projet peut partir dans le mur.
L'illustration suivante présente un exemple de “Definition Of Ready” où 3 aspects sont notamment utiles à préciser dans la story pour qu’elle soit complète : le design, les règles de gestion et les web services.
Construire une équipe pluridisciplinaire
De quelle équipe a-t-on besoin pour délivrer un projet agile? Bien évidemment, on ne peut pas démarrer un projet informatique qu’avec des développeurs. La connaissance fonctionnelle est apportée par le PO ou le responsable produit. Le delivery s’assure du pilotage global et le correspondant technique est l’interlocuteur pour tous les aspects techniques dans l’entreprise. Ces personnes constituent la base de l’équipe. A celles-là s’ajoutent les interlocuteurs extérieurs au projet mais qui interviennent ponctuellement sur le projet. C’est l’équipe minimaliste dont on peut avoir besoin sur un produit:
A cette équipe, d’autres profils peuvent être ajoutés pour apporter une plus-value importante au projet. Par exemple, avoir un OPS dans l’équipe constitue un atout considérable. Il est le garant du bon fonctionnement des environnements et s’assure qu’il n’y a pas de problème en production. Il crée également les pipelines pour pouvoir déployer les applications sur l’ensemble des environnements. L’UX permet d’apporter au projet une vraie orientation utilisateur. Sa présence est notamment très importante en début de projet pour définir une version 1.0 de l’outil. Attention cependant à ne pas trop changer l’ergonomie avant la première mise en production pour ne pas s’éparpiller et retarder la date de sortie du produit. Sur une grosse équipe, le PO devrait : parler à l’UX, aux développeurs, aux stakeholders, aux beta testeurs, aux experts... Son travail deviendrait vite considérable. Le co-PO (pour Co-Product-Owner) peut l’aider dans cette tâche, à l’image d’un co-pilote. Ce co-PO effectue le travail que n’a pas le temps de faire le PO. Il rédige les user story, recette, répond aux questions des développeurs… A partir de cette structure on peut plus facilement augmenter le projet et avoir de grosses équipes (experts, experts techniques, autre co-po, PMO, coach…).
Définir un process agile fluide et transparent
Comment définir son process sur un delivery agile?
Pour une première base, on peut suivre le modèle traditionnel de scrum et diviser le workflow en 3 colonnes : “à faire, en cours, fini”. Mais de même que “nous n’avons pas tous la même définition de ce qu’est une chambre rangée”, il est important de s’aligner sur ce que chacun considère comme “fait” pour passer dans la colonne suivante. Pour s’accorder sur ce qui permet de passer d’une colonne à l’autre, on élabore en équipe les “definition of done” (DOD). Ces DOD fixent les critères qu’il faut remplir pour que le travail apporté sur le ticket soit terminé dans une colonne et puisse passer dans la colonne suivante. Pour favoriser la visibilité de l’ensemble du process et insister sur la qualité du développement, on peut ajouter d’autres colonnes au tableau.
Par exemple, dans la mesure où le PO fait partie de l’équipe il est intéressant d’ajouter la partie “spécifications” des user story dans le board afin qu’elle soit visible par toute l’équipe. On peut également ajouter la colonne “recette” pour avoir un workflow favorisant la qualité du développement (pas de développements validés si le ticket n’a pas été recetté d’abord). Dans la partie développement, l’ajout d’une colonne “à revoir” permet à plusieurs développeurs de connaître le code d’une fonctionnalité et donc de partager la connaissance sur le sujet. Ce partage est utile pour ne pas être dépendant d’un développeur et pouvoir continuer à coder même si le développeur expert du domaine est absent. Ces tests effectués sur le code permettent également de réduire le nombre de bug et d’avoir un code cohérent entre tous les développeurs.
Travailler en flux tiré pour fluidifier le processus
Pour s’assurer que le processus soit fluide nous vous conseillons de travailler en flux tiré : “C’est l’heure d’arrivée qui tire l’heure de départ”. Tout ce qui est dans le flux correspond à ce qui doit être livré à l’arrivée. L’encours de chaque colonne doit être limité pour inciter à avoir le moins de tâches possibles démarrées et non terminées. Si une colonne est pleine le développeur ne peut pas passer un ticket dans cette colonne. Il doit d’abord vider la colonne pleine en travaillant sur un ticket compris dedans.
Prioriser le backlog à plusieurs
Le PO priorise le backlog. La partie haute correspond à la partie la plus prioritaire. Mais s’il priorise le backlog seul, le PO court le risque d’avoir des manques techniques qui risquent de bloquer les développeurs au moment de coder. A l’inverse, si les développeurs priorisent seuls, ils pourront développer un produit très beau d’un point de vue technique mais peu fonctionnel pour l’utilisateur. La priorisation la plus efficace est donc celle où les PO et les développeurs discutent pour trouver le meilleur compromis.
Favoriser la mise en place des rituels
La méthode Scrum préconise de tenir 5 rituels au cours des sprints : le sprint planning, le stand up, la démo, le bilan de fin d’itération et la rétro.
Sur le terrain, vous identifiez parfois des douleurs qui pourraient être atténuées par la mise en place de rituels additionnels. Voici une proposition de rituels très utiles pour améliorer le delivery :
- ajouter une réunion de présentation des user story auprès des développeurs (au moins une semaine avant le sprint planning). Si les user story ne sont pas totalement prêtes, les présenter une semaine avant le sprint planning permet aux développeurs de challenger le contenu et laisse le temps au PO/CoPO de les retravailler avant le démarrage du sprint. A l’ouverture du sprint les user story seront donc mieux cadrées et le risque de blocage pendant le développement sera réduit.
- un comité projet (COPROJ) les semaines paires pour s’assurer que le backlog est bien alimenté, les semaines impaires pour partager l’avancée du produit.
- le découpage des user story nécessite également d’organiser des points réguliers pour trouver le découpage adéquat.
L’amélioration continue : limites et perspectives de la rétro
Dans les delivery agile, on cherche l’amélioration continue à travers l’application notamment du rituel de la rétrospective. On surveillera que l’amélioration ne se limite pas à remettre les processus en question uniquement durant la rétrospective.
Par ailleurs, sur une grosse équipe quand la rétrospective est constituée par exemple de seulement 2 PO et 14 tech, le contenu des échanges peut être déséquilibré au profit d’un contenu très tech. Dans cette configuration un découpage en plusieurs rétro peut être approprié. On peut par exemple la séparer en 3 rétro : une rétro tech, une rétro fonctionnelle et une rétro globale pour échanger tous ensemble sur le système dans sa globalité.
5 indicateurs pour piloter
Voici les 5 indicateurs que nous utilisons pour partager concrètement la santé d’un projet de delivery :
- le volume de User stories prêtes
- l’avancement de l’itération
- le nombre d’anomalies en cours
- le nombre de bugs détectés après la validation par le PO/Co-PO
- l’avancement global du projet
Ces indicateurs sont directement extraits du board de l’équipe, comme ceci :
Organiser des comités réguliers
Quels comités tenir et à quelle fréquence?
Une bonne pratiques consiste à inviter les développeurs à tour de rôle aux différents comités.Cela permet de présenter un axe différent de lecture du projet, de se rendre compte des complexités non communiqués, de sentir l’état d’esprit du projet et de mieux partager les contraintes du projet.
MISE EN PRODUCTION
Avec les conseils présentés auparavant, la mise en production n’est plus un événement exceptionnel, car on se sera suffisamment entraîné depuis le début du projet.
ENRICHIR LE PRODUIT
Après la mise en production, vous allez découvrir des bugs en production que vous n’auriez pas nécessairement pu trouver avant. Ces bugs ne sont pas graves car tout au long de la phase de développement vous avez fabriqué votre propre usine pour construire le produit. Vous maîtrisez votre usine, vous avez la main sur l’ensemble de l’application,vous pouvez donc corriger ces bugs facilement. Suite à la mise en production, la qualité est la priorité car les bugs sont directement remontés par les utilisateurs.
Vous devez créer un rythme de déploiement (par exemple, toutes les 2 semaines). Ces livraisons régulières vous permettront d’aligner l’ensemble des acteurs du projets ; spécification, développement et recette.
Une fois en production, vous pourrez mesurer l’usage du projet et faire de l’A/B testing. Ces pratiques vous permettront de comprendre l’usage de votre produit.
CONCLUSION
Vous avez vu à travers le modèle ACME les différentes phases d’un projet.
Sur chacune des ses phases se posent des challenges différents.
Maintenant que vous avez conscience de ces challenges et que vous avez connaissance de nos conseils pour y faire face vous devriez être plus serein face à votre delivery et savoir comment trouver des axes d’amélioration pour maintenir le projet sur les rails et mieux dormir dès ce soir.
Si vous êtes sur un delivery agile, nous vous souhaitons donc bon courage, patience et surtout une bonne nuit !
Retrouvez le support complet : https://www.slideshare.net/OCTOTechnology/petitdjeuner-delivery-agile-retrouvez-le-sommeil