by Huenei IT Services | Sep 15, 2020 | UX & UI Design
El User Story Mapping es un ejercicio visual que realizan a menudo los gerentes de producto y sus equipos de desarrollo de aplicaciones o desarrollo web para definir el trabajo que creará la experiencia de usuario más agradable, óptima y ágil.
En otras palabras, es un método de diseño de producto ágil y poderoso que sirve para crear un producto centrado en el usuario, es decir, son la ayuda visual para construir un entendimiento compartido entre los miembros de un proyecto de desarrollo web o de aplicaciones, para conocer cómo elaborar un proceso de diseño exitoso.
Este tipo de método se utiliza para mejorar la comprensión de los equipos de sus clientes y para priorizar el trabajo de todos los equipos de desarrollo, donde estos crean un esquema dinámico de las interacciones de un usuario representativo con el producto, evaluando qué pasos tienen el mayor beneficio para el usuario y priorizando lo que se debe construir a continuación.
En este caso, este proceso siempre comienza con la comprensión de un problema y al mismo tiempo, conociendo los objetivos del usuario, permitiendo dibujar de forma central los pasos que este usuario recorrerá para lograr sus objetivos y de esa manera, narrar un flujo narrativo natural del viaje del usuario para explorar toda la actividad del usuario fácilmente.
¿Todavía tenés dudas sobre este tema? Visitá nuestro artículo anterior “¿Qué es el User Story Mapping?”.
Elementos básicos de un User Story Mapping
Para conocer cómo elaborar un User Story Mapping, es importante saber cuáles son los elementos estructurales que organizan este tipo de diseño, es por eso que en Huenei IT Services primero te presentamos sus nombres y de esa manera, podrás comprender mejor cada uno de los pasos.
A continuación, los elementos básicos de este tipo de diseño, que, al organizarse en dos dimensiones, la vertical denota prioridad, mientras que la horizontal representa los pasos que un usuario toma para realizar acciones en el sistema, también conocido como viaje del usuario o Buyer’s journey en inglés, permiten una lectura sencilla y clara de la estructura general:
1) Columna vertebral (backbone)
En inglés la encontrarás como “Backbone” y esta es la base del mapa, consiste en épicas o temas que describen las actividades generales del usuario en el sistema, como por ejemplo “Buscar Productos”, en este caso, las epopeyas se organizan en un orden horizontal, ya que representan los pasos que toma un usuario mientras interactúa con el producto, que es básicamente una simple visualización del viaje del usuario.
Para entender mejor los conceptos de épicas y epopeyas dentro de esta estructura, es importante saber que la épica representa la Historia de Usuario de tamaño tan grande como para ser capaz de albergar varias historias y la epopeya se refiere a cuando se mantienen varias épicas en sí.
2) Historias de los Usuarios
También conocido como “Stories” y a diferencia de una estructura plana de backlog, las historias de los usuarios están organizadas en dimensiones verticales y horizontales.
En este caso, se agrupan en las épicas correspondientes, que describen tareas más específicas que un usuario puede requerir. Si una épica describe una fase de búsqueda, puede incluir historias como búsqueda básica, productos de filtrado, búsqueda avanzada, etc. Cuando las historias se priorizan verticalmente, se pueden dividir en lanzamientos.
3) Usuarios
Se refiere a las personas ficticias que usarán el producto, es decir, realizarán los pasos descritos en las historias de los usuarios.
Este elemento es proporcionado por especialistas de UX o por el departamento de marketing y servirán como base para el mapa, ya que al no saber quiénes son los usuarios, será imposible comprender las epopeyas del producto y, por lo tanto, perderá todo el punto del mapeo de historias.
Al tener personas de usuario o hablar con el personal de UX, puedes definir quiénes son las personas que realizarán ciertas acciones en el sistema.
Guía para elaborar un User Story Mapping
Elaborar un User Story Mapping será tan variado y diferente de acuerdo al tamaño de tu equipo, el alcance y la duración de un proyecto y la fase de madurez del producto.
Sin embargo, este es un proceso que se debe realizar, en especial cuando se esperan resultados óptimos de principio a fin, y para ello, el mejor momento para comenzar a elaborarlo es cuando has reunido todos los requisitos del producto y has definido el equipo para el proyecto, ya sabiendo qué es la columna vertebral, las historias de los usuarios y los usuarios, es más fácil realizar estos pasos.
Paso 1: Fija los objetivos del proyecto
Primero que nada, concéntrate en los clientes potenciales de tu negocio y resume qué objetivos pueden lograr estos clientes a través del uso de tu producto, escribe cada uno de los objetivos y organízalos en el orden lógico, puedes utilizar pegatinas o realizarlo en un tablero.
Paso 2: Crea el mapa del viaje
Después de recopilar los objetivos, contabiliza el viaje del usuario hasta lograr el objetivo, identifica los pasos y evita los errores siguiendo fielmente el flujo narrativo, para organizarlo de forma más cercana a la realidad, coloca los pasos en la segunda línea, paso a paso.
Paso 3: Encuentra soluciones
A través de este proceso, creas “historias de usuario”, inicialmente, puedes usar la siguiente plantilla: Como usuario – Quiero Este Objetivo – Así que el paso es este.
Haz una lluvia de ideas con su equipo para recopilar la mayoría de las soluciones posibles y poner todas las historias de los usuarios en los pasos relacionados.
Paso 4: Organiza las tareas según su prioridad
Si el equipo de lluvia de ideas tuvo éxito, entonces el mapa de la historia debería estar lleno de grandes ideas, sin embargo, estas historias no se pueden ejecutar en el mismo momento así que en este paso, determinas los diferentes niveles de prioridad.
Identifica el comportamiento más común o la solución básica al problema, así, organizas las historias de los usuarios por prioridad y colocas la más importante en la parte superior de la columna.
Discutir las prioridades con el cliente es crucial, así que asegúrate de mantenerte conectado con tus socios.
Paso 5: Determina la estructura de lanzamiento
Para ello, indica inicialmente la parte de trabajo más pequeña del producto, el producto mínimo viable, intenta completar el recorrido del usuario comenzando con las tareas más comunes o más fáciles de desarrollar.
En esta parte, solo concéntrate en completar al menos un viaje de usuario, después de eso, organiza el resto del trabajo acumulado en piezas tangibles dibujando líneas horizontales entre las tareas.
Si agrega estimaciones a las historias de los usuarios, puede planificar y programar todo el proceso de desarrollo versión por versión.
Todos los pasos de esta guía para elaborar un User Story Mapping son importantes, en especial esta última representa una de las piezas de información más importantes en todo el proceso, porque no solo representa una fase crucial del mapa sino también porque te ayudará a calcular el tiempo y los costos de entrega.
Conclusiones
Lo más importante es siempre tener en mente la experiencia del usuario final, ya que su nivel de satisfacción y adopción son clave en el éxito del desarrollo, así como en el cumplimiento de los objetivos del negocio.
Si necesitas conocer más sobre User Story Mapping, te recomendamos que visites nuestra página de servicios UX/UI Design Services.
by Huenei IT Services | Sep 1, 2020 | Software development
Previamente conocimos los beneficios sobre la Aceleración por Hardware con FPGAs, así como diversos Conceptos clave tras la aceleración con FPGA que ofrecen a las compañías y equipos que los implementen. En este artículo, conoceremos las aplicaciones que típicamente se benefician al emplear esta tecnología.
En primer lugar, se realizará una comparación entre computación distribuida y heterogénea, destacando el lugar que las FPGAs han conseguido en los centros de datos. Luego, presentaremos las aplicaciones más difundidas de la Aceleración con FPGAs, entre ellas, Machine Learning, Procesamiento de Imágenes y Video, Bases de Datos, entre otras.
Computación Distribuida Vs. Heterogénea
En los últimos 10 años, hemos sido testigo de un crecimiento exponencial en la generación de datos, esto en parte gracias al surgimiento y popularidad de aparatos electrónicos, como los teléfonos celulares, dispositivos del tipo Internet de las Cosas (IoT), dispositivos wearables (relojes inteligentes), y muchos otros más.
Al mismo tiempo, el consumo de contenido de mayor calidad por parte de los usuarios ha ido en aumento, siendo un ejemplo claro el caso de la televisión y/o los servicios de streaming, quienes han aumentado paulatinamente la calidad del contenido, lo que se traduce a una mayor demanda de datos.
Este crecimiento en la generación/consumo de datos trajo la aparición de nuevas aplicaciones computacionalmente demandantes, capaces tanto de aprovecharlos como de ayudar en su procesamiento. Sin embargo, surge entonces la problemática con los tiempos de ejecución necesarios para su procesamiento, afectando directamente la experiencia del usuario haciendo impráctica la solución. Esto plantea la interrogante: ¿cómo podemos disminuir los tiempos de ejecución para hacer más viable las soluciones planteadas?
Una de las soluciones planteadas consiste en usar la Computación Distribuida; en esta se interconectan más de una computadora en red para distribuir la carga de trabajo. Bajo este modelo, la aceleración teórica máxima a obtener es igual a la cantidad de máquinas agregadas en el procesamiento de datos. Si bien es una solución viable, ofrece la problemática de que se deben considerar los tiempos involucrados en realizar la distribución y transmisión de datos por la red.
Por ejemplo, si queremos disminuir el tiempo de procesamiento de datos a la tercera parte, tendríamos que configurar hasta cuatro computadoras, lo cual dispararía los costos de consumo de energía y el espacio físico a ocupar.
Otra alternativa, es emplear Computación Heterogénea. Esta, además de utilizar procesadores (CPUs) para las tareas de propósito general, buscan mejorar el rendimiento de un mismo equipo agregando capacidades de procesamiento especializadas para realizar tareas particulares.
Es en este punto donde se emplean las tarjetas gráficas de propósito general (GPGPUs) o de lógica programable (FPGAs), siendo una de las principales diferencias que las primeras poseen una arquitectura fija, mientras que las segundos son totalmente adaptables a cualquier carga de trabajo, además de consumir menos (debido entre a otras cosas a la posibilidad de generar el Hardware exacto que se utilizara).
A diferencia de la Computación Distribuida, en la Computación Heterogénea la aceleración dependerá del tipo de aplicación y la arquitectura que se desarrolle. Por ejemplo, en el caso de las bases de datos, la aceleración puede tener una menor frecuencia que la que tendría un caso de inferencia de Machine Learning (la cual puede acelerarse por cientos de veces); otro ejemplo sería el caso de la aceleración de algoritmos financieros, donde la tasa de aceleración se da por miles. Adicionalmente, en lugar de agregar computadoras, simplemente se agregan placas en slots PCIe, ahorrando recursos, espacio de almacenamiento y consumo energético, traduciéndose en un menor Coste Total de Propiedad (TCO de sus siglas en inglés).
Las tarjetas aceleradoras basadas en FPGA se han convertido en un excelente complemento para los centros de datos, estando disponibles tanto on-premise (servidores propios) como en servicios en la nube de Amazon, Azure y Nimbix, entre otros.
Aplicaciones que se benefician de la aceleración por Hardware con FPGAs
En principio, cualquier aplicación que involucre algoritmos complejos con grandes volúmenes de datos, donde el tiempo de procesamiento sea lo suficientemente largo para mitigar los accesos a la tarjeta, es candidata a aceleración. Además, debe tratarse de un proceso que pueda realizarse a través de paralelización. Entre las soluciones típicas para FPGA, que responden a estas características, encontramos:
Una de las técnicas más disruptivas de los últimos años ha sido Machine Learning (ML). La aceleración por hardware puede aportar muchos beneficios, debido al alto nivel de paralelismo y el enorme número de operaciones matriciales necesarias. Estos pueden apreciarse tanto en la fase de entrenamiento del modelo (reduciendo este tiempo de días a horas o minutos), como en la fase de inferencia, posibilitando aplicaciones en tiempo real (detección de fraude, reconocimiento real-time en video, reconocimiento de voz, etc.)
El Procesamiento de Imágenes y Video es una de las áreas más beneficiadas por la aceleración, posibilitando trabajar en tiempo real en tareas como transcodificación de video, transmisión en vivo y procesamiento de imágenes. Se utiliza en aplicaciones como diagnósticos médicos, reconocimiento facial, vehículos autónomos, tiendas inteligentes, realidad aumentada, etc.
Las Bases de datos y Analíticas reciben cargas de trabajo cada vez más complejas debido a los avances en ML, lo que obliga a una evolución del centro de datos.
La aceleración por hardware aporta soluciones a la computación (por ejemplo, con aceleradores que, sin tocar código, aceleran PostgreSQL entre 5-50X o Apache Spark hasta 30x) y al almacenamiento (vía discos SSD inteligentes con FPGA).
La gran cantidad de datos a procesar, precisa de Sistemas de almacenamiento más rápidos y eficientes. Moviendo el procesamiento de la información (compresión, encriptación, indexado) lo más cerca posible de donde residen los datos, se reducen cuellos de botella, liberando al procesador y reduciendo los requerimientos de energía del sistema.
Algo similar ocurre con la Aceleración de redes, donde se mueve el procesamiento de la información (compresión, encriptación, filtrado, inspección de paquetes, conmutación y enrutamiento virtual) a donde los datos ingresan o salen del sistema.
La Computación de Alto Rendimiento (HPC), es la práctica de agregar más poder de cómputo, de tal manera de entregar un rendimiento muy superior al de una PC convencional, para resolver grandes problemas de la ciencia y la ingeniería. Incluye desde la secuenciación del Genoma Humano hasta el modelado del clima.
En el caso de las Tecnología Financiera, el tiempo es clave para reducir riesgos, tomar decisiones comerciales informadas y proveer servicios financieros diferenciados. Se pueden acelerar procesos tales como el modelado, negociación, evaluación, gestión de riesgos, entre otros.
Con la aceleración por Hardware se pueden ofrecer Herramientas y Servicios que procesen la información en tiempo real, ayudando a la automatización de diseños, obteniendo tiempos de desarrollo más cortos.
Conclusiones
Haciendo una breve comparación entre los modelos, en la Computación Distribuida se interconectan más de una computadora en red y se distribuye la carga de trabajo entre todas ellas. Este modelo, utilizado por ejemplo por Apache Spark, es altamente escalable, pero tiene como desventaja el consumo y el espacio físico ocupado, los cuales se incrementarán proporcionalmente.
En lo que respecta a la Computación Heterogénea, se mejora el rendimiento de un mismo equipo, mediante el agregado de hardware (por ejemplo, vía tarjetas gráficas como GPGPUs o FPGAs), sumándole capacidades de procesamiento especializadas. Esto posibilita obtener tasas de aceleración que dependen del tipo de aplicación, pero que pueden estar, en algunos casos, entre 1-10X (por ejemplo, al usar Bases de Datos) hasta cientos o miles de veces al utilizar Machine Learning.
A través de un análisis de rentimiento (profiling) y de validad la factibilidad de paralelizar los distintos procesos y soluciones podemos determinar si la Aceleración de Hardware por FPGA es la solución ideal para tu compañía, principalmente si esta trabaja con algoritmos complejos y grandes volúmenes de datos.
De esta forma, tu negocio podrá mejorar la experiencia del usuario al ofrecer una experiencia más rápida y fluida gracias a reducir los tiempos de ejecución de procesos; adicionalmente, y gracias a la reducción del TCO de sus soluciones, se optimizaría el control del presupuesto.
by Huenei IT Services | Aug 15, 2020 | UX & UI Design
En proyectos grandes, la colaboración y el trabajo en equipo suelen ser cruciales para que el progreso sea iterativo y pueda existir un progreso incremental con el paso del tiempo. La realidad es que mientras más complejo es el proyecto, más difícil es llegar al objetivo final: conectar con el usuario final.
En los proyectos de desarrollo de software, por ejemplo, en las que el equipo debe realizar complejos procesos de Testing & QA para garantizar que el producto final cumple con las expectativas del cliente, es vital contar con un mecanismo sencillo que permita hacer un seguimiento de que todo el desarrollo está orientando sus recursos a resolver sus necesidades.
Y es aquí cuando técnicas como el User Story Mapping se convierten en una vía confiable para crear proyectos participativos en los que sea posible combinar la visión de los usuarios y los desarrolladores de una forma equilibrada y funcional, creando prototipos representativos que ayuden a vislumbrar el resultado final y fomentando el trabajo en equipo.
¿Qué es el User Story Mapping?
El User Story Mapping (o User Story Map) es una técnica que facilita la delimitación de los requisitos de un servicio o producto a partir de la colaboración del usuario y los desarrolladores, de modo que se pueda determinar las funciones imprescindibles –la cual se denomina Producto Mínimo Viable o MVP bajo sus siglas en inglés– del mismo.
En proyectos de gran escala, el User Story Map se puede desglosar en dos dimensiones el proyecto: dimensión horizontal –también conocidos como Customer Journey– y dimensión vertical, las cuales permitirán que se identifiquen los actores involucrados en el proyecto de forma directa (los usuarios) e indirecta (los desarrolladores).
¿Para qué nos sirve?
Inicialmente puede resultar complicado de implementar y mucho más difícil de identificar, en especial cuando se está llevando a cabo muchos pasos en la elaboración de un proyecto. En líneas generales, nos sirve para desarrollar cada uno de los puntos del proyecto que guardan algún tipo de interacción directa o indirecta con los usuarios. Durante el proceso de desarrollo se busca identificar cada una de las variables que entrarán en contacto con el usuario, como actividades, tiempos de espera, necesidades mínimas, información, interacción con el contenido visible, inicio de sesión, entre otros.
También sirve para crear un arquetipo de usuario que facilite la identificación de pasos que el usuario realizará cuando este esté usando el producto o servicio final, así como diseños visuales de cada fase del proyecto para tener una visión de lo que el usuario experimentará en cada etapa.
¿Cómo implementarlo en el proceso de desarrollo?
Esta puede realizarse de dos formas: realizando un arquetipo de modelo de usuarios (conocido también como Customer Journey) o determinando las características que tendrá el producto como mínimo –también llamados como dimensión horizontal y dimensión vertical, respectivamente.
Diseñando un arquetipo de modelo de usuarios (Customer Journey)
Se realiza una ficha con todas las características de un usuario, de modo que se pueda identificar como si fuese una personal real (en proyectos grandes lo ideal es tener varias fichas, las cuales representarán a diferentes usuarios que facilitarán las pruebas).
De esta forma se logra identificar los parámetros por la cual se puede desarrollar el proyecto, teniendo a cada uno de los usuarios como participantes. Esta fase se puede aplicar tantas veces sea necesario, con el fin de identificar todos los arquetipos de usuarios existentes.
Determinando las características mínimas del producto
La segunda forma no es muy diferente a la primera, pero en esta el enfoque está en el usuario y tipo de Customer Journey. Desde este punto es posible determinar cuáles son los pasos que afectarán el proyecto o hasta aquellos eventos que puedan ser importantes en la resolución final del proyecto.
En Huenei IT Services, por ejemplo, brindamos servicio de diseño de UX/UI multiplataforma, de modo que si el proyecto cambia en la fase final y el cliente requiere de una aplicación móvil a la medida, podamos brindar desarrollo móvil sin problema.
Beneficios
Más allá de la optimización de recursos al orientar todo el esfuerzo en resolver las necesidades reales de los usuarios y las funcionalidades clave del desarrollo, encontramos que:
- Facilita la elaboración de un producto desde cero, de modo que sea mucho más sencillo corregir errores y evolucionar sus procesos en el futuro.
- Es posible detallar subprocesos del proceso principal que difícilmente fueron detallados al inicio. Estos son vitales para crear soluciones a la medida, mejorar la toma de decisión a futuro, saber a qué se le debe dar prioridad, entre otras cosas.
- Facilita la identificación de una o más versiones del producto que se desea entregar al usuario antes de su entrega, de modo que delimiten las características y funciones que tendrá.
- Ayuda a priorizar las actividades que se deben realizar en su momento para evitar retrasos.
- Analiza cada una de las actividades realizadas por el usuario para crear una estructura sistémica completamente nivelada.
- Ayudar a controlar las User Stories en diferentes entornos, de modo que cada persona del equipo pueda llevar un seguimiento de cada uno de los movimientos realizados en tiempo real.
- Controla los retrasos o fallos de todo tipo de una forma general y estructurada, de modo que sea mucho más sencillo prever eventos futuros que puedan perjudicar la experiencia del usuario, como es el caso de fallos en el sistema que se pueden identificar realizando un Testing.
Recomendaciones
- Implementar post-its o cualquier otra herramienta similar (como carteleras, por ejemplo) para que el proceso de redacción de ideas sea mucho más sencillo y dinámico.
- Realizar reuniones constantes para hacer una lluvia de ideas colaborativa en la que se pueda discutir temas y proponer ideas creativas.
- Mantener un registro de toda la información hablada durante las reuniones luego de que estás finalicen. De esta forma se puede llevar un control digitalmente de los tópicos hablados para rehusarlos en el futuro.
Conclusión
El desarrollo de proyectos enfocados en el progreso iterativo suele suponer un reto para cualquiera, en especial cuando no se tiene claro los objetivos principales del proyecto y su finalidad. El trabajo en equipo es, sin duda alguna, la base de todo, y por ello la implementación de la técnica de User Story Map resulta tan conveniente y sencilla de ejecutar.
En Huenei IT Services sabemos que sin importar cuán lejos se quiera llegar en un proyecto, en ocasiones elegir una técnica sencilla es la mejor vía para lograr los objetivos planteados. Proyectos de Desarrollo de Software, Desarrollo Móvil, QA (Quality Assurance) e incluso la aplicación de outsourcing o tercerización en proyectos de TI podría requerir de una técnica flexible y dinámica como la User Story Map. Es un método bastante intuitivo, en la que importa la colaboración y se fomenta la participación individual de cada participando del equipo de desarrollo para dar con ideas que puedan acercar el proyecto a su resolución final.
Sin dudan alguna, el impacto que genera el story mapping en la dinámica de trabajo de un equipo es positivo, y más allá de facilitar el entendimiento entre los desarrolladores y los usuarios, está el hecho de fomentar la comunicación dentro y fuera del equipo, un factor que puede hacer la diferencia en cualquier proyecto.
by Huenei IT Services | Aug 1, 2020 | Software development
¿Qué es DevOps?
La combinación entre “desarrollo” y “operaciones” conocida como DevOps, ha gestado todo un cambio cultural cerrando la brecha entre dos importantes equipos que históricamente habían funcionado por separado. Esta importante relación da cuenta de una cultura que impulsa la colaboración entre ambos equipos para automatizar e integrar los procesos entre el desarrollo de software y los equipos de TI a fin de que puedan cimentar, experimentar y proyectar un software en el menor tiempo posible.
Gracias a ello, se ve aumentada también la capacidad que tiene una empresa o institución de proporcionar aplicaciones y servicios casi inmediatos, permitiéndoles brindar una mejor atención a sus clientes y competir más eficientemente en el mercado. Los equipos se pueden valer de prácticas innovadoras para automatizar procesos que anteriormente se llevaban a cabo de forma manual, apoyándose siempre en herramientas que los ayudan a administrar y optimizar las aplicaciones de manera más rápida.
DevOps puede operar bajo diversos modelos donde incluso los equipos de control de calidad y de seguridad se integran también a la combinación que han hecho los equipos de desarrollo y operaciones, desde el desarrollo, pruebas hasta la implementación de una aplicación. Esto es sobre todo común cuando la seguridad es una prioridad en el proyecto.
¿Cómo saber si necesito DevOps?
Si su empresa u organización atraviesa por cualquiera de estas situaciones, es bastante probable que necesite implementar una dinámica DevOps:
- El equipo de desarrollo está teniendo problemas para optimizar el código antiguo, crear un nuevo código o preparar nuevas características de productos.
- Las disparidades entre los equipos de desarrollo y producción han ocasionado errores y fallas de compatibilidad.
- Las mejoras que fueron implementadas (relacionadas al software deployment) están actualmente obsoletas.
- Su empresa está experimentando un lento time-to-market, es decir, el proceso que va desde la elaboración del código hasta la puesta en producción es demasiado pausado y poco eficiente.
¿Cómo llevar a cabo un proceso de implementación de DevOps?
Implementa una mentalidad DevOps
Identifica las áreas donde el proceso de entrega actual de tu empresa sea ineficaz y deba optimizarse. Esta será una gran oportunidad de gestar un cambio real en tu organización, así que debes estar abierto a experimentar. Aprende de los posibles fracasos a corto plazo, te servirán para mejorar, no te acostumbres a aceptar dinámicas ineficientes porque es lo “tradicional”.
Saca provecho de las métricas
Es importante escoger las métricas correctas para verificar y dar seguimiento al proyecto. No tengas miedo de medir aquello que podría no verse bien en un comienzo, ya que, tomando consciencia de esto, es que podrás notar un progreso verdadero, así como beneficios comerciales reales.
Acepta que no existe un camino único
Cada organización debe atravesar circunstancias diferentes de DevOps vinculadas a su negocio y cultura, donde, el modo en que deberán hacer las cosas, dependerá más de cómo puedan cambiar sus hábitos y patrones en los equipos que de las herramientas que usen para habilitar la automatización.
No dejes a un lado el aseguramiento de calidad (QA)
Las empresas que implementan DevOps con frecuencia se enfocan en automatizar las implementaciones, dejando a un lado las necesidades de QA. Aunque sabemos que no se pueden automatizar todas las pruebas, es primordial automatizar al menos las pruebas que se ejecutan como parte del proceso de integración continua tales como pruebas unitarias o análisis de código estático.
Aprende a mirar la automatización desde un enfoque más inteligente
Realmente no se pueden acelerar procesos de entrega sin automatizar. Tanto la infraestructura, el entorno, la configuración, la plataforma y las pruebas están escritas en código. Por ello, si algo comienza a fallar o deja de ser eficiente es probable que sea hora de automatizarlo. Esto traerá diversos beneficios como reducir los tiempos de entrega, aumentar las repeticiones y eliminar la deriva de la configuración.
Principales beneficios
Existen diversas razones por las que DevOps es útil para los equipos de desarrollo, a continuación, examinaremos las más importantes:
- Gracias a su alta previsibilidad, la tasa de fallas de DevOps es bastante reducida
- Esta dinámica permite reproducir todo, en caso de que se quiera restaurar la versión anterior sin problemas
- Si se inhabilita el sistema actual o alguna nueva versión falla, DevOps ofrece un proceso de recuperación sencillo y rápido
- Time-to-market reducido a un 50% mediante la entrega optimizada de software. Una buena noticia para aplicaciones digitales y móviles.
- Los problemas de infraestructura están incorporados en DevOps, por lo que los equipos pueden ofrecer una calidad más elevada en desarrollo de apps.
- La seguridad está incorporada también en el ciclo de vida del software, ayudando además en la reducción de defectos.
- DevOps conduce a un sistema operativo más seguro, resiliente, estable y con cambios 100% auditables.
- La eficiencia en costes durante el desarrollo es posible cuando se implementan herramientas y modelos DevOps
- Está basado en métodos de programación ágil por lo que permite dividir la base del código más grande en fragmentos más pequeños y adaptables.
Conclusión
Antes de la llegada de DevOps, el equipo de desarrollo y el equipo de operaciones trabajaban de manera aislada dando como resultado un consumo de tiempo mucho mayor al que suele tomar una construcción real. Este modelo era bastante ineficiente ya que las pruebas y la implementación era llevadas a cabo después del diseño y la construcción, además el despliegue manual del código daba paso a múltiples errores humanos en la producción, lo que ralentizaba aún más cualquier proyecto.
Con la implementación de DevOps se ha visto aumentada la velocidad del desarrollo dando como resultado entregas rápidas, la calidad de las actualizaciones es mayor, la seguridad también se ha incrementado por lo que se considera como uno de los sistemas más confiables. La transformación digital de nuestros días ha incrementado las exigencias para el desarrollo de softwares y DevOps ha demostrado que puede cubrir bastante bien todas las necesidades y satisfacer las expectativas del mercado.
by Huenei IT Services | Jul 15, 2020 | Process & Management
La gestión de proyectos en el rubro tecnológico es un elemento clave para el éxito de la operación, ya que sienta las bases y estructura general del proyecto a realizar, ya que sobre esta estructura se construyen los otros elementos, como el diseño de la interfaz, la experiencia del usuario, validación de concepto, pruebas de calidad, entre otros.
Para que estos proyectos avancen, primero debemos entender la finalidad de estos, así como las necesidades actuales, futuras, explícitas e implícitas de nuestros clientes, sus usuarios finales y los respectivos grupos de interés. Posteriormente, y entendiendo el alcance de la solución, dividimos el proyecto en fases que nos permitan la realizarlo de una forma ágil y eficiente.
Es aquí donde se viene lo difícil, ya que debemos asignar de forma estratégica cada actividad a realizar, entendiendo que debemos completar una para continuar con la siguiente, sin embargo, constantemente surge la duda: ¿esta tarea/actividad está “hecha”? ¿no está relacionada con otra tarea futura que podrá afectar su estatus?
Estas y otras interrogantes son las más comunes de lo pensado, siendo el principal debate que deberían tener tanto el cliente (Product Owner) como los líderes de proyecto de parte de las compañías de desarrollo de software.
Definir el significado de “Hecho”
La Definición de “Hecho” (o como se estila decir en inglés DoD por Definition of Done) es cuando todas las condiciones, o criterios de aceptación, que un producto de software debe satisfacer son cumplidas, de manera que cumple funcionalmente con los requisitos de un usuario, cliente, equipo, o está disponible para ser utilizado por otro sistema, cumpliendo con los parámetros de calidad establecidos. Esto evita que alguna característica/funcionalidad incompleta sea puesta en productivo, generando errores y retrabajo al tener que regresar para hacer las debidas correcciones, así como disconformidad de los clientes y/o usuarios finales.
Esta definición se determina al inicio de cada proyecto, usualmente en las reuniones que sostiene el Product Owner y los líderes de desarrollo, sin embargo, suele ocurrir que a medida que avanza el proyecto, esta definición es replanteada variadas veces, de manera de que las expectativas del mismo terminan acoplándose a la práctica, así como a los distintos parámetros de calidad, proceso de trabajo, entre otros.
Teniendo claro cuándo una característica/funcionalidad esta “hecha”, entonces se puede tener una mejor idea de en qué parte del proyecto nos encontramos, permitiendo tomar decisiones más certeras y claras acerca de cuanto falta para terminarlo y cuándo deben ser incluidos los respectivos recursos en el proyecto.
Un elemento clave, que nos ayudará enormemente en esta definición consta en las llamadas User stories (historias de usuario), estas podrían definirse como el trayecto que siguen los usuarios dentro de nuestro desarrollo para realizar las tareas deseadas.
Uno de los mayores riesgos que puede ocurrir al no contar con una clara definición y entendimiento de las partes ocurre justamente al presentar todos los requerimientos completados durante el proyecto, precisamente al final de cada iteración, donde al momento hacer las debidas revisiones nos daremos cuenta de que dichos requerimientos no están del todo finalizados, generando los debates sobre el avance real.
La importancia de acordar términos
Cuando una historia de usuario o un incremento (conjunto de historias) está “Hecho”, todos en el equipo deben dar por entendido lo mismo: que esta funcionalidad/incremento ya puede salir a producción. Si bien este entendimiento es resultado de transparencia y confianza entre las partes, la parte más evidente es cuando se suele avanzar a la siguiente fase del proyecto, ejemplo: cuando el equipo Scrum finaliza un sprint.
Otro aspecto importante es definir qué tan completa debe estar una característica, funcionalidad, historia o incremento para pasar a la siguiente etapa. Si esta es de vital importancia para todo el proyecto, entonces debe ser considerado como un criterio de mínima. De lo contrario, volverán a ocurrir malentendidos de parte y parte.
Sin embargo, la Definición de “Hecho” puede evolucionar. Cuando la relación entre el Product Owner y el equipo Scrum madura y se desarrolla positivamente, puede ocurrir que la definición de “Hecho” usada previamente en los incrementos se amplíe durante las reuniones de Retrospectiva y retroalimentación, incluyendo nuevos criterios de mayor calidad, basados en parámetros más prácticos.
Relación entre “Hecho” y Criterios de Aceptación
Un elemento importante para determinar el estado de alguna característica, funcionalidad, etc. Es el llamado Criterio de Aceptación, su definición más básica es cuando esta cumple con todos los requisitos mínimos necesarias para poder ser puesta en producción, tanto a nivel técnico, como funcional, operativo, entre otros.
Los criterios de aceptación son importantes para:
- Gestionar las expectativas, tanto para el Product Owner como para el equipo Scrum.
- Definir el alcance y reducir la ambigüedad.
- Establecer criterios de prueba para el control de calidad.
- Evitar el cambio de alcance a mitad del Sprint, lo cual afecta directamente en la planificación.
Uso de la Definición de “Hecho” en las Fases de un Proyecto
Una vez entendida esta definición, así como los Criterios de Aceptación mínimo, los responsables de planificación del proyecto podrán elaborar la debida hoja/mapa de ruta del desarrollo del producto/servicio, así como la estimación global del esfuerzo a invertir con el propósito de cumplir efectivamente con las Historias de los usuarios.
A su vez, define la cantidad de trabajo a definir en cada Sprint, ya que se usará como guía para cumplir con la definición de los criterios establecidos en la reunión de planificación y en las subsecuentes reuniones de seguimiento y retrospectiva. Esto tiene como resultado una mejor evidencia en la terminación de una fase del proyecto y el inicio de la siguiente.
Impactos de la falta o mala de aplicación de la Definición de “Hecho”
Uno de los principales efectos de una incompleta o mala aplicación de la Definición de “Hecho” es la “Deuda Técnica, la cual se refiere al trabajo adicional producido por una implementación de una funcionalidad o característica que no estuvo finalizada, o que no cumplió con todos los requerimientos mínimos necesarios, como puede ser el haber realizado las debidas pruebas de calidad, o la documentación.
Como principal consecuencia encontramos que el equipo debe retrabajar en finalizar los requerimientos mínimos en las funcionales/características previamente aprobadas, lo cual genera retrasos y pérdida de recursos.
Consejos a tener en cuenta para la redacción de la Definición de “Hecho”
- Involucrar al equipo: incluir en la etapa de planificación a la mayor cantidad de miembros responsables del equipo, de esta manera todos podrán dar su punto de vista y traer a la mesa temas que solo se podrían ver más adelante del proyecto. Mejorando la visión que se tiene del proyecto y cuándo terminaría una fase y comenzaría otra.
- Realizar las historias de los usuarios: este valioso recurso nos permite identificar las necesidades de los usuarios desde su punto de vista. Mientas mejor definidas estén, más fácil será determinar cuándo un desarrollo está “Hecho”.
- Cumplir con los requerimientos técnicos: es muy importante que todas las funcionalidades y requerimientos técnicos sean alcanzados, de manera de que el desarrollo tenga los parámetros de calidad aceptados, garantizando que el aplicativo tenga el desempeño esperado.
- Cumplimiento de los requerimientos: es muy importante que todas las funcionalidades y requerimientos sean alcanzado a nivel técnico, de manera de que el desarrollo tenga los parámetros de calidad aceptados, garantizando que el aplicativo tenga el desempeño esperado.
- Ejecutar Testing funcional y no funcional: validar la calidad y que los requerimientos técnicos estén debidamente testeados es clave. Ningún desarrollo de ningún tipo debería estar considerado “Hecho” sin haber pasado por el proceso de Testing & QA.
- Contemplar las Épicas (Epics): donde “Hecho” a este nivel puede referirse a una prioridad estratégica de la organización, un objetivo del plan de negocio, o alguna un conjunto de requerimientos que satisfagan una necesidad del mercado.
Conclusión
El arte de gestionar un proyecto va más allá de dividirlo en fases y asignar recursos y fechas de entrega, siendo lo más importante el conocer a fondo tanto los requerimientos del cliente como contar con el dominio técnico necesario para saber asignar los recursos correctamente.
Los procesos de Huenei incluidos en su Propuesta de Servicios Ágil incluyen acordar con sus clientes la Definición de “Hecho” para sus servicios, permitiendo brindar transparencia en los resultados y confianza sobre el avance del trabajo.
Así mismo y como parte del compromiso en la aplicación de Nuestros Valores de Orientación al Cliente y Eficiencia, hacemos seguimiento y llevamos métricas de eficacia del desempeño de nuestros equipos al medir el nivel de retrabajo por deficiencias en la aplicación de la Definición de “Hecho” y sus criterios de aceptación.
En lo que respecta a la realización de tareas, la clave es que todo el equipo (tanto interno como de parte del cliente) estén en sintonía y entendimiento sobre qué se necesita para que un desarrollo, característica y funcionalidad está completamente finalizadas, permitiendo avanzar con el proyecto como para levantar la bandera para señalar que algo falta.
