Al observar las prácticas ágiles comunes, me parece que (¿intencionalmente o no?) Obligan a los desarrolladores a dedicar más tiempo a trabajar en lugar de leer blogs / artículos, chatear, tomar un café y simplemente postergar.
En particular:
1) Programación en pareja: el mayor forzador de trabajo, solo porque es inconveniente hacer toda esa procrastinación cuando hay dos de ustedes sentados juntos.
2) Historias breves: cuando tiene una ENORME porción de trabajo que debe realizarse, por ejemplo, en un mes, es bastante común que se relaje en las primeras tres semanas y cambie al modo OMG DEADLINE para la última.
Y con los pequeños trozos (que se deben hacer en un día o menos) es exactamente lo contrario: siente que el tiempo es escaso, no hay espacio para maniobrar y se le hará responsable de la tarea muy pronto, por lo que comienza trabajando de inmediato.
3) Comunicación y cohesión en equipo: cuando tiene un bajo rendimiento en un entorno lento, distante y silencioso, puede sentirse bien, pero cuando al final del día en la reunión de Scrum, todos se jactan de lo que han logrado y no tienen nada que decir que realmente pueden sentir avergonzado.
4) Pruebas y comentarios: una vez más, le impide mantener las tareas "99% listas" (cuando en realidad es alrededor del 20%) hasta que la fecha límite de repente ocurra.
¿Sientes que con Agile trabajas más que con metodologías "convencionales"? ¿Esta presión es compensada por el ambiente más cómodo y por la sensación de hacer las cosas bien rápidamente?
Respuestas:
La idea principal detrás de los métodos ágiles es ayudarlo a ser productivo, en un sentido positivo. A nadie le importa si pasas una hora navegando todos los días si cumples con la fecha límite. Todos se enojan si navegas media hora todos los días, pero no cumples con tu fecha límite. La solución: facilitarle el cumplimiento de la fecha límite.
Como notó, la programación de pares asegura que se mantenga enfocado (entre todas las otras ventajas, como mejorar la difusión de habilidades / conocimientos, mejor código, menos errores, diseño uniforme, etc.).
Descubrí que la disciplina siempre es una lucha para mí. Si me emparejo con alguien, lo más probable es que uno de nosotros quiera que se haga un trabajo hoy y haga que el otro avance. Entonces, "trabajar por un mes" a menudo se convierte en "trabajar juntos durante una semana", sorprendiéndose de cómo esa gran cantidad de trabajo se resolvió al final, pasar un día más o menos recuperándose (refactorizando, arreglando TODOS en el código, agregando un un par de pruebas, navegando con la conciencia tranquila) y luego agarrando el próximo mes de trabajo.
Resultado neto: estoy mucho más relajado (más porque a pesar de la supervisión constante), la cohesión del equipo es mucho mejor, el trabajo se realiza más rápidamente, las personas no se quedan con algún problema menor durante horas o incluso días (porque alguien más puede detectar el problema mucho más rápido).
Cuando dices "puedes sentirte realmente avergonzado", ¿no es eso algo bueno? Significa que sientes que hiciste mal y deberías. No te pagan por no hacer nada. No hacer nada te hace sentir impotente, infeliz, indigno, miserable. En lugar de sentirte avergonzado, retrocede y piensa "¿Por qué no logré nada hoy?" ¿Necesitas ayuda? ¿Hay algo que no entiendas? ¿La tarea actual es demasiado difícil? No te gusta Tal vez puedas cambiar la tarea con otra persona. Quizás alguien más pueda ayudarte a superarlo. Ágil significa: asumir la responsabilidad en lugar de ser microgestionado como un títere con cuerdas. ¿Necesitas una herramienta? Ve a tu jefe y pídelo. Aprende a discutir. Aprenda a ponerse de pie y gritar cuando sea necesario.
En cuanto a las pruebas, hay un punto óptimo cuando su código colapsa repentinamente de "agradable" a "perfecto". Ese es el momento en que te das cuenta de que necesitas implementar la función X y crees que será una pesadilla y de repente te das cuenta de que el código está casi allí. Solo una pequeña refactorización aquí y allá. Una nueva clase y listo. Cuatro semanas de trabajo de repente se convirtieron en un día. ¡Victoria! ¡Triunfo!
fuente
Estoy de acuerdo.
Es una forma de trabajo muy intensa y exhaustiva, y nunca la aplico a menos que tenga algunos desarrolladores que necesitan ser entrenados por otros (nuevos participantes, por ejemplo)
Sí Ágil y específicamente Scrum es un gran impulsor de productividad. Cuando se aplica correctamente, la rotación puede ser de hasta el 20% (1 desarrollador en 5 abandona la empresa).
La razón es simple: Scrum no proporciona más productividad
it provides the whole company with much more visibility on what's going on(incluso en la gestión, por supuesto).Hace imposible que un desarrollador solo haga lo mínimo. ¡El mínimo es ahora el promedio del equipo!
Hace imposible que la gerencia no colabore adecuadamente.
Es por eso que dije (en mis otras respuestas en preguntas similares), que Agile NO es para todas las organizaciones (y para todos).
Por ejemplo, el sector público realmente no es adecuado para Agile.
¿Ágil se utiliza como herramienta de presión? Por supuesto, lo he visto muchas veces. Simplemente empeora las cosas.
fuente
Me hace trabajar más, pero, sobre todo, me hace trabajar en lo correcto. En cualquier momento sé lo que debería estar haciendo .
Es una especie de presión positiva. Eso es bastante diferente de algunos externos "ya está retrasado, ¡trabaje más, codifique horas extras!" -tipo de presión.
fuente
En realidad, soy mucho más productivo cuando uso los métodos convencionales. Con el método convencional, creo, por ejemplo, un análisis detallado de requisitos, un estudio de viabilidad, una especificación funcional, una especificación técnica y muchos protocolos de reunión, ¡todo en unos pocos meses! ¡Incluso podría crear algunas líneas de código una vez que se realiza el análisis de impacto!
Ágil, todo lo que creo son unos pocos entregables.
fuente
En nuestra compañía,
Programación por parejas: cuando algo realmente complejo requiere un análisis amplio, incluso podríamos reunir a dos personas excelentes y hacer la tarea en tiempo RÁPIDO. Aquí la complejidad de la tarea decide la necesidad de programar pares.
Relatos breves: luego, durante 3 semanas (aproximadamente 5-6 horas por día) y corriendo en el último momento (aproximadamente 12 a 14 horas por día) como desarrollador, no me gusta tener una oscilación en mi carga de trabajo. Trabaje alrededor de 8 horas por día y mantenga su horario estable y esto siempre se ve FRESCO.
Comunicación y cohesión del equipo: en la reunión scrum no solo compartimos el estado de la tarea sino también los obstáculos. Aquí, cuando alguien realmente necesita ayuda, a otros miembros se les ocurren ideas para ayudarlo. Pero ciertamente necesitas un excelente equipo para esto y estamos :)
Pruebas y comentarios: Ciertamente, como desarrollador, no quiero que me carguen de errores por fin, el siguiente momento después de que encuentre un error fue solucionarlo y nuevamente, esto me permitiría tener un buen pronóstico de lo que debería / puede A continuación, vuelva a programar la fecha límite (si es necesario).
Entonces, como desarrollador, estoy muy contento con el tipo de tarea que tomo y estoy seguro de que puedo decir que nunca sentí la presión REAL de la fecha límite.
fuente
Usualmente pienso en términos de Ferrari (como convencional) vs Landrover (como Scrum). Cuando se conduce por una autopista, Ferrari supera a Landrover.
Es todo terreno cuando se necesita un jeep, no un auto deportivo; quiero decir, si sus requisitos son irregulares y / o si el trabajo en equipo y la experiencia gerencial no son tan buenos, tendrá que elegir Scrum, simplemente porque tratar de hacerlo convencional obtendrá te atascaste, como Ferrari se quedará fuera de la carretera.
En cuanto a "trabajar más" , bueno, creo que uno que espera cosas así probablemente subestima el coeficiente intelectual del programador y su capacidad para adaptarse a diversas formas de gestión de la demencia .
Hasta ahora, participé en dos equipos Scrum haciendo proyectos bastante diferentes en diferentes compañías. En ambos equipos no noté ningún cambio en mis hábitos en comparación con, por ejemplo, cascada / iterativo.
fuente
Agile obliga a los programadores a hacer un trabajo más útil, porque las diversas técnicas de desarrollo ágil eliminan el trabajo ocupado y el trabajo que simplemente no es necesario.
fuente
Estoy en desacuerdo. Trabajé con un grupo de fumadores y todos lograron tomarse un descanso juntos durante períodos prolongados porque "todos lo hacían".
Esta es una señal de mala gestión, independientemente de la metodología. Incluso si se espera una gran parte en un mes, esperaría ver algo al final de la primera semana.
Si estás dispuesto a masturbarte durante tres semanas, pensarás en algunas tonterías que decir.
Los proyectos en cascada pueden tener pruebas y construcciones diarias.
Personalmente, odiaría escribir código y no tener nada que hacer durante un mes. Prefiero el ciclo de retroalimentación más corto en mi código, ya sea una revisión codificada o el cierre de sesión del usuario. Hacer que otros aprueben mi trabajo es gratificante. Es como el gato que deja caer un mouse en tu puerta solo para hacerte saber que está haciendo su trabajo.
fuente
Agile no obliga a los desarrolladores a trabajar más , sino a trabajar de manera más eficiente
fuente
Plantear la pregunta 'obligar a los desarrolladores a trabajar más' parece un poco negativo, pero seguramente es positivo si realmente hacemos más y postergamos menos.
Dicho eso, es un buen punto. Me he sentido un poco agotado con agilidad este año, pero este es un gran beneficio no escrito que no había reconocido.
Estoy de acuerdo en que ágil puede llevar a los desarrolladores a ser más productivos. Sus puntos sobre la visibilidad, la responsabilidad y la tendencia a posponer menos son todos muy ciertos.
Pero ágil puede y también debe llevar a los desarrolladores a trabajar más duro por razones positivas: la zanahoria frente al palo. Bien hecho, ágil dará a los desarrolladores más interacción con los usuarios, menos beuracracia, más control sobre su trabajo, todo lo cual puede llevar a obtener más de su equipo.
fuente
más trabajo aún no es semánticamente correcto o relevante para Agile, el objetivo es ser más productivo . Se enfoca específicamente en trabajar menos en lo incorrecto y más en trabajar normalmente en lo correcto ; lo que no significa trabajar más , solo de manera más productiva .
Un efecto secundario es que expone a los holgazanes y a aquellos que son poco eficientes o poco competentes muy rápidamente. Lo que suena más a lo que estás llegando.
La metodología es irrelevante sobre si un desarrollador no funciona o no . El proceso es, incluso en cascada, las revisiones de gestión y las revisiones de código pueden exponer estas cosas que no hacen nada, solo que no son tan transparentes como la mayoría de las metodologías ágiles.
fuente
"Las armas no matan a la gente. ¡La gente mata a la gente!" Es lo mismo con Agile. Agile no hace que las personas trabajen más, los gerentes hacen que las personas trabajen más.
fuente