Scrum master a tiempo completo: 42 Tareas

Uno de los artículos que más referencio en mi formación en Scrum (Qué es Agile) cuando hablo de las labores del Scrum Master es: 42-tasks-for-a-scrum-masters-job. Por alguna razón, todo el mundo parece entender que el Product Owner es un trabajo a tiempo completo, o ser miembro de un equipo también, pero que probablemente el rol del Scrum Master puede ser realizado a media jornada o incluso menos.
El scrum master también tiene mucho trabajo en equipos medianos o grandes, o nuevos. Muchos de liderazgo. Y es preferible que se centre en sus tares como scrum master, compartiendo su trabajo entre dos equipos por ejemplo, que trabajar también con la gorra compartida de miembro del equipo. ¿Por qué? Por que las labores que tenderá hacer son las de desarrollador antes que las de scrum master.

He querido traducir este artículo, para que quede en castellano, con permiso de Bernd Schiffer, para que quede constancia, y pueda referenciarlo en nuestro idioma :)

Artículo original: 42 Tasks for a Scrum Master’s Job

Update: ¡Cómo va a cambiar con la Inteligencia Artificial! Impact of AI in organizational design

Las siguientes preguntas aparecen a menudo cuando realizo formaciones o consultorías en Scrum:

¿Por qué los roles de Scrum Master y Project Manager deberían ser llevados por personas diferentes? (Quora)
¿Será el Scrum Master una ocupación al 100% o puede un programador ocuparse de ello si tiene mucha experiencia en planificación ágil? (Quora) 

Tras estas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Quien hace esas preguntas conjeturan con la posibilidad de ahorrar dinero juntando dos roles en una sola persona.

Las preguntas son realizadas por novatos como Scrum Masters, por product owners, por miembros del equipo, por managers, por stakeholders de cualquier tipo. De los tres roles en Scrum, todos parecen inferir inmediatamente que ser miembro del equipo es un trabajo a tiempo completo -por que desarrollan software el día completo - y que ser un product owner es también a tiempo completo - por que desarrolla el producto todo el día-, pero parece difícil de imaginar cual es el trabajo de un Scrum Master pueda ser y el por qué diablos sería un trabajo a tiempo completo, también.

¿Quizás esos que preguntan no sepan que es lo que un scrum master hace todo el día?

Aquí presento una lista de 42 cosas que diría que son parte del trabajo de un scrum master:

Reuniones

- Facilitar reuniones para el equipo. Esto incluye:

   - Preparar

   - Moderar

   - Postprocesar

 - Realizar retrospectivas, que son especiales, por consiguiente las cuento separádamente.

Dinámicas de equipo

 - Realizar coaching a los miembros del equipo (p. ej. coaching 1a1)

 - Mediar en los conflictos

 - Ayudar al equipo en la toma de decisiones

 - Fomentar la auto-organización del equipo

 - Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el product owner (más funcionalidad)

Aprendizaje

 - Continuar aprendiendo todo lo relativo a Agile (p. ej. visitar grupos de comunidades, atender a conferencias, leer libros, escribir blogs,…)

 - Asesorar a los miembros del equipo en todo lo relacionado con Agile.

 - Ayudar al equipo a crear radiadores de información.

 - Dar feedback al equipo.

 - Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme trabajo para invertir el tiempo de un Scrum Master, incluyendo por ejemplo, publicación/releases automáticas, entrega continua, TDD, y muchos más).

 - Desafiar al equipo con nuevas ideas sobre Agile Management (p. ej. FedEx -Days).

 - Colaborar constantemente con otros Scrum Master en la organización (p. ej. a través de la comunidad de práctica).

 - Bajar al Gemba.

Producto

 - Ayudar a escribir o dividir historias de usuario.

 - Ayudar a escribir o adaptar la visión del producto.

 - Ayudar a ordenar los elementos de la pila de producto.

 - Ayudar con la planificación del sprint.

 - Estar familiarizado con el trabajo del equipo (p. ej. el producto)

[Sobre producto hemos escrito Desarrollo de Producto y facilitación]

Visión general

 - Juntar a la gente que debería hablarse entre ellos.

 - Estar en contacto con los stakeholders regularmente.

 - Ayudar al equipo a informar a management.

 - Ayudar a fortalecer la comunidad ágil dentro de la organización

 - Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, stakeholders y el resto de la organización

 - Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas,…)

 - Ser la persona de contacto para todos en el equipo y los stakeholders en todo lo concerniente a Agile. 

 - Dar oportunidades de aprendizaje a la gente en la organización (p.ej. charlas o talleres) y permitirles aprender conceptos Agile importantes como p.ej. la deuda técnica.

Cambio

 - Ayudar al equipo a eliminar impedimentos.

 - Sugerir nuevas métricas para el equipo como catalizadores del cambio

Espejo

 - Reflejar los valores ágiles y de scrum al equipo.

 - Recordar al equipo sus acuerdos (p.ej. políticas)

 - Ayudar al equipo a mejorar constantemente sus procesos.

 - Reflejar los problemas al equipo a través de la observación desde fuera.

 - Hacer preguntas abiertas.

 - Comprobar los modelos que usa el equipo (p.ej. sprint backlogs, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.

Varios

 - Ayudar al equipo a mantener el foco (p.ej. actuando como un buffer entre las distracciones externas y el equipo)

 - Ayudar al equipo a mantener sus herramientas scrum (paneles, pilas de acciones, gráficas, backlogs,…)

 - Ayudar al equip y el product owner para encontrar los adecuados:

    - Definición de terminado (DoD).

    - Definición de preparado (DoR).

¿Has hecho o considerado todo lo mencionado anteriormente? Tomate un respiro, ¡debes estar agotado!

     Creemos que el scrum master es un rol a tiempo completo para una persona en un equipo Scrum. Scrum Master Manifesto.

¿Interesado en mentoring de Scrum Master? 
Contacta -TAYARI-

Agile Fluency Model en castellano

He publicado el modelo de fluidez ágil en castellano.



Este modelo desarrollado por James Shore y Diana Larsen proporciona una interesante perspectiva sobre el camino al agilismo por los equipos.

Modelo de fluidez ágil.

Además, encaja muy bien con el diseño de equipos, y las topologías de equipos.

O el diseño organizacional.

Si llevo Kanban, también llevo los principios ágiles

Recientemente se está hablando de si kanban es una metodología ágil o no. Creo que la primera vez que me lo plantee fue al leer una serie de magníficos posts de Michael Sahota sobre la cultura de las organizaciones.

NOTA: Es realmente curioso que un tema tan específico haya llegado a una revista como Forbes. Steve Denning, al que debeis seguir atentamente si no lo haceis ya, está "fusilando" las ideas de Agile, pero moviendolas exactamente allá donde las necesitamos: en el mundo fuera de IT, hablando a la gente de siglas raras (CEOs, CTOs,...) y el resto de "managers" que no entienden el mundo IT.

M. Sahota empezó identificando los principios ágiles sobre una clasificación de culturas organizacionales.

Este modelo, de William Schneider, tiene dos ejes, uno para la orientación a realismo/posibilismo y otro para la orientación de orientación a las personas o a la compañía. Sahota clasifica las regiones COLABORACIÓN y CRECIMIENTO como las que encajan con la cultura Ágil. En resumen, establece los principios alineados con la cultura más adecuada a cada uno de ellos, y es donde se situan la mayoría de los 12 principios del manifiesto.
Posteriormente analizó kanban como metodología, aplicando el mismo sistema, y Kanban según él, pertenece a al cuadrante de CONTROL.

 Se centra en el sistema, en los procesos, y únicamente hace una pequeña (aunque importante) referencia a mejorar colaborativamente. No quiere decir esto que kanban no pueda dar soporte a los principios ágiles, todos tienen cabida.
La clave para mi es la siguiente: Una vez comenté en un tweet, imposible de encontrar ya :(, que Kanban bien hecho llevaría a terminar haciendo Scrum. Por supuesto hablaba del desarrollo de producto, donde encaja muy bien Scrum. Pero a lo que realmente me refería, es que no concebía kanban sin aplicar los principios ágiles. Buscando la mejora continua con los valores y principios ágiles, en los cuales Scrum se fundamenta. Sin principios ágiles no hay Scrum. Sin embargo, sí podrías hablar de kanban sin esos principios.

En realidad, kanban, como todas las herramientas es absolutamente agnóstica en cuanto a principios y valores. Más de una vez he insistido en la idea que podría parecer que hacer Scrum, sin hacerlo realmente. Si utilizas las reuniones, roles y artefactos de Scrum, pero no buscas la aplicación de los principios en los que se basa, no estás haciendo Scrum.

 Así que cuando voy a trabajar con un equipo que utiliza o empeiza a usar kanban, siempre llevo en la maleta los principios ágiles. El concepto de la gestión del flujo de trabajo y minimizar el trabajo en progreso de kanban, más los principios ágiles que nos guíen en nuestra mejora continua, crean una combinación ideal: un punto de partida muy útil para aquellos equipos que por las razones que fuera no pueden o no quieren empezar a trabajar con Scrum.

 Actualización Enero 2013: Un enlace interesante con la misma idea: Kanban Values or How I Almost Attacked a Manager With Hot Coffee

 Actualización Noviembre 2018 (!): Mi última visión sobre los principios ágiles. ¿los hemos perdido?

 Actualización Diciembre 2018: Sobre el Agile Manager.

Formación en Agile Coaching - Noviembre 2012

Este Noviembre Ariel Ber y yo vamos a impartir una formación en Agile Coaching, con Agilar. Se realizará en Madrid, y haremos un curso muy práctico, intentando transmitir también nuestra experiencia. No debéis dejar pasar esta oportunidad de escuchar a Ariel en acción ;)
Os pego la introducción al curso. Daos prisa que hasta el 24 de Septiembre hay descuento por inscripción temprana :)

Si te has hecho alguna de estas preguntas: 

• ¿Observas que tus equipos hacen agilismo, pero no son ágiles?
• ¿La mejora continua hace tiempo que dejó de ser continua?
• ¿Echaste en falta técnicas para trabajar con un equipo?
• ¿Cómo ayudar a los Scrum Masters de los equipos? ¿Necesitas comprender las motivaciones de las personas?
• ¿Cómo me enfrento a nuevos retos, tras los primeros pasos en el agilismo de los equipos?

Entonces, has encontrado lo que buscas.

Si sientes que necesitas superpoderes porque has sobrepasado tu zona de confort como Scrum Master y la organización te pide abordar el trabajo con varios equipos a la vez o atravesar las fronteras y conquistar terrenos hasta entonces desconocidos (involucrar al resto de la organización, gerencia, clientes, etc.).
Las herramientas que adquieres como Scrum Master son beneficiosas e imprescindibles para aplicar en equipos ágiles. Sin embargo, ya sea por su escalabilidad o por demandas de equipos avanzados, necesitas ampliar la visión del sistema. A través de este curso les proponemos desplegar y potenciar toda vuestra capacidad y habilidad para orientar y acompañar en la evolución a los equipos y a las personas. Un paso fundamental en el camino ágil hacia el máximo rendimiento.

URL: http://www.agilar.org/trainings/70-agile-coaching

Agilar: jugando en equipo

Uno de los comentarios más certeros sobre mí, me lo dijo un buen amigo al decirme: "Tú eres un jugador de equipo". Esto dicho cuando te acabas de poner como freelance para buscarte la vida por tu cuenta, puede sonar a golpe bajo (¡ouch!), ¿para que quieres tener un coach personal teniendo amigos así? :) Pero en realidad, no le faltaba razón.
Lo cierto es que me gusta trabajar en equipo. Compartir los objetivos. Compartir las alegrías y problemas del camino. Ayudar. Y es algo que cada vez iba a hacer menos trabajando por mi cuenta. En realidad, me han salido muchísimas colaboraciones y propuestas con más personas. Pero cada vez, las decisiones y los objetivos eran más individuales.

Así que ahora, al cruzarme con un proyecto para trabajar en equipo (¡y vaya equipo!) no me ha costado demasiado trabajo decidirme. Me uno a Agilar para continuar desarrollando mi camino como "Agile Coach". Agilar está en un momento muy interesante, reinventándose como organización. Tenemos mucho trabajo por delante para crear la clase de organización que se adapte al agilismo y a nosotros. X. Quesada lidera la idea de crear la organización que este fundada por los valores ágiles. No podría estar más de acuerdo :)

Sigo siendo autónomo, freelance. Tengo muchas colaboraciones entre manos, independientemente de este proyecto todavía. Dependo de mis propios pasos para llegar donde quiero (como todos en realidad, ;) supongo...). Pero ahora juego en equipo.

Protocolos básicos para mantener la visión compartida (#coreProtocols) en un equipo

Con un par de semanas de retraso, pero es que me pillaron las vacaciones, publico este post explicando uno de los temas que propuse en el AOS2012: los "Core Protocols" o comportamientos básicos para crear y mantener la visión compartida en un equipo.

Mi presentación en el AOS traté de explicar y dar a conocer brevemente los Protocolos Básicos de comportamiento, que propone Jim McCarthy para el trabajo en equipo. Básicamente la idea nace de un concepto muy simple: Equipo=Producto. (Esta ecuación ya cambio mi mundo en el 2008).
Con esa idea en mente, los McCarthy se embarcaron en un experimento que debio ser bastante alucinante. Basicamente estudiar como diferentes equipos trabajaban juntos, observando y estudiando qué les hacía funcionar mejor. El mismo lo explica ampliamente en su sitio. Y el libro original lo podeis conseguir libre.

Doy acceso a un documento compartido donde estábamos traduciendo algunos de los protocolos, y están traducidos los compromisos. Os explico qué hay en ese documento:

Traté de explicar en la sesión del AOS lo que he leido sobre los protocolos y algún experimento que hemos hecho y lo que hemos trabajado. Básicamente se componen de dos partes. Primero, los compromisos básicos, una serie de principios, que deben ser compartidos por el equipo. Cuando los lees generalmente piensas que son obvios, y en cuanto rascas la superficie, te das cuenta del número ingente de veces que nos los saltamos. ¿quién no ha estado en una reunión escuchando y "aguantando" sin estar realmente presente, sin aportar valor? ¿quién no ha rechazado ideas sin evaluarlas, solo por que las dice Fulano o Mengano, al que no aguanto? Creo que es un ejercicio ver negro sobre blanco esta serie de asunciones, que no nos atrevemos a hablar en voz alta. (Ya tienes tema para una retro de equipo ;) )

Por otro lado, hay una serie de protocolos... digamos, una serie de reglas de comportamiento. Sí, reglas. Sí, de comportamiento. Esto es lo que más rompe los esquemas. ¿reglas? ¿no debíamos basarnos en principios? ¿y además de comportamiento? ¿no es ir un paso más allá de donde es necesario? Pues ahí está mi duda. Como herramientas, muchas de ellas me parecen fabulosas, para tomar decisiones rápidas, para trabajar en reuniones, para asegurarte que entregas valor en cada situación productiva... y son cuestiones que se pueden ir incorporando a las técnicas de un equipo. Pero no sé como funcionará como reglas "de obligado cumplimiento" en un equipo. Todo será probarlo, e introducirlas como experimento poco a poco.
La verdad es que da la impresión que encorsetará demasiado a un equipo. Por otro lado, me fascina tanto la posibilidad de que se pueda llegar a tener algo que nos acerque hacia el trabajo ideal en equipo, que me parece que merece una oportunidad. En realidad, sé que volvemos a lo de siempre, y es que si no se cree en los compromisos (principios) ninguna regla va a ir a poner orden en un equipo. Pero, podrían ayudar una vez en esa situación?

Por otro lado, si alguien va a trabajar y experimentar con estos protocolos, dos cosas: No os olvideis de contármelo después :), y que sepáis que Jim McCarthy estará a finales de Agosto en la ALE2012 en Barcelona, donde seguro que nos habla de su libro ;) Además, haré un descuento importante en algún trabajo de consultoría si quereis que lo trabajemos juntos :)

Open Space, para un roto o para un descosido

NOTA: Estoy escribiendo la guia de facilitación de Open Space.

Hemos hablado varias veces aquí ya de los Open Space como un formato increible para la organización y facilitación de conferencias. En Agile-Spain hemos organizado ya tres a nivel nacional, y han surgido multitud de pequeños "opens" para tratar muchos temas alrededor del agilismo.
Si no sabes qué es un Open Space, echa un ojo a esta explicación, o no entenderás demasiado el siguiente post :)
Pero un Open Space puede servir más que para la organización de conferencias. Veamos una definición usada en http://www.openspaceworld.org/:

Open Space Technology is one way to enable all kinds of people, in any kind of organization, to create inspired meetings and events. Over the last 20+ years, it has also become clear that opening space, as an intentional leadership practice, can create inspired organizations, where ordinary people work together to create extraordinary results with regularity.

Me gusta por que coincide con uno de mis mantras: "De lo racional a la inspiración". Se puede usar el formato de Open Space como herramienta de gestión del cambio en las organizaciones. Es un formato que ensalza la participación, y que crear espacios de colaboración realmente potentes.
Hasta ahora había visto este formato más como organización de conferencia o encuentros. Pero he visto el verdadero poder al facilitar un Open en una organización. Cuando participamos en un Open como formato de conferencia, cada uno se lleva lo que escucha y lo que aprende. Cuando realizamos un Open en una organización, es importante que quede constancia de los temas que se traten y las conclusiones a las que se llega. Es un regalo para la organización. Un punto de partida desde el que trabajar, donde la gente interesada ha participado para crearlo. Co-crear el cambio en una organización es un punto clave para que sea aceptado, y vaya en la dirección adecuada.

• Intenta involucrar al mayor número de personas posibles, pero no obligues a asistir. Insiste ;) , pero no obligues.
• Calma en el momento de sacar temas. A veces parece que no salen nuevos temas, ten sangre fría :) siempre se generan muchas ideas.
• Controla los tiempos, es importante cumplir los plazos marcados en la agenda.
• Haz consciente a todos los asistentes que ni el facilitador ni la organización dirigen la reunión. Que un Open es SU reunión, SU agenda, y SUS conclusiones.
• Haz enseguida un plan de acción para tratar las conclusiones.

Dar la posibilidad a la gente de actuar en los cambios abre muchas puertas, muchas ideas, y genera una confianza increible en sus propias posibilidades. El camino del cambio en las organizaciones sufre muchas dificultades. Inspira a la gente hacia la dirección adecuada.

Agilismo sin software

Al establecerme como profesional independiente, queriendo ganarme las habichuelas como Agile Coach danzando al viento para esparcir los principios ágiles, no había pensado, que uno de mis primeros trabajos sería en una empresa NO relacionada con el desarrollo de sw.
Por casualidades de los contactos (¡gracias!) estoy colaborando con una empresa de fabricación de componentes mecánicos para aeronautica. (!) Y no producen software. Aquí trabajan con la creación del proceso de industrialización, antes de crear piezas en serie. Así que mi primera reacción ante la petición de ayuda fue pensar, "¿y qué hago yo aquí?" Sin embargo, viendo el objetivo de la organización: crear equipos, organizar el trabajo del conocimiento, realizar cambios culturales,... le di una vuelta, y me di cuenta que era en gran parte lo que había tratado de hacer estos últimos años.
Así que estoy trabajando con una organización que realiza industrializaciones de piezas de aeronautica, implantando Kanban, ayudando con la gestión de equipos, técnicas de retrospectivas y en general, ayudando a trabajar con una filosofía de mejora continua basada en Lean.

Los problemas que he encontrado son básicamente los mismos que en los equipos de desarrollo de software, solo que aquí no entiendo nada de lo que producen :) ... ¡y no importa! Es verdad que en este area no puedo recomendar montar un servidor de integración continua, o explicar como hacer TDD. Pero puedo hablar de comunicación, de gestión de equipos, trabajar con paneles kanban, trabajar la organización del proceso,... es decir, transmitirles algunos de los valores más importantes para mi con el agilismo: transparencia, mejora continua, trabajo en equipo.

La principal sorpresa fue trabajar con un panel kanban de más de 40 fases. Y comprobar que todos hacen falta. Olvidémonos de nuestro mítico análisis-diseño-desarrollo-testeo-deploy :)

El poder de reflejar el trabajo en un panel kanban es impresionante. De repente, tenemos información, y sobre todo, un lugar desde el que partir para mejorar. El equipo empieza a organizarse alrededor de ello. Y a contagiarse las ganas de hacer las cosas bien y mejor cada vez.

Las prácticas y principios que hemos aprendido desde el desarrollo de software y metodologías ágiles, son transportables a otros mundos, donde el principal problema en común es la gestión del conocimiento. Lugares comunes donde la inspección y adaptación y las personas, son los mejores enfoques para afrontar los problemas.

Metodologías Agiles y coaching

Este post tiene como raíz las conversaciones con Visi Serrano, otra emprendedora como profesional independiente, psicologa y facilitadora de procesos participativos, colaborativos y autogestionados y muchas cosas más que me sorprenden desde mi visión de ingeniero.

En las metodologías ágiles se habla mucho de la figura del Agile Coach, casi como el nirvana de la figura de un Scrum Master. El coaching aporta un valor inmenso a los que los que ayudamos en la implantación de metodologías ágiles, por su caracter enfoque de conseguir metas o habilidades personales.
En las metodologías ágiles, no es suficiente con hablar de procesos a seguir. Hay que hablar de principios y valores. Y es ahí donde el coaching más nos ayuda.
De todas maneras, siempre que me preguntan por al Agile Coaching, suelo indicar que no es realmente coaching. No el coaching que la mayor parte de las personas piensan cuando oyen esa palabra. El otro día, Tobias Mayer comentaba en Twitter:

for those who asked, Agile Mentor, Agile Guide or even Agile Sherpa are more accurate descriptors than Agile Coach, in almost all cases. https://twitter.com/#!/tobiasmayer/status/173280854108409856

   Y en general estoy de acuerdo con él. Lo que muchas veces llamamos coaching en el mundo de las metodologías ágiles, es realmente un mentoring, una guía, o simplemente una formación. Las diferencias fundamentales, 

• que el coaching trabaja con que la solución sale del coachee. Como Agile Coaches, muchas veces debemos forzar las soluciones, enseñar un camino claro.
• que el coaching no dirige, va donde el cliente quiere. Sin embargo, en el caso de un agile coach, obviamente, no se puede ir donde quieras. Si te dicen que quieren hacer waterfall, ¿les dejas? :D ¡No! 

   Y aún así, me he ido a recibir formación en coaching -un curso sobre coaching co-activo, por cierto, muy interesante. Me parece una de las herramientas más potentes para provocar el cambio en las personas. El conocimiento y las técnicas que aporta me resultan útiles para entender a los clientes, para entender a los equipos y para entender a las personas (no quiero decir que los clientes no sean personas! ;) ). El cambio cultural para una implantación de metodologías ágiles es un cambio imprescindible, y desde la perspectiva que nos proporciona el coaching, más facil de atacar y conseguir.
   A raíz de unos mensajes cruzados en Twitter, por intereses comunes -si no recuerdo mal fueron a partir de charlar sobre "Open Space Technology"- Visi Serrano y yo llevamos unas semanas preparando unos temas, donde podremos aunar la experiencia en metodologías ágiles de uno, y la experiencia en coaching y cambio organizacional de otra. Hemos visto claro que los dos campos son muy complementarios. Así que para centrarnos en la primera linea del manifiesto, una de las primeras cuestiones que deberíamos entender es como trabajar con personas, y eso es precisamente donde observo que el coaching más nos ayuda. Nos ayuda a ver las cosas desde la perspectiva de otras personas, a entenderlas y escucharlas. La creación de equipos auto-organizados siempre ha sido una especie de mito, y no es nada fácil de conseguir. El trabajo con un coach especialista en estas tareas, puede facilitar la labor de manera importante.
   Como autodenominados Agile Coach, sabemos hacia donde debemos dirigir a las personas y los equipos. Sabemos qué valores creemos, y debemos transmitirlos. Sabemos el por qué de estas metodologías y debemos cambiar nuestra parcelita del mundo. El coaching nos ayuda a que otras personas descubran y transiten ese camino más fácilmente, y nos da mejores herramientas para acompañarles.

   A raíz de las conversaciones con Visi, he visto que el coaching ontológico, y con su experiencia en trabajo de cambio en organizaciones,  podemos ofrecer las dos caras de la moneda que se complementan perfectamente. Pronto, más en sus pantallas y sus organizaciones ;)


PD: Este es el post cruzado de Visi: Psicología y Scrum: desarrollo ágil de equipos.