Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Por aquí ya hemos hablado una vez y otra sobre como gestionar los datos sensibles (como las cadenas de conexión) de nuestras aplicaciones, porque, claro, nadie debería de poner los datos de producción en el código fuente que grabamos en nuestro repo, ¿verdad?

Anteriormente las opciones pasaban por efectuar mezclas/transformaciones de tal manera que en tiempo de compilación se generara un archivo final con los datos sensibles correspondientes a cada entorno, lo cual si bien nos daba simplificación para colocar la clave correcta en el paquete y entorno correcto, nos obligaba a seguir versionando las cadenas de conexión en el código fuente (por no mencionar que había que compilar mas de una vez); la otra opción pasaba por gestionar dentro del entorno de destino (en nuestros ejemplos: WebApps) sobrescribiendo de esta manera los valores que vinieran desde el código fuente.

Dado que ni nuestro repositorio ni nuestra herramienta de integración/despliegue deberían contener datos sensibles, usaremos un servicio de nube que nos da la seguridad necesaria para gestionar nuestras credenciales, el Azure KeyVault, el cual nos permite almacenar de manera segura y granular ya sea certificados digitales como data sensible, pudiendo restringir quienes pueden acceder a que datos y a que no (aplicando Control de acceso basado en roles: RBAC). Un mecanismo usual de accesos a estos recursos sensibles es programar dentro de nuestra aplicación un código que lea los valores en tiempo de ejecución (procurando no releer el valor a cada uso, sino hacerlo una única vez), en este caso usaremos un enfoque distinto que consistirá en leer los valores almacenados en KeyVault durante nuestro pipeline de despliegue, alterando secciones del archivo appsettings.json (porque nuestro ejemplo se basara en .Net Core) que se alojara en nuestra Web App destino (aunque también funciona perfectamente en un despliegue sobre IIS).

Así que estos serán los pasos que seguiremos:

  • Crear un KeyVault
  • Crear un “Secret” dentro de nuestro KeyVault, ahí sera donde almacenaremos una cadena de conexión a la base de datos
  • Identificar el “Principal” mediante el cual nuestro Team Project se conecta a Azure
  • Dar los permisos sobre nuestro KeyVault a dicho principal
  • Identificar en nuestra aplicación las secciones a modificar en tiempo de ejecución
  • Enlazar nuestro TeamProject contra el KeyVault, fijando el scope respectivo
  • Configurar el reemplazo de valores en el appsettings.json
  • Validar que nuestros cambios han sido desplegados en el entorno destino

Para esta demo asumiremos que tendremos tanto un pipeline de Build como de Release, de una aplicación en ASP.Net Core, en nuestro ejemplo usare la aplicación de ejemplo del libro de EF Core in Action (excelente libro que tuve el honor de revisar) cuyo código fuente se puede descargar aquí, y claro, como es usual el despliegue lo haremos contra una Azure Web App.

Para el primer paso seguiremos las instrucciones dadas en la primera parte de este articulo, en mi caso he usado estos nombres: RG_DevmoVault01 para el Resource Group y ErnestoDemoKeyVault para el KeyVault, como en este caso la creación la hemos hecho vía linea de comandos verificaremos que podemos revisar este recurso en el Portal de Azure, así:

Finish Reading: Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

En el Microsoft Ignite 2018!!

Estas semanas han sido muy intensas para mi pues tuve la ocasión de participar en el Microsof Ignite, que se realizo en Orlando el pasado Septiembre, y si, era la primera vez que iba a un evento de estas dimensiones, pero la emoción era mayor pues participaba como speaker al haber sido aprobada mi ponencia DevOps is about people, beyond automation, reto grande, ya que si bien es un tema que me es familiar significaba mi primera vez como orador en ingles, por lo que me pase un buen tiempo ensayando todos los días para estar a la altura del evento.

Domingo 23, MVP Preday donde nos dieron los ultimos tips para la presentación.

Ya en el evento en si, arrancamos con el Keynote de Satya Nadella, y tuve la suerte de poder ver de cerca la presentación.

Y antes de mi charla aproveche para visitar el stand de libros donde hojee dos de los libros que tuve la suerte de revisar para Manning

Y llego el momento, lunes 24 en el Expo Theater 6, tocaba presentar el material, felizmente todo salio bien ante mas de 100 asistentes.

Aquí con la gran Jessica Deen, de la League!!

Ya en los siguientes días, trate de aprovechar el evento con calma, pero primero atendí a una entrevista con el equipo de Microsoft Latam!!.

Ultimo día, mis pasos se dirigían con cierta pena al OCCC, pero contento por todo lo aprendido.

Con la promesa de regresar!!
Gracias OCCC y hasta la próxima!!!

Comparto mi sesión, esperando sus comentarios sobre estas visión de DevOps.

Presentando Azure DevOps

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

¿Qué es lo que esperamos de nuestros Scrum Masters?

Normalmente en los artículos y conferencias vinculados a la agilidad se nota mucho el enfoque de como los Scrum Master (y Agile Coaches) pueden ir mejorando, evolucionando y lograr lo mejor de los equipos para conseguir los objetivos esperados de la organización, pero… ¿cuantas veces hemos reflexionado sobre que es lo que esperamos los miembros “de base” de los equipos ágiles de nuestros respectivos SM? (*)

Es así que en la pasada reunión de Agile Perú, propuse el tema así que comparto las reflexiones de dicha reunión sumado a los comentarios de entonces y los que luego tuve en conversaciones posteriores.

Como punto de partida previo, hay que tener claro que no se esperaba que el Scrum Master fuera un “cargo” institucionalizado, si no mas bien un “rol” dentro de los integrantes del equipo; lamentablemente, por la deriva que ha tenido la “escena ágil”, la figura se ha consolidado, tanto por el movimiento de ex PMs que se acercaron a la agilidad, como por los profesionales que buscan ir a la rama de “gestión” esquivando lo técnico, esa es la realidad y si bien hay que recordar cual era la intención original del rol, también es bueno procurar canalizar de manera adecuada la situación en aras de lograr lo mejor para los equipos.

Con esto como base, soy de los que considera que el objetivo del Scrum Master es volverse prescindible para el equipo ya que ha procurado que este haya llegado a un grado de madurez que permite se pueda confiar en su auto-organización, esto implica muchos retos, pues el perfil de cada equipo es diferente, puede tratarse de profesionales con poca experiencia en las practicas ágiles (o en el dominio tecnológico respectivo) por lo que corresponderá un acompañamiento adecuado para que esto se vaya impregnando en el hacer de los miembros del equipo, o también tratarse de un equipo de rockstars con mucha experiencia tanto tecnológica como en agilidad y que por lo mismo tocara hacer los esfuerzos para que las diversas personalidades logren la sinergia y colaboración esperada. Como se ve, retos diferentes pero con el (se supone) mismo objetivo, convertir un grupo de personas en un equipo auto-organizado, así que creo que el éxito de la carrera de un SM (**) debe apreciarse por como (y a cuantos) ha contribuido a lograr que los equipos hayan llegado a ese estadio, que (por cierto esta en el Manifiesto Ágil) : “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados“. Finish Reading: ¿Qué es lo que esperamos de nuestros Scrum Masters?

Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.

Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.

Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.

Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Agilidad ¿responsabilidad de todos?

Si, por aquí de nuevo, luego de unas semanas muy ajetreadas, donde pudimos organizar el Global DevOps Bootcamp, renové mi participación en el programa Microsoft MVP (gracias por la confianza!) y se organizo el Ágiles Perú 2018 con motivo del décimo aniversario de nuestra comunidad.

El evento se realizo en la UTEC, y pese a todo lo acelerado que pasamos como comité organizador fue todo un éxito, mucho interés del publico por las charlas de los asistentes y varias propuestas interesantes en el Open Space.

 

En todo caso la jornada me dejo algunas anécdotas que están derivando en reflexiones, que comparto con uds. Finish Reading: Agilidad ¿responsabilidad de todos?

¿Una Imagen vale más?

En esta ocasión cedemos el espacio a una amistad de la comunidad que prefiere permanecer en el anonimato, pero tiene algo valioso y crudo que contar.

La famosa frase que dice “Una imagen vale más que 1000 palabras” ¿Realmente calza en todos los entornos? Porque lo que percibo en mi mundo laboral, mi entorno el desarrollo de Software, Aplicación de Negocios, y Mejora de Procesos, etc. Realmente esta frase solo engaña.  L

Mi comentario, es que ahora lo que se ve más por los pasillos son lindos posits  de colores e imágenes bonitas de equipos que aparentan la mejor calidez y que nada malo pasa por ahí.

Hasta que se tienen resultados. Finish Reading: ¿Una Imagen vale más?

De valor, historias técnicas y mantenimiento

A veces una reunión de la comunidad te genera un debate interno una revisión de tópicos que ya se habitan visto antes pero que conviene reflexionar y visitar de nuevo, así en la ultima reunión de Agile Perú Cynthia presento como tema principal si existían las historias técnicas, planteándose los siguientes conceptos clave: los componentes técnicos dependen o tienen que depender de un requerimiento de valor de negocio, siendo mayormente tareas y no deberían ser considerados como “historias” puesto que estas son una base para conversar, siendo clave el reflexionar valor de negocio que se le deja al cliente si al día de hoy se acaba el proyecto.

El debate posterior fue interesante, se comento que de haberlas no se debería llamarla “historias” sino “epicas” “enablers”, que si lo que importa únicamente es el negocio, lo cual me ha derivado a unas reflexiones que quiero compartir con ustedes.

Ante todo, hay que precisar ¿a que llamamos historias técnicas? En mi experiencia creo que corresponde llamar así a las actividades técnicas (sorry por lo redundante) que no se pueden subordinar o mapear directamente a requerimientos de negocio, siendo así ¿deberíamos considerar como tal al código que implementa una funcionalidad o historia de usuario? para respondernos planteémonos el caso de que  por X razones debemos escribir un script para conectarnos a una BD externa a fin de lograr realizar una consulta para uso de nuestros usuarios, pues no… no es historia técnica a pesar de su complejidad ya que hay una vinculación directa con un historia de usuario, lo contrario pasa con actividades tales como refactorización, configuración de infraestructura, etc, procesos que por su naturaleza transversal No deberíamos forzarlos (como muchas veces se insiste) a que encajen como tareas hijas de una historia de usuario.

Siendo así ¿que tipos de historias técnicas hay? pues Alexander Menzinsky nos recuerda una muy razonable categorización (**):  Arquitectura, Infraestructura de Producto, Infraestructura del Equipo, Refactorización y Spikes (investigación).

Como pueden darse cuenta, mi posición es a favor de la “existencia” de las historias técnicas como la ha sido desde hace unos años, ya entonces insistía en su lugar debido a la necesidad de hacer visible el “como” se llega a la necesaria entrega de valor que se propugna desde la agilidad, los años transcurrido han reafirmado mis posturas visto que las tendencias que ya comentaba entonces respecto al descuido al componente técnico no han hecho sino acrecentarse, siendo que sin pelear por la visibilidad no se lograra el cambio. ¿Y por qué es importante esa visibilidad? pues, como me comentaba Omares como si las historias (tradicionales) se hubiesen hecho para mostrar el exterior y no el interior… ” por lo que “hay una especie de vacío sobre donde poder ver dichos aspectos (técnicos) y que se valoren” ya que “las historias están hechas para conversar con el cliente y entenderse….pero la parte técnica, no la comprenderá mucho pero la valorara de la forma que pueda y en ese sentido la relegara hasta que pueda aprender sobre la importancia de esta en algún momento“, lo cual nos lleva a algo que sale a nuestras conversaciones de tanto en tanto, la importancia de explicar adecuadamente el rol estos componentes para que el Producto Owner acepte su inclusión en los sprints que vayan saliendo, y claro… ¿como se puede iniciar el dialogo sobre estos componentes si no están visibles? (*).

Dicho esto queda pendiente sobre como se deben visibilizar y nombrar, y reitero que no debe forzarse su subordinación a una historia de negocio, sino asumir su rol transversal en la generación de valor con calidad y su impacto en la capacidad del equipo, ahora… que no te guste el nombre de “historias técnicas” es otra cosa (a mi si, aunque si no te gusta usa otra opción, pero siempre hay que recordar que la nomenclatura tiene impacto en como entendemos las cosas), pero no por eso hay que retirar su lugar visible dentro de los flujos de un equipo, muy por el contrario toca potenciarlo como muestra Henrik Kniberg:

Dicho esto, toca tener un necesario balance para evitar que por mor de la excelencia técnica nos encontremos atrapados en ciclos de refactorización sin generación de valor como ironiza Angel Medinilla:

 

Así que toca seguir dando vueltas y recalcar la importancia de la visibilidad de los componentes técnicos dentro de nuestros backlogs y sprints, como parte importante de la calidad del software y el valor que entregamos.

Y ya que hablamos de valor, no puedo dejar de mencionar una conversación en la que se hablaba de como pasar de los ciclos de desarrollo y entrega a la etapa en que un software es mantenido, en ese momento se comenzó de hablar de “equipos de mantenimiento” y de “equipos que generan valor”, lo cual me hizo un ruido instantáneo por lo que tuve que manifestar mi postura respecto a que ese lenguaje involucraba que los equipos de mantenimiento NO generaban valor, siendo que consideraba que hay valor en el sostenimiento de las operaciones del negocio, y que encima agravaba las barreras dentro de la organización, generando naturales recelos que no hacen sino bloquear los objetivos de la organización, es que las palabras cuentan, y mucho.

(*) Mas allá del caso obvio de los aspectos de Infraestructura de Producto, como puede ser la instalación y configuración de un servidor, escenarios sobre los cuales también he escuchado defensas de colocarlos como subordinados a una historia técnica.

(**) Gracias a Guino por apuntar que quien planteo esta categorización fue Robert Galen.

¡Mudanza en MySQL

Tal vez algunos recuerden pero hace un tiempo migre este blog de Blogger a un servicio WordPress alojado en Azure, ha sido un buen tiempo desde la migración pero lo que no comente plenamente en su momento es que para poder funcionar WordPress requiere contar con una base de datos MySQL, siendo que al momento de la migración Azure no proveía un servicio manejado de MySQL por defecto se nos ofrecía una base de datos gratuita proveída por ClearDB, lo cual nos hace tener que administrar ese servicio en “otro lado”.

El caso es que entre las muchas novedades lanzadas por Microsoft en el Build del año pasado estaba el lanzamiento de una versión manejada (o sea que no tenemos que instalar un servidor Linux) de MySQL, por lo cual una de las cosas que pasaba por mi cabeza era migrar de ClearDB a Azure Database for MySQL, pero por una razón u otra siempre lo postergaba (aun cuando ya había creado una instancia en la misma zona geográfica y Resource Group que este blog!)

Y como suele suceder a veces es un hecho externo el que te hace pasar a la acción y en este caso fue la decisión de ClearDB de descontinuar los servicios gratuitos que estaba ofreciendo, dando como opción hacer un upgrade dentro de sus nuevos planes, pero como supondrán decidí hacer lo contrario y hacer pleno uso de mi BD en Azure, para lo cual seguí las instrucciones detalladas de este excelente post, con un salvedad que paso a contar:

El autor da las instrucciones para que una vez que, vía MySQL Workbench, nos hemos conectado a la BD destino y origen invoquemos un Wizard que efectúe la migración por nosotros y así lo intente, pero por alguna razón el efectuar pruebas consume el numero de conexiones que se pueden hacer hacia ClearDB, por lo que decidí jugar con otra opción: usar el backup que te ofrece ClearDB y tratar de restaurar en Azure, para lo cual entre a la consola web de ClearDB y exporte el ultimo backup disponible.

Una vez descargado el .zip exportado lo que tuve que hacer fue:

  1. Desempaquetar el archivo .sql que esta dentro del .zip (¡Si toda la base de datos esta en un archivo SQL!)
  2. En mi BD de Azure crear un schema con exactamente el mismo nombre existente en la instancia de ClearDB (para mas seguridad pueden copiar el comando de creación desde la BD origen)
  3. Seleccionar nuestra nueva bd/schema y ejecutar el SQL en cuestión.

Luego toca proseguir con las instrucciones del post respecto a la configuración de seguridad y conexión en nuestra Azure Web App de WordPress, pero adicionalmente es necesario editar el archivo wp-config.php de nuestro site, a fin de que todos los parámetros estén actualizados completamente, y claro luego de eso verificar que funcione adecuadamente, lo cual como pueden ver, va perfectamente.

Asi que … ¡gracias ClearDB, hola Azure Database for MySQL!

Aun es tiempo de DevOps… pero…

Hace unos meses comentaba sobre el interés creciente de las organizaciones sobre el concepto de DevOps y como estas debían enfocarse en la sinergia y colaboración a fin de mejorar la eficiencia de sus procesos de despliegue, lo cual implica todo un reto.

El problema es que en este tiempo he podido percibir que la percepción respecto a DevOps se ha quedado en la parte técnica del asunto, reduciendo DevOps a aplicar correctamente los scripts de despliegue, usar Docker y/o Infraestructura como Código, monitoreo, control de código fuente ahhh y si todo lo hacemos en la nube, mejor aun.

Y claro, así como en su momento surgio el boom de las certificaciones de los frameworks de proyectos, de liderazgo, de escalamiento, de cambio, era cuestión de tiempo que se implantaran por aquí los cursos y/o certificaciones de DevOps, con el sabor que se desee, contexto en el cual es difícil separar la paja del trigo.

En todo caso creo que debemos distinguir lo que propugna el enfoque DevOps: colaboración y sinergia en búsqueda de mejora de resultados, de una potencial implementación especifica en la cual ya pasamos directamente a las herramientas que se pueden utilizar, siendo que no hay recetas únicas sino el elegir adecuadamente el stack correcto según las necesidades y realidad de las aplicaciones y/o organización, por ejemplo… si uno “aprende DevOps” basandose en containers  ¿esos conceptos nos servirán para coordinar las mejoras para desplegar servicios Windows? (o viceversa).

Otro tanto viene con los procesos de reclutamiento de personal, la confusión es tal que como mencionaba Nico Paez se ve a “DevOps” como un perfil,  no como “mindset” (personalmente yo prefiero llamarlo “enfoque”) y como indique en mi sesión “En búsqueda del DevOps perdido” los reclutadores ven la palabra “DevOps” y te contactan preguntando por tecnologías que no están tu perfil; y por el otro lado pasa lo mismo, cuando me ha tocado entrevistar a postulantes por roles relacionados, al preguntar sobre el entendimiento respecto al enfoque DevOps no ha sido raro que lo primero que les vino a la mente fue … automatización!

Al final casi siempre termino regresando a la “definición” que en su momento hizo Carlos Peix respecto a como definir un “rol” para DevOps: “Para mí el nombre del rol debería ser “Facilitador de mentalidad DevOps”. Eso es lo que yo he hecho y hago en varios casos.

Sin duda, para cumplir ese rol, me viene muy bien saber de bash, de firewalls, de DMZs, de TCP/IP, de herramientas de automatización, lenguajes de programación, etc. También me viene bien haber sufrido mucho con el trabajo manual repetitivo, cometido errores y haber creado soluciones artesanalmente. Por último, también me ha sido útil desarrollar habilidades de facilitación de debate, procesos de diálogo y de discusión, de divergencia y de convergencia.” Y claro, el detalle es que en una certificación no te viene la experiencia de haber desplegado manualmente, el sufrir con organizaciones en las que el divorcio entre áreas sea tal que las ventanas para desplegar sean estrechas y escasas (¡alguien dijo silos?), ni el saber como son las cosas que uno quiere evitar para lograr la mejora.

En ese sentido, si uno va a estudiar herramientas para DevOps, pues genial, pero teniendo en cuenta que al final ese stack puede ser el valido en un contexto, pero que en otro corresponderá aplicar los criterios de colaboración y comunicación con tu equipo para entender el contexto y así poder definir correctamente el flujo y el stack necesario, pues son justamente esas capacidades de comunicación y de preguntar correctamente las que te permitirán adaptarte pronto a escenarios con herramientas que no hayas visto antes; y es que también de eso se trata el enfoque DevOps: no ser el super sabelotodo que domina tanto los stacks de desarrollo como de infraestructura sino de, con mucha humildad, poder plantear esquemas de colaboración y multicapacidad de los equipos.