Ágil: ¿Cuándo funciona bien y cuándo no?

Question

Nuestro equipo está debatiendo si queremos convertirnos en Agile o no. Ninguno de nosotros habla fluidamente Ágil. Me gustaría tener algunas ideas sobre cuándo Agile funciona bien y cuándo no.

Para dar un poco de antecedentes, 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 no ser mañana. Tenemos muchas aplicaciones para crear y mantener. Hemos empezado a incursionar en 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 esto, no dude en preguntar.

Gracias.

Answer 1

matriz de la complejidad de Ralph Stacey es comúnmente utilizado para ilustrar el punto dulce para Agile:

alt text http://nooperation.typepad.com/.a/6a00e54ff8b9c1883400e553fdfccb8834-400wi

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

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

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

Answer 2

Parece que sus prioridades cambian con demasiada frecuencia para la metodología Agile o Waterfall. Con las prioridades cambiando con frecuencia, es probable que se mueva dentro y fuera de los proyectos, dejando a muchos de ellos en parte. El ágil siempre está listo para liberar puede ayudar. Según mi experiencia, la implementación de una metodología mejorará la productividad.

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

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

La administración puede estar más dispuesta a contener las nuevas prioridades si puede ponerlas en un sprint en una semana o dos. También podrá identificar las compensaciones de prioridad. Si agrega algo al próximo sprint, lo que se eliminará.

Considere tener una parte del equipo que trabaje Agile mientras que los demás mantienen el status quo. Gira a un miembro del equipo en cada carrera mientras adquieres experiencia. Considere la posibilidad de 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 una mayor productividad y rentabilidad para la empresa, podrá aumentar la cantidad de trabajo que se realiza con su metodología.

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

Answer 3

Traspaso de un related answer mío:

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

Waterfall is like ajss. Piensa y planifica mucho, trata de prever todos los problemas posibles lo antes posible. Hay mucha planificación, pero solo tiene sentido en dominios estables y bien conocidos, donde no se espera mucho cambio.

Agile 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 espera un cambio (las aplicaciones web, por ejemplo, tienden a caer en esta categoría). Otro punto a tener en cuenta es que, incluso si tienes los mejores jugadores, si no lo hacen 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ás ver lo que está funcionando o no. Y esto es muy valioso, especialmente como un equipo "aficionado", que se espera que aprenda y descubra cosas mucho más constantemente.
• Como amateurs, probablemente no podrá prever todo (y eso es algo que abarca ágilmente)
• Hay más espacio para compartir experiencias (reunión stand-up, retrospectiva e incluso planificación de reuniones). Y usted comparte experiencia REAL (debe escribir código todas las semanas en lugar de solo planificar)

Answer 4

En mi experiencia, absolutamente necesita lo siguiente para que sea ágil (XP o Scrum al menos) para funcionar. Sin estos prerrequisitos 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 área de trabajo.
3. El cliente/el propietario del producto debe estar disponible en el sitio en todo momento.
4. Asistencia de la administración. Esto significa proporcionar fondos y valentía para garantizar los puntos anteriores.

Proporcione estos puntos, probablemente pueda abordar cualquier cosa siempre que se mantenga en el values.

Answer 5

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 oiría sobre un proyecto, que fue en la forma de un documento de requisitos y una fecha límite.
• Los participantes a menudo se mostraban reacios a para 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 incorrecta.
• Cuando mostramos a las partes interesadas nuestro trabajo, , generalmente lo aprobaron.Ellos sería hablar sobre lo que les como, a la que respondían "Eso se puede hacer en aproximadamente una cantidad X de tiempo", a los que respondían, "Bueno hay necesidad de ir sobre la fecha límite para ese "
• El proceso de implementación fue largo y complicado, lo que desaconseja las implementaciones frecuentes de . Entonces, en la práctica, a menudo implementamos cosas cuando se realizó un proyecto de 2 meses , no al final de un sprint de .
• Nuestras reuniones de planificación de sprint fueron largas e ineficientes.
• Parece que todo el mundo estaba confundido sobre qué es el scrum (y sobre cuál fue nuestro proceso), a excepción de los evangelistas del scrum.

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

Algunas cosas que han nos acelerado, que seguimos utilizando:

• automatizado construye que el trabajo en la máquina de todos
• un acuerdo formal para nuestro repositorio de código (ayuda enorme!)
• aprender cómo aplicar aplica mecanismos de abstracción de código de interfaz de usuario
• refactorización
• unidad e integración pruebas
• de 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 es malo ágil, yo sólo estoy informar también mi experiencia, por favor, comprenda que no elijo lo que la metodología que utilizamos..)