Você está na página 1de 5

-Aplicación de asignación de requerimientos

- Scrum: un Framework para mejorar la


calidad de software
por Antonio de Rojas | Jul 4, 2011 | software | 2 Comentarios

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 (http://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

Você também pode gostar