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 User Stories Applied de Mike Cohn ¿Qué es una historia de usuario?¿qué elementos debe cumplir?¿cómo se crean? El libro User Stories Applied de Mike Cohn nos da respuesta a éstas y c...
Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...

Dejar un comentario

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