¿La metodología ágil está empeorando la vida de los desarrolladores?

No lo creo. ¿Quién debería realmente tenerle miedo a lo ágil?

Hoy en día, muchas compañías de software implementan una metodología ágil en su actividad. Esto conduce a ciertos cambios en el procedimiento de trabajo y la organización interna de la propia empresa.

En primer lugar, una metodología ágil presupone una autogestión del equipo. Como resultado, el proyecto no necesita gerentes, gerentes de proyecto y líderes de control de calidad. Pero, ¿qué deben hacer estos especialistas? ¿Realmente estarán en dique seco?

Ciertamente, no lo harán. Las pruebas de software son ágiles en sí mismas, y uno puede regresar rápidamente a otro especialista o volver a las tareas que se realizaron anteriormente. Pero hay muchos matices aquí.

Especialmente, sería difícil para aquellos gerentes cuyo trabajo se limitara a la comunicación y la representación de resultados de todos los procesos en un tiempo determinado. Tal pseudoespecialista no entra en los detalles del trabajo: las pruebas móviles , la verificación de sitios web, las pruebas de juegos, las pruebas de aplicaciones bancarias, las pruebas de la tienda en línea o las pruebas de aplicaciones de escritorio están fuera de su interés, lo principal es entregar los resultados al cliente en hora.

¿Qué enfrentará el gerente en el caso de la implementación de metodología ágil?

  • Uno debe volver a la ejecución de las tareas prácticas, participar activamente en el proceso de creación y prueba del producto, no simplemente decirle al equipo qué y cuándo deben hacer.
  • Es muy difícil convencer a otras personas de que exactamente su punto de vista es correcto. Es importante que un equipo comparta la opinión del gerente y su visión del proceso completo.
  • Se debe cambiar el sistema de evaluación de los resultados del trabajo. Es necesario centrarse no solo en el resultado, sino también en los métodos y peculiaridades de la realización del plan de trabajo.

Parece haber una gran falta de comprensión sobre lo que es Agile, según las respuestas dadas hasta ahora.

Comprender Agile es fácil, implementarlo es difícil. La razón por la que es difícil es porque el proceso Agile está diseñado para optimizar una organización para la entrega rápida de lo correcto y la capacidad de cambiar de dirección rápidamente.

Cuando las organizaciones están optimizadas para otras cosas, como especialización profunda en conjuntos de habilidades, equipos de componentes, costo y no valor, mantener a las personas ocupadas en lugar de innovar …

entonces Agile es realmente difícil.

Cuando es difícil, a menudo es el equipo el que siente el pellizco. Un buen Scrum Master y Product Owner pueden mantener el choque cultural lejos del equipo para que puedan funcionar mejor, pero a menos que la organización esté tratando activamente de adaptar Agile más allá del equipo de desarrollo, entonces es un proceso doloroso.

En resumen, Agile no es el problema, es el choque cultural de la organización.

Como alguien dice, puede cambiar el proceso o la organización, por lo que si no puede cambiar la organización, debe cambiarla.

El proceso funciona bien 🙂

Gracias

Simon

Considere una característica de Agile / Scrum, la “Reunión diaria de standup”. Solíamos hacerlos donde trabajaba, y perdía 30-60 minutos por día.

“Scrum” lleva el nombre de la parte de Rugby donde una pila de cuerpos se empujan entre sí y se pelean para obtener la pelota.

Supongamos que el “standup diario” es a las 9am. Pero no puede ir a trabajar a las 9 a.m. (debido a la incertidumbre con el tráfico / metro). Entonces, para hacer la “reunión diaria”, debe apuntar a ponerse a trabajar entre las 8: 30-8: 45am.

Pero no puede hacer nada antes de la reunión diaria, porque lo interrumpirán a las 9 a.m.

Y durante la reunión diaria, dos personas siempre se distraen por algún tema que no le afecta, y terminan hablando de eso por más de 15 minutos. Entonces, la reunión diaria promedia 30 minutos. (Sé que esa no es la forma correcta de hacer reuniones diarias, pero así es como funcionaban las personas a las que asistí). Además, el 95% + de las cosas en las que otras personas están trabajando no me afecta, por lo que realmente no necesito hacerlo. ir a una reunión para escucharlo.

Entonces, la reunión diaria mata casi una hora de productividad por día. (8: 30-9: 30)

Si alguna vez tengo mi propio negocio, espero que mis competidores usen Agile y Scrum, para poder correr círculos a su alrededor.

Ágil por sí solo no lo hace. Pero la mala comprensión e implementación de ágil sí. Cualquier implementación de Agile que haga que un desarrollador haga una pregunta como esta no es Agile en primer lugar.

Había escrito una publicación de blog sobre este tema. El título es “Ágil no es para ti si”. Aqui esta el link

http://agiledevtest.blogspot.in/

Creo que si

#Agile es visto como un Silver Bullet que resolverá todos los problemas (incluido un mal caso de negocios)
# La gente piensa que los requisitos se pueden cambiar cuando lo deseen.
#Agile se usa como una excusa para una mala ingeniería de software
# El concepto de time-boxing no se entiende completamente

Creo que son los ingenieros quienes realmente sienten el calor de la agilidad en mayor medida. Para leer sobre la realidad real que enfrenta un ingeniero, lea esta publicación: ¿Qué es este Agile de todos modos? Es un verdadero relato de un ingeniero a la parrilla por Agile.

Si. Debido a que la mayoría de los mocosos de la vieja escuela que se han dedicado a la gestión y el liderazgo piensan que la metodología ágil es realizar cambios en los requisitos cuando lo deseen y todavía esperan cumplir con los mismos plazos sin pensar en el estado futuro del producto.

¿Qué mundo sería si los desarrolladores establecieran los plazos y esperaran que el liderazgo planifique en base a eso?

Sí, si la administración lo usa para la microgestión, de lo contrario, Agile es para personas, por lo que de ninguna manera empeorará la vida del desarrollador.

More Interesting

¿Cuál es el propósito de la gestión de calidad del software?

Desarrollé un motor de base de datos en el trabajo y entiendo bien los conceptos básicos, como los árboles B y la integridad transaccional. ¿Cuál sería un buen libro sobre los temas avanzados, como los tipos de índice poco comunes y las técnicas para indexar el lenguaje natural?

¿Cómo es la Universidad Carnegie Mellon de Silicon Valley, California para el curso y las perspectivas laborales? ¿Puede alguien sin antecedentes de CS en pregrado solicitar MS en Ingeniería de Software sin carta de recomendación (pero con puntajes decentes GRE / TOEFL / CGPA) y ser aceptado?

¿Es posible cambiar de ingeniería de software a ingeniería biomédica?

¿Está bien que un ingeniero senior con 7 años de experiencia trabaje continuamente en un campo técnico durante 3 años más?

Alibaba registró un récord de ventas de $ 9 mil millones en un día durante su venta del Día del Soltero. ¿Qué pasos tomó para llevar a cabo operaciones tan masivas sin problemas técnicos en términos de tráfico y otras cosas?

¿Cuál es el crecimiento de la habilidad en la nube y Devops en la industria de TI?

¿Es un buen salario de $ 110ka en el área de la bahía de SF para un nuevo graduado de MS con dos años de experiencia laboral como ingeniero de software?

¿Por qué los desarrolladores de software siguen haciendo 'generadores' de algún tipo? Por ejemplo, un generador de sitios web. ¿No es eso quitarle el trabajo a otros desarrolladores?

¿Qué lenguajes de programación que combinan bien deberían aprender para el desarrollo de inteligencia artificial, la ciencia de datos y el desarrollo de software?

¿Por qué casi todas las compañías de software (en India) solo usan Linux o Unix en sus oficinas?

¿Cuáles son algunas decisiones de programación aparentemente inofensivas que volvieron para atormentarte?

¿Cuál es el tamaño estándar para Agile Team?

¿Cómo podemos procesar números incluso más grandes que largos?

¿Debo dejar mi trabajo e ir a Dev Bootcamp?