En esta nota les voy a presentar Scrum, seguro que alguno ya lo escuchó nombrar alguna vez, pero no tuvo las ganas de googlearlo. Está bien, a mí me pasó lo mismo al principio.
Scrum nació pensando en lograr conseguir un proceso que permita solucionar los problemas que siempre tuvo la industria en el momento de desarrollar software que trae requerimientos complejos, y que además exige tecnología nueva… lo cual se dice que es el caos. La idea entonces es poner orden en ese caos.
Para esto Scrum define define tres tipos de personas (o grupos de personas):
- Team: es el equipo. Está formado por todas aquellas personas que se crea que se necesita para llevar a adelante el proceso (analistas, programadores, diseñadores, testers, etc…)
- Product Owner: puede ser el cliente, o un proxy que representa a varios stakeholders. Él es el encargado de traer los requerimientos y sus prioridades. Scrum exige una participación activa de este personaje a lo largo del desarrollo. No solo para traer los requerimientos, si no también para ayudar al Team a lo largo de los Sprints.
- Scrum Master: sí, tiene un nombre copado. Sería como He-Man, la idea de este rol es que la persona que lo representa tiene que ser el encargado de que el proceso se desarrolle sin problemas. Es decir, que es el encargado de resolver todos los problemas que se presentan. Por ejemplo, cuando aparece el manager de la empresa a apurar al equipo, aparece el Scrum Master y le corta la cabeza con su espada…, o algo por el estilo. Se podría decir que es el protector del Team, el que tiene que ayudar a resolver los problemas que pueda llegar a haber.
El proceso de scrum se desarrolla de una manera bastante simple:
- Llega el Product Owner con su lista de requerimientos, y las prioridades que cada uno. Los cuales se vuelcan en lo que se llama el Product Backlog, sería un documento en el cual quedan registrados todos los requerimientos.
- Se reúnen el Product Owner, el Team y el Scrum Master, y determinan qué requerimientos se incluirán en el próximo Sprint, que dura 30 días generalmente (el cual en el primer caso será el primero obviamente). La decisión sobre cuáles requerimientos incluir se toma en base a la prioridad que tiene cada uno, se dice que es un enfoque dirigido por riesgos. De manera de tener las funcionalidades más críticas, o importantes, cuanto antes en el desarrollo. El lugar al que van a parar todas las tareas a realizar en el Sprint se llama Sprint Backlog.
- Una vez que se tiene lo que se va a realizar en el Sprint, este comienza. La idea es al finalizar, tener software funcional, y tener listos todos los requerimientos que se pusieron como meta para este Sprint.
- Todos los días, durante el Sprint, se realiza lo que se llama la reunión diaria de 15 minutos. En ésta participan los miembros del Team y el Scrum Master, también la puede presenciar el Product Owner. Aquí cada miembro del equipo responde tres preguntas
i. ¿Qué hizo ayer?
ii. ¿Qué va a hacer hoy?
iii. ¿Qué problemas puede llegar a tener a la hora de hacer lo que tiene que hacer?
A partir de esta información, el Scrum Master (y el resto del equipo), puede saber en qué situación se está en el proyecto. Además, el Scrum Master puede enterarse de distintos problemas que puede llegar a tener cada miembro del equipo, y así solucionarlos.
b. A lo largo del Sprint se trata de implementar y testear todo, de manera de lograr con el objetivo propuesto para este Sprint. Si hubiese algo que no se puede llegar a hacer en este Sprint, se deja para el siguiente, pero de ninguna manera se alarga la duración del Sprint.
c. El Product Owner puede colaborar con el Team, refinando requerimientos, o partipando en el descubrimiento de requerimientos nuevos.
- Cuando termina el Sprint, se tendría que tener software funcional testeado. Las tareas que no se pudieron completar, vuelven al Product Backlog, para ser incluídas en el próximo Sprint.
- Una vez finalizado el Sprint, se lleva a cabo una demostración de lo que se hizo, del software resultante. Aquí participan el Product Owner, el Team y el Scrum Master. Si llegase a haber algo que al Product Owner no le parece, se toma nota, para corregir. Si va todo bien, listo. Se sigue con el paso 2, para planificar el próximo Sprint.
Como se puede ver, lo más interesante que tiene Scrum es que se basa en que el Team trabajando libremente, y con colaboración del Product Owner puede llegar a obtener un producto que de alta calidad, y que satisfasga las necesidades y expectativas del cliente. Así como también permite que a medida que el proyecto avanza, se puedan descubrir requerimientos nuevos, y que le sumen valor al cliente. Y finalmente, puede verse cómo este tipo de proceso de desarrollo ágil, se adapta al cambio muy fácilmente, y lo recibe de la mejor manera.
Creo que como desarrolladores tenemos que conocer, por lo menos mínimamente, cómo es que funcionan las principales metodologías de desarrollo. Tenemos que ser conscientes que vivimos y trabajamos para desarrollar software que ayude a las distintas organizaciones a cumplir sus objetivos, y para poder hacer eso, tenemos que conocer no solo las mejores tecnologías informáticas, si no también los procesos que dan soporte a estas tecnologías.
El año pasado se publicó un artículo en el que se enumeraban las diez habilidades que debería tener un programador para ser competitivo en los próximos cinco años. Entre ellas estaban: metodologías ágiles, habilidades humanas, y conocimiento de dominio. Así que, ténganlo en cuenta.
"El éxito de los proyectos es solo un objetivo preliminar de Scrum. Nuestra meta es crear un ambiente donde los desarrolladores superen las expectativas de la gerencia y creen nuevos productos más rápido de lo que marketing, ventas, y los clientes puedan absorber. Esto permite que un equipo de desarrollo Scrum de primer nivel pueda enfocarse excepcionalmente en conseguir alta calidad y usabilidad, mientras que posicionan a su companían para dominar el mercado." - Jeff Sutherland, uno de los creadores de Scrum.
Links
No hay comentarios:
Publicar un comentario