¿Cuáles son los beneficios monetarios de ser ágil? [cerrado]

8

¿Por qué ser ágil ? Esta es la primera pregunta que me viene a la mente cuando pienso en ser ágil. ¿Cuáles son los posibles beneficios financieros que uno puede lograr al volverse ágil?

A la mayoría de nosotros sin duda nos gusta pensar que los clientes y clientes son personas que no saben lo que quieren. Entonces, ¿por qué ayudarlos? ¿Por qué no chupar su dinero siendo una compañía parasitaria y hacerlos más estúpidos cada día? El desarrollo de software tradicional no es malo y es probable que (en la mayoría de lo que he visto) sea un entorno mucho más fácil para trabajar en lugar de proyectos ágiles.

Entonces, ¿por qué ser ágil? ¿Qué puede dar Agile adicional (quiero decir financieramente) que el desarrollo de software tradicional no puede?

agile development-methodologies

— menosSeven
fuente

1

+1 Esta es una buena pregunta. Los defensores ágiles enfatizan los estudios de que ágil es más eficiente . Se da por sentado que las personas quieren mejorar como profesionales. Pero, ¿qué pasa si no te importa eso? ¿Qué pasa si solo quieres ganar dinero ? ¿Es ágil algo bueno para eso?

— Joonas Pulakka

13

Pareces hastiado como alguien que trabajó en una empresa de Agile-Fall, experimentó la disfunción extrema y luego le dijeron que era Agile. La mayoría de nosotros creemos que entendemos cuando estamos comenzando, y luego tenemos personas más experimentadas que nos dicen cómo debe hacerse. Nos dijeron esto, pero nunca supimos por qué. La cascada tiene una tendencia al fracaso donde Agile verdadero tiene una tendencia al éxito y hasta que experimentemos tanto el fracaso de uno como el éxito del otro, nunca lo sabremos realmente. Si está pensando en beneficios financieros, entonces ya está demostrando que no comprende.

— maple_shaft

44

Tener experiencia ágil en su currículum puede proporcionarle beneficios monetarios.

— jfrankcarr

3

El problema es que los clientes no son estúpidos, y si intentas ser parasitario, eventualmente llegarán a un punto en el que ya no querrán trabajar contigo. Y no será tanto como quieras. Desea ser más eficiente porque puede ofertar menos que su competidor, lo que le dará más negocios.

— Andy

1

Pregunta algo relacionada: programmers.stackexchange.com/questions/125429/…

— SoylentGray

16

Agile produce mejores resultados (más cercanos a lo que el cliente necesita , no necesariamente lo que inicialmente dice que quiere ), en menos tiempo = dinero (o al menos con estimaciones más confiables). Es simplemente una mejor manera de llevar a cabo proyectos (en comparación con "cascada"). Los clientes están más felices. Los programadores son más felices. Los proyectos son mejores. La comunicación es verdadera y transparente. La vida es buena. ¿Qué es lo que no te gusta, en sentido profesional?

Si tiene buenos vendedores, puede vender basura a sus clientes y cobrarles más. Financieramente, esto tiene sentido. La realidad es mucho más complicada que la visión crédula "si hace felices a los clientes, sus ventas aumentarán; si los decepciona, sus ventas disminuirán". El mundo no es un lugar justo. Puedes vivir bien como un parásito imbécil. Muchos hacen. Es tu elección si quieres ser uno. Si es así, no jugaré contigo.

No es ningún truco ganar mucho dinero, si todo lo que quieres hacer es ganar mucho dinero. ~ "Everett Sloane" en Ciudadano Kane

También:

ingrese la descripción de la imagen aquí

— Joonas Pulakka
fuente

Es la diferencia "Buena ganancia" y "Mala ganancia". "Buena ganancia" = cliente satisfecho, "Mala ganancia" = estafó al cliente

— Atif

44

-1 No creo que esté de acuerdo con ninguno de sus primeros párrafos como una declaración general. Si tiene un proyecto deficiente y una administración deficiente, cambiar a un proceso ágil no hará que el equipo se sienta feliz de repente, el proyecto sea excelente o los clientes apreciarán sus esfuerzos.

— SoylentGray

2

Bueno, sí, cambiar los procesos en medio de un proyecto mal administrado podría no marcar la diferencia para ese proyecto . Cambiar los procesos como una estrategia a largo plazo para mejorar el rendimiento general.

— DaveE

1

-1: Primero, no puedo determinar si el primer párrafo está vendiendo aceite de serpiente o balas de plata. Ya es hora de que esta industria crezca y detenga este tipo de basura. Creo que Agile es un mejor enfoque para el desarrollo de software que Waterfall, pero no mucho mejor.

— mattnz

2

mattnz: si tiene requisitos bien definidos, con un alcance bien definido, la cascada funciona perfectamente. Agile funciona mejor en el mundo real al ajustarse a la fluencia del alcance y los requisitos cambiantes. A veces funciona un martillo y otras veces un destornillador es mejor.

— SoylentGray

8

Sospecho que por "tradicional" te refieres a algún tipo de flujo de trabajo en cascada.

Los beneficios monetarios son muchos. Las horas hombre requeridas para implementar una característica adicional son lo principal. No puede detener el proceso una vez que lo inicia, por lo tanto, si el cliente no está contento con lo que obtiene (y siendo 'estúpido', al cliente solo le importa hacer su trabajo, así que si su software no hace ese trabajo correctamente perderás al cliente).

Otra es la garantía de satisfacción del cliente, que también genera más ventas y más clientes satisfechos (y queremos eso desde una perspectiva comercial).

Tener la capacidad de retroalimentar el ciclo de desarrollo también significa que puede adaptarse a las mejoras tecnológicas (por ejemplo, asp.NET mvc 4 que está llegando ahora), lo que también ahorra mucho tiempo. Después de haber establecido una especificación estricta para el proyecto, no puede actualizar a una tecnología / biblioteca / activo más nuevo / mejor que también podría potencialmente ahorrar tiempo.

El tiempo es dinero.

— Mihalis Bagos
fuente

Me gusta tu declaración final. +1

— Andrei G

2

En mi experiencia no hay una garantía absoluta de satisfacción del cliente. A veces quieren lo imposible y no estarán contentos con lo cerca que entregas. Además, a menudo no entienden la brecha entre lo que quieren y lo que realmente necesitan. Sin embargo, las técnicas de desarrollo secuencial no son mejores que ágiles para resolver ese problema. Simplemente son mejores para definir en lenguaje legal por adelantado lo que va a entregar, y no dejan espacio para que el cliente verdaderamente patológico comience a pagar.

— Joris Timmermans

2

Jaja sí, el cliente siempre querrá más, eso es cierto. Sin embargo, creo que al obtener constantemente la confirmación de que las cosas van en la dirección correcta, el producto final al menos valdrá la pena. Luego, si el cliente necesita más funciones, etc., dado que acordó que el producto estaba bien (en ese momento), puede justificar costos de desarrollo adicionales.

— Mihalis Bagos

Mi investigación me lleva a creer que el ahorro de tiempo en la implementación de funciones es realmente menor. Es llegar a la solución CORRECTA que es más rápido.

— SoylentGray

6

Hay una demostración que vi que es una analogía bastante buena de los beneficios de Agile sobre los métodos más tradicionales. Está basado en el juego Battleship. Usted y el otro jugador se sientan en la grilla normal de Battleship. Ambos tienen 20 disparos, cada uno con un costo de $ 5,000 para un gasto inicial total de 100,000. Aquí está el truco; Tienes que planificar TODOS tus disparos antes de disparar uno solo. Tu oponente disparará sus disparos "normalmente"; tomar una foto, ver qué pasa, tomar otra foto.

Al final de 20 disparos, ¿adivina quién anotó más golpes?

La analogía se traduce en Agile vs Waterfall de manera bastante limpia; En Agile, puede tener en cuenta la suma total de todo lo que ya ha hecho al planificar lo que va a hacer a continuación. Tendrá una idea básica de las áreas que serán difíciles y las áreas que serán fáciles según las dificultades o la falta de dificultades que ya haya experimentado. También ha recibido comentarios de su cliente en fragmentos más pequeños, indicando que les gustó esto o no, y que pueden incorporar ese conocimiento rápidamente, sin haber creado una gran cantidad de código adicional además de algo que el cliente dice que está mal .

En las metodologías tradicionales de Waterfall, todo el sistema y el cronograma de desarrollo se planifican antes de que comience la codificación. Este es el enfoque de "planificar todos los disparos antes de disparar uno"; es posible que pueda entregar exactamente lo que el cliente solicitó, pero podrían echarle un vistazo y decir "eso no es lo que necesitamos". Sí, obtienes tu dinero porque entregaste de acuerdo con los términos del contrato, pero tus desarrolladores han perdido su tiempo, tu cliente ha desperdiciado su dinero y ninguno de los dos está contento con el resultado. Agile está diseñado para ayudar con esto, permitiendo que los requisitos del proyecto cambien mientras el desarrollo está en marcha. Cualquier cosa que aún no haya hecho está abierta a cambios; todo lo que HAS hecho también puede cambiar

Además, debido a que el cliente decide primero en qué trabajará, y con usted entregando pequeños trozos de trabajo completado con mayor frecuencia, el cliente podría posiblemente tener un sistema que pueda usar antes. Ese es el ROI visible para su cliente, lo que generalmente hace que el cliente esté más dispuesto a participar en este proceso de desarrollo más complicado.

— KeithS
fuente

Tu analogía es bastante defectuosa. Para hacer que el enfoque ágil sea más análogo al de Battleship, deberías permitir que tu oponente cambie la ubicación de las naves después de cada iteración. Entonces tu analogía sería más apropiada.

— Dunk

¿De dónde vino este mito de que los clientes de los desarrolladores de cascada siempre son infelices y ágiles habrían resuelto ese problema? Parece que demasiadas personas están bebiendo el kool-aid.

— Dunk

No era mi analogía, y la idea es que, incluso dado un plan para lo que el cliente dice que quiere, ser capaz de "golpear" de manera confiable lo que realmente quiere sin comentarios en el camino siempre será más difícil (y más costoso, ya que se espera que tanto el tipo Agile como Waterfall alcancen todos sus objetivos, pero Waterfall necesitará más dinero para más rondas de desarrollo).

— KeithS

Dunk, tú y yo ya hemos pasado por el arbusto de moras en Agile. No te gusta No crees que funcione. Hay muchos que no estarían de acuerdo, pero la realidad es que si no te gusta Agile, puedes continuar con Waterfall. Le garantizo que terminará adoptando algunas de las ideas que Agile promueve (como la retroalimentación rápida de los clientes y lo que el cliente quiere hacer primero) sin importar la metodología SDLC que elija.

— KeithS

Nunca dije que Agile no funciona. Sin embargo, solo funciona bien para ciertos tipos de proyectos. Y esa es mi objeción. Para un agilista, ágil es la bala de plata. no existe el fracaso para un agilista siempre que tenga una versión. No importa si no satisface las necesidades del cliente. En cuanto a adoptar algunas de las ideas que Agile promueve, eso ya lo han hecho los practicantes exitosos de la cascada mucho antes de que Agile fuera concebido. Por lo tanto, no otorgue crédito ágil por los conceptos que ágil robaron de los procesos que luego dan vuelta y critican.

— Dunk

4

Para mí, el beneficio viene al hacer contratos de oferta fija. He podido ganar contratos de oferta fija y hacer una tarifa por hora efectiva que me daría vergüenza incluso hablar utilizando métodos ágiles. Pero también requiere un equipo talentoso que se haya unido para que valga la pena.

Tienes razón, es más fácil hacer un trabajo pobre, facturar todo el tiempo. Después de haber trabajado en la industria durante 16 años, he visto una buena cantidad de escándalo. Especialmente durante el boom de las puntocom. Incluso es posible ejecutar la misma estafa, evitándola repetidamente. Pero lo mismo es posible en cualquier industria. He sido estafado por talleres de reparación de automóviles. Incluso los supuestamente "acreditados". Casi todos los días escuchas historias sobre contadores que malversan a sus clientes, predicadores que roban de su iglesia, políticos que reciben sobornos de grandes empresas. Y todos ellos se clasifican como delitos de "cuello blanco" como si lo mejoraran. Oh, robaron millones de dólares de sus accionistas, pero fue un delito de cuello blanco.

No hay nada que le impida aprovechar la confianza y las expectativas de las personas. Personalmente, es una cuestión de orgullo. Prefiero ir a la cama sabiendo que superé las expectativas de aquellos con quienes trabajo / para los que trabajo.

— Michael Brown
fuente

Te di un +1 aunque no tengo claro lo que escribiste. Creo que dijo que el beneficio de la cascada es para contratos de oferta fija. Lo cual es mi punto exactamente. Si soy cliente, quiero saber exactamente qué está comprando mi dinero. No quiero pagar millones y terminar con la mitad de lo que necesito. Como cliente, yo llamaría a eso un fracaso. Como agilista, eso se llamaría un éxito porque tienen un programa a medias. Independientemente del hecho de que es bastante inútil para el cliente en ese estado.

— Dunk

En realidad, uso ágil para contratos de oferta fija. Obtiene una buena imagen de lo que el cliente quiere y planifica el proyecto. Luego, use la iteración rápida y la entrega para que el ciclo de retroalimentación funcione. Al final, si lo haces bien, terminas entregando más de lo que el cliente esperaba.

— Michael Brown

O se queda sin dinero mucho antes de darle al cliente el producto que necesita. Es posible que tenga algunas características importantes, pero eso no ayuda mucho sin el paquete completo. Como he dicho antes, los aviones que pueden despegar pero no aterrizar no son muy útiles. Sin embargo, un agilista lo llamaría un éxito.

— Dunk

Nunca llamaría a un proyecto que resulte en un éxito incompleto del producto.

— Michael Brown

2

Agile aborda el problema de cómo "entregar" software de calidad con:

a) Cambio de requisitos: incluso cuando el espacio del problema es muy claro, los requisitos no funcionales como el rendimiento, la seguridad, el cumplimiento, etc. pueden cambiar la funcionalidad principal.

b) Plazos de entrega cortos: el tiempo de comercialización es extremadamente crítico, por lo que deben tomarse decisiones sobre lo que está terminado y los clientes pueden esperar recibirlo.

c) Tecnologías que cambian rápidamente: los cambios en la tecnología son tan rápidos que es difícil para los proyectos mantenerse al día.

d) Mejoras y condiciones cambiantes del mercado: las soluciones tienen que evolucionar rápidamente para cumplir con las condiciones cambiantes del mercado y agregar características para competir con otros productos.

— Stephen Senkomago Musoke
fuente

1

+! Creo que esta es la mejor manera de ver ágilmente. Como una herramienta en el cuadro para hacer frente a estos problemas.

— SoylentGray

1

Bueno, Agile tiene como objetivo obtener un producto terminado en una fecha exacta.

Si se supone que la cascada tradicional debe hacer lo mismo, pero a menudo sufre debido a que el arrastre del alcance no se maneja adecuadamente.

Se supone que Agile gestiona mejor esto para guiar al "negocio" a ayudar a impulsar características importantes a las que se les dará mayor prioridad y se entregarán primero. La prioridad de los elementos puede cambiar a través del proyecto a medida que haya nueva información disponible.

El beneficio es que entrega algo más útil en lugar de quedarse atascado continuamente incumpliendo plazos.

— ozz
fuente

Mientras a su cliente no le importe obtener un producto medio terminado, sus puntos son válidos.

— Dunk

@Dunk bueno, sí, esa es la opinión negativa. Lo veo desde un punto de vista de "vaso medio lleno". Primero obtienen las características correctas, con la capacidad de cambiar fácilmente.

— ozz

Como ingeniero, es mi trabajo analizar todos los riesgos y mirar el panorama general, no enterrar mi cabeza en la arena y solo mirar la tarea inmediata en cuestión y asumir que todo lo demás funcionará bien. Esa no es la opinión negativa, es la opinión de un profesional. Si la mitad de un sistema de trabajo satisfará las necesidades del cliente, entonces bien, ágil podría ser el mejor enfoque, pero para el tipo de proyectos en los que trabajo, ese nunca ha sido el caso. También me opongo totalmente con su comentario de "capacidad de cambiar fácilmente incorporado", ya que la capacidad de crear software como ese requiere habilidad.

— Dunk

@Dunk - oh cierto, eres profesional y yo no, lo que sea, amigo. En ninguna parte dije que el enfoque entierra su cabeza en la arena. Ni siquiera soy un fanático ágil, tenga en cuenta el "supuesto" en cursiva en mi respuesta. La cascada tradicional sufre exactamente los mismos problemas, ya sea a medio terminar o ridículamente por encima del presupuesto. Ambos procesos pueden funcionar, ambos procesos pueden fallar, he visto que todo sucede. Simplemente estaba tratando de responder la pregunta original de cómo "puede" ahorrar dinero. Ágil NO es una bala de oro, ni una garantía de éxito.

— ozz

@Dunk: veo tus comentarios sobre otros puntos. Estoy de acuerdo en que hay muchos fanáticos ágiles que lo ven como una bala de plata. No soy uno de ellos, pero creo que Agile tiene sus ventajas cuando se hace correctamente con un equipo maduro y un cliente comprometido. Sin embargo, no creo que la anología del "avión" funcione bien. Para construir un avión, TODAS las necesidades deben conocerse desde el principio. No creo que Agile funcione bien en ese escenario. Pero para muchas aplicaciones, quizás más comúnmente aplicaciones comerciales donde el cliente tiene una idea descabellada de lo que quiere / necesita, y esto cambia con el tiempo, Agile funciona muy bien.

— ozz

0

Si crear un mejor software no le hace ganar más dinero, tiene un problema comercial y no un problema de metodología de desarrollo.

¿Por qué no chupar su dinero siendo una compañía parasitaria y hacerlo más estúpido cada día?

¿Por qué no proporcionar un beneficio real a la empresa donde hacen la conexión de sus servicios a su rentabilidad?

— JeffO
fuente