{"id":8875,"date":"2022-02-23T07:19:32","date_gmt":"2022-02-23T07:19:32","guid":{"rendered":"https:\/\/www.cybermedian.com\/es\/?p=8875"},"modified":"2022-02-24T08:17:02","modified_gmt":"2022-02-24T08:17:02","slug":"equipos-multifuncionales-frente-a-autoorganizados-frente-a-funciones-frente-a-equipos-de-componentes-en-agile","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/es\/cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile\/","title":{"rendered":"Equipos multifuncionales frente a autoorganizados frente a funciones frente a equipos de componentes en Agile"},"content":{"rendered":"
\n
\n
\n
\n

Tradicionalmente, un proyecto se organiza en torno a\u00a0\u00a0equipos de componentes<\/strong>\u00a0\u00a0(es decir, UX, Dev, Business, Tester y…), cualquier lanzamiento que requiera una variedad de conocimientos de componentes deber\u00e1 involucrar a varios equipos de componentes.\u00a0Por lo general, diferentes equipos tendr\u00e1n diferentes conjuntos de prioridades, lo que inevitablemente genera cuellos de botella en el ciclo de lanzamiento del producto.<\/p>\n

Seg\u00fan Wikipedia, un equipo multifuncional es un grupo de personas con diferentes conocimientos funcionales que trabajan hacia un objetivo com\u00fan.\u00a0Una de las mejores maneras de mejorar la calidad de su equipo es hacerlo multifuncional.\u00a0Un equipo multifuncional tiene todas las habilidades necesarias para convertir una idea en un producto funcional.<\/p>\n

\u201c\u00a0Los\u00a0\u00a0<\/em>equipos multifuncionales<\/em><\/strong>\u00a0\u00a0tienen todas las competencias necesarias para realizar el trabajo sin depender de otros que no forman parte del equipo<\/em>\u00a0\u201d \u2014 Gu\u00eda Scrum<\/p>\n

En contraste con el enfoque de equipo de componentes,\u00a0\u00a0los equipos multifuncionales<\/strong>\u00a0\u00a0son grupos formados por personas de diferentes \u00e1reas funcionales de la empresa.\u00a0\u2014 debe estar formado no solo por especialistas t\u00e9cnicos (back-end, desarrolladores de front-end, ingenieros de control de calidad, etc.) sino tambi\u00e9n por miembros como Business Analysts, especialistas en marketing y UX o cualquier otra persona que participe activamente en el proyecto.<\/p>\n

<\/figure>\n

Un\u00a0\u00a0equipo autoorganizado<\/strong>\u00a0\u00a0es un equipo que tiene la autonom\u00eda para elegir la mejor manera de realizar su trabajo, en lugar de ser dirigido por otros fuera del equipo.\u00a0A diferencia de los principios de gesti\u00f3n tradicionales, los equipos empoderados autoorganizados no est\u00e1n dirigidos ni controlados desde arriba;\u00a0m\u00e1s bien evolucionan a partir de miembros del equipo que participan activa y colectivamente en todas las pr\u00e1cticas y eventos de Scrum.<\/p>\n

<\/figure>\n

Equipo tradicional vs equipo \u00e1gil<\/p>\n

\u201cUn\u00a0\u00a0<\/em>equipo de autoorganizaci\u00f3n<\/em><\/strong>\u00a0\u00a0consiste en un grupo de trabajadores del conocimiento que tienen que administrarse a s\u00ed mismos.\u00a0Tienen que tener autonom\u00eda\u201d \u2014\u200a<\/em>\u00a0Peter Drucker.<\/p>\n

La Gu\u00eda de Scrum indica que \u201cEl Equipo Scrum consta de un Propietario del Producto, el Equipo de Desarrollo y un Scrum Master.\u00a0Ellos son:<\/p>\n

\u201c\u00a0Los Equipos Scrum<\/strong>\u00a0\u00a0son\u00a0\u00a0autoorganizados<\/strong>\u00a0\u00a0y\u00a0\u00a0multifuncionales\u00a0<\/strong>\u201d \u2014\u200a<\/em>\u00a0Gu\u00eda Scrum:<\/p>\n

Equipo de componentes vs Equipo de caracter\u00edsticas<\/span><\/h3>\n

El enfoque tradicional consiste en dividir el producto de forma m\u00e1s o menos l\u00f3gica y significativa en componentes y asignarles equipos de componentes.\u00a0Sin embargo, estos componentes son completamente irrelevantes desde el punto de vista del cliente.<\/p>\n

Un enfoque de equipo de caracter\u00edsticas ahora es una forma casi universalmente aceptada para organizar sus equipos, a diferencia del equipo de pila de tecnolog\u00eda, especialmente, en el enfoque de entrega continua, enfatiza las caracter\u00edsticas (es decir, una porci\u00f3n vertical del sistema) que resuelven las necesidades de los usuarios que normalmente pueden acelerar entrega de valor de cualquier caracter\u00edstica o software funcional y acorta el ciclo de retroalimentaci\u00f3n de los usuarios reales.\u00a0Un equipo de caracter\u00edsticas tendr\u00eda todas las habilidades para realizar el trabajo necesario a nivel de tarea para realizar el trabajo.\u00a0En particular, suponiendo una arquitectura de tres niveles, los miembros del equipo trabajar\u00edan en tareas relacionadas con las partes de esta historia relacionadas con la GUI, el nivel intermedio y la base de datos.<\/p>\n

<\/figure>\n

La gran desventaja de la organizaci\u00f3n de componentes es obvia: ralentiza el flujo de valor.\u00a0La mayor\u00eda de las funciones del sistema crean dependencias que requieren la cooperaci\u00f3n entre los equipos de componentes para construir, implementar y, en \u00faltima instancia, lanzar.\u00a0Los equipos pasan gran parte de su tiempo discutiendo las dependencias entre los equipos y probando el comportamiento de los componentes en lugar de poder ofrecer valor al usuario final.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

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