Esta semana continuamos en esta serie sobre la organización en Calipso Studios con la metodología de trabajo. La semana pasada pretendía contaros como trabajamos en esta entrada, pero viendo que para que comprendáis el qué, el por qué y el como hay que introducir las metodologías ágiles creo que es conveniente dedicar esta entrada a realizar ese introducción y dejar la adaptación de las mismas a nuestro caso particular para una próxima entrada.
La metodología es algo bastante propio de cada equipo y se debería escoger aquella con la que funcionamos mejor. Como punto de partida para modificar después es conveniente utilizar alguna metodología basada en «Agile Programming«, sobre todo si seguís un modelo de «customer-development«. Os recomiendo que os leáis la presentación del segundo enlace para comprender el porqué, pero para aquellos que no quieran hacerlo el resumen sería que para vender a un cliente tenemos que conocer qué es lo que quiere y para ello, hacer el típico monolito de 20,000 lineas de código del modelo de desarrollo en cascada, con su única fase de análisis, diseño, implementación, pruebas e implantación viendo al cliente únicamente al inicio para sacar una especificación completa del producto y al final del ciclo cuando le entregamos el producto con todas las características ya implementadas tiene el mismo efecto que tratar de cazar moscas con guantes de boxeo de 20 kg: no darle ni a una y acabar agotados por mantenimientos que son reingenierías del producto. Y en una startup lo que tenemos que hacer es encontrar nuestro público objetivo o target y conocer e implementar sus necesidades/gustos/ideas, no las nuestras. Las metodologías agile promueven precisamente 2 cosas que nos pueden ayudar para conseguir esto: la primera implicar al cliente como uno más del equipo para obtener feedback continuamente y la segunda reducir el ciclo de desarrollo en tiempo y en ámbito, a semanas en vez de meses y sobre características concretas demostrables del producto en vez de sobre una especificación de producto completa. En este caso veremos 2 de estas metodologías Kanban y Scrum. El más simple de los dos es Kanban y su idea principal es mantener constante el flujo de trabajo, minimizando los cuellos de botella y asignando los recursos allí donde hacen falta. Imaginaos que tenéis vuestro equipo de desarrollo, os reunís inicialmente con el cliente y los requisitos que sacáis sobre el producto los escribís en una serie de tarjetas o post-its, uno por cada requisito que os diga. Imaginaos también que tenéis una pizarra con varias columnas que representan las etapas del ciclo de vida de desarrollo que seguís en vuestro equipo. Para hacerlo simple, un ejemplo de estas columnas serían: selección del requisito actual a implementar, Análisis del requisito actual, Desarrollo del requisito actual y Pruebas del código implementado con feedback del cliente. Los post-its con los requisitos los ponéis en la columna de selección. Entonces Kanban funciona de la siguiente manera:
Scrum sube un peldaño la formalización e introduce algunos particularidades dentro del ciclo de vida. En el enlace de la wikipedia sobre Scrum viene una buena descripción sobre los elementos de este modelo, por lo que no los voy a reproducir aquí. Un ejemplo de como funciona sería el siguiente:
Ahora que conocemos un poco como funcionan estas metodologías ágiles, ¿cuál puede ser la mejor para una startup? Mi respuesta en este caso es la siguiente: aquella que mejor se adapte a vuestro equipo, modificando y adaptando aquellos elementos de la misma que por algún motivo no funcionen con el equipo que tenéis. Considero que una metodología nunca debe ser algo que limite y encorsete el funcionamiento hasta el punto de que por ser metódico y tener que cumplir necesariamente con algún requerimiento establecido o etapa de la misma nos bloquee o reduzca nuestra eficiencia. La metodología simplemente es otra herramienta que está al servicio del equipo y no al revés, no son las tablas de la ley. Por tanto, considero que lo mejor es modificar, eliminar o añadir aquellos elementos que mejor pueden funcionar en vuestro entorno. Si tenéis esto claro, Kanban es un buen punto de partida para establecer una metodología que se adapte a nosotros. En Kanban a diferencia de Scrum, no se ha hablado para nada de si hay alguien que se encarga de representar al cliente dentro del equipo o de planificar el trabajo (más allá de seleccionar el/los requisitos que se hacen en el momento actual), ni cuanto va a durar en media un ciclo completo de desarrollo, ni como podemos medir esos ciclos. Kanban es más intuitivo y sólo dispone lo fundamental, de hecho incluso hasta las etapas del ciclo de vida que seguimos se pueden elegir. El punto fundamental de esto es:
«Adapta la metodología a tu equipo»
Un ejemplo de esto es «Kanban vs Scrum» una magnifica lectura que recomiendo sobre ambas metodologías que establece una comparación entre ellas y una experiencia real sobre la adaptación de la metodología al equipo para obtener el máximo potencial del mismo, combinando ambas.
He de decir que esto es algo que estoy intentando ajustar continuamente pues de lo que se trata aquí es de encontrar la manera óptima de trabajar entre nosotros como un equipo. La semana que viene veremos como he planteado esta adaptación.
2 Comentarios
Todo esto me es más o menos conocido, aunque me parece un buen preámbulo :). Esperaremos pues la aplicación práctica en Calipso para la semana que viene 😀
Muy buen post!
Para mí lo más importante de las metodologías ágiles es incluir entre sprint y sprint (scrum) el feedback del cliente/usuario. Al final estas metodologías no nos hacen avanzar de manera más rápida, sino que nos dan la posibilidad de adaptar aprendiendo continuamente del mercado.
De hecho, cada lote de trabajo no debe de terminar cuando está funcionando a nivel técnico, sino que el objetivo es validar o invalidar el trabajo desarrollado analizando si ha sido útil y apreciado por el usuario final, que es lo que importa.
Gracias por compartir tu experiencia, es de gran valor 🙂
Cometarios cerrados