Filosofía Agile: la forma esencial de vivir la programación

Uno de los valores fundamentales de una startup es que los miembros consigan tener un objetivo común. Trabajar en un producto e ir mejorándolo en cada iteración. Pero sobrellevar la incertidumbre inicial en las fases más tempranas de un proyecto no es sencillo. Tampoco lo es gestionar el flujo de trabajo cuando el equipo crece. Por todo ello, las metodologías ágiles se presentan, en cierta forma, como el gran facilitador en el desarrollo de aplicaciones en una startup.

La filosofía Agile va más allá del simple hecho de iterar cada 2 o 4 semanas sobre un producto inicialmente concebido como un MVP.

“Una de las características más potentes que definen una startup es su velocidad para crear producto, experimentar y pivotar si las cosas no salen según lo esperado. Todo eso solo se consigue con metodologías ágiles”, nos comentaMarcos Sorribas de Minube.

Elegir una Metodología Ágil

No hay que crear una guerra entre metodologías ágiles, que si mejor Scrum o que si mejor Kanban. Lo primero es identificar las necesidades de nuestros proyecto y sus dimensiones.

Hay que definir cuál será el periodo entre una subida a producción o entrega de funcionalidades. Lo normal es rondar entre dos o cuatro semana para proyectos más grandes. Aunque si nos decantamos por Kanban ese concepto no existe: cuando se acaba una tarea se puede dar por finiquitada y no requiere de un tiempo hasta que cumpla el sprint de dos semanas, por ejemplo. En Minube, Marcos Sorribas nos comenta: “Los sprints que actualmente tenemos definidos son de una semana, lo que nos permite tener un muy buen ritmo de trabajo además de tener mucha flexibilidad para ir adaptándonos al roadmap”.

En el mundo de las startups nos movemos creando hojas de ruta y definiendo hitos importantes, sobre todo para mostrar a los inversores. Esto desemboca en un release plan para organizar el flujo de funcionalidades que hay que sacar adelante. Hay que proporcionar un calendario de entregas; quizás aquí es donde empezamos a fijar una periodicidad de entre 2 o 3 semanas para presentar novedades en el producto que estemos construyendo.

En toda metodología ágil hay que definir las fases desde que una funcionalidad pasa de una definición funcional hasta su análisis técnico, desarrollo, testing, aceptación o puesta en producción. Según los miembros del equipo y su grado de especialización quizás nos interese definir una serie de pruebas unitarias, de integración o de aceptación dentro del apartado de QA. O por otro lado, necesitamos preparar el entorno o una release concreta antes de poder marcar una tarea como DONE.

Traducir los requerimientos del Project Manager a tareas técnicas

En una startup es complicado encontrarse con documentos de requisitos para una determinada features de 150 páginas, pero lo que si nos encontramos es con funcionalidades en plan muy difusas o que necesitan definir tareas concretas. Por tanto, debemos ir completando sobre la marcha muchos requisitos.

En un análisis funcional con descripción de requisitos generalmente se utiliza UML. Un lenguaje descriptivo pensado inicialmente en la sencillez de la comunicación y que se ha convertido en un monstruo que entienden muy pocos y que utilizan correctamente aún menos. Por eso, uno de los primeros pasos esconvertir todo ese lenguaje más formal en un lenguaje entendible por todo el equipo. Esto son las Historias de usuario.

Las historias de Usuario están vivas. Representa casos de uso independientes, las cuales reflejan una funcionalidad tangible para el usuario. Su construcción se basa en la identificación del caso de uso concreto: “Como usuario quiero poder filtrar los resultados de búsqueda”. Consta de un enunciado escrito en lenguaje coloquial y una serie de requisitos funcionales que nos servirán, posteriormente, como criterios de aceptación.

El primer paso para poder utilizar una metodología ágil, ya sea aplicando Scrum o Kanban es con esas historias de usuario dividirlas en tareas técnicas, marcar el peso en el desarrollo y definir lo que el equipo podrá asumir en un sprint (un periodo de tiempo determinado que fijamos para tener un entregable al cliente).

Gemma Gamerson, VP of Technology de Xing nos da algunas claves de los beneficios: “Se puede empezar muy light. Por ejemplo, con Kanban de manera de visualizar y priorizar las tareas. Dividelas en piezas pequeñas manejables (el mismo tamaño) y puedes medir cómo de rápido es tu progreso y empezar así a hacer predicciones. Pero lo más importante es limitar tu work-in-progress, así puedes centrarte realmente en lo que es importante, y cerrar tareas a buen ritmo, crucial en una startup”.

Gestionar el equipo Agile

La figura del scrum master es fundamental para esa labor. En ningun caso debe ser confundida como la de una madre que va detrás de sus hijos para que hagas sus tareas. El scrum master es un facilitador para que el equipo avance.

Para Gemma Garmeson: “En teoría no es necesario un Scrum Master si el equipo es ya maduro y se autoorganiza, pero en mi experiencia todos los equipos necesitan una mano de vez en cuando. En Xing cada equipo tiene un scrum master y esta persona no solo soluciona los impedimentos, sino también hace coaching para que el equipo mejore. Por eso a veces son un observador, y se meten cuando el equipo está bloqueado. Eso es muy difícil que alguien dentro el equipo lo haga”.

El propio equipo es responsable de saber qué tareas tiene que hacer en cada momento. Para ello, el uso del tablón Scrum o Kanban es fundamental. La gestión del equipo se sustenta sobre él y, por supuesto, es un indicador de en qué tarea está cada uno de los miembros.

El scrum master prioriza las tareas extrayendolas del backlog y definiendo lo que va a entrar en el sprint que se va a comenzar. Una vez en marcha los desarrolladores van trabajando en cada una de ellas y pasando las distintas “columnas del tablón”.

Las “dailys” reuniones diarias del equipo son fundamentales, esenciales para comentar qué se hizo, qué se va a hacer hoy y qué impedimentos se han tenido para que el scrum master lo gestione. Pero no debemos olvidar las retrospectivas en las que se detectan posibles problemas y dónde se inicia la mejora continua.

Fuente: http://www.genbetadev.com/