Idée fausse n°3 sur le développement logiciel dans une grande organisation : notre équipe doit-elle avoir une vision limitée ou une vision globale du produit ? : Différence entre versions

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
Ligne 8 : Ligne 8 :
 
----
 
----
 
Traducteur : Fabrice Aimetti<br />
 
Traducteur : Fabrice Aimetti<br />
Date : 09/08/2019<br />
+
Date : 25/08/2019<br />
 
----
 
----
 
Traduction :<br />
 
Traduction :<br />

Version du 25 août 2019 à 10:54

Auteur : Michael James (MJ)
Source : Large Organization Software Development Misconception #3: Should Our Team See A Narrow View Or A Whole Product View?
Date : 03/08/2019


Traducteur : Fabrice Aimetti
Date : 25/08/2019


Traduction :

Seattle-Scrum-Company-logo.png
Les équipes de petite taille sont formidables et sont prescrites par la définition de Scrum. Scrum prescrit également un Backlog Produit et un Product Owner.


La plupart des entreprises ont plus de 11 personnes qui travaillent sur un produit donné. Juste pour faire en sorte que Scrum soit adapté (une optimisation locale), ils vont redéfinir le mot "Produit" pour signifier quelque chose de plus étroit/limité que l'ensemble du produit. C'est le premier pas dans un "jeu aux miroirs" où les mots signifient le contraire de leur intention originelle.

L'erreur suivante est de donner à chaque équipe un "Backlog Produit" pour lequel des observateurs avertis remarqueront qu'il n'est en fait qu'un Backlog d'Équipe.

Product-backlog-minus-whole-product-authority-equals-team-backlog fr.png

Ensuite, donnez à chaque équipe un "Product Owner" distinct qui n'est en fait qu'un Team Output Owner.

Product-owner-minus-whole-product-authority-equals-team-output-owner fr.png

Cela nous laisse avec peut-être une douzaine d'"Equipes Scrum" séparées dont les managers s'inquiètent en courant autour comme des poulets avec la tête coupée, à moins que nous ne les rassemblions d'une manière ou d'une autre. La manière traditionnelle de le faire, qui remonte au moins à l'armée de Jules César, est d'ajouter des couches hiérarchiques. Les humains ont du mal à penser à des alternatives aux couches hiérarchiques ; c'est malheureusement ce qui est recommandé à la fin de la vidéo extrêmement populaire de Henrik Kniberg sur le Product Owner (une vidéo géniale jusqu'aux dernières minutes avant la fin). Nous avons donc maintenant un "Chief Product Owner" ou "Business Owner" ou un autre moyen de combler le vide.

Un décendant de l'approche ratée RUP (Rational Unified Process) appelée Scaled Agile Framework (SAFe) ajoute tout une pile de couches de management traditionnel en plus de nos "Equipes Scrum". Il se vend très bien parce qu'il s'agit simplement de renommer tous les rôles traditionnels en rôles à consonance Agile (fr).

Ces approches hybrides traditionnelles/Agile laissent les plus gros problèmes dans l'espace traditionnel plutôt que dans l'espace Scrum de priorisation d'une liste unique et d'auto-organisation des équipes. Avec une vue limitée du produit, seuls nos orteils finissent par être Agile.

Les Scrum Masters (et la le management, si vous l'avez avec vous) devrait vous aider à éradiquer les mesures incitatives actuelles et à encourager plutôt une approche globale du produit (fr).