Agile, kanban, waterfall, proces unficiado… son decenas las metodologías que se han propuesto para desarrollar software a lo largo de la historia. Tras más de una década peleándome con diferentes aproximaciones nunca he visto ninguna correctamente implementada y, creo, nunca he visto ninguna funcionar hasta que en mi última empresa decidimos implementar durante una época una metodología que llamamos internamente D5

D5 combina, en mi opinión, todas las buenas ideas que se han propuesto en otras metodologías. Es suficientemente estricta como para que todo el equipo tenga claro que hacer en cada momento pero a la vez es suficientemente flexible como para no ahogar en burocracia y rituales. D5 consiste en identificar problemas y ofrecer soluciones lo antes posible.

Los seguidores del movimiento lean, o del desarrollo ágil hace años que tienen una máxima clara “desarrolla un MVP lo antes posible, válida tu idea y aprende”.

D5 divide el desarrollo en 5 fases en las que aunque todo el equipo participa, siempre hay un claro responsable de cada una de ellas. Discovery, Design, Develop, Deploy, Deliver

Discovery

Responsable: Product Owner

odo empieza aquí. En esta fase, la persona responsable del producto está constantemente entrevistándose con usuarios y potenciales usuarios detectando “problemas” (pains).

El objetivo fundamental es escuchar al usuario, entender qué problemas tiene, cómo usa el producto, saber qué alternativas existen y los pros y los contras.

En este punto, he observado muchos errores que se repiten constantemente en diferentes empresas:

1. Ideas felices

La persona responsable de producto tiene ideas felices que añade al backlog sin realizar ningún tipo de discovery:
“Vamos a añadir un chat”. “Creo que si ponemos avatares de colores, la gente nos va a usar más”.

2. Ingenieros ausentes

Aunque estrictamente la fase de discovery es responsabilidad del equipo de producto, es bueno que el equipo de ingeniería esté al corriente de lo que está pasando. Obligarles a dar soporte o asistir a reuniones con clientes cada cierto tiempo es una manera de recordarles que el software es una herramienta para resolver problemas a otras personas.

3. Falta de issue tracker

Creo que es fundamental disponer de un issue tracker automatizado donde los clientes puedan reportar errores y sugerencias de mejora, y sacar métricas constantemente. Si el 90% de los errores están relacionados con una funcionalidad concreta, quizá sea hora de darle un lavado de cara.

4. Soluciones antes de problemas

Lo más importante en esta fase es tener claro que el objetivo de esta fase es identificar PROBLEMAS.

Os contaré una historia. Hace tiempo trabajaba en una app de chat y videollamada. Uno de los clientes nos pidió un “detector de presencia”, el típico icono verde/rojo que indica si un interlocutor está conectado o desconectado a un chat. Implementar esa funcionalidad nos llevó meses y muchos quebraderos de cabeza. Justo antes de entregarla a alguien, se le ocurrió preguntar para qué querían esa funcionalidad, y resultó que la estaban usando para asignar responsables a un determinado chat.

Su problema era que, dada una incidencia, querían asignar a una persona concreta para chatear. ¡Y esto lo hacían marcándose como “no disponibles” manualmente!

Resultó que la asignación de chats era algo que nuestra plataforma ya soportaba, pero no estaba bien documentado. Se solucionó en 1 día, y todo el sistema de presencia quedó en el olvido*.

Design

Personas responsables: product owners, product designer, tech lead

En esta fase, tenemos un problema correctamente identificado, y el equipo debe analizarlo en busca de una solución.

Esta solución no debe ser definitiva, debe ser algo que se pueda desarrollar lo antes posible, sin acumular deuda técnica, y que permita validar con el usuario si la solución propuesta aporta valor resolviendo el problema.

Quizá en esta fase es donde más decisiones críticas se toman, por eso es importante involucrar a todo el equipo.

Es importante recordar que diseño no solo implica interfaz gráfica. Diseño implica pensar en todas las cosas que pueden salir mal, implica pensar en GDPR, implica hablar con el departamento legal, implica hablar con finanzas, implica no tener miedo a comprar soluciones en lugar de reinventar la rueda.

De nuevo, en esta fase he identificado varios problemas recurrentes.

1. Exceso de optimismo

Los product owners son demasiado optimistas. En mi experiencia, es frecuente que siempre piensen en el caso “de oro”, pero nunca se paren a pensar en los casos extremos.

Recuerdo una vez que estábamos implementando una funcionalidad de cash-back.

“De todas las compras que haga el usuario, se le devolverá un 1% a final de mes.”

¿Qué es un mes? ¿Un mes UTC? ¿Un mes en la zona horaria del usuario? ¿Qué pasa si el usuario se mueve? ¿Qué pasa si el usuario compra un coche de 30.000€ el día 31 y lo devuelve el 5 del mes siguiente? ¿Qué pasa si el usuario usa su tarjeta para recargar su cuenta de Revolut? ¿Puede crear dinero infinito? ¿Deberíamos añadir todo esto a los términos y condiciones?

Todo este tipo de cosas y casos raros suelen estar en la cabeza de los ingenieros y rara vez en la cabeza del equipo de producto.

Por ello, es importante que una persona de ingeniería esté encargada de buscar casos raros en esa fase.

2. Subestimar esfuerzo

Otro problema que suelo encontrar en esta fase es que el equipo de producto subestima la complejidad de algunas tareas. Por ello, es conveniente siempre tener a personas del equipo de ingeniería involucradas en el proceso de diseño para dar estimaciones realistas del coste de cada propuesta.

3. No se recorta el alcance

Una vez tenemos una solución pensada, hemos estudiado sus implicaciones, y tenemos una idea del coste de desarrollo, toca hacer lo más difícil: RECORTAR.

Dedicar un tiempo a pensar bien en un problema y su solución no quiere decir que tengamos que implementar todo desde el primer momento. En muchas ocasiones, se pueden hacer concesiones y reducir el alcance de una funcionalidad, dejando partes para etapas posteriores.

En este punto, es importante preguntarse: Sabiendo lo que sabemos, ¿qué es lo mínimo que podemos hacer para que el cliente lo utilice y nos dé feedback sin hipotecar nuestro futuro?

Seguro que poder filtrar por fecha con un datepicker es una idea genial, pero igual podemos usar el input por defecto del navegador en la primera versión. Seguro que crear una herramienta de analíticas en tiempo real es la bomba, pero igual le podemos mandar al usuario un csv por email.

Al final, se trata de hacer concesiones conociendo los riesgos y beneficios de cada decisión.

Develop

Persona responsable: Tech lead

Llegamos a la fase de desarrollo. En esta fase, hay cientos de metodologías sobre las que podría escribir algún día, pero en este texto me limitaré a dar un simple consejo:

 1. Ten todo automatizado

Si alguien pregunta: “¿En qué estado está esta tarea?” o si el equipo no tiene claro si un ticket está desplegado, es un claro indicio de que algo va mal.

Herramientas como conventional commits y convenciones de nombrado de ramas permiten que los tickets se asignen y se muevan por el board automáticamente, sin necesidad de que los desarrolladores abran JIRA.

De nuevo, puede que escriba sobre esto porque tengo opiniones muy fuertes sobre dinámicas de desarrollo de software.

Deploy

Persona responsable: Tech lead

Personalmente, considero el despliegue como una fase más del proceso de desarrollo. Es más, si todo está automatizado, no debería existir más allá de las herramientas de gestión de tareas. En todo caso, es en esta fase donde los cambios se despliegan, y es importante no confundirla con la última fase (deliver), en la que los cambios son visibles por el cliente.

Desplegar algo implica tener el código integrado en la rama correspondiente, independientemente de si las funcionalidades implementadas son visibles o no por el usuario final.

En esta fase, el equipo puede realizar pruebas internas (QA) o incluso probar con clientes reales.

De nuevo, el mismo consejo: tener todo automatizado. En nuestro caso, cada commit a cada rama dev y prd se despliega automáticamente en el entorno que corresponda, y no es necesaria ninguna acción extra por parte del equipo de desarrollo.

Además, esta automatización mueve los tickets automáticamente por el board para representar el estado actualizado del ticket en cada momento. (IN REVIEW --> DEPLOYED TO STG)

Deliver

Persona responsable: Product Owner

Aunque parezca increíble, me he encontrado varias veces en equipos donde se desarrolla una funcionalidad y se nos olvida desplegarla para que los clientes puedan usarla.

Por ello, es importante que la persona responsable sea la misma persona encargada de producto (PO), y por ello es importante que disponga de herramientas para entregar la nueva funcionalidad sin recurrir al equipo de desarrollo.

De nuevo, se podrían escribir varios artículos al respecto, pero en mi opinión, lo que mejor funciona es utilizar feature flags, y una vez que la funcionalidad ha sido validada (QA), se puede liberar y entregársela a todos los usuarios.

Conclusión

Personalmente, toda esta metodología me gusta porque puede verse como una cadena de montaje donde los tickets van pasando de una fase a otra, y en cada fase se da libertad al equipo responsable de los detalles de implementación. No se especifica si en la fase de desarrollo se debe usar Kanban, XP o Scrum con sprints de dos semanas.

Se centra en QUÉ debe hacer un grupo de personas en cada fase y no en el CÓMO, y lo hace poniendo al usuario y sus problemas como el origen de todo el ciclo de desarrollo.

Si esta metodología se implementa bien, cada equipo se despierta con una serie de tareas bien definidas en su columna "TODO". Como estas tareas han pasado por una etapa de refinamiento previa, estarán bien pensadas de antemano, por lo que el equipo puede centrarse en desarrollarlas y aportar valor en lugar de perder su tiempo aclarando detalles y haciendo preguntas absurdas.