La cuestión aquí radica en el “mi punto de vista es el único bueno”, cuando verdades universales hay pocas y el tiempo en cuanto a cantidad no suele ser sinónimo de calidad: por un lado deja apartada la posibilidad de que el aprendiz pueda enseñar al maestro, y por otro, hay personas, que seguro no es su caso, tienen 30 años de experiencia, repitiendo el primer año.
Una pequeña disertación (mentira, larga):
Si dividimos la forma de afrontar los proyectos en una forma tradicional llamemosle en cascada o waterfall vs una forma moderna llamemosle ágil o “agile”, cada proyecto puede aplicarse mejor siguiendo una o la otra o a veces, mezclando alguna etapa de una en la otra.
Waterfall puede servir para proyectos de envergadura o alcance pequeño y/o muy acotados, con equipos pequeños. Por ej. desarrollar una utilidad, un CLI o librería de conexión a una API o una prueba de concepto para validar una hipótesis. Y aún así, se enriquece si empleamos prácticas típicamente potenciadas con el agile como TDD, CI/CD por nombrar alguna.
Agile sirve para proyectos en los que la única forma de validar el proyecto es entregándolo y hacer, no ya sólo que su cliente lo pruebe y valide, si no que sus usuarios o a su vez clientes (e incluso usuarios de sus clientes) lo validen. Léase validar como hacer que se use. Un software sin usuarios …
La educción de requisitos puede formar parte de los artefactos que utilice para acometer un proyecto, tanto en waterfal como en agile. Pero la literatura e internet están llenas de fracasos de desarrollos puramente waterfal caja negra.
Por otro lado ver a un ente privilegiado y providente (una persona o comité) que es capaz de definir todo lo que debe hacer el software, mitigar el riesgo de desviación en alcance, presupuesto y tiempos, de modo que cuando unos trabajadores de cuello azul lo desarrollen y se entregue dentro del plazo comprometido (¿2-3 años vista?) con el cliente sea lo que este espera (y repito lo anterior que comentaba: que sea lo que usen sus usuarios o clientes), es como hacer sonar la flauta. Los proyectos se enriquecen cuando en ellos participan varios stakeholders: clientes, usuarios y equipo de desarrollo, típicamente multidisciplinar y se entrega de forma continua: cuello blanco
Le recomiendo que revise la historia del desarrollo del software, de cómo cuando al nacer, el desarrollo de software me refiero, nos fijamos en escuelas cercanas como la ingeniería industrial o arquitectura para copiar las mismas etapas (diseño-plano, perfiles-obreros, código-ladrillos) y cómo a través del tiempo y la frustración, se vio que debía haber otras formas de hacer software: movimiento agile y el agile manifiesto y que no eran trasladables 1 a 1 ni mucho menos por los graves problemas de sobrecostes y disgustos a la entrega.
Si necesita enlaces, puede pedírmelos.
Y por terminar esta parrafada que hasta a mi me está costando leer para repasar (¿quizás no debiera publicarla?) como se suele decir, como muestra vale un botón y partiendo de que la gente puede vivir y comer de muchos tipos de actividades y cómo afrontarlas, me encantaría que me pusiera ejemplos concretos, públicos (webs, Apps, sistemas, etc.) que se acometieron en alcance, presupuesto y tiempo con una estrategia waterfall, con recomendaciones de clientes y buen NPS; no hay más crédulo que el que ve y mete el dedo en el agujero del clavo. No es un reto, o quizás sí, como digo, de todo se aprende y me vendrá bien conocerlos.
Por mi lado, puedo hablarle directamente de www.dialenga.com, producto de mi empresa, desarrollado durante sus 3 años de vida con metodologías ágiles, con el usuario en el centro (product management, hablando con el cliente y usuario constantemente), entregas continuas mensuales y que usamos en nuestra propia empresa (por lo de Taleb y el ingeniero que vive debajo del puente), además de para más de 20 clientes y más 20000 usuarios. Sigue en evolución porque para mi el software es un ente vivo. Y podemos hablar de otros proyectos abordados igualmente si lo desea.
Un saludo.
.
