Cristian Ayala IT Pro

Scrum es un proceso de desarrollo de software iterativo y creciente utilizado comúnmente en entornos basados en el desarrollo ágil de software, en realidad también se puede usar para cualquier sector de la empresa, IT (lo aprendí y practique para el sector de IT en una empresa que estuve “SouthWorks”), Administración, entre otros, ya que sirve para planificar, ordenar, reportar el trabajo del día a día, semanal, mensual, anual.

Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o internos), y el Team que incluye a los desarrolladores o IT’s en mi caso.

Durante cada Stand Up, que dura un periodo entre 15 o 30 minutos (la magnitud es definida por el equipo), cada persona del equipo retroespecta sobre las tareas que hicieron el día anterior y luego le dicen al equipo que tareas van a realizar en el día. Estas tareas las sacan del Sprint Backlog, el cual se hace semanalmente mediante la tarea de Iteration Planning (IP) en donde el Team se compromete y responsabiliza de realizar las tareas que piensan realizar esa semana, las tareas del proyecto ya se encuentran planificadas y cuantificadas en tiempo en el Product Backlog (es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar) y el equipo las selecciona según su prioridad, y se marca objetivos generales.

Hay que tomar entre 6 hs y 8 hs por día para cada persona del Team, no hay que pasarse de las 40 hs semanales por persona así no hace sobre tiempo, y hay que pensar si puede haber un Working Issue.

El IP semanal generalmente se hace al comienzo de la semana (los días Lunes), para el cual se debe encontrar todo el equipo. Estas tares se encuentran en una herramienta Web o de escritorio. El ProductOwner envía las tareas del IP al cliente y las sube a la herramienta que utilicen. Cada vez que terminas una tarea la tenes que marcar como “hecha” en el Sprint Backlog y si estas realizando alguna la tenes que marcar como “tomada”.

Cada día se debe realizar Stand Up al comienzo de cada día, y al final del día se envía un reporte con las tareas que se hicieron y si tuvieron algún problema.

A mitad de la semana, generalmente los miércoles se realiza un Mid Iteration, en donde también debe estar el equipo completo, en este paso se revee las tareas que se tomaron para ver si se van a poder terminar las tareas que se le prometieron cumplir al Cliente, cada integrante del Team dice si tuvo algún Working Issue, y si es que no llegan con algunas tareas se le comunica al cliente sobre este retraso. Si las tareas se terminaron rápido o si alguna no se puede realizar por algún motivo (prioridades) se la saca del Sprint y se le comunica al Cliente, también se agregan nuevas tareas al Sprint.

Al fin de la semana, generalmente los días Viernes se realiza el Iteration Review (IR), en donde se reveen los objetivos generales si se cumplieron, y las prioridades, y las tareas que se prometieron. En esta fase los integrantes piensan en como se sintieron al hacer cada tarea, si tuvieron problemas, si algo no le gusto del Team, etc. Al final de la meeting que hace el Team, se realiza una votación (“a los numeritos”, decía Beto Ortega!, que groso ese compañero de trabajo) sobre los objetivos si se cumplieron, si el Team anduvo bien, si no hubo que hacer sobre horas, si hay alguna queja, etc.

Si surgen algún requisito nuevo del cliente se agrega y actualiza al Product Backlog.

Espero que les haya gustado…