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

Question

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

fin estoy en una posición donde pudiera rodar algo como esto a cabo donde trabajo, pero tengo serias dudas acerca de que es el camino a seguir para nosotros:

• No hay un mínimo ¿para esto? Gran diseño en la delantera debe ser más eficiente para un proyecto de tres o cuatro semanas ... ¿verdad?
• 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 y, aun así, las personas se sienten más cómodas con un límite. Entonces, ¿cómo puede proporcionar un presupuesto si va con un proceso que es tolerante a los cambios de requisitos en curso?
• Entiendo que Agile puede ofrecer mejores probabilidades de éxito en proyectos más complejos, pero ¿no aumentará los costos para el cliente? Y, por supuesto, está el costo de no tener en cuenta, quizás volvamos a la pregunta sobre el tamaño mínimo aquí.
• ¿Cómo podría explicar este enfoque contraintuitivo a los clientes? Las partes interesadas no tecnológicas podrían no tener la experiencia para entender nada más allá de Waterfall.
• Incluso para proyectos internos, hay presupuestos. ¿Qué me estoy perdiendo?
• Parece que hay alguna reacción violenta contra Agile últimamente. ¿Algo más va a comenzar a ganar tracción pronto?

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

¡Muchas gracias!

Brian MacKay

Answer 1

No creo que una metodología pueda descartarlos a todos. Lo siento. Creo firmemente en encontrar el modelo correcto para el proyecto correcto. Por ejemplo, cómo se sentiría si estuviera en cirugía y supiera que la máquina que lo mantuvo vivo 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 en los enfoques ágiles, de mantener sus iteraciones cortas, enfocándome en lo que el usuario quiere, y no construyendo el acorazado sino construyendo exactamente lo que necesita. Yo 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 en cuanto a BDUF (Big Design up Front), tuvimos un gran éxito con un equipo de 20 personas en un proyecto de 4 meses, tomamos el proyecto dividiéndolo en 3 ciclos de cuatro semanas, al comienzo de cada ciclo todos nos reunimos en una sala, y dijimos que bien, esto es lo que tenemos que construir, así es como lo construiremos, y analizamos cómo serían nuestras interfaces, qué datos necesitábamos, etc. ... Pero solo era un apuñalamos, luego volvimos a nuestros escritorios, y quienquiera que sea el dueño de las diversas piezas se deshizo de los detalles.

Esencialmente hicimos suficiente BDUF por adelantado para reactivar el equipo (y asegurarnos de que cubrimos todos los requisitos del negocio). Solíamos llamar a estas sesiones Developer Days y era una buena forma de reactivar el equipo. Si tiene dinero en efectivo, saque al equipo fuera del sitio y llénelo en una sala de conferencias en un hotel, aliméntelo con un montón de basura y observe cómo fluyen los jugos.

Answer 2

Depende de a quién le pregunte, y si creen en ágiles o no ...

En cuanto a esto:

Me gustaría encontrar una metodología para gobernar el centro comercial.

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

Son todos sus clientes el mismo? Ya dijiste que las duraciones varían enormemente ... ¿Por qué supones que todo tipo de proyectos diferentes se adecuarían a una única metodología?

Answer 3

Busca lo que hace que la práctica Agile falle ... Si tienes 1-2 puntos menores, hazlo, encontrarás 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 4

Comience con proyectos internos para obtener un poco de experiencia sobre cómo funciona su proceso ágil y cómo puede estimar mejor cuánto tiempo tomará. Cuando sienta que está listo para enfrentarse a un cliente real, elija uno con el que tenga mucha confianza y elija un proyecto razonablemente pequeño para empezar. La clave aquí es que quieres generar confianza. Explique qué está haciendo y por qué desea proporcionarles un mejor software que refleje mejor sus prioridades antes y muéstreles cómo ha tenido éxito en sus proyectos internos. Cumple con tus promesas, ya que creo en métodos ágiles, no creo que esto sea demasiado difícil de hacer.

Una vez que haya tenido éxito (y haya impresionado al cliente), le pedirán que use el método en sus otros proyectos. Una vez que tiene 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 también se arrastran hacia sus procesos de "cascada". Eventualmente, habrás bebido suficiente kool-aid para ser como el resto de nosotros los 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 avanzados que lo que permite ágil. La mayoría de nosotros no trabajamos en estos proyectos.

Answer 5

Si no puede obtener la compra de las partes interesadas; si su organización requiere alguna otra metodología y los desarrolladores se evalúan por técnica en lugar de éxito; si no hay suficiente tiempo o dinero; entonces no es apropiado.

La pregunta sería, ¿qué otra metodología haría mejor en esas circunstancias.

Answer 6

la solución simple tiene 2 etapas:

1. no estimar los costos y horarios para proyectos, estimar los costos y horarios para características
2. medir y registrar suficiente información para calcular su velocidad y de estimación de errores

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

Nota: esto sólo funcionará si el cliente se ha comprometido a hacer su parte, a saber, que es altamente disponible para los desarrolladores (para responder a preguntas, escribir historias y descripciones de las pruebas, y otros), y para no cambiar su opinión durante una iteración

¡buena suerte con su transición y háganos saber cómo va!

Answer 7

Con mucho, la mayor contraindicación que he visto es una discrepancia de valores. Extreme Programming 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 dará lugar a ningún cambio duradero (IME).

Answer 8

Scott Ambler es una buena autoridad para an answer en esto. Su artículo hace un buen trabajo destacando algunas de las trampas del precio fijo, pero definitivamente es posible. Alistair Cockburn agrees también es posible, pero señala que algunos de los beneficios que obtiene de ágil se pierden en los contratos de precio fijo.

Un problema básico con el "diseño grande por adelantado" (BDUF) es el tiempo dedicado al diseño de la funcionalidad que rara vez, o nunca, se utiliza. Si necesita tener un producto terminado en un mes o menos, el problema debe estar realmente bien definido de antemano.

En cuanto al costo de la falla, es una preocupación muy legítima. Uno de los beneficios de Agile es que cualquier falla ocurre antes y a un costo mucho menor de lo que serí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 de cascada puede ofrecer. El gobierno federal tiene un buen número de fallas de alto perfil de proyectos de software que siguieron la metodología de cascada y BDUF. Tengo blogged sobre el fracaso del proyecto FBI Virtual File File.

Las metodologías que utilice se determinarán tanto por el tamaño de su equipo como por el tipo de software que esté creando y sus clientes. tvanfosson tiene 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 preparadas para Agile desde una perspectiva cultural, independientemente de sus méritos y éxito en otros lugares.

Answer 9

Permítanme responder a sus preocupaciones, punto por punto:

¿No hay un tamaño mínimo para esto? El diseño grande al frente debe ser más eficiente para un proyecto de tres o cuatro semanas ... ¿No?

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

De todos modos, incluso si lo fuera, la cuestión de si BDUF paga sería mucho más una función de la cantidad de aprendizaje que 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 perderá el 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 precios fijos .Necesitan saber qué están tratando con , excepto en los casos especiales donde nos enfrentamos a un obvio agujero negro e incluso entonces las personas son más cómodas con una gorra. Entonces, ¿cómo puede proporcionar si está yendo con un proceso que es tolerante de cambios de requisitos en curso?

Solo acepta cambios de requisitos que no cambian el esfuerzo total. Es decir, cuando ingresan nuevos requisitos, elimine los menos importantes. Deje que el cliente decida para que pueda sacar el máximo provecho del dinero.

No obtendrá todos los beneficios de Agile de esta manera, pero es tan bueno como el precio fijo puede obtener, por lo que puedo ver.

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

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

Y, por supuesto, existe el costo de no tener en cuenta, tal vez volvamos a la pregunta sobre el tamaño mínimo aquí.

El costo de la falla disminuye con un proyecto Ágil, debido a los comentarios anteriores. Puede notar el fallo, y por lo tanto, decide cancelar el proyecto, mucho antes.

¿Cómo podría explicar este enfoque contraintuitivo a los clientes? Las partes interesadas no tecnológicas podrían no tener la experiencia para entender nada más allá de Waterfall.

Why does Agile Software Development pay?

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

No lo sé. Agile funciona bien con presupuestos: implemente las características de mayor prioridad hasta que se agote el presupuesto. Usted tiene el sistema más valioso que podría haberse implementado para ese dinero.

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

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

Lean Software Development está ganando mucha tracción. No está en competencia con el desarrollo ágil, sino más bien complementario. Las comunidades en realidad se solapan bastante.

En cuanto a la "única metodología para controlarlos a todos", eche un vistazo a la familia de procesos ágiles "Crystal" de Alistair Cockburn. Él argumenta (con bastante competencia) que cada proyecto necesita su propio proceso, y que incluso el proceso de un proyecto necesita cambiar a lo largo del proyecto.Y él proporciona un marco liviano para desarrollar su proceso.

Al igual que Scrum, como yo lo pienso. En realidad, Scrum no le dice mucho sobre cómo ejecutar su proyecto, sino mucho más sobre cómo saber qué está funcionando y cómo capacitar al equipo para adaptarse a esos hallazgos.

Answer 10

Sugeriría en contra de Agile al desarrollar un nuevo sistema de control de tráfico aéreo.

Answer 11

No usaría necesariamente ágil para un proyecto donde todo se conoce desde el principio. Agile funciona bien cuando el cambio es altamente probable. En el caso de que el cambio no sea probable, se puede usar el proceso predictivo o en cascada para administrar dicho proyecto.

Responde a tus preguntas particulares a continuación: ¿No hay un tamaño mínimo para esto? Desde una perspectiva práctica, Agile es independiente del tamaño. Una vez dicho esto, cuanto más grande sea un proyecto, más probable será el cambio. Si un proyecto es pequeño, entonces todo es cognoscible y el cambio es poco probable.

El diseño frontal grande 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. Debería tener suficiente arquitectura en el frente para saber dónde caen las piezas principales. No utilice la arquitectura para adivinar lo que va a hacer, solo capture lo que es cognoscible. Deje 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 fijo. Necesitan saber a qué se enfrentan, excepto en casos especiales en los que nos enfrentamos a un agujero negro obvio y, aun así, las personas se sienten más cómodas con un límite. Entonces, ¿cómo puede proporcionar un presupuesto si va con un proceso que es tolerante a los cambios de requisitos en curso? Se requiere un poco de educación inicialmente. Usted establecería una cartera de pedidos de productos, le pedirá al propietario del producto que le dé prioridad y luego realizará una estimación inicial del trabajo. Esto requiere que el propietario del producto establezca una línea de corte en la acumulación de la oferta fija. Luego, dimensione el equipo y la duración para cumplir con el cálculo. El contrato luego establece que usará la capacidad fija del equipo para el horario establecido. Esto mantendrá al propietario del producto enfocado en el calendario y el presupuesto al realizar llamadas prioritarias en la cartera de pedidos.

Entiendo que Agile puede ofrecer 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 se explicaría este enfoque contraintuitivo para los clientes? Las partes interesadas no tecnológicas podrían no tener la experiencia para entender nada más allá de Waterfall. La educación (es decir, el campo de entrenamiento ágil) y la visita de equipos ágiles exitosos te ayudarán tremendamente. Entonces, haz que el equipo funcione. El trabajo los mantendrá ocupados y los resultados los venderán.

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

Answer 12

En mi humilde opinión:

ágil o no, debe diseñar lo que se conoce antes de implementar - antes de "tratando cosas". Recursivamente divida las cosas en tareas manejables, luego diseñe lo que se conoce, ya sea detalles minúsculos o simplemente conceptos amplios. Cosas como la IU y los requisitos de negocios diarios casi nunca se establecen en piedra antes del desarrollo, mientras que las características de simulación de aeronaves pueden serlo.

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