logo

midulive


Transcribed podcasts: 746
Time transcribed: 15d 5h 20m 39s

This graph shows how many times the word ______ has been mentioned throughout the history of the program.

Hay aquí una persona que me preguntaba que por qué ese hate a Scrum.
Scrum, para el que no sepa, es un framework.
Se supone trabajar con desarrollo ágil y todo esto.
Yo como tal no le tengo hate.
Yo no le tengo hate a nada en la vida.
O sea, yo no odio nada.
Bueno, sí que hay cosas que puedo odiar,
pero no tecnologías, frameworks, formas de trabajo y tal.
No las odio como tal.
Lo que sí que puedo odiar es ciertos comportamientos de la gente,
especialmente cuando son nocivos.
Y el problema de Scrum, para mí,
que es un framework que se ha utilizado mucho
para trabajar en empresas ágiles, entre comillas,
el problema de Scrum no es Scrum en sí mismo.
Es la mentira que hay detrás del Scrum, ¿vale?
¿Qué quiere decir esto? ¿Qué mentira?
Pues que la realidad es que Scrum poco a poco
se ha ido pervirtiendo la idea original
hasta convertirse más bien en un framework
para controlar a los desarrolladores
y que ha dejado de ser desarrollo ágil
para convertirse en algo más parecido
a un micromanagement lleno de procesos
y que va totalmente en contra
de realmente el desarrollo ágil,
que era a lo que se supone que íbamos.
Entonces, hay algunas ideas que pueden llegarse a interesantes.
Se vende como que es una metodología ágil,
pero hay muchas cosas que a día de hoy
ya no son tanto metodologías ágiles.
Y una de las cosas por lo que es más interesante,
el manifiesto ágil era para hablar de desarrollo
y Scrum en realidad cada vez habla menos de desarrollo
y habla más de proyectos, ¿no?
Yo creo que se han ido pervirtiendo un montón de cosas
porque a la gente, a las empresas les va bien decir
y hablar de, no, es que somos una empresa ágil
porque utilizamos Scrum.
Y al final no es que sean ágiles porque utilizan Scrum.
De hecho, utilizan un pseudo-Scrum un poco raro.
¿Qué a las empresas les cuesta migrar sus necesidades de control
en cuanto a project management?
Ah, bueno, sí, no, totalmente.
Mira, Scrum es muy burocrático.
Los Scrum Masters son de lo peor.
La gran mayoría de Scrum Masters lo que hace es tedioso el desarrollo.
Trabajo con Scrum y mi Scrum Master está cada rato.
¿Cómo estás, muchacho? ¿Cómo va, muchacho?
¿Cómo va? ¿Cómo va eso? ¿Cómo va eso?
El problema de Scrum es cuando hay demasiados procesos y cosas así
y es un framework que te obliga a seguir ese proceso
y va totalmente en contra al final del ágil, ¿no?
Es para marketing porque involucran al cliente en el proceso.
Son ágiles para los patrones para mantener sentados programadores 24 horas al día.
Ya te digo.
Sí, bueno, esto muchas veces se ponen aquí esas excusas de
sí, sí, que somos ágiles y tal, pero ¿cuándo lo vas a entregar?
Dime en qué momento lo vas a hacer y cosas así, ¿no?
Buenas, ¿y dónde debemos guiarnos y fijarnos sobre Agile o Scrum?
Yo creo que lo mejor de Agile es leer el manifiesto y entenderlo, ¿vale?
Al final yo entiendo que Scrum puede ser necesario en muchos equipos,
pero para que os hagáis una idea de por qué Scrum no suele ser buena idea
es que en el manifiesto se supone que cada equipo debería ser capaz
de decidir cómo trabaja porque debería ser autónomo
y decidir cuáles son sus mejores herramientas de cómo entregar valor al usuario
en el desarrollo de software.
Pero cuando en una empresa todos los equipos tienen el mismo marco de trabajo,
el mismo framework que es Scrum, eso ya te da a entender que en realidad
no están utilizando Scrum para hacerlo ágil, están utilizando Scrum para obligar
a que todos los equipos estén trabajando exactamente igual porque a ellos
les interesa por beta saber qué motivo.
Entonces ya eso debería hacer o leer alguna cosa, ¿eh?
Scrum es... Hola, ¿cómo vas? Hola, ¿cómo vas?
Me acuerdo en un proyecto, dice Phone GoRoute, que premiaban a la gente
que sacaba más tickets en menos tiempo.
A mí me parecía una mala idea, joder, es que es muy mala idea, joder.
O sea, es muy mala idea.
Un proyecto que premia a la gente que saca más tickets en menos tiempo.
Es que no me parece, no me puede parecer más perverso, más perversa la idea.
O sea, es como todo lo contrario seguramente a Jail también, porque el tema no es...
No es... Es que... ¿Cómo os lo explico?
Los tickets no es lo importante, ni siquiera los tickets.
Los tickets no son lo importante, lo importante es el valor que se le entrega al usuario.
Entonces tú puedes entregar un ticket y entregar muchísimo valor o hacer 15 tickets
y a lo mejor no entregarle tanto valor.
Y el que lo haga más o menos rápido tampoco es tan importante,
porque lo importante es el valor que le estás entregando, no cuántas cosas terminas, ¿sabes?
Es que... ¡Oh, Dios mío! Todo mal, todo mal, todo mal.
¿Qué opinión tienes sobre Kanban?
Pues Kanban me parece bastante más interesante que Scrum,
porque es mucho más corto todo el framework que tiene y todos los procesos.
Y sí que se acerca un poco más a la idea de una priorización continua
en la que tú tienes una pila, pero vas pillando las tareas.
Muchas veces en Scrum, para que nos hagamos a la idea,
lo perverso del Scrum, que te digan cosas así como...
¿Pero esto para cuándo lo tienes?
O vamos a hacer un sprint y vamos a meter tanto número de tareas,
como si supieras ya...
Es como... En realidad es un waterfall en pequeñito, ¿no?
Solo que como lo haces un poquito más pequeñito, como que parece...
No tiene... Ese tipo de cosas no tiene sentido.
Pero si el Scrum hace de figura transversal entre el producto y los dev,
podrán saber qué prioridad y cómo entregar valor correctamente.
Ya, pero para eso no necesitas Scrum.
No quiero entrar ahora hasta...
Pero eso no te lo hace el Scrum.
Por ejemplo, con Kanban también lo podrías hacer.
O con Extreme Programming también incluso lo podrías hacer.
Hay un montón de formas de hacerlo.
Que mucha gente se cree, no, es que solo se puede hacer con Scrum.
No, se puede hacer de muchas, muchas formas.
El tema con recompensar el poco tiempo o la cantidad de tickets hechos
es que empieza a aparecer un efecto llamado sandbagging.
Sí, no, totalmente.