Primero lo primero

Scrum es una práctica de gestión de proyectos agile, en la cual se beneficia ya que no requiere demasiado tiempo de producción y tiene relativamente pocos gastos generales esto debido que se concentra en la generación de valor iterativo e incremental de un producto, donde la constante medición y monitoreo de un producto es esencial para el éxito del mismo. Esto ayuda de sobremanera ya que ayuda mejorar la previsibilidad y mitigar el riesgo de mismo, que son aspectos fundamentales cuando gestionan un proyecto ya que esta metodología se basa en 3 pilares fundamentales:

• Transparencia
• Inspección
• Adaptación

Primer Pilar, Transparencia

A lo que se refiere con esto es que todas las partes interesadas osea los stakeholders puedan ver el proyecto, el avance del mismo y a su vez que se accesible para poder generar retroalimentación en el transcurso del mismo proyecto. Esto para poder generar un mejor entendimiento de algún requerimiento y dar una definición de “terminado”, esto ultimo en Scrum tiene su propio significado.

Segundo Pilar, Inspección

Scrum propicia la inspección frecuente del proyecto para poder corregir, modificar o redefinir desviaciones que puedan haber en las expectativas del proyecto.

Ken Schwaber, entrenador y autor de Scrum, dice: “Scrum es como tu suegra, señala todos tus defectos. ”

Para esto hay “ceremonias o eventos” en scrum para poder generar observaciones y señalar las cosas que no se están haciendo bien pero con el fin de poder hacerlo de manera asertivas y no se interpongan en el trabajo del equipo.

Tercer Pilar, Adaptación

Durante el proyecto se debe poder inspeccionar el desarrollo del mismo, esto con el fin de poder determinar si se está cumpliendo las expectativas, se está alejando la visión del alcance o surjan contingencias del mismo. Para ello existen 4 herramientas en scrum que ayudan en la inspección y adaptación.

Roles en Scrum

En Scrum y en todo proyecto existen roles definidos que ayudan a la gestión del mismo al encargarse de tareas específicas y poder especializarse en cada rol para dar el mejor resultado posible al mismo, estos son:

Product Owner

El propietario de producto es responsable de la tomar decisiones sobre el producto o la cartera de productos. Estos son parecidos como un consultor dentro del equipo que ayuda a poder aterrizar las expectativas del cliente y poder hacer que sean entendibles los requerimientos del mismo al equipo de desarrollo al priorizar el Product Backlog. El product owner es una sola persona, no es un comité o un grupo, ya que la labor de un product owner es representar a los stakeholders, entenderlos y poder aterrizar las ideas que puedan tener para definir el alcance del mismo, pero ojo el product owner es el único que puede implementar cambios en el producto. Su responsabilidad es proporcionar una serie de requerimientos mediante historias de usuario o el elemento que sea necesario claramente definidas y luego priorizar estos requerimientos en orden de importancia o de generación de valor al cliente. Estas deben ser respetadas y desarrolladas en el orden que es definida por el product owner. Estos al tener la última palabra en lo que se desarrolla el debe asegurarse de que el equipo de desarrollo comprenda lo que se espera de las funciones y requerimientos definidas en el backlog ya que todas las decisiones debe deben provenir de este rol. El propósito de un único punto de contacto con el cliente es para reducir los problemas de comunicación ya que es muy frecuente de que muchas personas pueden entender y escuchar cosas distintas cuando queremos definir que es importante en un proyecto, empezar a construir cosas que no son importantes o peor aún que son innecesarias y que no era lo pedido o esperado por el cliente generando confusión y pérdida de tiempo en reuniones innecesarias muchas veces. Un equipo de trabajo agobiado no es un equipo productivo y hace que se pierda tiempo y recursos. Por lo que el product owner que si bien no necesariamente debe ser un programador debe entender ambos mundos y principalmente debe entender el negocio del cliente, en como el genera valor para el y sus usuario finales.

Equipo de desarrollo de scrum

El principal aspecto de un equipo de desarrollo de scrum es que son auto organizados, me explico: Esto se refiere que nadie, ni el Scrum Master pueden decirle al equipo de desarrollo en cómo tomar la acumulación y convertirlas en incrementos de software funcional. Esto no se debe confundir con seguir alineamientos específicos definidos previamente en el proyecto. Esto principalmente se refiere a que tienen autonomía en el trabajo. Estos equipos son multifuncionales, es decir, que en un principio el equipo esta formado por todos y todo lo que necesitan para completar el producto. Esto si bien pueden haber especialistas que formen parte del equipo de algún area específica no debe depender el equipo de nadie en específico. Además de que en un principio todo integrante del equipo puede llevar a cabo las diversas tareas como codificar, pruebas de funcionalidades, etc…. En el equipo de scrum no existen títulos. (Esto en un principio es así aunque eh visto como en otros equipos se dividen funciones en paralelo para mejorar la productividad, recordar que scrum es un conjunto de buenas prácticas pero con la capacidad de poder adaptarse en diferentes entornos y necesidades). Los equipos de scrum son pequeños idealmente, mas grande de 3 personas y menos de nueve (El product owner y el scrum master no están incluidos en este número a menos que contribuyan al construir código). Una buena forma de poder determinar si un equipo es muy grande es que se deba alimentar a todo el equipo con dos pizzas. La responsabilidad de que se cumpla las metas es de todo el equipo de scrum, no solo de una persona.

Scrum Master

Quizás el rol mas importante en el scrum ya que es la figura que vela para que se cumpla la metodología de scrum como corresponde en teoría, prácticas y reglas. Esto mediante deberes específicos junto al product owner y el equipo de desarrollo. Algunas de as responsabilidades del Scrum Master con el Product Owner puede ser encontrar técnicas para gestionar la acumulación de tareas o requerimientos, ayudando a comprender al equipo las necesidades de poder priorizar las tareas que agregan valor al producto y ayudando como facilitador en las ceremonias de scrum. Algunas de las ceremonias que está implicado el scrum master son:

• Sprint Planning Esta ceremonia es una reunión que se realiza al comienzo de cada sprint para inspeccionar el backlog, los acuerdos que hubieron en la retrospectiva, la capacidad del sprint, el definition of done, para un sprint de 4 semanas este evento llega a durar 8 horas proporcionalmente.
• Daily Scrum Esta es una reunion diaria, la cual no es para planificar ni de dar un estatus de lo avanzado, sino mas bien de poder comentar de bloqueos en la ejecución de la tarea o funcionalidad específica y poder transparentar al equipo, esta reunion no debe ser de mas de 10 - 15 minutos. Se da notificación a los demás integrantes del equipo para que puedan ayudarse entre sí o buscar una solución en conjunto, no en la reunion sino despues de esta.
• Sprint Review Esta es la ceremonia que se hace al final de cada sprint para poder hacer entrega del incremento del producto o un desarrollo de software probado y funcional. Uno de los focos mas importantes en este caso es el poder evaluar los resultados que obtuvo el equipo de scrum al terminar el sprint. Es decir que lo que se busca en esta ceremonia es inspeccionar el incremento del producto y adaptar el product backlog en caso de ser necesario para el próximo sprint. Esta ceremonia varía según la duración del sprint pero como referencia para un sprint de 4 semanas el evento duraria 8 horas.
• Sprint Retrospective Esta ceremonia es el momento donde el equipo de scrum puede ser críticos consigo mismo y se realiza después del sprint review, con el fin de poder buscar areas de mejora, la duración de esta ceremonia es de 3 horas. Lo que hay que buscar en este caso es que a funcionado bien en el ultimo sprint, cuales cosas hay que mejorar en el siguiente sprint, problemas del ultimo sprint y recomendaciones para el próximo sprint.
• Sprint Corresponde a generalmente a 1 o 2 semanas es donde el equipo de desarrollo de scrum pueden ejecutar las tareas que eligieron a ejecutar para el proyecto, los sprints deben mantenerse constantes en todo el desarrollo del mismo para evitar que se cambie el ritmo de trabajo independiente si hay requerimientos que se cumplieron antes de lo proyectado.

Todos estos eventos el scrum master es quien está ayudando a gestionar a que se cumplan en tiempo y frecuencia de estos eventos, esto con el fin de poder tener el alcance de los requerimientos gestionados evitando retrasos en los requerimientos. Y una última cosa importante que lo mencionamos fue el definition of done, es decir, la definición o el consenso que tenemos para que una tarea pueda considerarse como hecha y que su incremento en el valor y el alcance sea aceptado por el product owner. Esto ayuda para evitar tareas a medio hacer o que no se entendieron bien cuales eral los alcances de la misma por lo que el scrum master ayuda en este caso.