metodología - ¿Cuáles son algunas situaciones en las que Agile es inapropiado?
que es agile methodology (12)
He estado escuchando y leyendo sobre Agile durante años. Tengo un libro o dos y me gusta la idea.
Finalmente estoy en una posición en la que podría hacer rodar algo así en mi trabajo, pero tengo serias dudas sobre si es la mejor opción para nosotros:
- ¿No hay un tamaño mínimo para esto? El diseño grande por adelantado 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 explicarías 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 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
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.
Las respuestas a sus preguntas particulares siguen: ¿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 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. 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 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? 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 es siempre más barato que uno fallido.
¿Cómo explicarías 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. 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 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 las 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.
Busca lo que hace fallar la práctica Ágil ... Si tienes 1-2 puntos menores apúntate, 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ó ...
Comience con proyectos internos para obtener alguna experiencia sobre cómo funciona su proceso ágil y cómo puede estimar mejor cuánto tiempo llevará. 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 le 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.
Con mucho, la mayor contraindicación que he visto es un desajuste 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, aplicar XP causará fricción y no dará lugar a ningún cambio duradero (IME).
Depende de a quién le pregunte y si cree 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
¿Son todos tus clientes iguales? 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?
Scott Ambler es una buena autoridad para una respuesta sobre esto. Su artículo hace un buen trabajo destacando algunas de las trampas del precio fijo, pero definitivamente es posible. Alistair Cockburn está de acuerdo en que también es posible, pero señala que algunos de los beneficios que obtienes de ágil se pierden en los contratos de precio fijo.
Un problema básico con "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 del fracaso, esa 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. He escrito sobre el fracaso del proyecto FBI Virtual File File.
Las metodologías que use se determinarán tanto por el ajuste con 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.
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 bajo esas circunstancias?
la solución simple tiene 2 pasos:
- no calcule los costos y horarios de los proyectos, estimar los costos y los horarios de las funciones
- medir y registrar suficiente información para calcular su velocidad y errores de estimación
comience de a poco y dentro de la empresa 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 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 probar descripciones, etc.), y para no cambiar de opinión durante una iteración.
¡buena suerte con su transición, y háganos saber cómo va!
Permítanme responder sus inquietudes punto por punto:
¿No hay un tamaño mínimo para esto? El diseño grande por adelantado debe ser más eficiente para un proyecto de tres o cuatro semanas ... ¿Verdad?
No estoy seguro de qué le hace pensar 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 cuánto aprendizaje esperas 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 mientras implementaba el sistema.
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?
Solo acepte cambios de requisitos que no cambien el esfuerzo total. Es decir, cuando ingresen 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 puede obtener el precio fijo, hasta donde yo sé.
Entiendo que Agile puede ofrecer mejores probabilidades de éxito en proyectos más complejos, pero ¿no aumentará los costos para el cliente?
¿Sugiere que los proyectos que se ejecutan de forma á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, está el costo de no tener en cuenta, quizás 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 iniciales. Puede notar el fallo, y por lo tanto, decide cancelar el proyecto, mucho antes.
¿Cómo explicarías 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.
¿Por qué paga el desarrollo ágil de software?
Incluso para proyectos internos, hay 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 reacciones violentas 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.
Con respecto a la "única metodología para gobernarlos 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, cuando 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.
Sugeriría contra Agile al desarrollar un nuevo sistema de control de tráfico aéreo.
En mi humilde opinión:
Agile o no, debe diseñar lo que se conoce antes de implementarlo, antes de "simplemente probar 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. Ágil, donde obtienes actualizaciones semanales sobre el estado, demostraciones prácticas a medida que están disponibles y el derecho de interrumpir el servicio cada 2 semanas (en caso de que no te guste nuestro trabajo).
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 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 tu 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, 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 dividiéndolo en 3 ciclos de cuatro semanas, al comienzo de cada ciclo en el que todos nos reunimos. una habitación, y dijo: "Ok, 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 fue solo una puñalada, entonces Volvimos a nuestros escritorios, y quienquiera que sea el dueño de las diversas piezas se deshizo de los detalles.
Básicamente, 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.