Ingeniería de software: ¿Por qué algunas personas odian en Agile / Scrum?

Answer 1

La crítica común dirigida a Scrum puede ser causada por algunos conceptos erróneos al respecto. Recientemente, tuve la oportunidad de leer un excelente artículo sobre este tema creado por Jakub Grajcar con el apoyo de un especialista en esta área, Dominika Brzezińska.

El artículo señala 4 mitos comunes con contraargumentos también, que puedes encontrar a continuación:

1. “¡Scrum es todas las reuniones y no trabajo!” Es el juicio más popular que afirma que hay demasiadas reuniones de las necesarias para garantizar la efectividad del equipo. La verdad es que el proceso de planificación lleva solo el 15% del tiempo en Scrum. El resto (alrededor del 85%) es trabajo puro. Durante las reuniones, el equipo crea un claro sentido de la visión, el calendario y las acciones para brindar un servicio de alta calidad.
2. “Scrum no funciona en nuestra empresa” se dice muy a menudo después de un período de prueba. Después de eso, algunas empresas deciden que no es la mejor solución para ellos. Pero la verdadera pregunta debería ser “¿Mi empresa está lista para Scrum?”. Significa que la cooperación directa que ofrece Scrum requiere cierto tiempo para acostumbrarse y requiere los valores adecuados de la empresa. Seguro que no es una solución para organizaciones en caos, sin comunicación frecuente y abierta. La verdad es que en esta situación se esperará cierta resistencia en la implementación de cualquier sistema.
3. “Solo quiero programar, no necesito reuniones ni discursos” significa que los desarrolladores que son nuevos en Scrum pueden ver las reuniones de Scrum y el trabajo de Scrum Master y Product Owner como una pelusa innecesaria, interrumpiendo su flujo de trabajo. Es importante recordar que Scrum tiene un gran énfasis en el trabajo en equipo. Trabajar en un proyecto complejo requiere un conocimiento constante de la visión y los objetivos del producto. Se puede perder sin un plan de trabajo y realizar un seguimiento de las necesidades del cliente. Al final, a los desarrolladores se les paga por resolver los problemas del cliente, no por suministrar tantas líneas de código como puedan.
4. “¡Scrum Master es solo una niñera glorificada!” Algunos afirman que Scrum Master no es necesario para el funcionamiento del equipo. La verdad es que Scrum Master ayuda a seguir el marco cuando el equipo pierde motivación. Incluso si esta situación no ocurre y el equipo se autoorganiza, Scrum Master es necesario para:

• enseñando Scrum en la práctica
• mantener buenas prácticas cuando ocurre un cambio
• Empujando al equipo a mejorar durante el estancamiento.
• Dando una perspectiva externa sobre los retos.

Dominika Brzezińska, la Scrum Master entrevistada para el artículo, también mencionó el error Scrum número 1 , que es:

La gente hace cosas sin preguntar “¿por qué?”

Los adeptos de Scrum a menudo se centran en los pasos reales del proceso, pero hay una falta de razonamiento detrás de eso.

También hay un gran video que aclara la importancia de “por qué” en este caso. Lo recomiendo encarecidamente (encontrarás el enlace de abajo)

Tech Power Summit 2017 de STX Siguiente – YouTube

Si desea leer más, también lo invito a visitar el próximo blog de STX y leer la versión completa del artículo para profundizar en este tema.

Answer 2

De acuerdo en los puntos explicados por Patrycja Okowicka. Esto es lo que añadiría a eso:

La resistencia humana a los cambios y el miedo.

La gente, en general, tiende a disgustar los cambios, especialmente cuando se les impone. Es solo en la naturaleza humana proteger nuestra cómoda estabilidad.

Generalmente, los principios Scrum o Agile se presentan al equipo existente cuando hay algo que arreglar. Esto hace que las personas vean este cambio como si estuvieran investigando, por lo que se oponen por todos los medios.

También hay casos en los que los miembros del equipo temen perder sus trabajos o su posición despreocupada en el trabajo. De todos modos, Scrum no tolera el enfoque de “entregamos cuando entregamos”, por lo que para mantener la posición que algunas personas necesitan para acostumbrarse a las nuevas dinámicas y comenzar a entregar dentro de los plazos estimados. Aquí es donde el odio tiene sus raíces.

Conceptos erróneos sobre Scrum y Agile

La otra razón por la que la gente odia a Scrum radica en varios conceptos erróneos al respecto. Al igual que el que dice que Scrum no puede funcionar para equipos distribuidos. Creo que es importante recordar que Scrum es una herramienta, no un remedio. Scrum en su comprensión clásica será difícil de aplicar al equipo distribuido (o cualquier otra condición específica). Para ser eficaz, la metodología Scrum necesita ser ajustada. Aquí es cómo se puede hacer en el ejemplo de equipos distribuidos.

También recomiendo leer esta publicación del blog sobre el tema (y diviértete con fotos increíbles mientras lees 🙂

Answer 3

Mi opinión sobre esto es:

1. No se presta a las personas que desean BRUF (grandes requisitos por adelantado) y desean estimaciones detalladas y un plan detallado antes de comenzar un proyecto. Algunas partes interesadas quieren esto, no es así como funciona Scrum / Agile. Las personas que dicen que odian Scrum tienden a no entender las diferencias fundamentales entre la cascada y lo suficientemente ágiles como para incluso debatirlo. En muchos casos, las empresas, equipos y similares no se esfuerzan lo suficiente con Agile. ¿Hacen las prácticas y se preguntan por qué no están entregando? Bueno, porque asistir a algunas reuniones y obtener una pizarra blanca no es lo suficientemente profundo. Pregunta a 100 equipos cuáles son los principios de ágil y te miran fijamente. Se trata de refinar continuamente el proceso, inspeccionar y adaptar como usted. Muchos de los equipos con los que he trabajado en el pasado, una vez que han dejado de lado los principios, simplemente se mantienen en eso, incluso si el proyecto cambia, el contexto, la complejidad y se preguntan por qué las cosas no van lo suficientemente bien.

Desde la perspectiva de los interesados ​​diría esto:

1. La alta gerencia quiere fijar el tiempo, el costo, la calidad y el alcance desde el principio: esto no funciona bien con los requisitos emergentes y pivotantes, hipótesis de cambio y pequeños experimentos para obtener un buen retorno de la inversión. Necesitas un buen PO para ayudar aquí.

2. Las personas se fijan en “cuándo” terminan, no en “por qué” lo están haciendo. ¿Hay algún valor de negocio? ¿Cuántas veces he tenido que decirle a los directores, “qué problema intentas resolver?” La solución que ellos mismos idearon tomó 6 meses y me dieron una fecha límite, toneladas de trabajo y podríamos haberles dado el 80% en 2 semanas. Entonces, ahora uso la palabra ‘no’ lotes … 95% de esfuerzo para entender la necesidad, la oportunidad o el problema percibido, luego el análisis de opciones, luego la priorización, el tema, la calma épica, y luego comenzar a trabajar en una solución que proporcione una Buen retorno de la inversión con la menor cantidad de esfuerzo. Agregamos valor 10 veces en el año, no una sola vez, días felices.

3. El esqueleto de scrum es un proceso empírico, por lo que la retroalimentación es clave. Si construyes un producto o una característica porque tu jefe tuvo una idea en la ducha y te llevará seis meses construir algo perfecto, has perdido el punto. Cuando bombardea y él o ella no está contento y culpa al equipo, bueno … A menos que tenga algún tipo de retroalimentación antes, ¿cómo podría saber si va en la dirección correcta o ahora? simplemente deja a la mente cómo la cascada deriva cualquier valor para cualquiera. NHS como ejemplo.

4. La mayoría de los equipos no saben cómo manejar las expectativas con estimaciones. Dar una línea de tiempo fija es una tontería, especialmente si está lanzando funciones una por una. Las estimaciones de alto nivel (semanas) con tolerancias son suficientemente buenas y se refinarán con el tiempo. Ver ‘cono de incertidumbre’. Si tiene una fecha arbitraria, comience a seleccionar las funciones de baja prioridad.

5. Algunas personas en la gestión odian ágil porque está mal implementado. Algunos lo odian porque no ven resultados / resultados, debido a una mala asignación de prioridades por parte de la OP, otros lo odian porque no tienen idea de lo que significa usar Scrum y no les importa. A algunos les disgusta porque interrumpe el comportamiento de comando y control de antaño, donde el Project Manager lo sabía todo, agregaba toda la información a sí mismos y distribuía instrucciones a todos los miembros del equipo. Personalmente, estoy encantado de que se haya interrumpido la gestión tradicional de proyectos. Con Scrum es más un esfuerzo compartido, el primer ministro no puede codificar, por lo que no puede decirles a los desarrolladores qué hacer y la orden de compra es más un facilitador entre las partes interesadas y el equipo. Tiene un mejor equilibrio y todos los miembros del equipo comparten el esfuerzo, las victorias y los fracasos. En las paradas, los miembros del equipo estacionan sus cerebros y esperan que se les diga qué hacer. Hace que todos estén más comprometidos.

Personalmente, creo que Agile puede ganar mucho más que una cascada. El costo del cambio es menor, reduce las relaciones contractuales entre las partes interesadas y el equipo, abarca el cambio y la incertidumbre, aumenta la colaboración y la comunicación y, en un buen mundo, entrega un producto enviable una vez que se realiza un sprint. Las partes interesadas se sienten más comprometidas, el equipo lo hace y todos están contentos. Puede que sea un idealista, pero he trabajado muy duro en los últimos 5 años para hacer que esto suceda en equipo, en todo el departamento / división. Puede trabajar con las personas adecuadas en su lugar. Buenos POs, buenos Scrum Masters / Agile Coaches / desarrolladores de software brillantes, entusiastas y talentosos.

Answer 4

¿Es la energía nuclear el mayor mal inventado? ¿O es una increíble fuente de energía?

Respuesta: ¡Depende de cómo lo uses!

Actualmente: Scrum es anti-ingeniería.

Scrum como todo en la tierra es una idea noble y poderosa que el capitalismo tomó y convirtió en una herramienta de monetización malvada, como la Navidad y el vegetarianismo. La forma en que normalmente se usa, hace que sea nada más que continuar con la creación rápida de prototipos mientras se ignora la deuda técnica, para generar su primera venta y puede ser una venta de la empresa, luego el horrible código base se convierte en el problema de alguien más. Es utilizado por jefes no técnicos para impulsar a los desarrolladores y trabajarlos hasta el hueso. Para microgestionar todo y pedirle que registre cada minuto de su día. Toda la deuda técnica acumulada no importa porque todo lo que necesita es mostrar su característica para venderlos. Luego, una vez que lo haces, culpas al equipo de desarrollo heroico actual por los errores y los reemplazas con otros. Se utiliza para que su código de comercio mono sea impulsado a producir, mientras que el talento de ingeniería se suprime. Empuja a Devs a elegir la solución más rápida para implementar, no la mejor solución, porque quién tiene tiempo para investigar e implementar esa nueva biblioteca o marco que lo convertirá en una prueba de futuro, cuando pueda marcar algunas líneas ahora, y luego cuando se produzca un cambio. A lo largo, eliminas esa mierda y comienzas desde cero. ¿Por qué intentar abstraer y reutilizar el código, cuando simplemente puede copiar y pegar? Porque cuando sobreestima o subestima su historia de usuario, la gerencia lo considera un ladrón, un perezoso o ambos. Porque cuando intentas objetar y plantear inquietudes acerca de ser obstaculizado por todo el seguimiento y la estimación, la administración dice: el proceso liviano es un privilegio que debes ganar. Y no culpe al maestro del scrum por ser un títere de administración que solo está ahí para espiar al equipo porque no está entrenado, pero no tenemos el presupuesto para el entrenamiento del scrum real. Pero nosotros somos scrum.

Otros también están de acuerdo

¿Por qué algunos desarrolladores de empresas fuertes como Google consideran que el desarrollo ágil no tiene sentido?

Answer 5

Agile tiene mucho sentido: entregue en pequeñas porciones, tenga un trabajo atrasado, mantenga las cosas flexibles, iteree, promueva el trabajo en equipo, entregue características regularmente, bla, bla, bla. Nadie puede discutir con nada de esto. Sin embargo, Scrum es una orgía de palabras de moda, comercializada con la promesa del aceite de serpiente de solucionar todos los problemas de desarrollo: costo / programa excedido, trabajo en equipo deficiente, proceso inflexible, usuarios infelices. Si no lo estás haciendo, debes hacerlo antes de que te quedes atrás. Desafortunadamente, las ideas de sonido básicas definidas en los Principios Ágiles han sido secuestradas por un frenesí alimentador de vendedores y una interminable publicidad de marketing. Ver mi perorata sobre todos los problemas que tengo con Scrum.

Answer 6

La razón principal es el mal uso, el malentendido y las implementaciones horribles de Agile. Muchos desarrolladores de software lo consideran como la excusa de la administración para una mayor microgestión, que es exactamente lo contrario de lo que Agile requiere.

Answer 7

Porque en lugar de hacer una cosa muy compleja a la perfección, se enfoca en hacer cosas pequeñas rápidamente para probar suposiciones. Prefieren medir el progreso como cuánto han hecho en términos de su especificación, donde las medidas de desarrollo ágil progresan, y cuántas suposiciones están evaluando. Básicamente, prefieren hacer un producto completo, libre de errores y de apariencia limpia, incluso si nadie lo quiere, y no les gusta cómo el desarrollo ágil o scrum puede tener errores o no tener un aspecto perfecto.

Answer 8

El desarrollo de software es un caos. Agile es un intento de orden. El orden puede ser llevado al caos solo temporalmente. Cualquiera que odie en él probablemente se vea obligado a seguirlo en todo momento. Es bueno tener pautas, pero las reglas deben romperse cuando el caos es máximo. El secreto que lleva más de 10 años en aprender es evitar la afinidad religiosa con cualquier estilo o práctica por cualquier cosa que tenga que ver con la tecnología, pero estar dispuesto a pedir prestado algo de eso.

Answer 9

Los clientes a menudo no pueden querer que se use porque están más contentos con un acuerdo en el que se proporciona una lista de estilo de Microsoft Project de resultados finales y costos específicos por adelantado, a menudo antes de que el producto esté diseñado. Esto nunca va bien, pero eso se encuentra más tarde.

Los proyectos gubernamentales tienen esta enfermedad en gran medida, pero también las grandes organizaciones, en realidad cualquier lugar donde alguien no pueda tener la libertad de tener éxito.

No he visto a los ingenieros que no les guste cuando se hace correctamente. Me imagino que estar involucrado en un proceso ágil mal organizado o de estilo de culto de la carga haría que la gente pensara que la idea era mala. Pero incluso hecho de manera incompleta, Agile puede ser bastante bueno para los desarrolladores.

Answer 10

Creo que son los ingenieros quienes realmente sienten el calor de lo ágil en mayor medida con las terminologías de Agile, Scrum, Sprint, User Stories, Stand-Up, Sync-Up, Burn down chart, kanban board, etc. . Para leer sobre la realidad real a la que se enfrenta un ingeniero, lea este post: ¿Qué es Agile de todos modos? Es un relato verdadero de un ingeniero que Agile ha interrogado.

Answer 11

Porque esta roto Para cambios incrementales, para pequeños proyectos, funciona bien. Para sistemas grandes y complejos, ignora cualquier cosa que se parezca a un diseño arquitectónico bien pensado, lo que lleva a sistemas realmente horribles.