The War of Software

SCRUM. Una Herramienta de Hiper-Productividad

El problema para los desarrolladores es que los cambios en el software se traducen en problemas, especialmente cuando el error puede “tumbar” el sistema completo. Con Scrum se trata de convertir estos problemas en oportunidades.

Para Rugby, Scrum es la forma de reiniciar el juego, después de una falta menor. En cambio, en desarrollo de software, Scrum es una mejora a las aproximaciones metodologicas incrementales e iterativas, que lo que busca es tener una “caja negra” controlada.

El proceso de desarrollo de software es complejo y complicado. Sobretodo si se requiere alta flexibilidad y control. Para esto, la selección de la metodología juega un papel importante para determinar la probabilidad de éxito en el proyecto. Las metodologías ágiles permiten esta flexibilidad, pero eventualmente pueden tornarse impredecibles e impracticas.

Scrum, tiene como premisa ser una “herramienta hiper-productiva”. Su objetivo primordial es encontrar el máximo de productividad de un equipo de desarrollo. Tratando de reducir al máximo la burocracia y los riesgos generados por las actividades no orientadas a producir software, optimizando al máximo el retorno de la inversión y dando valor agregado en corto tiempo.

Este proceso ágil, tiene varias características, una de ellas es que es un proceso iterativo con iteraciones mensuales en las cuales el cliente interactúa con el equipo para saber que quiere desarrollar. Existen 3 actores en Scrum, uno de ellos es el equipo desarrollador (Scrum Team), que es autogerenciado, y sabe que es lo que va a hacer, el cliente que se llama Product Owner que se encarga de saber que funcionalidades son de alto riesgo para el producto y quiere que sea implementado para la próxima iteración mensual, llamada Sprint. Al inicio de cada Sprint, el equipo se reúne en una Sprint Planning Meeting y en conjunto con el Product Owner prioriza las características a desarrollar del producto que están consignadas en un artefacto llamado Product Backlog. De esta priorización el Scrum Team selecciona la tareas que se van a completar durante el Sprint, y estas tareas son “movidas” del Product Backlog al Sprint Backlog que es un artefacto en el cual se almacenan las actividades del Sprint.

Durante todo el mes, se realizan reuniones diarias al inicio del día, llamadas Daily Scrum Meeting, en las cuales se resuelven los problemas que se tuvieron desde la anterior reunión. Los problemas que se deben resolver en los Daily Scrum se basan en dar respuesta a las siguientes preguntas:

- ¿Que hiciste ayer?

- ¿Que harás hoy?

- ¿Hubo algún impedimento para realizar tu trabajo?

Enfocándose solo en lo que se hizo ayer y lo que se hará hoy, se gana un buen entendimiento de la velocidad con que se desarrolla el proyecto. Esta reunión no es para que un jefe recolecte información de lo que están haciendo los miembros del equipo o quien se esta atrasando. En vez de eso, esta reunión es para que lo miembros hagan compromisos con los otros miembros y haya una buena comunicación en el equipo, es decir, alinear a las personas hacia una misma dirección. Esta reunión es coordinada por el tercer actor, el Scrum Master, que (y espero se entienda bien), no es un director de proyectos, es el líder del equipo que se encarga de que los miembro del equipo se compenetren con las practicas y valores de Scrum, vela para que el equipo no se comprometa con cosas que puede cumplir durante el Sprint, además de facilitar y ser responsable de remover cualquier obstáculo que el equipo reporta en las reuniones diarias.

A pesar de que Scrum parece ser un proceso simple, para medianos y pequeños proyectos, no nos podemos dejar engañar. Solo un tercio de las empresas que adoptan Scrum logran implementarlo con éxito. Y no es porque Scrum no sirva, es porque realmente es difícil de implementar, debido a que las organizaciones están estructuradas para construir software de forma tradicional en la cuales los equipos son controlados y comandados por alguien que les dice que hacer, mientras que Scrum requiere de equipos autogerenciados, además de los roles funcionales contra los equipos ínter funcionales con la capacidad de entregar productos al cliente de forma mas rápida. En resumen, es difícil de implementar porque requiere un cambio de hábitos que se han mantenido a lo largo de los años, esto es algo con lo que las organizaciones deben lidiar. Pero la forma de afectar esto es crear cultura, empezando con un equipo a trabajar y ver que no se esta trabajando con un batallón militar, sino como equipo colaborativos, con personas que están pensando como resolver problemas conjuntamente, cuando los otros equipos vean esta forma de trabajar, van a querer saber que esta haciendo ese equipo para ser productivo, y eventualmente los cliente se van a dar cuenta que se le esta entregando software cada mes y va a querer saber como se trabaja y va a integrarse al proceso, y al final toda la organización va a estar trabajando con esta herramienta altamente productiva.

posted by Unknown @ 5:25 p. m.