Ken Schwaber, cofundador de Scrum y fundador de Scrum.org, dice que Waterfall “literalmente arruinó nuestra profesión”. “Hizo que las personas fueran vistas como recursos en lugar de participantes valiosos”. Con tanta planificación, los empleados pasana convertirse en una pieza más de ajedrez.
El modelo de desarrollo en cascada «Waterfall» surgió en las industrias de fabricación y construcción; donde los entornos físicos altamente estructurados hiso que los cambios de diseño se volvieron prohibitivamente costosos. Cuando se adoptó por primera vez para el desarrollo de software, no había alternativas reconocidas para el trabajo creativo basado en el conocimiento.
El problema
El trabajo de diseño y construcción de un programa de software era bien conocido. Aunque la evolución del software fue bastante rápida en comparación con cualquier otro tipo de ingeniería, no había máquinas sofisticadas y rápidas disponibles que pudieran compilar y procesar nuestro trabajo en medio segundo para mostrar el resultado en pantallas de computadora o exponerlo en una capa interactuable. Había que perforar tarjetas con toda la lógica del programa. Solo entonces, las máquinas leían tarjetas perforadas. Un error de escritura generalmente significaba volver a perforar una tarjeta completa.
Echando una mirada al pasado, esto suena doloroso y lo fue. Se necesitaban varios programadores para ejecutar una compilación simple. Había personas que se encargaban únicamente de organizar las tarjetas. Claro que esto no es ningún trabajo especializado, pero alguien tenía que hacerlo. Para este sencillo proceso minimizaba el costo de esta engorrosa operación es donde interviene Waterfall. No había necesidad de tener muchos profesionales altamente especializados sentados y perforando tarjetas todo el día si la planificación se había hecho antes. Esto funcionó perfectamente. Se pudieron evitar muchos errores y se necesitó menos tiempo para desarrollar un programa.
Avanzando
La conocida lentitud de las organizaciones para adoptar nuevos conceptos no podía seguir el ritmo de la evolución de las máquinas. Cada vez era más fácil y barato acceder a más recursos de hardware, las compilaciones de programas dejaron de necesitar interacción física con las computadoras, la web se inventó e implementó globalmente, lo que permitió a los desarrolladores compartir conocimientos desde cualquier lugar.
Waterfall dejó de tener mucho sentido en un entorno tan rápido y colaborativo. Cualquiera podía tener una máquina en la comodidad de su casa y escribir y, en ocasiones, programas disruptivos que sacudían los cimientos de prácticas de mercado conocidas. Dedicar meses de planificación, escribir cientos de páginas (comúnmente libros) de documentación de requisitos y diagramas comenzó a ser un paso innecesario de una gestión opresiva. Los cambios habían llegado.
Lo viejo contra lo nuevo
En los últimos años, muchos han hablado de Agile como la metodología central y obligatoria para los procesos de desarrollo de software e incluso los que no son de software dentro de una organización. La mentalidad común es que es la respuesta a todos los problemas. No importa en qué sector, qué/quién esté involucrado y cuál sea la naturaleza, habrá un marco Agile para usted.
Cada organización es única y se enfrenta a varios elementos internos (es decir, tamaño y estructura) y elementos externos (es decir, clientes y modelo de negocio). Se ha trabajado mucho en la creación de nuevos marcos siguiendo el manifiesto Agile para satisfacer la demanda de diferentes tipos de problemas emergentes. La simplicidad proviene del hecho de que es un conjunto de principios para seguir y ajustarse a sus necesidades. No hay una solución única para todos. Cada sector tiene sus propios roles, problemas, procesos, personas y habilidades. Qué combinación es buena para el equipo dependerá de los factores, deseos y objetivos internos y externos.
En un entorno Agile, la colaboración entre equipos está presente de forma más constante en comparación con las metodologías Waterfall, donde la documentación se escribía y luego se transmitía al siguiente en la línea. Cada pregunta hecha fue respondida con un simple y perezoso «Lea los documentos» . Inspirado por una visión del futuro o simplemente compilado malas experiencias que parecían comunes a todos dentro de esa habitación, el manifiesto ágil cobró vida. Con toda buena metodología, solo un objetivo es importante: resolver un problema.
El (viejo) nuevo problema
En ese momento (años 1990, 2000) había poca o ninguna segregación entre quién era responsable de crear un buen producto de software. La mayor parte del trabajo en manos de los desarrolladores. La experiencia del usuario no era algo en sí mismo. Evidentemente siempre estuvo presente pero si un producto tenía buena aceptación era un tanto un misterio. El diseño de la interfaz de usuario no se consideró importante y presentó algunos resultados terribles.
Hoy, sin embargo, es posible que necesite varias personas con diferentes conjuntos de habilidades para crear y mantener un producto competitivo en el mercado. Diseñadores de UX/UI , gerentes de producto (y sus variaciones), desarrolladores backend , desarrolladores frontend , desarrolladores móviles , profesionales de infraestructura , etc. (¿ve un patrón aquí?) Está claro que la necesidad de más personal, diferentes títulos de trabajo está aumentando día a día.
Sumado al hecho, las grandes empresas de tecnología están comenzando a desesperarse. No hay suficiente profesional para alimentar sus necesidades. En una década (2001-2011) los salarios aumentaron hasta un 35% y hasta un 47% en la última según la zona. ¿Podría volver a ocurrir una era de crisis de software?
El objetivo principal de Waterfall es reducir los costos de la fase de desarrollo (la escritura del código real). Con salarios tan altos y la falta de profesionales disponibles, señales del regreso de la planificación anticipada. Las pequeñas empresas no pueden simplemente competir con los salarios de las grandes tecnológicas y mantener a los profesionales cerca para “cometer errores más rápido”.
¿Qué piensas? ¿Vale la pena hacer la planificación antes de la ejecución real? ¿O todos deberían usar la prueba y el error? ¿Quizás una mezcla de ambos?
