Software Evolutivo

Colaboración en equipos tecnológicos: Integrando el Corazón de la Agilidad

Gissella Trujillo — Thu, 17 Oct 2024 23:45:13 +0000

Vivimos en una era donde la tecnología evoluciona a un ritmo vertiginoso. La incertidumbre, la volatilidad, la complejidad y la ambigüedad (VUCA) son la nueva normalidad.

En este contexto, los equipos de tecnología ya no pueden trabajar de forma aislada. La clave para destacar y ser competitivos radica en la colaboración.

La colaboración en equipos de tecnología es fundamental para mantenerse competitivo en el mercado actual. Las estadísticas muestran que el 97% de los ejecutivos considera que la falta de alineación dentro de un equipo impacta negativamente en los resultados de proyectos o tareas (Jobstik). Además, el 56% de los ejecutivos encuestados indican que las medidas relacionadas con la colaboración son el factor más importante que afecta la rentabilidad de sus organizaciones (KhrisDigital).

Estos datos resaltan la importancia de fomentar un ambiente colaborativo, ya que no solo mejora el rendimiento y la satisfacción de los empleados, sino que también contribuye a los resultados financieros y a la innovación de la empresa.

La Suma es Mayor que la Suma de las Partes

Cada miembro de un equipo aporta un conjunto único de habilidades, conocimientos y perspectivas. Cuando estos se unen y se complementan, el resultado es mucho mayor que la simple suma de sus partes individuales.

La colaboración multiplica las capacidades del equipo

La interacción entre los miembros del equipo no solo suma habilidades, sino que también genera una sinergia donde nuevas ideas pueden emerger. Es como si las ideas rebotaran y se combinaran, dando lugar a conceptos innovadores que no surgirían de manera aislada. Esto se traduce en que, en un entorno colaborativo, 1+1 puede ser igual a 5, ya que la colaboración potencia exponencialmente las capacidades del equipo. Esto sucede gracias a:

La colaboración en equipos no solo maximiza el potencial individual de cada miembro, sino que crea un entorno donde las ideas pueden florecer y convertirse en algo extraordinario. Es un claro ejemplo de cómo la colaboración puede superar la simple suma de sus partes, produciendo resultados excepcionales.

Agilidad: Un Corazón Colaborativo

En el corazón de la agilidad se encuentra la colaboración. Los equipos ágiles se basan en la comunicación abierta, la transparencia y la retroalimentación constante. Esto fomenta un ambiente de confianza donde todos los miembros se sienten valorados y empoderados para contribuir.

El corazón de la Agilidad, se centra en cuatro principios fundamentales: Colabora, Entrega, Reflexiona y Mejora. Estos principios, representados de forma visual en un diamante, encapsulan la esencia de la agilidad de manera simple y directa.

La belleza de estos cuatro principios radica en su simplicidad. No requieren una gran cantidad de formación o explicación para ser entendidos y adoptados. Al enfocarse en estos conceptos básicos, los equipos pueden cultivar una mentalidad ágil y un enfoque orientado a resultados, fomentando un entorno de trabajo dinámico y efectivo. El diamante que los representa es un recordatorio visual de que cada elemento es igualmente importante y está interconectado, formando un sistema cohesivo que impulsa el éxito de equipos ágiles.

Para este caso, nos centramos en cómo fomentar la Colaboración:

Trabajar en un equipo ágil, significa colaborar en sintonía. Y para hacerlo bien, hacerlo bien, es importante centrarse en tres aspectos clave: confianza, motivación y el acto de colaborar en sí mismo.

✨Confianza: La confianza es un tópico enorme. Una búsqueda rápida en Amazon entrega más de 91.000 títulos de libros de confianza. Cuando confías en tus compañeros, te sientes cómodo compartiendo ideas y opiniones, sin miedo a ser juzgado o ignorado, ahí estamos hablando de seguridad psicológica. Esto se construye con el tiempo y es vital para un equipo innovador.

“El clima de equipo positivo es el impulsor más importante de la seguridad psicológica y es más probable que ocurra cuando los líderes demuestran comportamientos de apoyo y consulta, y luego comienzan a desafiar a sus equipos” – McKinsey and Company

✨Motivación: La motivación es lo que impulsa a las personas a trabajar con entusiasmo. Puede ser de dos tipos: Motivación intrínseca: Es la que viene de adentro, como la satisfacción de hacer un buen trabajo o aprender algo nuevo. Motivación extrínseca: Son recompensas externas, como dinero, reconocimiento o promociones.

La motivación intrínseca es más poderosa; sin embargo, es diferente para cada persona, y podemos fomentar un ambiente motivador si entendemos las motivaciones de los miembros del equipo. Una manera sencilla de conocer los motivadores personales del equipo es mediante la dinámica de Moving Motivators o Champ Frogs. Estas herramientas te pueden ayudar a diagnosticar y mejorar los aspectos que motivan al equipo dentro del ambiente de trabajo.

✨El acto de colaborar: No es solo trabajar juntos, sino también comunicarse abiertamente, escuchar a los demás y ser flexible. La colaboración efectiva significa que todos los miembros del equipo se sienten valorados y que sus contribuciones son importantes.

Una herramienta que puede ayudar a diagnosticar y mejorar la colaboración es Dinámicas de Roles de Belbin: Esta herramienta permite identificar los roles que cada miembro tiende a asumir en el equipo, ya sea como líder, implementador, creador de ideas, etc. Al conocer estos roles, puedes ajustar el trabajo para que cada persona esté en una posición donde su colaboración sea más efectiva.

Preguntas para mejorar la colaboración

Para mejorar la colaboración en un equipo, es útil hacer preguntas con intención, es decir, preguntas que no solo busquen obtener información, sino que también fomenten la reflexión y el diálogo.

Sobre la confianza

¿Qué acciones pueden tomar los miembros del equipo para construir y mantener la confianza?
¿En qué momentos te has sentido más confiado trabajando con el equipo? ¿Qué contribuyó a esa confianza?
¿Hay alguna situación reciente en la que hayas sentido falta de confianza? ¿Cómo podríamos haber manejado mejor esa situación?

Sobre la motivación

¿Qué te motiva a dar lo mejor de ti en el equipo?
¿Qué factores disminuyen tu motivación? ¿Cómo podemos abordarlos como equipo?
¿Cómo podemos asegurarnos de que cada miembro del equipo se sienta valorado y reconocido por sus contribuciones?

Sobre el acto de colaborar

¿Qué herramientas o métodos han sido más efectivos para colaborar en proyectos recientes?
¿Qué desafíos has enfrentado al colaborar con otros y cómo los superaste?
¿Hay formas en que podríamos dividir mejor las tareas y responsabilidades para aumentar la eficiencia?

Las preguntas están diseñadas para promover una conversación abierta y reflexiva. Al centrarse en estos temas, los equipos pueden trabajar para crear un entorno de trabajo más colaborativo y efectivo.

Liderazgo en todos los niveles: ¿Quién Debería Impulsar la Colaboración en el Equipo?

Hacer preguntas intencionadas para mejorar la colaboración no solo ayuda a identificar áreas de mejora, sino que también fortalece las relaciones dentro del equipo. Pero, ¿Quién debería ser el encargado de hacer estas preguntas?

1. Líderes de Equipo y Gerentes

Los líderes de equipo y gerentes son responsables de establecer un ambiente de trabajo positivo y productivo. Como figuras de autoridad, tienen la responsabilidad de guiar las discusiones y asegurar que todos los miembros del equipo se sientan escuchados y valorados. Al hacer preguntas intencionadas, pueden:

Identificar obstáculos en la colaboración.
Fomentar la confianza y la transparencia.
Motivar a los miembros del equipo a expresar sus ideas y preocupaciones.

2. Facilitadores de Reuniones y Coaches Ágiles

Los facilitadores de reuniones, como Scrum Masters o coaches ágiles, juegan un papel crucial en la dinamización de equipos ágiles. Su función es observar las dinámicas del equipo y proporcionar retroalimentación constructiva. Al hacer preguntas, estos facilitadores pueden ayudar a:

Reflexionar sobre el trabajo realizado y encontrar áreas de mejora.
Promover la autoevaluación y el aprendizaje continuo.
Guiar al equipo hacia soluciones prácticas y efectivas.

3. Miembros del Equipo

Cada miembro del equipo tiene la capacidad de influir positivamente en la colaboración. Al ser proactivos y formular preguntas, pueden:

Contribuir a una cultura de apertura y honestidad.
Fomentar un diálogo constructivo y respetuoso.
Asegurar que las diferentes perspectivas sean consideradas y respetadas.

4. Consultores Externos

En ocasiones, las organizaciones pueden recurrir a consultores externos para obtener una perspectiva imparcial. Estos profesionales pueden facilitar discusiones y realizar preguntas que quizá no sean obvias para los miembros internos del equipo. Al hacerlo, pueden:

Identificar problemas subyacentes que podrían estar afectando la colaboración.
Proporcionar soluciones basadas en experiencias de otras organizaciones.
Ayudar a implementar cambios estructurales o culturales necesarios.

La responsabilidad de hacer preguntas intencionadas para mejorar la colaboración no recae en una sola persona. Es un esfuerzo colectivo que debe ser fomentado por todos los niveles de la organización. Al fomentar una cultura de preguntas abiertas y reflexivas, se pueden identificar problemas y oportunidades de mejora, lo que lleva a un equipo más cohesionado y eficiente.

Recuerda:

La clave está en la disposición para escuchar y actuar sobre las respuestas recibidas.

¿Cómo fomentamos la colaboración en Software Evolutivo?

En Software Evolutivo, creemos que la agilidad es clave para ofrecer resultados exponenciales a nuestros clientes.

Más allá de las técnicas y herramientas, lo que realmente marca la diferencia es cómo colaboramos y trabajamos en equipo. La agilidad es un enfoque que nos permite adaptarnos rápidamente, y fomentar una cohesión efectiva entre nuestros equipos de desarrollo y comercial.

Colaboración Continua y Transparente: Organizamos reuniones diarias y revisiones de sprint para alinear objetivos y facilitar el intercambio de información. Esto asegura que todos los miembros del equipo estén informados y puedan contribuir con sus perspectivas únicas.
Equipos Multifuncionales y Autonomía: Nuestros equipos están formados por profesionales de diversas disciplinas que trabajan juntos para resolver problemas y mejorar productos. La autonomía les permite tomar decisiones rápidas y efectivas, adaptándose a las necesidades del cliente.
Cohesión a Través de la Retroalimentación y la Reflexión: Realizamos retrospectivas al final de cada sprint para discutir aciertos y áreas de mejora. Este proceso fomenta un ambiente de apertura y confianza, crucial para el desempeño efectivo del equipo.
Integración de Perspectivas para Soluciones Óptimas: La colaboración entre los equipos de desarrollo y comercial nos permite crear soluciones ajustadas a las necesidades del mercado, maximizando el valor entregado a nuestros clientes.
Fortalecimiento de la Relación con el Cliente: Involucramos a nuestros clientes en cada fase del proyecto, asegurando que sus necesidades sean comprendidas y atendidas. Esto resulta en productos que realmente solucionan sus problemas y añaden valor significativo.

En Software Evolutivo, la agilidad es mucho más que un enfoque; es un reflejo de cómo trabajamos juntos para alcanzar el éxito. Nuestra cohesión interna y nuestra capacidad para colaborar de manera efectiva nos permiten entregar soluciones de software que cumplen con estándares, superan expectativas y generan un impacto positivo en nuestros clientes.

Conclusiones

La Colaboración como Pilar de la Innovación
En la era del conocimiento, la colaboración es fundamental para el éxito. La diversidad de habilidades y perspectivas en un equipo crea un entorno donde la suma de las partes es mucho mayor que sus componentes individuales. Este fenómeno, donde 1+1=5, demuestra cómo la sinergia puede llevar a soluciones innovadoras y eficientes que no serían posibles en el trabajo aislado.O como dice el proverbio africano: “Si quieres ir rápido ve solo, si quieres llegar lejos ve acompañado”

El Corazón de la Agilidad: Simplicidad y Efectividad
Los principios del corazón de la Agilidad—Colabora, Entrega, Reflexiona y Mejora—son simples pero poderosos. Estos principios no solo facilitan la colaboración efectiva, sino que también promueven un enfoque ágil y adaptable en un entorno de trabajo dinámico. La simplicidad de estos conceptos permite su fácil adopción y aplicación, potenciando la productividad y la satisfacción del equipo.

Importancia de la Comunicación Abierta y la Retroalimentación
Para fomentar una colaboración efectiva, es crucial mantener una comunicación abierta y honesta. Las preguntas intencionadas, ya sean formuladas por líderes, facilitadores o los propios miembros del equipo, ayudan a identificar áreas de mejora y a fortalecer las relaciones internas. Este enfoque promueve un ambiente de confianza y respeto, esencial para un trabajo colaborativo exitoso.

¿Buscas mayor agilidad y eficiencia?

Automatiza y moderniza tus sistemas con nuestras soluciones en automatización y modernización de aplicaciones.

¡Da el siguiente paso hacia la transformación digital!

Modernización de Aplicaciones

The post Colaboración en equipos tecnológicos: Integrando el Corazón de la Agilidad appeared first on Software Evolutivo.

GitHub Flow, una forma ligera y eficaz para gestionar tu Software

Fernando Paz — Wed, 24 Jul 2024 20:38:09 +0000

En el mundo del desarrollo de software y la gestión de productos digitales, mantener un flujo de trabajo eficiente y colaborativo es crucial. Se presenta aquí a GitHub Flow, una forma ligera y eficaz para gestionar tu Software. Exploraremos qué es GitHub Flow, cómo funciona, y por qué podría ser la estrategia perfecta para tu equipo de TI.

¿Qué es GitHub Flow?

GitHub Flow es un modelo de flujo de trabajo ligero y basado en ramas que facilita la experimentación y colaboración en equipos de desarrollo. Diseñado para ser simple y efectivo, este flujo se centra en la integración continua (CI) y la entrega frecuente de código.

El proceso de GitHub Flow

El siguiente diagrama muestra cómo el workflow propuesto de GitHub Flow para la gestión de los fuentes:

Crear una rama: Todo comienza con la creación de una nueva rama desde ‘main’ (la rama por defecto), para trabajar en una nueva característica o corrección.
Realizar cambios: En esta nueva rama, haces commits con tus cambios, iterando sobre tu trabajo.
Abrir un Pull Request: Cuando estés listo para el feedback, abre un Pull Request (o un Merge Request si estás en GitLab). Esto inicia la conversación sobre tus cambios.
Discusión y revisión: Tus colaboradores revisan el código, sugieren mejoras y discuten los cambios propuestos.
Implementar cambios: Basado en el feedback, puedes seguir haciendo commits en tu rama para mejorar tu propuesta.
Fusionar en main: Una vez que los cambios son aprobados, se fusionan en la rama principal (main).
Desplegar: Con los cambios en main, puedes desplegar inmediatamente.

La rama defecto es main, lo que significa que es la rama fuente para ambientes de producción y no tenemos ramas por versiones, tan solo las identificamos por tags, por ejemplo.

Casos de uso sugeridos

Desarrollo de nuevas características: Ideal para trabajar en nuevas funcionalidades sin afectar el código en producción.
Corrección de errores: Permite aislar y resolver problemas rápidamente.
Experimentación: Perfecto para probar nuevas ideas sin comprometer la estabilidad del proyecto.
Revisión de código: Facilita la revisión y discusión de cambios antes de integrarlos.
Releases continuas: Permite una entrega más frecuente y controlada de nuevas versiones.

Beneficios de adoptar GitHub Flow

Se presentan los siguientes como los principales beneficios:

Simplicidad: Un flujo fácil de entender y seguir para todos los miembros del equipo.
Flexibilidad: Se adapta a diferentes tamaños de equipos y tipos de proyectos.
Rápida iteración: Permite ciclos de desarrollo más cortos y ágiles.
Mejor colaboración: Fomenta la discusión y revisión de código entre el equipo.
Calidad mejorada: La revisión constante ayuda a mantener un alto estándar de código.
Despliegue continuo (CD): Facilita la implementación de prácticas de CI/CD.
Transparencia: Todos pueden ver y contribuir al progreso del proyecto.

Consideraciones y desafíos

Aunque GitHub Flow ofrece numerosos beneficios, es importante considerar también sus limitaciones:

Dificultad con versiones múltiples: GitHub Flow está diseñado principalmente para mantener una versión principal del software. Si tu producto requiere mantener y dar soporte a múltiples versiones simultáneamente (por ejemplo, para diferentes clientes o plataformas), este flujo puede resultar complicado de gestionar.
Complejidad en proyectos grandes: En proyectos muy extensos o con un gran número de colaboradores, el flujo puede volverse caótico si no se gestiona cuidadosamente. La cantidad de ramas y pull requests puede ser abrumadora sin una organización adecuada.
Dependencia de CI/CD: GitHub Flow funciona mejor cuando se implementa junto con prácticas robustas de Integración Continua y Despliegue Continuo (CI/CD). Establecer y mantener esta infraestructura puede ser un desafío para equipos más pequeños o con recursos limitados.

Conclusiones

GitHub Flow ofrece un enfoque ágil y efectivo para la gestión de versiones en productos digitales.
Su simplicidad lo hace accesible, mientras que su potencia lo hace escalable para proyectos de cualquier tamaño.
Al adoptar GitHub Flow, los equipos de TI pueden mejorar su colaboración, aumentar la calidad del código y acelerar el ciclo de desarrollo, llevando sus productos digitales al siguiente nivel.
Por supuesto hay otras propuestas para la gestión del versionamiento , como GitFlow o GitLab Flow, que pueden aplicar en escenarios donde necesitamos más control o tenemos que dar mantenimiento a versiones específicas.

The post GitHub Flow, una forma ligera y eficaz para gestionar tu Software appeared first on Software Evolutivo.

Kubernetes: Arquitectura y Recursos Principales

Jorge Aguilar — Thu, 18 Jul 2024 18:29:50 +0000

En un mundo donde se hace necesario disponer de aplicaciones escalables y que puedan responder a las exigencias de disponibilidad más demandantes, es donde surgen plataformas de orquestamiento de contenedores como Kubernetes. En esta entrada veremos la plataforma Kubernetes, su arquitectura y los recursos principales que la conforman.

¿Qué es Kubernetes?

Kubernetes se puede definir como un sistema de código abierto para la automatización del despliegue, el escalado y la gestión de aplicaciones contenerizadas.
Fue desarrollado por Google y es ampliamente utilizado en la industria para implementar y administrar aplicaciones en la nube privada, pública o híbrida entre estos dos tipos.
Kubernetes se ha convertido en la alternativa de facto cuando se requiere coordinar una gran cantidad de contenedores.

Kubernetes (K8s) se presenta como la respuesta natural al escalamiento de soluciones como Docker, containerd o contenedores en general.

(Si te interesa, en un artículo anterior compartimos los Primeros pasos en Docker).

Su adopción ha sido masiva en todas las industrias, con una tendencia a soluciones provistas en la nube.

Kubernetes no llega para reemplazar a los contenedores, sino más bien a complementarlos, lo que es muy beneficioso para responder a las demandas crecientes que tienen las aplicaciones nativas de la nube.

5 Beneficios Principales de Kubernetes

Kubernetes ofrece muchos beneficios para el despliegue de aplicaciones en entornos empresariales, más allá del escalamiento de la contenerización, así presentamos los siguientes 5 beneficios principales de esta tecnología:

– Escalabilidad Automática: Kubernetes permite escalar automáticamente las aplicaciones según la demanda, aumentando o disminuyendo el número de contenedores en función del tráfico o la carga de trabajo.
– Alta Disponibilidad: Gracias a su arquitectura distribuida y sus mecanismos de autorecuperación, Kubernetes asegura que las aplicaciones estén siempre disponibles, incluso en caso de fallos en los nodos o contenedores.
– Portabilidad y Flexibilidad: Las aplicaciones desplegadas en Kubernetes pueden ejecutarse en cualquier entorno que soporte Kubernetes, ya sea en la nube pública, privada o en entornos híbridos, sin necesidad de cambios significativos.
– Eficiencia en el Uso de Recursos: Kubernetes optimiza la utilización de los recursos del clúster, asignando contenedores a los nodos de manera eficiente y permitiendo un mejor aprovechamiento del hardware.
– Despliegues y Rollbacks Simplificados: Con Kubernetes, es posible realizar actualizaciones y rollbacks de aplicaciones de manera controlada y sin tiempo de inactividad (por ejemplo despliegue blue/green), lo que facilita la implementación de estrategias de integración y entrega continuas (CI/CD).

Arquitectura de Kubernetes

La arquitectura de Kubernetes se divide en dos partes:

Control Plane

El Control Plane es el corazón del sistema y se encarga de la gestión del cluster, así es, estamos hablando de un conjunto de servidores, conocidos como servidores master, trabajando de manera colaborativa. Los componentes principales del Control Plane son:

– API server: Servicios Web del tipo REST que dan acceso a consultas y peticiones sobre el sistema. La interfaz por línea de comandos o la consola Web lo utilizan para realizar las diferentes tareas administrativas y de monitoreo.
– etcd: Es una base de datos distribuida donde se aloja la configuración y el estado del sistema. Se accede a ella mediante el API server.
– scheduler: Es el componente encargado de asignar la nueva carga de trabajo a los nodos del cluster. Éste necesita información actualizada sobre la disponibilidad de los nodos y de los recursos que puedan ofrecer.
controller: Es el que monitorea el estado de los recursos del cluster y toma acciones para asegurarse que se regrese al estado esperado.

Cluster

El Cluster como tal, formado por nodos esclavos (servidores de máquinas virtuales o físicas) y que ejecutan las aplicaciones contenerizadas.

Nodo

Cada nodo ejecuta un agente llamado kubelet, el cuál se comunica con el Control Plane para reportar el estado y conocer sobre nuevos requerimientos. También se encarga de solicitar el inicio o detención de los contenedores en cada uno de los nodos.

Los nodos también ejecutan el kube-proxy de Kubernetes, que se encarga de la comunicación por la red.

Finalmente, tienen al Container runtime, que corresponde al espacio de ejecución de los contenedores, brindando acceso a los recursos de Hardware que puedan requerir, como son: memoria, CPU, red, etc.

Componentes Complementarios

Por otro lado, también podríamos considerar otros servicios que no son, de por sí, parte de Kubernetes pero que lo complementan para brindar soluciones integrales. Estas podrían ser:

– Image Registry: Repositorio de las imágenes de contenedor utilizados para crear los contenedores de las aplicaciones y servicios como por ejemplo una base de datos.
– Load Balancer: Servicio que redirige las peticiones de los clientes para que la carga pueda ser distribuida y también para aislar a los nodos que puedan tener problemas, soportando alta disponibilidad.

Recursos Principales

A continuación detallaremos los recursos que se consideran la base de Kubernetes y que a través de ellos se obtienen los beneficios más importantes de este tipo de soluciones.

Pod

La unidad más pequeña del despliegue en Kubernetes es el Pod y puede contener uno o más contenedores. Entre los contenedores que forman parte de un Pod comparten el mismo espacio de nombres y recursos como la dirección IP o volúmenes de disco, lo que significa que pueden comunicarse entre sí de forma fácil y rápida.

Service

Otro recurso importante de Kubernetes incluye al Service, que es una abstracción de uno o más Pods (están al frente de los Pods y proveen un balanceo de carga), proporcionan una dirección IP más estable que un Pod y además se publica un nombre DNS para facilitar la ubicación del mismo dentro de la red. Los Service se utilizan para que los Pods se comuniquen entre sí, siendo un intermediario, de forma segura y estable.

Deployment

Finalmente tenemos al Deployment, que es el elemento encargado de gestionar y actualizar un conjunto de pods similares. Un Deployment define la plantilla para los Pods y se encarga de crear y mantener la cantidad de los mismos que sean necesarios para cumplir con la especificación deseada. Los deployments también facilitan el despliegue gradual y el rollback de las aplicaciones.

Conclusiones

– Kubernetes como Solución Integral para la Gestión de Contenedores: Kubernetes se ha establecido como una plataforma esencial para la automatización y orquestación de aplicaciones contenerizadas. Su capacidad para escalar aplicaciones de manera automática, gestionar eficientemente los recursos y garantizar alta disponibilidad lo convierte en una solución robusta y adaptable para entornos de nube pública, privada e híbrida.
– Arquitectura de Kubernetes:
Control Plane y Clúster Distribuido: La arquitectura de Kubernetes está diseñada para proporcionar un control centralizado mediante el Control Plane, que gestiona el estado del clúster, y una ejecución distribuida en nodos, que asegura la operación continua de las aplicaciones. Esta separación de funciones permite una gestión eficiente y una recuperación automática ante fallos, mejorando la resiliencia de las aplicaciones.
– Beneficios tangibles de Kubernetes para DevOps: Kubernetes ofrece ventajas significativas en términos de escalabilidad automática, alta disponibilidad, portabilidad y eficiencia en el uso de recursos, lo que lo convierte en una herramienta fundamental para equipos de desarrollo y operaciones que buscan optimizar sus procesos de CI/CD.

Hasta aquí llegamos con esta entrega, para una próxima oportunidad estaremos abordando contenido práctico, donde crearemos recursos como los que hemos analizado previamente.

Esperamos que nos sigas acompañando en esta serie de artículos sobre Kubernetes y te invitamos a dejar tus comentarios o preguntas en la sección inferior. Nos encantaría conocer sobre qué otros temas te gustaría que compartamos. ¡Nos leemos pronto!

Referencias:

– https://kubernetes.io/

Conoce Nuestros Servicios

Escalabilidad sin Límites: Consultoría de Kubernetes para su Empresa

Nuestro enfoque en Kubernetes está diseñado para impulsar la escalabilidad de su infraestructura de TI, a través de la implementación estratégica de contenedores y la orquestación eficiente de aplicaciones y servicios, su infraestructura estará lista para escalar sin límites.

Solicitar DEMO

The post Kubernetes: Arquitectura y Recursos Principales appeared first on Software Evolutivo.

Apache ActiveMQ Artemis

Bryan Diaz — Wed, 17 Jul 2024 04:28:25 +0000

En este artículo vamos a hablar sobre una herramienta muy popular para la comunicación entre aplicaciones llamada Apache ActiveMQ Artemis, además revisaremos un ejemplo de cómo implementar su funcionamiento utilizando dos microservicios implementados con Spring Boot y Java.

A menudo, nos encontramos con eventos que suceden en nuestros sistemas y necesitamos que otros sistemas se enteren de ellos. Notificar estos eventos de manera síncrona puede generar problemas de rendimiento y disponibilidad, ya que los sistemas dependen de la respuesta inmediata de otros sistemas. En cambio, hacerlo de manera asíncrona presenta varias ventajas, como la reducción de la dependencia y el acoplamiento entre sistemas, mejorando la eficiencia y la escalabilidad de nuestras aplicaciones.

A veces, incluso tenemos procesos manuales que requieren la intervención de una persona para realizar acciones en respuesta a un evento. Con la ayuda de Apache ActiveMQ Artemis, podemos conectar nuestras aplicaciones de manera más eficiente y eliminar estos procesos manuales que no generan valor a nuestros negocios. Este tipo de productos, conocidos como MOM (Message Oriented Middleware), nos permiten implementar el asincronismo, facilitando la comunicación entre sistemas de una manera más flexible y robusta.

Artemis

Comenzamos hablando sobre qué es ActiveMQ Artemis.

En términos oficiales, Apache ActiveMQ Artemis es un intermediario que facilita la comunicación entre diferentes sistemas o aplicaciones. Es de código abierto, muy popular y multiprotocolo, basado en Java. Artemis permite integrar aplicaciones multiplataforma utilizando diversos protocolos, como AMQP (Advanced Message Queuing Protocol – Protocolo Avanzado de Cola de Mensajes), JMS, MQTT, STOMP, OpenWire, entre otros. Gracias a esta variedad de protocolos, Artemis es una excelente opción para tener comunicación entre dos aplicaciones y poder pasar información de un sistema a otro cuando ocurre un evento.

Arquitectura

La estructura utilizada es un Middleware Orientado a Mensajes (MOM), el cual permite la comunicación a través del intercambio de mensajes de forma asíncrona. Esto significa que las operaciones se llevan a cabo sin requerir que todas las partes involucradas en la comunicación estén disponibles al mismo tiempo que ocurre el envío de eventos, permitiendo así que los procesos continúen su ejecución sin esperar una respuesta inmediata.

En Artemis contamos con dos tipos de envío de mensajes: los mensajes que se envían a colas de tipo anycast y los de tipo multicast.

Anycast: Conocido como punto a punto (Point-to-Point), en este tipo de cola, varios consumidores están a la escucha de la misma cola y van leyendo los mensajes a medida que llegan. Sin embargo, no todos los consumidores pueden leer el mismo mensaje al mismo tiempo.

Multicast: Es un modo de distribución de tipo publicación-suscripción (pub/sub). Cada mensaje que se envía a una dirección de tipo multicast se replica a las colas que contienen cada sistema que esté a la escucha de los mismos. Como se muestra en la gráfica, aquí tenemos dos consumidores y ambos se enterarán del mismo mensaje al mismo tiempo.

Para el desarrollo de este blog, se trabajará con colas de tipo anycast.

La versión que utilizaremos de ActiveMQ Artemis será la última hasta la fecha de este blog, que es la 2.35. Podemos buscarla en DockerHub como se puede observar en la imagen.

Spring Boot

Para este blog vamos a trabajar con microservicios de Spring Boot, utilizaremos Maven y el lenguaje Java. La última versión de Spring Boot hasta la fecha de este blog es 3.3.1, y la versión de Java es 21. Agregaremos ActiveMQ Artemis a los proyectos. Los proyectos tienen el nombre de “producer” y “consumer”. El producer es el encargado de enviar el mensaje a Artemis y crear la cola en Artemis, y el consumer es el encargado de suscribirse a esa cola y leer los mensajes que envíe el producer.

Escenario a Resolver

En un hospital, hay dos sistemas involucrados en la gestión de camas que funcionan de la siguiente forma:

El Sistema A, encargado de registrar la disponibilidad de camas cuando un paciente abandona la sala de emergencias.
El Sistema B, monitorea la ocupación de camas en todo el hospital.
Actualmente, cuando el Sistema A registra que una cama está disponible, una enfermera debe ingresar manualmente esta información en el Sistema B.
Se busca una mejora para sincronizar automáticamente estos sistemas, de modo que cualquier actualización en el Sistema A se refleje instantáneamente en el Sistema B, eliminando la necesidad de registros manuales.

Para desarrollar este requerimiento, los proyectos que creamos en Spring Boot serán: el producer como nuestro Sistema A y el consumer como nuestro Sistema B.

En el proyecto que creamos en Spring, al agregar la dependencia de Docker y ActiveMQ Artemis, se genera un archivo compose.yaml. Utilizaremos este archivo para levantar nuestro contenedor de Artemis. En el proyecto producer, como es el que va a generar el evento, editaremos el archivo compose.yaml, añadiendo la siguiente información:

Para levantar el contenedor de Artemis con las modificaciones realizadas al archivo compose.yaml, en este blog se ejecutará con Podman porque la práctica se está realizando en un sistema operativo Fedora, que ya lo incluye. Pero si cuentan con Docker también pueden utilizarlo, no habría problema. Ejecutamos nuestro archivo desde la ubicación donde se encuentra nuestro archivo compose.yaml y ejecutamos:

podman-compose -f compose.yaml up

o con Docker:

docker compose -f compose.yaml up

Esto comenzará a descargar la imagen de Artemis.

Una vez que en los logs salga un mensaje como el siguiente: AMQ241004: Artemis Console available at link, podemos ingresar a un navegador y acceder a la URL localhost:8161 para acceder a la pantalla de Artemis.

Las credenciales serán las que configuramos en nuestro archivo compose.yaml, en este caso artemis como username y artemis como password.

Una vez dentro de la consola, podemos observar las versiones de Artemis y navegar por el mismo.

Se debe deshabilitar el Docker Compose de los proyectos Spring Boot, en el archivo de propiedades application.properties colocar:

spring.docker.compose.enabled=false

Para que no se levante Artemis cada que se ejecute el proyecto, sino que se levante una única vez cuando nosotros lo necesitemos.

Para poder enviar el evento desde el Sistema A al Sistema B, necesitamos un método que nos ayude con el envío. En este caso, hemos creado el método pushRequestPaymentOrder (puedes darle cualquier nombre). Primero, creamos nuestro DTO que contendrá la información que necesita el Sistema B. Para nuestro caso planteado, vamos a enviar un mensaje que indique que la cama está disponible y el ID de la cama correspondiente.

Utilizamos el atributo de clase que inyectamos de JmsTemplate, una clase de Spring que facilita el envío y recepción de mensajes a través de JMS. Utilizamos el método convertAndSend, que convierte el objeto DTO en un mensaje en formato JSON y lo envía a TopicDemo, que es el nombre de la cola a la que se envía el mensaje.

El método pushRequestPaymentOrder se llama desde la lógica de negocio en el sistema cuando se necesita encolar información. Por ejemplo, cuando se detecta que una cama está disponible, se invoca este método para enviar la información al Sistema B.

Para que podamos observar la información de ese mensaje en Artemis, debemos tener en nuestro producer lo siguiente:

El convertidor se utiliza tanto en el productor como en el consumidor para manejar la transformación del DTO. En el Sistema A, el convertidor transforma el DTO de un objeto Java a JSON antes de enviarlo a Artemis. Luego, cuando consumimos el evento en el Sistema B, el convertidor transforma el JSON almacenado en Artemis de vuelta a un objeto Java. Esto asegura que los datos se mantengan consistentes y fácilmente manejables a lo largo del proceso de comunicación entre sistemas.

Una vez confirmado que nuestro evento llegó con normalidad a Artemis y podemos observar su información, lo siguiente es levantar nuestro Sistema B, que en este caso sería nuestro consumidor. Debemos configurarlo para que esté a la escucha de los eventos que lleguen a una cola específica para poder leerlos y acceder a su información.

Eso lo realizamos de la siguiente manera:

Creamos nuestro método que tiene la etiqueta @JmsListener, que indica que está a la escucha de lo que llegue a esa dirección de cola, llamada TopicDemo, que es el nombre de la cola donde el producer envió el evento. Pero como se mencionó anteriormente, al momento de leer el evento, está leyendo un valor tipo JSON, por lo que queremos que lo transforme al objeto que necesitamos. Para ello, aquí también utilizamos el método jacksonJmsMessageConverter.

Como podemos ver en los logs, al levantar este microservicio se hará el consumo del mensaje que representa el evento. Ya tenemos que la cama está disponible, y lo siguiente sería actualizar en el Sistema B, en base de datos, que ahora la cama con el ID que acabamos de leer está disponible.

Resumen

En resumen, teníamos un Sistema A que contaba con una información, pero esa información necesitaba saberla el Sistema B. Para que el Sistema B se enterara, era necesario contar con una persona que analizara los cambios en el Sistema A y luego actualizara el Sistema B. Pero, ¿Qué ocurre si durante el almuerzo hay cambios o si la persona encargada de actualizar se distrae? No contaremos con la información actualizada en tiempo real.

Para eso, presentamos la solución planteada en este Blog: ahora no se requiere de una persona para hacer estas actualizaciones, sino que el Sistema A será un producer que envía eventos a Artemis cuando se desocupe alguna cama. Luego, el Sistema B será un consumer que esta a la escucha de esos eventos en Artemis para leerlos y actualizar automáticamente en sus registros que ahora la cama está disponible, asegurando así información actualizada en todo momento.

Esto fue un ejemplo con el uso de colas de tipo anycast. Próximamente se hará un blog con un escenario para colas de tipo multicast.

Si tienes alguna pregunta o comentario sobre este tema, no dudes en dejarlos abajo. Nos encantaría saber tu opinión y ayudarte con cualquier duda que puedas tener. ¡Gracias por leer!

Link de los proyectos:

https://github.com/softwareevolutivo/artemis

Referencia:

https://activemq.apache.org/components/artemis/documentation/2.0.0/address-model.html

Taller en Youtube – Apache ActiveMQ Artemis ▶ ¿Qué es y para qué sirve?

https://www.youtube.com/watch?v=Sn4TyzmtLxU

¿Quieres mejorar tus procesos de integración?

Descubre nuestros servicios y agenda una demo.

Ver Demo

The post Apache ActiveMQ Artemis appeared first on Software Evolutivo.

Esenciales para la Administración de Servidores Linux

Mateo Martínez — Sun, 30 Jun 2024 23:27:24 +0000

Los servidores son la columna vertebral de las redes informáticas, proporcionando servicios esenciales a otros dispositivos o clientes en la red. En el ámbito de los servidores, Linux se ha consolidado como una opción muy popular y robusta debido a su estabilidad, seguridad y flexibilidad. Estos servidores pueden manejar una amplia variedad de tareas, desde alojar sitios web y gestionar bases de datos hasta operar aplicaciones empresariales y servicios de correo electrónico.

Contenido:

Sistemas Operativos

Los sistemas operativos tipo Unix son conocidos por su robustez y amplia utilización en servidores y estaciones de trabajo. A continuación, se presentan algunos ejemplos destacados:

Linux es un sistema operativo de tipo Unix-like con una arquitectura y filosofía común basada en la idea de que “todo es un archivo”. Multiusuario y multitarea, permite la ejecución simultánea de múltiples tareas por diferentes usuarios.

Distribuciones de Linux:

Rolling Release: Ejemplos como Arch Linux y Manjaro. Estas distribuciones reciben actualizaciones continuas, lo que proporciona las últimas características y mejoras de software de manera constante.
Fixed Release: Ejemplos como Debian, Ubuntu y Fedora. Estas distribuciones lanzan versiones específicas con actualizaciones periódicas no solo de seguridad, sino también funcionales. Están diseñadas para diferentes públicos objetivos, como hackers, servidores, usuarios comunes, gamers, entre otros. Algunas distribuciones son más estables que otras, y cada una está optimizada para cierto tipo de trabajo.

Sistemas de archivos en Linux

Los sistemas de archivos son métodos estructurados para almacenar y organizar datos en dispositivos de almacenamiento, como discos duros y unidades flash. Cada sistema de archivos tiene características distintas que afectan su rendimiento, confiabilidad y capacidad de manejar diferentes tipos de datos.

A continuación, se presentan algunos sistemas de archivos en entornos Linux:

Btrfs: Diseñado para manejar grandes conjuntos de datos con alta redundancia y escalabilidad.
Ext4: Predeterminado en muchas distribuciones, conocido por su rendimiento y confiabilidad.
XFS: Adecuado para sistemas de archivos muy grandes.
NTFS, FAT32: Compatibles con Windows, utilizados comúnmente en unidades portátiles.

El Rol del Administrador de Servidores

Habilidades clave:

Control de accesos: Gestión de permisos y autenticación de usuarios.
Monitoreo del sistema: Uso de herramientas como top, htop, y ps para supervisar procesos y recursos.
Administración de recursos: Gestión eficiente de CPU, memoria, y almacenamiento.
Troubleshooting: Resolución de problemas mediante logs y herramientas de diagnóstico.
Instalación y mantenimiento de software: Uso de manejadores de paquetes como APT y DNF (antes YUM).
Creación de respaldos: Planificación y ejecución de respaldos regulares.
Documentación: Mantener registros detallados de configuraciones y cambios.

Roles específicos:

DevOps Engineer: Enfocado en la integración y entrega continua en el desarrollo de software.
Site Reliability Engineer: Garantiza la operación y confiabilidad de los sistemas.
Security Operations Engineer: Encargado de la seguridad a nivel de red y aplicaciones.
Network Engineer, Database Administrator, Cloud Engineer, etc.

Instalación de Servidores

Métodos de instalación:

Instalación directa: Descargar una imagen ISO y utilizarla para instalar el sistema operativo en el hardware.
Virtualización: Uso de software como VirtualBox o KVM para crear máquinas virtuales.
Hypervisor Tipo 1: Ejemplo: VMware ESXi, KVM, instalados directamente en el hardware.
Hypervisor Tipo 2: Ejemplo: VirtualBox, está instalado sobre un sistema operativo host.

Gestión de Usuarios y Permisos

Creación de usuarios:
useradd nombre_usuario
Asignación de contraseñas: passwd nombre_usuario
passwd nombre_usuario
Gestión de grupos:
groupadd nombre_grupo
usermod -aG nombre_grupo nombre_usuario

Administración de memoria y almacenamiento

Visualización de dispositivos de almacenamiento:
lsblk
Gestión de particiones:
fdisk /dev/sdX
parted /dev/sdX
Formateo de particiones, con los diferentes sistemas de archivos:
mkfs.ext4 /dev/sdX1
mkfs.xfs /dev/sdX1
mkfs.btrfs /dev/sdX1
mkfs.ntfs /dev/sdX1
mkfs.fat -F 32 /dev/sdX1
Montaje y desmontaje de sistemas de archivos:
mount /dev/sdX1 /mnt
umount /mnt
Visualización del espacio de almacenamiento:
df -h
du -sh /ruta
Gestión de volúmenes lógicos con LVM:
LVM (Logical Volume Manager) es una tecnología de administración de almacenamiento que permite gestionar volúmenes lógicos en Linux de manera flexible y dinámica. Con LVM, puedes crear, modificar y eliminar volúmenes lógicos sin necesidad de apagar el sistema ni mover datos.
Este es un tema muy amplio. Más adelante, profundizaremos sobre LVM en un blog dedicado, donde exploraremos cada comando y su aplicación práctica en escenarios de administración de almacenamiento en Linux.

Monitoreo y Mantenimiento del Sistema

Monitoreo de procesos y recursos:
Comando ps: Lista procesos en ejecución.
ps aux
Comando top: Monitorean el uso de recursos en tiempo real.
top
Comando lsof: Lista archivos abiertos y los procesos que los utilizan.
lsof -i :80 (ver procesos que usan el puerto 80)
Buscar ID de un proceso:
pidof nombre_proceso
El comando kill -15 PID se usa para enviar una señal de terminación al proceso especificado por su PID.
Se puede reemplazar el -15 por el número -9 que corresponde a la señal SIGKILL, que fuerza la terminación inmediata del proceso sin permitir que el proceso realice ninguna limpieza o cierre ordenado de recursos.

Gestión de demonios y servicios:
Uso de systemd:
Crear y gestionar demonios
systemctl start nombre_servicio
systemctl enable nombre_servicio
Para crear un nuevo servicio personalizado en systemd, debes crear un archivo de unidad en el directorio /etc/systemd/system/.
EjemploTe dejamos un ejemplo de un archivo de unidad para el servicio D-Bus (sistema de mensajería que permite que diferentes aplicaciones se comuniquen entre sí). Este archivo configura cómo se debe iniciar, detener y recargar el servicio D-Bus en el sistema, con sus dependencias y configuraciones de entorno.

Seguridad

Asegurar la seguridad en sistemas Linux implica implementar prácticas y herramientas adecuadas para proteger el sistema contra accesos no autorizados y vulnerabilidades. Aquí se presentan algunas medidas básicas y cómo utilizar herramientas específicas para configurar firewalls y gestionar actualizaciones:

Configuración de firewalls:
Uso de ufw (Ubuntu):
ufw allow 22/tcp
ufw enable
Uso de firewalld (CentOS, Fedora, Red Hat, Oracle Linux):
firewall-cmd --permanent --add-service=http
firewall-cmd --reload

Gestión de actualizaciones y parches:
apt update && apt upgrade (Debian/Ubuntu)
dnf update (Red Hat/CentOS)
Configuración de SSH: Asegurar el acceso remoto.
Cambios en el SSH: Editar /etc/ssh/sshd_config, se recomienda realizar los siguientes cambios:
Cambio del puerto SSH
Desactivar el acceso como root
Restringir usuarios específicos
Configurar autenticación de clave pública
Limitar protocolos y cifrados débiles
Configuración de timeout y límites de intentos

Automatización con cron jobs

Configurar y utilizar cron jobs de manera efectiva ayuda a automatizar procesos rutinarios y a mantener la consistencia y eficiencia del sistema operativo Linux. Es importante verificar regularmente los cron jobs existentes y asegurarse de que funcionen según lo esperado para evitar problemas y mantener la integridad del sistema.

Validación del estado del demonio de cron:
systemctl status cron
Creación de cron jobs:
Editar crontab:
crontab -e
Sintaxis de crontab: minuto hora día_mes mes día_semana comando
Ejemplo (Ejecutar backup.sh todos los días a las 2 AM):
0 2 * * * /path/to/backup.sh
Listar cron jobs:
crontab -l

Respaldo y Recuperación

Métodos de creación de respaldos:
Respaldo con tar:
tar -czf /ruta/destino/respaldo.tar.gz /ruta/origen
Respaldo incremental con rsync:
rsync -av --delete /ruta/origen /ruta/destino
Uso de herramientas de respaldo:
duplicity
borg
Estrategias de recuperación:
Restauración de archivos con tar:
tar -xzf respaldo.tar.gz -C /ruta/destino
Restauración de archivos con rsync:
rsync -av /ruta/destino/ /ruta/origen
Planificación de recuperación ante desastres:
Documentar procedimientos de recuperación.
Realizar pruebas regulares de restauración.

Administración de Paquetes

Manejadores de paquetes:
APT (Debian/Ubuntu):
Actualizar lista de paquetes: sudo apt update
Instalar un paquete: sudo apt install nombre_paquete
Eliminar un paquete: sudo apt remove nombre_paquete
YUM (Red Hat/CentOS):
Actualizar lista de paquetes: sudo yum update
Instalar un paquete: sudo yum install nombre_paquete
Eliminar un paquete: sudo yum remove nombre_paquete
DNF (Fedora/CentOS 8+):
Actualizar lista de paquetes: sudo dnf update
Instalar un paquete: sudo dnf install nombre_paquete
Eliminar un paquete: sudo dnf remove nombre_paquete

En conclusión, la administración de servidores Linux contempla una amplia gama de competencias y conocimientos, desde la instalación y configuración inicial hasta el monitoreo, mantenimiento y seguridad continuos.

Conoce nuestros servicios

Orquestación de Aplicaciones y Servicios

Nuestro enfoque en Kubernetes está diseñado para impulsar la escalabilidad de su infraestructura de TI.

The post Esenciales para la Administración de Servidores Linux appeared first on Software Evolutivo.

Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile?

Gissella Trujillo — Fri, 14 Jun 2024 23:50:43 +0000

¡Software Evolutivo es una empresa ágil! ¿O tal vez no? Durante el Team Building trimestral de Software Evolutivo, nos sumergimos en una experiencia única que combinó la diversión de LEGO con los principios ágiles de Scrum.

Cuando te introduces en el mundo de la agilidad, es habitual encontrar muchas fotografías o referencias de equipos que parecen divertirse “jugando” con Legos de colores. Siendo formadores, coaches o líderes de proyecto, enseguida nos planteamos si este “juego” también podría ser útil para nosotros.

En este blog, explicaremos cómo Lego Scrum nos permitió descubrir aspectos que podrían haber pasado desapercibidos durante la rutina del día a día y fortalecer la colaboración entre nuestros equipos Comercial y de Desarrollo. A través de las metodologías ágiles, buscamos transmitir y asentar mejor los conocimientos en nuestros equipos. Acompáñanos para conocer más sobre esta experiencia.

Índice:

1. El Desarrollo del Lego Scrum: Personas y proyectos

2. Planeación y Estimación

3. Sprint y Construcción

4. Revisión y Retrospectiva

5. Lecciones Aprendidas

6. Conclusiones

1. El Desarrollo del Lego Scrum: Personas y proyectos

Durante el evento, dividimos a nuestro equipo en grupos multidisciplinarios, es decir, mezclamos a personal del área comercial con el equipo de Desarrollo, e incluso incluimos a nuestro jefe Jorge. Una vez que todos estábamos bien integrados y mezclados, cada equipo recibió uno de estos desafíos:

💬 Cada proyecto Lego tenía sus propias historias de usuario y desafíos únicos, lo que les ofreció oportunidades para enfrentar situaciones distintas y demostrar toda su creatividad y habilidades.

Reglas de Lego Scrum (las mismas que Scrum, pero ajustadas):

– Los equipos deben usar solo los materiales proporcionados.
– Cada historia de usuario debe completarse antes de pasar a la siguiente.
– Se alienta la comunicación y colaboración dentro de los equipos.
– Cada Sprint debe resultar en un producto o mejora tangible que se pueda revisar.
– ¿Y el Product Owner? Compartimos uno para los dos grupos.
– ¿Y el Scrum Master? Cada equipo se encargó de nombrar uno.

2. Planeación y Estimación

Comenzamos con una sesión de planificación, donde cada equipo seleccionó el proyecto a construir y estimó el tiempo necesario para completarlo.

– El equipo “Transporte Espacial Lego” 🚀 utilizó la técnica de Planning Poker, para llegar a un consenso sobre la complejidad de cada historia de usuario. ¡Muy bien, estaban liderando con esa organización!

– Lamentablemente nuestro equipo “Ciudad Lego” 🏙️ no empezó con estimación (a algunos agilistas no les gusta estimar) y durante el primer sprint no lograron entregar todo el valor.

Desde la perspectiva de los participantes, se consideró la falta de realizar una incepción para poder entender mejor el producto como una limitación significativa en el proceso de desarrollo.

💬 ¡Recuerda! Siempre realiza una reunión de incepción y planificación, y estima tus historias para asegurar que todos los miembros del equipo tengan una comprensión clara de las tareas, prioricen adecuadamente y establezcan expectativas realistas sobre lo que se puede lograr en cada sprint. Esto también ayuda a identificar posibles obstáculos con anticipación y facilita la comunicación y la colaboración eficaz dentro del equipo.

3. Sprint y Construcción

Con el plan en su lugar, cada equipo se embarcó en su primer Sprint de construcción. Durante este tiempo, los grupos aplicaron los principios de Scrum, realizando reuniones “diarias” de stand-up para compartir el progreso, identificar obstáculos y ajustar el plan según fuera necesario.

¿Y el Product Owner? Bueno, indicamos que la comunicación con el PO se realizaría On Demand.

– El grupo “Transporte Espacial Lego” 🚀 utilizó muy bien sus tiempos y preguntaron todos los posibles obstáculos con anticipación, ¡Muy bien, seguían liderando con esa gestión de riesgos!
– Lamentablemente nuestro equipo “Ciudad Lego” 🏙️ no empezó con estimación y casi pero casi no lograron entregar todo el valor comprometido para el final del Sprint.

Imagen: Equipos en Sprint de Construcción

Imagen: Product Owner Disponible On Demand

Imagen: Equipo "Transporte Espacial Lego" en Acción

Imagen: Equipo "Ciudad Lego" en el Sprint Final

4. Revisión y Retrospectiva

Al final de 3 sprints, y con algunos sobresaltos mientras se apagaban los incendios, cada equipo presentó su proyecto terminado. Con cada revisión se pudo mejorar el producto y con cada retroalimentación mejoraron el proceso. Ambos equipos aprendieron de sus errores iniciales y al final de todo…

– “Transporte Espacial Lego” 🚀 y el equipo “Ciudad Lego” 🏙️ ¡culminaron exitosamente sus proyectos! 🏁

💬 Entonces, ¿Software Evolutivo es ágil? No lo sabremos sin antes tener una sesión de retroalimentación donde discutimos los resultados y compartimos feedback constructivo.

Aunque en los equipos más jerárquicos y tradicionales, el proceso de feedback puede verse con temor por el miedo a un ataque personal o una mala interpretación de las observaciones, en Software Evolutivo practicamos una comunicación asertiva para identificar: áreas de mejora, reconocer los logros del equipo y fomentar un ambiente de aprendizaje continuo.

5. Lecciones aprendidas

Aunque trabajamos juntos día a día, cuando se encendió el cronómetro, nos encontramos resolviendo problemas urgentes, y tal vez olvidamos algunas cosas importantes, la experiencia del Lego Scrum fue reveladora en varios aspectos:

– La colaboración entre los equipos comerciales y de desarrollo se fortaleció significativamente mientras trabajaban juntos para completar las historias de usuario. Cuanta más cohesión tengamos en el equipo, más resultados exponenciales obtenemos.
– Estima tus historias para tener una visión clara del esfuerzo necesario para completarlas.
– La negociación con el Product Owner es clave para entregar valor al cliente, ya que ayuda a establecer expectativas realistas y a alinear las prioridades con las necesidades del cliente.
– Si no estamos seguros de alcanzar a entregar todo lo que nos pide el cliente, podemos aplicar la regla de Pareto y entregar primero lo que es más importante, maximizando así el valor entregado en el tiempo disponible.
– Además, recuerda que en equipos pequeños el Scrum Master también puede formar parte del Scrum Development Team, lo que facilita una colaboración más estrecha y una mayor comprensión de los desafíos y oportunidades del proyecto.

💬 Recuerda: Al realizar una retrospectiva del evento Lego Scrum en general, lo que estamos buscando es la mejora de la ejecución del evento como tal y como eso nos ayuda a replicar y mejorar las actividades para obtener mejores resultados en el futuro. También en este caso, el facilitador y el Product Owner recibieron feedback por parte de los desarrolladores y el equipo comercial.

6. Conclusión

El Lego Scrum fue mucho más que una actividad de Team Building; fue una experiencia transformadora que fortaleció nuestra colaboración y mejoró nuestra capacidad para entregar valor al cliente. Si estás buscando una forma innovadora de fortalecer la colaboración en tu organización y maximizar la entrega de valor al cliente mediante enfoques ágiles, ¡considera el Lego Scrum como una opción! En nuestro próximo Blog se realizará la guía paso a paso para replicar Lego Scrum con tu equipo.

¿QUIERES SER ÁGIL?

¡Descubre cómo los frameworks agile maximizan la entrega de valor al cliente!

Contáctanos para obtener más información sobre cómo podemos ayudarte a implementar estas prácticas en tu organización.

Conoce más

💬 Nos encantaría conocer tu opinión sobre cómo las metodologías ágiles han impactado en tu equipo y en la entrega de valor al cliente. ¡Déjanos tus comentarios y comparte tus experiencias!

The post Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile? appeared first on Software Evolutivo.

DevOps: CI/CD en proyectos de desarrollo ágil

Mateo Martínez — Tue, 05 Mar 2024 13:42:28 +0000

En el desarrollo ágil de proyectos de software, la calidad del resultado, la velocidad de entrega del producto y la tolerancia a fallos son aspectos fundamentales para el éxito de los mismos. En este contexto, DevOps (Development – Operations) ha surgido como un enfoque integral que busca mejorar la colaboración entre los equipos de desarrollo y de operaciones. Su principal objetivo es permitir entregas ágiles de software sin perder la estabilidad de las operaciones de la organización.

Al implementar DevOps, se busca cumplir con los principios establecidos en el Manifiesto Ágil. Particularmente, el principio que enfatiza la entrega temprana y continua de software con valor para satisfacer al cliente se alinea perfectamente con la filosofía de DevOps de ofrecer cambios de manera rápida y confiable.

Dentro de DevOps, surge un término importante “pipelines” que se define como una serie de pasos automatizados que permiten la integración continua de software (CI) y la entrega o despliegue continuo del mismo (CD). Esto asegura que el código se incorpore, pruebe y despliegue de forma ininterrumpida, facilitando a los equipos de desarrollo la entrega ágil y fiable de cambios.

DevOps no se trata simplemente de adoptar nuevas herramientas tecnológicas y acelerar procesos, sino de un cambio cultural en el cual se busca promover la comunicación, la colaboración entre los equipos. Los procesos de DevOps no son estáticos, sino más bien orgánicos y evolutivos. Cada equipo de desarrollo tiene sus propias necesidades y desafíos únicos, por lo que no existe una receta mágica o un enfoque único que funcione para todos.

El resultado de aplicar DevOps en una organización será una mayor agilidad, resiliencia y capacidad de innovación.

Integración Continua (CI)

Este proceso tiene su origen con la metodología ágil Extreme Programming, la cual busca la entrega de software de alta calidad de manera rápida y continua. CI busca integrar el trabajo de cada uno de los desarrolladores constantemente. Cada integración debe estar respaldada por pruebas automatizadas que permitirán detectar errores para corregirlos lo antes posible.

El objetivo principal de CI es reducir el riesgo de errores y conflictos de integración que dificulten el progreso de un proyecto. Una de las razones para adoptar Integración Continua (CI) es evitar el temido “Big Bang Integration”, es decir, a la práctica de integrar grandes volúmenes de código de diferentes desarrolladores o equipos al final del ciclo de desarrollo, en lugar de integrarlo de manera continua a lo largo del proceso.

Trunk Based Development (TBD) es una estrategia de desarrollo de software que fomenta la integración continua al reducir la complejidad de fusionar cambios y alentar a los equipos a integrar su trabajo con frecuencia en la rama principal, por lo que el CI está estrechamente relacionado a TBD.

Entrega Continua (CD)

Cuando el código pasó por el CI, todos los miembros del equipo de desarrollo tendrán disponible los últimos cambios del código, lo cual es muy útil. Pero el desarrollo de software tiene que seguir su ciclo de vida, y precisamente esa es la ayuda que nos va a dar esta primera variante del CD, que se define como una serie de pasos automatizados a seguirse para el que el código se encuentre en un estado listo para desplegar, es decir, todos sus artefactos (.jar, .war, imágen de contenedor) listos para que alguien tome la decisión y los despliegue en un servidor.

Despliegue Continuo (CD)

Esta segunda variante de CD es el complemento de la primera, con la gran diferencia que en este caso, no solo se busca dejar los artefactos listos para que alguien los despliegue, sino que el despliegue en el servidor es automático.

Para lograr esto, es fundamental contar con las herramientas y/o infraestructura adecuadas que permitan realizar cambios sin afectar los servicios en producción, lo que se conoce como despliegue sin tiempo de inactividad (Zero-Downtime Deployment).

La idea detrás del Zero-Downtime Deployment es asegurar que los usuarios finales puedan continuar utilizando la aplicación sin experimentar ningún tiempo de inactividad, esto se logra mediante la implementación de estrategias y técnicas específicas que permiten desplegar las nuevas versiones de la aplicación, entre las estrategias más comunes se encuentran:

– Blue-green deployment: Despliega dos entornos de producción, donde uno está activo y otro se actualiza. Una vez probada la nueva versión, el tráfico se redirige al nuevo entorno.
– Canary deployment: Implementa una nueva versión inicialmente para un pequeño grupo de usuarios o servidores, permitiendo probarla antes de implementarla completamente.
– Rolling deployment: Despliega nuevas versiones de la aplicación en etapas o secuencialmente en diferentes partes de la infraestructura, manteniendo la aplicación en línea durante todo el proceso.

Volviendo a CI y CD, contamos con varias herramientas en el mercado que nos pueden ayudar a correr pipelines en nuestros proyectos: Jenkins, GitLab, Travis CI, CircleCI, Spinnaker, AWS CodeDeploy, Azure DevOps, entre otras.

Particularmente “GitLab” es una herramienta que para la empresa Software Evolutivo es una de las mejores no solo para DevOps, sino también para la gestión y planificación de proyectos de software. Seguramente, pronto estaremos profundizando sobre esta herramienta en otro blog que te dejaremos en las lecturas recomendadas.

¿Cómo diseñar un pipeline de CI/CD para un proyecto?

– Identifica el flujo de trabajo y el ciclo de vida completo de tu proyecto desde el momento cero hasta el momento en que este sale a un ambiente de producción o cualquiera que sea el ambiente objetivo.
– Determina los pasos que tu pipeline debería seguir para que el ciclo de vida que identificaste pueda ser automatizado.

En este punto deberías tenerlo todo sentado en papel, sigamos:

– Considera el estado y las características tecnológicas de tu proyecto.
– Investiga las herramientas que te permitirán implementar tu pipeline (valida que los recursos tecnológicos y económicos requeridos estén a tu alcance).
– Define las herramientas a utilizar.

Es momento de desarrollar, y para esto se sugiere lo siguiente:

– Incluye un paso a la vez a tu pipeline, pruébalo y valida que cada paso logre su objetivo.
– Empieza por implementar el CI desde lo más simple y fundamental para que puedas continuar (compilación, tests).
– Continúa por un CD de delivery. Lograr que tu aplicación genere y suba su artefacto en el repositorio que deseas, será un gran hito.
– Cuando tengas el artefacto en el repositorio deberás buscar la manera adecuada de que tu repositorio se conecte a tu servidor donde harás el despliegue.

Y por último, busca siempre la retroalimentación de tu equipo con el objetivo de mejora continua.

Desafíos al implementar DevOps

– Superar la resistencia a los cambios y fomentar una cultura de colaboración y responsabilidad compartida.
– Lograr la automatización completa de los procesos de desarrollo, pruebas y despliegue.
– Comunicar efectivamente los beneficios de DevOps y proporcionar capacitación y apoyo para la transición.
– Integrar prácticas de seguridad y cumplimiento sin comprometer la velocidad de entrega.
– Establecer una estrategia de monitoreo y retroalimentación continua para mejorar el rendimiento y la calidad del software.
– Diseñar una infraestructura y procesos que puedan crecer y adaptarse a medida que los proyectos y equipos evolucionan.

En conclusión, DevOps y CI/CD son dos conceptos sumamente relacionados que se basan en los principios de colaboración, automatización y entrega continua para impulsar la excelencia en el desarrollo y entrega de software en entornos ágiles.

Conoce nuestros servicios

Cultura DevOps

Impulsa la colaboración, agilidad y excelencia

Transforme su equipo en un motor de entrega continua y logre resultados sorprendentes.

Conoce más

The post DevOps: CI/CD en proyectos de desarrollo ágil appeared first on Software Evolutivo.

Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo?

Bryan Diaz — Thu, 23 Mar 2023 15:43:36 +0000

Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo?

En la actualidad, Quarkus representa la pila tecnológica de Java Nativa de Kubernetes (una colección de herramientas, marcos, lenguajes de programación y bibliotecas) diseñada para GraalVM y OpenJDK HotSpot (Máquinas Virtuales de Java).

Los desarrolladores pueden crear aplicaciones con el mismo Stack (Estructura de Datos) y microservicios más ligeros, rápidos y escalables gracias a las mejores bibliotecas y estándares de Java utilizados en su creación. Esta herramienta permite a los desarrolladores escribir código en Java/Kotlin mientras proporciona funciones de gestión de memoria y escalabilidad. Por lo tanto, “Quarkus” ayuda a los desarrolladores a trabajar de manera proactiva y eficiente si buscan una forma eficiente de desarrollar una determinada aplicación o microservicio Java, ya que es una de las mejores opciones disponibles.

Quarkus es más que un proyecto de código abierto presentado por Red Hat (Que conquistó a la comunidad Java y el primer release fué presentado en el 2019), por el hecho de que combina la productividad y la alegría del desarrollador (similar a Node.js), con la velocidad y rendimiento de GO, puesto que aquello le permite a los desarrolladores Java crear soluciones tecnológicas y arquitecturas modernas futuristas.

Turețchi (2022) muestra que Quarkus es una pila de Java nativa para la nube, basada en contenedores y diseñada para mejorar la productividad de los desarrolladores, reducir la huella de memoria de las aplicaciones y microservicios Java. Esta herramienta brinda a los desarrolladores una experiencia de tiempo de ejecución unificada y liviana mediante el uso de GraalVM, HotSpot y otros lenguajes como Kotlin, lo que permite el desarrollo eficiente de aplicaciones modernas nativas de la nube, con un enfoque en la escalabilidad y la gestión de la memoria. En consecuencia, Quarkus, como parte de un conjunto de herramientas tecnológicas, facilita la creación rápida de servicios modernos nativos en la nube.

Aplicaciones de Quarkus y por qué es actualmente el marco más popular

Quarkus es uno de los marcos de desarrollo nativos en la nube más populares en la industria tecnológica debido a sus características notables. Ofrece un tiempo de arranque rápido, una pequeña huella de memoria y una gestión escalable de la memoria. Por esta razón, el marco Quarkus con Kotlin es ampliamente utilizado en la industria. Su capacidad para reducir los tiempos de desarrollo también ayuda a mantener un alto rendimiento con servidores y redes de baja gama.

Cabe recalcar que, todos estos elementos claves, inciden en la creación de aplicaciones con un alto grado de rapidez/eficiencia, ya que se pueden implementar y escalar fácilmente en varias arquitecturas de la nube.

Con las capacidades de Quarkus, las organizaciones ahora pueden desarrollar servicios modernos con mayor velocidad y eficiencia que nunca, y usando Java o Kotlin proporciona una experiencia de desarrollo fluida con un modelo de programación reactivo moderno.

Arquitectura Empresarial Tradicional vs. Arquitectura Contenerizada.

En Quarkus, puedes desarrollar aplicaciones Java y ejecutarlas directamente en el sistema operativo subyacente sin necesidad de una máquina virtual de Java intermedia. Esto reduce significativamente el tiempo de ejecución, el consumo de memoria y otros recursos, lo que se traduce en una ejecución más eficiente y rápida de la aplicación. Quarkus lleva poco más de tres años en el mercado y ofrece una propuesta de valor para la creación de aplicaciones Java de última generación. Además, proporciona arquitecturas escalables para ejecutar aplicaciones Java y Serverless en la nube.

Arquitectura Tradicional

En la arquitectura tradicional, el primer nivel consta del hardware esencial para ejecutar el segundo nivel, que es el sistema operativo, como por ejemplo una Mac OS o Linux. En el tercer nivel, se requería la instalación de la popular Máquina Virtual de Java (JVM), mientras que en el último nivel, comúnmente utilizado en entornos empresariales, se instalaba un servidor de aplicaciones. Para ello, era necesario contar con una máquina virtual de Java capaz de comunicarse con el sistema operativo subyacente y traducir toda la aplicación al sistema operativo. Esta arquitectura era común en empresas, pero con el tiempo ha dejado de ser una buena práctica debido a sus implicaciones en el desarrollo, la agilidad y la complejidad en su mantenimiento. Actualmente, existen otras arquitecturas que ofrecen soluciones más ligeras y eficientes.

Figura 1: Arquitectura Java Tradicional

Arquitectura Contenerizadas.

En la actualidad, la arquitectura contenerizada se ha vuelto cada vez más popular gracias a la presencia de nuevas tecnologías en el mercado. Entre ellas, la tecnología Docker (Si te interesa, en un artículo anterior compartimos los Primeros pasos en Docker.) ha tomado un gran protagonismo en la mayoría de las empresas. Docker nos permite construir y empaquetar aplicaciones de forma portable, lo que significa que pueden ejecutarse en diferentes sistemas operativos y entornos sin necesidad de compilar la aplicación para un sistema operativo en particular. En esencia, Docker realiza una tarea similar a la que la máquina virtual de Java realizaba, pero aplicable a cualquier tipo de aplicación.

En la arquitectura contenerizada, el primer nivel es el hardware, seguido por el sistema operativo, que puede ser cualquiera que tenga la capacidad de ejecutar contenedores. En el siguiente nivel, se debe instalar Docker para poder colocar nuestras aplicaciones en contenedores y ejecutarlas. Gracias a esta arquitectura, podemos tener diferentes versiones de aplicaciones sin que esto suponga un problema, ya que cada una se ejecuta en un contenedor independiente. Esto nos brinda una ventaja significativa en términos de mantenimiento y evita conflictos entre versiones de aplicativos.

Figura 2: Arquitectura Contenerizadas

Quarkus representa una mejora significativa en la arquitectura contenerizada al eliminar la necesidad de tener una JVM en cada contenedor para la ejecución de nuestras aplicaciones. Esto permite un despliegue más rápido y una menor utilización de recursos, lo que se traduce en una mayor eficiencia y ahorro de costos.

Superpoderes de Quarkus: Gestión de Memoria y Escalabilidad

Los desarrolladores pueden utilizar Quarkus, un marco Java que les brinda las herramientas necesarias para administrar la memoria de manera efectiva y escalar sus aplicaciones. Quarkus cuenta con una variedad de herramientas de optimización de memoria, como administración de memoria dinámica, recolección de elementos no utilizados y dimensionamiento de almacenamiento dinámico. Además, Quarkus proporciona soluciones de escalabilidad para aplicaciones que necesitan escalar rápidamente hacia arriba o hacia abajo, a través de herramientas de escalabilidad como orquestación de contenedores, escalado automático y equilibrio de carga. Estas características permiten a los desarrolladores asegurarse de que sus aplicaciones puedan manejar grandes cantidades de tráfico sin problemas de rendimiento. Con la administración de memoria dinámica de Quarkus, los desarrolladores pueden realizar cambios en sus aplicaciones sobre la marcha sin necesidad de reiniciar la aplicación, lo que les permite probar rápidamente los cambios y optimizar el uso de la memoria. Es importante destacar que la variedad de herramientas de escalabilidad permite la escalabilidad horizontal, lo que permite a las aplicaciones manejar fácilmente una mayor carga de usuarios.

Características y ventajas de Quarkus sobre los marcos tradicionales de Java

Quarkus es un marco independiente del tiempo de ejecución diseñado para proporcionar una forma eficiente y rentable de desarrollar aplicaciones nativas de la nube. Ofrece una gestión inteligente de la memoria y herramientas que facilitan a los desarrolladores la creación de aplicaciones con menos recursos y tiempo de arranque más rápidos que los marcos de Java tradicionales, lo que permite que las aplicaciones sean escalables de forma rápida y eficiente. Además, Quarkus tiene ventajas sobre los marcos de Java tradicionales en cuanto a la gestión inteligente de la memoria, la escalabilidad y el rendimiento mejorado, y brinda a los desarrolladores la capacidad de escribir código en cualquier idioma que elijan e implementarlo como una aplicación en contenedores, lo que lo convierte en una excelente opción para aquellos que buscan aprovechar los beneficios de la computación en la nube manteniendo el control sobre sus aplicaciones.

Desventajas de Quarkus sobre los marcos tradicionales de Java

Aunque Quarkus tiene muchas ventajas para el desarrollo de aplicaciones en la nube, también tiene algunas desventajas a tener en cuenta. Una de ellas es que, al ser un marco relativamente nuevo, puede haber una curva de aprendizaje para los desarrolladores que no estén familiarizados con él. Además, debido a que Quarkus utiliza tecnologías de vanguardia, puede haber algunos problemas de compatibilidad con bibliotecas y frameworks más antiguos. Por último, aunque Quarkus es altamente escalable, puede ser menos adecuado para aplicaciones que no necesiten escalabilidad horizontal, ya que esta característica puede agregar complejidad y costo al desarrollo y la implementación.

El tamaño de la imagen nativa de Quarkus puede ser una desventaja para algunos usuarios, por el hecho de que puede resultar más grande que el tamaño de la imagen de una aplicación Java tradicional. Esto se debe a que la imagen nativa incluye todo lo necesario para que la aplicación se ejecute sin depender de una máquina virtual, lo que aumenta su tamaño. Sin embargo, es importante tener en cuenta que esta desventaja puede ser mitigada mediante la optimización de la imagen y la eliminación de componentes innecesarios. Además, el tamaño de la imagen puede ser compensado por las ventajas en cuanto a rendimiento y eficiencia que ofrece Quarkus.

Conclusiones

En resumen, Quarkus es un nuevo marco de desarrollo de Java de alto rendimiento que permite a los desarrolladores crear aplicaciones empresariales de manera fácil y rápida. Con sus características únicas como la eficiencia del tiempo de ejecución, el soporte de Java y la integración con tecnologías empresariales, Quarkus es una opción atractiva para los desarrolladores que buscan crear aplicaciones rápidas y escalables. Por esa razón, vale la pena explorar Quarkus como una opción para su próximo plan de desarrollo de aplicaciones.

Referencias

https://quarkus.io/
Gascó Compte, A. (2022). Sistema de ayuda a las pruebas de fragilidad. Obtenido de: https://repositori.uji.es/xmlui/handle/10234/200566
Turețchi, G., & Cerbu, O. (2022). Aplicarea frameworkului Quarkus în cadrul arhitecturii bazate pe microservicii. In Conferinţa tehnico-ştiinţifică a studenţilor, masteranzilor şi doctoranzilor (Vol. 1, pp. 56-59).

The post Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo? appeared first on Software Evolutivo.

¿Qué opciones tiene mi empresa ante los cambios tecnológicos y del mercado?

Gissella Trujillo — Wed, 11 Jan 2023 16:25:55 +0000

El éxito de las empresas es directamente proporcional a su habilidad de adoptar modelos comerciales basados en software, como parte de su estrategia y su interacción con el cliente.Fig.1

En diferentes industrias, las empresas posicionadas se ven amenazadas por empresas basadas en software; por lo que se ven forzadas a adaptarse a nuevos esquemas comerciales.

¿Qué pueden hacer las empresas para hacer frente a la realidad cambiante del mercado actual?

Integrar la tecnología en todas las áreas de la empresa, cambiando la manera en que opera y entrega valor a los clientes, esto implica:

Cambios culturales.
Procesos Ágiles.
Arquitectura de la siguiente generación.

El proceso de transformación para cada empresa es diferente, por lo que depende de sus necesidades específicas. Por ejemplo:

¿Cómo responder ante la amenaza de un nuevo competidor?

Ante la amenaza de un nuevo competidor disruptivo, con un nuevo software avanzado, la mejor opción para una empresa consolidada es lograr primero que sus operaciones actuales sean más eficientes.

La Estrategia de respuesta ante un mercado cambiante y nuevos competidores, abarca más que solo tecnología, implica preparar a sus personas y procesos; para las empresas consolidadas, un socio con experiencia en adopción de nuevas tecnologías puede agregar valor y ayudar en su proceso de mejora continua.

¿Por qué es fundamental contar con una estrategia tecnológica?

Históricamente, las empresas han cambiado constantemente, a la par de los hábitos de consumo, y con el avance de la tecnología, este proceso de mejora continua no se ha detenido desde el inicio del comercio, la diferencia con nuestra realidad actual es la velocidad con la que las cosas cambian y la tecnología avanza.

Este proceso de mejora continua, que no se detiene y acelera cada día es la razón principal para cuestionar nuestra estrategia tecnológica o la carencia de ella. Otras razones importantes incluyen:

Adopción y uso de la tecnología en todas las industrias: las empresas deben cambiar para adaptarse a los avances tecnológicos y su uso que aumenta rápidamente.
Competidores que son más veloces y eficientes con sus recursos, entienden mejor a sus clientes y dan un valor diferenciado: Las empresas deben actualizarse y realizar cambios iterativos y continuos para seguir siendo competitivas.
El comportamiento, las demandas y las expectativas cada vez más altas de los clientes: Las empresas que no logran aprovechar las tecnologías digitales corren el riesgo de perder cuota del mercado.
Rápida innovación e invención: La transformación digital está cambiando la manera en que usamos la tecnología y creando nuevos competidores y nuevos modelos empresariales en todas las industrias.

¿Qué pueden hacer las empresas ante el cambio constante?

Como se ha mencionado anteriormente, el proceso de adopción de nuevas tecnologías es diferente para cada empresa, dependiendo en la etapa que se encuentre, se pueden diferenciar 3 grandes enfoques para arrancar la estrategia y poner en marcha el camino de transformación:

Surgir: Adoptar una tecnología nueva para la transformación.
Transformar: Agilizar la transformación para convertirse en líder.
Liderar: Innovar constantemente para seguir siendo un líder.

Podemos concluir entonces que para cubrir las necesidades del mercado cambiante, haciendo frente a las tecnologías disruptivas de la competencia y a las cada vez más altas expectativas de los clientes en un mundo interconectado, es importante colocar en el mercado nuevos productos y servicios antes que nuestra competencia lo haga y eso implica que la organización pueda responder más rápido y que las áreas internas como TI tengan la capacidad de apoyar a las áreas de negocio con las nuevas iniciativas.con escalabilidad y disponibilidad, lo cual implica crecimiento.

Anteriormente, un sistema central Mainframe gestiona todas las cargas de trabajo asociadas con las aplicaciones y cuando la carga de trabajo aumentaba, la solución habitual era escalar verticalmente con más servidores (hardware). Sin embargo, por ser más demandantes, las cargas de trabajo en la actualidad se escalan horizontalmente.

¿Qué es la escalabilidad horizontal?

La escalabilidad es la capacidad del software para adaptarse a las necesidades de rendimiento a medida que el número de usuarios crece, las transacciones aumentan y por ende la base de datos y otros componentes de las aplicaciones empiezan a sufrir degradamiento del rendimiento por las cargas crecientes.

Cloud Computing habilita el escalamiento horizontal de los servicios TI. En lugar de adquirir y mantener hardware y software de manera local, los usuarios pueden acceder a aplicaciones y recursos informáticos a través de Internet.

El Cloud Computing, sin embargo, no es algo nuevo.

La mayoría de las empresas utilizan al menos un servicio comercial proporcionado a través de Internet. En total, las empresas gastaron casi $230 mil millones a nivel mundial en 2019 en servicios de la nube, según Gartner, una firma de investigación, y podrían gastar hasta $355 mil millones en 2023.

Existen tres proveedores líderes del mercado: Amazon Web Services (AWS), Microsoft Azure y Google Cloud Platform (GCP).

¿Por qué las empresas buscan la nube?

Para competir en el mercado con una estrategia tecnológica se requiere:

Entregas de aplicaciones a mayor velocidad
Reducción de costos
Escalabilidad adaptable

¿Qué es software nativo en la nube?

El desarrollo nativo de la nube (Cloud Native Development) es un enfoque para el desarrollo de aplicaciones en la nube que se centra en aprovechar al máximo las características y capacidades de la nube.

En lugar de intentar adaptar aplicaciones existentes a la nube, el desarrollo nativo de la nube implica diseñar aplicaciones desde cero para ejecutarse en la nube.

Beneficios del desarrollo de software nativo en la nube

El software nativo en la nube permite crear, desplegar y administrar aplicaciones modernas en entornos de computación en la nube. Las empresas modernas buscan crear aplicaciones altamente escalables, flexibles y resistentes que se puedan actualizar de manera rápida para satisfacer las necesidades de los clientes, utilizando herramientas y técnicas que promueven el desarrollo de aplicaciones en la infraestructura en la nube.

Estas tecnologías nativas en la nube permiten hacer cambios frecuentes y rápidos en las aplicaciones sin interrumpir el servicio, lo que proporciona a los usuarios una ventaja competitiva y de innovación.

Entre los principales beneficios tenemos:

– Más desarrollo de aplicaciones.
– Mayor velocidad de entrega.
– Más flexibilidad de implementación.
– Mayor calidad en el software.
– Menores riesgos de implementación.
– Acceso desde cualquier lugar
– Escalabilidad

Conclusiones

Para competir en la realidad actual, las empresas necesitan responder con un nuevo enfoque que brinda mayor velocidad y eficiencia a su modelo operativo.

El camino hacia una transformación guiada por una estrategia tecnológica, entonces, no es el mismo para cada empresa, pero ante la versatilidad de las nuevas tecnologías disruptivas que ganan su cuota mercado, la primera opción para empresas consolidadas es modernizar sus aplicaciones para obtener un nuevo valor de las inversiones en TI existentes.

Una solución de desarrollo de software nativo en la nube permitirá ir más allá, permitiendo sacar partido de una variedad de herramientas, frameworks, arquitecturas, etc, para:

Aprovechar al máximo los recursos con tecnologías innovadoras como Contenedores y Microservicios
Mejorar sus operaciones habilitando prácticas pensadas para la realidad del mercado cambiante (Agile, DevOps, CI/CD)

Estos términos que no se mencionan previamente en el blog (Contenedores, Microservicios, DevOps, CI/CD), se estarán abordando más adelante. Este es el primero de una serie de blogs sobre estrategia tecnológica, lo invitamos a leer la siguiente entrega para profundizar en el Desarrollo nativo en la nube. Si le gustaría saber más sobre un tema en particular o tiene una pregunta, lo atenderemos en la sección de comentarios.

Enlaces:

https://www.redhat.com/es/engage/devops-forrester-openinnovation-s-201902250310

https://www.gartner.com/en/doc/8-steps-playbook-to-optimize-software-and-saas-negotiations-2022

https://aws.amazon.com/es/what-is/cloud-native/#:~:text=El%20desarrollo%20nativo%20en%20la,para%20crear%20aplicaciones%20escalables%20r%C3%A1pidamente.

https://www.stormforge.io/wp-content/uploads/2020/11/451_cloud-container-kubernetes-economics-wp.pdf

https://www.economist.com/business/2020/03/14/how-corporate-it-is-entering-the-multi-cloud

The post ¿Qué opciones tiene mi empresa ante los cambios tecnológicos y del mercado? appeared first on Software Evolutivo.

Scrum: El rol del Product Owner

Mateo Martínez — Thu, 15 Dec 2022 21:55:04 +0000

El marco de trabajo “Scrum” dentro del desarrollo de software, sugiere un conjunto de buenas prácticas aplicadas al desarrollo de productos de software, estas permiten mejorar el trabajo en equipo y busca obtener los mejores resultados. Para lograr su objetivo, Scrum sugiere que cada equipo cuente con 3 roles principales: el Product Owner, el Scrum Master y el Equipo de Desarrollo.

Es muy común confundir las tareas y objetivos que cada rol cumple sobre todo con el Product Owner, quien ocupa un lugar menos técnico en el equipo, por lo tanto, el objetivo de este blog será dejar en claro cuáles son las responsabilidades, retos y características que un Product Owner tiene.

Figura 1. El Product Owner y sus responsabilidades.

El objetivo principal del Product Owner (PO) es optimizar el valor del producto final entregado por todo el equipo de desarrollo hacia el cliente.

Para poder cumplir con este objetivo el PO es responsable de:

– Desarrollar y comunicar de manera clara a todo el equipo sobre los objetivos del producto, para saber hacia dónde se encamina el trabajo a realizarse.
– Comunicar explícitamente sobre los elementos de trabajo, es decir, entrar en detalles sobre las especificaciones de lo que se va a desarrollar a través de cada entregable (conocido también como sprint).
– Mantener una comunicación con el Scrum Master y el Equipo de Desarrollo siempre transparente y comprensiva, además, se sugiere que sea hablada y no escrita para facilitar el feedback (retroalimentación) y la resolución de dudas.

Retos a los que el Product Owner se enfrenta

En cuanto a la cultura ágil se refiere, el PO deberá mantener la orientación a las entregas, las prácticas que se adaptan al equipo en base a la experiencias y evidencias del equipo.

En cuanto a la cultura empresarial, el PO se enfrenta a desafíos relacionados a los resultados del producto, principios y prácticas, y a la retroalimentación en cada entrega del producto.

Enfrentarse a estos retos no es algo sencillo, para que un miembro del equipo califique para desempeñarse como Product Owner deberá:

– Tener conocimiento del negocio.
– Tener conocimiento del producto para identificar los puntos fuertes y débiles de este para mejorarlos y tener un dominio sobre todas las aristas.
– Tener conocimiento del contexto en el que se encuentra el usuario final.
– Desarrollar un correcto análisis del negocio, es decir, entender los problemas y estar en la capacidad de ofrecer soluciones en base al cliente, el equipo y la organización.

Además, las habilidades blandas que se identifican en un PO son:

– Influencia positiva en el equipo.
– Comunicación y buen diálogo durante las reuniones. Permite siempre llegar a soluciones y conclusiones productivas.
– Negociación constante tanto con el cliente como con el equipo.
– Abstracción y categorización de toda la cantidad de información que recibe para poder comunicar y llegar con el mensaje al resto del equipo.

El trabajo del Product Owner

Hemos revisado las características de un Product Owner de una manera un tanto general, ahora en la práctica, en el día a día quien ocupe este rol deberá realizar actividades como las siguientes:

– Determinar los objetivos de un producto.
– Definir y crear el backlog mediante las características del producto.
– Gestionar y priorizar el backlog creado.
– Crear las historias de usuario. (Para más info “Mejores Historias de Usuario para Scrum”)
– Para garantizar el desarrollo adecuado del producto debe estar presente en:
– Reuniones de refinamiento de los pendientes (semanales).
– Reuniones para revisar los sprints.

Interacción con el resto del equipo

Figura 2. Interacción del Product Owner.

Al ser el Product Owner la voz del cliente y el negociador principal entre él y el equipo de desarrollo, el PO interactúa constantemente con el resto del equipo en situaciones como:

– Para el desarrollo del backlog, se tiene en cuenta la opinión y perspectiva de todo el equipo.
– En la planeación del sprint, se realiza la estimación en base a un consenso entre todos quienes colaboran en el proyecto.
– Cuando surgen impedimentos o bloqueos para el avance del proyecto, el PO tiene la responsabilidad de interactuar con el equipo para informar y establecer qué tan prioritaria es la entrega del elemento que está teniendo el bloqueo en cuestión o cuánto valor puede entregar al cliente este elemento.
– En la revisión del sprint, el PO tiene que reunir al equipo y a los involucrados relevantes para que se realice una inspección de lo que se está entregando.
– El PO participa en la retrospectiva del sprint y durante ese período debe tratar de participar en todas las dailys.

Importante

Establezcamos un par de roles con los que más a menudo solemos confundir al Product Owner:

– El Business Analyst identifica y define soluciones para maximizar el valor que se entrega en un proyecto, se lo confunde con el PO pero en la práctica el PO suele tener un Business Analyst para ayudarlo en la toma de decisiones, sin embargo la diferencia radica en que solo el PO puede priorizar en base a la información de la que dispone.
– El Product Manager es quien crea las estrategias del producto pero a un nivel más global, en este caso es el Product Manager quien puede tener a varios Product Owner trabajando en diferentes partes de un proyecto.

Conclusiones

Al Product Owner se lo puede definir de manera sencilla como ”la voz del usuario final en el equipo de desarrollo”, cumple con un rol estándar dentro del marco de Scrum y su trabajo se enfoca principalmente en realizar la entrega de un producto de calidad que permita satisfacer tanto a cliente como a usuario final después de haber seguido un largo pero claro y organizado camino junto al resto de su equipo de trabajo.

Complementos

Te invito a revisar mucha más información que puede ayudarte a desarrollar tus conocimientos en agilidad.

– Mejores Historias de Usuario para Scrum
https://softwareevolutivo.com.ec/mejores-historias-de-usuario-para-scrum/

– ¿La Agilidad puede ayudar a mi organización?
https://softwareevolutivo.com.ec/la-agilidad-puede-ayudar-a-mi-organizacion/

Fuentes

El presente blog, fue desarrollado en base a los conocimientos adquiridos en:

– “Curso de Fundamentos de Product Owner” de Platzi:
https://platzi.com/cursos/product-owner/

– Scrum Guide:

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf

The post Scrum: El rol del Product Owner appeared first on Software Evolutivo.

Software Evolutivo

Colaboración en equipos tecnológicos: Integrando el Corazón de la Agilidad

La Suma es Mayor que la Suma de las Partes

La colaboración multiplica las capacidades del equipo

Diversidad de pensamiento

Ampliación de visión

Mayor Eficiencia

Agilidad: Un Corazón Colaborativo

Preguntas para mejorar la colaboración

Liderazgo en todos los niveles: ¿Quién Debería Impulsar la Colaboración en el Equipo?

1. Líderes de Equipo y Gerentes

2. Facilitadores de Reuniones y Coaches Ágiles

3. Miembros del Equipo

4. Consultores Externos

¿Cómo fomentamos la colaboración en Software Evolutivo?

Conclusiones

¿Buscas mayor agilidad y eficiencia?

Automatiza y moderniza tus sistemas con nuestras soluciones en automatización y modernización de aplicaciones.

GitHub Flow, una forma ligera y eficaz para gestionar tu Software

¿Qué es GitHub Flow?

El proceso de GitHub Flow

Casos de uso sugeridos

Beneficios de adoptar GitHub Flow

Consideraciones y desafíos

Conclusiones

Kubernetes: Arquitectura y Recursos Principales

Contenidos

¿Qué es Kubernetes?

5 Beneficios Principales de Kubernetes

Arquitectura de Kubernetes

Control Plane

Cluster

Nodo

Componentes Complementarios

Recursos Principales

Pod

Service

Deployment

Conclusiones

Referencias:

Conoce Nuestros Servicios

Escalabilidad sin Límites: Consultoría de Kubernetes para su Empresa

Apache ActiveMQ Artemis

Artemis

Arquitectura

Spring Boot

Escenario a Resolver

Resumen

¿Quieres mejorar tus procesos de integración?

Esenciales para la Administración de Servidores Linux

Sistemas Operativos

Sistemas de archivos en Linux

El Rol del Administrador de Servidores

Instalación de Servidores

Gestión de Usuarios y Permisos

Administración de memoria y almacenamiento

Monitoreo y Mantenimiento del Sistema

Seguridad

Automatización con cron jobs

Respaldo y Recuperación

Administración de Paquetes

Conoce nuestros servicios

Orquestación de Aplicaciones y Servicios

Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile?

1. El Desarrollo del Lego Scrum: Personas y proyectos

2. Planeación y Estimación

3. Sprint y Construcción

4. Revisión y Retrospectiva

5. Lecciones aprendidas

6. Conclusión

¿QUIERES SER ÁGIL?

¡Descubre cómo los frameworks agile maximizan la entrega de valor al cliente!

DevOps: CI/CD en proyectos de desarrollo ágil

Integración Continua (CI)

Entrega Continua (CD)

Despliegue Continuo (CD)

¿Cómo diseñar un pipeline de CI/CD para un proyecto?

Desafíos al implementar DevOps

Conoce nuestros servicios

Cultura DevOps