¿Se puede usar el desarrollo de software Agile en proyectos definidos por un contrato?

14

Hace poco tuve una conversación con un desarrollador de Agile Software Development. Si bien entiendo el principio, parece que los requisitos que cambian continuamente crean el potencial para que el proyecto continúe para siempre. Pero, al menos donde trabajo, los proyectos deben completarse porque es un contrato.

Es decir, la primera iteración puede llevar meses, porque para algunos proyectos el cliente no puede usar una aplicación incompleta. Para algunos proyectos, creo que primero debe definir terminado, luego puede dividirlo en iteraciones y refinar su definición después de cada iteración. Pero siempre debes tener esta definición.

Si el desarrollo de software ágil abarca requisitos cambiantes, ¿cómo sabe dónde termina? ¿Cómo puede presupuestar un proyecto cuando el resultado final siempre está cambiando?

¿Es Agile Software Development más un proceso ágil que un producto ágil?

    
pregunta Verax 14.07.2011 - 04:07
fuente

7 respuestas

7

De los comentarios del OP parece que él como yo trabaja para una tienda de Consultoría, donde brindamos servicios de desarrollo para nuestros clientes ... Creo que porque en este marco mental está causando su confusión ... Así que Voy a declarar un hecho bien conocido pero nunca declarado.

Agile es incompatible con el desarrollo de software definido por un contrato.

  • Los contratos deben ser difíciles. Usted paga X, nosotros lo hacemos Y. Usted quiere que X + M nos pague Y + (M * N)
  • Los contratos DEBEN ser satisfactorios, (IE no abierto) de lo contrario no son contactos legales. (Cuando se trata de un contacto, debe pasar por un estricto proceso de control de cambios).

Muchas tiendas de consultoría afirman que Agile, están mintiendo. Solo lo dicen porque Agile ha alcanzado el estado de la palabra Buzz.

Agile funciona mejor para el desarrollo interno donde los programadores están a tiempo completo, y se habla poco de presupuestos. Sólo marcos de tiempo y características.

    
respondido por el Morons 14.07.2011 - 21:16
fuente
19

Si te estás enfocando en hacer (lo que crees que es) lo más importante primero, entonces el proyecto terminará cuando:

  • Has gastado el dinero que presupuestaste.
  • Ha transcurrido el tiempo que presupuestó.
  • Ya no desea agregar ni cambiar nada.
  • El siguiente lote de sus cambios de mayor prioridad no vale lo que costarán.
respondido por el Dale Emery 14.07.2011 - 04:17
fuente
14

Se detiene cuando la empresa decide que no desea realizar más iteraciones. Esperaría que esto ocurra después de que se haya entregado una cantidad significativa de valor, pero antes de llegar demasiado lejos en el ámbito de los rendimientos decrecientes.

Siempre debe ser impulsado por "el negocio" lo que sea que signifique en su circunstancia. Podría ser la administración superior de una tienda de desarrollo de software o los patrocinadores de negocios reales en un entorno de desarrollo interno. Ellos decidirán cuándo el costo de la próxima iteración es mayor que el beneficio de las características que se entregarán en la próxima iteración.

    
respondido por el mcottle 14.07.2011 - 07:03
fuente
5

Nunca, y esa es la belleza de ello.

El proyecto nunca está terminado . Alcanzó otro lanzamiento, otro hito, pero mientras el dinero fluya, siempre hay una característica más para agregar, una pieza más para mejorar, un error más para corregir. El proyecto morirá cuando ya no sea necesario, pero nunca se terminará. A diferencia del modelo Waterfall con requisito - > project- > product- > end, este es un ciclo que puede girar para siempre, siempre y cuando se te pague.

No es una característica comercial mencionada con frecuencia de esta tecnología, ¿verdad?

    
respondido por el SF. 14.07.2011 - 08:41
fuente
3

Aquí hay una idea errónea: Agile no fomenta que los requisitos del proyecto cambien. En cambio, permite el cambio sin desperdiciar trabajo o sacrificar áreas importantes de desarrollo.

Hay cuatro restricciones fundamentales para cualquier proyecto de ingeniería; Alcance, coste, tiempo y calidad. La cascada asume que estos serán estáticos. Esa es una suposición incorrecta; uno o más de estos SIEMPRE cambian. El alcance del alcance, los presupuestos recortados y otras "incógnitas desconocidas" SIEMPRE interfieren con un proyecto, cambiando las restricciones. Waterfall no anticipa esto, por lo que cuando sucede, el proyecto cambia de manera indeseable; Las funciones importantes que aún no se han agregado desaparecen, se hacen rápidamente, o el lanzamiento se debe retrasar, o el costo de los globos a medida que el primer ministro arroja dinero a los nuevos desarrolladores para que lo hagan bien.

Agile, por el contrario, permite que las restricciones cambien, y en realidad lo espera. Lo hace haciendo el trabajo en trozos pequeños y utilizables, de acuerdo con las prioridades del propietario, y por lo tanto los trozos son idealmente inmediatamente útiles para el propietario del proyecto. Por lo tanto, reduce la exposición a lo desconocido al no hacer grandes planes en un período de tiempo donde las incógnitas son grandes. Si la línea de tiempo cambia, los equipos se pueden agregar, o las características menos importantes se "eliminan", y el sistema que el equipo ya ha construido no se ve afectado.

También proporciona mejores estimaciones del tiempo y costo requerido para producir el alcance dado con la calidad requerida. Las personas son notoriamente malas para estimar grandes empleos; se necesita MUCHA experiencia y mucho más cálculo inicial para hacerlo correctamente. En contraste, las personas generalmente son buenos jueces de lo que pueden hacer en un día, una semana o dos. Eso produce rápidamente un estado estacionario en el que puede extrapolar el tiempo y el costo del trabajo que queda por realizar en función de su ritmo histórico, con bastante precisión.

En cuanto a la definición de puntos finales, tienes razón; Un proyecto ágil puede continuar para siempre. Sin embargo, también puede hacerlo el tradicional SLDC; El cliente a menudo vuelve con más dinero y una lista de deseos de actualizaciones. La diferencia es que no hay una línea clara entre "análisis", "diseño", "desarrollo" y "mantenimiento" cuando se mira el proyecto como un todo; todo sucede ladrillo por ladrillo, sprint por sprint. Si en algún momento el propietario quiere que el proyecto esté "terminado", pueden hacerlo, y tendrán la suma total de "ladrillos" que pagaron en una "pared" sólida; puede que no sea tan alto o extendido como lo planearon originalmente, pero está firmemente en su lugar, hace el trabajo y se puede agregar en una fecha posterior con un mínimo de demolición.

    
respondido por el KeithS 14.07.2011 - 20:33
fuente
1

Finaliza una vez que se implementan todas las funciones y se corrigen todos los errores.

Si el plazo es fijo y los requisitos también son fijos. Entonces esto no será un problema. Pero si la fecha límite es fija, pero los requisitos están cambiando, entonces hay algo que debe hacer para continuar el proyecto con éxito.

precio fijo parte 1, ¿qué es tan malo?

Parte 2 del precio fijo, ¡corríjalo con agile!

    
respondido por el CharithJ 14.07.2011 - 04:07
fuente
1

La gran suposición detrás del desarrollo ágil es que los requisitos siempre están cambiando, independientemente de la metodología que utilice. Ahora, por supuesto, puede crear un documento de requisitos, crear un plan para ejecutarlo y entregarlo al final, y puede parecer que sus requisitos no cambiaron. Es posible que no hayan cambiado en su plan, pero con los cambios en el mercado y una mejor comprensión del producto por parte de usted y su cliente, los requisitos en términos de lo que quiere el cliente van a cambiar. Agile aparece y sugiere un proceso que no oculta estos cambios a través de un calendario fijo, sino que responde a cambios inevitables en el proceso.

Cuando haya terminado, ahora pasa de completar un programa fijo a cuando su producto se encuentra en un lugar donde puede entregar suficiente valor comercial donde su cliente puede enviar y comercializar el software en su estado actual. La finalización se relaciona mucho más con el valor que está entregando en lugar de cómo se adhirió a un cronograma.

    
respondido por el Brian Geihsler 14.07.2011 - 04:35
fuente

Lea otras preguntas en las etiquetas