Fernando Paz, Author at 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.

Arquitectura de Microservicios: qué es, ventajas y desventajas

Fernando Paz — Thu, 21 Jul 2022 19:57:23 +0000

Existen dos grandes paradigmas a la hora de diseñar Software: la Arquitectura Monolítica y la Arquitectura de Microservicios. En este artículo vamos a revisar qué es la Arquitectura de Microservicios, y cuáles son sus ventajas y desventajas.

Qué es la Arquitectura de Microservicios
Características de los Microservicios
Ventajas de la Arquitectura de Microservicios
Desventajas de la Arquitectura de Microservicios

Qué es la Arquitectura de Microservicios

Antes de hablar de la Arquitectura de Microservicios, vamos a partir identificando a su predecesor que es la Arquitectura Monolítica.

La Arquitectura Monolítica, es un enfoque en donde todos los conceptos y dominios de negocio de un producto de Software se implementan como componentes completamente acoplados, por lo que, tanto las entradas como las salidas de cada componente tienen su razón y especificación en contexto de un único producto de Software que es indivisible.

Iniciando desde la interfaz del usuario (en algunos casos), pasando por una o varias capas de lógica de negocio, la capa de persistencia, y, hasta la base de datos, el producto de Software se construía como un solo concepto, y a menudo se ejecuta como un solo binario o unidad entregable (JAR, WAR, EAR, Folder, etc.).

La Arquitectura de Microservicios es un enfoque para el desarrollo de un producto de Software, en donde cada concepto específico de negocio es construido en una unidad pequeña de código accesible a través de una API liviana y bien definida.

El TODO del producto de Software entonces, constituye la ejecución sincronizada de un conjunto de estos servicios, cada uno con su propia e independiente definición, para el proceso de una transacción padre disparada desde una interfaz de usuario o sistema.

Características de los Microservicios

Aunque parece no existir una especificación única para crear Microservicios, y más depende del caso de negocio y/o planificación; generalmente se sugiere que deban cumplir las siguientes características:

Interfaz Única

Cada Microservicio debe proveer una interfaz ligera y bien definida para consumo, que aísle todos los detalles técnicos, estructura de datos y datos de la capacidad de negocio que maneja, a sus clientes.

Especializado

Cada servicio es diseñado con un conjunto limitado de capacidades que resuelvan uno y solo un problema de negocio, y que incluye su propia estructura de datos persistentes.

Autónomo

Cada servicio puede ser desarrollado, desplegado, operado y escalado sin afectar o depender de otros servicios o sistemas, o, de otros datos fuera de su especialización.

Claramente una Arquitectura de Microservicios es una aplicación del paradigma de Cómputo Distribuido, lo que representa muchas ventajas para el negocio pero también muchos retos en la operación y mantenimiento.

Ventajas de la Arquitectura de Microservicios

Agilidad Este paradigma de desarrollo permite crear equipos pequeños e independientes que se apropian de la especialización de los servicios, acelerando el tiempo de desarrollo, facilitando la auto-organización e incluso el soporte post-producción.	Escalamiento Esta división de funcionalidad hace más fácil la medición y observabilidad de la implementación, permitiendo planificar mejor la disponibilidad y escalabilidad.
Simplificación de Despliegue Una unidad pequeña de implementación, permite ciclos de CI/CD más simples, reduciendo el tiempo de despliegue de la misma y el rollback en caso de fallos. Esto agiliza las operaciones y al mismo tiempo reduce el riesgo de innovación con nuevas características.	Resiliencia A diferencia de una Arquitectura Monolítica, un fallo en una Arquitectura de Microservicios compete a un componente específico, lo que hace más fácil su recuperación y no desestabiliza el producto de Software por completo, sino la capacidad de negocio concreta que le compete.
Independencia Tecnológica El uso de una sola tecnología no es una restricción en la Arquitectura de Microservicios, dado que su interfaz de consumo abstrae los detalles de implementación y habilita a la selección de la mejor herramienta de acuerdo a la especialización del servicio.	Reutilización de Código Evidentemente una vez construido un servicio que atiende una capacidad de negocio, el mismo puede ser utilizado por otros productos de Software de forma que su construcción aproveche la funcionalidad ya implementada.

Desventajas de la Arquitectura de Microservicios

Más que desventajas, se puede hablar de retos a la hora de adoptar una Arquitectura de Microservicios, y entre los principales tenemos:

Versionamiento Un Microservicio, al ser autónomo, suele evolucionar independientemente del producto o de los productos de Software a los cuales provee funcionalidad. Esto significa que su interfaz API y la validación del esquema de datos varía continuamente, sin embargo para no afectar la estabilidad de sus clientes antiguos debe mantener un versionamiento de los mismos y obviamente mantenerlos operando. Esto tanto para áreas de operaciones y de desarrollo implica una tarea adicional en su implementación.	Pruebas Si bien un Microservicio por sí solo es más simple de probar, su orquestación con otros servicios (test de integración) y las pruebas integrales (pruebas end to end) son mucho más complejas. Esto resulta a menudo en una cobertura incompleta de escenarios de pruebas y un esfuerzo redoblado en su desarrollo.
Rollback y Sistemas Distribuidos El reto más grande, para mí, es el diseño de sistemas distribuidos, puesto que hay que definir qué sucede en caso de fallos esperados o inesperados en la orquestación de los servicios, analizar patrones de resiliencia y recuperación de transacciones, mirar la atomicidad de operaciones y consistencia de datos, entre otros. Claro está, que para esto nos podemos apoyar en conceptos como “Patrones de Integración Empresarial”, “Mallas de servicios” o similares, pero sin duda estas decisiones son extremadamente relevantes no solo para el desarrollo sino para el soporte post-producción.	Coordinación de equipos Si bien, al desarrollar un Microservicio, paradigmas como la Agilidad y un equipo responsable puede representar una gran ventaja para generar valor e innovación constante en su implementación, al tener decenas o centenas de microservicios con decenas o centenas de equipos responsables, la cooperación y comunicación de estos equipos es un reto, pues el TODO de un Sistema y su evolución se puede poner en riesgo cuando se carece de una acción combinada.
Sobrecarga de infraestructura En la Arquitectura Monolítica un operador a menudo mira un servidor y un Software correspondiente con su archivo log; en un paradigma de Arquitectura de Microservicios puede enfrentarse a escenarios donde un Software tiene 100 servicios y centenas de servidores, con uno o varios balanceadores, muchos archivos de logs y decenas de formatos. Aunque hoy existen esquemas de contenerización como Docker y Kubernetes, la administración sigue siendo un reto y se necesita varias tecnologías complementarias para enfrentarlo.	Tiempo y esfuerzo 1x A este punto del artículo ya hemos descrito muchas actividades adicionales en el diseño, implementación, operación y mantenimiento de la Arquitectura de Microservicios, por su característica de Sistema Distribuido. Por este motivo es importante sopesar el beneficio de este paradigma en contraste con el caso de negocio y los resultados esperados a corto, medio y largo plazo; del mismo modo debemos pensar en el soporte post implementación, en relación al equipo, sus capacidades.
Despliegue ¡Si!, desplegar un solo microservicio es simple, sin embargo desplegar cientos de ellos de forma manual se vuelve imposible. El orden de despliegue, los cambios de base de datos que implica, la estratégia de entrega (Blue-Green, Canary, etc.), entre otros, son cosas a planificar y deben estar automatizadas, con prácticas DevOps entre otras como Integración Continua (CI) y entrega Continua (CD).	Logs y Monitoreo De la misma manera, un producto de Software Monolítico deja un solo log de operación y se puede medir su performance centralizadamente. En una Arquitectura de Microservicios, vamos a tener tantos logs como servicios implementados para el producto de Software y además si estos son redundantes, tendremos logs multiplicados por cada servicio. Debemos planificar una estratégia para rastrear errores, identificar la salud de cada servicio y del sistema como tal.
Debug Encontrar un problema no siempre va a ser posible revisando logs (que al ser tantos ya nos agrega una complejidad), a veces vamos a tener que depurar la implementación y esto en un sistema distribuido no va a ser factible, por lo que se requerirá de otras técnicas y patrones que permitan repetir ciertas ciclos de transacciones.

Pensamientos Finales

A este punto del artículo, puede sonar complejo decidir por microservicios, y la verdad lo es; sin embargo, esta complejidad no se evidencia desde el momento cero de una implementación, sino que irá apareciendo gradualmente mientras vamos creando más microservicios y escalándolos.

Son muchas sus ventajas, y aunque hay retos, en una estratégia digital a largo plazo es sin duda el camino a adoptar, y así mismo, debe venir acompañada de un soporte directivo dado que la estructura organizacional, técnica y de costos va a tener que evolucionar también.

¿Debo usar Microservicios? La realidad es que muchos desarrollos de Software nacen con este enfoque, sin abordar en un primer momento las soluciones a estos desafíos, pero eventualmente lo harán. Les invito a ver una interesante conversación entre Martin Fowler y Sam NewMan sobre cuando usar microservicios y cuando no.

El soporte de este tipo de aplicaciones es complejo, pues detectar un fallo en una Arquitectura de Microservicios requiere de un entrenamiento en el flujo de negocio, en los puntos de integración y en la interpretación de los logs de información. En muchos casos al soporte de primera línea le faltan insumos para responder y el escalamiento de las incidencias es muy rápido al equipo técnico, resultando en una sobrecarga de operación y costo.

The post Arquitectura de Microservicios: qué es, ventajas y desventajas appeared first on Software Evolutivo.

Kata Juego de la Vida

Fernando Paz — Wed, 18 May 2022 19:35:27 +0000

Una de las katas más populares al hacer Coding Dojo es la Kata Juego de la Vida, y de hecho la más usada en Code Retreat.

Descripción del problema

Este Kata se trata de calcular la próxima generación del juego de la vida de Conway, dada cualquier posición inicial. Consulta Juego de la vida de Conway para conocer los antecedentes.

Comienza con una cuadrícula bidimensional de celdas, donde cada celda está viva o muerta. En esta versión del problema, la cuadrícula es finita y no puede existir vida fuera de los bordes.

Al calcular la próxima generación de la red, sigue estas reglas:

Cualquier celda viva con menos de dos vecinas vivas muere, como si la causa fuera la subpoblación.
Cualquier celda viva con más de tres vecinos vivos muere, como por superpoblación.
Cualquier celda viva con dos o tres vecinos vivos seguirá viva.
Cualquier celda muerta con exactamente tres vecinos vivos se convierte en una celda viva.

Pistas

La posición inicial de entrada podría ser un archivo de texto que se vea así:

Generación 1 inicial:

4 (filas) 8 (columnas)

0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0
0 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0

Generación 2 próxima resultante por regla No. 4:

4 (filas) 8 (columnas)

0 0 0 0 0 0 0 0
0 0 0 1 1 0 0 0
0 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0

Visualiza tus casos de prueba

Hemos preparado la siguiente herramienta para que puedas dibujar (en caso remoto colaborativo) tus casos de prueba, revísalo en Juego de la vida visual.

Casos de prueba sugeridos

Asegúrate de tener suficiente cobertura de casos en los extremos, en donde hay nacimientos y muertes en el extremo de la cuadrícula.

!Que te diviertas! En tu Kata Juego de la vida

DISCLAIMER: La mayoría de este texto es traducido del valioso aporte en GameOfLife, pero no está disponible en español. Pero hemos añadido varias cosas a la descripción y alguna herramienta, para hacerlo en nuestro entendimiento más comprensivo.

The post Kata Juego de la Vida appeared first on Software Evolutivo.

Mejores Historias de Usuario para Scrum

Fernando Paz — Tue, 25 May 2021 03:59:11 +0000

Mejores Historias de Usuario para Scrum

Las Historias de Usuario son una herramienta muy usada en el mundo de la Agilidad, vienen de Extreme Programming y han sido adoptadas en marcos de trabajo ágiles como Scrum. Pero… ¿Cómo escribimos mejores Historias de Usuario para Scrum?.

Hay que decir primero que las Historias de Usuario no son solo para la Agilidad, sino más bien son algo que describe lo que hace un usuario en el sistema para completar una determinada tarea.

Nacieron precisamente de una carencia de los requerimientos, los requerimientos funcionales anteriormente tenían un enfoque desde el sistema. Por ejemplo:

El sistema debe permitir …

Las Historias de Usuario por otro lado sacan del contexto al sistema y expresan que necesita el usuario. Por ejemplo:

Ana como ejecutiva de cuentas requiere … para …

La gran diferencia es que el usuario nos transmite así su necesidad… desde su óptica, con libertad de expresarse, sin lenguajes restrictivos, para luego ser traducido a una perspectiva del sistema por un analista de negocios.

Para escribir mejores Historias de Usuario para Scrum, debemos regresar a ver los principios de la agilidad.

Manifiesto por el Desarrollo Ágil de Software y su conexión con las Historias de Usuario

El Manifiesto ágil nos dice: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: …”.

Individuos e interacciones sobre procesos y herramientas

Las Historias de Usuario crean un entendimiento compartido de una conversación, para los miembros del equipo, los stakeholders y los usuarios finales.

Software funcionando sobre documentación extensiva

Un solo documento de acuerdos reemplaza a mil redacción de actas.

Colaboración con el cliente sobre negociación contractual

Queremos deleitar al cliente… y una negociación contractual no es la mejor manera. La colaboración continua y fluida es clave en los productos y esto representa un Historia de Usuario.

Respuesta ante el cambio sobre seguir un plan

Es necesario tener un plan pero debe ser flexible, general y permitir reaccionar al cambio. El feedback del cliente es el único que nos marca el éxito de un Producto, más allá de cumplir funcionalidades, tiempos y presupuestos.

¿Cómo se relacionan las Historias de Usuario con los principios de la Agilidad?

La más alta prioridad es satisfacer al cliente mediante la temprana y continua entrega de software de valor, mismo valor que se expresa en la historia de usuario.
Los cambios son bienvenidos incluso si es tarde en desarrollo, y si dividimos bien las historias de usuario reducimos los impactos en desarrollo.
Entregar software frecuentemente, desde un par de semanas hasta máximo un par de meses, para esto hay que trabajar en historias pequeñas completas que realmente agreguen por si solas.
Las personas de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto, y las Historias de Usuario son por naturaleza escritas en colaboración continua y fluida.
Construir proyectos alrededor de gente motivada, darles el ambiente y soporte que necesitan, y confiar que van a realizar el trabajo, y aquí la colaboración y apropiación de la solución motiva a las personas alrededor de las conversaciones de la Historia de Usuario.
La forma más eficiente y efectiva de transmitir información hacia y dentro del equipo es una conversación cara a cara, parte de la dinámica de las Historias de Usuario.
El software funcionando es la principal medida de progreso, mismo progreso que se madura, prioriza, simplifica y entrega a través de mejores Historias de Usuario.
Un proceso ágil promueve un desarrollo sustentable, las Historias de usuario nos permite mantener un ritmo predecible de entrega de valor constante.
Poner continua atención a la excelencia técnica y un buen diseño mejora la agilidad.
Simplicidad, el arte de maximizar la cantidad de trabajo no hecho es esencial, hay que enfocarse en los resultados (valor expresado en la Historia de Usuario) y no en las salidas.
La mejor arquitectura, requerimientos y diseño emergen de equipos auto-organizados.
En intervalos regulares, el equipo reflexiona en como ser mas efectivo, luego hace ajustes en su comportamiento acorde a las conclusiones.

Escribiendo mejores Historias de Usuario para Scrum

Como se dijo anteriormente las Historias de usuario no son solo para Scrum pero es cierto que dado las dinámicas y artefactos de Scrum se pone énfasis en ciertos detalles que hacen que las mismas sean más adecuadas para implementar en los ciclos iterativos e incrementales de la propuesta Scrum.

En las siguientes secciones vamos a revisar en detalle las Historias de Usuario sus componentes, características y mejores pŕacticas.

Contenido:

Introducción a las Historias de Usuario

¿Qué son las Historias de Usuario y por qué estas son usadas?

Es una pequeña unidad para trabajar, que dice desde la perspectiva del usuario cual es la funcionalidad deseada.

Mueve el foco de escribir requerimientos a conversar sobre los requerimientos, es decir el principal objetivo es habilitar la conversación y fomentar la colaboración.

Las Historias de Usuario ponen a los usuarios finales en el centro de la conversación.

Historias de Usuario además, nos provee un contexto no técnico para el equipo de desarrollo. El equipo después de participar en una Historia de Usuario sabe porque ellos están construyendo lo que están construyendo y que valor la solución provee.

Una Historia de Usuario escrita efectivamente incrementa la colaboración, la creatividad y el producto en general.

Al escribir la Historia de Usuario debes preguntarte tres cosas básicas:

¿Quién es tu cliente?
¿Qué lo satisface? y,
¿Qué necesita?

La Historia de Usuario ayuda a entregar el más alto valor enfocándose en pequeñas y urgentes necesidades del cliente.

Cuando la necesidad del cliente es descompuesta en pequeñas funcionalidades es posible entregar valor en días o incluso en horas.

Partiendo de un enfoque de entregar el más alto valor en cada Historia de Usuario, conseguimos que:

el equipo esté empoderado
el equipo esté conectado
el equipo pueda colaborar con el usuario final.

Al enfocarse y brindar el mayor valor con cada historia de usuario, los equipos están empoderados, están conectados y pueden colaborar con el usuario final. Y cuando se conectan directamente con el usuario final, los desarrolladores tienen una oportunidad de entender realmente desde la perspectiva del usuario, sus desafíos, sus puntos de dolor, y reciben esa retroalimentación temprana con cada entrega, para que puedan asegurarse que están construyendo un producto adecuado.

Formato de una Historia de Usuario:

[who] as as

[what] I would like

[why> So that or

Siempre se expresa una Historia de Usuario desde la perspectiva del cliente “As a/an…”.

¿Quién escribe las Historia de Usuario y cuando estas son escritas?

Todos los integrantes del equipo pueden escribir Historias de Usuario sin embargo la mayoría del tiempo lo hace el Product Owner o el Analista de Negocio (Business Analyst), esto es más porque ellos están más tiempo cerca del cliente/usuario pero en realidad todo el mundo puede hacerlo.

Una de las mejores prácticas es que el equipo debe ser experto acerca del cliente y del producto por tanto estén en la capacidad de escribir Historias de Usuario. No deben necesariamente hacerlo pero deberían tener esa capacidad y además la capacidad de conversar qué es lo siguiente que viene del Product Backlog.

Por ejemplo el Product Owner y analista de Negocio escriben la primera versión del Historia de Usuario, pero luego el equipo ayuda a madurarla, mejorándola y añadiendo detalles y cosas.

¿Cuando son escritas? Pues en todo momento que llegan o surgen de conversaciones, a lo mejor en primera instancia es un borrador que se debe ir iterando con el equipo y priorizando pero lo importante es tomar nota de aquello que el usuario nos cuenta.

Hay que tomar en cuenta que una idea por si no es una Historia de Usuario, por lo que hay que tomar un tiempo para conversar y transformarla a una Historia de Usuario. Por esta razón es muy común que se manejen documentos alternativos al Product Backlog (donde ya están las Historias de Usuario) para ir desarrollando esas ideas.

Uno de esos momentos es los Demo de productos en donde hay feedback de lo que se hizo y se expresan además cosas que se esperan tener del producto. Estas conversaciones pueden llevarnos a nuevas Historias de Usuario y/o ajustes a Historias de Usuario existentes.

Otro instrumento que se suele tener en los equipos son los Talleres de Historias de Usuario (Story Workshops), que son sesiones cada cierto periodo de tiempo (2 o 3 meses) para escribir Historias de Usuario para los siguientes tres meses (al menos su versión inicial).

Hay otras sesiones importantes como el Backlog Refinement o (Grooming) en donde se crean nuevas Historias de Usuario, se descartan otras, y se estiman o se ajusta la estimación de Historias de Usuario faltantes. Incluso en estas sesiones se Divide (Splitting)” las Historias de Usuario.

3 C's para escribir historias de usuario

Las 3 C’s son las recomendaciones al escribir Historias de Usuario: Tarjeta (Card), Conversación (Conversation) y Confirmación (Confirmation).

La Historia debe ser lo suficientemente pequeña para que entre en una tarjeta y que invite a una conversación.

Hay que recordar que en un enfoque ágil de desarrollo no tienes que tenerlo todo perfectamente definido por adelantado antes de llevarlo al equipo. El equipo y el negocio realmente pueden trabajar juntos para descubrir la necesidad mientras trabajan juntos, y esto puede acordarse a través de la conversación y colaboración alrededor de las Historias de Usuario.

La tarjeta conduce a una conversación entre el Product Owner y los equipos, y esto debe suceder en persona tanto como se posible, y finalmente debe incluir una especie de confirmación.

Ese momento es cuando el equipo sabe realmente qué se debe hacer y en este momento es cuando entran los criterios de aceptación.

Diferencias entre Requerimientos y Historias de Usuario

Muchas veces las solemos intercambiar pero no son lo mismo de ninguna manera.

Existen 4 diferencias básicas:

Perspectiva:
1. El requerimiento tiene perspectiva desde el sistema o desde la solución (el sistema debe…).
2. La Historia de Usuario lo mira desde el problema descrito desde el punto de vista del cliente (como supervisor… quiero… para..).
Cuando estas son usadas:
1. Los Requerimientos tradicionales se utilizan en proyectos no ágiles, por ejemplo en metodologías en espiral o cascada.
2. Las Historias de Usuario se usan en proyectos ágiles mayormente.
Cómo son obtenidas/definidas:
1. Para los requerimientos tradicionales los Analistas de Negocio usan técnicas como entrevistas, encuestas u otras que extraigan respuestas en reacción a las acciones o preguntas, para luego documentarlas en los instrumentos que usen en la organización (ejemplo un BRD – Business Requirement document). Suele ser una actividad única, el Analista de Negocio obtiene las respuestas las documenta y cambia a la siguiente cosa
2. En Agil la Historia de Usuario es una discusión y un esfuerzo colaborativo. La manera en que son escritas ayudan a empujar una conversación, terminando en cosas como porque la necesitan realmente?, cuales son los detalles?, que sabemos y que no sabemos? cuales son los matices que la componen?. Esto es un trabajo de salida constante de información y de conversaciones constantes que aseguran que se consideren todas esas pequeñas piezas desde la perspectiva del usuario.
Quien es el dueño:
1. Los requerimientos tradicionales normalmente pertenecen a quien lo escribió, dado que lo hizo en su lenguaje y en su entendimiento y más allá de eso lo hizo desde la perspectiva de sistema o solución, lo que los hace confusos si no entiendes el contexto desde donde fue escrito. Generalmente el analista de Negocio es el dueño de esos requerimientos con su estructura y normalmente esto implica que se “deba” explicar el documento a otros lectores y de como hacer cambios en el mismo, sintaxis, etc.
2. En enfoque Ágil, el dueño es el Grupo ya que se escribió en grupo con muchas conversaciones y desde la perspectiva del usuario con lenguaje natural y propio del problema. Todos sienten su piel en el juego y que han ayudado a desarrollar esa Historia de Usuario.

Diferencias entre Casos de Uso y Historias de Usuario

Ambas describen una misma meta pero tiene diferentes propósitos: los Historias de Usuario son acerca de necesidades, mientras que los Casos de Uso ayudan a explicar el comportamiento que el sistema debe tener para ser exitoso.

Las Historias de Usuario son realmente pequeñas y concisas, su alcance es muy delgado y específico, en cambio las Casos de Uso describen las interacciones de todo el sistema y a veces con otros sistemas.

Roles de Usuario

Cuando escribes Historias de Usuario tu vas a querer conocer a los usuarios de esas Historias de Usuario, saber qué rol cumplen, como operan, etc.

Al tener esta información sueles tener muchos roles y no tiene sentido y se vuelve inmanejable describir a cada uno en una historia de usuario.

Se recomienda crear grupos de usuarios/roles sobre los cuales discutir las características a implementar.

Según Scrum Alliance los Roles de Usuario son usuarios que comparten:

necesidades comunes
intereses
expectativas
comportamientos

Son entonces una manera de pensar en ciertos usuarios y conversar sobre ellos porque comparten cosas.

Aquí la recomendación siempre será hacer una lluvia de ideas de todos los roles y refinar esta lista y agruparla según los criterios de Roles de Usuarios de Scrum Alliance por ejemplo. Esto podría ser parte de la Incepción Ágil.

Personas

Una vez que tengas los roles puedes crear los “Personas”, de forma que pueda visualizar mejor esa clase de persona:

Persona, es una representación ficticia del usuario, es como la figura Persona que se usa por ejemplo en procesos Customer Journey Map.

Más de las Historias de Usuario

Ojo que las Historias de Usuario son como un punto de partida en donde puedes tener dentro cosas como documentos de respaldo, wireframes, maquetas de UI, diagramas de flujo, y una serie de estas representaciones visuales de requisitos.
- Es importante esto porque a menudo significan un entendimiento común para todos los stakeholders así que no subestimes esta parte.
No asumas que una Historia de Usuario tiene una funcionalidad implícita, esto por ejemplo en el caso de una Historia de Usuario que habla de crear registros, a menudo se suele omitir la actualización de esa información, pero esto puede causar problemas ya que la actualización puede implicar por ejemplo connotaciones de recálculo de otros valores, o reprogramación de otras actividades.
- Es importante ser explícito en las funcionalidades para describir que una Historia de Usuario incluye el CRUD completo o que hay otras Historias de Usuario que especifican tal feature.
Otro detalle importante es el “Porqué?”, ya que nos da el contexto del valor que representa la Historia de Usuario para el cliente y el negocio, y, nos ayuda a priorizarla en el Backlog.
- A menudo las Historias de Usuario quedan mal documentadas y no proveen los suficientes detalles, no para estimarlas, pero si para entenderlas tanto que el “que busca”, así como el “porqué es importante” ya que es probable que después de un tiempo al regresar a retomar una conversación no podamos identificar realmente lo que quisimos expresar.
Hay veces que una Historia de Usuario involucra una funcionalidad compartida entre dos o más roles. Por ejemplo dar de alta a un usuario, esta funcionalidad involucra crear un usuario en el sistema, que lo puede hacer el mismo usuario que desea darse de alta o un administrador de usuarios; sin embargo aunque las pantallas e input son similares no tienen los mismos detalles y accesos por lo que está bien y es correcto tener dos o más Historias de Usuario que representen cada caso con sus particularidades aunque cierta funcionalidad podría ser implementada por la otra Historia de Usuario.

Criterios de Aceptación

Entendiendo los Criterio de Aceptación

La Historia de Usuario no provee suficientes detalles por sí sola para que alguien pueda tomarla y crear algún tipo de solución.

Es por eso que tenemos los criterios de aceptación, que son una serie de condiciones que un producto debe cumplir para ser aceptado por un usuario, un cliente o otro sistema.

Provee estándares y requerimientos que el resultado final debe cumplir para ser exitoso.

Hay cuatro beneficios principales de los criterios de aceptación:

Crea un entendimiento común: provee detalles necesarios en una solución como criterio compartido por los stakeholders.
Define el alcance: le dice a los creadores de la solución dónde empezar y dónde terminar, y que es lo importante.
Valida que una Historia de Usuario está completada: provee un checklist o condiciones que al ser alcanzadas nos indican que finalizó de una forma certera.
Muestra que probar y si pasa la prueba la solución entregada.

Normalmente obtenemos esos detalles faltantes para figurar una solución a través de preguntas poderosas como por ejemplo:

Cuál es la información más relevante a mostrar?
Cómo se va a obtener esa información?
A qué se refiere tal o cual término mencionado?
Quién puede obtener esa información?,
etc.

Su definición pasa por un proceso evolutivo en donde las preguntas fluyen conforme varias conversaciones suceden.

Escribiendo un Criterio de Aceptación

Hay varias formas de escribir los criterios de aceptación entre los cuales mencionamos las siguientes:

Checklist Format, listando esos detalles que hacer la solución exitosa.
Given-(And)-When-Then-(And) que es otro enfoque especialmente usado en pruebas BDD (Behavior Driven Development).

¿Quién escribe los Criterios de Aceptación y cuando son escritos?

El Product Owner generalmente escribe la Historia de Usuario inicial y luego suele recaer la responsabilidad de escribir los criterios de aceptación en el Analista de Negocios, en donde él aplica todo su expertise de análisis de negocios y elicitación (traspaso de información de forma fluida de un ser humano a otro por medio del lenguaje) para el fin.

Aquí el Analista de Negocios suele usar muchas cosas como entrevistas, sesiones de brainstorming, talleres, etc. de forma que pueda documentar con precisión los criterios de aceptación.

Normalmente al crear una Historia de Usuario no se escriben los criterios de aceptación, y la misma se va a iterando en conversaciones en el tiempo. La idea es que la Historia de Usuario esté en un punto sólido de forma que el Analista de Negocios pueda en ese momento trabajar en los criterios de aceptación.

Ninguna Historia de Usuario debería entrar en el Sprint Backlog si la misma no tiene criterios de aceptación.

Mejores prácticas para los Criterios de Aceptación

Escríbelos en texto simple, evita tecnicismos y modismos de forma que sea legible por todos los integrantes del equipo.
Explica la intención no la solución que se necesita.
Mantenlos medibles evita puntos grises, es decir, debe haber criterios blanco o negro porque el gris es sujeto a quien lo usa y como lo usa.
Listas extensas de criterios de aceptación son aceptables, luego preocúpate de dividir la Historia de Usuario; esto, al mismo tiempo significa para los stakeholders interiorizar cuan complejo puede ser la solución y entender que se requiere dividir dicha Historia de Usuario para poder cumplirla en un Sprint.

Escribir mejores Historias de Usuario con INVEST

¿Qué es INVEST?

Una buena práctica al escribir Historias de Usuario es chequearlas con el criterio INVEST.

INVEST significa:

Independiente: la idea es ver si hay dependencias con otras Historias de Usuario ya que puede resultar en problemas de planificación. Incluso afecta a la prioridad ya que una dependencia puede tener baja prioridad pero bloquea una de alta prioridad.
Negociable: la idea es que no es un contrato sino una invitación a una conversación en donde se acuerdan los detalles, los tiempos y los criterios de aceptación entre todo el equipo.
Valiosa: el valor de esa historia debe estar realmente claro para todo el equipo, no solo desde la perspectiva del cliente sino en términos de negocio, y como todas estas Historias de Usuario trazan el camino a los metas del negocio.
Estimable: debe tener los detalles suficientes para que el equipo las pueda estimar, no todos los detalles pero si lo relevante a la Historia.
Pequeña (Small): si la Historia no puede ser completada en un Sprint es muy grande y debería ser dividida, de igual forma si no es necesario hacer una Historia más pequeña pues evite hacerlo ya que al dividirla puede quedar la sensación de trabajo incompleto en un todo.
- Por ejemplo separar un CRUD no tiene mucho sentido a menos que haya algo específico que cause una acción en particular.
Comprobable (Testable): de modo que podamos decir que la implementación está finalizada correctamente.

Más del criterio INVEST

Una de las cosas más importante de una Historia de Usuario es mantenerla negociable, es decir que se permita cambios en la misma. Recuerda que no es un BRD, esto especialmente si hablamos de un ambiente ágil, no tiene sentido hacer algo que nadie quiere por cumplir un BDR.
Otra cosa muy importante es siempre cuestionar si aporta valor, ya que muchas historias parecen aportar valor pero no es relevante frente a las prioridades funcionales y los objetivos de negocio por lo que no debería ser implementada.
Mantenerlas pequeñas por otro lado es crucial porque pueden liberarse al uso rápidamente y retornar la inversión al negocio.
Recuerda que INVEST es una guía y no son reglas estrictas así que hay que tomarlas en cuenta para construir nuestro Backlog pero no tratar de forzar todas las ideas.

Non-Historias de Usuario

Entendiendo los Spikes

Hay aspectos en la solución que no se relacionan al negocio en sí, como por ejemplo la arquitectura, que de acuerdo a los principios de Scrum debe evolucionar según sigue el desarrollo o la implementación del producto. Esto significa que no toda la infraestructura como toda la arquitectura debe estar prediseñada antes de arrancar el Producto.

Spike es una investigación de un conocimiento o incluso la producción de un nuevo conocimiento que da una respuesta para la solución de algo en el Backlog.

Los Spikes son usados para responder a estos retos técnicos e incluso a problemas de diseño.

El resultado de un Spike puede derivar en una nueva Historia de Usuario o una actualización a una existente.

Una de las razones por las que los Spikes pueden ser usados es la investigación, cuando una Historia de Usuario es muy grande para ser estimada, así se analiza el comportamiento esperado, se divide la Historia en otras más pequeñas y se reduce significativamente el riesgo y la incertidumbre en una story.

Recuerda que no por estar en un enfoque ágil vas a dejar de necesitar analizar ciertos aspectos técnicos, de diseño o incertidumbres.

Debes ser documentados como cualquier Historia de Usuario (pero no son Historias de Usuario realmente), deben tener criterios de aceptación para saber qué preguntas tiene que responder o qué preocupaciones tiene que aclarar, y así mismo ir al Backlog ser priorizado y eventualmente incluido en un Sprint Backlog.

La diferencia principal es que en lugar de generar valor para el negocio debe responder preguntas al equipo, preguntas como:

Es esto factible?
Podemos hacer eso con nuestra actual tecnología?
Es esta la mejor opción o hay otras que deberíamos considerar para entregar la misma característica/valor?
Cuáles son los riesgos de tomar cierto camino?

Entendiendo las Historias de Usuario Técnicas y de Infraestructura.

Hay necesidades en la implementación de un producto que no tiene que ver con sus usuarios o el negocio, sino que son necesidades para poder crear el mismo Producto, esto incluye por ejemplo:

Implementación de herramientas de testing.
Implementación de automatizaciones de despliegues.
Implementación de servidores.
Implementación de esquemas de seguridad externos, etc.

Estas Historias de Usuario de Infraestructura o Técnicas tiene el mismo tratamiento que las de negocio e igualmente con criterios de aceptación, adicionadas al Backlog, priorizadas y eventualmente incluidas en un Sprint.

La parte “como … “ (as a …) en la Historia de Usuario es confusa en esta clase de Historias pero a menudo el usuario que requiere dicha feature es el programador, el arquitecto, o incluso el equipo de desarrollo.

Estimando Historias de Usuario

Conceptos Generales de Estimación

En la metodologías tradicionales como cascada las estimaciones son absolutas y van en métricas como horas o días.

En proyectos ágiles son muy importantes las estimaciones pero tienen una diferencia… en los proyectos ágiles las estimaciones no son absolutas sino relativas. Estas estimaciones son producto de comparar tareas unas con otras y así poderlas agrupar según el grupo la complejidad en la que cada una se ubique.

Una métrica bastante conocida es la T-shirt technique (tallas de camiseta) con medidas como pequeña, mediana o grande. Esto nos permite ubicar en un determinado conjunto a tareas que son parecidas unas con otras.

Otra técnica es la serie de Fibonacci que permite una una estimación relativa con un número que determina la complejidad.

Entendiendo la técnica de estimación Fibonacci

Aquí los valores de la serie de Fibonacci representan el tamaño de la Historia de Usuario

Cada Historia de Usuario es comparada con otras y se les asigna un número de la serie de Fibonacci que representa el tamaño más adecuadamente. Este número asignado es conocido como “Puntos de Historia” (Story Points).

Cuando nos encontramos con Historias de Usuario con asignación mayor a 8 como tamaño deberíamos dividirla antes de pasarla a un Sprint Backlog.

En una iteración (Sprint) se implementa un número determinado de “Puntos de Historia” por parte del equipo y el promedio de este número en varias iteraciones viene a ser la velocidad del equipo.

Obviamente al principio, es decir en las primeras iteraciones, la velocidad del equipo no la vamos a tener porque va a depender del desempeño del mismo en el tiempo.

Las Historias de Usuario Épicas

Suele haber casos en que una Historia de Usuario es tan grande o compleja que no se puede estimar tan solo como una definición de “Grande” o con un número Fibonacci como 13, 21, 55 o superior, en este caso es mejor no estimarla y nombrarla como épica (Epic)

Epica marca a un Historia de Usuario, como una conversación pendiente acerca de un análisis más profundo de su complejidad, fases y partes para llegar a una definición derivada de 3, 4 o muchas más Historias de Usuario que permitan su implementación.

Dividiendo las Historias de Usuario

Introducción al concepto de División (Splitting)

A menudo los equipos deben trabajar con Historias de Usuario grandes y muy grandes que no se pueden terminar en una iteración, aquí es cuando es necesario dividir esa gran Historia de Usuario en varias más pequeñas de forma que sea posible implementarlas en una iteración y que por supuesto traten de estar lo más cercano a los principio INVEST.

¿Por qué dividir la Historias de Usuario?

Una de las ventajas principales de dividir una Historia de Usuario es que las Historias de Usuario resultantes explican de mejor manera el todo y a menudo se las puede priorizar y evaluar en cuanto a qué valor aporta, así es probable que muchas de estas pierdan prioridad en el todo o no se las deba implementar realmente.

Al final esta actividad deriva en optimizar y enfocar el esfuerzo en el 20% del trabajo que tiene una alta aportación de valor, y, asignar una priorización más baja a esas stories que no aportan tanto.

La otra gran razón, como ya lo mencionamos, es que una Historia grande no se puede implementar en una iteración (1 o 2 semanas), y dividirla permite implementar parte de ella con un valor determinado en una iteración.

La idea es: algunas historias de Usuario implementadas es mejor que ninguna Historia de Usuario implementada.

La última razón más importante es que una estimación de una Historia de Usuario grande a menudo es errónea ya que no se entiende la complejidad o tamaño de la misma. Dividirla ayuda al equipo a clarificar algunos detalles que son importantes para tener una estimación real del esfuerzo, y así no dar falsas promesas.

Tener divididas las Historias de Usuario también ayuda a que estas sean testeables, y se evidencia con el cómo testear las mismas por ejemplo en ambientes e2e, ambientes mock y/o prueba unitarias solamente.

Dividiendo con simplicidad

Hazlo simple al principio y luego empieza con variaciones.

La idea es que uses primero opciones simples respecto a una solución, y luego las complejas.

Las opciones más complejas puedes escribirlas en las siguientes iteraciones pero al principio mantenlo simple.

Por ejemplo:

Historia de Usuario A: como comprador quiero poder hacer transferencias bancarias entonces puedo cancelar mi pedido.

Dividiéndola:

Historia de Usuario A-1: como comprador quiero poder hacer transferencias bancarias manuales entonces puedo cancelar mi pedido.
Historia de Usuario A-2: como comprador quiero poder hacer transferencias bancarias a través de un link de pagos de mi banco entonces puedo cancelar mi pedido.
Historia de Usuario A-3: como comprador quiero poder hacer transferencias bancarias conectando automáticamente a mi banco entonces puedo cancelar mi pedido.

Dividiendo con un Workflow

Las Historias de Usuario grandes a menudo están compuesta de pasos para ser implementadas.

Por ejemplo una Historia de Usuario como “Comprar en la Tienda en línea” involucra cosas como:

Buscar productos,
Comparar productos,
Seleccionar forma de pago,
Crear una cuenta,
Especificar dirección de entrega, etc.

Cada uno de estos pasos son en sí una Historia de Usuario por lo que una forma de muy evidente de dividir Historias de Usuario es discutir en el proceso que envuelve su cumplimiento.

Dividiendo con CRUD (Crear, Leer, Actualizar y Borrar)

Se puede dividir una Historia de Usuario pensando en las operaciones normales del registro de información: crear, leer, actualizar y borrar.

Tiene sentido si alguna de estas operaciones tiene una complejidad particular y/o son usadas por diferentes roles.

En la mayoría de casos un CRUD es una sola Historia de Usuario aunque operaciones relacionadas como búsquedas, reportes o clasificaciones pueden resultar en otras Historias de Usuario.

Dividiendo por el Método de Ingreso

Hay Historias de Usuario que involucran una entrada de información y esta entrada se puede hacer por varios canales.

Un ejemplo es la función de “añadir fotos en Word”, se puede hacer subiendo las fotos del sistema de archivos, se puede hacer referenciando a un URL, se puede hacer usando un servicio como Pexels, etc. Cada una de estos métodos de ingreso representa una Historia de Usuario en particular y forman parte de una Historia de Usuario más grande que es “añadir fotos en Word”.

Dividiendo con Spikes

Considera una Historia de Usuario en donde necesitas hacer una investigación previa de las alternativas de implementar una solución, es decir un Spike.

Por ejemplo: quieres “pagar con la integración a un Gateway de pagos”, pero no sabes cómo se integra y que necesitas.

En este caso parte de la Historia de Usuario, es esta investigación y debe ir como una Historia de Usuario, la idea es que esa Historia esté planteada con criterios de aceptación de manera que clarifiquen esas dudas que necesitan respuesta antes de la implementación de la funcionalidad.

Ojo debe hacerse un en la investigación porque de lo contrario es muy fácil entusiasmarse en más y más investigación de alternativas y dilatar los objetivos de la Historia de Usuario.

Más acerca de Dividir las Historias de Usuario

No trates de agrandar una iteración para lograr implementar una Historia de Usuario.
No dividas las Historias de Usuario en fases: diseño, desarrollo y testing.
No partas con la mentalidad fija que una Historia de Usuario no se puede dividir, a menudo tener la mente abierta y pensar y hacer preguntas, te llevan a técnicas con las cuales llegas a dividir esa Historia de Usuario.

Retos Comunes al gestionar las Historias de Usuario

Proporcionando el Quién y el Porqué?

No olvides que especificar con precisión quién necesita la funcionalidad en una Historia de Usuario es útil para el enfoque de la solución, el equipo así sabrá quien es esa persona y cuál es su comportamiento normal.

Poner algo como “Como Usuario…” es decir genérico no ayuda al entendimiento de la necesidad.

El “Porqué” en la Historia de Usuario es extremadamente fundamental, y a veces olvidamos describirlo o detallarlo con precisión.

El “Porqué” da el contexto de la necesidad y suele llevar a preguntas adicionales que clarifican la solución.

Manejando defectos y bugs

Es normal que aparezcan de cuando en cuando defectos o mal funcionamientos en el Software, pues se considera que estos al final son parte de la solución o de la creación de la solución.

Muchos equipos tratan de resolver mágicamente estos problemas encontrando tiempo al parecer de la nada, pero hay que recordar que el equipo tiene ya una carga de trabajo asociada a las Historias de Usuario que se hayan comprometido entregar en la iteración que transcurren en ese momento.

Este enfoque es frecuentemente erróneo ya que no terminan de completar las Historias objetivo del Sprint, afectando a su velocidad y expectativas del cliente. La mejor forma es documentar estas incidencias como cualquier otra Historia de Usuario de forma que nos lleve a una conversación, a su estimación y a una definición de criterios de aceptación que expliquen cuando esta incidencia ha sido superada, y, que de igual forma se priorice en el Backlog.

Hay que recordar que hay varios tipos de incidencias, unas que a lo mejor son inhabilitantes o otras que son de forma que no tienen porque ser resueltas de manera urgente.

Lidiando con las dependencias

La mejor forma de lidiar con las dependencias es no tenerlas, y esto en un primer momento es usar prácticas o guías como INVEST que ya la conversamos anteriormente. Aquí el principio de INDEPENDENCIA es un control sobre la definición de una Historia de Usuario que marca que la misma está lista para incluirla en una iteración (Sprint Backlog).

El típico ejemplo es una story que añade funcionalidad o complementa a otra story; aquí evidentemente la story a ser modificada debe existir antes y haber sido implementada en una anterior iteración, pues si las planificamos ambas en una misma iteración vamos a tener un inevitable tiempo muerto para el equipo y por consiguiente un desperdicio de su velocidad.

Combinando Historias de Usuario

Al encontrarnos con Historias de Usuario que son dependientes podemos intentar re-enfocar las mismas de forma que esa o esas dependencias se eliminen. La práctica aquí es combinar las Historias y crear una sola gran Historia de Usuario y a partir de ella pensar en otras formas de dividirla, como por ejemplo encontrar hacerla en fases y no por segmentos de funcionalidad.

Intercambiando algunos de esos requisitos

La idea es que si tenemos dependencias entre Historias de Usuario, podemos identificar esos detalles que componen la dependencia y moverlos de una story a otra de forma que lleguen a un punto que sean independientes.

No hacer nada

Hay veces que estas dependencias no se pueden disolver, incluso aplicando los anteriores métodos.

En estos casos monitorear estas Historias de Usuario es clave para asegurar que su implementación no esté causando problemas al negocio mientras se implementan las Historias dependientes.

Cambiando las Historias de Usuario en medio de un Sprint

Hay que diferenciar el Product Backlog con el Sprint Backlog, ambas contienen Historias de Usuario pero el Sprint Backlog tiene solo aquellas Historia de Usuario priorizadas, estimadas, verificadas (con INVEST por ejemplo) y acordadas con los Stakeholders, antes de iniciar una iteración.

Una iteración (Sprint), normalmente de 2 semanas, tiene como base de trabajo estas Historias de Usuario que han pasado por un proceso y que son el compromiso del equipo. No tiene que y no debe incluirse otras stories una vez comenzada la iteración pues esto genera varios problemas al equipo como por ejemplo: afecta a su velocidad ya que existe más trabajo, afecta a la solución pues no se ha conversado los detalles previamente y afecta la planificación comprometida a los stakeholders.

Si hay una necesidad urgente de una Historia de Usuario esta debe pasar por su proceso de maduración y ser priorizada en el Product Backlog para luego ser incluida, tras el descubrimiento de detalles e implicaciones, en el Sprint Backlog.

El Sprint es un compromiso de trabajo del equipo con los stakeholders.

Retos usando estimación Ágil

Mentalidad relativa a horas

Hay que apoyar a los miembros del equipo que piensa aún en términos de horas (pues sabemos que están acostumbrados a esa referencia), y hacerlos estimar comparando esfuerzo de una story a otra.

Recuerden que la estimación se hace al tener los detalles suficientes sobre la Historia de Usuario, es decir deben haberse ejecutado esas conversaciones que la definen antes, así como tener esos criterios de aceptación.

Comparación de estimaciones entre proyectos o equipos

La estimación en agilidad es relativa a la comparación de stories, al contexto del proyecto y a la base que se haya tomado como métrica.

Por tanto, una estimación en “Puntos de historia” de una misma Historia de Usuario es diferente entre equipos pues su base o perspectiva es acordada en sus conversaciones. 21 Puntos de Historia como velocidad del equipo A puede significar más entrega de valor (funcionalidades) del Producto que 50 Puntos de Historia de velocidad del equipo B en el mismo Producto.

Incluso la velocidad de un mismo equipo puede ser diferente entre implementación de productos ya que son otros los puntos de vista y conversaciones que se acordaron en ese Producto en el equipo.

No es sano y no agrega valor comparar velocidades en ningún caso pero las estimaciones son relativas en proyectos ágiles.

Pensamientos Finales

Las Historias de Usuario son una herramienta muy utilizada en el mundo de la Agilidad, que viene en sus inicios desde el marco de trabajo “Extreme Programming (XP)“, y que ha sido adoptada por varios otros marcos como Scrum.

La idea principal es recordar que la misma provoca varias conversaciones acerca de la necesidad del cliente y se robustece en el tiempo con otra información como diagramás, flujos, documentos, etc. que maduran la necesidad y sirven como datos para una solución efectiva.

Al final esta Historia de Usuario derivará en otras más pequeñas, hasta que tengamos una Historia de Usuario de un tamaño que puede implementarse en un Sprint.

La habilidad de escribir mejores Historías de Usuario para Scrum u otro framework es un conjunto de pasos y técnicas que se interiorizan en el tiempo por el equipo y que al final les permite crear funcionalidades de valor y con entendimiento común.

Esperamos que esta guía robusta de Historías de Usuario les ayude a mejorar esta habilidad y poder entregar cada vez mejor valor a su cliente.

The post Mejores Historias de Usuario para Scrum appeared first on Software Evolutivo.

Código Limpio: Manual del Arte de Desarrollo Ágil de Software

Fernando Paz — Tue, 14 Jul 2020 21:46:57 +0000

Código Limpio – ¿Le mostrarías el código de programación a tu mamá?

Le puede resultar difícil de entender por la semántica del lenguaje de programación y los conceptos de negocio, pero más allá de estos aspectos, escribir Software es un arte creativo en donde narras la solución de un problema. ¿Estás de acuerdo?

Que tal esto:

var a = (m, t) => {

return m*(i/100) }

A esto:

var impuesto = calcular_impuesto(monto, tasa);

function calcular_impuesto(monto, tasa) {

var tasa_en_decimal = tasa / 100;

var valor_impuesto = monto * tasa_en_decimal;

return valor_impuesto;

}

Esta narración permite contar la solución de forma clara a tus colegas (o a ti mismo en un futuro) pudiendo centrar sus esfuerzos en aportar más a ese producto de Software y le compromete dejar el lugar tan limpio como lo encontraron… ¿Todos cuidan un Ferrari verdad?

Hay mil cuestiones más atrás de crear un código limpio, pero la primera en mi concepción es tu profesionalismo y después algunas más importantes que contaremos en otros post:

mantenibilidad
escalamiento
evolución
deuda técnica
costo

El arte del Software se desarrolla a través de la práctica y la experiencia… pero muchas actividades son útiles para acelerarla en los equipos como el Pair Programming, TDD y CI, de lo cual esperamos hablar en otros posts.

Hoy compartimos la primera parte de una serie de Cheat Sheets acerca del libro, MUST READ, para todos los desarrolladores de Software llamado Clean Code: A Handbook of Agile Software Craftsmanship del autor Robert C. Martin.

The post Código Limpio: Manual del Arte de Desarrollo Ágil de Software appeared first on Software Evolutivo.

Liderazgo al Servicio

Fernando Paz — Sat, 13 Jul 2019 16:35:51 +0000

Image by mohamed Hassan from Pixabay

¿Quiero ser Jefe, Gerente, Supervisor, Director…. en mi Trabajo?

Mientras que esta pregunta puede tener múltiples respuestas en cada uno de nosotros hoy queremos poner a su consideración qué significa ser un Líder Servicial.

Las buenas ideas

La globalización y la tecnología, como sabemos, se ha acelerado en todas las industrias haciendo posible ofrecer nuestros servicios/productos a otros países o continentes sin casi limitaciones; sin embargo, al mismo tiempo ha creado contextos de competencia entre empresas similares y entre “aparentes” diferentes empresas.

Hoy Facebook planea permitir pagos en su plataforma compitiendo con la Industria Financiera.

Las buenas ideas no están más solo en los líderes, y la co-creación de conocimiento desde cada una de las arterias de una empresa es vital para el crecimiento y la supervivencia de la misma.

En ese contexto cada una de las personas que apoyan a una empresa son parte de su estrategia de operación, que por su puesto debe tener un “para qué?” significativo para todos.

“Piensa ‘NOSOTROS’ en lugar de ‘YO’”

Valor SEWorker

Alineamiento

Uno de nuestros valores como equipo en la empresa es “Piensa en NOSOTROS en lugar de YO”, sin embargo sin un “para qué?” el valor pierde su significado.

Un “para qué?” (Why según el Golden Circle) puede ser un objetivo que nos lleva a otro objetivo más grande y a su vez a metas… esas metas son las que llamamos Misión y Visión de nuestra Empresa.

Compartir esas metas y su significado como equipo en la empresa hace que cada miembro de él tenga su “para qué?” convencido del valor que le aporta.

Dar más y esperar menos

En su libro “Los Líderes comen últimos”, Simon Sinek menciona la importancia de ciertas hormonas que se generan en el equipo de una empresa. Dos muy importantes son las relacionadas a la gratificación por ayudar y el reconocimiento por hacer. La cultura de colaboración para todo el equipo nos ayuda a obtener estas sensaciones y el Líder debe promover este comportamiento desde el ejemplo.

El agradecimiento y reconocimiento a cada miembro del equipo por su esfuerzo, más la sensación de avance (“para qué?”), es la forma sugerida de mantener al colaborador motivado y enfocado en las metas.

“El compromiso individual en un esfuerzo de grupo hace que un equipo funcione, que una compañía funcione, que una sociedad funcione, que una civilización funcione”.

Vince Lombardi

Confianza

Porque un soldado confía su vida a otro soldado?… porque el primero arriesgaría su vida si fuese al contrario. La confianza es una creencia que se cultiva en ambos sentidos y que un Líder Servicial debe depositar en su equipo para recibirla de él.

La creación de confianza comienza por un interés genuino en cada persona del equipo, teniendo empatía respecto a sus problemas laborales y personales, perfeccionando y fomentando la comunicación efectiva y escucha activa del equipo con el Líder y entre pares.

Un Líder Servicial se podría preguntar:

“Cuán mejor puedo ser para mi equipo/colega?”
“De qué forma puedo aportar más a mi equipo/colega”

Quiero ser Jefe, Gerente, Supervisor, Director… porque…

Dentro del contexto de un Líder Servicial y estructuras de las empresas que están en un proceso de Agilidad Empresarial, estos roles se definen como “líderes que se involucran, empoderan, delegan, entrenan e inspiran a los equipos”.

El Líder Servicial entonces está para su equipo, para su desarrollo de habilidades y mejorar sus debilidades, de forma que no haga la siguiente actividad correctamente, sino para que elija la siguiente actividad correcta.

The post Liderazgo al Servicio appeared first on Software Evolutivo.

[:es]PMP y Ágil, hacia el éxito del Software[:]

Fernando Paz — Wed, 13 Sep 2017 20:17:47 +0000

[:es]

By Easa Shamih (Flickr: Team Work) [CC BY 2.0]

“Los proyectos ágiles también fracasan”

En el Informe del Caos del 2015, publicado por el grupo Standish Group, se evidencia una tasa importante de fracaso en los proyectos de Software que han sido apoyados en prácticas Ágiles para su desarrollo, donde se ha utilizado métodos o marcos de trabajo como Scrum, Kanban o SAFe.

Extraido de https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf

Si bien existe al momento una notable diferencia con los porcentajes fallidos con metodologías tradicionales como Cascada, es importante por otro lado analizar las razones que llevan al 9% de los proyectos Ágiles al fracaso.

Según VersionOne, una de las organizaciones más grandes en el mundo Ágil, en su reporte anual del Estado de los Proyectos Ágiles 2015, el 46% de responsabilidad del fracaso de un proyecto Ágil se debe a la falta de alineamiento de la cultura y filosofía organizacional con los principios ágiles. Pero existen también otros factores que han influido como la falta de experiencia en la implementación del agilismo en las organizaciones, con una incidencia del 41%.

Es de vital importancia para las empresas y todos los actores de los Proyectos de Software trabajar estos riesgos, para construir un camino que asegure el éxito de su trabajo.

Sinergia PMP y Ágil

La colaboración entre el área de Planificación de Proyectos y los practicantes Ágiles es clave en la desarrollo del Software. Es importante tener claro que la visión de trabajo es diferente para cada rol, pero el objetivo es el mismo y este es terminar con éxito el proyecto.

El PMP mira Proyectos que tienen alcance, tiempo y costos muy bien definidos.
El Agilista mira Productos que evolucionan, cuyo alcance se valida constantemente y con costos y tiempos priorizados de acuerdo al valor de negocio.

Si la visión es diferente, la métricas de interés también lo son, así como todo lo relacionado a la trazabilidad del Proyecto o Producto. En consecuencia es recomendable empezar con tres actividades cualquier proyecto Ágil:

Capacitación introductoria al paradigma Ágil.
Acuerdo formal de trabajo.
Incepción ágil.

Por supuesto estas actividades deben ser realizadas con los Stakeholders, Usuarios, Equipos IT, Gerentes de Proyecto y/o PMPs. Existe extensa literatura y programas de formación que nos pueden conducir al conocimiento del paradigma Ágil; queremos en esta publicación enfocar el análisis hacia los retos que supone trabajar colaborativamente entre los dos paradigmas Ágil y PMP, para encaminar un Proyecto exitoso.

“Las prácticas Ágiles apoyan a las metodologías de Gestión de Proyectos, no las reemplazan”

Acuerdos formales de trabajo

Toda organización cuenta con procesos establecidos en mayor o en menor medida para su funcionamiento, la carencia de estos procesos cuestan a las empresas dinero en términos operativos y de mercado, por consiguiente es obligatorio incluirlos dentro de una planificación de proyectos. Así como agilistas, la clave está en entender y aprovechar su valor de negocio con respecto al Producto o Proyecto; esto es uno de los trabajos en conjunto que requiere mayor dedicación de tiempo y de detalle pues es clave a la hora de medir resultados dentro de ambos paradigmas de consecución.

Entre otros se propone establecer acuerdos con respecto a temas como:

Gestión de Comunicación: como vamos a formalizar nuestras conversaciones teniendo en cuenta los riesgos de no hacerlo y los riesgos de sobrecargar los protocolos.
Gestión de Cambios: negociar la planificación PMP en el contexto de la realidad del cambio pero al mismo tiempo basarla en un proceso suficiente y verificado con el negocio, de modo que permita establecer un productos claros.
Productos Evolutivos: divide y vencerás…, que significa visualizar Productos dentro del TODO para planificar Proyectos concretos y medibles; de esta forma no desgastamos los esfuerzos de ambas partes en cronogramas de 6 meses o más y generamos factibilidad de medición de resultados.
Riesgos: los riesgos no se delegan entre sí, sino se mitigan con esfuerzos en conjunto.
Gestión de Documentación: bajo la premisa de que todo documento es importante en tanto y en cuanto alguien lo lea.
Mejora Continua: aquí es importante enfatizar la existencia de reuniones de evaluación inclusiva con los PMPs para tener su retroalimentación respecto a la ejecución del Proyecto y mejorar cíclicamente.

Es requerido entonces mantener un estado de aprendizaje en cada ámbito, de forma que podamos cuestionar criterios y asimilar otros con el mismo objetivo final.

“Construir Software no es como Ensamblar Autos”

Estimar realmente el tiempo que toma la implementación de una funcionalidad parte de un Proyecto es tan importante como la definición misma del requerimiento. Es responsabilidad de todos los practicantes ágiles (PO, Developers, etc.) tanto como de los líderes de la gestión del Proyecto (PMP, Gerentes, etc.) asegurar la no subestimación de los mismos, considerando que el proceso de desarrollo no es una actividad procedimental sino se trata de creatividad; se puede escribir la solución a un mismo problema de 100 formas diferentes con 100 impactos diferentes y con varios niveles diferentes de valor para el negocio.

Como desarrolladores nuestra función es hablar en términos de valor con el equipo del Proyecto, remarcando el aporte que produce al negocio diferentes actividades que ejecutamos en la construcción de Software como TDD, Pair Programming, Refactoring, etc. Siendo este tema un tema tan extenso, es necesario llevarlo al pragmatismo en la planificación de proyectos y ser ágiles tanto en la gestión como en la ejecución de los mismos.

CMMI, ISO u otra?

Finalmente abordamos estos modelos de gestión que están presentes en muchas empresas, y que representan los lineamientos del “QUÉ” se debe hacer para alcanzar la gestión eficaz de la misma, sin embargo el “CÓMO” es el aporte posible del Agilismo; de modo que en el contexto de la sinergia PMP y Ágil, este “CÓMO” se puede mejorar para aportar a la razón del negocio y maximizar el valor.

Podemos referirnos a investigaciones sobre cómo se han complementado estos modelos en Scrum and CMMI Level 5: The Magic Potion for Code Warriors.

Ideas Finales

Capacitar a todos los actores de Proyecto dentro del paradigma Ágil nos permitirá tener una sola visión del Proyecto y la propuesta del valor en el Negocio.
Pre-establecer un marco de trabajo con el área PMO e incluir una retrospectiva de los acuerdos, nos permite sentar la base para mitigar riesgos y generar valor para ambos paradigmas en la consecución del proyecto.
Las interacciones de sinergia presentadas en este artículo enfocan una adopción del paradigma Ágil en pequeños pasos y la constante mejora del proceso, sin embargo se puede partir de resoluciones más corporativas a nivel de estrategia de empresa (top down).
Considerando que el desarrollo de Software es un proceso creativo se debe estimar el tiempo suficiente para la implementación de cada funcionalidad.
Se puede complementar metodologías de gestión como CMMI con las prácticas ágiles.

Te animamos a que nos cuentes también: Como ha sido tu experiencia trabajando en conjunto PMP y Ágil?

[:]

The post [:es]PMP y Ágil, hacia el éxito del Software[:] appeared first on Software Evolutivo.

[:es]Implementación de Liferay 6.2 sobre JBoss 6.4.0 – Como[:]

Fernando Paz — Mon, 12 Sep 2016 17:00:42 +0000

[:es]

Esquema Instalación Liferay sobre JBoss usando Docker. Copyleft www.softwareevolutivo.com.ec

Liferay es un producto para gestionar portales empresariales de información, construido sobre Java y con licenciamiento en Software libre LGPL define a esta tecnología como uno de los actores más importante y con mayores implementaciones en el mercado.

Animados por nuestros valores empresariales que considera al conocimiento como fin social, dejamos una experiencia acerca de este portal y su despliegue en infraestructuras de software modernas.

Antes de continuar con la implementación nos referimos a los productos que usamos como software base:

Docker es una tecnología que implementa contenedores livianos que complementan o sustituyen a las estrategias de virtualización tradicionales. Dado el aprovechamiento masivo del hardware y su rápido despliegue y replicación, es muy utilizado en la tendencia actual de la industria especialmente en áreas como: desarrollo de software, implementación de estrategias de entrega continua y provisión de ambientes de producción con alto crecimiento por demanda.
JBoss EAP, es la versión empresarial de Redhat de un servidor de aplicaciones JEE, con una alta ocupación del mercado y una comprobada comunidad que lo desarrolla y potencia.

Instalación:

El desarrollo de esta instalación de Liferay, está apoyada por documentación existente en proyectos complementarios a este objetivo. Los pasos de estos proyectos complementarios, que serán detallados a continuación, cubren las siguientes actividades:

Definición y creación de un contenedor Docker que contenga una implementación activa del servidor de aplicaciones JBoss 6.4.0.
Definición y creación de un contenedor Docker, a partir del contenedor anterior, que contenga una instalación activa del software Liferay 6.2.
Configuración inicial de software Liferay 6.2.

Docker JBoss 6.4.0:

El primer paso es crear el contenedor Docker que soporte al servidor de aplicaciones JBoss 6.4.0, para este fin se puede revisar otra referencia de cómo podemos realizar esta implementación en https://github.com/pazfernando/jboss-eap-6.4.0-docker.

Es muy importante, en este punto, revisar el README.md de este proyecto debido a que previamente requieren descargar por su cuenta la distribución de JBoss (por cuestiones de licencia) y adicionalmente el contenedor se crea con el nombre “jboss-eap:6.4.0” que es con el que partiremos esta instalación de Liferay 6.2.

Docker Liferay 6.2:

La propuesta de esta implementación de Liferay se basa en el contenedor anterior. La siguiente actividad será crear el contenedor Docker mismo de Liferay a partir del proyecto https://github.com/pazfernando/liferay-6.2-jboss-eap-6.4.0-docker. Este proyecto usa el nombre “jboss-eap:6.4.0” como base de su implementación, y apoyado en esta infraestructura instala el producto Liferay. Para la consecución de esta actividad se debe seguir las instrucciones del archivo README.md.

El nombre “jboss-eap:6.4.0” por su puesto puede cambiar pero requerirá que esté coordinado con el primer proyecto base.

Configuración Liferay 6.2:

Esperamos que en este punto tengan instalado Liferay en esta infraestructura correctamente; Liferay en adelante tiene un wizard el cual lo guiará con los pasos de configuración y datos iniciales. Hasta este momento y como pueden haberlo advertido, no se ha mencionado la base de datos, puesto que la definición de la misma es parte del wizard inicial de configuración de Liferay. Nuestra implementación ha sido pensada para ejecutar el producto sobre el motor Oracle 11g, para lo cual se ha adjuntado y configurado el driver en las actividades previas anteriores.

Recomendaciones finales:

Este proyecto por supuesto es una implementación de una solución para ambientes de desarrollo o testing y requerirá de varios cambios para pensar en una automatización en producción.

Si se requiere profundizar en las configuraciones del producto Liferay en la tecnología JBoss, se puede partir de la URL: https://dev.liferay.com/discover/deployment/-/knowledge_base/6-2/installing-liferay-on-jboss-7-1, estas configuraciones se han automatizado en el contenedor Docker utilizado en este tutorial. Básicamente son los mismos pasos, pero existen especificaciones concretas debido a que JBoss 7.2 fue la última versión antes de que Redhat lo renombrara como JBoss EAP Alpha 6.2; y de ahí en adelante al ser la versión comercial tiene ciertas diferencias a las versión Wildfly que es la comunitaria.

Adicionalmente y como siempre si tiene dudas, comentarios, erratas o algo que decir 🙂 los animamos a comentar en este blog para todos tener un mejor conocimiento y entendimiento.[:]

The post [:es]Implementación de Liferay 6.2 sobre JBoss 6.4.0 – Como[:] appeared first on Software Evolutivo.

[:es]Microservicios en aplicaciones empresariales[:]

Fernando Paz — Mon, 18 Jul 2016 14:40:00 +0000

[:es]

El concepto de Microservicios está a la orden del día y muchas empresas miran o estudian esta alternativa para la implementación de su Software. Este artículo trata de analizar tres temas principales de esta tecnología para que los CIO de la empresas tengan más elementos a la hora de tomar decisiones:

Concepto de Microservicios
Escenarios para adopción de este diseño de Software
Características de la arquitectura y retos de implementación

Concepto de Microservicios

No existe una definición única, pero en general al hablar de microservicios nos enfocamos en una arquitectura en donde se implementa la funcionalidad en silos de programación específicos definidos por el dominio del negocio (DDD). Estos servicios en conjunto, unos con otros, sirven cierta funcionalidad que podríamos denominar el Software producto. Así, en un clásica aplicación de compras en línea podríamos decir que el Software producto está dividido en dominios como inventario de productos, carrito de compras, procesamiento de pagos, sistema de entregas, servicio al cliente, etc., cada uno de ellos se concibe como una micro aplicación que se despliega independientemente de las otras en su proceso y que en la mayoría de casos en general tiene su propio repositorio de datos.

Delante de ellos y por la dinámica de los negocios en la actualidad se construyen los “front-end” que van desde páginas web, aplicaciones móviles, etc., hasta aplicaciones de consolas como Xbox, los cuales interactúan con estas micro aplicaciones a través de API gateway. Muchas de estas aplicaciones se intercomunican entre sí para proveer su funcionalidad, de una forma auto-gestionada, natural en una práctica conocida como coreografía. (Esto a diferencia del concepto de orquestación que se define en SOA[1]).

Existen muchos comparaciones o símiles con una arquitectura SOA (incluso inicialmente Netflix llamaba a esta arquitectura como SOA finamente desglosado[3]), y de un lado y del otro las opiniones tienen puntos válidos acerca de las razones.

En esta perspectiva ponemos a consideración dos puntos:

SOA es una estrategia empresarial que busca alinear la tecnología con la visión estratégica del negocio a través de la orientación a servicios.
Los Microservicios están pensados para simplificar la complejidad de una aplicación empresarial buscando productividad, escalabilidad y reutilización en base al diseño de funcionalidades en silos de programación concebidos como servicios.

Escenarios para adopción de este diseño de Software

La arquitectura de Microservicios en la mayoría de casos puede no ser necesaria pues las aplicaciones con la arquitectura monolítica tradicional funcionan y se vuelven menos complejas de administrar, siendo esta dinámica la más común en las empresas que no tienen un portafolio grande de aplicaciones y/o requerimientos funcionales.

En las empresas de mayor volumen la realidad es diferente, el negocio ha requerido un portafolio grande de software que cubre requerimientos operacionales y comerciales. Aquí la propuesta del uso de esta arquitectura tiene que ver con dos aspectos:

Estrategia del negocio: En este contexto el negocio presenta una dinámica en la cual muchas funcionalidades son requeridas por otros sistemas propios o de terceros. Este podría ser el caso del sistema para emisión de boletos aéreos, el cual es requerido por diferentes canales como kioscos, la página web, los centros de servicio, los sistemas de las agencias de viajes, cajeros automáticos de bancos, etc. , aquí es importante poder cumplir con todos ellos y no perder la oportunidad. En un esquema monolítico donde existe un sistema principal, la disponibilidad de este producto estratégico depende de este sistema principal en donde existen otras funcionalidades no interesantes para el negocio como la administración de usuarios por ejemplo, y presenta riesgos asociados con su evolución, disponibilidad y escalabilidad como tal. Es razonable pensar en abstraer este producto del sistema principal, buscando responder al negocio y su dinámica de forma ágil con un enfoque apropiado buscando su innovación y escalabilidad, en consecuencia podemos pensarlo como un servicio.
Complejidad: En un sistema monolítico sumamente extenso, por toda la funcionalidad que provee, es complejo el mantenimiento porque conceptos como pruebas, validación, despliegue y el conocimiento en sí del negocio se entiende como un todo. Ponemos como ejemplo la adición del campo “referencia” en un formulario de datos de direcciones de los clientes, parte de un sistema de seguros; aquí la tarea se identificada como sencilla, pero dado a que el módulo de clientes es parte de una aplicación monolítica, el cambio tiene un impacto en todo el software, y como tal sus procesos de validación y puesta en producción son extensos, demorados y restringidos. En este escenario se evidencia que la administración debe dividirse para responder al negocio a la velocidad que lo requiere y evitar sobre esfuerzos en tareas simples. Si abstraemos este dominio del negocio y los demás es más probable que este requerimiento sea atendido con prontitud y evitar incluso costos asociados.

Escalamiento Horizontal Aplicaciones Monolíticas, Copyleft www.softwareevolutivo.com.ec

Escalamiento Vertical Microservicios, Copyleft www.softwareevolutivo.com.ec

Características de la arquitectura y retos de implementación

La adopción de la arquitectura en Microservicios requiere además, del análisis de varios aspectos técnicos y organizacionales que debe prever la empresa para no verse inmersa en problemas de gestión y en consecuencia implementaciones no exitosas y llenas de problemas.

Ponemos a consideración las siguientes características:

La concepción de un servicio debe ser en función de un dominio específico y bien delimitado del negocio, generalmente organizados alrededor de una capacidad del negocio.
Los servicios deben ser independientes, disponibles en su propio proceso lo cual nos permite una escalabilidad vertical y no como en las aplicaciones monolíticas que es horizontal.
A un servicio se lo entiende como un producto, por tanto evoluciona como tal y cuenta con un equipo multidisciplinario de desarrollo, su objetivo siempre es mejorar la capacidad de negocio.
Un servicio tiene un punto de conexión inteligente que es capaz de reconocer el mensaje y el mecanismo de acceso con protocolos simples como HTTP básico.
La plataforma tecnológica de un servicio está pensada en la solución correcta y no en estándares corporativos, así podemos crear servicios con diferentes lenguajes de programación y con diferentes repositorios de datos como bases de datos relacionales. documentales o clave-valor.
Esta arquitectura al tener varios servicios requiere varios procesos de despliegue, por lo que es crítico tener un plan de automatización de los mismos evitando sobrecargas de esfuerzo y errores manuales, son muy útiles las tendencias de despliegue como Devops.
La transaccionalidad debe estar preparada para fallos, estamos en un escenario que básicamente es programación distribuida y este concepto requiere experiencia. La atomicidad de la transacción no existe debido al riesgo de falla por la latencia en redes o cortes de servicio, así mismo por otros temas como errores de ejecución
La sobre-arquitectura es una tendencia que puede afectar al diseño de servicios, la idea es crearlos simples pero con una visión evolutiva que crezca a la par del requerimiento de negocio. Aunque la tendencia es desarrollar servicios que toleran cambios en sus proveedores es probable que se requiera de estrategias/políticas más formales como versionamiento y niveles de servicio.

Conclusión

Este artículo presenta tres conceptos principales a tomar en cuenta para la adopción de la arquitectura Microservicios, si bien su adopción puede ser parcial o total se requiere planificar otros aspectos para que la empresa esté preparada para su implementación. Animamos a todos a exponer en este medio sus puntos de vista y su conocimiento para mejorar este contenido y crear elementos de decisión sobre el paradigma.

Casos de éxito:

Finalmente queremos dejar dos enlaces a casos de éxito en la implementación de esta arquitectura para su evaluación y como elemento de decisión:

From a Monolith to Microservices + REST: the Evolution of LinkedIn’s Service Architecture[4]
A Microscope on Microservices[5]

Referencias:

[:]

The post [:es]Microservicios en aplicaciones empresariales[:] appeared first on Software Evolutivo.