¿Se puede utilizar el desarrollo de software ágil en proyectos definidos por un contrato?

14

Recientemente tuve una conversación con un compañero desarrollador sobre desarrollo ágil de software. Si bien entiendo el principio, parece que los requisitos continuamente cambiantes 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 podría 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 Agile Software Development abarca los requisitos cambiantes, ¿cómo sabe dónde termina? ¿Cómo puede presupuestar un proyecto cuando el resultado final siempre está cambiando?

¿El desarrollo de software ágil se trata más de un proceso ágil que de un producto ágil?

agile

— Verax
fuente

termina cuando realmente necesita entregar algo que funcione, en lugar de jugar. En ese punto, debe comenzar a imponer estructura, planificación, fijar requisitos y plazos, y comenzar a trabajar en lugar de perder el tiempo.

— Jwent

Cada iteración ágil da como resultado un producto funcional y entregable que el cliente puede usar y aprender más. Esto continúa hasta que estén satisfechos, lo que a menudo ocurre antes de lo planeado originalmente. Esto garantiza que el producto siempre esté funcionando y tiene en cuenta el hecho de que el software nunca se termina, sino que evoluciona para siempre o muere. Simplemente elija un punto en el tiempo cuando piense que el producto es lo suficientemente bueno y pare allí (por ahora).

— Martin Wickman

@ Martin Wickman: Entiendo esto, pero "un producto entregable que el cliente puede usar" es el problema aquí. Si este es el caso, la primera iteración podría 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 DEBE tener esta definición.

— Verax

@Verax: el manifiesto ágil se creó para gestionar los cambios. Si su proyecto no tiene cambios, entonces ágil no es para usted. Fin de la historia.

— Martin Wickman

2

@Verax: debe aclarar su pregunta y agregarle más contexto. Sus comentarios muestran que hay más en la pregunta. Esto también es obvio por la votación cuenta con la respuesta y que la respuesta aceptada no está relacionada con el texto de la pregunta real (e incluso dice "de los comentarios del OP ...").

— Martin Wickman

7

Según 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 en este marco mental que está causando su confusión ... Así que voy a Indique 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 hacemos Y. Usted quiere X + M nos paga 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á mintiendo. Simplemente dicen eso porque Agile ha alcanzado el estado de palabra de moda.

Agile funciona mejor para el desarrollo interno, donde los programadores trabajan a tiempo completo y se habla poco de presupuestos. Solo marcos de tiempo y características.

— Imbéciles
fuente

A medida que aprendo más sobre esto, llego a la misma conclusión. Tu última oración parece ser absolutamente correcta. Solía trabajar para el gobierno y mi cliente era la agencia para la que trabajaba, y los programas tenían que mantenerse durante años, siempre y cuando los empleados los utilizaran. Puedo ver ágil trabajando allí. Ahora desarrollo sistemas embebidos. El proyecto finaliza cuando la máquina funciona (todo o nada). Si la máquina funciona parcialmente, no se puede vender, el proyecto falló.

— Verax

2

En realidad, una tienda de consultoría en la que trabajaba hace un par de años tenía un documento escrito por un adherente ágil que describía cómo ágil podía adaptarse a un modelo de servicio de precio fijo.

— mcottle

2

Tengo que estar en desacuerdo con esta respuesta. La razón es que si tiene un contrato que no tiene final abierto, significa que no desea administrar el desplazamiento del alcance (lo que casi siempre ocurre). Los contratos que estoy acostumbrado a ver comienzan con: Usted paga X, nosotros hacemos Y. Luego tienen una cláusula que establece que cualquier cambio en el alcance tiene un precio adicional. Siempre y cuando sea muy temprano para notificar el avance del alcance (que requiere recursos y tiempo adicionales), los clientes anteriores pueden reaccionar a los cambios (obtener aprobaciones y presupuesto de la alta dirección, etc.). Entonces el proceso de gestión en sí mismo se vuelve ágil.

— Spoike

Esto no es incompatible si el contrato es por servicio (escritura de código) en lugar de producto (software terminado). Agile permite estimar qué se hará bajo qué presupuesto, y si el requisito cambia, el presupuesto también debe cambiar. ¿Quieres otra característica? Debe contratar otras 500 horas hombre. El avance de las características también es un aumento de los precios, completamente satisfactorio para los desarrolladores, y si el cliente está dispuesto a pagar, ¿a quién debemos cuestionar eso?

— SF.

2

Hay contratos ágiles , por lo que obviamente esta respuesta es incorrecta por definición.

— Martin Wickman

20

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

Has gastado el dinero que has presupuestado.
Has transcurrido el tiempo presupuestado.
Ya no quieres agregar ni cambiar nada.
El próximo lote de sus cambios de mayor prioridad no valen lo que costarán.

— Dale Emery
fuente

55

1. No más dinero: el cliente gastó todo su dinero en un producto inútil incompleto. 2. No más tiempo: el cliente todavía tiene un producto inútil incompleto. 3. Nada que agregar - ¡Sí, claro! 4. No vale la pena: el cliente acaba de abandonar el proyecto. --- ¿Qué me estoy perdiendo? Esto no tiene sentido para mí.

— Verax

77

Para 1 y 2: si primero hace las cosas más importantes, cuando se quede sin dinero, tendrá las cosas más importantes que puede obtener por el dinero. Similar por el tiempo. Admito que 3 es raro. Para 4: Parar no necesariamente significa que el cliente simplemente se rindió. Podría significar que tienen las cosas más importantes que querían de esto, y ahora preferirían hacer otras cosas con su dinero. ¿Cómo decides cuándo terminar otros proyectos? Cualquiera que sea el criterio que use ahora, todavía está disponible en proyectos ágiles.

— Dale Emery

1

Dale, gracias por tus pensamientos. Creo que esto solo funciona si el cliente paga por cada iteración individualmente y valora cada iteración como un producto en sí mismo. No veo cómo esto podría funcionar bien para productos de costo fijo o productos que requieren todo o nada.

— Verax

55

@Verax: No existe un producto que requiera "todo o nada". Siempre hay características que son simplemente "agradables de tener" y errores que son cosméticos en lugar de funcionales. Un proyecto de costo fijo es un éxito si eso es todo lo que queda cuando se acaba el dinero. Los métodos ágiles intentan maximizar la probabilidad de eso.

— Michael Borgwardt

1

Por supuesto, hay un costo para cambiar los requisitos. Si construyes algo en una iteración, luego cambias los requisitos para esas cosas en la siguiente, hay un costo por eso. Ágil reduce el costo. No lo elimina. Si tiene un presupuesto, tenga en cuenta el presupuesto cuando decida si agregar una nueva característica o cambiar una existente, sabiendo que siempre está intercambiando una con la otra. Aprendes a priorizar y volver a priorizar, y aprendes las consecuencias.

— Dale Emery

14

Se detiene cuando la empresa decide que no desea hacer más iteraciones. Es de esperar 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", sea lo que sea que eso signifique en su circunstancia. Podría ser la alta gerencia de una tienda de desarrollo de software o los patrocinadores comerciales reales en un entorno de desarrollo interno. Decidirán cuándo el costo de la próxima iteración supera el beneficio de las características que serán entregables en la próxima iteración.

— mcottle
fuente

5

Nunca, y esa es la belleza de esto.

El proyecto nunca está terminado . Alcanzaste 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 terminará. A diferencia del modelo Waterfall con requisito-> proyecto-> producto-> final, este es un ciclo que puede girar para siempre, siempre y cuando le paguen.

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

— SF.
fuente

2

Los proyectos en cascada tampoco están completamente terminados, solo es más probable que se entreguen con la opción de llevarlo o dejarlo con características importantes que faltan, lo que hace necesario un proyecto nuevo y costoso.

— Michael Borgwardt

4

Aquí hay una idea errónea: Agile no alienta los cambios del proyecto. 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, costo, tiempo y calidad. Cascada supone que estos serán estáticos. Esa es una suposición incorrecta; uno o más de estos SIEMPRE cambian. El desplazamiento del alcance, los presupuestos reducidos 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 características importantes que aún no se han agregado desaparecen, o se hacen rápidamente, o el lanzamiento tiene que ser retrasado, o cuesta globos a medida que el primer ministro lanza dinero a los nuevos desarrolladores para que entren y ayuden a hacerlo bien.

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

También proporciona mejores estimaciones del tiempo y el costo necesarios para producir el alcance dado con la calidad requerida. Las personas son notoriamente malas para estimar grandes trabajos; Se necesita MUCHA experiencia y MUCHO más cálculo inicial para hacerlo correctamente. Por el contrario, las personas generalmente son buenas jueces de lo que pueden hacer en un día, o una semana o dos. Eso produce rápidamente un estado estable donde puede extrapolar el tiempo y el costo del trabajo que queda por hacer en función de su ritmo histórico, con una buena cantidad de 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 SLDC tradicional; el cliente a menudo regresa 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 observa el proyecto como un todo; todo sucede ladrillo por ladrillo, sprint por sprint. Si en algún momento el propietario quiere llamar al proyecto "hecho", puede hacerlo, y tendrá la suma total de "ladrillos" que ha pagado en un "muro" sólido; Puede que no sea tan alto o extendido hasta donde se planearon originalmente, pero está firmemente en su lugar, hace el trabajo y se puede agregar en una fecha posterior con un mínimo de derribo.

— KeithS
fuente

Lo sentimos, pero "en cambio permite el cambio sin desperdiciar el trabajo", es una falacia enorme que se utiliza para convencer a la gerencia de lo bueno que es. ¿Refactorizar y / o rediseñar el sistema para acomodar cambios inesperados no cuenta como un desperdicio de trabajo? En el campo de la cascada sí, aparentemente no en el campo ágil. Además, si el cliente solo quería un trabajo que demora 2 semanas en completarse, no importa qué metodología se use, las personas pueden dar buenas estimaciones. Lo que el cliente realmente quiere es cuánto tiempo antes de tener el producto completo, donde ágil no es mejor que otros métodos de estimación.

— Dunk

1

Además, lo haces sonar como algo bueno que el propietario puede llamar hecho en cualquier momento y lo que has terminado es lo que obtiene. IME, en general, el cliente quiere saber que sus X dólares le proporcionarán un cierto conjunto de características antes de gastar el dinero. No creo que sea un beneficio que el cliente haya gastado un montón de dinero en efectivo y solo haya obtenido la mitad de las funciones que esperaban. Considero que es un fracaso por parte de las empresas en desarrollo, aunque hayan entregado algo que llaman trabajar ...

— Dunk

2

¿Qué pasa si un cliente contrata una casa pero el dinero se acaba antes de que se ponga el techo? El campo ágil todavía lo llamaría un éxito. Nadie más lo haría; en particular el cliente.

— Dunk

1

En cuanto a la estimación, el equipo estima lo que pueden hacer en un sprint, y eso se extrapola para crear una línea de tiempo para todo el proyecto. Nuevamente, ayuda a proteger tanto a los desarrolladores como al cliente. Puede incluir cualquier cosa que desee en un contrato, incluida una cantidad y fecha "que no exceda". Es negociable Ágil todavía ayuda, al mostrar a ambos lados muy rápidamente si las restricciones son factibles. Dos semanas después, si no parece que se hará a tiempo para el dinero, se pueden agregar equipos, se pueden eliminar características o se puede extender el cronograma.

— KeithS

1

¿Qué pasaría si hubiera hecho lo mismo en una cascada SLDC? O bien el desarrollo se detendría y el cliente podría obtener una base de código con serios agujeros de funcionalidad, o anticipando una escasez de dinero / tiempo, el cronograma restante se concentraría en el tiempo restante. Eso SIEMPRE sacrifica la calidad, y al final de dicho proyecto, el equipo de desarrollo está frito. Además, se producen muchos sobrecostos porque una cascada tradicional no produce un producto hasta que se completa el desarrollo; eso limita la capacidad del cliente para decir "eso no es lo que quería".

— KeithS

1

Termina una vez que se implementan todas las características y se corrigen todos los errores.

Si la fecha límite es fija y los requisitos también lo son. 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é tiene de malo?

Precio fijo parte 2, ¡arréglalo con agile!

— CharithJ
fuente

Es difícil saber cuándo se corrigieron todos los errores.

— Martin Wickman

¿Tal vez "cuando todos los errores conocidos que valen la pena corregir se corrijan"?

— Dan Ray

@CharithJ, tus enlaces están rotos. ¿Todavía están disponibles en alguna parte? Gracias.

— TwainJ

1

La gran suposición detrás del desarrollo ágil es que los requisitos siempre cambian, sin importar la metodología que utilice. Ahora, por supuesto, podría 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 del mercado y su mejor comprensión del producto por parte de usted y de su cliente, los requisitos en términos de lo que el cliente quiere van a cambiar. Agile entra y sugiere un proceso que no oculta estos cambios a través de un horario fijo, sino que responde a los cambios inevitables en el proceso.

Cuando haya terminado, ahora pasa de terminar un horario fijo a cuando su producto está en un lugar donde puede ofrecer suficiente valor comercial donde su cliente puede enviar y comercializar el software en su estado actual. Estar hecho está mucho más vinculado a la cantidad de valor que está entregando en lugar de cómo se adhirió a un cronograma.

— Brian Geihsler
fuente

1

Los defensores ágiles hacen la suposición muy equivocada de que en el mundo de las cascadas los desarrolladores desaparecen después de que se firma un contrato y nunca se vuelve a saber de ellos hasta que un producto sale por la puerta. La forma en que funciona en la vida real es que hay una buena cantidad de puntos de control y muchas revisiones en las que el cliente puede involucrarse tanto como quiera. Si no les gusta la dirección o las decisiones, pueden solicitar cambios. En el momento en que se entrega un producto, debe ser lo que el cliente desea en la medida en que el cliente elija participar. Agile no mejora esto para muchos proyectos.

— Dunk