El GRAN Problema de SCRUM 

Jajajajaja eso aplica para todas las metodologías no ágiles

Scrum se volvió un Scam, por culpa de las cosas comerciales, a mi me gusta decir, que si el tablero no me sirve para organizar el trabajo entonces no sirve (generalmente pasa eso cuando metes a un jefe-proyecto o rol de solo gestión, o personas que lo usan como una gantt)

Justamente, aunque a veces es al revés. A veces pretenden que un solo senior con 5-6 juniors, por no decir aprendices, te levanten un ERP. En el sector falta un poco de orden. Tener equipos bien balanceados y con gente profesional. Cuando el equipo és de séniors no necesitan ningún puñetero manager. Pero cuando son todos juniors, el manager si es técnico va como pollo sin cabeza, y si solo es gestor, no se entera de nada. Y todo esto creo que es debido al boom de nuevos programadores que ha habido en la últimos años. Programadores que pocas veces se enfrentan a problemas lógicos que les hagan crecer, y al final solo son usuarios de herramientas (frameworks)

@@carles.noguera Más o menos a eso me refiero, ya que en situaciones así, hay mucho puesto woke en los equipos IT, y ellos se justifican que son el éxito de una aplicación, cuando no es más que un negocio cerrado desde arriba. Cito un ejemplo: Hace un año me incorporaron a un proyecto en remoto, de una gran empresa de renombre valenciana, para migrar la applicacion PHP 7.4 Codeignter 3 a PHP 8+ con Symfony 6 en DDD, Hexagonal, etc. Una vez adentro, me dejaron tirado, resolviendo bugs de la aplicación legacy que se caía cada cierto tiempo, siendo yo el único que descubrió el porqué. (en un meeting el CTO hasta lloró porque no encontraba el error) Éramos 6 backend. Nunca me escucharon ni les interesó ninguna propuesta. Me hicieron la vida imposible y me hecharon con causa por que dije que no veía solución al problema de la migración con el plan que llevaban. La última semana que estuve, me enteré que era el único backend que estaba en el mantenimiento, el resto no solo no hacía nada de back, sino que eran juniors tocando sin saber, y para el remate, era el único con Windows 10 cuando todos usaban Linux - el CTO me habían dicho que por orden de la empresa había que usar Windows. Como sigue el tema? Esa gente sigue adentro, con una rotación de personal impresionante, sin embargo al CTO no lo hechan. Y la empresa? A la empresa le inyectan dinero del gobierno valenciano. Se la suda si funciona bien o no la aplicación. Resumen: Los incompetentes se rodean de incompetentes.

Se usa como excusa para una mala planificación, testing y aseguramiento de la calidad deficientes y documentación nula.

Tal cual.

maestro de scum ? xD se nota xD

Soy desarrolladora, project manager y scrum master. La gente no sabe la diferencia del product owner, scrum master. Entiendo lo que dices.

SCUM? JAJAJA

Si, una mala planificación conduce a muchas cosas malas el problema es que los que NO saben de software quieren meter sus manos en el software y en decisiones pensando que así se hacen las cosas y después de 6 meses de trabajo, es trabajo perdido. Y el scrum es usado para los pajazos mentales y el "hype" de "ágil" frente a los clientes pensando que van a entregar todo super rápido y eso conlleva hacer las cosas malas y al final entregan productos basura y te los venden como lo mejor, te venden gato por liebre.

Seguramente tus jefes no tengan ni idea de los roles en scrum, en la propia guía se dice que los desarrolladores tienen la última palabra de COMO se va a implementar una solución

Te recomiendo waterfall es la mejor de la mejor los hace muy felices y productivos a todos 🫠

Léase las 16 páginas de la guía de scrum

Metodología te dice que y cómo hacerlo, framework te dice que pero no como

Puedes leer las 16 hojas de la guía de scrum

@@tsuchiya_kouta5969 no sé si tu respuesta fue de mala o buena fe (sospecho más en lo primero). Yo se que puedo leerlo. Prefiero escuchar la experiencia y recomendaciones y observaciones que Midudev pueda aportar.

De que manera aconsejarías sustituir SCRUM?

@@elifeleth Pues no sé si es la mejor manera, pero en el equipo donde estoy, se ha desarrollado una metodología ágil propia del equipo, adaptando planning, review, retro, determinación de capacity etc, al valor que se espera que entreguemos. Es decir, si al owner del equipo le definen una entrega de valor que se espera, definimos OKR's, y en base a eso definimos planning, y en base a la capacity las user stories que mejor se adaptan a los KR que están definidos, que dependen de la entrega de valor esperada. En cada sprint lo vamos puliendo cada vez más, para que los distintos componentes de la metodología nos permitan volvernos más ágiles y autónomos en la entrega de valor. No sé si se entendió pero más o menos es cómo nos manejamos.

@@guillermooscarnunez4275 Justamente es lo que toda organización debe hacer, navegar por las metodologías agiles y crear algo que funcione para ese contexto. SCRUM asi como XP, canvas, etc... no funcionarían por si solas en la mayoría de las organizaciones, esperan que todos los involucrados sean expertos en la materia y que el cliente acepte condiciones muy arriesgadas.

Todos necesitan proyecciones. Creo que el verdadero dilema es la burocracia y el cumplimiento total de las estimaciones. Tuve un trabajo donde le dije varias ocasiones al Project Manager que esa estimacion era demasiado corta (10 dias habiles), no me paro bola, que ya eso estaba planificado. Un solo frontend, me ofreci a tomar tickets de el, de vivazo me lanzo un ticket largo y pues flutter no era mi fuerte, el punto es que el feature demoro 27 dias habiles, es decir casi el triple de tiempo y eso sin tomar en cuenta que decidi ayudar osea si no ayudo demora mas. Que crees que paso? hubo requerimientos no contemplados en el ticket, lo participe nos reunimos y tuvimos que hacer un refactor, parte de mi codigo se rompio por el refactor en backend, me quedo el ultimo ticket a mi y el project manager la vio facil de tirarme el muerto, la CPO queria su vaina en 10 dias y veia "atrasada" la entrega. Me botaron y se justificaron que yo genere el delay en el entregable y fue falso, la estimacion era incorrecta y sin el analisis total del flujo del feature. Tenia correos para demostrar que esa estimacion estaba mal porque avise con antelacion, sin embargo cuando vi como la CPO reacciono me hizo entender que esa empresa no era un lugar donde debia estar ni siquiera quise pelear. En ese trabajo el PM constantemente pedia sugerencias y me las rechazaba todas, de pronto esas sugerencias aparecian presentadas por otras personas de la empresa. Un ambiente de vivoras era donde me encontraba. Me lleno de bastante frustracion porque me contrataron como backend php y hacia commits a repos en nodejs, graphql, laravel y flutter. Era de los pocos que podian colaborar en cualquier repositorio.

No puedes pedir a un equipo que valore algo que no se ha planificado, y las metodologías ágiles se basan en la improvisación. Una buena gestión de proyecto implica un responsable (arquitecto) que valore y planifique como de desarrollará el proyecto. Que disponga de un equipo competente de confianza y que conozca , para llevar a buen puerto el proyecto, y que el agilismo sea la excepción y no la norma. Pero si no se planifica, se tiene un equipo improvisado, mediocre, mal dimensionado o desmotivado; ya puedes meter cualquier metodología que se va a liar.

El framework es tan poco prescriptivo que no te dice ni cómo tienes que aplicar las prácticas en tu entorno concreto, eso sería una metodología. Si no sigues las 4 cosas que se prescriben, no estás siguiendo Scrum. Y si lo estás usando para un desarrollo que no necesita los beneficios ni la estructura Scrum, es tu problema, pues al final nadie te obliga a seguir una u otra forma de trabajar y parece q Scrum es la navaja suiza cuando no saben ni cómo organizarse

Tenia lo mismo en mente pero tu lo dijiste 😂😂❤ tal cual.👌🏽

Si eso es así, el problema son quienes los contratan. A veces no necesitas scrum ultra técnicos, sino que sepa coordinar bien un equipo. No todos saben hacerlo

La coña es que scrum ni siquiera te dice cómo estimar ni con qué unidades, esa mierda te la meten en cursos y paginas que no saben ni lo que están diciendo, Scrum solo te dice que seas capaz de crear items que quepan en un sprint o menos, para que a ojo puedas ver cuantos items vais a incluir en el sprint

No usar metodologia seria lo mejor en tu caso

Scrum no supone, la idea es que el equipo se empoderé y se vuelva auto suficiente.

@@tsuchiya_kouta5969 "Adaptación Si algún aspecto de un proceso se desvía fuera de los límites aceptables o si el producto resultante es inaceptable, el proceso que se aplica o los materiales que se producen deben ajustarse. El ajuste debe realizarse lo antes posible para minimizar una mayor desviación. La adaptación se vuelve más difícil cuando las personas involucradas no están empoderadas ni se autogestionan. Se espera que un Scrum Team se adapte en el momento en que aprenda algo nuevo a través de la inspección. "

Mi último trabajo no uso ningún tipo de metodología y el jefe de célula tenía a todos enfermos de los nervios.

Nadie ha dicho que no sirva. Pero llamarlo metodologia agil y venderlo como tal es lo incorrecto.

@@rubenescalantea es una metodología ágil, que este más implementada es otra cosa

Kamban es tanto una metodología ágil como la tabla en sí, pero como ha demostrado ser muy útil muchos frameworks la utilizan

Drkidb, antes de corregir por lo menos entérate de lo que hablas. menuda chorrada que acabas de soltar.

Existe también el método Kanban

Yo le entendí perfectamente, será que tú no usas Scrum, por ejemplo, el daily se diseño para mejorar la comunicación y ayudar a otros con sus bloqueantes, hoy en día en casi todos lados sirve para jefe llevar control del avance que hacen los desarrolladores, así es como conviertes algo de procesos a administrativo.

@@javierduque8059 Los objetivos técnicos tienen que estar alineados con los objetivos de la empresa. El jefe, sea pm/po o el ceo debe saber el avance el proyecto, porque el a su vez lo tiene que informar a un cliente o mesa de directivos o tomar decisiones el mismo si así lo considera.

@@javierduque8059 Y respecto a utilizar scrum para oprimir al equipo enfatizando la figura de autoridad (Dark Scrum) no creo que sea un problema de la metodología sino de la cultura de las empresas y la falta de capacitación a PMs/Scrum Masters. Scrum es muy poderoso, que bien usado potencia al equipo, mal utilizado es como poner un arma en las manos equivocadas.

@@barrenaedu claro, totalmente de acuerdo, pero aquí la discusión o el asunto es que esto nació desde el manifiesto ágil de los desarrolladores para los desarrolladores, pero la gente de administración piensa que desarrollar intangibles es igual a producir carros en serie como lo estableció Henry Ford, no se si me entiendes el punto y la molestia de los desarrolladores, terminaron haciendo pequeños cambios y dañaron el sentido de porque se inventó y tuvo tanta popularidad Scrum. El otro problema es poner alguien que no sabe programar a ser el jefe de tecnología, en lugar de poner a un buen desarrollador a que aprenda a dar manejo administrativo.

@@javierduque8059 Lo que dices sobre de que fue creado "de los desarrolladores para los desarrolladores" no estaría tan de acuerdo, fomenta la comunicación entre todas las partes del equipo y empresa/cliente. La parte técnica (Desarrollo) debe estar alineada al negocio (Producto). Pero volviendo a mi comentario original, creo que Midu se queda corto en su explicación, ya que no da demasiado fundamentos personales con ejemplos, la primer mitad del video dice que no esta de acuerdo y la otra mitad lee comentarios, pero no termina de explicar bien eso; y eso lo que yo le comento, desde mi punto de vista, con respeto.