Hola! en esta oportunidad les quiero contar un poco más sobre la forma en que trabajamos en Garage Labs. Me gustaría compartir cómo medimos cuán difícil puede ser desarrollar un software y en especial una funcionalidad del mismo, y cuál fue el camino que recorrimos para llegar a todo esto.

En Garage Labs trabajamos con metodologías ágiles en todos nuestros desarrollos, que están compuestos por distintos integrantes que se reparten los roles de Product Owner, Diseño y Desarrollo. Si nos damos cuenta, cada uno de ellos tiene conocimientos distintos y nociones distintas del software en que se trabaja, por lo que nos nace la duda, ¿cómo evaluamos la dificultad de una funcionalidad de tal forma que todos entiendan lo mismo?

Uno de los artefactos más importantes de la metodología Scrum son las historias de usuario, que en palabras sencillas representan una funcionalidad del software desde el punto de vista del usuario final, indicando su camino feliz y las posibles excepciones a la regla. Lo más importante de una historia de usuario es que aporte valor a quién use el software. Sobre lo mismo, se suele trabajar con puntos de historia (story points, sp) , que nos indican la dificultad relativa de realizar dicha funcionalidad.

‍

¿Y cómo asignamos los puntos de historia?

Esta es la parte entretenida. Existen dos tipos de escalas frecuentemente utilizadas: la primera, es pensar en la funcionalidad como si fuese una prenda de ropa, por ejemplo, una polera (!!)

Podemos pensar en darle pequeña, mediana, grande, súper grande o extra grande. O quizás utilizar las tallas reales: XXS, XS, S, M, L, XL, XXL y así. Lo importante siempre es que los incrementos entre un nivel y el siguiente sean significativamente grandes y entendibles por todos.

Otra forma de asignar los puntos de historia es con la escala de Fibonacci.

Esto utilizamos en Garage Labs. ¿Por qué? Muy simple: Los incrementos entre un nivel y otro son claros, ya que son la suma de los dos niveles anteriores, lo que potencia aún más la estimación relativa. Por otra parte, nos encanta que sea una escala numérica, ya que nos da posibilidades infinitas.

OK, me convenciste, ahora: ¿cómo relacionas esta serie con una historia de usuario?!?!

Existen distintos factores para darle “peso” a una historia de usuario, pero antes de esto debes definir cuántas sp puede realizar tu desarrollador en una hora. En base a esto puedes tener referencias para calcular KPIs (sp reales vs referenciales), velocidades de desarrollo y la cantidad de puntos que entraran en tus sprints. En Garage Labs partimos bajo el supuesto de que un desarrollador puede concluir 21 puntos de historia en 1 día (bastante holgado). Esto dependerá totalmente de la expertiz de tu equipo.

Bajo esta premisa, te voy a detallar algunos casos que siempre se repiten durante el tiempo, que te pueden servir si eres dev (para tener referencias) o si eres Product Owner (así no te pasan gato por liebre).

‍

Detalles visuales

Generalmente los detalles visuales (como mover un botón, cambiar un texto, etc) te van a tomar poco tiempo solucionarlos, por lo que el peso de estas funcionalidades debiese estar en la parte más baja de la escala de Fibonacci (límite 5 puntos).

‍

Una funcionalidad nueva, pero copiable

Muchas veces nos piden hacer algo que ya hemos hecho antes, si al final de eso se trata ser dev jaja. Este tipo de funcionalidades debiese andar por la parte media de la escala, pero como todo siempre hay excepciones. No me atrevería a darte un estimado exacto en puntos de historia, pero en nuestro caso nunca sobrepasa los 21 puntos.

‍

Algo totalmente nuevo

A veces el equipo (ya sea por parte del cliente o de parte de Garage Labs) se pone bastante creativo y te piden hacer algo nuevo que probablemente tengas que buscar en stackoverflow durante un rato para sacar ideas. En estos casos dependerá mucho de la funcionalidad el peso, probablemente no sobrepase los 34 puntos. Si te pasas es porque probablemente esa historia se podía subdividir en cosas más pequeñas.

Algo que simplemente es difícil

Hay cosas que simplemente son difíciles. Ya sea porque tienes que probar muchos casos de uso para asegurarte de que quede bien, o porque una query SQL es muy compleja, en cualquier situación tómate la libertad de darle el peso necesario para completar la funcionalidad. Si estás en el caso de no saber si realmente se puede hacer una funcionalidad, recuerda que puedes adelantarte a los hechos e incluir una historia de usuario del tipo “spike”, que te servirá para explorar una posible solución y sacar conclusiones sobre la factibilidad de la misma.

‍

Integraciones

Todas las veces en que hemos tenido que integrarnos a otro sistema asumimos lo peor: nunca pero nunca nunca nunca saldrá bien a la primera. Ni la mejor documentación, ni el mejor servicio de soporte harán que puedas hacerla a la primera. Tómate tu tiempo y dale el peso que estimes a este tipo de funcionalidades, acolchónate para lo peor.

Todos estos tips y detalles que te dí son en base a nuestra experiencia, por lo que puedes ajustarlo a la realidad de tu equipo y adaptarlo para conseguir el mejor rendimiento. De todas formas te aseguro que mucho de lo que te dejé aquí se repetirá de alguna u otra forma. Varias cosas que comento las hemos sacado del libro amarillo escrito por el mutan de Scrum, Jeff Sutherland. Te lo recomendamos a ojos cerrados si aún no entras en el mundo ágil ✌.

‍

Espero que les haya gustado este artículo y desde ya los dejo invitados para que sigan leyendo nuestro contenido, muchas gracias!

‍

‍