Pregunta:
Scrum Master utiliza un generador de números aleatorios para asignar números de tarea al sprint. ¿Es así como funciona normalmente el desarrollo de software ágil?
sraddich
2019-11-28 22:36:22 UTC
view on stackexchange narkive permalink

Soy un junior y apenas llevo unos meses en mi primer trabajo como desarrollador de software después de graduarme. Somos tres sprints en nuestro nuevo proyecto y la gerencia decidió usar Scrum ya que es "un enfoque nuevo". Para "mantener las cosas ágiles", el Scrum Master utiliza un generador de números aleatorios para elegir las tareas que se deben realizar durante la planificación del sprint. Aparentemente se le llama "planificación del juego".

Usamos React y Django, por lo que las tareas de front-end y back-end están separadas. La "planificación del juego" ha dado como resultado todo tipo de partes frontend sin backend y todo tipo de cosas backend que no hacen nada.

También adoptaron de todo corazón la filosofía ágil de no dedicar tiempo a documentar nada, por lo que los desarrolladores están tomando todas las decisiones más allá de la única frase de funcionalidad que nos dan en las tareas. Bien si los desarrolladores estaban construyendo el componente completo (ya que tenemos revisiones / demostraciones), pero es problemático cuando los componentes necesitan hablar en alguna tarea aleatoria asignada más tarde y los componentes no están completamente construidos.

El proyecto avanza lento ya que se dedica mucho tiempo a adivinar las necesidades reales del componente, la alta dirección se queja de la falta de progreso en piezas específicas (y culpa a nuestro líder tecnológico, no al scrum master , que dice que elegir un componente en lugar de otro es gestión de cascada), y pasamos mucho tiempo rehaciendo el trabajo porque el propietario del producto y el scrum master hacen toda una oración antes de enviar a los desarrolladores al código y esperan que adivinen el objetivo del componente correctamente.

¿Así es normalmente el desarrollo de software? Como creo que esta carrera ya no es para mí ...

Tal vez podrías tirar algunos dados para decidir si un día determinado es un día laboral.
@chrisstratton - Me gusta mucho esa idea.¿Pero eso significa que el jefe puede tirar los dados sobre si me paga?_Espera un minuto ..._
Por "planificar el juego", ¿estás hablando de "planificar el póquer"?Si es así, lo han entendido mal.
Lo que describe no es Scrum ni Agile.Es el caos.
@MatthewGaiser También me preguntaba eso, pero una búsqueda del término 'planificar el juego' no arroja ningún resultado más que esta Q ... parece que están usando un RNG para decidir qué tareas llevar a cabo en el sprint2 de una lista de 10 o lo que sea), nunca había oído hablar de esto antes y no creo que sea un enfoque válido.
@sraddich Mencionaste en un comentario a una de las respuestas que también se refirieron a ella como "planificación de póquer". ¿Puedes editar eso en la Q, ya que es información útil?
@JoeStrazzere Disfruto codificando y construyendo proyectos.No estar asignado a bits y piezas de código aleatorios.Quiero quedarme en el software.
Si está absolutamente configurado en el RNG, ¿podría tener una categoría de backend y frontend, con las tareas de backend con una interfaz correspondiente, y si se elige una, también se elige la parte delantera / trasera que lo acompaña, para que al menos tenga algo algo significativohecho al final del sprint?
¿Se le permite intercambiar tareas con sus compañeros de trabajo una vez que se le asignan al azar?
@systemovich asume que las personas continuarán actuando de la misma manera que lo hicieron en Waterfall excepto por los cambios prescritos.El problema es que los seres humanos son muy sensibles a los incentivos.Apostaría a que en muchas empresas, los sprints toman dos semanas y todo se hace simplemente, sin importar qué tan bien o mal haya ido el sprint.Si salió mal, omita las pruebas unitarias.Si salió bien, vaya a Reddit.
Cada vez que he estado en un proyecto con un scrum master bueno / experimentado y un buen equipo de desarrollo, un proyecto funciona como una máquina bien engrasada y nada era conjeturas cuando los desarrolladores lo pusieron en sus manos.Al final de cada sprint había una característica o iteración demostrable y útil en una característica y, en general, la experiencia fue muy positiva.Lo que usted describe no suena nada bien.
_ "la filosofía ágil de no perder tiempo documentando nada" _, esa no es la filosofía ágil ...
Seis respuestas:
Daniel
2019-11-28 22:58:14 UTC
view on stackexchange narkive permalink

Vaya, hay mucho en esto. Comencemos con el sencillo:

Agile no fomenta en absoluto la falta de documentación.

El Manifiesto Agile dice que valora el software que funciona sobre la documentación completa. Si lee algo de una de las personas involucradas en la elaboración de esa declaración, el significado claro es que documentar qué software creará no es lo mismo que hacerlo. Si tiene una pila de documentos de diseño y no tiene software, todavía no tiene software. Esto se utiliza para admitir lotes cortos en los que diseña y documenta sobre la marcha en lotes pequeños en lugar de tener una gran fase de diseño y documentación seguida de una fase de implementación. Para los equipos que practican Scrum, es común tener un elemento en la Definición de Terminado para completar toda la documentación necesaria, lo que significa que el trabajo no se realiza hasta que toda la documentación para esa funcionalidad esté terminada.

No Front-End / Back-End

Ok, obviamente, desde un punto de vista arquitectónico hay un front-end y un back-end. Desde el punto de vista del cliente, estas son palabras sin sentido. Esto significa que los elementos de su cartera de pedidos deben abarcar toda la función. Por ejemplo, debería tener un elemento de la lista de trabajos pendientes que diga:

Como usuario registrado, me gustaría poder actualizar la dirección de correo electrónico de mi cuenta para poder recibir correos electrónicos en mi nueva dirección.

Este elemento se haría cuando tanto el back-end como el front-end estén completos. Además, el equipo de desarrollo es responsable de encontrar el mejor enfoque para ese elemento. Los niveles de intercambio, capacitación cruzada y coordinación quedan estrictamente bajo su discreción. La línea exacta de la Guía Scrum es:

[El equipo de desarrollo] se autoorganiza. Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo convertir el Product Backlog en Incrementos de funcionalidad potencialmente liberable;

La única forma en que puedo imaginarme que lo que está haciendo tu Scrum Master es una buena idea:

Hay tiempo, como scrum master o coach, que he aconsejado el equipo para hacer algo que era una mala forma de desarrollar software. Por lo general, estos fueron por un período corto de tiempo para obtener algún otro aprendizaje como equipo. Fui claro con el equipo sobre lo que estaba tratando de lograr y tuve su aceptación. Si explico su historia de la mejor manera posible, este podría ser un ejercicio de aprendizaje para el que deberían haber obtenido la aceptación del equipo primero. Pude ver cómo la selección aleatoria de tareas obligaría al equipo a coordinarse de cerca y crear una propiedad compartida del código si el ejercicio se ejecutaba bien. Sin su aceptación, sin embargo, no veo que tenga el efecto deseado.

Mi consejo

Me sentaría con el Scrum Master y le pediría que me explicara lo que está intentando lograr. Probablemente estén tratando de ayudar de verdad. Aprecielos por ello, luego explique el impacto real que están teniendo. Al final, tal vez lo haga de una manera diferente que obtenga el aprendizaje que buscan sin causar caos. Quizás intentes algo diferente. Quizás lo dejes caer por completo. Al final, usted (el equipo de desarrollo) siempre debe poder hacer valer su derecho a decidir cómo construir el incremento por sí mismo. Sin embargo, una advertencia, no lo convierta en un proceso de abogado de reglas. Usa la guía de scrum como guía, pero no está escrita en piedra.

Para mayor comodidad, aquí tienes un enlace a la versión en línea. Son 16 páginas cortas. La guía de Scrum

¡Buena respuesta!Lamentablemente (no soy el OP), no me parece que sea un ejercicio de aprendizaje al hacerlo deliberadamente "mal" o algo así.Han completado 2 sprints y están en un tercero (creo) y en ese tiempo (¿6 semanas?) El proyecto está progresando poco y recibe quejas de la alta dirección.Si es un ejercicio de aprendizaje (!), Parece que el SM se ha vuelto deshonesto.
No puedo hacer una edición de un solo carácter, pero a menos que realmente lo sienta con tanta fuerza, "Scum Master" podría querer arreglarlo.
Error tipográfico arreglado, gracias
Probablemente le vendría bien una pequeña actualización, pero creo que el principal problema es la selección selectiva.
Goose
2019-11-29 02:28:33 UTC
view on stackexchange narkive permalink

¿Eso es normal? No.

Eso no es ágil ni scrum ... ni siquiera cerca. Eso es una locura.

Existe un concepto ágil llamado póquer de planificación, pero gira en torno a la estimación del tamaño de la tarea ... individuos que usan cartas para indicar su estimación del tamaño de la tarea. Esto evita que los miembros influyan en otros miembros en las estimaciones del tamaño de la tarea, también genera suposiciones en conflicto / omitidas cuando las estimaciones están demasiado alejadas.

Los propietarios de productos deben priorizar las tareas / características ... no los RNG. Las dependencias de tareas / funciones deberían haberse identificado antes de priorizar los elementos.

En lo que respecta a la documentación, no hay nada en ágil que diga "Sin documentación" ... así que parece que alguien malinterpretó el manifiesto ágil, o agregó un giro personal (equivocado).

ObscureOwl
2019-11-29 20:20:11 UTC
view on stackexchange narkive permalink

¿Así es normalmente el desarrollo de software? Como ya no creo que esta carrera sea para mí ...

Hay muchas empresas que dicen que están haciendo Agile y Scrum. Tómalo con una pizca de sal. Lea sobre Agile y Scrum. Son textos sorprendentemente breves:

The Agile Manifesto

The Scrum Guide (2017)

el scrum master está usando un generador de números aleatorios para elegir las tareas que se realizarán durante la planificación del sprint. Aparentemente se le llama "planificar el juego".

Una práctica común en Scrum es "planificar el póquer", que se utiliza cuando los desarrolladores estiman cuánto tiempo tomaría implementar una historia en particular. Cada uno de ellos tiene un juego de cartas numeradas (comúnmente numeradas 1, 2, 3, 5, 8, 13, 21) y todos escogen una carta que creen que coincide con la dificultad. Si todos los desarrolladores muestran tarjetas muy diferentes, es una señal de que los desarrolladores no están realmente de acuerdo con lo que se les pide que hagan. En ese caso, la historia probablemente deba explicarse mejor. Así que el propósito de planificar el póquer es reducir la incertidumbre. No apostar.

Elegir tareas aleatorias es, de hecho, muy contrario a la filosofía de Scrum, donde cada sprint debe tener un objetivo general claro. Luego, los desarrolladores eligen historias del backlog para trabajar, que ayudarán a cumplir con ese objetivo.

Finalmente, esto realmente no parece un Scrum Master haciendo su trabajo correctamente. El Scrum Master no es un bromista / gerente de proyectos. Él entrena a los desarrolladores y al propietario del producto en el uso eficaz del proceso Scrum.

También adoptaron de todo corazón la filosofía ágil de no perder tiempo documentando nada

Esto es no filosofía ágil. Literalmente, el Manifiesto Agile dice:

"Software de trabajo sobre documentación completa"

(...)

"Es decir, aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda".

El proyecto avanza lento ya que se dedica mucho tiempo a adivinar las necesidades reales del componente

Esto va muy en contra de la idea de Scrum, que es que siempre estás trabajando en algo que claramente añadir valor. No vas a construir nada en Scrum hasta que sepas para qué sirve.


Suena muy parecido a que tu Scrum Master leyó el título de una presentación de diapositivas sobre Scrum , pero nada más. Es realmente inusual que sea tan ridículo como lo que describes. Me gustaría cerrar con una cita de la guía de Scrum:

Nota final

Scrum es gratuito y se ofrece en esta Guía. Los roles, eventos, artefactos y reglas de Scrum son inmutables y, aunque es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum existe solo en su totalidad y funciona como un contenedor para otras técnicas, metodologías y prácticas.

Robin Bennett
2019-11-29 14:49:13 UTC
view on stackexchange narkive permalink

¿Así es normalmente el desarrollo de software?

Puede ser, en el peor tipo de empresas en cascada, en las que sigue un plan rígido e ignora si realmente está funcionando hasta el final. ¡Parece que su empresa ha logrado recrear los problemas de la cascada descartando los (supuestos) beneficios!

El objetivo del desarrollo ágil es que regularmente observa cómo van las cosas y cambia su plan y procesos hasta que funcionen para usted. Apegarse rígidamente al proceso de otra persona es lo opuesto a ágil, incluso si lo etiquetaron como 'Ágil'.

Recuerde a todos que parte de Scrum son retrospectivas. Siéntese y hable sobre lo que está funcionando y lo que no, y aprenda de la experiencia. Puede que estés reinventando la rueda, pero eso es mejor que intentar usar ruedas cuadradas porque crees que todas las personas geniales lo están haciendo.

AndreiROM
2019-11-28 22:48:59 UTC
view on stackexchange narkive permalink

Estás generalizando en función de una experiencia y creo que lo sabes mejor.

Parece que ese lugar es simplemente un manicomio y que necesitas empezar a buscar un trabajo que te permita aprender y crecer en un entorno más estructurado. Cuanta más experiencia tenga, más podrá hacer frente a menos estructura y más responsabilidad. Sin embargo, cuando eres relativamente nuevo, esto será perjudicial para tu crecimiento profesional.

Tu liderazgo está alterando las metodologías y simplemente jugando al bingo de palabras de moda. Toda la operación sufrirá tremendamente más temprano que tarde (la deuda técnica es una cosa).

Sí, pero todos parecen usar Agile ...
@sraddich: he estado en la industria durante 9 años, nunca trabajé en un entorno verdaderamente ágil.¿Documentación y proceso perfectos?Raramente.¿Pero sin estructura alguna y construyendo basura al azar como estás describiendo?No. Simplemente parece que estas personas no tienen ni idea de cómo administrar una tienda de software, y se darán cuenta de eso cuando pierdan un montón de dinero y / o la gente comience a irse en masa.
@sraddich lo que usted describe no es ágil, es un caos.Como decía siempre mi scrum master favorito: ¡No confundas ágil y caos!
Supongo que estamos hablando de scrum, ya que hay una etiqueta de Scrum y estamos hablando de Scrum Masters.Dado que la Guía de Scrum tiene solo 16 páginas, uno pensaría que las empresas la leerían primero.
@Daniel el OP dice en el primer párrafo que usan Scrum.
Entonces lo hacen.La declaración sigue en pie entonces
@sraddich He trabajado en varias empresas y equipos que usaban Agile (Scrum u otro), sí es muy común hoy en día.Pero la experiencia ágil típica no es como la que describiste en la Q: todavía no he visto una implementación ágil / scrum 'purista' y no creo que sea posible en la práctica (y soy bastante cínico en términos de agileyo mismo), se puede hacer mucho mejor que esto.
Gibbon
2019-11-28 22:51:08 UTC
view on stackexchange narkive permalink

De acuerdo, quiero decir que nunca me he encontrado con la idea de elegir tareas al azar; eso parece contraproducente para poner las cosas en vivo.

Pero, en general, tampoco he Realmente he visto cualquier lugar de trabajo hacer "Agile" de forma remota de la misma manera que en otros lugares, así que quién sabe. Pero también Agile no se trata de una "falta de documentación" ... mantener un software bien documentado es uno de los aspectos clave para hacer que Agile funcione, por lo que su software debe estar documentado.

De los lugares en los que he visto trabajar, aunque la documentación es a menudo bastante escasa, y hace que recoger proyectos de otra persona sea una pesadilla. Esta parte es algo habitual en el desarrollo de software, pero puede ayudar escribiendo documentos para las cosas que aprende (también hay herramientas para generar documentos automáticamente en todas partes).

Pero sí, el " Planificar el juego "no es algo con lo que me haya encontrado, y probablemente estaría muy en contra, a menos que alguien pudiera darme una lista bastante simple de razones por las que sería beneficioso, por lo que esta parte, al menos, no es exactamente típica de los lugares de trabajo.

tl; drAgile se hace de manera muy diferente en diferentes empresas. La "planificación del juego" es algo que nunca había visto antes, pero la falta de documentos suele ser bastante común por experiencia.

Creo que también se refirieron a él como "planificación de póquer".¿Te resulta familiar?
pero la planificación del póquer es donde todos los miembros del equipo participan en la estimación de la duración de los proyectos y luego toman una decisión grupal sobre en qué trabajar, etc.no hay nada aleatorio en la planificación del póquer


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 4.0 bajo la que se distribuye.
Loading...