Ágil - Scrum Master (Por Makingdevs)

Primero que nada quiero decir que este post, tendrá un poco de teoría y más que nada mi opinión de los conocimientos adquiridos durante el curso y debo aclarar que no soy ningún experto en el tema 😎

¿Que es ser ágil?

Para mi este concepto significa la capacidad que tiene una persona para adaptarse ante cualquier tipo de proyecto o situación. Así mismo nos menciona que esté enfoque ágil combina a las personas sensibles en colaboración con objetivos demostrables y concretos.

La verdad es que siempre se obtiene un manifiesto ágil como se ve en la siguiente imagen, sin embargo la verdadero importancia se encuentra en como lo aplicamos en nuestros proyectos de software.

Siempre que se hace referencia a nuevo proyecto es muy cierto que nuestra principal prioridad es la satisfacción del cliente mediante entregas continuas y oportuna.

Pero es importante saber que en el mundo habrá clientes que tengan contratos fijos con prioridades importantes a las cuales ellos le otorgan un lapso de tiempo considerado por ellos mismos, por eso mismo siempre tenemos que cargar con 3 simples verdades que nos salvaran en los proyectos:

• Es imposible obtener todos los requerimientos al principio de un proyecto.
• Cualquier requerimiento que obtengas esta garantizado a cambiar.
• Siempre habrá mucho mas por hacer que lo que el tiempo y dinero permitan.

Desarrollo interactivo incremental.

El propósito de esta herramienta, se trata en planificar el proyecto en diferentes iteraciones donde el cliente logre ver cambios y avances importantes de tal manera que se alimente su perspectiva del proyecto y así mismo pues tomar mejores decisiones en el transcurso del mismo.

Una de las ventajas mas importantes de esto es que podemos tomar los requisitos más significativos para el cliente con el fin de que estos ya puedan ser usados por el cliente desde la primeras iteraciones.

¿Como lo hago?

Para llevar acabo estos métodos ágiles existe el Scrum Master

¿Que es?

Scrum Master, es importante tener muy en cuenta que NO es una metodología es un framework que nos servirá como guía en nuestros proyectos y nunca como una religión, más adelante me entenderán porque lo hago mención.

Es un enfoque esbelto para el desarrollo de software, como un marco simple donde se busca organizar a un equipo y realizar su trabajo de forma más productiva con mayor calidad.

• Se centra en dar prioridad al trabajo con mayor valor para el negocio.
• Se adapta a las necesidades cambiantes durante el proceso.
• Permite al equipo dar la prioridad a las necesidades del cliente.

El equipo:

• Product Owner -> Responsable de tomar las entradas de requerimientos para el producto y también funje como el conocedor del negocio (No hace estimaciones)
• Miembros -> Construyen el producto que el cliente va consumir, conocimientos técnicos. gestión de auto-organizado.
• Scrum Master -> Responsable de asegurar que el equipo se adhiera a los valores de Scrum, practicas y norma, más que nada es un facilitador nunca un lider de equipo.

Artefactos:

• Product Backlog -> Lista de características priorizadas por valor de negocio y es dinámico
• Product Backlog Item -> Especifica el QUÉ, no el CÓMO, de una función centrada en el liente, se recomiendan las “User Story”

Para ello también existen faces representadas de la siguiente manera

Este framework también nos dice que a medida que vamos realizando que requerimientos y pasandolas a tareas pequeñas, estas deberán ser catalogadas por puntos de esfuerzo para que de esta manera logremos identificar cuales son las tareas mas importantes para el proyecto y a partir de ellas comenzar el desarrollo.

En mi opinión un aspecto muy importante con respecto a lo que dije en un principio sobre que scrum es una guía y nunca una religión, hago referencia a lo siguiente:

Daily: Se nos recomienda que nunca pasen de 15 minutos y buscando que solo se exprese de manera concreta en donde se encuentra la persona, ahora suponiendo un ejemplo donde somo 2 desarrollares y cuando hacemos nuestro daily, usamos 10 minutos o menos, no significa que debamos buscar llegar a los 15 como lo dice el framework. Aquí jamas se resuelven los problemas de la persona, solo enfocarte a escuchar y posteriormente si alguien tiene el conocimiento o la respuesta se deberá acercar a él.

Sprint: Se da la recomendación de que sean 1 - 4 semanas constantes en lo personal me gusta mas la idea de una vez a la semana ya que entregamos constantemente y así tenemos la confianza de nuestro cliente de tal manera que si existen cambios en los requerimientos se puedan tratar lo más antes posible.

Por otro lado un scrum master jamas debe ser un lider, al contrarió “el mejor scrum master, es aquel que tiene la capacidad de perder su trabajo lo mas rápido posible” y con esto me refiero a que en el memento que el equipo sea capaz de llevar el framework por ellos mismo, ya no será necesario dicho scrum master.

¿Se puede ser programador y Scrum master a la vez?

La verdad es que esta tarea se considera como de tiempo completo, si se quiere ejecutar de manera óptima, sin embargo se considera que cualquiera que tenga conocimiento de los valores ágiles y del framework puede actua como scrum master, considerando que sus demas tareas se pueden ver afectas en su velocidad.

Estimaciones

Este es un tema que a todos nos interesan notablemente ya que todos buscamos, realizarlo de manera correcta en la proyección de un proyecto y siempre creemos que el único factor a considerar es la experiencia de la persona en dicha tecnología pero propongamos una metáfora.

Listo?

Nosotros somos personas expertos en comer ya que llevamos toda nuestra vida comiendo, entonces hagamos lo siguiente:

• Predice en cuanto tiempo comes una galleta y después cómela.
• Le atinaste al resultado? supongamos que tardaste 40 segundos en comerla, entonces si debiéramos comer 10 galletas seguidas.
• Tardaríamos 400 segundos?.

Y lo mas seguro es que no logremos hacerlo seguro porque interfieren otros factores como la capacidad de cada persona para comer, o que tal vez necesites un baso de leche para realizar la tarea, lo importante ver aquí es que son esfuerzos totalmente diferente y es por eso que ágil propone catalogar a las tareas como puntos de esfuerzo.

¿Pero como deduzco estos puntos de esfuerzo?

Por este punto siempre se debe hacer la estimación de las tareas junto al equipo, donde todos tengan una participación en base a la experiencia como linea de aprendizaje, vaya es mas importante considerar este punto porque si nos conocemos, sabemos que tan rápido podemos aprender una nueva tecnología o en su defecto resolver una tarea difícil, sabiendo cuanto esfuerzo deberemos dedicarle.

Para ello se propone que te bases en la sucesión de Fibonacci “1..2..3..5..8..13..” ya que con ello lograremos hacer estimaciones no perfectas pero si más acertadas, ejemplo:

1 pt = 3 horas

De esta forma nos obligamos a considerar mas cosas a nuestro al rededor y hacer estimaciones que contemplen cosas que no estas predichas, como por ejemplo algún problema personal o dificultad en el día.

Para esto también es muy importante la comunicación del equipo para que ellos logren apoyarse entre si cuando uno se encuentre en un problema ya sea personal o con la tecnología.

Y es aquí cuando se ve verdaderamente la importancia de los daily, para lograr saber en que se encuentra cada integrante de nuestro equipo.

Una herramienta que nos puede ayudar notablemente a este tipo de organización es la herramienta KANBAN lo cual nos sirve para gestionar nuestro trabajo intelectual.

TO DO: Items del product backlog a realizar en un sprint por el equipo.

DOING: Tareas que se encuentran en desarrollo.

DONE: Tareas que hemos terminado.

Y con este tipo de control lograremos tener proyecciones del avance incremental que hemos tenido a lo largo de nuestro proyecto en cada sprint.

Conclusión

En lo personal creo que el tomar este curso más que darme conocimiento ya sea teórico o practico me cambió como persona ya que ahora veo que lo mas importante para que una persona pueda ser ágil no son las habilidades profesionales, si no más bien nuestras aptitudes y valores que nos constituyen como persona, un claro ejemplo de ello podría ser la siguiente frase:

“Nuestro mejor tiempo como individuo es nuestro peor tiempo como equipo y nuestro peor tiempo como individuo es nuestro mejor tiempo como equipo” -> José Juan Reyes Zuñiga.

Y es muy cierto porque en el momento que nos detengamos a ver que nuestro equipo avance como uno solo veremos que al final obtendremos mejores entregas y calidad en nuestros proyectos.

Otro aspecto que me costo un poco trabajo de ver fue que naturalmente el mundo nos acostumbra a que lo mejor que podemos aspirar es a ser un lider dentro de un equipo u organización, pero la verdad es que un scrum master es más humilde ya que busca que él equipo sea autodidacta con el framework y así mismo el crecimiento de las personas, al contrario de los lideres donde siempre se va caracterizar el nivel de jerarquías.