Historia

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales.^[1] Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual las fases se traslapan de manera intensa y el proceso completo es realizado por un equipo con funciones transversales, con el rugby, donde el equipo entero «actúa como un solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro».^{[cita requerida]}Los casos de estudio provienen de las industrias automovilísticas, así como de fabricación de máquinas fotográficas, computadoras e impresoras.

En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous Solutions (A problemas malvados, soluciones virtuosas),^[2]se refirieron a esta aproximación como scrum (melé en inglés), un término propio del rugby mencionado en el artículo por Takeuchi y Nonaka.

A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a poner en práctica el scrumen su compañía, Advanced Development Methods.^{[cita requerida]}Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla scrum.^[3] En 1995 Sutherland y Schwaber, durante el OOPSLA '95 desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo scrum, siendo ésta la primera aparición pública de la metodología.^{[cita requerida]} Durante los años siguientes, Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a lo que ahora se le conoce como scrum.^{[cita requerida]}En 2001, Schwaber y Mike Beedle describieron la metodología en el libro Agile Software Development with Scrum.

Características de Scrum

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o internos), y el Teamque incluye a los desarrolladores.

Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.^[4] Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Scrum ha estado durante algún tiempo en los círculos orientados a objetos, aunque confesaré que yo no estoy muy al tanto de su historia o desarrollo. De nuevo se enfoca en el hecho de que procesos definidos y repetibles sólo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles.

Scrum divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 días. Antes de que comience una carrera se define la funcionalidad requerida para esa carrera y entonces se deja al equipo para que la entregue. El punto es estabilizar los requisitos durante la carrera.

Sin embargo la gerencia no se desentiende durante la carrera corta. Todos los días el equipo sostiene una junta corta (quince minutos), llamada scrum, dónde el equipo discurre lo que hará al día siguiente. En particular muestran a los bloques de la gerencia: los impedimentos para progresar que se atraviesan y que la gerencia debe resolver. También informan lo que se ha hecho para que la gerencia tenga una actualización diaria de dónde va el proyecto.

La literatura de Scrum se enfoca principalmente en la planeación iterativa y el seguimiento del proceso. Es muy cercana a las otras metodologías agiles en muchos aspectos y debe funcionar bien con las prácticas de código de la XP.

DESARROLLO MANEJADO POR RASGOS

El Desarrollo Manejado por Rasgos (FDD por sus siglas en inglés) fue desarrollado por Jeff De Luca y el viejo gurú de la OO PeterCoad. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran dos semanas.

El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

• Desarrollar un Modelo Global
• Construir una Lista de los Rasgos
• Planear por Rasgo
• Diseñar por Rasgo
• Construir por Rasgo

Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación.

Los desarrolladores entran en dos tipos: dueños de clases y programadores jefe. Los programadores jefe son los desarrolladores más experimentados. A ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen solos. Solo identifican qué clases se involucran en la implantación de un rasgo y juntan a los dueños de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe actúa como el coordinador, diseñador líder y mentor mientras los dueños de clases hacen gran parte de la codificación del rasgo.

Hasta recientemente, la documentación sobre FDD era muy escasa. Finalmente hay un libro completo sobre FDD. Jeff De Luca, el inventor primario, ya tiene un portal FDD con artículos, blogs y foros de discusión. La descripción original estaba en el libro UML in Color de Peter Coad et al. Su compañía, TogetherSoft, también da consultoría y entrenamiento en FDD.

Metodología De Trabajo

Equipos de entre 6 y 10  personas   revisan los requisitos, la tecnología disponible y evalúan los conocimientos para Colectivamente determinar como incrementar la uncionalidad.

* Reuniones diarias, antes de empezar a trabajar,con una duración máxima de 4 hrs.

* Se llevan a cabo hasta que el proyecto este   listo  para ser puesto en producción o ser lanzado     al  mercado.

EL  FLUJO  SCRUM

 Ver Documento Pdf                  Ver Documento Ppt