Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

private joke

  • Private joke

    Aujourd'hui c'est vendredi et le vendredi c'est récréation. Cette semaine, je vous propose une private joke, car seul les initiés (responsables techniques de projets ou scrum master). Une fois encore je vais me moquer du chef de produit, il faut dire que c'est un bon client ! Vous le connaissez déjà, c'est celui qui tiens les cordons de la bourse et qui demandait d'aller plus vite en baissant la qualité interne (voir ici). Rappelez-vous, il avait fini par abdiquer sur la qualité interne.

    Quelques mois plus tard, nous montons un projet avec des méthodes agile (scrum). A la fin de notre réunion de backlog produit, tout le monde était fier des fonctionnalités à développer, les priorités étaient fonctions du besoin utilisateurs. On a même fait les découpes en sprints. Il y en avait 6. Connaissant le chef de produit, qui ne nous avait pas encore donner les délais, je lance :

    - 6 sprints, donc grosso modo 6 mois de travail !

    Je vois alors les sourcils se froncer, l'air dubitatif, il me répond :

    - Mais c'est pas possible ! Attendez, mais il y a vraiment pas moyen de lancer deux sprints en même temps (rire de l'assistance), comme cela dans trois mois c'est fini !

    - Non, on ne peut pas coudre la braguette d'un pantalon avant d'avoir cousu les jambes. Les prirorités jusqu'au sprint 3 ont une logique technique !

    - Ah, mais c'est dimentionné pour une équipe de combien ? parce qu'on peut embaucher pour doubler l'équipe et diviser par deux le temps d'un sprint.

    - Eventuellement, mais à partir d'un moment, le travail en binôme sera le seul moyen d'être éfficace pour ne pas se marcher sur les pieds.

    Cette petite expérience montre que la logique de délais technique n'est pas perçu de manière par tout le monde. Pour un chef de produit avec un background commercial ou financier (donc sans bagage technique), il est difficile de comprendre les dépenses sur des dév. techniques : ce n'est pas aussi "proportionnel" que déposer des fonds sur un cours en bourse !

    L'avantage d'aborder un nouveau projet avec une méthode de programmation continue, est que l'équipe technique peut livrer tous les mois une version fonctionnelle sur laquelle l'équipe produit fait ses retours. De plus, au vu des délais, j'ai fait comprendre que le seul moyen de réduire les délais, sans mettre en cause le succès du projet et sa qualité interne, était de diminuer le nombre de fonctionnalités. En revenant sur notre backlog produits, nous nous sommes apreçus qu'une version avec les fonctionnalités repondant aux besoins essenciels des utilisateurs était possible dès la fin du sprint 3 ! Donc d'un point de vue utilisateur, 3 mois ont suffit pour livrer l'essentielle des attentes. Les fonctionnalités secondaires, ont pu être revue et repriorisée en fonction du retour des premiers visiteurs. Certains usage du site qu'on avait imaginé au départ ont été supprimé.