Introduction
Dans le framework SAFe les Features [1] sont conçues pour maximiser la valeur ajoutée. Lors de mes différentes interventions, j’ai observé certaines pratiques ou anti-patterns qui conduisent à des dérives, compromettant ainsi l’efficacité et la pertinence du développement produit.
Dans cet article j’aborde quelques-uns des anti-patterns rencontrés dans la gestion des Features et propose des solutions pour les aborder. Pour illustrer chaque point, j'utilise des exemples d’une application de téléconsultation médicale.
Anti-pattern 1 : La Feature Surchargée
Symptôme : La Feature est surchargée avec trop de sous-fonctionnalités et de détails. Elle devient alors difficile à réaliser dans un PI, ce qui peut mener à des retards et au non-respect des engagements.
Exemple : une Feature de “Gestion des dossiers médicaux” inclut plusieurs sous-fonctionnalités telles que l’ajout de prescriptions, la consultation des dossiers antérieurs, et l’intégration avec des systèmes externes. Ce niveau de détail rend la Feature trop complexe.
Solution : Scinder la Feature en plusieurs Features indépendantes, chacune orientée sur une sous-fonctionnalité distincte, avec une description claire de chaque objectif et hypothèse de bénéfice.
Anti-pattern 2 : La Feature basée sur des hypothèses non validées
Symptôme : Une Feature est créée et planifiée sans validation suffisante de l’hypothèse de bénéfice (voire sans hypothèses de bénéfice). Ce type d'anti-pattern mène souvent au développement de fonctionnalités inutiles ou mal alignées avec les besoins réels des utilisateurs.
Exemple : Une équipe décide de créer une Feature de “Rappel automatique des rendez-vous” dans l’application de téléconsultation, supposant que cela réduira les rendez-vous manqués. Cependant, aucune étude utilisateur n'a validé cette hypothèse, et le problème d’absentéisme persiste après le déploiement.
Solution : Valider chaque hypothèse de bénéfice par des données utilisateurs et des retours d’expérience avant d’investir dans le développement d’une Feature. (Etude de marché, sondage, etc.).
Anti-pattern 3 : La Feature à la Dérive
Symptôme : La dérive de la Feature se produit lorsque des fonctionnalités supplémentaires sont ajoutées sans réelle justification, souvent en réponse à des demandes spécifiques de certains stakeholders. Cela complexifie la réalisation de la Feature sans apporter de valeur mesurable.
Exemple : Une Feature de “Vidéo consultation” inclut initialement des options basiques pour une consultation. Progressivement, des demandes sont ajoutées pour des filtres vidéo, des fonds d’écran personnalisés et une messagerie instantanée, rendant la Feature trop large.
Solution : Définir des critères d’acceptation clairs et s’en tenir à la version initiale de la Feature. Impliquer les stakeholders dans des revues de validation pour éviter la dérive.
Anti-pattern 4 : La Feature orpheline
Symptôme : Une Feature est développée sans lien clair avec les objectifs métier ou sans vision de bout en bout, rendant difficile la démonstration de sa valeur ajoutée.
Exemple : Une Feature de “Chat instantané” est intégrée à l’application de téléconsultation sans que son alignement avec les priorités stratégiques ou les objectifs utilisateurs soit clarifié.
Solution : Assurer que chaque Feature soit justifiée par un objectif business précis et s’aligne avec la vision produit. Avant de commencer le développement, lier chaque Feature à un objectif stratégique.
Anti-pattern 5 : La Feature sans Test d'Acceptation
Description : Une Feature est créée et planifiée sans critères d'acceptation clairs, rendant difficile l’évaluation de sa complétion ou de sa valeur pour l’utilisateur final.
Exemple : une Feature “Envoyer un rappel de rendez-vous par SMS” est identifiée. Cependant, aucun critère d’acceptation n’a été défini pour vérifier la bonne exécution de cette fonctionnalité. Par exemple, on ne sait pas combien de temps avant le RDV il faut envoyer le sms et s’il faut l’envoyer uniquement aux personnes ayant confirmé leurs RDV?.
Solution : Intégrer les tests d’acceptation dès la phase de conception, en utilisant le format BDD [2] pour clarifier les attentes et valider le bon fonctionnement de la Feature.
Pour conclure
La gestion des Features dans SAFe doit être menée avec rigueur pour maximiser la valeur produite. Éviter les anti-patterns, comme la surcharge, les hypothèses non validées, la dérive, les Features orphelines et les features sans tests d'acceptation permet aux équipes d’optimiser le retour sur investissement pour chaque PI.
En savoir plus
[1] https://scaledagileframework.com/features-and-capabilities/
[2] "Specification by Example" de Gojko Adzic. Manning Publications, 2011.
Aucun commentaire:
Enregistrer un commentaire