{"id":10219,"date":"2022-01-26T01:46:08","date_gmt":"2022-01-26T01:46:08","guid":{"rendered":"https:\/\/www.cybermedian.com\/fr\/?p=10219"},"modified":"2026-04-20T09:13:14","modified_gmt":"2026-04-20T09:13:14","slug":"equipes-interfonctionnelles-vs-auto-organisees-vs-fonctionnalite-vs-composants-en-agile","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/fr\/cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile\/","title":{"rendered":"\u00c9quipes interfonctionnelles vs auto-organis\u00e9es vs fonctionnalit\u00e9 vs composants en Agile"},"content":{"rendered":"
\n
\n
\n

Traditionnellement, un projet est organis\u00e9 autour d’\u00a0\u00a0\u00e9quipes de composants<\/strong>\u00a0\u00a0(c’est-\u00e0-dire UX, Dev, Business, Tester, et \u2026), toute version qui n\u00e9cessite une gamme d’expertise de composants devra impliquer plusieurs \u00e9quipes de composants.\u00a0En r\u00e8gle g\u00e9n\u00e9rale, diff\u00e9rentes \u00e9quipes auront des ensembles de priorit\u00e9s diff\u00e9rents, ce qui entra\u00eene in\u00e9vitablement des goulots d’\u00e9tranglement dans le cycle de lancement du produit.<\/p>\n

Selon Wikipedia, une \u00e9quipe interfonctionnelle est un groupe de personnes ayant une expertise fonctionnelle diff\u00e9rente travaillant vers un objectif commun.\u00a0L’un des meilleurs moyens d’am\u00e9liorer la qualit\u00e9 de votre \u00e9quipe est de la rendre interfonctionnelle.\u00a0Une \u00e9quipe interfonctionnelle poss\u00e8de toutes les comp\u00e9tences n\u00e9cessaires pour transformer une id\u00e9e en un produit fonctionnel.<\/p>\n

\u201c\u00a0Une\u00a0\u00a0<\/em>\u00e9quipe interfonctionnelle<\/em><\/strong>\u00a0\u00a0poss\u00e8de toutes les comp\u00e9tences n\u00e9cessaires pour accomplir le travail sans d\u00e9pendre d’autres personnes ne faisant pas partie de l’\u00e9quipe<\/em>\u00a0\u201d \u2014 Scrum Guide<\/p>\n

Contrairement \u00e0 l’approche par \u00e9quipe de composants,\u00a0\u00a0les \u00e9quipes interfonctionnelles<\/strong>\u00a0\u00a0sont des groupes compos\u00e9s de personnes issues de diff\u00e9rents domaines fonctionnels de l’entreprise.\u00a0– il doit \u00eatre form\u00e9 non seulement avec des sp\u00e9cialistes techniques (d\u00e9veloppeurs Back-end, Front-end, ing\u00e9nieurs QA, etc.) mais \u00e9galement compos\u00e9 de membres tels que des analystes commerciaux, des sp\u00e9cialistes du marketing et de l’UX ou toute autre personne prenant une part active au projet.<\/p>\n

<\/figure>\n

Une\u00a0\u00a0\u00e9quipe auto-organis\u00e9e<\/strong>\u00a0\u00a0est une \u00e9quipe qui a l’autonomie de choisir la meilleure fa\u00e7on d’accomplir son travail, plut\u00f4t que d’\u00eatre dirig\u00e9e par d’autres en dehors de l’\u00e9quipe.\u00a0Contrairement aux principes de gestion traditionnels, les \u00e9quipes auto-organis\u00e9es ne sont pas dirig\u00e9es et contr\u00f4l\u00e9es d’en haut ;\u00a0ils \u00e9voluent plut\u00f4t \u00e0 partir des membres de l’\u00e9quipe participant activement et collectivement \u00e0 toutes les pratiques et \u00e9v\u00e9nements Scrum.<\/p>\n

<\/figure>\n

Equipe traditionnelle vs \u00e9quipe Agile<\/p>\n

\u00ab Une\u00a0 \u00e9quipe d’\u00a0<\/em>auto-organisation<\/em><\/strong>\u00a0\u00a0se compose d’un groupe de travailleurs du savoir qui doivent se g\u00e9rer eux-m\u00eames.\u00a0Ils doivent avoir de l’autonomie \u00bb \u2014\u200a<\/em>\u00a0Peter Drucker.<\/p>\n

Le Scrum Guide indique \u00ab L’\u00e9quipe Scrum se compose d’un Product Owner, de l’\u00e9quipe de d\u00e9veloppement et d’un Scrum Master.\u00a0Elles sont:<\/p>\n

\u00ab\u00a0Les \u00e9quipes Scrum<\/strong>\u00a0\u00a0sont\u00a0\u00a0auto-organis\u00e9es<\/strong>\u00a0\u00a0et\u00a0\u00a0interfonctionnelles<\/strong>\u00a0\u00bb \u2014\u200a<\/em>\u00a0Guide Scrum\u00a0:<\/p>\n

\u00c9quipe de composants vs \u00e9quipe de fonctionnalit\u00e9s<\/span><\/h3>\n

L’approche traditionnelle consiste \u00e0 d\u00e9composer le produit de mani\u00e8re plus ou moins logique et significative en composants et \u00e0 leur affecter des \u00e9quipes de composants.\u00a0Cependant, ces composants sont totalement sans rapport avec le point de vue du client.<\/p>\n

Une approche d’\u00e9quipe de fonctionnalit\u00e9s est maintenant presque universellement accept\u00e9e pour organiser leurs \u00e9quipes, par opposition \u00e0 l’\u00e9quipe de pile technologique, en particulier, dans l’approche de livraison continue, elle met l’accent sur les fonctionnalit\u00e9s (c’est-\u00e0-dire une tranche verticale du syst\u00e8me) qui r\u00e9solvent les besoins des utilisateurs qui peuvent g\u00e9n\u00e9ralement acc\u00e9l\u00e9rer valoriser la livraison de toutes les fonctionnalit\u00e9s ou logiciels fonctionnels et raccourcir la boucle de r\u00e9troaction des utilisateurs r\u00e9els.\u00a0Une \u00e9quipe technique aurait toutes les comp\u00e9tences n\u00e9cessaires pour effectuer le travail n\u00e9cessaire au niveau des t\u00e2ches pour faire le travail.\u00a0En particulier, en supposant une architecture \u00e0 trois niveaux, les membres de l’\u00e9quipe travailleraient sur des t\u00e2ches li\u00e9es aux parties de l’interface graphique, du niveau interm\u00e9diaire et de la base de donn\u00e9es de cette histoire.<\/p>\n

<\/figure>\n

Le gros inconv\u00e9nient de l’organisation des composants est \u00e9vident : elle ralentit le flux de valeur.\u00a0La majorit\u00e9 des fonctionnalit\u00e9s du syst\u00e8me cr\u00e9ent des d\u00e9pendances qui n\u00e9cessitent une coop\u00e9ration entre les \u00e9quipes de composants pour cr\u00e9er, d\u00e9ployer et finalement publier.\u00a0Les \u00e9quipes passent une grande partie de leur temps \u00e0 discuter des d\u00e9pendances entre les \u00e9quipes et \u00e0 tester le comportement des composants plut\u00f4t que d’\u00eatre en mesure de fournir de la valeur \u00e0 l’utilisateur final.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n