Un día de cervezas con mi amigo y compañero de trabajo José Manuel de Proweb en la Universidad de Alicante, me estuvo comentando la importancia de los métodos de desarrollo ágil de software, en concreto de SCRUM.
Me picó la curiosidad y le pedí bibliografía. Me recomendó SCRUM Y XP DESDE LAS TRINCHERAS (pdf), un libro totalmente recomendable la verdad, muy sencillo de leer y lo mejor: con un enfoque muy práctico. Además está tambien muy bien el blog del propio autor Henrik Kniberg.
Me resultó tan interesante que en esta nueva etapa de nitsnets | studios vamos a empezar a aplicar SCRUM, al menos en los grandes proyectos. Lo más curioso es que tengo la impresión de que muchos procesos ya los estamos haciendo siguiendo una metodología parecida, casi por inercia.
¿Qué es SCRUM?
Scrum es una metodología para el desarrollo de software basada en un proceso iterativo e incremental. – definición de la wikipedia. Os voy a listar algunas referencias que me han ayudado ya que viene muy bien explicado todo el método:
- Por supuesto, la propia entrada en la wikipedia.
- El Manifiesto por el Desarrollo Ágil de Software nos explica los doce principios que debemos aplicar.
- En este post: Metodología Ágil para tus Proyectos.
- Y este otro titulado sencillamente Qué es SCRUM
- Incluso un caso de éxito muy interesante: SCRUM funciona!
Organización
Mejor equipos pequeños y por tanto más fáciles de organizar, auto-organizados.
Siempre he creido en este principio, en micro equipos de trabajo. Siempre piensas: ¿cómo es posible que trabajen tantas personas en esta web? ¿cómo puede ser que valga tanto? Y es que mi experiencia es que cuanto las estructuras son más grandes, más cuesta organizarlas y por tanto más se derrocha en todos los sentidos (esfuerzo, dinero…). El mayor ejemplo quizás sean los países y sus gobiernos: y es que mover estructuras tan grandes no es nada sencillo!
Recuerdo como un amigo me explicaba su experiencia en HP en 2006 y su forma de organizarse en mini grupos, como mini empresas que hacían piña (o méle que es la traducción literal de scrum). Ahora he entendido que aplicaban el método Scrum.
Los roles principales en Scrum, intentando no limitarnos a cerdos y gallinas 😛 son:
- Product Owner. Jefe del producto. Encargado de hablar con el cliente y sacar los requisitos del sistema así como sus prioridades.
- ScrumMaster. Director de proyecto. Encargado de que se cumplan las entregas, en un concepto más amplio los sprints.
- Team. Desarrolladores. Los que pican vamos 😉
- Externos (gallinas). Su rol es distinto, es aportar información y datos importantes al proyecto pero desde un punto de vista desde fuera, no implicados en el desarrollo.
Usuarios/testers (podrían ser los internautas en desarrollo web), clientes, especialistas del sector… (si estas haciendo una web de docencia: profesores por ejemplo), etc
Proceso
- 1. Se empieza con la pila de producto. Lista priorizada de requisitos/funcionalidades.
Cada funcionalidad tiene: identificador del requisito, nombre (p.e «Ver listado de pedidos» en un ecommerce), importancia (se le da un peso a cada funcionalidad, más alto más importante), estimación inicial (se mide en puntos, cada punto es un día, 3 personas 2 días => 6 puntos de la tarea), test, notas, solicitante (quién pide esta funcionalidad: cliente, desarrollador, jefe de proyecto), etc.El documento con las funcionalidades se llama Product Backlog y debe ser utilizado por todo el equipo, un documento colaborativo. Lo mejor sería utilizar GoogleDocs
- 2. Planificación de sprints que son cortos. Entregas frecuentes.
Sprint Planning Meeting
Scrum se basa en ciclos de desarrollos cortos, ya que la mente trabaja mejor con periodos de entrega a 2 días vista que a 2 meses, y es que a largo plazo nos solemos descentrar. Otra cosa que he tenido la experiencia de sufrir.Mediante un documento Sprint Backlog se detalla cómo se va a desarrollar. A partir del Product Blacklog de funcionalidades se despieza en tareas que no pasen de 2 días, 16 horas.
Y cuando se van a hacer entregas parciales, que va llevar cada SPRINT (entrega). El tiempo de cada entrega se determina según el proyecto (suelen recomendar 2 y 4 semanas). A partir de los sprints se puede enseñar trozos al cliente para que pueda introducir cambios, es decir, ser flexibles. Esto en mi experiencia y sector, puede ser la muerte con ciertos proyectos/clientes jeje aunque supongo que para proyectos grandes debe ser ideal pq retroalimenta.
La definición de los sprints se hacen con el equipo donde se define: una meta del sprint (para qué se hace este sprint, integra al equipo a conocer el porqué), fecha de finalización del sprint, que funcionalidades llevará el sprint y que desarrolladores con su dedicación posible si no es al 100%. No lo hace el ProductOwner todo porque cada desarrollador puede determinar mejor en su especialidad lo que puede tardar, las cosas que se pueden complicar… por eso lo de la piña.
En estas reuniones se define el alcance, importancia (definido por ProductOwner) y la estimación (definido por el equipo de desarrollo). Las reuniones tienes que ser breves, no podemos llegar a un consenso en el equipo y perder horas y horas en reuniones. Para tomar las decisiones se suelen utilizar tarjetas y post-its, por ejemplo para el tiempo que va a llevar una funcionalidad, y sacan todos a la vez su estimación así no están influenciados; esta similitud con el poker (planning poker) ha hecho que me llame la atención el método 🙂
A partir de los tiempos se hace la gráfica del BurnDown que planea un desarrollo ideal según lo planificado.
- 3. Reuniones diarias durante el desarrollo. Daily Scrum
Se suele hacer por las mañanas a las 9.00 al entrar. 15 minutos y de pie para prestar mayor atención. Todo el mundo expone lo que hizo el día anterior y que dificultades tuvo (suelen apuntarlo en una wiki).Fuente de conocimiento y solución de problemas. Cada uno debe contestar a unas preguntas: ¿Qué hiciste desde ayer?, ¿Qué tienes planeado hacer hoy?, ¿Has encontrado algún problema durante el desarrollo?
En definitiva al ir todos en una piña seguro que la cohesión del grupo es mejor y más ágil. Así como el entendimiento del equipo.
Herramientas
Os dejo algunas herramientas que aún no he tenido oportunidad de probar, para gestionar SCRUM: SCRUMWORKS, SCRUMDESK, PLANNING POKER (para estimar tiempos)
En próximos posts escribiremos sobre el estado actual de nitsnets | studios antes de utilizar SCRUM y nuestras reflexiones. Será interesante ver como afecta al rendimiento de la empresa en el futuro, también escribiremos más adelante con nuestras conclusiones posteriores 😉
Gracias por la mención, me ha parecido un buen post.
Un abrazo fuerte.
Hola Elad,
muy interesante el post, además viene como anillo al dedo ya que hace tiempo venimos pensando en esta metodología de trabajo para aplicar a ciertos proyectos.
Todas las referencias que nos han pasado algunos amigos son buenas 😉
Un saludo!!
PD: Tendré que aprender a jugar al poker para que mis estimaciones siempre ganen jiji
Se me plantea una duda con esta metodología, y que en cierta manera entiendo que puede ser la clave para poder aplicarla. ¿Esto se supone que es aplicable a un equipo que tiene encima de la mesa un único proyecto? ¿o serviría para que un mismo equipo simultaneara proyectos? El hecho de contar con un equipo dedicado en exclusiva a un proyecto es complicada dependiendo en qué empresas, qué dimensiones y qué proyectos.
Me planteo que si tienes abiertos unso 5 frentes activos, o digamos 3 para no ser demasiado, reuniones diarias de 15 minutos por cada proyecto se traducen en 45 minutos de reuniones al día, volcar la información en una wiki se multiplicaría por 3, determinadas tareas documentales idem…, además de que tareas implementadas a 2 días vista, implican 3 tareas en 2 días por cada persona, y así sucesivamente si los proyectos son más de 3.
En mi experiencia (y seguramente sea culpa mia no digo que nó, pero en la carrera lamentablemente se me impartió muy poco o nulo conocimiento en como dirigir proyectos reales), el cliente normalmetne hace prácticamente impredecible los plazos de entrega, simplemente en ocasiones tienes que retrasar un proyecto porque el cliente no aporta todo el material necesario, no da el feedback necesario sobre una funcionalidad, o si te emocionas en hacer las cosas bien y le mandas un documento funcional de 20 hojas detallando todo, puede tardar 3 meses en leerlo (o decir que lo ha leido) para decirte que bien, y luego llegarte con que el quería no se qué que no venía en el documento pero que evidentemente él no miró porque eran muchas hojas.
Otro factor importantísimo son los plazos con los que cuentan en ocasiones algunos proyectos… que en el mundo del marketing online a veces son para tirarte por la ventana de un quinto piso que no tienes… por suerte.
En definitiva, soy muy metódico conmigo mismo, y sería feliz si pudiera serlo en equipo, pero en mi realidad práctica profesional me cuesta mucho imaginarme la manera de lograr hacer las cosas tan bien tanto por factores internos como externos!!
Estaré muy atento a vuestros comentarios y evolución, me interesa mucho conocerlos!
Por cierto tios, meterle a esto un plugin para suscribirse a los comentarios de un post, porque sino se hace muy complicado saber cuando la gente aumenta la miga de cada entrada!!!!
Buenas Marcos! Agradecerte el seguimiento que haces del blog y la gran participación que estas teniendo en él.
Como comentas en el siguiente post, a nosotros se nos generan exactamente las mismas dudas con SCRUM y con nuestra organización:
http://www.lostiemposcambian.com/blog/metodologia-de-trabajo/reflexion-metodologia-agil-scrum-en-pymes/
A ver si hay algún SCRUM Master con experiencia que nos ayude a clarificar dichas cuestiones, sino con el tiempo ya os contaremos nuestras sensaciones.
un abrazo muy grande
PD: pondremos el plugin esta semana mismo! gracias
Excelente referencia.. espero puedas publicar tu experiencia usando el Planning Poker…. es una herramienta muy interesante…..
GRC
Te felicito, muy bien explicado, me voy a leer el libro, pero tengo el concepto básico gracias a tu post.
Excelente información. En mi blog http://www.aletecno.com.ar/noticias/metodologias-agiles-de-desarrollo-de-software-scrum-ejemplos-pdf-ebooks.php he creado una entrada con más info sobre SCRUM y Metodologías Ágiles que quisiera aprovechar para compartir. Saludos Cordiales
Estaré muy atento a vuestros comentarios y evolución, me interesa mucho el tema metodologías ágiles. Hace poco participé de unas charlas sobre desarrollo de videojuegos en Formosa y realmente me interesó mucho el tema.
Saludos.