¿Es el enfoque ágil una excusa demasiado conveniente para los vaqueros?

Creo que un enfoque ágil es mejor para proyectos donde los requisitos son confusos y se requiere mucha interacción para ayudar a dar forma a las ideas del usuario final.

Sin embargo ... En mi trabajo profesional, sigo terminando en empresas donde se utiliza un enfoque "ágil" como excusa de por qué no se hizo ningún esfuerzo en un diseño inicial; cuando los requisitos se entienden bien.

No puedo evitar pensar que si el enfoque ágil no existiera, estaría sentado aquí con una buena especificación de alto nivel y sin tener que volver a visitar la misma pantalla y funcionalidad cada dos días cuando surge algo más. y entonces no había pensado en eso.

¿Los beneficios de las metodologías ágiles son realmente suficientes para superar la excusa por ser cojo que da a los conductores técnicos de vaqueros?

Actualización: Irónicamente, ahora soy un Scrum Master certificado. Uno de los documentos presentados en el curso Scrum observó que el mejor proceso de desarrollo era uno en el que había un solo experto o gurú que tomaba las decisiones de diseño, sin embargo, eso tenía debilidades obvias. Scrum transfiere la responsabilidad de producir software de calidad al "Equipo", lo que significa que un equipo de calidad inferior puede salirse con la suya produciendo espaguetis que supongo que no es diferente a otros procesos de desarrollo ágiles y no ágiles.

Creo que si está utilizando el desarrollo ágil como una excusa para la programación de estilo vaquero, entonces realmente no está siguiendo el desarrollo ágil. Los vaqueros siempre serán vaqueros, sin importar el proceso que les des.

Agile no tiene más culpa de las malas prácticas de desarrollo que BDUF. El problema radica en la disciplina, o falta de ella, en la aplicación de las prácticas. El propósito de las prácticas de BDUF es identificar la dirección del proyecto y determinar los riesgos de antemano. El propósito de las prácticas ágiles es mantener el estado del desarrollo lo suficientemente flexible como para cambiar rápidamente de dirección. Un proyecto ágil podría preparar historias de usuario altamente detalladas para que el equipo esté al tanto de las direcciones futuras y todavía solo seleccione 2 o 3 por iteración para implementar completamente. El problema sigue siendo el mismo, cualquiera que sea la metodología utilizada: la administración está dejando que los vaqueros se vuelvan locos.

[BDUF: Gran diseño por adelantado]

Agile, como cualquier cosa , puede usarse para cubrir un mal comportamiento o para tratar de resolver un problema del que el equipo cree que no es responsable.

Sin embargo, la magia en algunas metodologías ágiles como Scrum es que proporcionarán mucha visibilidad sobre los problemas dentro de la organización. ¡Incluyendo problemas dentro del equipo!

Luego se le dará la oportunidad de resolverlos a medida que surjan.

Si el problema es de los vaqueros, esto será muy visible después de la primera iteración. Si el problema está en otra parte, lo verá muy pronto también.

Por extraño que parezca, de los proyectos "ágiles" en los que he estado involucrado, parece más una excusa de la gerencia para omitir la fase de recopilación de requisitos que un deseo del vaquero de simplemente comenzar a codificar. Mis proyectos han sido extremadamente frustrantes porque no tenemos usuarios finales con los que interactuar. En cambio, tenemos un director que habla con las ventas para averiguar qué creen que quieren los clientes, luego convoca una reunión y se lo describe a los gerentes, quienes luego comienzan a asignar tareas a los desarrolladores. En un proyecto "bueno", podríamos tener una presentación PP a la que referirnos, pero generalmente terminamos pasando nuestras reuniones diarias de scrum preguntando cómo se supone que funcionan algunas características, y el gerente anota las preguntas y le pregunta al director. Es una gran pérdida de tiempo, ¡pero es "ágil"!

No diré que soy un fanático de Waterfall, ya que yo también trato con el alcance del frustrante alcance siempre frustrante, pero siempre he visto a Agile como una concesión al problema, no como una forma efectiva de combatirlo. Un buen diseño, con pruebas iterativas tempranas y muchos prototipos en papel, parece ser mucho más efectivo.

Veo defensas de Agile Development que dicen que no es responsable de las fallas causadas por los vaqueros. El éxito con Agile requiere diligencia e inteligencia.

Esta parece una posición razonable, siempre y cuando aplique la misma concesión a otras metodologías. Si no puede culpar a Agile por fallas en los proyectos causadas por vaqueros, no puede culpar a las metodologías no ágiles por fallas en los proyectos causadas por vaqueros.

Entonces podemos discutir si existe una correlación (¡no causalidad!) Entre Agile y los vaqueros. Con solo evidencia anecdótica, creo que la hay. ¿Se percibe como una buena manera de salir adelante con las prácticas de vaqueros sin ser detectado por la gerencia?

Por supuesto, si aceptamos que los vaqueros pueden no estar distribuidos uniformemente entre las metodologías, y aceptamos que los vaqueros socavan el uso exitoso de un proceso, haremos que sea muy difícil probar si un proceso es exitoso. La afirmación de que un proceso es mejor (dentro de un contexto) se vuelve casi imposible de verificar. Este es uno de los problemas que me hace avergonzarme de mi profesión: la falta de fundamento científico de muchas de las afirmaciones.

(Por cierto, odio llamar a la (s) alternativa (s) a Agile "cascada", porque los procesos en cascada parecen ser un hombre de paja que todos atacan, pero muy pocas personas realmente utilizan sin ninguna iteración.

Agile está bien siempre que funcione para su equipo.

Demasiados lo están vendiendo como una forma de convertir un mal equipo en un buen equipo, y simplemente no funciona de esa manera. No puedes tomar a las personas malas y aplicar un proceso para que de repente sean útiles.

Me gustan muchas de las ideas detrás de ágil, pero el fracaso que veo una y otra vez es que los gerentes están presionando un estricto conjunto de "procesos ágiles", que va en contra de todo el concepto de ágil, que los equipos deberían ser independientes -organizando.

En cuanto a los "vaqueros", encuentro que para todos los equipos ágiles en los que he estado, los procesos sirven para ralentizarlos más que dejarlos enloquecer. Nunca he experimentado una situación en la que ágil sirviera para permitir un "codificador de vaquero".

Para los buenos equipos, parece funcionar bien (una vez más, la mayoría de los procesos parecen funcionar bien cuando se tiene un buen equipo, es curioso cómo funciona, ¿no?).

Para otros equipos, en mi experiencia, nunca ayuda a las personas malas a mejorar, pero a veces sirve para empantanar a las personas productivas.

En general, creo que lo importante es formar un buen equipo, decirles lo que necesita y luego salir del camino. No creo que aplicar ninguna cadena de palabras de moda pueda resolver el problema de tener un mal equipo.

(Si no te has dado cuenta de lo anterior, no soy fanático de "Capitol-A Agile" en lo más mínimo. Por otro lado, tampoco creo que anime a los vaqueros).

Ágil cuando se hace correctamente debería tener el efecto de controlar a los líderes técnicos "vaqueros" y los programadores "héroes". Si no observa este efecto, puede ser una señal de que falta algo importante en su implementación ágil.

Quiero agregar que "Agile" es realmente una interfaz (estoy usando una metáfora orientada a objetos aquí) y no se puede crear una instancia. Si su implementación concreta es XP , entonces debe seguir un montón de prácticas técnicas con mucha disciplina, lo que deja poco espacio para la programación de vaqueros. Otra posibilidad es que el trabajo en equipo de un equipo Scrum bien autoorganizado lo mantenga bajo control.

Los codificadores de vaqueros también tienden a escribir código que no es muy comprobable, y no les gusta escribir pruebas. Creo que tener a todos haciendo TDD puede ayudar a reinar en la actitud de vaquero y hacer que los desarrolladores piensen un poco más en la arquitectura. Ninguna metodología es perfecta, por supuesto.

Actualmente estoy trabajando en una tienda donde este es el caso, excepto que tiene más que ver con la cultura organizacional que con los vaqueros individuales en particular.

La organización siempre ha operado con un enfoque relativamente flexible, "ágil informal". No diría que es realmente ágil, es más "ágil en nombre", pero simplemente una metodología inexistente en la práctica. Los diferentes equipos operan de manera diferente, pero dado que la cultura organizacional general no tiene una metodología establecida que no sea un proceso muy flexible de "Ágil solo en nombre", es relativamente vaquero y caótico en general, especialmente en la integración (y hay mucho de eso )

La moraleja de la historia es: Sí, esto sucede. Si estuviera buscando trabajo en este momento, sería muy cuidadoso con esto. Si una tienda dice ser ágil, haría algunas preguntas bastante difíciles en la entrevista para asegurarme de que se siga más que un nombre inapropiado de Agile.

Descubrí que los usuarios solo pueden darnos su opinión una vez que tienen una aplicación que pueden usar, pantallas en las que pueden ingresar datos. Solo entonces, realmente entienden lo que estábamos tratando de decir en los documentos de requisitos (que los clientes firman pero todos tienen su propia versión del significado). Si no es un desarrollo ágil, será un proyecto en cascada que supere el presupuesto, pero la aplicación cambiará una vez que lo entregue. Su primera versión no es más que un prototipo para que los usuarios discutan cuáles deberían haber sido los requisitos. Así que prefiero llamarlo ágil que por encima del presupuesto.

Creo que es cierto, en algunos entornos Agile se utiliza como excusa para no disciplinar. El verdadero problema es que hemos perdido de vista por qué tenemos alguna metodología. Personalmente, creo que la metodología es un problema arquitectónico en el sentido de que se supone que la arquitectura del sistema aborda los atributos de calidad no funcionales, la metodología debería abordar algunos de esos mismos atributos (mantenibilidad, productividad del desarrollo, transferencia de conocimiento, et al.)

Ver la metodología como un control para los atributos del proceso implica un par de cosas: 1) sin métricas, no podemos comparar la efectividad de una metodología sobre otra, 2) es necesario tomar una decisión activa sobre qué atributos son importantes (tiempo de entrega versus código calidad vs transferencia de conocimiento).

Sin tener métricas y un objetivo tangible, simplemente elegimos una metodología como nuestra "pluma mágica" que, si nos aferramos a ella, podremos entregar software.

Ahora los que dicen en contra de Agile, XP, Scrum, etc. hablan sobre la fragilidad de esa categoría particular de metodologías. El argumento es: ¿por qué usar una metodología que pueda ser saboteada por un individuo que carece de la disciplina para seguir todas las reglas? La pregunta es válida; sin embargo, ese es el síntoma, no la causa. Si un conjunto de métricas de proceso precisas y significativas (esa es la parte difícil) se definen, prueban y reciben comentarios oportunos, creo que descubriremos que la metodología particular tiene poco que ver con el éxito. (Hablando de manera anecdótica, he visto proyectos exitosos que usan una miríada de metodologías y el doble de los que fallan usando las mismas metodologías)

Entonces, ¿cuáles son las métricas? Varían de proyecto a proyecto, de equipo a equipo y de vez en cuando. Útil para cuando el cronograma de entrega es importante, uno que personalmente he usado es la habilidad y la calidad de la estimación. La mayoría de los desarrolladores pueden estimar con precisión las tareas que duran una semana o menos. Entonces, un enfoque es dividir el proyecto en tareas de un desarrollador de una semana de duración y rastrear quién hizo la estimación. A medida que avanza el proyecto, pueden cambiar sus estimaciones. Después de completar una tarea, si está desactivada en más del 10% (1/2 día), tratamos esto de la misma manera que un error: identificamos por qué la estimación estaba desactivada (es decir, no se consideró una tabla de base de datos), identificamos acción correctiva (es decir, involucrar al DBA en la estimación) y luego continuar. Con esta información, podemos crear métricas como el número de errores de estimación por semana, el número de errores por desarrollador,

¿Y qué? Ahí es cuando entran las metodologías: si tiene un modelo predictivo que no cumple con las cualidades del proceso, puede optar por agregar o eliminar algún aspecto de la metodología y ver cómo afecta a su modelo. Por supuesto, nadie quiere jugar con un proceso de desarrollo por miedo al fracaso, pero ya estamos fallando a un ritmo consistentemente alto y predecible. Al hacer cambios individuales y medir el resultado, puede encontrar que Agile es la metodología perfecta para su equipo, pero podría encontrar fácilmente RUP, cascada o simplemente una combinación de mejores prácticas para ser ideal.

Entonces, mi sugerencia es que dejemos de preocuparnos por lo que llamamos el proceso, establezcamos controles que sean relevantes para nuestros objetivos del proceso de desarrollo y experimentemos con diferentes técnicas para mejorar ese proceso.

Estaría sentado aquí con una buena especificación de alto nivel y sin tener que volver a visitar la misma pantalla y funcionalidad cada dos días, ya que algo más surge y no había pensado en eso.

Eso parece coincidir con la experiencia de mi colega del proyecto "ágil" en el que se encuentra (nunca he estado en uno yo mismo): se le pide que escriba un fragmento de código con alguna especificación, justo cuando ha terminado de probarlo y está listo para moverse cuando surge un nuevo requisito que requiere que lo cambie y lo vuelva a probar. Lo encuentra frustrante.

No estoy criticando a ágil, sospecho que el equipo no lo está haciendo correctamente, pero como usted dice, el término "ágil" a veces puede ser utilizado por los vaqueros para convencer a la gerencia de que el diseño a medias es positivo en lugar de negativo .

Es curioso cómo nadie piensa de sí mismos como codificadores de vaqueros. Apuesto a que muchos de los carteles son o han sido uno;)

Los codificadores de vaqueros son buenos porque les gusta hacer las cosas rápidamente. A menudo no están tan preocupados por los problemas generales o la calidad del código, por lo que el "codificador de vaqueros" es a menudo un epíteto. Sus métodos mitigan los riesgos de costo de oportunidad de la entrega tardía del proyecto.

A los codificadores que no son vaqueros les gusta hacer su trabajo de manera segura, disciplinada y ordenada. Les gusta construirlo bien y construirlo una vez. Son conocidos por recopilar información para siempre, considerar qué sucede, producir documentos de gran tamaño que nadie lee y entregar sistemas tarde o muy tarde. Sus métodos intentan mitigar los riesgos del software de baja calidad.

La brillantez de las metodologías ágiles es que aprovechan las fortalezas de ambos tipos de codificadores al forzar iteraciones de trabajo de tiempo limitado que les piden a los codificadores que produzcan pequeños trabajos de alta calidad rápidamente. Y cada iteración mitiga los riesgos de costo de oportunidad de entrega tardía y los riesgos de software de baja calidad.

La razón por la que Agile pone muy poco énfasis en el diseño / especificaciones iniciales no es solo porque los requisitos pueden cambiar. La razón más profunda es que incluso cuando los requisitos son estables, las especificaciones tienden a ser:

• incorrecto: no puede capturar los requisitos.

• inconsistente - plagado de contradicciones porque contienen suficiente información para que sea imposible para el escritor / lector captarlas.

• independientes: no incorporan información valiosa de un sistema en funcionamiento (aunque degenerado).