¿Cuáles son algunas situaciones en las que Agile es inapropiado? [cerrado]

Question

He estado escuchando y leyendo sobre Agile durante años. Tengo uno o dos libros y me gusta la idea.

Finalmente estoy en una posición en la que podría implementar algo como esto donde trabajo, pero tengo serias preocupaciones sobre si es el camino a seguir para nosotros:

• ¿No hay un tamaño mínimo para esto? Gran diseño por adelantado debe ser más eficiente para un proyecto de tres o cuatro semanas ... ¿No?
• Nuestros clientes generalmente requieren precios fijos. Necesitan saber a qué se enfrentan, excepto en casos especiales en los que nos enfrentamos a un agujero negro obvio e incluso entonces las personas se sienten más cómodas con una gorra. Entonces, ¿cómo puede proporcionar una cotización si va con un proceso que es tolerante a los cambios en los requisitos en curso?
• Entiendo que Agile puede proporcionar mejores probabilidades de éxito en proyectos más complejos, pero ¿no aumentará los costos para el cliente? Y, por supuesto, existe el costo de no tener en cuenta: tal vez volvemos a la pregunta de tamaño mínimo aquí.
• ¿Cómo podría explicar este enfoque contraintuitivo a los clientes? Es posible que las partes interesadas no técnicas no tengan la experiencia necesaria para comprender algo más allá de Waterfall.
• Incluso para proyectos internos, hay presupuestos. ¿Qué me estoy perdiendo?
• Parece que últimamente hay una reacción violenta contra Agile. ¿Algo más va a comenzar a ganar fuerza pronto?

Nota: Somos una tienda de 5 desarrolladores con proyectos que van desde un día o dos hasta varios meses. No creo que haya una metodología para gobernarlos a todos, pero sería genial encontrar algo lo suficientemente flexible como para que podamos adaptarlo a todos nuestros proyectos.

¡Muchas gracias!

Brian MacKay

Answer 1

No creo que una metodología pueda gobernarlos a todos. Lo siento. Creo firmemente en encontrar el modelo correcto para el proyecto correcto. Por ejemplo, ¿cómo te sentirías si estuvieras en cirugía y supieras que la máquina que te mantiene con vida se desarrolló en un ciclo iterativo rápido con poco diseño por adelantado?

Pero de todos modos, a su pregunta. Soy un gran creyente de los enfoques ágiles, de mantener sus iteraciones cortas, enfocarme en lo que el usuario quiere y no construir el acorazado, sino solo construir exactamente lo que necesita. Diría que el 95% de todos los proyectos podrían usar enfoques ágiles, y si no pueden, generalmente es un problema cultural, no un problema de proyecto.

Ahora, hasta BDUF (Big Design up Front), tuvimos un gran éxito con un equipo de 20 personas en un proyecto de 4 meses, tomamos el proyecto dividido en 3 ciclos de cuatro semanas, al comienzo de cada ciclo. todos se reunieron en una habitación y dijeron: vale, esto es lo que necesitamos construir, así es como lo construiremos, y analizamos cómo se verían nuestras interfaces, qué datos necesitábamos, etc. Pero fue solo una puñalada. , luego volvimos a nuestros escritorios, y quienquiera que fuera el propietario de las diversas piezas eliminó los detalles.

Esencialmente, hicimos suficiente BDUF por adelantado para impulsar el equipo (y asegurarnos de que cubrimos todos los requisitos comerciales). Solíamos llamar a estas sesiones Días de desarrollador y fue una buena manera de impulsar el equipo. Si tiene dinero en efectivo, lleve al equipo fuera del sitio, puede meterlos en una sala de conferencias en un hotel, alimentarlos con mucha basura y ver cómo fluyen los jugos.

Answer 2

la solución simple tiene 2 pasos:

1. no calcule costos y cronogramas para proyectos, calcule costos y cronogramas para características
2. mide y registra suficiente información para calcular tus errores de velocidad y estimación

comience pequeño y de forma interna si es posible para obtener algunos números base. Si aún desea hacer un "diseño inicial grande", hágalo para funciones individuales. Esto ayudará a que sus estimaciones iniciales sean más precisas, y también con la granularidad de 'característica' con la que se siente cómodo.

Nota: esto solo funcionará si el cliente se compromete a hacer su parte , es decir, estar altamente disponible para los desarrolladores (para responder preguntas, escribir historias y descripciones de pruebas, etc.), y para no cambiar de opinión durante una iteración

¡buena suerte con tu transición y cuéntanos cómo te va!

Answer 3

Con mucho, la mayor contraindicación que he visto es una falta de coincidencia de valores. La programación extrema se basa en el respeto, la comunicación, la retroalimentación, el coraje y la simplicidad. En una organización que se comporta en base a valores incompatibles, la aplicación de XP causará fricción y no generará ningún cambio duradero (IME).

Answer 4

Depende de a quién le preguntes y si creen en ágil o no ...

En cuanto a esto:

  

Me gustaría encontrar una metodología para gobernarlos a todos.

http://www.opaquelucidity.com/facepalm.jpg

¿Todos sus clientes son iguales? Ya has dicho que las duraciones varían enormemente ... ¿Por qué supones que toda clase de proyectos diferentes serían adecuados para una sola metodología?

Answer 5

Busca lo que hace que la práctica ágil falle ... Si tienes 1-2 puntos menores, busca la forma de superarlos. De lo contrario, estás buscando un fracaso. Y una vez que fallaste, no tendrás otra oportunidad para probarlo. Incluso si no es la práctica ágil que falló ...

Answer 6

Comience con proyectos internos para obtener experiencia sobre cómo funciona su proceso ágil y cómo puede estimar mejor cuánto tiempo tomarán las cosas. Cuando sienta que está listo para asumir un cliente real, elija uno en el que tenga mucha confianza y elija un proyecto razonablemente pequeño para comenzar. La clave aquí es que desea generar confianza. Explique qué está haciendo y por qué (si desea proporcionarles un mejor software que refleje mejor sus prioridades antes) y muéstreles cómo ha tenido éxito en sus proyectos internos. Cumpla sus promesas: como creo en los métodos ágiles, no creo que sea demasiado difícil de hacer.

Una vez que tenga éxito (y sorprenda al cliente), le pedirán que use el método en sus otros proyectos. Una vez que tenga un cliente satisfecho, puede comenzar a expandirse a otros, utilizando a su primer cliente como referencia. Muy pronto descubrirá que las prácticas que está utilizando funcionan tan bien que se infiltran en su "cascada". procesos también. Eventualmente, habrás bebido suficiente kool-aid para ser como el resto de nosotros, agilistas. :-)

Oh. Y sí, hay proyectos que no son particularmente susceptibles a los métodos ágiles. Cosas como los sistemas críticos para la vida, el control de plantas de energía nuclear, las industrias altamente reguladas pueden requerir un diseño y un proceso más avanzado de lo que permite Agile. La mayoría de nosotros nunca trabajamos en estos proyectos.

Answer 7

Scott Ambler es una buena autoridad para una respuesta sobre esto. Su artículo hace un buen trabajo al destacar algunas de las trampas del precio fijo, pero definitivamente es posible. Alistair Cockburn está de acuerdo también es posible, pero señala que algunos de los beneficios que obtiene de Agile son perdido en contratos de precio fijo.

Un problema básico con "diseño grande por adelantado" (BDUF) es el tiempo dedicado a diseñar funcionalidades que rara vez, si es que alguna vez, se utilizan. Si necesita tener un producto terminado en un mes o menos, el problema debe estar realmente bien definido de antemano.

En cuanto al costo del fracaso, esa es una preocupación muy legítima. Un beneficio de Agile es que cualquier falla ocurre antes y a un costo mucho menor de lo que ocurriría en un proyecto siguiendo la metodología de cascada. Ser capaz de aprender de esas fallas y obtener un buen producto al final no es un resultado que la metodología en cascada pueda ofrecer. El gobierno federal tiene una buena cantidad de fallas de alto perfil en proyectos de software que siguieron la metodología de cascada y BDUF. blogueó sobre el Caso virtual del FBI Error de proyecto de archivo.

Las metodologías que use dependerán tanto del ajuste con su equipo como del tipo de software que esté creando y sus clientes. tvanfosson tiene bastante razón sobre los proyectos que no son adecuados para los métodos ágiles. Estoy de acuerdo con Kent Beck en la idea de desajuste de valores. Algunas organizaciones no están listas para Agile desde una perspectiva cultural, independientemente de sus méritos y éxito en otros lugares.

Answer 8

Permítame responder a sus inquietudes punto por punto:

  

¿No hay un tamaño mínimo para esto?   Gran diseño por adelantado debe ser más   eficiente por tres o cuatro semanas   proyecto ... ¿verdad?

No estoy seguro de qué te hace pensar que dibujar rectángulos en papel debe ser más rápido que refactorizar el código.

De todos modos, incluso si fuera así, la cuestión de si BDUF paga sería mucho más una función de cuánto aprendizaje espera durante el proyecto que del tamaño del proyecto. Cuanto más espere aprender algo sobre el diseño, los requisitos, etc. mientras implementa el sistema, más se desperdiciará su diseño inicial.

Todavía tengo que encontrar un proyecto en el que no aprendí cosas importantes al implementar el sistema.

  

Nuestros clientes generalmente requieren arreglos fijos   precios. Necesitan saber lo que son   tratar, excepto en casos especiales   donde nos enfrentamos a un obvio   agujero negro e incluso entonces las personas son   Más cómodo con una gorra. Así que cómo   puedes proporcionar una cotización si eres   ir con un proceso tolerante   de cambios continuos en los requisitos?

Solo acepte cambios de requisitos que no cambien el esfuerzo total. Es decir, cuando entran nuevos requisitos, elimine los menos importantes. Deje que el cliente decida para que pueda aprovechar al máximo el dinero.

No obtendrá todos los beneficios de Agile de esta manera, pero es lo mejor que puede obtener el precio fijo, por lo que puedo decir.

  

Entiendo que Agile puede proporcionar mejores probabilidades de éxito en proyectos más complejos, pero ¿no aumentará los costos para el cliente?

¿Está sugiriendo que los proyectos ejecutados de manera ágil son más costosos que los proyectos tradicionales? En realidad, existen empresas que experimentaron lo contrario, hasta una reducción de costos del 50%.

  

Y, por supuesto, existe el costo de no considerarlo; quizás volvamos a la pregunta de tamaño mínimo aquí.

El costo de la falla disminuye con un proyecto Agile, debido a los comentarios iniciales. Puede notar un error y, por lo tanto, decidir cancelar el proyecto, mucho antes.

  

¿Cómo podría explicar este enfoque contraintuitivo a los clientes? Es posible que las partes interesadas no técnicas no tengan la experiencia necesaria para comprender algo más allá de Waterfall.

¿Por qué paga Agile Software Development?

  

Incluso para proyectos internos, hay presupuestos. ¿Qué me estoy perdiendo?

No lo sé. Agile funciona bien con los presupuestos: implemente las funciones de mayor prioridad hasta que se agote el presupuesto. Tiene el sistema más valioso que podría haberse implementado por ese dinero.

  

Parece que últimamente hay una reacción violenta contra Agile. ¿Algo más va a comenzar a ganar tracción pronto?

Ha habido una reacción violenta contra ella desde el principio. Y a medida que se está volviendo más popular (¡y lo es!), Es natural que también veas más reacciones violentas.

Lean Software Development está ganando mucha tracción. Sin embargo, no compite con el desarrollo ágil, sino más bien complementario. Las comunidades en realidad se superponen bastante.

Con respecto a la metodología de "uno para gobernarlos a todos" - Echa un vistazo a "Crystal" de Alistair Cockburn familia de procesos ágiles. Él argumenta (de manera bastante competente) que cada proyecto necesita su propio proceso, y que incluso el proceso de un proyecto debe cambiar en el transcurso del proyecto. Y proporciona un marco ligero para desarrollar su proceso.

Al igual que Scrum, según lo pienso. Scrum en realidad no le dice mucho sobre cómo ejecutar su proyecto, pero mucho más sobre cómo averiguar qué está funcionando y

Answer 9

No necesariamente usaría agile para un proyecto donde todo se conoce por adelantado. Ágil funciona bien cuando el cambio es muy probable. En el caso de que el cambio no sea probable, se puede utilizar el proceso predictivo o en cascada para gestionar dicho proyecto.

Las respuestas a sus preguntas particulares son las siguientes: ¿No hay un tamaño mínimo para esto? Desde una perspectiva práctica, Agile es independiente del tamaño. Dicho esto, cuanto más grande sea un proyecto, más probable será el cambio. Si un proyecto es pequeño, entonces todo es conocible y el cambio es poco probable.

El diseño grande por adelantado debe ser más eficiente para un proyecto de tres o cuatro semanas ... ¿Verdad? El diseño simple y evolutivo impulsado por TDD siempre es más efectivo. Debe tener suficiente arquitectura hecha por adelantado para saber dónde caen las piezas principales. No use la arquitectura para adivinar lo que va a hacer, solo capture lo que se puede conocer. Permita que el diseño simple y evolutivo le permita evolucionar su diseño detallado a medida que crea la aplicación.

Nuestros clientes generalmente requieren precios fijos. Necesitan saber a qué se enfrentan, excepto en casos especiales en los que nos enfrentamos a un agujero negro obvio e incluso entonces las personas se sienten más cómodas con una gorra. Entonces, ¿cómo puede proporcionar una cotización si va con un proceso que es tolerante a los cambios en los requisitos en curso? Se requiere algo de educación inicialmente. Debería establecer una cartera de productos, pedirle al propietario del producto que le dé prioridad y luego hacer una estimación inicial del trabajo. Esto requiere que el propietario del producto establezca una línea de corte en la cartera de pedidos para la oferta fija. Luego, mide el equipo y la duración para cumplir con la estimación. El contrato establece que utilizará la capacidad fija del equipo durante el tiempo establecido. Esto mantendrá al propietario del producto centrado en el tiempo y el presupuesto al hacer llamadas prioritarias en la cartera de pedidos.

Entiendo que Agile puede proporcionar mejores probabilidades de éxito en proyectos más complejos, pero ¿no aumentará los costos para el cliente? Un proyecto exitoso siempre es más barato que uno fallido.

¿Cómo explicaría este enfoque contraintuitivo a los clientes? Es posible que las partes interesadas no técnicas no tengan la experiencia necesaria para comprender algo más allá de Waterfall. La educación (es decir, el campo de entrenamiento ágil) y la visita a equipos ágiles exitosos ayudarán enormemente. Entonces pon en marcha al equipo. El trabajo los mantendrá ocupados y los resultados los venderán.

Incluso para proyectos internos, hay presupuestos. ¿Qué me estoy perdiendo? Parece que últimamente hay una reacción violenta contra Agile. ¿Algo más va a comenzar a ganar tracción pronto? La única reacción violenta que conozco son los proyectos ágiles que no utilizan prácticas de ingeniería de manera efectiva (es decir, SCRUM solamente). Un equipo que use SCRUM y XP effectivley lo hará muy bien en la entrega y el ritmo sostenible.

Answer 10

Sugeriría contra Agile cuando desarrolle un nuevo sistema de control de tráfico aéreo.

Answer 11

Imho:

Ágil o no, debe diseñar lo que se conoce antes de implementar, antes de "probar cosas". Divide las cosas de forma recursiva en tareas manejables, luego diseña lo que se conoce, ya sea detalles esenciales o simplemente conceptos amplios. Cosas como la interfaz de usuario y los requisitos comerciales de todos los días casi nunca se establecen en piedra antes del desarrollo, mientras que las características de simulación de aviones pueden serlo.

Una forma de tratar de "vender" ágil para los clientes es otorgarles dos opciones: 1. Cascada, donde no hay cancelación siempre y cuando nosotros (los desarrolladores) cumplamos con nuestro fin del acuerdo. 2. Ágil, donde obtiene actualizaciones semanales sobre el estado, demostraciones prácticas a medida que estén disponibles y el derecho de suspender el servicio cada 2 semanas (en caso de que no le guste nuestro trabajo).