Predictivo vs diseño de software reactivo

Question

Sé que para mí primero comencé siguiendo el método de cascada de gestión de proyectos y junto con eso fui con el enfoque predictivo para el diseño de software. En esto quiero decir que teníamos enormes paquetes de documentación, UML, esquemas de bases de datos, diccionarios de datos, flujos de trabajo, diagramas de actividades, etc.

Después de haber trabajado en software por más de 10 años ahora me parece mucho más realista acercarme al software diseño desde un enfoque reactivo. Frecuentemente sigo un enfoque de scrum para la gestión de proyectos y con eso se genera muy poca documentación. Tenemos muy pocas especificaciones de flujo de trabajo (aunque todavía tienen uso). Este es un enfoque mucho más dinámico para la creación de software. Por supuesto, junto con esto viene la refactorización frecuente a medida que pasa el tiempo a medida que descubrimos nuevas características a lo largo del tiempo que, si hubiéramos planeado desde el principio, habrían cambiado las cosas de manera espectacular.

La gran diferencia para nosotros es que el primer enfoque lleva más tiempo, parece fallar con más frecuencia en un mundo de construcción de software y no es tan flexible. El segundo enfoque proporciona más flexibilidad, nos hace conscientes de la falla más rápido (por lo que podemos corregir el curso más rápido), y proporciona alguna forma de funcionalidad al final de cada iteración.

Conociendo ambos lados por experiencia, todavía encuentro muchas personas que AMAN el enfoque de cascada sobre el enfoque ágil para el desarrollo de software. No lo entiendo

pregunta: ¿Por qué alguien usaría cascadas sobre alguna forma de ágil con todo el respaldo de investigación ágil? ¿Cuáles son los argumentos fuertes para usar la cascada sobre ágil?

Answer 1

Mi jefe me dice que lo haga.

Sospecho que muchas personas no tienen otra opción y los viejos jefes no aprenden nuevos trucos.

Answer 2

Cuando comencé a programar (con COBOL no menos), la cascada era el "nuevo" enfoque. Hoy, les diría que utilizo una metodología ágil de cascada. Para sistemas más grandes, encuentro que el inicio de una cascada funciona mejor. No crear documentos enormes (eso es una pérdida de tiempo IMO), sino más bien dar algunos pasos, como crear un prototipo de UI y/o casos de uso para tener en cuenta el problema comercial. Una vez que nos sentimos cómodos tenemos el problema abordado y tenemos una comprensión sólida, nos movemos hacia un modo de desarrollo ágil.

Para responder a su pregunta, creo que la gran razón por la que la cascada se queda es que a mucha gente no le gusta el cambio. Da miedo cambiar y pasar de la cascada a la ágil es un gran cambio.

Answer 3

Si sabes exactamente los requisitos que nunca cambian, si sabes cuánto durará cada paso y si sabes que todos los recursos están disponibles en el momento necesario, puedes hacer la cascada y funcionará. Pero, de hecho, este tipo de proyectos son bastante raros y creo que nunca seré parte de ellos.

Answer 4

Al diseñar sistemas para ser utilizados por los usuarios finales, ágil a menudo funciona bien porque es probable que los requisitos sean incorrectos y una gran parte del proceso recibe comentarios de los usuarios en forma de una versión utilizable.

Sin embargo, cuando se crea un software que interactúa con otro software a menudo los requisitos se pueden resolver de forma muy clara. En este caso, a menudo es más productivo asegurarse de tener una especificación muy clara y precisa, pruebas unitarias. En este modelo también puede generar estimaciones de trabajo bastante buenas y el uso del modelo ágil implicaría un costo mucho mayor.

Answer 5

Creo que parte de la razón por la que las personas aún se aferran a las cascadas es porque da la ilusión de control.En una cascada, puede hacer suficiente trabajo por adelantado para armar un calendario hermoso que aborde todas las contingencias que pueda imaginar, y luego proporcionar una hoja de ruta detallada para el futuro a cualquier persona del lado comercial que pregunte cuándo será la característica X. disponible.

El problema es que casi nunca se puede seguir ese plan al pie de la letra, y casi siempre se atrasa/se caen las funciones. Sin embargo, desde el principio, parece muy controlado y manejable.

Soy un gran admirador de Agile, pero lo que siempre he tenido problemas es la hoja de ruta/previsión a largo plazo que a menudo solicita la gente de ventas y marketing. Creo que la ilusión de certeza de la cascada es muy reconfortante para los gerentes y la gente de negocios.

Answer 6

No toma partido, pero prácticamente cualquier investigación sería, en el mejor de los casos, no científica.

Usted dice (el subrayado es mío)

pregunta: ¿Por qué alguien usar cascada sobre alguna forma de ágil con todo el respaldo de la investigación ágil? ¿Cuáles son los argumentos fuertes para usar la cascada sobre ágil?

pero no se enlazan con ningún estudio.

Es una de esas cosas que se sabe que son extremadamente difíciles de probar realmente. No puede tener dos equipos idénticos trabajando en el mismo proyecto al mismo tiempo, porque no hay dos equipos idénticos. No puede hacer que el mismo equipo complete la misma tarea dos veces seguidas utilizando dos metodologías diferentes sin que el primer pase afecte al segundo. Nunca he escuchado que alguien diseñe un estudio experimental (o incluso estadístico) que pueda argumentar convincentemente sobre cualquier metodología de desarrollo de software. Sin embargo, me gustaría ver uno, si tienes un enlace.

A falta de evidencia real, se reduce a preferencia personal. ¿Cuáles son los argumentos fuertes para el chocolate sobre la vainilla?

Answer 7

Voy a jugar al abogado del diablo y afirmar que la agilidad es defectuosa es casi tantas formas como el método de la cascada. No soy de los que adoran el método de la cascada, pero tampoco me gusta el ágil.

Mi experiencia con ágil no ha sido muy positiva. Para ser justos, lo usé en un entorno corporativo, que fingió ser "ágil" mientras esperaba que nuestro gerente produjera hitos y resultados a largo plazo por adelantado.

Sin embargo, encontré que las metodologías ágiles (scrum en particular) a menudo disimulan los principales problemas con el diseño. Mientras que la cascada le da a los gerentes la ilusión de control, ágil parece hacer lo mismo para los equipos de desarrollo. He visto equipos en los que no se abordan los problemas que no están en el sprint/iteraton actual, con la expectativa de que se manejarán "a tiempo". Solo se deben ignorar algunas decisiones importantes de diseño para que el proyecto se desarrolle en el futuro, mientras que las iteraciones actuales se desarrollan sin inconvenientes y el proyecto parece estar bien encaminado.

Puede argumentar que el equipo tiene la culpa por no entender el espíritu de agilidad, pero me gustaría ver mejores metodologías que incorporen las mejores partes de ágil.

Answer 8

El título lo dice todo. (En realidad: proactivo vs reactivo). ¿Por qué elegir la forma reactiva y renunciar al control a menos que no sea necesario? La cascada no es la única alternativa, puede tener cualquier tipo de proceso de desarrollo que refine cuando lo desee. El control es la clave.

Es un espectro por cierto, la cascada en un extremo y los métodos de documentación totalmente reactivos, cero en el otro extremo. Si trabaja en la industria de consultores para clientes poderosos (y generalmente indecisos), debe recurrir a métodos reactivos. Si desarrolla software shrinkwrap, puede planificar anticipadamente y administrar el conocimiento. Algunos proyectos también requieren toneladas de especificaciones y reglas, donde el enfoque de código y arreglo simplemente no lo reduce. Para mí, la ingeniería de software se basa principalmente en la gestión y el diseño del conocimiento; la codificación ocupa el segundo lugar.

P.s. no hay tal cosa como el precio ágil y fijo. No en la forma clásica, generalmente venden el método. Ver http://martinfowler.com/bliki/FixedPrice.html

Answer 9

comportamiento retroactiva

Answer 10

Si usted tiene un equipo de una docena de personas que tienen a lo largo de una década, refinado la estrategia de cascada hasta el punto de que funciona bien para ellos, ¿quién eres tú para venir y decir, "Lo estás haciendo mal ..."? Realmente, si les funciona, ¿por qué cambiar las cosas? Sí, esto simplemente está volteando la pregunta, pero creo que puede ser un punto válido.

Answer 11

Una de las premisas de (al menos) XP es que el cambio es barato. El modelo de cascada fue construido sobre los principios que cambian, cualquier cambio, es costoso. La suposición en el modelo de cascada es que una vez que se ha escrito el software, cambiarlo es más costoso que invertir el tiempo por adelantado para llegar a una comprensión "completa" del problema.

La experiencia parece indicar que es muy difícil llegar a una comprensión completa del problema y que si se toman algunas precauciones (por ejemplo, las pruebas unitarias) el cambio puede ser mucho más económico. Por lo tanto, si encuentra un problema donde algunas de las premisas ágiles no son ciertas, otros enfoques podrían volverse factibles. Entre Waterfall y Agile hay al menos un desarrollo espiral que es, más o menos, lo que practicamos.

Answer 12

En mi equipo hemos encontrado que con los proyectos de mantenimiento (que es la mayor parte de lo que hacemos) donde estamos ajustando o reemplazando, no siempre hay tanta necesidad de la entrada del usuario más allá de alguna UI prototipos.

En ese caso, particularmente dado que hay acuerdos comerciales involucrados, el enfoque de cascada en un nivel macro puede encajar bien. Incluso entonces, todavía nos gustan los enfoques incrementales/ágiles en el nivel de implementación.

Vale la pena señalar que la mayoría de nuestros clientes son grandes organizaciones madereras que adoran sus trámites, lo que nos da aún más ímpetu para que al menos les parezcamos tradicionales.

Answer 13

La documentación generada durante el proceso de cascada permite una gran cantidad de CYA. Puede señalar con el dedo cuando un proyecto se sale de los rieles. Muy pocos ejecutivos van a estar bien con "oh bueno, creo que ese proyecto se nos escapó! Bueno, al menos nos enteramos temprano, no hay daño, no falta!"

Además, los documentos de diseño pueden generar automáticamente planes de prueba, lo que es útil para el control de calidad.

Answer 14

Debe ser lo suficientemente predispuesto para entregar los productos. Debe ser lo suficientemente reactivo para enfrentar los problemas.

Una vez tuve que esperar seis meses para completar un proyecto que se estima tomaría un año, y en base a la experiencia pasada, la experiencia tomaría dos. Así que pasé tres meses investigando metodologías. Terminamos a tiempo (en tres meses), utilizando las partes apropiadas de un proceso en cascada.

Algunos puntos que hicieron que el método funcione: - Cree un estándar de uso, actualícelo cuando sea necesario. - Generar bibliotecas: hágalo una vez, hágalo bien, corríjalo sin romper el código existente. - Haga la documentación suficiente. - Control de versiones todo lo que pueda. - Rompe cosas; un método debe administrar el trabajo o hacer el trabajo. - Aumenta la cohesión, disminuye el acoplamiento, reutiliza. - Compre o construya las herramientas que necesita. - Haz un seguimiento de tus problemas y progresos.

Otro proyecto en el que participé brevemente fue un proyecto de seis meses. No me involucré hasta un año y medio después de que comenzó. El líder de desarrollo había sido contratado en un marcado extremo ya que dejaba su carrera con un plan de pensiones. Al comienzo del proyecto, le preguntó al gerente del proyecto: "¿Quiere que lo haga bien o que sea reactivo?" ¿Puedes adivinar la respuesta? La semana en la que participé, la misma función se implementó los lunes, miércoles y viernes. ¿Adivina qué pasó el martes y el jueves?

La fuerza en Agile es su énfasis en lo suficiente, justo a tiempo. La fuerza en la metodología de la cascada es que cubre todas las cosas que necesita pensar. Todavía tengo que trabajar en un proyecto que hizo o debería haber hecho todos los pasos. He trabajado en muchos proyectos que hicieron los pasos que deberían haberse hecho en una base corporativa.

Answer 15

Al hacer una oferta por un contrato, es muy común que una de las condiciones más duras sea que sigas su "proceso" que en la inspección es una cascada.