Ciclo de vida predictivo vs adaptativo

Ciclo de vida adaptativo vs predictivo


Siendo realistas, la mayoría de empresas que conozco todavía siguen tratando los proyectos de software como si contrataran albañiles para reformar el lavabo. Cuentan con una idea más o menos clara de lo que quieren hacer, y buscan un presupuesto. Cuando tienen el presupuesto escriben en un papel lo que tienen en mente y se lo enseñan a 2 o 3 proveedores para que les pasen propuestas. De todas las propuestas, se elige la que más encaje en presupuesto, idea y tiempo estimado.

Cuando reformas el lavabo es fácil. Tus necesidades no van a cambiar, cuando acaben las reformas quieres seguir duchándote, lavándote la cara, mear, … Y quieres hacer todo eso con una ducha, un lavabo, un WC… No quieres que te presenten diseños, conceptos y experimentos de nuevo lavabos. Quiero un lavabo donde salga agua a media altura y se vaya por el desagüe. Eso con el desarrollo de software no pasa. Lo que quiero aun no existe, porque si existiera simplemente lo compraría. Lo que quiero aún no lo sé. Solo sé más o menos lo que necesito solucionar con él, pero el cómo todavía no lo sé.

Ciclo de vida predictivo

Lo que hemos visto antes es el enfoque tradicional, llamado ciclo de vida predictivo. Aquí prima la capacidad de averiguar toda la información desde el inicio. Por parte del cliente a la hora de recoger requisitos, y por parte del proveedor a la hora de interpretarlos y plantear una solución.

Otro símil que me gusta más es el del jugador de golf. El proyecto consistiría en meter la pelota en el hoyo. De antemano el jugador de golf debería conocer todas las variables necesarias:

  • tamaño y peso de la pelota
  • diferencia de altura entre la pelota y el hoyo
  • longitud desde la pelota al hoyo
  • dirección y velocidad del viento
  • condiciones climatológicas

Una vez conocidas, el jugador calcula (planifica) el ángulo de tiro y la velocidad que debe imprimir a la pelota. En base a eso escoge el palo, calcula la altura y la fuerza del golpeo, se coloca y dispara.

Ciclo de vida adaptativo

Como en un proyecto, pese a todos los cálculos es muy poco probable que aciertes a la primera. Es fácil haber pasado por alto una variable (requisito no detectado), como la altura de la hierba. Además puedes haber medido mal un parámetro (requisito malinterpretado), como el tamaño de la pelota. También que hayas optado por un palo que no es el adecuado para el golpeo para largas distancias (mala decisión de diseño). O que directamente alguna variable haya cambiado por el camino (cambio de requisito), como la dirección del viento. Para colmo es posible que el cliente haya cambiado de opinión o de necesidades, y ahora haya decidido poner el hoyo 20 metros más alejado.

Como ves, en un entorno donde hay tanto cambio, acertar a la primera no es cuestión de pericia, es un puro milagro. Una vez que golpeamos, todo escapa a nuestro control y no podemos hacer nada para rectificar.

Ciclo de vida adaptativo

Ciclo de vida adaptativo

Por suerte existe una manera diferente de afrontar los proyectos, el llamado ciclo de vida adaptativo, el utilizado en las metodologías ágiles como Scrum o Kanban. En el enfoque adaptativo no se pone el foco en el plan de proyecto sino en el problema del cliente. La idea es hacer un primer análisis del problema a lo grande, dividirlo en trocitos e ir construyendo y repitiendo el análisis en cada trocito, de uno en uno. Así, tras acabar el primer trozo de proyecto nos paramos a reflexionar y a preguntar al cliente si le gusta lo que hemos hecho.

Aprendemos nosotros, de la respuesta del cliente, si nos acercamos a la solución de su problema o si estamos lejos y por qué. También aprende el cliente sobre su propio problema y nos da más pistas para una mejor solución. Repetiremos el ciclo de analizar, crear y volver a reflexionar las veces necesarias hasta que el cliente dé por solucionado su problema.

En el ejemplo del golf, sería el equivalente a montarnos en el carricoche, pararnos cada 50 metros a ver dónde se encuentra el hoyo, y cuando llegáramos a él meter la pelota con la mano. Quizás no tenga tanta gracia meterla con la mano que acertar con el palito desde lejos. También quizás puede que tardemos algo más y que gastemos algo más de combustible. Pero hay algo que sí es seguro. Las posibilidades de cumplir con las expectativas del cliente y conseguir el objetivo para el que nos contrataron serán mucho más altas.

Y tú, ¿qué enfoque elegirías si tuvieras que meter la pelota en el hoyo?¿Y para desarrollar un producto software?

Fotos: dronepicr y Antonio Cinotti bajo licencia cc

También te puede interesar...

Resumen Scrum by Jeff Sutherland Tenía muchas ganas de leer este libro. Ya no solo porque era leer sobre el framework Scrum que utilizo a diario en mi trabajo, sino porque me lo había...
Los 7 desperdicios LEAN del software (y II) Este post es la continuación al post anterior Los 7 desperdicios del desarrollo de software donde describía los primeros 3 desperdicios del desarrollo...
Resumen Clean Code Este verano he releído uno de los libros de referencia de todo buen programador. Se trata de "Clean Code", de Robert C. Martin (o más conocido como Un...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *