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Ãģ...
@@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
11 āļŦāļĨāļēāļĒāđāļāļ·āļāļāļāđāļāļ +1
â@@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...
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
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.
@@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.
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.
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.
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
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.
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
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).
@@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. ð
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.
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.
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.
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Ã.
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
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
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.
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.
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.
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.
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.
7 āļŦāļĨāļēāļĒāđāļāļ·āļāļāļāđāļāļ +2
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
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.
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
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
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
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
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
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
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 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.
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.
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.
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.
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.
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 ...
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.
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.
aaaah Cascagil, una maravilla. Donde ya se definiÃģ cuando tienes que terminar, pero pierdes tiempo estimando con fibo-shirt-poker y no importa que cambien los requisitos porque somos ÃĄgiles, nos adaptamos, pero la fecha no se mueve
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.
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 !!
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
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.
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 (>.
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Ã.
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.
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
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.
Entiendo los comentarios considerando que en todos los casos se analiza desde el punto de vista del programador, mÃĄs no desde la vista del directivo de los equipos y a que apuntan las empresas. Las miradas del proceso son distintas y tienen distintas aplicaciones.
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.
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
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).
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.
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.
Yo no estoy del todo de acuerdo, la idea de meter Scrum es entre otros para medir la productividad del equipo, no del programador. Lo que se desea es saber como trabaja el equipo y la capcidad que tiene de aÃąadir valor a la empresa. TambiÃĐn te obliga a trabajar en tareas pequeÃąas e intentar ir sacando releases cada menos tiempo, para ir finalizando tareas y subiendolas a producciÃģn en periodos de tiempo mÃĄs cortos. No sÃĐ, es mi opiniÃģn, pero hay que saber adaptar bien la metodologÃa al equipo, y no seguir al 100% toda la teorÃa.
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.
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.
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
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
En scrum no se utilizan mÃĐtricas. Por lo que dice el post y lo que comentas tu en el video, es como dices, el scrum que se usa no es el verdadero scrum, claramente se nota que las cosas estÃĄn mezcladas... scrum no tiene nada que ver con las mÃĐtricas ni andar midiendo. Scrum estÃĄ mal utilizado, la gente no sabe usarlo y por demÃĄs se hace scrum como lo indica los jefes, la administraciÃģn y etc.... es decir, gente que no sabe de scrum que son gestores de proyectos, gestores del dinero son los que manipulan y tergiversan todo y manipulan el scrum para seguir haciendo o empeorar las cosas. Si contratas a un Scrum Master debes dejar que ÃĐl diga como son las cosas, no contratar a un Scrum Master y que sea un titere de los gerentes... eso es lo que estÃĄ mal y ellos que se dejan manipular. Lo que dices es cierto, el Scrum que ustedes viven no es el Scrum que se debe aplicar. Lo aplican mal, punto y lo que deben hacer es ver cuÃĄl, si el kanban, el xp, etc, cuÃĄl se adapta a su modelo de negocio no es implementar por implementar, scrum no se adapta a todo.
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
En mi experiencia, un buen equipo scrum donde se comprende "quÃĐ es eso" a todos los niveles funciona muy bien. ÂŋCual es el problema entonces? Que en el 90% de los casos no se comprende (sobretodo en los niveles superiores): Dailys eternas cuando solo debÃan ser de 10min (una visiÃģn superficial para corregir la planificaciÃģn y FUERA DE LA DAILY resolver bloqueos), puntos de esfuerzo que mapean 1 a 1 con una estimaciÃģn de tiempos (cuando se supone que se usan en lugar del tiempo precisamente para realzar que es una estimaciÃģn y no "una fecha de entrega pactada con sangre"), retrospectivas donde se piden mejoras frenadas por los superiores, introducciÃģn y estimaciÃģn de historias sin refinar dentro del sprint, historias nuevas a mitad de sprint... o sea, al final la mayorÃa de equipos scrum, no son mÃĄs que "otra forma de waterfall, pero peor". Por otro lado, en los pocos equipos que he trabajado que, en mi opiniÃģn, lo sigue mÃĄs acertadamente: Dailys realmente de 10 min o menos, puntos de esfuerzo usados mÃĄs para decidir quien se encarga que cuando tiempo se tardarÃĄ en hacer una tarea, si una tarea no se completa en un sprint simplemente se deja para el siguiente sin ningÚn tipo de drama, las historias de usuario llegan a la planing ya refinadas, por lo que son reuniones relativamente rÃĄpidas, las mejoras a pedir de un sprint al siguiente eran pocas (porque las que iban surgiendo se implementaban rÃĄpidamente), las historias nueva COMO PRONTO son para el siguiente sprint... un "TODOS estamos comprometidos con hacer un buen trabajo por encima de hacerlo rÃĄpido, y el software se entregarÃĄ cuando estÃĐ listo, necesite el tiempo que necesite" completamente contrario a waterfall. Repito, es solo mi experiencia ð PD: TambiÃĐn en mi experiencia, Kanban en el mundo del desarrollo apesta, no por kanban en sÃ, sino porque es muy fÃĄcil de pervertir y que se convierta en caos (cosa que por desgracia, es el Único caso que he conocido) PD2: En un buen equipo scrum, un "lider tecnolÃģgico" no es nada mÃĄs que alguien con mÃĄs conocimiento. No manda en nada, no dirije en nada, y no decide en nada por sà solo. Asà mismo, un buen scrum master habla solo lo mÃnimo necesario, y el product owner es solo "otro compaÃąero, pero funcional en lugar de tÃĐcnico". Recordemos que se supone que un equipo scrum es autogestionado POR LOS DESARROLLADORES (si, todos, no solo el lider tecnolÃģgico), siendo los distintos roles solo una cuestiÃģn de asegurar que la metodologÃa se cumple (Scrum Master. No, no es un jefe, y por tanto no puede mandar nada) y toma de requisitos/feedback del cliente (Product Owner. No, tampoco es un jefe, asà que tampoco puede "mandar" nada). ÂŋEl generente? Ese si puede mandar, pero en un verdadero equipo scrum no entra hasta que llega el momendo de las demos.
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.
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
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.
Todos , absolutamente todos los puntos planteados denotan mala interpretaciÃģn de Scrum y un mal uso del mismo. Si un medico no te puede ayudar cuando estÃĄs enfermo, el problema es el medico o la medicina como disciplina?
Alguien sabe como evitar usar esos mald1tos puntos de historia?, cambio de paradigma, cultura, a estas alturas estoy abierto a todo tipo de sugerencias
Malditos puntos!! Trabaje en un equipo con sprint de dos semanas. A una tarea le puse 3 puntos e iba mÃĄs de una semana con el tema. Cuando me preguntaron porque demoraba tanto les dije que ellos habÃan definido los puntos como el esfuerzo o complejidad de la tarea y no con el tiempo. Entonces la tarea que debÃa hacer era tres puntos porque era sencilla pero tenÃa que realizarla varias veces en varios mÃģdulos. No sabÃan que responderme ððð
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
Casualmente hoy tuve un refinamiento. Y uno de los lÃderes de proyecto estaba mÃĄs preocupado por los story points y si eso reflejaba el tiempoâĶ.ð
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
ðŊ Key Takeaways for quick navigation: ð Kanban es una metodologÃa ÃĄgil alternativa a Scrum, que se enfoca en flexibilidad y adaptabilidad. ðĄ Kanban se basa en dividir tareas grandes en partes mÃĄs pequeÃąas y visualizar su progreso en un tablero con columnas como "pendiente", "en proceso", "terminado", etc. ð El uso de Kanban favorece la transparencia y la coordinaciÃģn del equipo al mostrar claramente el estado de cada tarea. ð Las tareas se mueven entre columnas segÚn avancen, lo que permite un seguimiento eficaz y una priorizaciÃģn adecuada. ðž Kanban es menos burocrÃĄtico que Scrum, lo que lo hace mÃĄs accesible y fÃĄcil de implementar. ð La metodologÃa Kanban es Útil tanto para equipos pequeÃąos como grandes, ofreciendo flexibilidad y control. ð Facilita la divisiÃģn del trabajo y la organizaciÃģn del equipo, lo que mejora la eficiencia y la productividad. ðŊ Aplicar Kanban en el desarrollo de proyectos puede ser beneficioso para cualquier tipo de empresa, promoviendo una gestiÃģn mÃĄs ÃĄgil y eficaz. Made with HARPA AI
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... ;).
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.
El problema de scrum son los scrum mÃĄster 100% dedicados a ello, posiciones en sà solo de esoâĶ que presionan al resto para usarlo a su manera y de un dÃa para otro te cambian su metodologÃa porque al final su trabajo ya estÃĄ hecho una vez el equipo anda solo, pero al final su trabajo depende de reenseÃąarlo otra vezâĶmodificarlo etc..
No se usa bien scrum y es imposible usarlo bien, entre otras cosas porque en una empresa tecnologica no puedes esperar al siguiente sprint para programar la resolucion de un problema sangrante de seguridad, que puede ser o no contingente, por ejemplo, una eventualidad de esas te rompe todo, asi con bugs y otros. tampoco puedes dejar a un cliente esperando a 15 dias a que arreglen la verificacion de tu pais por celular se ha daÃąado en el fomulario y es una solucion de 15 min (me paso), que para lograrlo tienes cosas como CI/CD y que te permite hacer esos hotfix en infrastructuras complejas, y que si lo tienes hace aun mas tonto que uses scrum, o lo usas y te ahorras CI/CD o lo pones y quitas el scrum. Scrum no esta hecho para el mundo de hoy, es para sistemas que no estaban expuestos a internet, que a las empresas no le importaba tener a la gente meses para sacar un arreglo de una cosas pequeÃąa, y que el software se hacia hasta que se consideraba terminado, hoy en dia todo esta en crecimiento y arreglo. no esperas a que el software este terminado, simpre estas validadando en el mercado para ir modificÃĄndolo segun lo que te diga el mercado.
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
#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
11 āļŦāļĨāļēāļĒāđāļāļ·āļāļāļāđāļāļ +2
Pero si no te menten Scrum, te meten Kanban y apurando igual ijjiij
La primera parte es magnÃfica. Sin embargo, Scrum NO es para gestionar proyectos. La palabra proyecto no estÃĄ en Scrum y tampoco la palabra estimar. Me ha encantado lo de "hay mucha diferencia entre Scrum y el Scrum de las empresas"
En realidad aplican lo que se les canta, no lo que realmente es SCRUM, una sola vez en todas las empresas donde he trabajado realmente he hecho SCRUM, en esa experiencia solo habÃa una Scrum Master de los que te forman para ser Scrum Master, o sea una persona que sabÃa que era SCRUM... Era otro mundo, prÃĄcticamente diferente a lo que las empresas dicen que hacen (pero no lo hacen ni por mierda).
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.
Bajo mi punto de vista, sobre las quejas de encajar los puntos de dificultad en rangos de tiempo, creo que no es nada descabellado, los puntos miden dificultad, y cada desarrollador tarda un tiempo distinto en completar esa dificultad, un junior a lo mejor tarda una semana en hacer 3 puntos, y un senior 1 dÃa, pero son 3 puntos para los dos. Entonces, como cada tarea va asignada a un desarrollador, y tenemos un histÃģrico de quÃĐ velocidad tiene (cuantos puntos al dÃa suele hacer, por ejemplo) es viable predecir cuÃĄntos puntos podrÃĄ hacer ese desarrollador en ese sprint, y cuÃĄntas tareas asignarle. Si al final resulta que no se cumplen los plazos, probablemente sea porque la tarea no estaba bien estimada, y era mÃĄs difÃcil de los puntos que se habÃan estimado, pues se aumentan los puntos de la tarea para reflejarlo y listo. Cuando a mi me preguntan porquÃĐ estoy tardando mÃĄs de la cuenta, me lo preguntan porque quieren saber si la tarea estÃĄ bien estimada o no, no porque se estÃĐ poniendo en duda mi profesionalidad, al menos, ese ha sido mi experiencia, entiendo que habrÃĄ de todo.
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.
Creo que el problema estÃĄ en las empresas que no saben implementar Scrum, ademÃĄs existe la idea de medir productividad individual y el error de creer que "ÃĄgil" es equivalente a "trabajar rÃĄpido". Creo que muchos equipos de desarrollo dicen que usan Scrum (u otra metodologÃa que escucharon) por moda como lo fue en los 90 con el tema de la "reingenierÃa" . Se nota mucho cuando no entienden de generar un producto mÃnimo viable y el tema de las iteraciones o sprints, normalmente no se tiene claro lo que se debe construir, se controla quien no se queda hasta tarde trabajando, se quiere todo el software terminado para ayer.
El problema con SCRUM es que mucha gente que jamÃĄs ha tirado una lÃnea de cÃģdigo decide como se va a desarrollar y se les da mÃĄs importancia a sus "recomendaciones" que a los lÃderes tÃĐcnicos y precisamente si jamÃĄs haz tirado una lÃnea de cÃģdigo como carajos determinas productividad de un desarrollador.
Scrum no es el problema, el problema es cÃģmo se usa. Yo uso una mezcla de scrum y Kanvan y es lo mejor que he probado. No hacemos estimaciones, sino que intentamos dividir todas las taeras en subtareas que tengan mÃĄs o menos la misma complejidad, y suponemos complejidad 1
Habla por favor de la burocracia en los pipeline de deployment!!! Eso si que es insoportable!!! Especialmente cuando los equipos usan Gitflow!!! (que esta muy desaconsejado en todos lados)
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
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...
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
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.
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
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.
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
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.
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Ã.
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
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.
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
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.
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.
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.
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
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.
Scrum es la tunica nueva del emperador, que solo pueden ver los inteligentes.
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
En resumen si es un cÃĄncer para vigilar a tus esclavos ð
Bro, que no falten tus vÃdeos para acompaÃąar mi dÃa
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
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
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
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. ðĪĢðĪĢ
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
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 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.
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
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.
IncreÃblemente de acuerdo contigo en todo lo dicho. Scrum para mà se siente como una burocracia solo nos ralentiza
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?
me encantan tus opiniones midu, eres muy sabio realmente, muchas gracias por compartir :)
Gracias a ti!
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.
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 ...
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
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.
aaaah Cascagil, una maravilla. Donde ya se definiÃģ cuando tienes que terminar, pero pierdes tiempo estimando con fibo-shirt-poker y no importa que cambien los requisitos porque somos ÃĄgiles, nos adaptamos, pero la fecha no se mueve
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.
Scrum es una respuesta del middle managment a su propia obsolesencia.
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
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
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.
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Ã.
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.
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
El verdadero poker de SCRUM es la inflacion de los puntos cuando sabes que el ticket sera tuyo
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
Entiendo los comentarios considerando que en todos los casos se analiza desde el punto de vista del programador, mÃĄs no desde la vista del directivo de los equipos y a que apuntan las empresas. Las miradas del proceso son distintas y tienen distintas aplicaciones.
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,
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.
Brother.. mientras mas burocracia le ponen a un proyecto mas dificil se hace desarrollarlo a tiempo!!
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
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).
Por metodologia agil entiendase "cascada en sprints"
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.
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.
Yo no estoy del todo de acuerdo, la idea de meter Scrum es entre otros para medir la productividad del equipo, no del programador. Lo que se desea es saber como trabaja el equipo y la capcidad que tiene de aÃąadir valor a la empresa. TambiÃĐn te obliga a trabajar en tareas pequeÃąas e intentar ir sacando releases cada menos tiempo, para ir finalizando tareas y subiendolas a producciÃģn en periodos de tiempo mÃĄs cortos. No sÃĐ, es mi opiniÃģn, pero hay que saber adaptar bien la metodologÃa al equipo, y no seguir al 100% toda la teorÃa.
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.
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.
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
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
En scrum no se utilizan mÃĐtricas.
Por lo que dice el post y lo que comentas tu en el video, es como dices, el scrum que se usa no es el verdadero scrum, claramente se nota que las cosas estÃĄn mezcladas... scrum no tiene nada que ver con las mÃĐtricas ni andar midiendo.
Scrum estÃĄ mal utilizado, la gente no sabe usarlo y por demÃĄs se hace scrum como lo indica los jefes, la administraciÃģn y etc.... es decir, gente que no sabe de scrum que son gestores de proyectos, gestores del dinero son los que manipulan y tergiversan todo y manipulan el scrum para seguir haciendo o empeorar las cosas.
Si contratas a un Scrum Master debes dejar que ÃĐl diga como son las cosas, no contratar a un Scrum Master y que sea un titere de los gerentes... eso es lo que estÃĄ mal y ellos que se dejan manipular.
Lo que dices es cierto, el Scrum que ustedes viven no es el Scrum que se debe aplicar. Lo aplican mal, punto y lo que deben hacer es ver cuÃĄl, si el kanban, el xp, etc, cuÃĄl se adapta a su modelo de negocio no es implementar por implementar, scrum no se adapta a todo.
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
En mi experiencia, un buen equipo scrum donde se comprende "quÃĐ es eso" a todos los niveles funciona muy bien. ÂŋCual es el problema entonces? Que en el 90% de los casos no se comprende (sobretodo en los niveles superiores): Dailys eternas cuando solo debÃan ser de 10min (una visiÃģn superficial para corregir la planificaciÃģn y FUERA DE LA DAILY resolver bloqueos), puntos de esfuerzo que mapean 1 a 1 con una estimaciÃģn de tiempos (cuando se supone que se usan en lugar del tiempo precisamente para realzar que es una estimaciÃģn y no "una fecha de entrega pactada con sangre"), retrospectivas donde se piden mejoras frenadas por los superiores, introducciÃģn y estimaciÃģn de historias sin refinar dentro del sprint, historias nuevas a mitad de sprint... o sea, al final la mayorÃa de equipos scrum, no son mÃĄs que "otra forma de waterfall, pero peor".
Por otro lado, en los pocos equipos que he trabajado que, en mi opiniÃģn, lo sigue mÃĄs acertadamente: Dailys realmente de 10 min o menos, puntos de esfuerzo usados mÃĄs para decidir quien se encarga que cuando tiempo se tardarÃĄ en hacer una tarea, si una tarea no se completa en un sprint simplemente se deja para el siguiente sin ningÚn tipo de drama, las historias de usuario llegan a la planing ya refinadas, por lo que son reuniones relativamente rÃĄpidas, las mejoras a pedir de un sprint al siguiente eran pocas (porque las que iban surgiendo se implementaban rÃĄpidamente), las historias nueva COMO PRONTO son para el siguiente sprint... un "TODOS estamos comprometidos con hacer un buen trabajo por encima de hacerlo rÃĄpido, y el software se entregarÃĄ cuando estÃĐ listo, necesite el tiempo que necesite" completamente contrario a waterfall.
Repito, es solo mi experiencia ð
PD: TambiÃĐn en mi experiencia, Kanban en el mundo del desarrollo apesta, no por kanban en sÃ, sino porque es muy fÃĄcil de pervertir y que se convierta en caos (cosa que por desgracia, es el Único caso que he conocido)
PD2: En un buen equipo scrum, un "lider tecnolÃģgico" no es nada mÃĄs que alguien con mÃĄs conocimiento. No manda en nada, no dirije en nada, y no decide en nada por sà solo. Asà mismo, un buen scrum master habla solo lo mÃnimo necesario, y el product owner es solo "otro compaÃąero, pero funcional en lugar de tÃĐcnico". Recordemos que se supone que un equipo scrum es autogestionado POR LOS DESARROLLADORES (si, todos, no solo el lider tecnolÃģgico), siendo los distintos roles solo una cuestiÃģn de asegurar que la metodologÃa se cumple (Scrum Master. No, no es un jefe, y por tanto no puede mandar nada) y toma de requisitos/feedback del cliente (Product Owner. No, tampoco es un jefe, asà que tampoco puede "mandar" nada). ÂŋEl generente? Ese si puede mandar, pero en un verdadero equipo scrum no entra hasta que llega el momendo de las demos.
Que bien explicado! Gracias ð
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.
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
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.
Todos , absolutamente todos los puntos planteados denotan mala interpretaciÃģn de Scrum y un mal uso del mismo. Si un medico no te puede ayudar cuando estÃĄs enfermo, el problema es el medico o la medicina como disciplina?
Alguien sabe como evitar usar esos mald1tos puntos de historia?, cambio de paradigma, cultura, a estas alturas estoy abierto a todo tipo de sugerencias
Malditos puntos!! Trabaje en un equipo con sprint de dos semanas. A una tarea le puse 3 puntos e iba mÃĄs de una semana con el tema. Cuando me preguntaron porque demoraba tanto les dije que ellos habÃan definido los puntos como el esfuerzo o complejidad de la tarea y no con el tiempo. Entonces la tarea que debÃa hacer era tres puntos porque era sencilla pero tenÃa que realizarla varias veces en varios mÃģdulos. No sabÃan que responderme ððð
Se tenia que decir y se dijo ðŋ
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
Casualmente hoy tuve un refinamiento. Y uno de los lÃderes de proyecto estaba mÃĄs preocupado por los story points y si eso reflejaba el tiempoâĶ.ð
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
ðŊ Key Takeaways for quick navigation:
ð Kanban es una metodologÃa ÃĄgil alternativa a Scrum, que se enfoca en flexibilidad y adaptabilidad.
ðĄ Kanban se basa en dividir tareas grandes en partes mÃĄs pequeÃąas y visualizar su progreso en un tablero con columnas como "pendiente", "en proceso", "terminado", etc.
ð El uso de Kanban favorece la transparencia y la coordinaciÃģn del equipo al mostrar claramente el estado de cada tarea.
ð Las tareas se mueven entre columnas segÚn avancen, lo que permite un seguimiento eficaz y una priorizaciÃģn adecuada.
ðž Kanban es menos burocrÃĄtico que Scrum, lo que lo hace mÃĄs accesible y fÃĄcil de implementar.
ð La metodologÃa Kanban es Útil tanto para equipos pequeÃąos como grandes, ofreciendo flexibilidad y control.
ð Facilita la divisiÃģn del trabajo y la organizaciÃģn del equipo, lo que mejora la eficiencia y la productividad.
ðŊ Aplicar Kanban en el desarrollo de proyectos puede ser beneficioso para cualquier tipo de empresa, promoviendo una gestiÃģn mÃĄs ÃĄgil y eficaz.
Made with HARPA AI
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... ;).
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.
El problema de scrum son los scrum mÃĄster 100% dedicados a ello, posiciones en sà solo de esoâĶ que presionan al resto para usarlo a su manera y de un dÃa para otro te cambian su metodologÃa porque al final su trabajo ya estÃĄ hecho una vez el equipo anda solo, pero al final su trabajo depende de reenseÃąarlo otra vezâĶmodificarlo etc..
Las reuniones es para que los cargos altos y business puedan sentir que el trabajo estÃĄ en progreso a pesar que hay entregables rapido...
No se usa bien scrum y es imposible usarlo bien, entre otras cosas porque en una empresa tecnologica no puedes esperar al siguiente sprint para programar la resolucion de un problema sangrante de seguridad, que puede ser o no contingente, por ejemplo, una eventualidad de esas te rompe todo, asi con bugs y otros. tampoco puedes dejar a un cliente esperando a 15 dias a que arreglen la verificacion de tu pais por celular se ha daÃąado en el fomulario y es una solucion de 15 min (me paso), que para lograrlo tienes cosas como CI/CD y que te permite hacer esos hotfix en infrastructuras complejas, y que si lo tienes hace aun mas tonto que uses scrum, o lo usas y te ahorras CI/CD o lo pones y quitas el scrum.
Scrum no esta hecho para el mundo de hoy, es para sistemas que no estaban expuestos a internet, que a las empresas no le importaba tener a la gente meses para sacar un arreglo de una cosas pequeÃąa, y que el software se hacia hasta que se consideraba terminado, hoy en dia todo esta en crecimiento y arreglo. no esperas a que el software este terminado, simpre estas validadando en el mercado para ir modificÃĄndolo segun lo que te diga el mercado.
ese post que lees se debe llamar "como no usar scrum"
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
#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
Pero si no te menten Scrum, te meten Kanban y apurando igual ijjiij
La primera parte es magnÃfica. Sin embargo, Scrum NO es para gestionar proyectos. La palabra proyecto no estÃĄ en Scrum y tampoco la palabra estimar.
Me ha encantado lo de "hay mucha diferencia entre Scrum y el Scrum de las empresas"
En realidad aplican lo que se les canta, no lo que realmente es SCRUM, una sola vez en todas las empresas donde he trabajado realmente he hecho SCRUM, en esa experiencia solo habÃa una Scrum Master de los que te forman para ser Scrum Master, o sea una persona que sabÃa que era SCRUM... Era otro mundo, prÃĄcticamente diferente a lo que las empresas dicen que hacen (pero no lo hacen ni por mierda).
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.
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"
Bajo mi punto de vista, sobre las quejas de encajar los puntos de dificultad en rangos de tiempo, creo que no es nada descabellado, los puntos miden dificultad, y cada desarrollador tarda un tiempo distinto en completar esa dificultad, un junior a lo mejor tarda una semana en hacer 3 puntos, y un senior 1 dÃa, pero son 3 puntos para los dos. Entonces, como cada tarea va asignada a un desarrollador, y tenemos un histÃģrico de quÃĐ velocidad tiene (cuantos puntos al dÃa suele hacer, por ejemplo) es viable predecir cuÃĄntos puntos podrÃĄ hacer ese desarrollador en ese sprint, y cuÃĄntas tareas asignarle. Si al final resulta que no se cumplen los plazos, probablemente sea porque la tarea no estaba bien estimada, y era mÃĄs difÃcil de los puntos que se habÃan estimado, pues se aumentan los puntos de la tarea para reflejarlo y listo. Cuando a mi me preguntan porquÃĐ estoy tardando mÃĄs de la cuenta, me lo preguntan porque quieren saber si la tarea estÃĄ bien estimada o no, no porque se estÃĐ poniendo en duda mi profesionalidad, al menos, ese ha sido mi experiencia, entiendo que habrÃĄ de todo.
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.
Creo que el problema estÃĄ en las empresas que no saben implementar Scrum, ademÃĄs existe la idea de medir productividad individual y el error de creer que "ÃĄgil" es equivalente a "trabajar rÃĄpido". Creo que muchos equipos de desarrollo dicen que usan Scrum (u otra metodologÃa que escucharon) por moda como lo fue en los 90 con el tema de la "reingenierÃa" . Se nota mucho cuando no entienden de generar un producto mÃnimo viable y el tema de las iteraciones o sprints, normalmente no se tiene claro lo que se debe construir, se controla quien no se queda hasta tarde trabajando, se quiere todo el software terminado para ayer.
El problema con SCRUM es que mucha gente que jamÃĄs ha tirado una lÃnea de cÃģdigo decide como se va a desarrollar y se les da mÃĄs importancia a sus "recomendaciones" que a los lÃderes tÃĐcnicos y precisamente si jamÃĄs haz tirado una lÃnea de cÃģdigo como carajos determinas productividad de un desarrollador.
Scrum no es el problema, el problema es cÃģmo se usa. Yo uso una mezcla de scrum y Kanvan y es lo mejor que he probado. No hacemos estimaciones, sino que intentamos dividir todas las taeras en subtareas que tengan mÃĄs o menos la misma complejidad, y suponemos complejidad 1
mientras leias el texto, cada palabra coincidÃa con mi actual trabajo JASJ
Habla por favor de la burocracia en los pipeline de deployment!!! Eso si que es insoportable!!! Especialmente cuando los equipos usan Gitflow!!! (que esta muy desaconsejado en todos lados)
ÂŋQuÃĐ hay del Power bi?, el software para business inteligences control. Me parece que es algo nuevo, no es lo mismo que diversos mbi.
Es el git de la comunicaciÃģn e historial de progreso de los proyectos.
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
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...