La raíz del problema es que, como es natural, queremos hacer nuestro trabajo bien, y si es posible queremos que quede perfecto :-), y además hacerlo así "a la primera". Pero mientras más complejo sea el trabajo enfrentado más difícil será conseguir esa perfección a la primera (si dicha perfección existe y es posible alcanzarla). Una de las leyes de Murphy dice: "Se demuestra que todo sistema complejo que funciona ha evolucionado a partir de un sistema simple que funciona". En mi opinión, para un plazo concreto la perfección debe tomarse como una referencia, el objetivo en un plazo establecido debería ser dar un paso hacia esa perfección.
Llevemos estas ideas al terreno de desarrollo de software. El software, por su naturaleza, puede incluir características de forma casi ilimitada, me refiero a que el cliente nos puede pedir infinidad de funcionalidades o restricciones que debería considerar el producto resultante. Además, el mantenimiento del software dista mucho del mantenimiento en otras ingenierías, en las cuales se trata de básicamente de supervisar medidas, y ajustar, reparar o cambiar componentes, todo ello sin alejarse casi nada de las especificaciones originales. En ingeniería de software el producto actual puede diferir enormemente de la primera versión puesta en producción. Por otra parte, todo producto software exitoso requerirá mantenimiento, ya que ese éxito posiblemente conllevará más uso, más mejoras, nuevos requisitos, integraciones, adaptaciones, etc. En este contexto, ¿somos capaces de anticipar con precisión y acierto qué especificación tendría nuestro producto después de meses o años de su primera puesta en producción?, es más, ¿valdría la pena intentar este ejercicio de predicción?.
Obviamente, la experiencia en el dominio, en la tecnología, en el trabajo con el mismo equipo, etc. son factores que pueden favorecer dicha predicción y facilitar una rápida y acertada especificación del producto. Pero en desarrollo de software estos factores no suelen estar de nuestra parte, es más, son más bien factores de riesgo.
Además, lamentablemente en muchos equipos de desarrollo de software está muy institucionalizado el desempeño de roles de forma exclusiva, por ejemplo, personas que sólo analizan, personas que solo programan, etc. Los especialistas siempre serán bienvenidos, pero cuando no pueden realizar más que su especialidad, es muy difícil balancear la carga de trabajo de los integrantes del equipo. Si a esto le sumamos que, por ejemplo, los analistas no pueden/quieren pasar trabajo a los programadores hasta tenerlo todo bien definido, ya tendríamos que estar pensando en darle vacaciones a los programadores :-) o que éstos, mientras no reciben trabajo, estén haciendo otras tareas que posiblemente no sea escribir código del producto que estamos desarrollando.
Pero tampoco parece conveniente pasar trabajo a programación con muy poca o ninguna especificación, lo cual podría ocasionar demasiado re-trabajo.
La respuesta a este dilema, tal como se muestra en la siguiente figura es utilizar una estrategia MVP (Minimun Viable Product). MVP es un concepto proveniente de Lean Startup, el cual potencia enormemente un proceso de desarrollo iterativo e incremental. El concepto MVP es el punto en el cual un enfoque ágil y Lean Startup se complementan.
Como se observa, entre los dos extremos: Analisis-Parálisis y el lanzarse al vacío (piscina sin agua), podemos encontrar un punto de equilibrio basado en un desarrollo incremental de la definición del producto y de su implementación. Esto no debe interpretarse como una renuncia a la precisión de la especificación o del alcance del producto, tampoco como una resignación a conseguir un producto de menor calidad. El MVP es una estrategia, un camino para dirigirse al producto deseado.
La estrategia MVP tampoco significa dejar de planificar ni abandonar la gestión de alcance del proyecto (lectura recomendada: "Gestión de alcance en un proyecto ágil"), al contrario, en una estrategia MVP no solo planificamos más y más frecuentemente, sino que todo el equipo vive el plan y su seguimiento. La gran diferencia es que mantendríamos dos visiones de la planificación y gestión de alcance, una muy detallada a corto plazo (Sprint actual y el próximo) y otra menos detallada a largo plazo (la duración de la próxima entrega o del proyecto completo). Por esto la priorización del trabajo es clave ya que la definición detallada del trabajo solo se considera urgente para el trabajo más prioritario (el que se abordará en el próximo Sprint).
Uno de los principales temores de un enfoque de desarrollo iterativo e incremental, y especialmente cuando se lleva a cabo con una perspectiva MVP es que estaremos condenados a realizar mucho refactoring. Refactoring se refiere al trabajo de cambiar el código sin añadir nueva funcionalidad. El propósito del refactoring es conseguir que el código sea más fácil de mantener, probar y/o reutilizar. El refactoring es importante para asegurar que no acumulemos Deuda Técnica, es decir, que la arquitectura de nuestro producto se vaya degradando y cada vez resulte más caro mantenerlo ("pagando los intereses de dicha deuda"). Sin embargo, hay que diferenciar entre añadir código asociado al incremento de funcionalidad (esto NO es refactoring) y los cambios de código que no aportan nueva funcionalidad (esto SÍ es refactoring). Marcando esta diferencia deberían reducirse dichos temores. En general si el código se va construyendo incrementalmente siguiendo buenas guías de arquitectura, no deberíamos esperar refactoring de gran magnitud. También ayuda mucho el hecho de comenzar los primeros Sprints de un producto nuevo con las funcionalidades más importantes o que aportan más valor al cliente, pues suelen ser éstas las que determinan en mayor medida las decisiones de arquitectura.
Una estrategia iterativa e incremental basada en MVP puede aplicarse a cualquier nivel donde tengan que tomarse decisiones de especificación y alcance:
- Nivel de portafolio de proyectos, para seleccionar los proyectos que se deberían especificar con más detalle pues son más prioritarios y se pondrán en marcha ya, y cuáles podrían esperar.
- Nivel de características del producto/servicio que abordará un proyecto, para acotar las características o requisitos que se deberían especificar en detalle e implementar en cada incremento, y cuáles requisitos podrían esperar para ser especificados en más detalle más adelante.
- Nivel de sofisticación o completitud de un requisito, para acotar qué aspectos del requisito se deberían especificar e implementar en cada incremento durante su desarrollo. Especialmente cuando se trata de un requisito "grande" (una Épicas), y solo cuando ha llegado el momento de implementarla, al menos parcialmente.
Finalmente, la estrategia planteada nos llevará a negociar con la parte cliente un alcance más selectivo y menos ambicioso para cada entrega (MVP). Y luego, cuando se haga efectiva una determinada entrega puede que nos sorprendamos con que la parte cliente ha descubierto que la versión de MVP que ha obtenido es suficiente o que prefiere postergar la continuación de su desarrollo pues ya no le parece tan prioritario el resto. Esta situación puede ser vista como una amenaza para el proveedor (quien esperaba continuar desarrollando inmediatamente el resto del producto). Sin embargo, visto de forma positiva, el cliente y el proveedor pueden acordar dedicar a otros proyectos la financiación ahorrada :-). Efectivamente, esto un punto importante a considerar para los proveedores pues tienden a preferir contratos "grandes" y a largo plazo. Pero desde el punto de vista del cliente la estrategia MVP ofrece una gran ventaja respecto de la rentabilización de su inversión en un proyecto. Así pues, como contraparte, el proveedor puede aprovechar la estrategia planteada como una oportunidad para alinearse con los intereses de su cliente y conseguir a su favor una mayor fidelización de su cliente.
Otros posts relacionados:
- 8 consejos para realizar una gestión ágil de requisitos
- "Bueno, bonito y barato", ¿puede conseguirse esto con un método ágil?
- Gestión ágil de requisitos o ¿cuál y cuánta documentación/especificación es suficiente?
Patricio Letelier
Pensar demasiado nos puede llevar a la parálisis por análisis. También puede ocurrir, por el contrario, que nos embarquemos en demasiados proyectos, que hagamos demasiadas cosas...Conviene centrarse, al respecto.
ResponderEliminar