Metodologia SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto y por ello Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

Proceso:

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su costey quedan repartidos en iteraciones y entregas.  

Las actividades que se llevan a cabo en Scrum son las siguientes:

Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.
2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas.

Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:

• ¿Qué he hecho desde la última reunión de sincronización?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.

• Elimina los obstáculos que el equipo no puede resolver por sí mismo.
• Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos (para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o replanifican los objetivos del proyecto para maximizar la utilidad de lo que se desarrolla y el retorno de inversión.

Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.

Base de datos NoSQL

Cuándo pensamos en bases de datos relacionales a nuestra mente suelen acudir los mismos nombres y en la parte comercial tenemos Oracle y Microsoft SQL Server. Del lado del software libre, tenemos opciones como Postgre SQL o MySQL. 

Aunque cada una tiene sus peculiaridades, para un desarrollador no es difícil elegir entre un sistema y otro y al final todo son tablas, columnas, claves primarias, y sobre todo, consultas SQL. La decisión de cuál elegir, se basará en sus características y precio.

Si hablamos de bases de datos NoSQL, la cosa se complica.

 A día de hoy existen unos 150 sistemas de bases de datos NoSQL y elegir uno de ellos puede ser muy difícil, ya que ninguno ha obtenido todavía la fama que sí han conseguido las bases de datos relacionales.

Pero el problema principal que encontramos, es que aunque todas se denominan NoSQL, en realidad hay diferentes tipos.

Orientadas a documentos

Son aquellas que gestionan datos semi estructurados. Es decir documentos. Estos datos son almacenados en algún formato estándar como puede ser XML, JSON o BSON.

Son las bases de datos NoSQL más versátiles. Se pueden utilizar en gran cantidad de proyectos, incluyendo muchos que tradicionalmente funcionarían sobre bases de datos relacionales.

En esta categoría encontramos:

• MongoDB: probablemente la base de datos NoSQL más famosa del momento. En octubre del año pasado, MongoDB conseguía 150 millones de dólares en financiación, convirtiéndose en una da las startups más prometedoras. Algunas compañías que actualmente utilizan MongoDB son Foursquare o eBay.
• CouchDB: es la base de datos orientada a documentos de Apache. Una de sus interesantes características es que los datos son accesibles a través de una API Rest. Este sistema es utilizado por compañías como Credit Suisse y la BBC.

Orientadas a columnas

Este tipo de bases de datos están pensadas para realizar consultas y agregaciones sobre grandes cantidades de datos. Funcionan de forma parecida a las bases de datos relacionales, pero almacenando columnas de datos en lugar de registros.

En esta categoría encontramos:

• Cassandra: incluida en esta sección, aunque en realidad sigue un modelo híbrido entre orientada a columnas y clave-valor y es utilizada por Facebook y Twitter.
• HBase: Escrita en Java y mantenida por el Projecto Hadoop de Apache, se utiliza para procesar grandes cantidades de datos. La utilizan Facebook, Twitter o Yahoo.

De clave valor

Estas son las más sencillas de entender. Simplemente guardan tuplas que contienen una clave y su valor. Cuándo se quiere recuperar un dato, simplemente se busca por su clave y se recupera el valor.

En esta categoría encontramos:

• DynamoDB: desarrollada por Amazon, es una opción de almacenaje que puedemos usar desde los Amazon Web Services. La utilizan el Washington Post y Scopely.
• Redis: desarrollada en C y de código abierto, es utilizada por Craiglist y Stack Overflow (a modo de cache).

En grafo

Basadas en la teoría de grafos utilizan nodos y aristas para representar los datos almacenados. Son muy útiles para guardar información en modelos con muchas relaciones, como redes y conexiones sociales.

En esta categoría encontramos:

• Infinite Graph: escrita en Java y C++ por la compañía Objectivity. Tiene dos modelos de licenciamiento: uno gratuito y otro de pago.
• Neo4j: base de datos de código abierto, escrita en Java por la compañía Neo Technology. Utilizada por compañías como HP, Infojobs o Cisco.

Como veis los tipos son muy diferentes. Si tenéis pensado en usar algún sistema NoSQL, aseguraros bien de qué es lo que necesitáis.

Patrones de arquitectura

Los patrones arquitectónicos, o patrones de arquitectura, también llamados arquetipos ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. Dan una descripción de los elementos y el tipo de relación que tienen junto con un conjunto de restricciones sobre cómo pueden ser usados. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. En comparación con los patrones de diseño, los patrones arquitectónicos tienen un nivel de abstracción mayor.

Aunque un patrón arquitectónico comunica una imagen de un sistema, no es una arquitectura como tal. Un patrón arquitectónico es más un concepto que captura elementos esenciales de una arquitectura de software. Muchas arquitecturas diferentes pueden implementar el mismo patrón y por lo tanto compartir las mismas características. Además, los patrones son a menudo definidos como una cosa estrictamente descrita y comúnmente disponible. Por ejemplo, la arquitectura en capas es un estilo de llamamiento-y-regreso, cuando define uno un estilo general para interaccionar. Cuando esto es descrito estrictamente y comúnmente disponible, es un patrón.

Uno de los aspectos más importantes de los patrones arquitectónicos es que encarnan diferentes atributos de calidad.

MVC (modelo - vista - controlador)

De manera genérica, los componentes de MVC se podrían definir como sigue:

• El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al 'modelo' a través del 'controlador'.
• El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta el 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo' (véase Middleware).
• La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario), por tanto requiere de dicho 'modelo' la información que debe representar como salida.

Capas

El Patrón de arquitectura por capas es una de las técnicas más comúnes que los arquitectos de software utilizan para dividir sistemas de software complicados. Al pensar en un sistema en términos de capas, se imaginan los principales subsistemas de software ubicados de la misma forma que las capas de un pastel, donde cada capa descansa sobre la inferior. En este esquema la capa más alta utiliza varios servicios definidos por la inferior, pero la ultima es inconsciente de la superior. Además, normalmente cada capa oculta las capas inferiores de las siguientes superiores a esta.

Los beneficios de trabajar un sistema en capas son:

– Se puede entender una capa como un todo, sin considerar las otras.
– Las capas se pueden sustituir con implementaciones alternativas de los mismos servicios básicos
– Se minimizan dependencias entre capas.
– Las capas posibilitan la estandarización de servicios
– Luego de tener una capa construida, puede ser utilizada por muchos servicios de mayor nivel.

La imagen que se muestra a continuación presenta el esquema de una arquitectura siguiendo este patrón:

A continuación se describen las tres capas principales de un patrón de arquitectura por capas:

1. Capa de Presentación: Referente a la interacción entre el usuario y el software.  Puede ser tan simple como un menú basado en líneas de comando o tan complejo como una aplicación basada en formas.  Su principal responsabilidad es mostrar información al usuario, interpretar los comandos de este y realizar algunas validaciones simples de los datos ingresados.

2. Capa de Reglas de Negocio (Empresarial): También denominada Lógica de Dominio, esta capa contiene la funcionalidad que implementa la aplicación.  Involucra cálculos basados en la información dada por el usuario y datos almacenados y validaciones.  Controla la ejecución de la capa de acceso a datos y servicios externos.  Se puede diseñar la lógica de la capa de negocios para uso directo por parte de componentes de presentación o su encapsulamiento como servicio y llamada a través de una interfaz de servicios que coordina la conversación con los clientes del servicio o invoca cualquier flujo o componente de negocio.

3. Capa de Datos: Esta capa contiene la lógica de comunicación con otros sistemas que llevan a cabo tareas por la aplicación.  Estos pueden ser monitores transaccionales, otras aplicaciones, sistemas de mensajerías, etc.  Para el caso de aplicaciones empresariales, generalmente esta representado por una base de datos, que es responsable por el almacenamiento persistente de información.  Esta capa debe abstraer completamente a las capas superiores (negocio) del dialecto utilizado para comunicarse con los repositorios de datos (PL/SQL, Transact-SQL, etc.).

Microservicios

Si los servicios son independientes y aislados, ¿cómo compartir código entre ellos? Bueno, es cuestión de encontrar el punto de equilibrio. Lo positivo de compartir código entre servicios es que permite reutilizar funcionalidades existentes y mantener el principio DRY (no escribir código duplicado), lo negativo es que aumenta el acoplamiento entre los servicios. Una solución es compartir solamente las librerías de utilidades técnicas y las de funcionalidades comunes, estas se pueden configurar como servicios independientes a los cuales otros servicios pueden llamar. Entonces, el siguiente punto a resolver a continuación es la comunicación entre servicios.

La comunicación entre estos microservicios puede implementarse de dos maneras, mediante peticiones HTTP y a través de cola de mensajes (Azure Service Bus, RabbitMQ, Kafka Apache, etc.). Básicamente, HTTP es comunicación directa y debe usarse cuando se desea una respuesta inmediata del otro servicio. Por otra parte, el mecanismo publicación/suscripción de la cola de mensaje tiende a ser asíncrono.

Finalmente, como los servicios son muy granulares, las aplicaciones cliente generalmente necesitan interactuar con múltiples servicios para obtener los datos que necesitan. Para permitir cambios en los servicios sin afectar a los clientes, se utiliza una API Gateway. API Gateway es una capa abstracta que oculta a todos los microservicios, dejando un único Endpoint para que los clientes se comuniquen. Las solicitudes que lleguen al Gateway serán procesadas/enrutadas hacia los servicios específicos. El Gateway también nos permite monitorear fácilmente el tráfico y uso de los servicios.

          

Arquitectura Monolítica                                         Arquitectura de micrositios

¿LAS VENTAJAS?

Mientras que la arquitectura monolítica funciona bien en escenarios tradicionales, en el mundo de hoy, donde las aplicaciones necesitan desplegar nuevas funcionalidades frecuentemente (en términos de horas) y estar siempre en línea con alta disponibilidad, este estilo arquitectónico no cumple con las expectativas. Un cambio sencillo en un componente requiere pruebas de regresión, recompilar y volver a desplegar toda la aplicación. Y dado que todo se ejecuta en el mismo proceso, una excepción no controlada puede afectar todo el sistema monolítico.

Por el contrario, la arquitectura de microservicios es mucho más flexible y resistente:

1. Los servicios en sí son muy simples de construir, pues se centran en hacer solamente una cosa bien, de forma que son fáciles de probar y se puede asegurar mayor calidad.

2. Cada servicio puede construirse con las tecnologías y herramientas más adecuadas, permitiendo “Polyglot Programming” (las aplicaciones se deben escribir en una mezcla de lenguajes para explotar sus mejores características). La elección inicial de una tecnología no nos debería limitar durante el ciclo de vida del proyecto.

3. Múltiples equipos de desarrolladores pueden trabajar independientemente bajo esta arquitectura. Esto es ideal para lograr el “continuous delivery”, pues permite actualizaciones frecuentes mientras el resto del sistema se mantiene estable.

4. En el caso que un servicio deje de funcionar, solo afectará las partes que dependen directamente de él (si las hay). El resto seguirá funcionando bien.

Aspectos a prestar atención

Al igual que con los demás patrones y arquitecturas, la arquitectura de microservicios no es la solución absoluta a todos los problemas. Aunque soluciona muchos problemas de otros estilos arquitectónicos, también presenta nuevos inconvenientes que debemos considerar.

Por tener muchas partes modulares, los microservicios están en un nivel de complejidad distinto a la arquitectura monolítica. Se requiere una gran habilidad en DevOps para desplegar y mantener una aplicación de microservicios en producción. Mientras que la aplicación monolítica puede desplegarse en un pequeño clúster de servidores de aplicación, cada uno de los microservicios requiere su propio cluster para conmutación por fallas y resiliencia. También debe considerase adicionar balanceadores de carga y una capa de mensajería entre los clusters. Se requiere escribir los scripts de liberación automática para poder aprovechar la opción de “continuous delivery”.

Los sistemas de microservicios son distribuidos por naturaleza y como tal, son difíciles de construir. Un simple llamado (call) tradicional ahora podría convertirse en un llamado de procedimiento remoto (RPC), un REST o un mensaje asincrónico. Los desarrolladores necesitan pensar más en problemas como la latencia entre servicios, tolerancia a fallos, control de versiones, etc. Aunque siempre es bueno tener estas propiedades en el sistema, con toda seguridad su construcción requiere más esfuerzo.

Y mientras que los servicios son más fáciles de probar por sí mismos, las pruebas de integración end-to-end son más difíciles. Como el flujo de código es complejo, puede ser difícil identificar en qué parte de la cadena se presentan los errores.

Modelo–vista–presentador

En MVP el presentador asume la funcionalidad del "intermediario". En MVP, toda lógica de presentación es colocada al presentador.

MVP es un patrón arquitectónico de interfaz de usuario diseñada para facilitar pruebas de unidad automatizada y mejorar la separación de inquietudes en lógica de presentación:

• El modelo es una interfaz que define los datos que se mostrará o no actuado en la interfaz de usuario.
• El presentador actúa sobre el modelo y la vista. Recupera datos de los repositorios (el modelo), y los formatea para mostrarlos en la vista.
• La vista es una interfaz pasiva que exhibe datos (el modelo) y órdenes de usuario de las rutas (eventos) al presentador para actuar sobre los datos.

Normalmente, la vista de implementación instancia el objeto de presentador en concreto, proporcionando una referencia a él.

El grado de la lógica permitida en la vista varía entre las diferentes implementaciones. En un extremo, la vista es totalmente pasiva, reenviar todas las operaciones de interacción para el presentador. En esta formulación, cuando un usuario activa un método de evento de la vista, que no hace más que invocar un método del presentador que no tiene parámetros y no devuelve ningún valor. El presentador recupera entonces datos de la vista a través de los métodos definidos por la interfaz de vista. Por último, el presentador opera en el modelo y actualiza la vista con los resultados de la operación. Otras versiones de modelo-vista-presentador permiten cierta libertad con respecto a qué clase maneja una determinada interacción, evento o comandos. Esto suele ser más adecuado para arquitecturas basadas en la Web, donde la vista, que se ejecuta en el navegador de un cliente, puede ser el mejor lugar para manejar una interacción o comando en particular.

Desde un punto de vista de capas, la clase de presentador podría considerarse como perteneciente a la capa de aplicación en un sistema de arquitectura multicapa, pero también pueda ser visto como capa de presentador de su propiedad entre la capa de aplicación y la capa de interfaz del usuario.

Entrada sobre ux (experiencia de usuario)

Experiencia de usuario UX

¿Qué es la Experiencia de Usuario (UX)?

Es importante comenzar señalando que no existe una única definición común del término. Todos los que estamos involucrados en este ámbito de trabajo, podríamos formular una o varias definiciones singulares, y probablemente, todas ellas serían correctas.

Como disciplina, es un concepto de múltiples dimensiones que agrupa la Funcionalidad, la Usabilidad, el Diseño Interacción (IxD), la Arquitectura de la Información, Estrategia de contenidos,  la Interfaz de Usuario (UI), el Diseño Visual, el Diseño Emocional entre otros.

Tiene su historia y raíces en el Diseño Centrado en el Usuario (DCU) con el que comparte muchos rasgos. Es un enfoque de diseño cuyo proceso está dirigido por la información sobre las personas que van a hacer uso del producto. Básicamente se trata de dotar a un producto con la funcionalidad adecuada para usuarios concretos. Se trata de una manera de “humanizar” el producto, objeto, sitio web, app, máquina, artefacto… La Experiencia de Usuario va en esa dirección y  más allá de eso.

UX es la metodología  que actualmente condiciona las acciones que una empresa, organización, colectivo o equipo toma a la hora de crear o consolidar el diseño de sus servicios y productos.

Consejos para una buena experiencia de usuario

• Hacer una web que responda a los intereses del cliente y no de quien la diseña.
• Captar la atención del usuario y hacerle fácil e intuitiva la navegación por la página web.
• Convertir la visita de un usuario en tráfico recurrente. Es decir, vuelve a la página de forma asidua.
• Arquitectura de la información bien organizada y que no haga pensar demasiado al usuario. Si le hacemos dudar, mal.
• Contenidos atractivos, breves, concisos e interesantes.
• Navegación simple, sin sobresaltos. Necesidad de encontrar la información que busca de forma fácil.
• Adelantarse y evitar posibles errores. Si en un punto determinado puede aparecer un error, intentar evitarlo es fundamental.
• No debe primar el diseño por encima de usabilidad y navegación fácil. Si se consigue con un buen diseño mejor.

Si consigues los objetivos propuestos en tu web, todo hace indicar que cuentas con una página web que cumple los patrones de experiencia de usuario definidos.

Por ejemplo, de nada sirve estar en primera posición en los buscadores, si después la conversión es mínima porque no existe una buena experiencia de usuario.

Por tanto, para lograr una buena experiencia de usuario debe primar la calidad de lo que se ofrece (producto o servicio), unido a unos buenos contenidos en el site, una perfecta navegación que le ayude al usuario y un diseño web que vaya en línea con lo que el cliente potencial de una marca espera conseguir.

La experiencia de usuario no tiene en cuenta sólo la usabilidad o la tecnología utilizada, sino que se centra también en las percepciones que deja en un usuario. Emociones y sensaciones también se deben tener en cuenta a la hora de establecer un balance positivo o negativo por parte de un usuario en su relación con una página web.

La interacción que tenga el usuario con el dispositivo va a generar una percepción positiva o negativa del diseño web. De igual manera, la confianza que genere la marca también influye en una correcta experiencia de usuario.