SCRUM ES UN C*NCER... 😵
HTML-код
- Опубликовано: 31 авг 2023
- un usuario de twitter nos comparte en base a su experiencia porque SCRUM es un C*ncer y por que deberías de parar de usarlo
▶ No te pierdas más directos en: / midudev
▶ Discord de la Comunidad: / discord 
Наука
Estuve en una empresa donde se usaba SCRUM como herramienta de acosó extremo, con la única intención de tener a los dev 100% monitoreados, ejerciendo presión si no dabas señales de vida cada 10 minutos (ni al baño, ni a tomar café) habían despidos diarios a quien no se adaptaba y quién no terminaba una barbarie mínima de tareas diarias (mínimo 12) la empresa quebró...
Qué hermoso que quebró, adoro los finales felices!
Por qué quebraría? 😂
@@hectordnc si la gente se va rápido, la empresa no dura mucho. No suelen ser tareas que aprendas en una semana, aparte que por lo que comenta, la gerencia en es la mala
@@ikeduk exactamente. Esas costumbres tan radicales no los dejara avanzar
@@hectordncpor animales, esos cambios toman tiempo, y el maldito de mi ex-jefe, porque no te buscas un trabajo mas tranquilo ? y cuando el perro ese tardo como 2 años mas o menos un proyecto en Scala jajaaj y medio aprenderlo. creen que son los unicos que si necesitan tiempo, mother fuckers eso.
Este año empecé en una empresa que usa SCRUM y lo veo una fuente para crear reuniones sin sentido. Y la mitad de las veces valoramos las tareas sin tener tampoco mucho contexto con lo cual las valoras un poco a voleo, siempre en torno a los mismos puntos de historia. En mi anterior empresa solo respondíamos a un encargado sin tanto protocolo y lo veía todo mucho más cómodo y funcionábamos perfectamente.
Al final mucha gente termina valorando la tarea con el doble del tiempo/dificultad ...'por si acaso', y se pasa la mitad del proyecto tocándose el higo.
Los sprints pasan, el proyect manager acepta lo que le dicen los desarrolladores (porque no tiene ni idea de software) y aquello se va convirtiendo en un cachondeo.
Añade unos cuantos cambios que pide el cliente (porque todos sabemos que al cliente le han dicho que con esta metodología puede meter los cambios que quiera cuando quiera...) y tenemos un perfecto desastre de duración ilimitada.... muchas veces, el escenario genial que quiere la consultora, porque está sigue cobrando mientras haya proyecto y el cliente se ha dejado demasiado dinero como para parar ahora...
Scrum + xtreme programming, las dailys nada
Pero eso funciona hasta que te toca un jefe de proyecto que si sepa, o peor que pueda hacerlo en un cuarto de tiempo que te toma a ti….
Seguramente no estaban haciendo realmente Scrum, no seguían las buenas prácticas que propone, el Scrum Master no era Scrum Master o era junior en ese rol. Tambien hay personas que se llevan mejor con una forma de trabajar más tradicional con un Jefe de Proyecto o Project Manager.
Años haciendo SCRUM, y pensando que era yo solo el que creia que tenia varias cosas que me hacian ruido, mas que ruido, estruendo... este video de midu me da aires liberadores
El Scrum es como el "Tiki Taka" de la programación ya anda perdiendo fuerza.
De scrum lo único que rescato son los artefactos (entregables) y las daylies para nombrar los bloqueantes en caso de que existan muchos procesos dentro de la empresa y requieres apoyo en caso de necesitarlo. Los puntos son la más grande mentira que existe.
Estimar puntos nunca va a ser ciencia cierta, pero si se usan bien uno puede saber si una tarea es mas complicada que otra viendo en el puntaje.
@@errrzarrr como se menciona en muchos lugares el puntaje se usa para medir la complejidad de la tarea, no para medir cuanto te vas a demorar en esa tarea, el que usa el puntaje para medir tiempo lo está haciendo mal.
En mi humilde opinión, el problema es que muchas empresas acogieron SCRUM, y ya podían decir que son agile, porque es lo que está ahora de moda… vendemos agile 😂. Problema… se llega a pervertir la metodología porque al final se hace lo mismo que antes pero con otro nombre. Ejemplo: muy bonito lo de no medir las tareas en tiempo sino en puntos, pero al final los de arriba necesitan saber tiempo. Luego las dailys de 40 minutos 😳. Y como estos puntos, existen más.
Muy de acuerdo. Solo difiero ligeramente en que los de arriba "necesiten tiempo". Considero más bien que "están acostumbrados a planificar en base a tiempos", en lugar de en base a "resultados conseguidos en X tiempo" (que es lo que hace Scrum cuando se aplica bien). Si te das cuenta en ambos puedes conseguir "una fecha estimada", solo que en uno solo tiene que mirar el tiempo en sí y "ignoras los cambios en el volumen de trabajo", y en la otra tienes que ver la cantidad de trabajo y la velocidad para llegar al resultado (que obviamente es más fiable que solo mirar un tiempo desconectándolo del volumen de trabajo a realizar).
@@javiergavilanmerida2133 Totalmente de acuerdo 👍
@@eltrolado5764 En mi caso es igual, me tiro 8 horas delante de la pantalla incluso más, soy autónomo… pero eso no quita que una daily de 40 minutos no es productiva, ni reuniones de 2 horas. A lo que me refiero es que al final da igual la metodología que se use si como dice @javiergavilanmerida2133, si la empresa no cambia el chip, se pervierte. Y como dice Miguel Ángel en el vídeo, hay que ver cuál es tu objetivo como empresa para acoger una metodología u otra. Es como decir que en todos los proyectos vas a aplicar siempre la misma arquitectura porque es lo que está de moda. Pues no debería ser así, hay que analizar el proyecto, ver las necesidades de negocio, etc. 👍
@@errrzarrr totalmente 👍
Estas metodología contraponen mucho el trabajo real, sumado a ello tienes la voz de directivos que piden resultados con un tono "mamón" no encuentro otra palabra. Lo que personalmente rescato de estas metodologías es que uno debe ser ordenado en sus actividades y así logras ser eficiente, entregas pedidos rápido, eso te hace responsable y así sucesivamente. En este caso en particular sería ser flexible en el trabajo, teniendo presente que los objetivos pueden variar, hay otros requisitos. No seguir a pie todas estás metodologías, sino sacar lo bueno y lo que conviene.
Estoy aprendiendo programación web en una empresa, llevo un año aquí y me sorprende mucho el video y leer los comentarios. En mi empresa funciona el SCRUM tan desestresado y tengo solo experiencias positivas que me hace realmente valorar el lugar donde estoy
El problema no es el Framework como tal, es como lo aplican. Muchas empresas lo usan mas como mecanismo de control que para lo que está diseñado, inclusive muchas empresas caen en malas prácticas violando los valores y principios del manifiesto agile.
Justo eso iba a responder... No entienden que es scrum y lo terminan haciendo como una herramienta de acoso y de malas prácticas.
Exacto, dicen usar scrum pero siguen pensando en Gantt
Y para estar modificando a cada momento los alcances del software que ocasiona una descomunal reprogramación.
En mi opinión el Scrum es útil en la etapa de levantamiento de información y el estudio de necesidades y análisis y no usarlo en la etapa de programación y no modificar los alcances del software hasta que se haya terminado el sistema y entonces sí pensar en una nueva versión.
@@joserobertoz8408 dime que no entiendes de metodologías agiles sin decir que no entiendes de metodologías agiles xD
Sí entiendo de metodologías e incluso estoy certificado en modelos de calidad en la industria del software.
Aún así, creo que son varias empresas las que no entienden y creen que es para estar cambiando los alcances y moviendo todo el diseño original, lo cual es absolutamente incorrecto.
Por cierto, mi primer comentario iba dirigido a la persona que puso el comentario inicial y tal vez pensaste que la crítica era hacia tu comentario, así que aclaro que no fue así.
Los puntos no pueden ser traducibles a tiempo de manera directa. Lo más cercano sería entender que cada punto puede significar un rango de tiempo que varía entre los miembros del equipo debido a que los puntos miden complejidad y la complejidad va a ser abordada de manera distinta por cada quien! si no entiendes eso mejor estima en horas y que cada uno diga cuanto cree que le tomara terminar la tarea
He abierto un poco más los ojos, porque mi experiencia fue algo positiva, hasta que empezaron las cosas que mencionas en el video. Lo más gracioso fue cuando la project manager nos dijo que estimáramos una cosa que nunca habíamos hecho y le dijimos que no podíamos estimar algo que no hemos hecho. Y dijo ¿Y cómo no? Y le dije, cuanto la estimarías tú. Y dijo no se nunca he hecho eso xd
Jajajaja es lo malo de tratar con gente que no es desarrolladora. No comprenden que es un proceso. Me pasa seguido tener que estimar algo que no se. Usualmente le doy “puntos altos”. Y justificó como investigación 3 días o 5 si es algo que considere complicado más otros 3 o 5 días de desarrollo porque va a ser prueba y error.
Lo que sea que signifique los puntos también. En realidad cada quien dice 1 punto es un día. Para otros es medio día. Otros literalmente son mínimo 3 puntos a 8. Porque? No se.
@@yohcg Literalmente tenía la carrera de informática xd En la empresa que estoy ahora no hay ninguna daily y el modelo híbrido hace que en vez de esperar a resolver bloqueos preguntes a tus compañeros. Oye sabéis como va esto? Y te ahorras muchísimo tiempo.
jajaja, es un capitulo de condorito mano, jajajajaja
haha @notWinze me pasó lo mismo. Le decía que no podía estimar algo que nunca había hecho y de igual forma tenía que hacerlo, al final como no sabía tuve que inventarme varias cosas. Esto en lugar de hacer que el desarrollador haga mejor su trabajo sólo provoca que el desarrollador busque la forma en como no lo estén molestando. Nadie gana en estos escenarios.
Project Manager y Scrum, aceite y agua ...
Excelente tema, gracias!
Desarrollar software es un acto creativo que a menudo involucra abordar problemas únicos y construir soluciones desde cero. Dado que estamos lidiando con lo desconocido, es complicado prever con total exactitud cuánto tiempo tomará completar un proyecto. En este contexto, Scrum, con su enfoque en establecer 'compromisos' y plazos específicos, a veces puede sentirse como un obstáculo más que como una herramienta útil.
Al subdividir el trabajo en tareas atómicas para adaptarse a estos plazos, los equipos pueden terminar invirtiendo tiempo significativo en la planificación y revisión, tiempo que podría haberse utilizado en el desarrollo real. Es crucial recordar que mientras la estructura y la organización son importantes, deben servir para facilitar el desarrollo, no para estorbarlo.
😉
@@gabrielherz2781 exacto para cosas sencillas o reciclar proyectos o donde hay desarrolladores con mucha experiencia, pero para startups y productos innovadores es limitante
En mi corta experiencia con scrum (o intentos amorfos de scrum), lamentablemente terminaba siendo usado por la empresa para medir productividad, es decir se centraba en el desarrollador o el.equipo más que enfocarse en el PRODUCTO y el valor entregado.
Agrego dato anectdótico: en una empresa en la que trabajé, llegamos a estimar fracciones de puntos (0,5 - 0,3 🤌) en relación al tiempo (1 pto = media jornada). Nada más alejado de la filosofía Scrum.
señor @aaavilaa esto que escribió "es decir se centraba en el desarrollador o en el equipo más que enfocarse en el PRODUCTO y el valor entregado", es la muerte es del agilísimo, buenas palabras
a ver mi experiencia, es de 2 tipos de Scrum en 2 empresas diferentes, y en la primera, era un scrum más llevadero se hacían daily, se hacían reuniones semanales, y bueno los puntos de historia, era 1 punto 2 horas, con eso digo todo, así que al final la dificultad era una media de estimación de lo que te iba a costar, entre dificultad, y laborioso, algo muy laborioso en tiempo pero fácil tenía los mismos puntos que algo muy dificil pero no tan largo, los jefes necesitaban saber + o - cuando se iba a tener una funcionalidad, en la segunda empresa, era dailys pesadas, por cierto los feetback los usaban muchas veces para machacar a la gente delante de los demás, mi experiencia no es positivo, pero como dices fue un scrum adaptado en cada caso a la empresa y sus necesidades
Las retros dependen de que el team esté abierto al feedback pero esto también va para algunos roles "por fuera del equipo" que complican las cosas.
depende mucho de la cultura de la empresa y la calidad "humana" la verdad. yo concuerdo contigo.
Exacto, muchas empresas implementen metodologías ágiles en un célula, pero fuera de esa célula la empresa sigue siendo arcaica y llena de burocracia, scrum no va a funcional igualmente, porque es un tema cultura.
Me quejé de SCRUM en un assessment interno para aplicar a un ascenso y me ascendieron igual, me alegra ver que el Midu comparte mis pensamientos sobre esta metodología, actualmente trabajo en un proyecto con Kanban y no podría ser más feliz, no hay Sprints, no hay Dailys, no hay Retros, solo hay tickets y hay que trabajarlos, sin más.
SCRUM, es bueno si se utiliza bien, desafortunadamente muchas empresas de software para mostrarse como empresas "agiles", usan el SCRUM para cualquier cosa, y lo cierto es que no todo se hace con SCRUM, y además lo hacen muy mal. en ujn proyecto la empresa decidió usar SCRUM para soporte tecnológico, todo era un caos ya que cada caso prioritario que llegaba se tenia que atender en máximo 2 dias; el tiempo y las HU del sprint se cambiaba,; al final la mayor parte de los casos iniciales quedaban como deuda técnica.
Una vez me asignaron una historia de 13 puntos y a medio sprint me asignaron otra historia de 20 puntos, solo una vez expliqué largo y abierto porqué no terminaría todo en un sprint, me estuvieron acosando y como no quedaron las dos historias en un sprint me hicieron un PIP
totalmente de acuerdo con vos Midu. En mi caso luego de que mi equipo incorporó por orden del cliente Scrum, mi performance bajó muchísimo. En un momento había llegado a calcular que de 8 hs diarias de trabajo, solo podía dedicarle 4 al desarrollo. El resto era por temas de Scrum. Me hartaron las planning, retros, weeklies, refinamientos, etc. Salvo tal vez las dailies, que solo insumían 15 minutos al día (aunque igualmente estaban mal aplicadas, porque de tan rápido que uno tenía que hablar, nadie prestaba atención). Scrum es una máquina de quemar desarrolladores, y enaltece a los gerentes, porque les hacés el trabajo por ellos.
De ahora en más, pregunto qué metodología usa esa empresa y cobro en consecuencia, o bien no acepto entrar.
Bro, que no falten tus vídeos para acompañar mi día
Lo acoto a las consultoras. El intento de aplicar métricas a todo, y en concreto el desarrollo, es porque el que está arriba no es tecnológico. Desconoce lo que se tiene que hacer, lo delega, y no entiende nada. Y muchos no quieren ni saberlo ya que consideran que conocerlo, es rebajarse de nivel. P.ej. el COBOL surgió como un lenguaje de desarrollo que el no desarrollador pudiera mínimamente entenderlo, sin desarrollarlo él.
El responsable de desarrolladores tiene que ser un desarrollador que ha evolucionado con capacidades de gestión. Tanto de proyectos como de equipos. Y que tenga capacidad de comunicación con gente que no tecnológica.
Por supuesto que la posición de desarrollador es pasible de ser evaluada en términos de productividad. Si no, no habría diferencia entre desarrolladores vagos y desarrolladores diligentes, como en absolutamente cualquier trabajo.
No es ninguna tragedia ni fiasco.
El problema no es ése. El problema es que muchas veces se pone a valorar la productividad del desarrollador a alguien que no tiene idea de los que las actividades de éste implican ni por qué son como son.
Trabaje en una compañía que tardabamos más tiempo haciendo un sprint planing, más de medio día antes que poder realizar otras actividades más importantes, además era un acoso increíble, los Dailys eran un dolor de cabeza de más de 40 minutos diarios. en fin Odio mucho scrum jajajaja
Scrum es la tunica nueva del emperador, que solo pueden ver los inteligentes.
Definitivamente es un tema cultural... he sido parte de equipos en que teníamos muchas reuniones pero estas nunca se excedian el tiempo definido y eran muy productivas, yo atribuyo esto al hecho de que los "temas" tenían un encargado claramente definido que se encargaba de socializar cosas que había ideado previamente y la reunion era mas para que los demás compartieran opiniones, correcciones y que, en general estuvieran enterados.
También he estado en equipos que supuestamente tienen pocas reuniones pero que las mismas eran tediosas, se solían extender y al final nunca se lograban cubrir todos los puntos que eran requeridos... pero dile al SCRUM master que esto no es optimo y verás como terminas buscando proyecto
La retro es para decidir que se va cambiar a nivel de proceso en el proximo sprint. Ej: ir a 3 semanas en lugar 2, forzar pair programming, cambiar la forma de estimar, cambiar la daily, etc.
En mi opinion los story points o como quieran llamarlo son las medidas mas tontas e ineficientes que existen y se utiliza para ofuscar el proyecto por miedo a decir cuanto tiempo se tarda algo , ni que estuviéramos jugando dungeons and dragons
Increíblemente de acuerdo contigo en todo lo dicho. Scrum para mí se siente como una burocracia solo nos ralentiza
Pues soy nuevo en la programación y tuvimos desarrolando una ecommerce como proyecto final con 7 compañeros y la verdad fue muy bueno. haciamos daily todos los dias. pero eran 15 minutos nada mas y el resto del dia haciamos las actividades diarias sin que nadie te molestara. solo a veces cuando otro compañero te estaba esperando a que terminaras algo. pero muy padre. lo que cuentas son horrores. jajajaja
No todos saben aplicar y no todos saben adoptar Scrum
Coordinadores que no saben delegar ... Recomiendo la lectura de
"ELOGIO DEL IMBECIL: EL IMPARABLE ASCENSO DE LA ESTUPIDEZ" de Pino Aprile para dejar de sufrir en las reuniones con algunos coordinadores ... yo lo recomendé a algunos de mis jefes con resultados casi nunca positivos ...
Personalmente note que cuando pasamos de Kanban a Scrum bajo mucho la productividad en todo el equipo. Las tareas dejaron de ser "terminalo lo antes posible" y pasaron a ser "termina la tarea dentro del sprint". Ademas de que pasamos a tener casi 2 reuniones al dia porque haciamos 1 reunion de refinamiento a la semana y una daily de entre 30 y 45 minutos cada dia. En la daily la lider de equipo hablaba siempre despues de cada miembro del equipo alargando mucho lo que tenia que hablar cada uno y era innecesario porque si queria profundizar con alguno de los tema expuestos se podia quedar hablando con quien corresponda despues e la daily.
"Terminalo lo antes posible" no es bueno. Estoy trabajando en un codigo legacy cuyo equipo solo seguía kanban. Si bien es impresionante lo que lograron construir en solo 3 años, es un dolor de ojos tener que ver la muy pobre estructura que tiene el codigo.
Eso del significado de puntos: Complejidad vs Tiempo es el principal problema de SCRUM.
En una empresa donde trabaje, nos pidieron a 3 devs (entre esos, yo) que tradujeramos cerca de 5k de string de espanol a ingles, una tarea para nada compleja, pero que requeria mucho de nuestro tiempo, pasamos "debatiendo" 3h con la Scrum Master el por que nuestra tarea tenia una ponderacion de 3pts, pero en el comentario indicabamos que tardariamos la semana completa traduciendo.
Ahora ya con chatgpt o deepl en un día... 😅
@@MrNidnan Sí, pero recalquemos: Hoy en día. Hace 8 años era impensable 🤣
@@MrNidnanmenos de un día jaajjaja pero hace 5 años eso era imposible
En resumen si es un cáncer para vigilar a tus esclavos 😂
SCRUM vuelve muy complejo el proceso cuando en realidad el objetivo es simplificar y agregar valor. Hay que volver a la metodología Lean, es simple de entender y de implementar. Hay que preguntar siempre "esto agrega valor"?
SI: hacer y mejorar.
NO: evitar pérdidas de recursos.
Gracias Midu por este video!
Iba a decir eso justamente, siempre lo sentí como herramientas para medir y juzgar al trabajador, para peor muchas veces las empresas son tan inútiles que tampoco saben medir y mejorar los tiempos
No es Scrum es SCAM. En todos lados donde me toco trabajar que decian que lo usaban solo tomaban algunas cosas y me parecian innecesarias.
En el ultimo lugar dnd estuve parecia que era mas importante cerrar tickets que las features que desarrollabas
Lllevo más de 20 años trabajando en proyectos de TI cumpliendo distintos roles y creo que lo único que funciona bien es cuando atomizas todo lo posible un requerimiento y lo llevas a producción con alguien que organice y proteja al equipo de desarrolladores del acoso del cliente que, por alguna razón, muchas veces cree que sabe de lo que habla.
De las empresas en las que ha trabajado que porcentaje usa AWS? O es mas datacenter? Saludos
Scrum es una respuesta del middle managment a su propia obsolesencia.
Tengo que decirlo, en la empresa donde trabajo esta semana despidieron al 70% de los scrums, llevo mas de 2 años en la empresa y JAMAS me hizo sentido el rol, para mi eran solo unas secretarias con otro nombre
Es que técnicamente son eso, secretarios del equipo. Su trabajo es solo uno: Asegurar que el equipo permanece "agile". Para eso solo tiene que "reconducir" cuando el equipo se desvía de la metodología, e intentar dar solución a los problemas que en el equipo se presentan (problemas solucionables por gestión). Es como un "lider de equipo", pero sin liderar nada.
@@javiergavilanmerida2133 ademas son 0 técnicos, no tienen idea del negocio, nada de nada, te juro q es lo más inutil q he visto xD
¿te refieres a los scrum masters?
El problema que yo veo es que no entienden que es la planificacion de un proyecto. Existe por ejemplo RUP (Rational Unified Procces ) que muchos lo toman como waterfull, pero enrealidad es ciclico, y sigue utilizandoce para planificacion de proyectos grandes y luego tenemos una alternativa mas simple como Essence que fue propuesto por ivar jacobson el creador de los casos de uso y posterior OMG lo publico como el standar para planificacion de proyectos. Tienen que recordar que el movimeinto Agile son solo frases y fue propuesto por personas con mucha experiencia en desarrollo, y si pensamos que nosotros podemos manejar los proyectos como ellos sin las herramientas que nos da RUP o Essence estamos pecando de egocentricos.
Un cliente quería usar SCRUM. En SCRUM los proyectos están abiertos, no tienen presupuesto cerrado ni tiempo predeterminado. Todo muy bonito, pero el cliente al final nos seguía pidiendo un tiempo y un presupuesto.
Esto es completamente FALSO.
La idea igual es firmar un contrato al respecto para que no suceda eso
Creo que los profesores de universidad no entienden SCRUM, cómo pretenden enseñar algo que no comprenden?, aprendí más sobre SCRUM en este vídeo que en clase.
Manejar los puntos como invenciones abstractas de trabajo real, siempre terminará en caos. Lo que nos ha resultado mejor es manejarlo como horas estimadas de desarrollo.
Me encontre este video de casualidad y es justamente lo que llevo pensando hace ya varios años, muchas ceremonias , muchas metricas que no suman al proceso y viendo menos calidad del producto y los resultados. Por ejemplo unos board con mas de 20 columnas, casi como CMMI. Una locura. Lo importe como dices en el video es que el producto, software, funcione es la mejor metrica.
Brother.. mientras mas burocracia le ponen a un proyecto mas dificil se hace desarrollarlo a tiempo!!
Scrum es un marco de gestion de proyecto, mas no una metodología de desarrollo de software, por tanto, yo no se porque no implementan algo que si es una metodología de desarrollo como proceso unificado
me encantan tus opiniones midu, eres muy sabio realmente, muchas gracias por compartir :)
Gracias a ti!
Concuerdo con lo de las métricas. Cuando se como en un equipo calculan las métricas, entonces solo tengo que enfocarme en que cosas hacer para que de un lindo número y no por calidad o hacer un buen laburo perse.
El Scrum es como el "Tiki Taka" de la programación ya anda perdiendo fuerza.
Otra cosa que hace que todo sea mas dificil, es el ego de algunas personas en esta industria, se ve gente que sabe y tiene el ego por las nubes como tambien gente que cree que sabe y tiene el ego por las nubes, podrias hablar de este tema? y de la importancia tambien de saber dar un feedback constructivo
Pero scrum es tan ágil como lo quieras hacer, si algo de scrum en tu trabajo no funciona, lo quitas. No te va bien hacer retros? No las hagas. Que prefieres no hacer dailys? No las hagas. La gente se olvida de que el framework se tiene que adaptar a ti, no tú al framework
Esto es completamente FALSO. En Scrum la única cosa donde no hay flexibilidad es precisamente en la metodología. Si no aplicas la metodología a rajatabla, entonces no haces Scrum. Haces un engendro improvisado que si luego sale mal, entonces tienes a las hordas de haters protestando contra una metodología que no estás aplicando. En fin, lo de siempre.
@@errrzarrr yo he trabajado en sprints de una y de dos semanas, he trabajado con scrum sin hacer retros (a no ser que fueran necesarias porque algo haya salido mal) así que no me puedo incluir en tu caso. También he trabajado con diferentes métricas para valorar las tareas, así que igual he tenido suerte. O igual es que los equipos con los que he trabajado han sabido adaptarse bien e implementar bien la metodología
Seria interesante que hablaras sobre las otras metodologías.
Como desarrolladores deberíamos idear una metodología en base a nuestra experiencia, y hacer algo que nos facilite la vida, no que la vuelva un infierno 😔. Te odio scrum (>.
Conoces algo del metodo SWIRL?
es como la biblia depende de quien la interprete
eso es scrum xd pero la aplicacion
Los firmantes del manifiesto ágil son todos desarrolladores de software y en base a sus experiencias acordaron los 4 aspectos a valorar y los 12 principios derivados para facilitar la vida a los equipos de desarrollo de software.
La gran mayoría de frameworks ágiles como Scrum no han sido creados por gestores de negocio, al contrario, provienen del mundo del software y como respuesta a la experiencia empírica sobre qué funciona y qué no funciona en equipos de altas capacidades.
Sin embargo, la aplicación de Scrum, o de cualquier otro framework o metodología ágil, como una herramienta de control de tiempos para negocio es lo que provoca las fricciones.
Negocio espera obtener unas métricas de productividad, para calcular presupuestos y ROI que el desarrollo de software simplemente no puede proporcionar debido a su naturaleza y complejidad.
Yo trabajo con proyectos en el sector público y bancos, y scrum es el cielo, a las metodologías, en donde se duran años preparando sistemas que cuando se instalan ya no sirven por los cambios de condiciones. Imagina que en una, tuvimos que poner el doble de horas porque documentar sobre los parámetros requeridos, era sumamente engorroso y tardado. Otra vez, cual es el fin, hacer bien las cosas y los productos dentro de un parámetro razonable de tiempo y costos, o rematarse como locos para terminar, que creo que el la situación de muchos que comentan aquí.
Por metodologia agil entiendase "cascada en sprints"
Las reuniones es para que los cargos altos y business puedan sentir que el trabajo está en progreso a pesar que hay entregables rapido...
Hola @midu! Me ha gustado mucho el video y el análisis que has hecho. Si en algún momento te planteas profundiza run poco más en el tema e invitar a una persona dedicada en esto, cuenta conmigo!! 😉 Hay muchos conceptos que son mal entendidos y malvendidos, sería genial poder ahondar en ellos :) Como llamarlo metodología o decir que sirve para proyectos, 2 de los grandes errores más comunes.
Gracias por esto, he tenido un día fatal corrigiendo cosas de la UI que estipula el "Designer" del equipo que no tiene idea de programación ni de complejidad de componentes. Mañana tengo retro. Cada día que pasa me doy cuenta más que Scrum es una sarta de reuniones sin sentido. Trabajo en Nueva Zelanda. Saludos !!
Te aseguro que los UX/UI que diseñan entendiendo y minimizando el esfuerzo de front existimos.
Fuerza bro
Recuerdo que hice dos proyectos con scrum. Pero lo que jodia en verdad era la documentación. Mi equipo estaba conformado por vagos, le sabíamos a la programación xD. Las reuniones eran "Hay alguna dificultad con el diseño?, Alguien tiene una queja? Les parece si agregamos estos campos a la base de datos? No? Bien, hagan su trabajo". Fueron buenos proyectos xd
Que miedo programar así.
Después del análisis no debe modificarse el alcance ni agregar campos ni modificar tablas que no se tenga en el análisis original, de otra manera el análisis es una basura y el desarrollo está destinado al fracaso o a desbordar los tiempos máximos.
El verdadero poker de SCRUM es la inflacion de los puntos cuando sabes que el ticket sera tuyo
En mi opinion, el 80% de los problemas de Scrum, viene de cuando insisten en aplicar Scrum cuando no funciona
Cuando definimos un sprint de 1 semana, y un product owner llega a medio sprint, y pide que se haga algo URGENTE y que abandonemos todas las tareas de se habian planificado para ese sprint, porque las nuevas tareas que definio son mas importantes
Scrum funciona cuando TODOS suscriben, incluyendo el usuario final
A la hora de la verdad, cuando el negocio tiene una necesidad que rompe con el flujo de scrum, hay que dejar de seguir el proceso para responder a la necesidad de negocio.
Y scrum funciona mal cuando no se sigue el proceso, las metricas no tienen sentido, y lo que se ha planificado no se completa, proyectos que han sido estimados a largo plazo y planificados para completarse en 5 sprints, no se terminan incluso despues de 1 o 2 años
Cosa rara en el desarrollo de software con clientes, lo bueno es que suelen ser pacientes esas personas con sus requerimientos. 🤣🤣
Scrum no es más que una forma de autogestión adaptativa de equipos pequeños donde sólo hay un director limitado (PO) y un proyecto. La mayoría de los que imponen SCRUM compran el timeboxing, las estimaciones preliminares y el cambiar de objetivos por que les viene estupendo para seguir con su modelo de Project Management totalitario, añadiendo más micromanagement: es querer manejar comandos como batallones (y viceversa).
Totalmente de acuerdo, creo que shape up es el fw de desarrollo de software que más se acerca a la agilidad
Me subscribo, tienes razón, en el momento que la empresa se enfoca en la productividad y no en la calidad pierde mas dinero y tiempo.
Yo estoy llevando mis practicas en una empresa donde usamos azure que tiene algunas cositas de scrum, pero la verdad ya con el equipo nos organizamos mejor teniendo reuniones para charlar de los avances y de las dificultades, me dejaron a cargo del proyecto en el que estaba y mejor avance hemos tenido haciendo lo de programar algunas cosas juntos, asi tmb me entienden mis compañeros
Scrum es un marco de trabajo NO COMPLETO, es algo que nunca se dice. Simplemente da unos lineamientos básicos de como se debería trabajar pero hasta ahí, el framework se completa con lo que la empresa o equipo en cuestión considere apropiado.
La verdad es que hay empresas y colegas que hacen Scrum o creen que están ejecutando Scrum, pero lo hacen mal y lo modifican.
Otro punto es que la mayoria de los devo les cuesta adquirir y aplicar scrum por lo mismo, se sienten algunos monitoriados, otros sienten que es perdida de tiempo. La verdad es que como digo Hay Scrum Master que no saben aplicar bien y ddevs que no quieren adoptar.
También hay que analizar los equipos de trabajos, hay muchas metodologías ágiles el Scrum Master debería saber sugerir cuál es la que conviene más o aplica en determinados grupos de trabajo. Saludos crack te sigo y te tengo de contacto en Linkedin.
Si la verdad en coppel es un infierno esa metodología hay momentos que no avanzas nada pues si trabajas con programación modular carajo el versionado y la ejecución en tiempo real se vuelve imposible acabar un proyecto funcional y todo se reduce a analista dice si a cliente equipo dice si al contrato arquitecto desmenuza y da a cuentagotas lo que supone que es lo que quiere cliente desarrolladores acaban 2 componentes por día tester como loco si el team es de 3 desarrolladores xD y donde truene algo le pega a desarrollador, arquitecto, líder y líder fomentando un ambiente laboral tan tóxico y sin mencionar el consumo de tiempo se las dailys solo genera burnout
Se tenia que decir y se dijo 🗿
El problemas de las metricas es explicada por la ley de Goodhart: "Cuando una metrica se convierte en una meta, deja de ser una buena metrica"
¡Gran análisis del hilo de moda! En la empresa también he abierto este melón y daré la lata porque estoy muy de acuerdo con casi todo. Cómo siempre, lo mejor es tu opinión personal y experiencias. Un abrazo
Es ahí donde el trabajo del scrum máster es vital. Evangelizar al equipo scrum pero de buenas ideas, motivaciónes, etc…
Yo solo tengo 2 llamas el lunes para estar atengo de lo nuevo y el jueves para ver que se hizo y que fallas o problemas hubo, y siempre que alguien este pegado se crea una llamada para el caso en espesifi o con todos los que estén interesados
Management Cientifico
bueno, fuera de broma, hay reuniones donde no se usan esas ceremonias o artilugios y nadie va, o la mitad no participa, o se agarran a las trompadas ... ej las reuniones de consorcio, los tp en 'equipo' cuando haces un curso... etc... creo que es un mal necesario, pero si te bombardean con tanto rollo... es que el que maneja el tema lo hace MAL
y si efectivamente scrum no es para los developers, es para los product owners para saber cuanto tiempo te vas a tardar en hacer algo, y dividirlo,
EL problema con el scrum es que es apto para proyectos pequenos que tienen un principio y un final. Pero cuando se empiezan a gregar cambios, no se tiene un final definido y se convierte en tipo: Haz esto, haz aquello, cambia esto y lo otro, alli si todo se jode,
Eso suena a mala gestion del proyecto. A mis ojos, lo que estás desarrollando es un producto, y dicho producto debería ser escalable. SCRUM vendría siendo una herramienta para gestionar lo que estás desarrollando; donde defines en cada sprint algo nuevo para tu producto, ya sea alguna optimización, nueva implementación, etc... obviamente el alcance (y real) de lo que estás entregando debe ser delimitado en tus sprints. Por lo tanto si en tu proyecto llega una lista indefinida de cambios, por qué no funcionaría scrum?, eso sí, si el proyecto nunca llega a una etapa en la que se le puede entregar al cliente o usuario, yo no culparía a la metodología... ;).
to creo que el pproblema de scrum es que muchos no entienden que un framework solo es una estructura y eso debe ser scrum una estructura para poder llevar un control DEL PROGRESO mas no de la productividad. Al igual que en el desarrollo los framework solo nos sirven para no tener que reinventar la rueda y tener algo mas robusto y estable pero dan la libertad para adaptarse
Jajaja, Yo pienso lo mismo desde que lo comence a usar, estoy certificado en Project Management de PMI y en otras disciplinas, y muy en serio las metodologías ágiles le restan agilidad al proyecto queriendo aparentar que no se mide y al final es como hacer tabiques, ladrillos y te miden y eso es muuuuy malo.
No soy programador pero dónde trabajo solicitamos constantemente algún desarrollo para solventar algún problema o creación de productos, pero se nos dificulta entablar una comunicación fluida por los constantes reuniones o asambleas que se yo de scrum que tiene el equipo de desarrollo. Y el resultado final no es tan bueno o quedan cosas fuera de la idea original para la solución o producto solicitado. Luego hay que solicitar cambios y empiezan los sprint y blabla. Es una molestia y desperdicio de tiempo.
Sin ver el vídeo de los razonamientos de dicha afirmación estoy de acuerdo. Después de ver el vídeo, estoy de acuerdo. En mi último trabajo lo de las reuniones era otro nivel, por ejemplo los miércoles de las 8 horas de trabajo, 4 eran reuniones, los martes eran 2 horas de reuniones, los viernes eran otras 2 horas de reuniones...
La primera empresa en la que trabaje solo dependiamos de las tareas en el Kanban de Trello, en 1 año nunca tuve una reunion, la velocidad de desarrollo era increible y la comunicacion entre desarrolladores era casi nula, solo se diseñaba como se debia ejecutar la tarea, se dividia en minimas partes hasta el nivel de componente y se comenzaba a trabajar. No se que metodologia era pero ese para mi es el maximo de productividad que he visto nunca
Trello está op
Yo haría pair programming con tickets de tareas en un proyecto. cantidad PARES de programadores, trabajo en equipo obligatorio. Armas tareas que van resolviendo y listo JUST DO IT .
Con 1 coordinador de mas seniority
Totalmente de acuerdo, bro
En mi caso particular con el equipo que me encuentro actualmente usamos SCRUM y gracias a eso pudimos medir como evoluciono el equipo en tan solo 1 año cuando comenzamos con pocos History Point por sprint y a final de año haciamos el triple de History Point por sprint, logramos hacer un equipo solido y efectivo
No, no adivinaste no soy el scrum master
Si lo eres , reconócelo 😂
La verdad no, solo soy un desarrollador mas, que tuvo la suerte de tener un excelente equipo de trabajo y un mejor scrum master
@@eduardoherrera6511eres el scrum master we Ya TE cachamos
Pero si no te menten Scrum, te meten Kanban y apurando igual ijjiij
El tema de las reuniones en SCRUM a veces es más un problema que una solución.
XP no me gusta, si bien promueve la colaboración y cohesión entre equipos, también elimina la autonomía, más que nada por las programming sessions.
Por ahi lei sobre D5, y me llama la atención, pero aun no conozco un equipo que la esté usando.
Interesante opinion
ese post que lees se debe llamar "como no usar scrum"
Scrum me parece genial para la etapa de levantamiento de información y para el análisis del sistema y una vez que se tengan los alcances del software a desarrollar, debe irse a la etapa de desarrollo sin hacer uso de scrum para que los desarrolladores puedan hacer uso de su creatividad, concentración y trabajar sin presión porque es lógico que no todos los días se tiene la misma creatividad y por lo tanto unos días se avanza más que otros y queda equilibrado.
Además, las juntas solo deben efectuarse cuando haya un verdadero motivo y solo con las personas que tengan que ver con el motivo de dicha reunión y no durar más de 5 a 10 minutos.
Algo equivocado es decir: "Contratar al equipo de trabajo"... En un equipo siempre habrá el personalista, el flojo, el aprovechado, el trabajador sin comprometerse, los que nunca fallan, los que todo su código les truena y eso es precisamente por llamarle "equipo"...
Vean la diferencia con una orquesta, todos tocan a un mismo ritmo, todos son importantes, cada quien sabe cómo tocar y el momento preciso y es por eso que el resultado es producir melodías fantásticas.
Por lo tanto, en mi analogía, lo fundamental es la contratación de los desarrolladores que encajen a la perfección con la orquesta de software y lo anterior con buen sueldo para que todos trabajen despreocupados y concentrados.
coincido contigo en que SRUM no es una metodologia de desarrollo de software sino de gestion de proyecto.
en ese sentido scrum no funciona ni va funcionar con proyecto de tipo waterfull es decir aquellos proyectos donde se tiene un deadline y ya se tiene definidas las acrividades, eso es gestion de proyectos predictivo ahi aplicar Scrum es el peor error
Sobre el tema de las retros, hubo una vez alguien que intentó convencerme que hacer los comentarios de forma anónima era lo mejor porque asi "no se dañaba el ambiente del equipo". Acá pensé "¿Hay gente que se ofende por algo de feedback?¿Cuantos años tienen? ¿10?". A la gente se le olvida que las empresas ya son el mundo profesional, que no es la escuela ni la Universidad, allá se va a trabajar y te pagan unos sueldazos para que cumplas/logres lo que fuiste a hacer. Y si no lo estás logrando por x o y razón alguien tiene que señalarlo y ver qué se puede hacer al respecto, sin miedo a represarías. Por esa de arriba y otras razones no me gusta ese concepto de las retros, porque no invitan a la gente a ser abierta con sus compañeros en cualquier momento, sino que crea una palestra ahí, donde todos tenemos que ser observados y juzgados en público.
No estoy de acuerdo con las personas que dicen que el desarrollo de Software es unico y un acto creativo, yo más bien creo que se trata de un proceso de manofactura que involucra la menta y pensamiento racional. Pero no se puede dar a los desarrolladores que invidicualmente toman las deciciones de cual seria la manera de desarrollar. Creo que se debe establecer un marco y rutas por las cuales se deben escribir las funciones de los sistemas. Si no, podriamos caer en que unos hagan MVC, otros CQRS, otros Minimal API etc. El departamento debera elegir con que procreso/arquitectura de desarrollo pueden funcionar mejor y adapotarlo y es aqui donde esta el mayor reto y donde hay que ser creativo en realidad, pero en escribir codigo por el mero hecho de escribirlo no. Gracias
mientras leias el texto, cada palabra coincidía con mi actual trabajo JASJ
Estoy cursando una maestría y mi tesis de grado trata justamente de los obstáculos de la metodología scrum para los equipos de desarrollo web, utilizaré mucha información de este video jajajaja, agradecería los nombres de aquellas empresas que quebraron por ser scrum obsesivas y acosadoras.
Woow soy nuevo en utilizar esta metodología y veo que no soy el unico que odia scrum o su mal uso
Desde mi punto de vista, no puedes comparar scrum con metodologías para programar cómo xp pues son niveles de gestión diferentes... Se puede comparar scrum con pmp o pmi...
He visto en algunos casos donde el Scrum es un tropiezo grande dentro de los equipos de desarrollo de software, por ejemplo, he visto casos donde se tenía sprints de 10 días hábiles, se perdía un promedio de 3 días en reuniones innecesarias, ahí empiezan los trasnochos, trabajo los fines de semanas etc.(Se empieza a quemar la gente), además se siente la tensión del equipo y adicional a eso se debía tener la pieza de software 2 días antes para que el equipo de testing pudiera hacer su correspondiente pruebas, reportar bugs etc... adicional a esto se debe confirmar el despliegue a su correspondiente ambiente, porque sino no se tendría valor al cliente dentro de ese sprint... AAAHH y a eso le sumamos las deudas técnicas de los sprints pasados, una total locura.
Parece que trabajaste en la misma empresa donde estaba hace 2 años 😂, y eso si SCRUM es una mierda, donde estoy solo se usan los dailys por slack y si hay bloqueos lo vemos pero nos enfocamos en entregar valor y ya, no hay sprints
#SCRUM no funciona si es implementado por un "ProjectManager que quiere controlarlo todo, tengamos presente que este marco fue ideado por equipos de programadores para reducir la incertidumbre respecto al desarrollo del software, el inconveniente es que se use como herramienta opresiva, eso no es ser #AGILE
Lo primero que te enseñan en un curso de Scrum (y que aplica para cualquier framework) es que se soporta, promueve y sostiene por la corporación. Si tu empresa lo utiliza como un elemento mercadológico y dice que existirá más productividad al vender proyectos, solo traerá renuncias inminentes.
Quienes lo implementan como lo que nació, deben cambiar su esquema comercial, sus procesos de facturación, sus planificaciones y entender que no es para todo ni para todos.
"No sabemos usar scrum, que hacemos? Busquemos a un Scrum Master".
vivimos en un mundo complejo, es mucho mejor adaptar la metodologia al proyecto y no a todos los proyectos aplicarle la misma metodlogia, cada producto cada proyecto son distintos, la flexibilidad y adaptabilidad de las decisiones de la empresa y no que una metodologia mande a todos, porque al final depende de la cultura y del ritmo de los trabajadores también, es como aplicar comunismo a todo un continente, no pues no funcionará cada país tiene sus leyes culturas, etc no puedes aplicar los mismos métodos a todo, el mundo es diferente, es más rapido, más dinamico hay q adaptarse al momento
Las empresas usan muchas veces scrum para que el proyecto manager que no tiene ni idea de desarrollo tenga la ilusión de saber cómo va el proyecto.
Los desarrolladores, cuando se sienten presionados, inflan los tiempos, la complejidad... etc para que no le toquen las narices.
...y por supuesto, cuando entra una problemática de negocio (cliente) se mean en las reglas de scrum.
Es algo artificial, en ocasiones ineficaz, que infla los equipos de la consultora de gente encargada de procesar burocracia (y por tanto la cuenta al cliente).
Un buen proyecto.manager que sea el contacto único con el 'otro lado' con una gran capacidad de interlocucion, de comunicación, y un equipo compensado que trabaje bien junto es mil veces más eficaz... y más barato.
Al final, el único recurso real a administrar es el tiempo… eso de los puntos es una jtería progre