Desilusionado con ágil; ¿Cómo te preparas para la vida después del lanzamiento 1.1? [cerrado]

7

Mi empresa se está volviendo a todo vapor con el proceso ágil, con múltiples proyectos ágiles en funcionamiento. El primer equipo ágil, la prueba de concepto, llevó el producto hasta su lanzamiento y el primer lanzamiento de postproducción.

Después de este exitoso esfuerzo, el equipo se disolvió rápidamente y se envió para ayudar a otros proyectos en su forma ágil. Mi desilusión con Agile viene de la tercera y posterior etapa de lanzamiento del ciclo de vida del software.

Agile es bueno para atraer expertos y construir un momento, entusiasmarse con un proyecto, pero ¿cómo se puede terminar un proyecto y moverlo a una etapa en la que los clientes existentes deben estar contentos, para seguir pagando por toda esa diversión ágil temprana? Si lo desea, la fiesta ha terminado, y esta luz en la documentación, no la diseñe hasta que la necesite, y la carrera al próximo sprint deja poca documentación, poca visión y registros deficientes de por qué se tomaron las decisiones de diseño. Esta etapa de la vida también tiene poco interés en los desarrolladores ágiles iniciales, ya que han terminado con ese proyecto y están buscando nuevos equipos interesantes para comenzar.

Entiendo, y he superado la gran cantidad de problemas con la planificación a largo plazo, los horarios que faltaron y los requisitos que están desactualizados, pero por una parte que fue utilizable y aceptada por el cliente, existe información y conocimiento distribuido de por qué se tomaron decisiones, qué pasos se tomaron y algo más compatible al final.

Básicamente, ¿qué debe hacer un equipo ágil, qué debe hacer, qué se debe entregar para que un proyecto ágil tenga éxito, y el éxito se defina como un producto sostenible, sostenible y, con suerte, generador de ingresos?

Si el software ágil que construimos no se puede mantener, en un par de años ágil solo será otra promesa rota, que los gerentes de negocios no pagarán, lo que les permitirá volver al antiguo proceso de cascada de microgestión.

    
pregunta Scott S 20.08.2013 - 03:18

3 respuestas

13

Creo que lo que estás experimentando es muy similar a muchos otros equipos que primero hicieron la transición a Agile. En mi última compañía, cuando nos dijeron que fueran ágiles, sucedió casi lo mismo. Este artículo sobre Metodología ágil de culto de carga puede resonar con algunas de las cosas que probablemente haya experimentado en su pre-1.1. era. El punto es que no puede simplemente seguir las reglas / directrices escritas sin dar un paso atrás y considerar lo que es realmente importante para su equipo y su situación específica.

La clave es que la metodología Agile nunca dijo que no se puede tener documentación. Simplemente parece así porque eliminó el 90% (si no más) de la documentación en comparación con la cascada. Y eso es algo bueno, pero algunos equipos, toman "sin documentación" demasiado literalmente y van demasiado lejos, eliminando el 99.9% de la documentación. Luego se vuelven ágiles como la causa del producto no documentado.

Acabo de hacer una búsqueda en Google para encontrar este artículo sobre documentación ágil / lean y terminé encontrando otra pregunta con mi respuesta de hace un año que toca este mismo tema. La conclusión de todo lo que escribí allí es que creo que los documentos de diseño son importantes, pero para la memoria de la organización y solo cuando se mantienen en un nivel suficientemente alto. Son casi completamente inútiles cuando se escriben antes del código.

Lo mismo ocurre con la visión y la dirección a largo plazo. La metodología ágil sugirió que el diseño inicial grande es malo. Y lo que querían decir es que no intentes "esbozar" cada tuerca y tornillo de tu aplicación con palabras y luego tratar de codificar todo eso. Eso no funciona. Pero muchos equipos, incluido el mío, lo tomaron un poco demasiado literalmente y al iniciar nuevos proyectos, se lanzaron directamente a la codificación sin definir la arquitectura general o sin dar una idea general del aspecto del producto final. La conclusión es que en Agile, debe tener la documentación suficiente para que le ayude a avanzar y sea más eficiente (es decir, tenga una visión para que el equipo pueda trabajar hacia un objetivo común y no tengo que volver atrás y rehacer el trabajo) pero no crear la documentación solo para producir volumen sobre volumen de especificaciones de diseño que a) nadie leerá y b) quedará completamente obsoleto incluso antes de que se envíe el software.

En su esencia, Agile es increíblemente simple. Se trata de iteraciones cortas, eliminando el desperdicio y la mejora continua. Debe revisar constantemente lo que desperdicia su tiempo y lo hace menos eficiente y repararlo. Si el equipo ve que solo pasaron 2 semanas produciendo documentos y esos documentos no son necesarios para nadie, eso es un desperdicio. Sin embargo, si el equipo ve que las llamadas de los clientes y su propia incapacidad para comprender el código escrito se están ralentizando, entonces la falta de documentación es un desperdicio.

    
respondido por el DXM 20.08.2013 - 05:36
9

Lo que estabas haciendo no era ágil, repasemos tus puntos:

  • luz en la documentación : Agile no se trata de "no hay documentación". Se trata de crear código que no necesita documentación y solo crear documentación que sea necesaria.
  • no lo diseñes hasta que lo necesites : en ágil, esto no significa nada. El hecho de que esté diseñando más tarde, no significa que no esté diseñando en absoluto.
  • sigue compitiendo hasta el próximo sprint : Agile no se trata de correr hacia el próximo sprint. El principal punto de agile es crear un ritmo de desarrollo estable y sostenible. Así que no importa qué tan grande o complejo sea el software, el equipo puede agregar nuevas funciones y mejorar la calidad al mismo ritmo que hace un año.
  • deja poca documentación : una vez más, ágil se trata de que el equipo decida qué documentación necesita para su trabajo. El principal problema con otras metodologías es que es otra persona la que decide qué documentos se necesitan, por lo tanto, con bastante frecuencia los documentos presentan más problemas de los que resuelven.
  • pequeña visión - Lo que está mal. Los desarrolladores en sí no necesitan realmente una visión a largo plazo. Pero, al menos, el propietario del producto debería mirar hacia el futuro un año o dos e imaginar qué tipo de software desean. No hay necesidad de cargar a los desarrolladores con tantos "qué pasa si".
  • registros deficientes de por qué se tomaron las decisiones de diseño : en ágil, estos registros existen en código, se crearon la memoria del desarrollador y el equipo de documentos, porque la decisión fue tan compleja que el equipo decidió grabarlo.

Entonces, para responder a tu pregunta: no puedes desilusionarte con ágil, cuando nunca lo hiciste ágil.

    
respondido por el Euphoric 20.08.2013 - 07:38
6

La desilusión viene de tener ilusiones :-)

Mi opinión (que usa anteojos Scrum) sobre estos problemas es que son

  1. Principalmente causado por una "definición de hecho" deficiente. Si un sprint posterior necesita limpiarse después del sprint actual, entonces para mí eso dice que el sprint no terminó su trabajo.

  2. Contribuyó a dividir un equipo exitoso. Este es uno de los métodos clásicos para rellenar un producto.

Para mí, una característica clave de ágile es mantener un ritmo sostenible. Esto viene de conocer la velocidad del equipo, lo que pueden lograr en cada sprint. Grandes cambios en el equipo significan grandes cambios en la confiabilidad de la velocidad del pasado como un predictor del futuro. Ese ritmo sostenible incluye el mantenimiento, y también implica que no hay un recorte repentino.

Los equipos evolucionarán, por supuesto, a medida que las personas vayan y vengan, y los requisitos de habilidades cambien. Pero disolver a todo el equipo me hace estremecer.

    
respondido por el andy256 20.08.2013 - 03:40

Lea otras preguntas en las etiquetas