Durante años ha imperado dentro del desarrollo de software, el llamado modelo en cascada, que separa muy claramente y de forma secuencial las fases de desarrollo de software (https://es.wikipedia.org/wiki/Desarrollo_en_cascada): análisis de requisitos, diseño del sistema, diseño del programa, codificación, pruebas, implantación y mantenimiento.
Este tipo de desarrollo tiene muchos inconvenientes, y uno de los principales es que prácticamente desde el análisis de requisitos el contacto con el usuario final es mínimo. Para el cliente el proceso es básicamente una caja negra: digo lo que quiero, el equipo de desarrollo se pone a trabajar, y al final me entregan lo que he pedido.
Otro de los problemas importantes del modelo es su falta de adaptación al cambio. No se puede construir software rígido y estático, pensando que durante el propio proceso de construcción no se van a producir cambios en los requerimientos inicialmente recogidos.
El resultado final, es que el software desarrollado y entregado al cliente, no cumple las expectativas de los usuarios finales.
Este modelo que data de 1970, fue creado por Winston Royce. Lo paradójico del asunto, es que el propio Royce cuando postuló el modelo, argumentó los fallos y problemas que podría ocasionar, y sin embargo, por una parte las Universidades lo han estado enseñando (y de hecho lo siguen haciendo como válido) dentro de la Ingeniería del Software, y por otra la propia industria IT lo ha estado aplicando durante décadas.
En el año 2001 un grupo crítico a las metodologías clásicas de desarrollo, encabezados por Kent Beck, dió lugar a los que se conoce como “Manifiesto Ágil”, el cual expone que:
“Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
• A los individuos y su interacción, por encima de los procesos y las herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda”.
El objetivo claro es crear software que funcione y que cumpla las expectativas de los usuarios a los que va dirigido. Los principios del Agilismo los podemos detallar a continuación:
1. Satisfacer al cliente.
2. Aceptar cambios.
3. Trabajar como equipos.
4. Entregas frecuentes. El cliente tiene que comenzar desde estadios tempranos del proyecto a ver software que funcione.
5. Calidad excelente. Para ello las metodologías se apoyan en todo un conjunto de buenas prácticas como:
o Testeo unitario. El programador, antes incluso de desarrollar, especifica las pruebas que se deben realizar para que el software funcione. Es lo que se conoce como “Test-Driven Development” (TDD, Desarrollo Guiado por Tests).
o Integración contínua. No esperamos a tener todo terminado para generar la versión final y realizar las pruebas sobre ella, sino que regularmente se realizar integraciones automáticas del producto para detectar posibles fallos lo antes posible.
6. Mantener siempre el concepto de simplicidad.
7. Diseño evolutivo. En sucesivas iteraciones, se desarrolla y entrega el software hasta componer la imagen final esperada por el cliente.
8. Motivación.
9. Cara a cara. Importante la comunicación directa con los usuarios finales de la aplicación.
10. Retrospectivas. Tras cada entrega, el equipo reflexiona sobre aquellas cuestiones que han ido mal, para intentar mejorarlas, y aquellas que han ido, para persistir en ellas.
11. Medimos lo que llevamos hecho.
12. Paso sostenible.
Dentro de las metodologías ágiles una de las que más fuerza está cobrando en los últimos años es Scrum. Realmente, Scrum, no es ni un modelo ni una metodología, sino que se trata de más bien de un framework (marco de trabajo) para la construcción de proyectos complejos. Incluye un conjuntos de roles y artefactos, todos ellos dirigidos a cumplir con los doce principios del agilismo comentados anteriormente.
El proceso de trabajo de Scrum, lo define perfectamente la “Scrum Allianze” en http://www.scrumalliance.org/learn_about_scrum. Traduciendo literalmente (excepto la jerga propia de Scrum), la descripción del proceso que allí se nos hace es la siguiente:
• El propietario del producto (“product owner”) crea un lista priorizada de características deseables a ser incluidas en el producto final. Dicha lista priorizada se conoce como “product backlog”.
• El equipo dispone de una cierta cantidad de tiempo, llamado “sprint”, normalmente de dos a cuatro semanas, para completar su trabajo.
• Durante la planificación del “sprint”, el equipo selecciona un pequeño conjunto de características a implementar de la parte superior del “product backlog”, y decide como implementar esos elementos. La lista de cosas a desarrollar en un “sprint” se conoce como “sprint backlog”.
• Todos los días el equipo valora sus progresos en una reunión conocida como “daily scrum”.
• A lo largo del “sprint” el “ScrumMaster” mantiene al equipo centrado en sus objetivos.
• Al final del “sprint”, el trabajo debería ser potenciable entregable, preparado para instalar y ser usado por el cliente.
• El “sprint” termina con una revisión y una retrospectiva.
• Al comienzo del siguiente “sprint”, el equipo elige otro conjunto de elementos del “product backlog” y el trabajo comienza de nuevo.
• El ciclo se repite hasta que bastantes ítems en el “product backlog” se completan, el presupuesto se agota, o se alcanza la fecha de entrega. Cualquiera de los hitos que puedan marcar el final del trabajo, es específico de cada proyecto, pero lo que Scrum garantiza es que el trabajo más valioso se ha completado cuando el proyecto finaliza.
Una de las novedades introducidas por Scrum, es el uso de tableros “Kanban”, para el seguimiento de cada una de las tareas a realizar en cada iteración de desarrollo. Estos tableros ofrecen perfecta visibilidad a todos los miembros del equipo, incluso de otras áreas de la empresa, del estado actual de la iteración en curso.
Hoy en día, empresas como Toyota, Nokia, Google, Microsoft, Nike, IBM, Motorola, Vodafone, HP, etc., utilizan Scrum en sus procesos de desarrollo de software.
imagen: orcmid
Director de Desarrollo y Diseño I+D en Clavei. Posee certificación como Project Management Professional
Antonio buen trabajo de síntesis.
Para mi lo mas importante del método es la proximidad que da entre el equipo de desarrollo y el el cliente ya que tras la realización de la lista de necesidades el equipo interactua constantemente con el usuario para conseguir un resultado mas proximo a la propuesta inicial del cliente con las aportaciones del equipo de desarrollo.
Desde @clavei siempre se hablo de proximidad al cliente, no programar desde torres de cristal donde los programadores no ven su trabajo en funcionamiento.
Me ha gustado, me ha hecho recodar viejos tiempos, sigue así