Hola a todos! ¿Qué tal? Aquí estoy de nuevo para contar un poco más acerca del desarrollo de proyectos. Esta vez hablaremos del desarrollo ágil (de software o de cualquier otro proyecto).
Los enfoques más tradicionales de desarrollo de software, u otros productos e incluso servicios, se basan en un modelo secuencial de procesos. Lo que se conoce como desarrollo en cascada.
METODOLOGÍA TRADICIONAL EN CASCADA.
Este modelo viene de los años 70, y se aplicaba en un principio a la construcción y manufactura.
El modelo secuencial de procesos se basa en una serie de fases secuenciales de desarrollo. Es decir: El proyecto constaría de una fase A, luego una fase B, luego una C, y así hasta que termina y se entrega el producto al cliente.
Imaginemos que un cliente necesita un software con unas funcionalidades concretas y encarga el desarrollo a una empresa. El modelo en cascada seguido por esta empresa consistiría en:
1. Especificación de requerimientos del cliente. El cliente solicita el software, se especifican sus requerimientos, las funcionalidades deseadas, y se congelan. A partir de ahora se trabajará para ofrecer un producto final que cumpla con estos requerimientos congelados (es decir, no modificables, o poco modificables)
2. La empresa comienza a trabajar en el diseño. El cliente se aparta o se involucra bastante poco.
3. La empresa construye el software de acuerdo a los requerimientos del cliente
4. Se realizan pruebas, test
5. Implementación, o entrega. En esta fase, una vez probado, el cliente recibe la solución, el software. A partir de ahora ofrecerá feedback, ya que comienza a usarlo.
6. La empresa ofrece soporte y mantenimiento.
Problemas del modelo en cascada.
¿Qué inconvenientes creéis que podemos encontrar en la secuencia que acabo de describir?
El principal surge de la velocidad de cambios en el entorno. O para entenderlo mejor: en el paso 3 decía que la empresa construye el software en base a los requerimientos descritos en el paso 1 ¿verdad? Pues lo que suele suceder, es que para cuando llegamos a la fase 3, los requerimientos ya han cambiado. Por lo que el desarrollo no se realiza en realidad en base a lo que el cliente desea.
Otro problema derivado es que no termina de haber un “Product-Market Fit” porque al cliente no se le entrega nada hasta el final. Por tanto, éste no aporta feedback en el proceso. Esto es importantísimo eh? El feedback en el proceso es vital. Siempre debe haber feedback. Siempre. Claro que al no entregar nada, ¿cómo va a poder el cliente introducir feedback en el proceso?
METODOLOGÍA ÁGIL
Una metodología, enfoque o marco de trabajo ágil se caracteriza principalmente por involucrar al usuario-cliente en el proceso de desarrollo del producto, quien recibirá entregables (funcionalidades) desde el principio y de forma periódica, y retroalimentará (feedback) el proceso en cada iteración, para que se adapte a sus requerimientos en todo momento. Se llama “ágil” porque el proceso de desarrollo puede adaptarse con agilidad a cambios en los requerimientos del cliente durante el desarrollo.
Es decir, es una forma de desarrollar un proyecto mediante la cual:
- Desde las fases iniciales ya hay un producto funcionando (de forma limitada, pero funcionando y resolviendo)
- Existe una colaboración con el cliente desde el principio hasta el final. No se trata de un cliente que encarga un producto a una empresa y espera a recibirlo, o lo que es lo mismo, una empresa que desarrolla un producto para un cliente que espera, sino que se trata de un proceso en el que ambos trabajan juntos y colaboran en el desarrollo. El cliente con su feedback, y la empresa con su desarrollo y adaptaciones.
- Es trasversal, es decir, no es un proceso que tiene fases y al acabar se termina el proyecto, sino que se trata de una versión del proceso que se repite. En vez de desarrollar la fase A, luego una fase B, luego una fase C, se entrega y termina el proyecto, se hará un ciclo que incluye “un poco” de fase A, otro de fase B y otro de C. Se entrega y se vuelve a empezar, con otro poco de cada, y así sucesivamente. Estos ciclos reciben el nombre de iteración. Cada iteración finaliza con un entregable que genera feedback.
Imaginemos que un cliente necesita un software con unas funcionalidades concretas y encarga el desarrollo a una empresa. Un marco de trabajo ágil consistiría en:
1. Cliente y desarrollador se reúnen para descubrir los requerimientos del cliente. Estos requerimientos se traducen en funcionalidades que se plasman en un backlog.
2. El Equipo de Desarrollo selecciona de todas las funcionalidades y requerimientos, una combinación formada por algunos de los ítems, y que en su conjunto aporta valor. Es decir, un producto mínimo que puede funcionar por sí solo.
3. El equipo lo construye y lo entrega al cliente.
4. Éste aporta feedback, y en base a ello, se seleccionan las nuevas funcionalidades a incorporar a una versión más extendida. Estas nuevas funcionalidades se seleccionarán de las que quedan en el backlog, aunque el cliente puede incorporar nuevas, o realizar cambios.
5. El equipo construye y entrega de nuevo
6. Y así sucesivamente, iterando por ciclos, hasta llegar al producto final.
Ves? Totalmente diferente!
COMPARATIVA DE AMBOS MARCOS.
Ahora voy a hacer una comparativa de ambos métodos con un ejemplo:
Vamos a imaginar que somos una empresa a la que se nos encarga un proyecto de construcción de un aeropuerto.
- Metodología en Cascada:
1. Tras varias reuniones con el cliente, elaboramos una documentación que encaja con los requerimientos del cliente: el aeropuerto tendrá tres pistas (una de ellas pequeña para aviones de menor tamaño), dos hangares, una torre de control, y el edificio principal para pasajeros.
2. Diseñamos el proyecto
3. Construimos el aeropuerto: las obras comienzan con las obras del edificio principal de pasajeros, luego se une al trabajo las obras de las tres pistas a la vez, luego empiezan las obras de la torre de control y por último los hangares.
4. Una vez construido se entrega al cliente, y se inaugura.
5. Por último, la fase de mantenimiento y soporte. En esta fase recibimos una llamada importante del cliente (feedback). Necesita reunión urgente… Resulta que probando el aeropuerto se ha dado cuenta de que con los cambios de viento, no siempre pueden despegar y aterrizar en la orientación de las tres pistas, de este a oeste, o viceversa. Necesita que una de las dos pistas mayores esté orientada de Norte a Sur o viceversa, y que admita aviones grandes y pequeños. ¿Cómo? ¡Pero si ya está todo construido! Creo que va a ser cariiiiisimo.
- Metodología Ágil
1. Tras varias reuniones con el cliente, elaboramos un product backlog en el que establecemos junto con el cliente, cuáles son las funcionalidades requeridas. Además estarán ordenadas por prioridad. Necesita tres pistas, dos mayores y una menor, una torre de control, dos hangares, y un edificio para pasajeros.
ITERACIÓN 1
Iteración 1. Diseño: El Equipo de Desarrollo se reúne y selecciona del product backlog, las funcionalidades mínimas que combinadas ofrezcan valor al cliente. Lo que se llama un Producto Mínimo Viable, con “Minimun Marketable Features”. En este caso, establecemos (según las prioridades de los ítems del backlog) crear una pequeña parte del edificio de pasajeros que pueda funcionar por sí sola, la pista menor para aviones pequeños, y la parte más básica de la torre de control. Ya tenemos desarrollada la iteración 1.
Iteración 1: Construcción: el Equipo de desarrollo construye lo diseñado en el anterior punto
Iteración 1: Entrega. Hacemos una entrega al cliente para que ya pueda operar con aviones pequeños en la pista menor.
ITERACIÓN 2
Iteración 2. Diseño: El cliente ofrece feedback, y nos comenta que, debido al viento, una de las dos pistas que quedan por construir debería tener orientación Este-Oeste, pero la otra Norte-Sur. Cambiamos el backlog, y diseñamos la nueva iteración
Iteración 2: Construcción: Construimos lo diseñado para esta iteración: ampliación de la torre, ampliación del edificio de pasajeros, uno de los hangares, y la pista Norte-Sur.
Iteración 2: Entrega. Realizamos la segunda entrega.
Iteración 3. Diseño: El cliente aporta nuevo feedback y …. etc etc.
Iteración 4.
Iteración 5.
…
Producto Terminado!
¿Ves? Hemos evitado cambiar todo el proyecto cuando ya estaba construido, porque el cliente ofrece feedback desde el principio. Y porque el cliente USA versiones del producto desde el principio.
IMPORTANTE: El Equipo de desarrollo siempre debe seguir pautas de selección de características o funcionalidades de forma que aporte valor agregado. Es decir, desde la iteración 1, el resultado debe ser un entregable que aporte valor. La siguiente iteración consistirá en agregar valor al primer resultado, etc etc.
Por ejemplo, si construimos un coche, en la iteración 1 no podemos entregar las ruedas, o el capó o la estructura. Debemos entregar un monopatín. Que luego convertiremos en un triciclo, que después será un kart, y finalmente será un coche.
La metodología ágil no sólo es aplicable al desarrollo de proyecto (como acabo de exponer). También es aplicable a la parte estratégica, como por ejemplo al emprendimiento, innovación de modelos de negocios, desarrollo de clientes, etc.
Un ejemplo de marcos de trabajos ágiles para el desarrollo de proyectos es SCRUM.
Un ejemplo aplicado al emprendimiento es Lean Startup
También el Desarrollo de Clientes de Steve Blank (detallado en su libro "El manual del emprendedor")
Ejemplos de herramientas ágiles son el Business Model Canvas, o el Value Proposition Canvas, de Alexander Osterwalder.
Abrazo!
VOLVER
VER MÁS POSTS
0 comentarios