Fabrice Aimetti le 17 juillet 2018 à 21:35

2018-07-17T21:35:41Z

← Version précédente		Version du 17 juillet 2018 à 21:35
Ligne 5 :		Ligne 5 :
	----		----
	''<span style="background-color: #ffffff">Traduction :</span>''<br /> <br />		''<span style="background-color: #ffffff">Traduction :</span>''<br /> <br />
	[[LeSS - Portail Structure]]<br /> <br /> '''<span style="font-size: 110%">Qu'est-ce qu'une équipe ?</span>'''<br /> <br /> Les équipes sont la brique de construction essentielle pour le développement d'un gros produit, et la structure de l'équipe a un énorme impact sur la productivité et le temps de cycle.<br /> �<br /> L'équipe a :<br />		[[LeSS - Portail Structure]]<br /> <br /> '''<span style="font-size: 110%">Qu'est-ce qu'une équipe ?</span>'''<br /> <br /> Les équipes sont la brique de construction essentielle pour le développement d'un gros produit, et la structure de l'équipe a un énorme impact sur la productivité et le temps de cycle.<br /><br /> L'équipe a :<br />

	* un travail partagé sur le produit		* un travail partagé sur le produit

Fabrice Aimetti : Page créée avec « Category: Portail LeSS
Auteur : The LeSS Company B.V.
<... »

2018-07-17T21:35:29Z

Page créée avec « Category: Portail LeSS <div id="content_view" class="wiki" style="display: block">Auteur : The LeSS Company B.V. <... »

Nouvelle page

[[Category: Portail LeSS]]
<div id="content_view" class="wiki" style="display: block">Auteur : The LeSS Company B.V. Source : [http://less.works/less/structure/teams.html Teams - Large Scale Scrum (LeSS)] 
----
Traducteur : Fabrice Aimetti Date : 02/01/2017 
----
''Traduction :'' 
[[LeSS - Portail Structure]] '''Qu'est-ce qu'une équipe ?''' Les équipes sont la brique de construction essentielle pour le développement d'un gros produit, et la structure de l'équipe a un énorme impact sur la productivité et le temps de cycle. � L'équipe a : 

* un travail partagé sur le produit
* un travail interdépendant
* une responsabilité partagée
* un ensemble d'accords de travail
* la responsabilité pour gérer les relations en dehors de l'équipe [[https://www.amazon.com/The-Team-Handbook-Third-Edition/dp/1884731260 SJS03]]
* un leadership distribué [[https://www.amazon.com/Teams-At-Top-Jon-Katzenbach/dp/0875847897 Katzenbach98]].
 '''Équipes auto-gérées''' Les équipes auto-gérées sont la base de Scrum et c'est une pratique aujourd'hui en extension dans le domaine du management moderne. L'équipe a l'autorité pour concevoir, préparer et exécuter ses tâches et pour suivre et gérer son processus de travail et son état d'avancement [[https://www.amazon.com/Leading-Teams-Setting-Stage-Performances/dp/1578513332 Hackman02]]. L'équipe, et non le chef de projet, a la responsabilité de décider comment travailler. Les équipes auto-gérées n'apparaissent pas d'un coup, elles ont besoin du bon environnement. L'organisation a la responsabilité de soutenir le développement de l'équipe en créant les conditions nécessaires au succès de l'équipe. Evoluer avec des équipes auto-gérées signifie que le travail du manager traditionnel passe de la direction d'équipe à la création de ces conditions. '''Équipes pluridisciplinaires''' Les équipes auto-gérées sont pluridisciplinaires. Une équipe pluridisciplinaire est un ''"groupe de personnes avec un objectif clair représentant la diversité des silos ou disciplines de l'organisation, et dont les efforts combinés sont nécessaires pour atteindre l'objectif de l'équipe"'' [[https://www.amazon.com/Cross--Functional-Teams-Working-Strangers/dp/0787960853 Parker02]]. Par définition, une équipe Scrum est pluridisciplinaire. Ses membres intègrent au minimum le marketing produit (Product Owner), le développement logiciel et le test. Une équipe pluridisciplinaire implique de casser les silos de l'organisation entre le développement et le test en les mettant dans la même équipe. Pluridisciplinaire signifie qu'être membre de l'équipe met en jeu toutes les fonctions essentielles nécessaires à un projet, généralement l'ingénierie, le marketing et la fabrication, et c'est un minimum [[https://www.amazon.com/Flexible-Product-Development-Building-Changing/dp/0787995843 Smith07]]. '''Organisation basée sur les équipes''' L'organisation LeSS basée sur les équipes a la structure suivante : 

* '''Équipes dédiées''' : chaque membre de l'équipe est dédié à plein temps dans une et une seule équipe. Cela peut sembler rigide, mais les membres de l'équipe doivent être à plein remps si vous voulez qu'ils (1) partagent la responsabilité de l'objectif de l'équipe, et (2) s'approprient la façon dont travaille l'équipe et leur processus.
* '''Équipes pluridisciplinaires''' : chaque équipe contient toutes les compétences nécessaires pour fabriquer un produit déployable. La spécialisation traditionnelle peut sembler la plus "efficace" d'un point de vue fonctionnel, mais la plupart des efforts et des problèmes dans le développement produit sont "entre les fonctions", c'est ce qui explique que les équipes doivent être pluridisciplinaires si vous souhaitez qu'elles se concentrent sur la globalité du produit opérationnel.
* '''Équipes co-localisées''' : chaque équipe est co-localisée dans la même pièce. Cela peut sembler déraisonnable. Ne voudriez-vous pas utiliser, dans la société mondialisée d'aujourd'hui, les personnes disposant des meilleures compétences là où elles se trouvent ? Non. Nous souhaitons les meilleures équipes qui puissent partager la responsabilité des résultats de l'équipe, et apprendre les uns des autres. Une responsabilité partagée nécessite de la confiance. Les personnes bâtissent la confiance plus rapidement avec une coopération étroite et une communication en face à face. La co-localisation encourage aussi l'apprentissage de l'équipe, qui est l'essence de l'amélioration continue.
* '''Équipes pérennes''' : une équipe reste ensemble "pour toujours". Cela peut sembler idéaliste, mais les équipes ont besoin de stabilité si vous voulez qu'une équipe se préoccupent de la façon dont elle travaille en tant qu'équipe. Toute personne qui a déjà réellement été membre d'une équipe pendant très longtemps sait que les équipes deviennent meilleures lorsque ses membres apprennent à se connaître les uns les autres et apprennent à savoir comment travailler et s'améliorer ensemble.
 '''L'équipe gère les dépendances externes''' Quelles sont les implications sur le développement d'un gros produit ? Elles sont profondes ! Premièrement, chaque équipe doit avoir un objectif clair pour connaître les limites. Etablir des équipes feature qui soient centrées sur le client aide dans ce sens. Cela génère une communication inter-équipes et orientée sur le code. Deuxièmement, l'organisation doit clarifier au maximum que les équipes sont elles-mêmes responsables de coordonner leur travail avec les autres équipes. Le succès d'une équipe peut être mesurée par le succès du produit global, ceci afin de prévenir toute optimisation locale. Si vous supprimez les rôles officiels de coordination tels que les chefs de projet, il devient très clair pour l'équipe que la coordination est de leur responsabilité. Troisièmement, mettez en place un système d'intégration continue à l'échelle du produit global. Cela offre la visibilité dont les équipes ont besoin pour coordonner leur travail. La santé du produit doit toujours être visible par tous. '''Des employés multi-compétents''' Apprendre est l'activité principale dans le développement de produit. Sur le long terme, réduire l'apprentissage réduit l'efficacité, cela ne l'augmente pas. Sherman dit dans Fortune Magazine : ''"Les employés seront récompensés en fonction de leur connaissance et adaptabilité. Le spécialiste n'est plus de mode, c'est le généraliste qui l'est maintenant. Les personnes les plus employables seront des gens flexibles qui pourront facilement passer d'un poste à l'autre, en intégrant diverses disciplines et perspectives... ces personnes devront être capables non seulement d'acquérir de nouvelles compétences mais aussi de désapprendre les anciennes manières de travailler."'' '''L'équipe prend des décisions''' Les équipes auto-gérées prennent elles-mêmes leurs décisions. Pourtant, beaucoup de personnes ont grandi dans des environnements contrôle-commande où le management prend les décisions pour elles. Un ScrumMaster peut aider les équipes à apprendre comment prendre des décisions. Un accord entre les membres de l'équipe sur la façon de prendre des décisions est plus important qu'une méthode particulière de prise de décision. Le protocole Decider [[https://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566 MM02]] est un moyen facile et rapide de prendre des décisions par consensus (NfT : voir les [http://www.mccarthyshow.com/download-the-core/ Core Protocols]). '''Le conflit dans une équipe''' Le fait de travailler ensemble génère des conflits. Ce n'est pas une mauvaise chose. Mais le conflit doit être résolu. Un conflit non résolu a un impact négatif sur la performance de l'équipe et crée un dysfonctionnement dans l'ambiance de l'équipe [Lencioni02]. Un conflit résolu, par contre, crée de l'apprentissage et de la confiance, les deux ont un impact sur la performance. Le conflit est une opportunité pour l'équipe d'améliorer sa performance, c'est donc une bonne chose. '''Ne passez pas par une phase d'allocation de ressources''' Scrum, ce n'est pas du Cycle en V. Il n'y a pas de phase. Avec l'auto-gestion, la pluridisciplinarité et les équipes feature pérennes, il équilibre le "besoin en ressources" sur la version. Ce sont les mêmes personnes qui restent sur la version du début à la fin. '''Conclusion''' Ces concepts d'équipe, différents mais éprouvés, causent des changements majeurs dans les organisations : 

* Des équipes auto-gérées ont besoin de passer d'un management contrôle-commande à un management-enseignant. Au lieu de se concentrer sur ce que les gens font, le management devrait vraiment réfléchir à la manière de créer un environnement pour que les équipes réussissent.
* Des équipes pluridisciplinaires ont besoin de casser les silos de l'organisation globale et de travailler ensemble pour optimiser la valeur livrée au client. Au lieu de parquer les gens dans des silos, le management devrait se concentrer sur l'apprentissage pluridisciplinaire.
* Des équipes dédiées pérennes ont besoin de laisser les équipes existantes décider de leur façon de travailler. Au lieu de considérer chaque individu comme une unité de performance, concentrez-vous sur les équipes.
 '''Lectures conseillées''' Lorsque vous passez sur des équipes pluridisciplinaires, il est difficile de changer le style de management. Heureusement, beaucoup de choses excellentes ont été écrites sur le sujet : 

* [https://www.amazon.com/Leading-Teams-Setting-Stage-Performances/dp/1578513332 Leading Teams de Richard Hackman] Richard Hackman, professeur à Harvard, fait des recherches sur les équipes depuis longtemps. Son livre et notre préféré sur les équipes. Il est très axé sur la façon de changer le management en faveur du travail en équipe.
* [https://www.amazon.com/Leading-Self-Directed-Teams-Kimball-Fisher/dp/0071349243 Leading Self-Directed Work Teams de Kimball Fisher] Ce livre est très axé sur le changement de rôle qui s'opère lorsqu'on devient le team leader d'une équipe auto-dirigée.
* [https://www.amazon.com/Wisdom-Teams-High-Performance-Organization-Essentials/dp/0060522003 The Wisdom of Teams de Jon Katzenbach et Douglas Smith] C'est probablement la référence la plus populaire sur les équipes et ça vaut le coup de le lire.
* [https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756 The Five Dysfunctions of a Team de Patrick Lencioni] Ecrit comme un roman, il couvre bien le sujet des conflits dans les équipes.
 Les équipes pluridisciplinaires sont principalement décrites dans la littérature sur le développement produit. Voilà quelques bons ouvrages : 

* [https://www.amazon.com/Fast-Cycle-Time-Strategy-Structure/dp/141657624X Fast Cycle Time de Chris Meyer] C'est un classique sur le développement produit et il aborde en détail les équipes pluridisciplinaires.
* [https://www.amazon.com/Revolutionizing-Product-Development-Quantum-Efficiency/dp/0029055156 Revolutionizing Product development de Steven Wheelwright et Kim Clark] Un autre classique dans la littérature sur le développement produit. Un chapitre porte sur l'intégration des équipes pluridisciplinaires.
 D'autres textes sur les équipes de développement logiciel : 

* [https://www.amazon.com/Software-Your-Head-Protocols-Maintaining/dp/0201604566 Software for Your Head de Jim et Michele McCarthy] Jim et Michele ont passé des années dans des "boot camps" pour découvrir les meilleures manières de travailler pour les équipes. Ils l'ont documenté sous la forme d'un ensemble de protocoles dans ce livre.
* [https://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113 Peopleware de Tom DeMarco et Tim Lister] Ce classique sur l'importance des personnes dans le développement logiciel comporte aussi quelques chapitres axés sur les équipes.
</div>

LeSS - Equipes - Historique des versions

Fabrice Aimetti le 17 juillet 2018 à 21:35

Fabrice Aimetti : Page créée avec « Category: Portail LeSS Auteur : The LeSS Company B.V. <... »

Fabrice Aimetti : Page créée avec « Category: Portail LeSS
Auteur : The LeSS Company B.V.
<... »