¿Qué significa ser ágil?

Tenemos un proyecto que todos dicen que haremos de forma ágil, pero dudo que hayamos entendido claramente qué es ágil.

En proyectos anteriores tuvimos reuniones de planificación, luego definimos el registro de respaldo del producto y asignamos el trabajo a los desarrolladores en sprints de 2 a 3 semanas. Todas las mañanas teníamos reuniones de scrum (que parecían durar media hora cada vez) y cada desarrollador seguía con eso después de eso. Casi nadie escribió ninguna prueba hasta que al final del sprint y el trabajo que no se completó se agregó al siguiente sprint.

Los desarrolladores apenas se hablaban y no había TDD involucrado en el desarrollo. De hecho, la mayoría de los desarrolladores tenían una especificación al principio y solo la siguieron durante las 2 o 3 semanas para las que se arregló el sprint. Apenas hubo comunicación con el cliente / titular de la participación.

El control de calidad usualmente se involucró unos meses después y para entonces encontramos requisitos faltantes que aumentaron aún más la cantidad de trabajo que teníamos que hacer. Claramente no hubo un ciclo de retroalimentación.

Entonces mi pregunta es, ¿dónde nos equivocamos y cómo puedo evitar que el equipo cometa los mismos errores?

Lo que está describiendo no es Ágil por definición (Manifiesto Ágil) , es Cascada con reuniones de estado diarias. Ágil significa adaptarse fácilmente al cambio, si no hay un ciclo de retroalimentación interactivo con el propietario del producto y, por lo tanto, con los clientes, ¿qué cambio está ocurriendo?

Agile se trata de fallas rápidas, a través de una comunicación constante con el propietario / clientes del producto. Es mejor fallar más temprano que tarde, se hace menos trabajo y se "pierde" menos. Y no te quedas atascado con el argumento de que "no tenemos tiempo para hacerlo correctamente, ya que pasamos tanto tiempo haciéndolo mal, solo necesitamos continuar en este mismo camino, a pesar de que conduce al fracaso ".

Parece que tu administración está haciendo "SCRUM, pero ..." donde el "pero" es donde tiran todas las cosas de SCRUM que no entienden o con las que no están de acuerdo y simplemente hacen las cosas de la misma manera aleatoria que siempre, pero con nuevos nombres de palabras de moda brillantes para todo.

En SCRUM, la lucha diaria NO se trata de entregar el estado a la administración, es forzar la interacción del desarrollador, para que sepa lo que están haciendo los miembros de su equipo y puedan ayudarse mutuamente y no duplicar el trabajo. Si lleva más de 45 segundos por persona, lo está haciendo mal. Se trata de transparencia para el equipo, si una persona está dando el mismo estado varios días en algo que debería ser un solo día de trabajo, el equipo puede resolver el problema de las personas más temprano que tarde.

Si no está probando el código de los demás como está escrito, entonces tampoco lo está haciendo correctamente. Las pruebas deben integrarse en el proceso, no un pensamiento posterior. El control de calidad debe incluirse en las sesiones de planificación y proporcionar estimaciones sobre cuánto tiempo tomarán las cosas para probar.

Si no está cumpliendo con los compromisos de Sprint y está volcando las cosas, no lo está haciendo correctamente. Los sprints son sobre compromisos si te comprometes a hacer demasiado trabajo, deja de hacerlo, no hay forma de que puedas introducir ninguna predictibilidad o repetibilidad si no puedes comprometerte con precisión con los entregables.

Jarrod proporcionó una buena respuesta (+1 a eso) y me gustaría extender un poco más sobre eso.

Agile no se trata solo de fallas rápidas y comentarios entre el propietario del producto (cliente) y el equipo; se trata de una retroalimentación rápida entre todos los interesados ​​involucrados. Ser verdaderamente ágil (y esto es directamente del manifiesto ) es reconocer que el proceso existe solo para ayudar a los desarrolladores a entregar un mejor producto. El proceso de personas arriba significa que tan pronto como el equipo reconoce que su proceso existente no funciona, lo cambia y lo hace funcionar.

"Scrum pero ..." también es un problema, pero hay dos caras de esta moneda. Si observa el manifiesto, verá que se trata del equipo y de hacer que las herramientas / procesos funcionen para usted. No hay dos equipos iguales y, por lo tanto, cada uno operará de manera ligeramente diferente, y eso está bien. Ciertamente, podría tomar toda la metodología Scrum e intentar seguirla al pie de la letra y ver si eso funciona para su equipo.

Otra alternativa es en lugar de impulsar otro proceso en el equipo y hacer que todos sigan lo que Scrum le dice que haga, pruebe el enfoque ágil : comuníquese con el equipo y vea si juntos pueden identificar áreas problemáticas y soluciones para cada uno. Luego, introduzca gradualmente cambios en su forma de trabajar para que se aborden los problemas.

Puede llevar un poco de tiempo, pero ...

1. Primero solucionará los problemas más importantes, lo que tendrá el mayor impacto en la capacidad de sus equipos para entregar productos
2. Al identificar problemas inmediatos y participar en la búsqueda de soluciones, los miembros de su equipo comprenderán por qué ciertas prácticas son importantes y no las harán simplemente porque se les dice que las hagan.

Si dibujamos una analogía entre Scrum y un patrón de diseño, trabajar de la manera que propuse sería similar a la codificación en un patrón, donde mantiene el código lo más simple posible y solo converge en un patrón de diseño cuando es necesario. A diferencia de simplemente elegir un patrón de diseño y rodar con él (es decir, seleccionar ciegamente Scrum y todos sus procesos como un conjunto), lo que a veces hace que el código sea más complejo y difícil de mantener de lo que podría haber sido de otra manera.

La clave para entender es que ágil no se trata de crear un nuevo proceso para hacer las cosas; Se trata de un cambio continuo y un ajuste constante a los procesos / prácticas existentes.

Si el equipo (y su administración) realmente quieren "ser ágiles", deberían comenzar leyendo y discutiendo como equipo el Manifiesto Ágil y sus directores. Luego, elija una de las metodologías ágiles que se han creado ( Scrum , por ejemplo), obtenga capacitación y comience siguiendo eso. Recomiendo seguirlo bastante de cerca por un tiempo antes de modificarlo, pero solo soy yo.

También deben analizar profundamente las prácticas de ingeniería que se utilizan para apoyar la metodología de proyecto ágil particular elegida.