Vous avez certainement travaillé en mode cascade ou cycle en "V" durant votre parcours professionnel, vous avez comme Input un cahier de charge ou disant un CPS regroupant l'ensemble des fonctionnalités et demande à réaliser, le "Time To Market" est loin et trop long, on a qu'une seule livraison à faire en fin de projet.
Vous connaissez certainement ce cas, et cette situation de pression, stress, désordre, chaque équipe travaille seule (Développement, Test, Intégration, ...Etc.), toute l'équipe se bat et met les mains et les pieds pour livrer à temps et respecter le Deadline fixé au départ, sachant que dans la plupart des cas on dépasse cette date à causes d'un ou plusieurs problèmes et obstacles rencontrés ou c'est lié directement à la méthode de travail et la vision de départ d'un projet et pas produit.
Une fois le projet est mis en production, on va se rendre compte que la certaines ou la plupart des fonctionnalités ne répondent pas au besoin du client, certaines d'autre sont développées et réalisées, mais ne seront pas utilisées.
Bref, le logiciel ou l'application développé pendant une année ou plus ne répond pas vraiment en fin de compte aux besoins et attentes client et de ses utilisateurs finaux.
Dans l'agilité, c'est différent, il faut penser autrement, car il faut pas penser notion projet et date limite de livraison finale comme le cas en cascade, mais plutôt il faut avoir absolument la notion produit, et viser la valeur métier ajoutée à chaque livraison.
Parmi les questions qu'on doit se poser au départ c'est "Comment produire et réaliser un très bon produit ?", et l'enjeu et l'objectif des entreprises et prestataires doit s'orienter vers l'optimisation de la valeur métier à moyen et long terme, et pas tout simplement chercher à respecter les 3C du fameux triangle : Contexte (Scope), Coût (budget), et Calendrier (Délai).
Parmi les grands défis d'une transformation agile c'est de penser " Produit" et impact du business à moyen et long terme, et pas se limiter à surveiller le projet et le budget.
Même la notion de risque doit changer chez les gens, on se craint pas par rapport aux dates et Deadlines, mais plutôt est ce qu'est capable de produire un produit de qualité et comment le faire.....
On continu bien sur à piloter et gérer, mais quoi exactement, bien sur on doit piloter la valeur métier apportée et celle qui reste, et pas piloter le projet via une approche budgétaire.
Conclusion :
Visez plusieurs Feedbacks client et utilisateurs finaux anticipés et pas une seule fois à la fin du projet, prenez des décisions rapides et fréquentes vu que vous utilisez la notion itérative et vous livrez fréquemment des incréments produit.
Si vous arrivez à basculer du mode projet ordinaire vers mode produit piloté par la valeur métier alors vous avez gagné le premier défi de votre transformation agile.......
Certainement vous allez trouver beaucoup d'articles qui parlent des équipes produit au lieu équipe Scrum, sachant que c'est l'objectif principal de chaque Team, c'est comment produire un produit de qualité.
Opmerkingen