Está claro lo que es, verdad?, pues no, parece que no todo el mundo lo tiene claro.
La mayoría de los casos que veo son desarrollo de aplicaciones en las que se saca un producto de negocio, normalmente aplicando waterfall.
Con los nuevos marcos como Scrum se mejoran muchas cosas, el feedback del cliente, abordar nuev
as necesidades sin haber acabado, etc.., pero creo que uno de los objetivos principales de los enfoque ágiles no se consigue, y esto es obtener valor para el negocio lo antes posible. Y creo que esto no ocurre porque faltan personas que piensen bien al principio sobre la concepción inicial del producto.
Alistair Cockburn en el curso que organizó Javier Garzás sobre Agilidad avanzada, nos planteó un ejemplo a desarrollar, el Carpaccio, dónde pudimos comprobar cómo se pueden hacer historias más pequeñas que aporten valor real de negocio desde las primeras iteraciones. En la mayoría de los planteamientos agiles de las grandes compañías eso no está ocurriendo, se está haciendo un iterativo-incremental sin más.
Me he encontrado con historias de usuario que abordaban el caso típico de varios canales y que intentaban desarrollar todo en una única iteración, lo que ocurría es que había que trasladar esas historias a otras iteraciones posteriores. No se planteaban cuál era el canal más rentable para el negocio y desarrollar ese canal en una iteración corta para ponerlo en producción cuanto antes. Sobre esto de dividir las historias hay artículos muy buenos pero el otro día mi trainer de la Scrum Alliance, Carlton E. Nettleton, me propuso uno muy bueno de Richard Lawrence que aporta bastante claridad.
Creo que el concepto de Incremento de Producto Potencialmente Consumible, se queda en Incremento de Producto y que cuando está todo acabado entonces se pone en Producción. Y si hacemos esto, es porque no hemos hecho un buen análisis inicial de los objetivos y del valor de negocio que aportan.
Necesitamos buenos Product Owners que conozcan el negocio y que conozcan las técnicas a aplicar.
Necesitamos pensar!
en el desarrollo de productos se utiliza la métrica de «Cost delay» que es el costo de retraso cuando se hacen colas de componentes por desarrollar o ya desarrolladas y que se quedan formando el inventario de «WIP: Work in progress». En el desarrollo tradivional se trata de minimizar el costo de la capacidad (en el caso de desarrollo de software serían los desarrolladores) aumentando la eficiencia al máximo. Esto es, ocupar los recursos al 100% o lo más posible con tareas de desarrollo. De acuerdo a la ley de Little en teoría de colas, una variación en la capacidad (menos personas de desarrollo) o en la demanda (nuevos requerimientos, bomberazos, problemas de producción, corrección de bugs, etc.) afecta el crecimiento de las colas y por lo tanto el incremento en los tiempos de entrega dependiendo del nivel de ocupación de la capacidad. Medir el costo de retraso de liberar un componente (o historia) es una buena manera de ponderar cada historia en la cola del backlog y lo que nos da un indicador del valor al negocio de cada componente. Donald G. Reinertsen tiene varios libros dedicados a ese tema: «Managing the design factory» y «The Principles of Product Development FLOW» donde insiste en medir el impacto económico del desarrollo de productos (que bien se puede aplicar al desarrollo de software).