Saraclip

Always learning about UX, Agile & Psychology

Agile

Roles en Scrum

, , , ,

A continuación voy a hablar de los roles que existen dentro del Scrum Team y que funciones y deberes tiene cada uno.

Scrum no tiene un rol llamado «Project Manager».

Scrum Team

Scrum Team

El Scrum Team se compone de 3 perfiles:

  1. Product Owner (1 persona)
  2. Development Team (Varias personas)
  3. Scrum Master (1 persona)

El Scrum Team debe ser auto-organizado y multifuncional. Lo primero para saber elegir cual es la mejor manera de hacer el trabajo, mejor que siendo dirigidos por otros externos. Multifuncionales porque el equipo debe tener las comptencias necesarias para realizar el trabajo sin depender de otras personas que no formen parte del equipo.

El equipo perfecto en Scrum está diseñado para optimizar flexibilidad, creatividad y productividad.

Es decir, debe ser capaz de poder entregar y publicar (si ha sido pasada a Done) esa nueva release lanzada.

No puede depender de otros equipos para subir a producción algo definido como «Done».

El equipo entrega productos cíclica e incrementalmenre, maximizando las oportunidades para obtener feedback. Entregas incrementales de productos con la etiqueta «Done» (Hecho) aseguran potenciales versiones usables del producto están siempre en activo.

Product Owner

El Product Owner , PO es el responsable de maximizar el valor del producto y el trabajo del Development Team (Equipo de desarrollo). Como se realiza esto, puede variar dependiendo de la empresa, los Scrum Teams y los inddividuos.

El Product Owner es la única persona responsable para gestionar el Product Backlog.

Entre las tareas que se realizan en esa gestión se encuentran:

  • Nombrar claramente los ítems del Product Backlog.
  • Ordenar los items en el Product Backlog priorizándolos para lograr los mejores objetivos y resultados.
  • Optimizar el valor del trabajo que realiza el Development Team.
  • Asegurarse de que el  Product Backlog sea visible, transparente y claro para todos, y que muestra en que va a trabajar el Scrum Team.
  • Asegurarse de que el Development Team comprende perfectamente los elementos del Product Backlog.

El PO puede hacer el trabajo anterior o hacer que lo haga el equipo de desarrollo, pero en ambos casos será el Product Owner responsable.

Seguir leyendo «Roles en Scrum»

Aprendiendo Scrum

, , , , ,

Scrum es un framework (marco de trabajo) dentro del cual las personas pueden abordar problemas complejos, a la vez que ofrecen productos de manera eficiente y creativa del más alto valor posible.

Scrum

Web de scrum.org

Scrum proviene del trabajo de Ikujiro Nonaka e Hirotaka Takeuchi cuando publicaron «The New New Product Development Game» en Harvard Business Review (HBR) en 1986.

Su forma final proviene de “Scrum Development Process” presentado por Ken Schwaber en OOPSLA 95. Tanto Ken Schwaber como Jeff Sutherland son considerados sus creadores oficiales.

Aunque para Takeuchi y Nonaka, Scrum está relacionado indirectamente con el software. Tiene que tiene más que ver con el liderazgo y el funcionamiento de las principales compañías del mundo, tal y como aparece su artículo en HBR llamado «The Big Idea: The Wise Leader».

En sí mismo, no es un proceso o una técnica, sino que como marco de trabajo, para desarrollar complejos productos de software, pudiendose emplear varias procesos y técnicas. Presenta varios componentes, roles, eventos, artefactos y reglas, que tienen un propósito muy claro y son esenciales para el éxito de Scrum.

Sirve especialmente para ver de forma clara la eficacia relativa de las prácticas de desarrollo y gestión de producto para que se pueda mejorar.

Si de verdad se quiere lograr un cambio en la forma de trabajar, éste debe contar con el apoyo de «los de arriba».

Los stakeholders deben respaldar al Product Owner con conocimientos e información de los productos o servicios a desarrollar y apoyar al Scrum Master para provocar un cambio organizacional que fomente el empirismo, la autoorganización, la inteligencia y el poder decidir de forma inteligente cuando el producto está listo para ser lanzado.

Los 3 pilares de Scrum

Dentro de los principios Agile, vivimos en un mundo de constante cambio e incertidumbre por lo que es imposible predecir a futuro cual va a ser la siguiente innovación.

Scrum se basa en la teoría empírica de control de procesos. El empirismo afirma que el conocimiento proviene de la experiencia y toma decisiones basadas en lo que se conoce.

Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad del mundo en el que vivimos y controlar el riesgo.

Tres pilares sostienen la implementación del control del proceso empírico:

Seguir leyendo «Aprendiendo Scrum»

Principios Lean UX para guiar el proceso

, , , , , , ,

Una vez que hemos hablado qué cultura y organización debe existir en la empresa y los equipos, vamos a ver cómo deben trabajar.

Trabaja en bloques pequeños para reducir el riesgo

Otro principio fundamental heredado de Lean Manufacturing es la práctica de dividir el trabajo en pequeñas unidades, en su caso con el objetivo de reducir el inventario y obtener la máxima calidad.

Trasladado a Lean UX significa que sólo la cantidad de trabajo necesario se realizará para poder avanzar hacia delante, validando la hipótesis y continuando el desarrollo en base a lo aprendido. Con ello contribuimos a otro de los principios, el de reducir el desperdicio.

Descubrimiento continuo

Para realizar este proceso debemos involucrar al usuario o cliente en el proceso durante la fase de diseño y desarrollo de las ideas.

Muchas veces (en el caso de que se haga) este contacto, en vez de hacerse de forma regular se realiza al final, con el trabajo ya desarrollado. Por ello se deben definir encuentros seguidos mediante métodos cuantitativos o cualitativos que permitan obtener el feedback para la validación.

Descubrimiento continuo

El objetivo es claro: entender que hacen los usuarios con tus productos y por qué lo están haciendo.

Por ello la investigación debe hacerse de forma regular y con todo el equipo implicado.

Este segundo punto (con todo el equipo implicado) es muy importante ya que normalmente sólo los UX Research hacen esta parte teniendo posteriormente que explicar los resultados al resto del equipo.

Al introducir a todo el equipo en la investigación consigues 3 cosas:

  1. Que desarrollen una mayor empatía por el usuario y sus problemas
  2. Entendimiento compartido de lo que ocurre y por que luego se van a tomar ciertas decisiones.
  3. Reducción de la necesidad de generar documentación que explique los descubrimientos de la investigación

GOOB (Getting out of the building)

Con esta expresión que significa literalmente “salir fuera del edificio”, Steve Blank, profesor de Stanford, quiere conseguir que los equipos salgan fuera de las salas de reuniones con sus interminables divagaciones y suposiciones, y que den a los potenciales usuarios la oportunidad de proveer feedback real tan pronto como sea posible.

Gracias a esta dosis de realidad verás que ideas no funcionan antes de malgastar más recursos en ellas.

Exponer el trabajo

Con este principio, se quiere que las ideas salgan de la cabeza o de las pantallas de las personas y se pongan a la vista de todo el equipo. Esto permite ver el estado del trabajo, creando un flujo de información compartida, de nuevas ideas y sugerencias que surgen en base a lo visto…

Seguir leyendo «Principios Lean UX para guiar el proceso»

Principios Lean UX para guíar la organización de equipos

, , , , , ,

Los principios en los que se basa Lean UX se agrupan en 3 bloques. Cada uno sirve para guiar:

  1. La organización de equipos
  2. El proceso
  3. La cultura

Gracias ellos iremos viendo las ventajas que conlleva implementar Lean UX en tu organización y como esta se modificará conviertiendose en un lugar abierto, transparente, que aprovecha el conocimiento y la entrega de todos para conseguir los mejores resultados.

En ellos se basarán las herramientas y técnicas para lograr mejorar la colaboración, lograr entregar mejores productos y servicios de forma más rápida y con el menor gasto de recursos usando los conocimientos de todos los implicados y basando las decisiones en pruebas reales.

Y es que como dice Jeff Gothelf en su libro Lean Startup: «Get out of the deliverables business», en castellano: olvidémonos de centrar el negocio en las entregas y centrémonos en los que de verdad importa, hacer disfrutar a nuestros clientes con una experiencia memorable.

Principios Lean UX para guíar la organización de equipos

Equipos multifuncionales

Con esta palebreja lo que se refiere es que los equipos deben estar formados por aquellas personas con conocimientos necesarios en ese momento del proceso: desarrolladores, product management, testers, diseñadores visuales y de interacción, gestores de contenidos, marketing…

Para crear un gran producto es necesaria la suma de todos los conocimientos y la colaboración entre todas las disciplinas.

El todo es mayor que la suma de sus partes

Cuando un equipo está formado por personas de diferentes perfiles, se obtienen mejores soluciones ya que cada problema es visto desde un punto de vista diferente, aportando una gran diversidad.

Los miembros del equipo además están en contínuo contacto, por lo que poseen todo el conocimiento de lo que está sucediendo y lo que va a haserse al contrario que en organizaciones donde todo esta compartimentado. Gracias ello conseguimos una gran colaboración desde el inicio del proyecto logrando una mayor eficiencia de equipo, y trabajadores mucho más implicados en el proyecto.

Equipos pequeños, dedicados y juntos

Lo ideal: no más de 10 personas, focalizadas en el mismo problema y a ser posible en la misma ubicación. ¿Por qué?

Los equipos muy grandes tienen problemas para organizarse y compartir la misma información.

Los equipos pequeños generan un mayor sentimiento de camadería lo que genera mayor implicación en el proyecto y en las personas que lo están creando juntas.

Building a team

Imagen obtenida de aquí

Trabajando además en el mismo y único proyecto se consigue que estén centrados al máximo en las mismas prioridades y elimina las odiosas dependencias sobre otros equipos.

Autosuficientes y con poder para decidir

Si queremos obtener de forma rápida algo con lo que poder testear una suposición necesitamos que el equipo tenga todas las capacidades necesarias para trabajar sin dependencias externas.

Seguir leyendo «Principios Lean UX para guíar la organización de equipos»

Poka-Yokes, heurísticos de usabilidad y affordances

, , , ,

Un poka-yoke (en japonés, ポカヨケ), es un término japonés que significa: Poka: “error no intencionado, equivocación…” y Yoke: “evitar”, es decir, “evitar equivocaciones”.

Es una técnica de calidad que se aplica con el fin de evitar errores en la operación de un sistema, introducida por el ingeniero japonés Shigeo Shingo en Toyota (1960), basada en que la causa de los errores estaba en los trabajadores, y que los defectos en las piezas fabricadas se producían porque no se corregían.

Anteriormente ya existían precedentes de poka-yokes, pero fue en ese momento cuando se consolidó este método como una técnica preventiva de control de calidad.

Para Shingo, los defectos de producción son la consecuencia de la cadena de errores generados por los trabajadores, por lo que no tenía sentido analizar el producto final cuando el defecto se producía durante el proceso de trabajo.

Es decir, el buscaba mejorar la calidad en su origen, actuando sobre la fuente del defecto, en lugar de tener que realizar correcciones, reparaciones y controles de calidad posteriores.

Para ello ideo 2 métodos sobre los que basarse para mejorar el proceso de trabajo y evitar errores.

  1. Control: Conseguir la imposibilidad o la dificultad de que el operario pueda equivocarse en proceso diseñando un sistema que lo impida (¿Te suena el término «affordance» introducido en el campo de HCI por Donald Norman en 1998 (propiedad en la cual las características físicas de un objeto o entorno, influencian en su función y uso)?).
  2. Advertencia: asumiendo que el error puede suceder, se diseña in dispositivo que dirija la atención hacia él para reaccionar y poder corregirlo.

¿No os suena esto a los principios heurísticos de usabilidad?

  • Conocimiento del estatus del sistema: el sistema debería siempre mantener a los usuarios informados de lo que está pasando, ofreciendo feedback en un tiempo razonable.
  • Control y libertad del usuario: cuando elegimos funciones del sistema por error necesitamos una “salida de emergencia” sin tener que ir a través de una serie de pasos complicados.
  • Prevenciones de errores: mejor que buenos mensajes de error, lo ideal sería un diseño que previniera que ocurrieran los problemas.

Hoy en día, es muy común ver dispositivos diseñados a prueba de error, no solo dentro de una empresa de producción o de servicio, sino en nuestro día a día, siendo una ventaja para todos los usuarios, ya que además de evitarse errores, pueden salvar vidas.

affordance

Imagen extraída de http://www.pdcahome.com/poka-yoke/

¿Algunos ejemplos?

Seguir leyendo «Poka-Yokes, heurísticos de usabilidad y affordances»

Cambiando la metodología de trabajo (o al menos intentarlo)

, , , ,

He trabajado en varias empresas que querían modificar su proceso de desarrollo de producto. Algunas (2013) querían implantar una nueva metodología (Agile en este caso) y otras ya la tenían, pero necesitaban un pequeño reajuste para adecuarla a su cultura de empresa.

Y es que desde mi punto de vista, cualquier metodología o proceso de trabajo tiene sus herramientas e indicaciones, pero no siempre sirven al 100%, sino que debe adaptarse a lo que la empresa necesita en ese momento.

Son una base sobre la que trabajar para encontrar el proceso que realmente funcione para cada grupo de trabajo.

En ambos casos las empresas contrataron los servicios de una persona que facilitase y guiase el cambio. En una el proceso duraba X meses, para luego la empresa continuar por su cuenta con lo aprendido, mientras que en la otra la fase de implantación duraba X meses, pero prosiguiendo después el trabajo con el facilitador.

Es decir, (o por lo menos lo que yo creo que es lo ideal) esa metodología por la que se estaba apostando no era algo cerrado, inmutable para siempre, sino que seguiría evolucionado en el tiempo.

En ambas empresas, como muchos imaginaréis, el proceso no fue sencillo.

Para mi existen 2 puntos claves en el proceso:

  1. ¿El cambio viene impuesto desde arriba o es algo en lo que todo el equipo cree y apuesta?
  2. Como en cualquier materia, la constancia y repetición son claves para hacer algo bien.

Si el cambio viene impuesto desde la dirección, va a ser muy difícil que suceda si los principales implicados no lo aprueban. El facilitador se va a encontrar con un muro muy difícil de romper, no digo que imposible, pero muy complicado.

Lo ideal es partir de una base en la que la mayor parte cree que es necesario el cambio porque lo existente no funciona. O funciona pero podría ir mejor.  Pero aun siendo algo querido por todos, cambiar unas costumbres suele ser muy complicado.

No olvidemos que estamos trabajando con personas.

Personas que pueden llevar 5, 10, 15, 20 años trabajando de una misma forma. Personas que han luchado por sacar adelante un proyecto. Personas que no se han sentido escuchadas. Personas que van agobiadas porque tienen unos plazos de entrega. Personas con un baggage emocional hacia la empresa y otros compañeros.

Seguir leyendo «Cambiando la metodología de trabajo (o al menos intentarlo)»

Getting Things Done® (GTD®)

, , ,

Getting Things Done® (GTD®) es una metodología para ser más productivo sin estrés. Escrita por David Allen y publicada en un libro en 2001, en un principio estaba dirigida a  altos directivos, pero su uso puede ser aplicado a cada aspecto de tu vida.

Your mind is for having ideas, not holding them®

(David Allen)

Se basa en la idea de que nuestra mente es para generar ideas, no para mantenerlas, con lo que sino almacenamos de forma correcta las ideas, pensamientos… que vamos teniendo, el espacio que ocupan no permitiendo entrar a otras o el miedo a olvidarnos de ellas, nos genera un entimiento de estrés constante.

Más que un conjunto de consejos para la gestión del tiempo y la organización, GTD® es un sistema de gestión total. Allen crea un modelo coherente para almacenar elementos clave, los cuales aun pueden ser necesarios para nosotros, tanto para su uso futuro como presente.

El GTD es para no hacer, o más bien hacer sólo lo que vale la pena hacer.

Se trata de reducir la presión entrante de tareas por hacer aparcándolas en un sistema de almacenamiento auxiliar para centrarse en hacer sólo algunas.

En este mundo de información, constantemente nos están llegando nuevos datos, proyectos, ideas… que procesar que se suman a los que ya teníamos. El propósito de su proceso de gestión de flujo de trabajo es facilitarnos el hacer buenas elecciones sobre lo que estamos haciendo en ese momento.

GTD Diagram

 

Regla de los 2 minutos

A mi modo de ver, lo que cuenta Allen es de sentido común, y seguramente muchas de las cosas ya las haceis en vuestro día a día. Un ejemplo muy sencillo es la regla de los 2 minutos descrita en el diagrama superior.

La idea es muy sencilla. Cuando algo te llega, lo primero que te preguntas es si puedes hcer algo con eso. Si la respuesta es si, piensas en cual es la siguiente acción que quieres hacer con eso. Y si esa acción te cuesta menos de 2 minutos, la haces en ese momento, sino la delegas o la pospones apuntándola en un calendario si es para hacer en una fecha específica o en tu sistema de siguientes acciones.

GTD® en 5 pasos

La metodología se basa en 5 pasos que son los que naturalmente suceden en nuestra mente con las acciones más simples, solo que muchas veces lo hacemos de forma automática (Natural Planning Model) y no le ponemos nombres.

Seguir leyendo «Getting Things Done® (GTD®)»

Esto va de siglas: PMBOK® vs SCRUM

, , ,

Últimamente, durante este pasado año, he estado leyendo bastante sobre gestión de proyectos. Como en todo, hay un montón de información, con siglas y definiciones que pueden volver loca a cualquier persona.

En esta caso nos centraremos en las referidas a PMBOK® y SCRUM, cuyo error más común es pensar que PMBOK® es una metodología de gestión de proyectos, cuando es un estándar que recoge «the best practices», es decir, las mejores prácticas del sector.

Es el Project Manager quien decide que procesos aplica, con que nivel de detalle y ver que metodología escoge para la gestión, ya sea ágil como SCRUM o tradicional.

Web de Scrum.org

Imagen de la web de srcum.org

No son opciones excluyentes, sino complementarias, gestionando un proyecto teniendo en cuenta el marco definido en el PMBOK® pero aplicando metodologías ágiles para su desarrollo.

Más lío viene aun cuando nos metemos en el tema de certificaciones con tantas siglas ya que dependen de la entidad que las gestiona:

  • Certificación PMP® (Project Management Professional) del PMI®
  • Certificación PMI-ACP® (PMI Agile Certified Practitioner) del PMI®
  • Certificación PSM I (Professional Scrum Master) de Scrum.org
  • …

The Scrum Framework

SCRUM, por su parte es un método de gestión de proyectos con un enfoque ágil, especialmente útil en proyectos de desarrollo de software, pero que también se puede aplicar a otro tipo de proyectos y sectores. Aquí puedes descargarte de forma gratuíta la guía de Scrum escrita por Ken Schwaber and Jeff Sutherland, las persona que definieron el método.

Igual que SCRUM encontramos otras metodos ágiles como:

  • Extreme Programming (XP)
  • Lean Development
  • Kanban Development
  • Feature Driven Development (FDD)
  • Dynamic systems development method (DSDM)
  • Crystal Clear

Scrum.org ofrece entre otras la Certificación Professional Scrum Master™ (PSM) con 3 niveles de evaluaciones profesionales Scrum Master (fundación, intermedio y avanzado) que validan y certifican sus conocimientos de Scrum y la capacidad de aplicar ese conocimiento.

PMBOK® (Project Management Body of Knowledge)

El PMBOK®, en castellano, Guía de los fundamentos para la dirección de proyectos, es un estándar de gestión de proyectos que recoge las mejores prácticas del sector, gestionado y actualizado periódicamente por el PMI®.

Actualmente se encuentra en su 5ª Edición, y su 6ª Edición, se publicará oficialmente en septiembre de 2017.

Seguir leyendo «Esto va de siglas: PMBOK® vs SCRUM»

Meetup de Juegos y dinámicas ágiles

,

El pasado día 7 de junio nos juntamos en las oficinas de Flywire para una nueva reunión del grupo de Agile Levante, organizado por Emma López (@hell03610).

El taller consistía en la realización de dos dinámicas lúdicas, aprendiendo de ellas diferentes tipos de problemas que surgen en entornos de desarrollo.

Comunicación y visión compartida

La primera dinámica se realizaba en parejas. Una persona era el constructor y la otra el gestor (creo, no recuerdo muy bien los nombres). La idea era cambiar en base a los roles que ejecutamos en nuestro día a día para entender el papel de la otra persona.

Juegos agile

Emma le dio a cada gestor unas instrucciones para hacer una figura de origami (la conocida ranita) para que se las dictará al constructor. El constructor, apoyado en una mesa, con un folio, y de espaldas al gestor, no podía verlas no podía tampoco hablar con el gestor.

Así mismo el gestor tampoco podía ver lo que iba haciendo el constructor en base a sus indicaciones, con lo cual, imaginaos lo que salió de ahi. Ningún equipo consiguió finalizar algo similar a una ranita 🙁

En la segunda ronda, el gestor podía ver lo que realizaba el constructor e ir guiándole en consonancia a los pasos que daba. En este fase, sólo 2 equipos acabaron las ranitas.

Y en la tercera ronda, tanto el gestor como el constructor, veían las instrucciones. El gestor ayudaba al constructor guiándole y explicándoselas. En este caso todos los equipos acabaron las ranitas y a una mayor velocidad.

De este juego, se extrae la importancia de compartir todos los miembros del equipo la misma visión, y que está quede de alguna manera reflejada de una forma visual, ya que las palabras dependiendo de quien las interprete pueden tener diferentes significados.

Y es como dice Dani Latorre en este post sobre Una de BDD, Specification by Example y Cucumber: «Muchos problemas cuando desarrollamos software surgen de los malentendidos de comunicación entre los diferentes miembros del equipo. »

Estimación, competitividad y la importancia del testeo

En el segundo juego nos dividimos en 2 equipos. Emma nos dio 3 tipos de aviones diferentes a construir en papel, cada uno en folios de un color. Dependiendo de su dificultad cada tipo valía unos puntos u otros.

En una reunión inicial, debíamos decirle cada equipo, cuantos aviones de cada tipo íbamos a entregarle en los 4 minutos de tiempo para construir que disponíamos con el requisito imprescindible de que pasasen su test de vuelo.

Ahí, ya cometimos el primer error. Estimamos pensando en que TODOS iban a volar, es decir, el número de aviones que íbamos a construir en los 4 minutos no tenía que ser el mismo que el numero de aviones que iba a pasar el test.

Y lo que es peor, nos pusimos a hacer aviones como locos, sin probar antes que alguno volase (Hola?? TESTEO!!), para en el caso de que no lo consiguiesen, introducir alguna mejora. Emma no nos había especificado que no podíamos cambiar los diseños, simplemente dimos por hecho que no podíamos hacerlo.
Seguir leyendo «Meetup de Juegos y dinámicas ágiles»

Elementos de un sistema de diseño

, , , ,

Seguimos con la serie de artículos de cómo crear un buen sistema de diseño, primero vimos por qué eran útiles y segundo las características de un buen sistema de diseño. Continuamos con este artículo sobre qué debe contener un sistema de diseño.

Como comenta el libro Lean UX, «Si está hecho de pixels va en el sistema de diseño«.

Todos los componentes, con la definición de su aspecto visual e interacción, el código necesario para insertarlo, sus clases, selectores, modificadores… deberían estar en el sistema.

iOS Design System

Ejemplo de Search Bars en el Sistema de Diseño para iOS

Qué aspecto visual tiene el elemento

Detalles sobre el tamaño mínimo y máximo, restricciones verticales u horizontales, color, estados (active, inactive, hover….)….

Dónde se coloca normalmente en la pantalla

Especifica claramente si un elemento sólo puede estar ubicado en ciertos lugares de la pantalla, así como posibles excepciones.

Seguir leyendo «Elementos de un sistema de diseño»

Scroll hacia arriba