agile - principios - Ágil: ¿cuándo funciona bien y cuándo no?

scrum

Question

Nuestro equipo está debatiendo si queremos convertirnos en Agile o no. Ninguno de nosotros es realmente fluido en Agile. Me gustaría algunas reflexiones sobre cuándo Agile funciona bien y cuándo no.

Para dar un poco de historia, somos un pequeño grupo de desarrolladores, seis en total. Tenemos mucho más trabajo que podemos manejar. Nuestras prioridades cambian a menudo. Lo que es una alta prioridad hoy, puede que no sea mañana. Tenemos muchas aplicaciones para crear y mantener. Hemos empezado a incursionar en las prácticas ágiles en la medida en que tenemos scrums diarios y ciclos de Sprint de dos semanas.

Si necesita más información para responder a esta pregunta, no dude en preguntar.

Gracias.

Answer 1

En mi experiencia, absolutamente necesitas lo siguiente para que Agile (XP o Scrum al menos) funcione. Sin estos requisitos previos es probable que falle. Difícil.

1. El equipo debe ser estable y 100% dedicado a esto.
2. El equipo debe estar ubicado en un espacio de trabajo.
3. El cliente / propietario del producto debe estar disponible en el sitio en todo momento.
4. Apoyo de la dirección. Esto significa proporcionar fondos y coraje para garantizar los puntos anteriores.

Dale estos puntos, probablemente puedas abordar cualquier cosa siempre y cuando mantengas los values .

Answer 2

Estoy hablando solo por experiencia; YMMV.

Mi equipo no tuvo éxito en hacer un trabajo ágil. OMI, fue porque:

• La primera vez que el equipo de desarrollo escuchó sobre un proyecto, fue en forma de un documento de requisitos y una fecha límite.
• Los interesados ​​a menudo se mostraban reacios a tomarse el tiempo para ver el resultado del trabajo de un sprint, por lo que no tomarían medidas entre los sprints si pensaban que el proyecto iba en la dirección equivocada.
• Cuando mostramos a los interesados ​​nuestro trabajo, generalmente lo aprobaron. Hablarían sobre lo que les gustaría, a lo que les responderíamos "Eso se puede hacer en aproximadamente X tiempo", a lo que responderían, "Bueno, no hay necesidad de ir más allá de la fecha límite para eso".
• El proceso de implementación fue largo y complicado, desalentando las implementaciones frecuentes. Así que en la práctica, a menudo implementamos cosas cuando se realizó un proyecto de 2 meses, no al final de un sprint.
• Nuestras reuniones de planificación de sprint fueron largas e ineficientes.
• Parece que todos estaban confundidos sobre qué es scrum (y sobre cuál fue nuestro proceso), excepto por los evangelistas de scrum.

Así que estoy bastante seguro de que estábamos haciendo todo mal. No lo hagas mal, también.

Algunas cosas que nos han acelerado, que seguimos usando:

• compilaciones automatizadas que funcionan en la máquina de todos (¡ENORME ayuda!)
• Un arreglo formal para nuestro repositorio de código.
• Aprender a aplicar mecanismos de abstracción aplicados al código UI.
• refactorización
• Pruebas unitarias y de integración.
• integración continua

Supongo que se podría decir que nuestro código es más ágil, aunque nuestra metodología es menos ágil. Mientras que antes no podíamos seguir el ritmo de las demandas, ahora podemos.

(No estoy diciendo que agile sea malo; solo estoy informando sobre mi experiencia. Además, entienda que no elijo la metodología que usamos).

Answer 3

La matriz de complejidad de Ralph Stacey se usa comúnmente para ilustrar el punto dulce de Agile:

texto alternativo http://nooperation.typepad.com/.a/6a00e54ff8b9c1883400e553fdfccb8834-400wi

Para proyectos simples (donde tanto los requisitos como las tecnologías son bien conocidos), la previsibilidad es alta, por lo que una metodología predictiva (cascada) funciona bien.

Para proyectos complicados y complejos (y la gran mayoría de los proyectos de TI), la previsibilidad es baja y una metodología predictiva no funcionará, se debería preferir un enfoque adaptativo. Aquí es donde Agile funciona bien.

Cuando se desconocen tanto los requisitos como las tecnologías, estás cerca del caos y las probabilidades de fracaso son muy altas, independientemente de la metodología.

Answer 4

Parece que sus prioridades están cambiando con demasiada frecuencia para la metodología Agile o Waterfall. Dado que las prioridades cambian con frecuencia, es probable que esté entrando y saliendo de proyectos, dejando muchos de ellos parcialmente terminados. El Ágil siempre estará listo para su lanzamiento puede ayudar. Según mi experiencia, implementar una metodología mejorará la productividad.

Tu situación me recuerda a un proyecto en el que trabajé. El desarrollador del proyecto hizo una pregunta al principio: "¿Quieres que lo haga bien o que responda?" Yo estaba en el proyecto cuando tenía dos años en un proyecto de seis meses. Una semana se implementó la misma funcionalidad los lunes, miércoles y viernes. Martes y jueves se gastaron eliminando la funcionalidad.

Te sugiero que comiences a adoptar prácticas de Agile. Programar un período corto de sprint podría ayudar a cambiar las prioridades. Puede ser más fácil mantener las prioridades por un período de una semana o dos y puede facilitar la estabilización de las prioridades. También necesitará un retraso (parece que ya tiene uno grande).

La administración puede estar más dispuesta a mantener nuevas prioridades si puede ubicarlas en un sprint en una o dos semanas. También podrá identificar las compensaciones prioritarias. Si agregas algo al siguiente sprint, lo que se eliminará.

Considere tener una parte del equipo trabajando con Agile mientras que los otros mantienen el status quo. Gire un miembro del equipo cada vez que vaya ganando experiencia. Considere hacer que todo el equipo participe en una reunión diaria de estado de pie y en la revisión posterior al sprint. Una vez que haya demostrado un aumento de la productividad y los rendimientos para la empresa, debería poder aumentar la cantidad de trabajo que se está realizando utilizando su metodología.

Agile es una metodología adaptativa. Espere realizar cambios importantes en su método para el nuevo año o los dos. Eventualmente, deberías alcanzar una etapa en la que estés afinando.

Answer 5

Repostar una respuesta mía relacionada :

La discusión suele ser ágil vs. cascada, ¿verdad? Estoy enlazando un article , pero está en portugués, así que intentaré transmitir algunas de sus ideas:

La cascada es como el ajedrez. Piensas y planificas mucho, tratas de prever todos los problemas posibles lo antes posible. Hay mucha planificación, pero solo tiene sentido en dominios estables y bien conocidos, donde el cambio no es muy esperado.

Ágil es como el fútbol (o muchos deportes colectivos): las decisiones se toman en el juego y se deben hacer rápidamente. No hay mucho tiempo para analizar cada consecuencia. Es "ideal" para dominios dinámicos e inestables, donde siempre se esperan cambios (las aplicaciones web, por ejemplo, tienden a caer en esta categoría). Otro punto a tener en cuenta es: incluso si tienes los mejores jugadores, si no les va bien como equipo, no serás el ganador.

En mi humilde opinión, Scrum sería útil, porque:

• Una vez cada dos semanas (o cada mes, dependiendo del tiempo de iteración) podrá ver lo que funciona o no. Y esto es muy valioso, especialmente como equipo "amateur", que se espera que esté aprendiendo y descubriendo cosas mucho más constantemente.
• Como aficionados, es probable que no puedas prever todo (y eso es algo que abraza ágilmente)
• Hay más espacio para compartir experiencias (reuniones de pie, retrospectivas e incluso reuniones de planificación). Y compartes la experiencia REAL (debes escribir el código cada semana en lugar de solo un plan)