Related Articles
Pues esa es la pregunta que un dinosaurio tecnológico como yo, habituado en los años y experiencia a la gestión tradicional de proyectos me hice. Aparte me hice muchas más preguntas sobre el que, como y porque de esta moda y preguntarme tanto me ha traído aquí.
Como todos vosotros lo primero fue una inmersión en Google, algún curso online (os recomiendo UDEMY para esto si no lo conocéis), buscar mas por Internet y volver a preguntarme de nuevo.
En fin, no os voy a contar nada que no hayáis pasado ya. Lo mejor es entrar en un proyecto que lo use con gente experimentada que nos guíe, pero eso no está al alcance de todos ¿no?.
En este post lo único que puedo hacer por vosotros es daros mi opinión y transmitir lo poco que he aprendido. Insistiré más y os seguiré contando, de momento, lo básico es esto, en lo que resumo yo desde mi ignorancia SCRUM aplicado a proyectos de desarrollo de software.
- Imprescindible entregar software utilizable por el cliente en un mes o menos.
- El software a entregar debe dar valor.
- Todos los integrantes del proyecto, tanto equipo proveedor como cliente deben estar implicados y llevar por bandera la mejora del proceso.
SCRUM dispone de herramientas que nos ayudan a cumplir estos objetivos, por ejemplo el Sprint (una serie de tareas a desarrollar en un tiempo determinado que producen un entregable utilizable) es clave para tener resultados en cortos periodos de tiempo. Definir una fecha de cierre corta para unas tareas definidas nos pone como reto finalizar las tareas en el tiempo acordado.
Para saber que hay que hacer en cada Sprint tenemos el Sprint Goal que, de todo lo que podríamos hacer en el Sprint, nos marca que es lo importante. Gracias a esto garantizamos que entregamos software terminado.
Por otra parte dos «palabros» mas;
- Sprint Planning: nos ayuda a definir el Sprint.
- Daily Scrum: reunión diaria que nos ayuda a coordinar el equipo para acometerlo.
El equipo, ¿como es?, ¿quien lo forma?. Esta claro que el equipo de trabajo debe estar formado por personas comprometidas con el resultado y la mejora continua.
Los equipos SCRUM no tienen definidos roles, se autoorganizan y sus componentes en total deben tener todo el conocimiento y capacidades necesarios para hacer ese software de forma autónoma.
El equipo de desarrollo Scrum se guía por el Sprint Backlog o lista de tareas ordenadas a realizar en un sprint, es decir, un plan que les ayuda a inspeccionar y adaptar diariamente su trabajo con el objetivo de cumplir con el Sprint Goal .
Además del equipo de desarrollo es necesario un Product Owner. Y digo UNO porque si diluimos la toma de decisiones entre varios perfiles o personas no es posible llegar a desarrollar en cortos periodos de tiempo.
El Product Owner tiene que ordenar el trabajo del equipo para que no pierdan el objetivo mediante un Product Backlog (lista ordenada que decide con el cliente qué priorizar en cada momento).
El Product Owner utiliza otra herramienta SCRUM, el Sprint Review que nos permite inspeccionar lo que hemos terminado y entregado para adaptarnos en la siguiente entrega y que acertemos con lo que el cliente necesita realmente. Esto puede hacerse a través de las reuniones de retrospectiva y añadiendo en el siguiente Sprint mejoras del producto o del proceso que puedan garantizar una mejora real.
Una figura importante en un proyecto SCRUM es el Scrum Master. Este personaje es como un Yoda del SCRUM, tiene como misión enseñar Scrum al resto de roles y a la organización. Debe hacerlo no solo aplicando las reglas, sino usando los valores, principios y herramientas SCRUM.
El Scrum Master debe ayudar al equipo a conseguir la entrega solucionando los inconvenientes que puedan causar retrasos. Aparte de Yoda es el Mayordomo de Batman 😉
Por último herramientas y software. Al parecer con una pared, un boli y un taco de post-it lo tenemos arreglado, pero hay también mucho software que os puede ayudar (no sea que la señora de la limpieza haga limpieza y envíe nuestro proyecto a la basura). Yo he empezado con TRELLO, es gratis, online y fácil de usar.
Bueno, pues hasta aquí lo que creo que se de SCRUM de momento. Empezaré a aplicarlo en algunos proyectos y con algunos clientes (si el cliente no es receptivo a SCRUM no creo que funcione).