Aplicando Scrum, claves Ágiles sobre esta metodología

Más de tres años desarrollando proyectos en Intelygenz me han llevado a evolucionar en la aplicación de la metodología Scrum en los diferentes proyectos en los que he estado involucrado.

La complejidad que tiene aplicar una metodología tan simple como esta se agrava debido a la naturaleza de nuestra empresa. Somos Product Makers!, desarrollamos producto bajo demanda,  y esto nos ha llevado a romper la barrera del tradicional proyecto llave en mano o proyecto cerrado con el fin de ser ágiles en las entregas y dejar que el mercado evolucione el producto.

Breve historia de Scrum

Como te diría Google, la autoría de esta metodología no está clara. Por un lado, está la versión que nos acerca a los japoneses Hirotaka Takeuchi e Ikujiro Nonaka quienes, a mediados de los 80, se dedicaron a estudiar y analizar la manera de desarrollar software en empresas tecnológicas como Fuji-Xerox. Por otro, están aquellos profesionales que defienden que Jeff Sutherland, John Scumniotales y Jeff McKenna fueron los creadores de esta metodología.

En cualquier caso, Scrum surge por la necesidad de desarrollar software de una manera radicalmente opuesta a cómo se estaba realizando. Hasta ese momento y en un porcentaje muy muy alto de empresas, para afrontar un proyecto de software había que tratarlo como si de un vehículo o de un edificio se tratase. Es decir, se desarrollaba el proyecto siguiendo una metodología en cascada en la que cada fase debe estar cerrada para abordar la siguiente.

Pronto esto empezó a no parecer demasiado viable. Primero, porque el software no es ni un edificio ni un vehículo y aquí las necesidades cambian constantemente. Segundo, porque la velocidad de desarrollo software es mucho mayor, no hay por qué esperar a tener el producto finalizado para testearlo, más aún, para sacarlo al mercado.

Esto motivó que fueran muchos los interesados en generar unas bases y modelos propios para el desarrollo software. El primero en aventurarse fue Ken Beck al publicar un libro donde exponía la metodología Extreme Programming en la que se daba pie al manifiesto ágil y a metodologías tales como Scrum.

¿Qué es Scrum?

La metodología Scrum se basa en un conjunto de prácticas y roles muy definidos que han de intervenir durante el proceso del desarrollo de software. Se trata de una metodología flexible donde premia la aplicación de los 12 principios ágiles en un contexto acordado por todos los actores del producto.

Estos actores se reducen a equipo, equipo y equipo, pero dentro de él tenemos al Product Owner (responsable de las decisiones de negocio), al Scrum Master (facilitador y responsable de eliminar cualquier impedimento en el proyecto para alcanzar el objetivo  eficientemente), el equipo de desarrollo y los stakeholders.

Las prácticas se reducen a la definición de un backlog (funcionalidades que queremos), a una serie de reuniones obligatorias (daily meetings, sprint review, sprint retrospective y sprint planning) que promuevan la comunicación entre los miembros del equipo y, al testing continuo y refactorización.

etapas_scrum

Dentro de ese contexto, se debe acordar y acotar la dimensión de cada período de tiempo en el que se va a entregar un pedazo de software usable o incremento de producto, el denominado sprint, componiendo el proyecto un conjunto finito de sprints acordados según la necesidad de negocio. En Intelygenz hemos trabajado con sprints de 1 semana, de 2 semanas y de 3 semanas; y nuestra recomendación es la de realizar sprints de 2 semanas.

Por tanto, tenemos que cada intervalo de tiempo definido se entrega software al cliente (Product Owner + Stakeholders) que se puede probar, validar, valorar e, incluso, medir. Esta es una de las virtudes de las metodologías ágiles, la velocidad para salir al mercado y tomar decisiones para mejorar nuestro producto.

Actualmente el time to market adquiere un valor mayor que en otros momentos de la historia. Hoy día una compañía no se puede permitir desarrollar un producto software durante más de 4-6 meses para salir a producción, debe posicionarse en el mercado lo más pronto posible y, entonces, medir para evolucionar el producto; debemos dejar de ser endogámicos, debemos escuchar a nuestra audiencia (a los miles o millones de usuarios a los que podemos llegar) con el fin de mejorar nuestro software en intervalos cortos de tiempo, así mejoraremos la satisfacción del cliente final. Esta es la razón por la que las metodologías ágiles, concretamente Scrum, son un pilar fundamental en la construcción de nuestro software.

Este vídeo te representa, en menos de diez minutos, todo lo que te hemos contado hasta ahora.

Aplicando Scrum, el día a día en Intelygenz

Llegados a este punto, me gustaría adentrarme en nuestro día a día desde hace unos años gestionando proyectos bajo esta metodología y, aunque esto daría para varias partes del artículo, voy a intentar centrarme en lo más destacable.

Líneas arriba he comentado que somos Product Makers a medida, es decir, hacemos producto software para otros (también para nosotros :P) y esto implica una relación contractual donde los otros (nuestros clientes) van a pagar porque les hagamos un producto; lógico, ¿verdad?

Aquí encontramos la primera barrera, o mejor dicho, el primer gran reto. El cliente quiere definir y acotar lo que le vamos a desarrollar para tener un precio y no pagar más. Esto entra dentro de lo lógico pero, ¿realmente el cliente sabe lo que quiere?, ¿es capaz de definir hoy todas las funcionalidades que hay que desarrollar en los siguientes 3 meses sin alteración? No, la respuesta es no, y es muy normal que no lo sepa porque el producto se va construyendo cada día y cada día surgen decisiones nuevas que tomar e implementar. La confianza es el nexo de unión entre el cliente y el equipo de desarrollo. En Intelygenz, nuestro objetivo es hacer un producto de calidad en el menor tiempo posible traduciéndose en un win-win .

Otro apartado importante es la definición de escenarios. Hablar de Scrum o de una metodología ágil sin hablar de la definición de historias de usuario y de sus escenarios sería un error puesto que es el primer paso a llevar a cabo. Para ello se elabora una pila de producto a modo de Road Map y se priorizan las historias para que, en cada sprint, queden definidos los escenarios posibles antes del desarrollo. Esto es clave.

En Intelygenz desarrollamos las historias de usuario con el cliente, generando el backlog y creando tentativas de sprint backlog para cada sprint. En paralelo, vamos analizando cada historia en sí misma para crear sus escenarios posibles permitiendo que todas las personas que forman el equipo (Product Owner, Scrum Master y Desarrollo) estén alineadas y focalizadas en las funcionalidades a entregar en cada sprint.

Esta definición es vital para evitar bloquear al equipo de desarrollo con dudas funcionales durante el transcurso del sprint, de ahí que el sprint planning deba ser una reunión de larga duración ya que aparecen cuestiones que hay que esclarecer. El propósito de esta reunión es proporcionar información suficiente al equipo para trabajar sin interrupciones.

Como comenté anteriormente, Scrum se basa en un trabajo de equipo , desde el más junior del equipo hasta el Product Owner conocedor del negocio. Todos tienen un papel fundamental para el éxito del proyecto. No podemos tener un desarrollador que afirma implementar un algoritmo/s o funcionalidad/es en un tiempo estimado y que se equivoque constantemente. Pero tampoco podemos tener a un miembro de negocio, el Product Owner, que no tome decisiones porque ha de consultarlo todo o no conoce el negocio. El equipo debe estar equilibrado.

En ocasiones los dueños de producto quieren evitar invertir tiempo en reuniones sobre algo que ellos consideran que ya está (nos referimos a las historias en el backlog) o que ya ha quedado claro en otras conversaciones y que, la definición de escenarios, es algo que debe hacer el resto del equipo.

Cuando una de estas situaciones aparece, es momento de ponernos en alerta como desarrolladores y autogestores del proyecto puesto que el alcance del mismo va a extenderse, ¿por qué? podéis preguntaros, pues porque negocio está poniendo el primer bache en el proyecto, a saber, reducir la comunicación y evitar crear los escenarios junto al equipo para dilucidar todos los posibles problemas que puedan surgir en las siguientes dos semanas. Todo esto derivará en continuas interrupciones del desarrollo para reunirse con el product owner y aclarar las dudas.

En el mejor de los casos, él tomará la decisión, en el peor, él no tiene potestad  para tomar decisión así que escalará la duda; ¿creéis que en esta situación se cumplirá la entrega pactada en el sprint planning? Sí, es una pregunta retórica :). El resultado: aumento de alcance, de presupuesto o de tiempo.

triangulo

Para reducir ese riesgo en Intelygenz lo que hacemos es crear un backlog lo más extenso posible, priorizar y realizar los escenarios de, al menos, dos posibles sprints en la primera semana del proyecto. De esta manera somos capaces de generar tracción.

Documentar, auditar, aprobar…

Al entregar periódicamente un incremento del producto necesitamos validarlo, aprobarlo y cerrarlo. Esto significa que en 2 semanas hemos entregado ya algo pero, ¿cómo y dónde lo registramos? ¿cómo hacemos el seguimiento?

jirapivotal

Siempre han existido herramientas - Excel entre ellas 🙂 - para la gestión de proyectos. Nosotros hemos probado varias para, finalmente, decidir por juicio por combate entre jira agile y pivotal tracker. La victoria ha sido para el primero porque nos ofrece más opciones al gestionar proyectos como la posibilidad de definir un dashboard donde podamos configurar la información adhoc de cada proyecto  y, especialmente, la posibilidad de generar una serie de informes que nos ayudan con el seguimiento y la documentación.

Tests de aceptación a través de escenarios

Algo tan sencillo como que dado (given) una situación cuando (when) ocurre una acción entonces (then) se desencadena otra, nos permite definir un escenario usando lenguaje natural, incrementando la comprensión de la funcionalidad a desarrollar así como acotando cada caso de uso al mínimo. Por ejemplo, alguien tiene en cuenta qué debe pasar cuando se despliega el teclado del móvil mientras se está definiendo o diseñando la funcionalidad de una pantalla X? ¿se mueve el contenido hacia arriba o se debe flotar el teclado?

Cuando se trabaja con ATDD y con la definición de escenarios, se minimiza el riesgo de pasar por alto detalles como el ejemplo anterior.

Este punto es un adelanto de lo que será otro artículo del blog, pero puedo asegurar que, en unos años, siglas como ATDD o BDD y términos técnicos como cucumber y gherkins resultarán tan familiares como necesarios al desarrollar software.

 

Diego Romera

¿Te gustaría trabajar con nosotros? Genial ¡te esperamos!