La idea principal del marco Scrum es organizar el proceso de desarrollo para una ejecución más rápida del trabajo en varias etapas del ciclo de vida del proyecto. Pero, ¿este enfoque siempre empuja a los desarrolladores hacia los comportamientos correctos? Muchos usuarios que se unieron a la discusión de la pregunta anterioren Stack Overflow, han experimentado cosas similares cuando los desarrolladores toman atajos, ponen demasiado énfasis en las puntuaciones altas asignadas a sus tickets o incluso fingen ser empleados de alto rendimiento frente a los gerentes. ¿Cómo se pueden evitar estos peligros? La pregunta en cuestión se ha trasladado de work.stackexchange.com a softwareengineering.stackexchange.com . Esto sugiere que los programadores ven las consideraciones que rodean a Scrum y su efectividad como algo lo suficientemente serio como para ir más allá de la gestión del ciclo de desarrollo de software. Sienten el impacto de este método de gestión de proyectos en el entorno laboral general.
¿Scrum es la causa de las malas prácticas de desarrollo o es solo una excusa para este problema?
Mucha controversia ha provocado especulaciones sobre el impacto de Scrum en equipos y desarrolladores individuales, y las limitaciones que el marco impone a quienes lo usan. Si bien muchos culpan a Scrum por las fallas del equipo, otros creen que se trata de un error de atribución y que las raíces de los problemas en los equipos de desarrollo son mucho más profundas.
Los defensores de Scrum ven la mala gestión como la raíz del problema. Esto es lo que dice el usuario Llewellyn, resumiendo: “La gerencia esencialmente ignora a los desarrolladores. Hay plazos fijos que deben cumplirse para lograr resultados predeterminados. El trabajo no lo hace un equipo enfocado en lograr el mismo objetivo, sino un grupo de personas en el que todos solo se preocupan por sí mismos. Se desaconseja planificar con anticipación y pensar fuera de la caja. En tales condiciones, el programador, como resultado, sucumbe a las circunstancias y encuentra la salvación en la simple ejecución de las tareas que se le asignan. He trabajado en tales condiciones. Pero no culpes a Scrum por eso ".
El usuario DJClayworth expresó el sentimiento de muchos comentarios, diciendo que los programadores que piensan que están bajo presión se desempeñarán mal con cualquier metodología de gestión de desarrollo.
La opinión opuesta sobre este tema fue expresada mejor por el usuario Martin Maat , quien llamó la atención de la audiencia sobre el hecho de que el mismo hecho de que tantas personas sientan la necesidad de hablar sobre este tema habla de la frustración que Scrum les causa.
¿Cuáles son los problemas comunes al usar Scrum?
Algunos errores comunes de Scrum han surgido en los comentarios, ya sea porque se está utilizando mal el marco o porque son, de hecho, problemas inherentes a Scrum. Aquí hay casi una decena de problemas de este tipo que nos han llamado la atención.
▍1. Las reuniones diarias son para gerentes
La primera crítica a Scrum está relacionada con el hecho de que en el transcurso de las reuniones diarias (stand-ups) surgen tendencias no deseadas. Uno de los argumentos a favor de esta idea es que los stand-ups pueden degradar al estado de los hechos, cuyos participantes solo hacen lo que dicen sobre su productividad. Especialmente si los gerentes están presentes en tales eventos. Por lo tanto, el usuario Matthew Gaiser (ya nos escribió, pero nos topamos con su comentario por accidente) convocó eventos stand-up que tienen como objetivo informar a los gerentes sobre la situación actual ( gestión de actualizaciones). Él cree que las presentaciones de los desarrolladores en tales eventos solo alientan a los gerentes a observar en qué están trabajando, pero no trae ningún beneficio. Esto es aún más cierto para los equipos distribuidos, cuando cada uno de los miembros del equipo trabaja en su propio modo.
▍2. Completar tareas juega un papel importante
Otra idea que surgió en los comentarios es que cualquier metodología de desarrollo que divide las tareas grandes en tareas más pequeñas y monitorea el progreso de esas tareas conduce, intencionalmente o no, a nuevos enfoques para evaluar el trabajo. Si apenas comienza a aplicar algunas métricas, afectará el comportamiento de las personas cuyo desempeño se evalúa de acuerdo con estas métricas.
Muchos comentaristas dicen que esto significa que los desarrolladores pueden "tomar atajos" para completar lo que se necesita hacer en el sprint actual. El problema señalado por el usuario Gaisery otros usuarios, es que un ticket separado en el que se está trabajando, y que, durante el sprint, se transfiere a la categoría de "listo", esto es una "caja negra". Lo que sea que haya dentro de esta "caja negra", no afectará el resultado de evaluar la velocidad de trabajo. User Gaiser escribe que la implementación de baja calidad que pasó por el departamento de control de calidad y la implementación perfectamente probada y diseñada no son diferentes entre sí. Como resultado, resulta que contabilizar el número de tickets cerrados es un indicador poco confiable de la productividad laboral.
▍3. Desarrolladores extremadamente productivos que no trabajan en equipo
Otro hilo discutió la tensión entre los grandes programadores en solitario y los grandes equipos. Cuando todos siguen la metodología Scrum, algunos desarrolladores pueden ser extremadamente productivos, pero luego se puede olvidar al "equipo". User Gaiser dice que sin los incentivos adecuados, la autoorganización es un objetivo inalcanzable: “Los miembros del equipo resolverán los problemas como mejor les parezca o según las indicaciones. Si no ayuda a construir el equipo, quedará mucho y los miembros del equipo simplemente avanzarán en desorden ".
Continúa: "Además, al permitir que cada desarrollador elija sus propios métodos para resolver problemas, significa más difícil depurar el código".
▍4. Las tareas difíciles se posponen para más tarde
Gaiser, en la misma línea, continúa criticando la ilusión de productividad. Él dice que al aplicar Scrum, el enfoque principal es llevar el boleto al estado "Listo". Pensar profundamente en la tarea al mismo tiempo no parece particularmente productivo. Por lo tanto, los desarrolladores pueden tender a asumir tareas fáciles y evitar las más complejas. Aquí, nuevamente, las palabras del usuario Gaiser: "Scrum alienta a los desarrolladores a asumir tareas fáciles que requieren un poco de tiempo para resolver, lo que permite a los desarrolladores mostrar una alta velocidad de manera constante". Como resultado, resulta que las opciones de tareas diarias y los informes de trabajo diarios están impulsando la elección de tareas que tardan un día en completarse.
▍5. Las características del producto son más importantes que la calidad del código
De todos modos, Gaiser cree que el uso del marco Scrum conduce a una caída en la calidad del producto: “Lo bueno que es un desarrollador generalmente está determinado por su capacidad para desarrollar código confiable. Scrum, a menos que el propietario del producto comprenda la programación y revise el código, devalúa seriamente esta característica de los proyectos ". Enfatiza aquí que la "preparación" de un boleto a menudo se determina no después de verificar la calidad del código, sino solo después de que se haya implementado la función correspondiente.
▍6. Falta de tiempo para discutir temas laborales con colegas.
Si la velocidad del desarrollo es el único indicador de la efectividad del equipo, significa que los miembros del equipo ya no tienen tiempo para discutir algunos temas entre ellos, para obtener la opinión de otros o para probar sus ideas, alguien hablando de ellos. Y eso es exactamente lo que hace que un equipo sea un equipo. Aquí, nuevamente, las palabras del usuario Gaiser: “Los grandes desarrolladores a menudo consultan con otros desarrolladores y buscan alternativas a sus opiniones. Pero estas clases toman el tiempo necesario para cerrar los tickets y esto ralentiza la velocidad de desarrollo ".
▍7. Los errores identificados recientemente deben esperar su turno
Otro mal comportamiento de Scrum es que "los errores se encuentran después del sprint y se consideran tareas nuevas". Esto puede empujar a los desarrolladores a publicar código de baja calidad, ya que no se pueden incluir tareas adicionales en el sprint actual.
▍8. Arquitectura impulsada por tickets
El sistema de tickets no solo se basa en las tareas que los desarrolladores eligen por sí mismos. User Gaiser también dice que el uso de Scrum, inadvertidamente, conduce a una arquitectura confusa de proyectos, ya que los desarrolladores trabajan en los tickets en el orden en que aparecen e independientemente unos de otros. Como resultado, "la arquitectura se convierte rápidamente en un reflejo de las entradas".
▍9. Una metodología de gestión del desarrollo que afecta absolutamente a todo
Al leer la discusión, puede prestar atención a los comentarios, cuyos autores señalan que la raíz de todos los problemas radica en la falta de cumplimiento estricto de las reglas de Scrum. Sin embargo, quizás la afirmación anti-Scrum más fuerte del usuario Gaiser es que domina todo lo demás. Esto puede destruir un equipo fuerte. "[Scrum] distorsiona y rompe cualquier otro mecanismo de gestión del desarrollo, este marco se convierte en un fenómeno que lo abarca todo en el que nada más que realizar rituales se realiza de manera uniforme, y la realización de estos rituales crea la ilusión de éxito".
Hemos discutido una lista bastante larga de problemas que pueden ser causados por el uso de Scrum y, quizás, solo se vuelven más notorios debido al uso de este marco. Pero en la discusión que estamos investigando, puede encontrar tantas ideas sobre cómo los desarrolladores pueden vivir en paz y armonía siguiendo las reglas de Scrum .
¿Cómo aprovechar Scrum al máximo?
Muchas de las respuestas a los comentarios de Gaiser, que recibieron muchas calificaciones positivas, fueron que de lo que estaba hablando no era Scrum. Esto es lo que el usuario Stephen Byrne escribió sobre esto: “Creo que esta es una buena respuesta con algunas ideas valiosas, pero estoy de acuerdo con muchos otros comentaristas en que lo que se describe aquí definitivamente no es Scrum, aunque y se ve bajo la apariencia de Scrum ". Pero muchos odiaban abiertamente a Scrum o estaban de acuerdo con el usuario de Gaiser en que si algo sale mal al usar Scrum, significa que este marco simplemente no se está usando correctamente.
¿Cómo usar Scrum correctamente?
▍1. Las reuniones diarias no son lo mismo que recoger nuevos boletos todos los días
Mucha gente dijo que las reuniones diarias obligan a los desarrolladores a cerrar tickets todos los días. Pero, como señaló DJClayworth , tampoco puede prescindir de priorizar las tareas. Y si las prioridades no se establecen de forma natural, entonces esta tarea debe ser asumida por el Scrum Master: “Necesitamos priorizar las tareas dentro de los sprints, las tareas más grandes deben tener mayor prioridad, por lo que alguien debe asumir tareas difíciles el primer día del sprint. En cualquier caso, si para el segundo día nadie ha asumido una tarea grande y compleja, el Scrum Master debería decir algo como: “Veo que nadie ha asumido la tarea de comprimir la base de datos. Y esta es una gran tarea. Si vamos a completar el sprint, tenemos que empezar a trabajar en esta tarea ahora ".
▍2. ,
Todas las tareas resueltas en el sprint deben dividirse en partes pequeñas. Esto es innegable. Pero el marco de Scrum no dice que los desarrolladores deban estar obsesionados con las métricas que indican resultados. Scrum no sugiere enfrentar a los desarrolladores entre sí. El usuario Gaiser propone a abandonar por completo la consideración de los puntos programador individual. Señala que muchos gerentes pueden necesitar volver a examinar las reglas de Scrum: “Dígales a los gerentes que en el momento en que elogian a los desarrolladores o les dan una promoción basada en tickets cerrados, se convierte en el momento en que cambian radicalmente el comportamiento del equipo. ".
Usuario DJClayworthestá de acuerdo en que ignorar deliberadamente las métricas asociadas con los tickets individuales debería ser parte de la tarea de un buen Scrum Master: “La atención debería centrarse en asegurar que el equipo logre sus objetivos como equipo. El Scrum Master debe ceñirse a esta línea de comportamiento y evitar cualquier discusión o métrica basada en cuántas historias de usuario ha promovido cada miembro del equipo ".
▍3. Necesita dar pequeños pasos hacia grandes objetivos, pero con este enfoque no debe olvidarse de estos objetivos.
Aquí hay otra idea para dividir problemas grandes en piezas pequeñas: "Si está trabajando en una pequeña pieza de un rompecabezas, eso no significa que deba olvidarse de todo el rompecabezas".
El usuario Llewellyn señala que usar Scrum no es una excusa para ignorar por completo los principios del desarrollo de software de calidad: “Tienes que tener una buena idea de hacia dónde se dirige el proyecto. Este conocimiento se puede utilizar para planificar la arquitectura del proyecto, participando en la planificación incluso dentro del sprint actual ".
Scrum no libera a los programadores de la necesidad de hacer su trabajo, invirtiendo todo su conocimiento y toda su experiencia en él. Por eso, la llamada de Llewellyn va a los programadores que se encuentran entre los lectores de los comentarios: “Estuvisteis en la reunión, podéis mirar el backlog, sabéis cuál es la visión global del proyecto en la organización. Se esfuerza por evitar tener que pasar largos períodos de tiempo en algo del futuro lejano. Pero no hay nada de malo en sentar las bases de un sistema modular extensible que será adecuado para resolver los problemas actuales y le permitirá crear oportunidades adicionales ya planificadas sin problemas en el futuro ".
▍4. Es necesario decidir qué significa "Hecho"
Uno de los temas planteados en la discusión que estábamos discutiendo fue el criterio de Definición de Terminado (DoD), y cómo definir estos criterios ayuda a los programadores individuales a adherirse a ciertos estándares de calidad y estar al tanto de lo que se espera de ellos. La pregunta más urgente aquí fue quién y cuándo desarrolla estos criterios. Cuando se trata de " cuándo " , por lo general se trataba de desarrollar criterios lo más rápido posible o de cómo deberían desarrollarse durante la planificación del sprint.
La respuesta a la pregunta de quién produce el DoD fue escrita por el usuario SpoonerNZ en forma de respuesta a otra pregunta.en el sitio web de Ingeniería de software. “Los criterios de preparación los crea el equipo, pero este proceso puede requerir la presencia de un Scrum Master. Esto es necesario para establecer restricciones de calidad, en caso de que el equipo no tenga estándares de desarrollo claros. Por ejemplo, es posible que un equipo no quiera meterse con revisiones de código o pruebas unitarias, lo que resultará en que ScrumMaster agregue todo esto al DoD para garantizar un desarrollo de alta calidad. En una situación ideal, el equipo, habiendo entendido las fortalezas de lo que se ofrece, lo aceptará con gusto, pero el mundo real no siempre es ideal ".
¿Quién debería trabajar mientras se adhiere al DoD? Un objetivo natural (y desafiante) es garantizar que las disposiciones descritas en el DoD se apliquen en un equipo y que cuenten con el apoyo de todos los miembros de ese equipo. Pero hay buenas razones para extender la influencia del Departamento de Defensa a varios equipos. O incluso a toda la organización. Esto es lo que escribe el usuario Alan Larimer al respecto: “La falta de una definición de DoD universalmente reconocida para un producto afecta negativamente la calidad y transparencia del trabajo. El nivel organizativo del DoD debe ser mínimo, técnico y, a veces, específico de la organización, lo que puede proporcionar una aplicación universal de los criterios de preparación. La organización puede proponer estándares para la codificación. Una organización puede requerir la creación de ensamblajes automatizada, dando los recursos para crear y mantener ensamblajes para cada producto. Cualquier parte del DoD, ya sea creada por una organización o por un desarrollador individual, debe aportar algo de valor a los criterios de preparación ".
▍5. Los gerentes deben desempeñar el papel de observadores silenciosos
Si bien lo que está en el encabezado de esta sección ya está consagrado en el manual oficial de Scrum, el análisis de la discusión muestra que esta regla, que es triste, a menudo se viola en las reuniones diarias a las que asisten los gerentes. Debido a esto, los programadores sienten la necesidad de explicar por qué los trabajos de tickets están demorando más de lo planeado. Si solo hay programadores que asisten a la reunión, hay poca necesidad de tales explicaciones. Esto es lo que dice el manual de Scrum al respecto: “Daily Scrum es una reunión interna del equipo de desarrollo. Si alguien más está presente en él, el Scrum Master se asegura de que no interfiera con la reunión ".
▍6. Las personas deberían ser más importantes que los procesos
Para obtener orientación sobre cómo aplicar las reglas de Scrum, lea las palabras escritas por el usuario Frank Hopkins para recordarle un principio clásico: "Las personas son más importantes que los procesos". Aquí agregó lo siguiente: "Un buen equipo debe definir sus procesos, los procesos rígidamente definidos no contribuyen a la formación de un buen equipo".
Otro usuario, Meriton , señaló que el uso de Scrum depende de programadores individuales: “Scrum no estipula que los desarrolladores trabajen de forma independiente unos de otros. Scrum estipula que el equipo de desarrollo se autoorganiza, es decir, que el equipo toma decisiones sobre cómo interactúan sus miembros ". Notas de
nvoigt de usuarioque los equipos en Scrum se autoorganizan debido al hecho de que llegan al proyecto con una misión definida: “El marco de Scrum se basa en el hecho de que eres un equipo. No importa en el equipo si el ticket fue cerrado ayer por un programador específico. Cualquiera que trabaje en un equipo comprende el objetivo (es decir, el Departamento de Defensa) y se esfuerza por lograrlo junto con el resto del equipo ".
▍7. Construya equipos para trabajar como Scrum, pero no espere que Scrum cree un equipo
Usuario nvoigtaplicó una metáfora deportiva: “Imagina que 11 personas reciben un manual de fútbol impreso. Se les dijo que tenían que practicar alrededor de las 10 am todos los días en la Sala de Conferencias 5, dedicando 15 minutos cada uno. ¿Crees que el resultado será un buen equipo de fútbol? ¿Y si estas 11 personas fueran buenos futbolistas profesionales? ¿No funcionaría el comando de todos modos? Sí, no lo haría. Es solo que los equipos de fútbol no se crean de esa manera. Como cualquier deporte de equipo, Scrum necesita que aquellos que usan este marco sean un equipo. Si es solo un grupo de personas, cada uno de los cuales solo quiere ganar puntos para sí mismos mostrando cuántos puntos en la historia del usuario han cubierto, o cuántos objetivos lograron, entonces este grupo siempre perderá contra un equipo cuyos miembros juegan juntos, y no uno al lado del otro. amigo,o unos contra otros ".
Salir
El usuario de nvoigt está dispuesto a admitir que Scrum "no es adecuado para absolutamente todas las personas o equipos". Y, como ha demostrado el interés de la comunidad en el tema que estamos discutiendo aquí, aplicar un conjunto de reglas que Scrum podría impulsar para desarrollar puede llevar a un entorno de trabajo que está lejos de lo que le gustaría construir.
Nos gustaría resumir el resultado de este material con las palabras del usuario Seth R... Dice que no hay necesidad de esperar milagros de rituales ágiles. Demasiado es querido por quienes buscan con su ayuda, como por arte de magia, corregir las deficiencias del equipo de desarrollo. Así es como ve la situación: “Se trata de acelerar la retroalimentación. Como resultado, el equipo tiene la oportunidad de autoevaluarse y tomar decisiones sobre cómo trabajar para lograr los mejores resultados. Scrum no lo ayudará a crear un mejor producto, pero si se toma en serio las autoevaluaciones, puede ayudarlo a construir un mejor equipo. Esto, a su vez, conduce al desarrollo de un mejor producto ".
Mucha gente compara este marco con la democracia. Entonces, ¿tal vez Scrum es la peor forma de gestión del desarrollo, aparte de todos los demás?
O tal vez sea, como dice la guía oficial , un marco que es fácil de entender pero difícil de dominar a la perfección.
¿Cómo respondería a la pregunta del título de este artículo?
