EcuRed - Contribuciones del colaborador [es]

Chaabi

2020-02-04T22:17:34Z

Youfaska: añadir infomacion sobre musica y festivales relacionadas con el Chaabi Marruecos

{{Ficha de Género Musical
|nombre='''Chaabi'''
|imagen=Chaaabi.jpg
|orígenes_musicales=
|orígenes_culturales= Chaabi se refiere a varios tipos de música popular de [[Marruecos]], combinando música folclórica rural y urbana.
|instrumentos=
|popularidad= Principalmente en {{Bandera2|Marruecos}}
|derivados =
|subgéneros=
|fusiones=
|géneros_regionales =
|enlaces =
}}
'''Chaabi'''. Musica tradicional popular en '''Marruecos''' y con una danza muy bailable.
== Origen ==
El género comenzó como [[música]] de [[calle]] en [[plazas]] y zocos, y se puede escuchar en [[cafeterías]], [[restaurantes]] y [[bodas]]. Las variedades rurales incluyen Jerra y al-Aïta.

== Significado del nombre ==
Chaâbi, el término, significa «popular», «del pueblo» y no está solo presente en [[Egipto]]. Chaabi se refiere a distintas formas de «música de celebración» para bodas y enlaces familiares.
== Popularidad ==
Se extiende prácticamente por todo el norte de [[África]]: [[Marruecos]], [[Argelia]] y [[Egipto]] tienen su propio dialecto a partir de esta tradición, y en dichos terrenos es tan popular como el Raï argelino o comparable a la danza Dabke (más propia de Oriente Medio, [[Líbano]], [[Siria]], [[Jordania]], [[Israel]] o [[Palestina]]).
== Ritmo ==
De fuerte ritmo, acompaña a los bailes.Se interpreta en numerosos festivales a lo largo del país, en las zonas rurales se le denomina Aita , que varia según las zonas, Es típico del norte la música “El Aita Jebali “ un estilo de [[música]] y [[danza]] que se originó en las montañas del norte de [[Marruecos]], en el [[siglo XVIII]]. relacionado con las costumbres de los moriscos de Al Andalus. arte que destaca por el cante, el toque y el [[baile]], un patrimonio en peligro de desaparición, celebra su Festival en Taounate.
Hay una Música Aita, típica de la costa entre [[Casablanca]] y Safi, nostálgica que expresa el estado de ánimo, celebrándose su [[Festival Nacional en Safí]].

== Fuentes ==
*[https://www.guiademarruecos.com/consejos-viajar-marruecos/musica-y-bailes-tradicionales-marroquies/ musica-y-bailes-tradicionales-marroquies]

* [https://viajar-a-marruecos.org/festivales-en-marruecos/ Festivales y musica en Marruecos]
[[Categoría:Géneros musicales]]
[[Categoría:Tradiciones]]

Metodología Scrum

2019-03-25T18:33:59Z

Youfaska: añadir una referencia

{{Ficha Software
|nombre=El modelo Scrum
|familia=
|imagen=Scrum.jpeg
|tamaño=
|descripción=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.
|imagen2=
|tamaño2=
|descripción2=
|creador=Ikujiro Nonaka e Hirotaka Takeuchi
|desarrollador=
|diseñador=
|modelo de desarrollo=
|fecha de creación=Años 80'
|lanzamiento inicial=
|versiones=
|última versión estable=
|núcleo=
|tipo de núcleo=
|plataformas soportadas=
|género=
|sistemas operativos=
|idioma=
|licencia=
|premios=
|web=
}}
<div align="justify">
'''Scrum ''' es una [[Metodologías Ágiles|metodología]] ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka.

== 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. 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, como en el [[rugby]], donde el equipo entero «actúa como un sólo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro». 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), 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 scrum en su compañía, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla scrum.

En [[1995]] Schwaber y Sutherland, durante el OOPSLA '95 desarrollado en [[Ciudad Austin|Austin]], presentaron en paralelo una serie de artículos describiendo scrum, siendo ésta la primera aparición pública de la metodología. 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. 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 Team que 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. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.

Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. 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.

== Roles en Scrum ==

En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. El nombre de los grupos están inspirados en el chiste sobre un cerdo y una gallina que se relata a continuación. Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La [[gallina]] piensa un poco y contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el [[cerdo]], "Tú sólo estarías involucrada mientras que yo estaría comprometido". De esta forma, los 'cerdos' están comprometidos a través de sus aportes 'directos' en la construcción de software, mientras que las 'gallinas' están involucradas a través de sus aportes 'indirectos'. Las necesidades, deseos, ideas e influencias de los roles 'gallina' se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum. 

=== Roles "Cerdo" ===

Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato".

=== Product Owner ===

 El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog. 

=== ScrumMaster (o Facilitador) ===

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. 

=== Equipo ===

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc). 

=== Roles "Gallina" ===

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint. Análisis de la frase "Rol gallina": La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero. 

=== Usuarios ===

Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software no es usado ¿fue alguna vez escrito?. Stakeholders (Clientes, Proveedores, Inversores) Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint. 

=== Managers ===

Es la gente que establece el ambiente para el desarrollo del producto. 

== Reuniones en Scrum ==

=== Daily Scrum ===

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas: · La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc) · Todos son bienvenidos, pero sólo los "cerdos" pueden hablar.

La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo. · Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta) · La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días. Durante la reunión, cada miembro del equipo contesta a tres preguntas:· ¿Qué has hecho desde ayer? · ¿Qué es lo que estás planeando hacer hoy?· ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos). 

=== Scrum de Scrum ===

Cada día normalmente después del “Daily Scrum” · Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración. · Asiste una persona asignada por cada equipo. La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas: · ¿Qué ha hecho tu equipo desde nuestra última reunión? · ¿Qué hará tu equipo antes que nos volvamos a reunir? · ¿Hay algo que demora o estorba a tu equipo? ·

¿Estás a punto de poner algo en el camino del otro equipo? Reunión de Planificación del Sprint (Sprint Planning Meeting) Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo. · Seleccionar que trabajo se hará · Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo. · Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint · Ocho horas como límite Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint” 

=== Reunión de Revisión del Sprint (Sprint Review Meeting) ===

 · Revisar el trabajo que fue completado y no completado · Presentar el trabajo completado a los interesados (alias “demo”) · El trabajo incompleto no puede ser demostrado · Cuatro horas como límite 

=== Retrospectiva del Sprint (Sprint Retrospective) ===

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas. 

== Documentos ==

=== Product backlog ===

El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI) . Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto. 

=== Sprint backlog ===

El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. 

=== Burn down ===

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos. 

== [[Image:Proceso scrum.JPG|border|right|300x250px|Visión General del Proceso Scrum]] Scrum aplicado al desarrollo de software ==

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en [[1993]] en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En [[1996]] lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en [[2001]] serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son: · Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados. · Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento. · Reuniones: Planificación del sprint, Revisión diaria, Revisión del sprint. · Sprint

== Referencias ==

*(PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams Retrieved March 15, 2007 * (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process Retrieved July 01, 2010 * (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google Retrieved 2007-12-15 * (video) Ken Schwaber in Scrum et al. Retrieved 2008-01-19
*Para más información en [https://cafe-agil.com/ café ágil] hay mucha informacion sobre marcos de y metodos de trabajo agil como Scrum y Kanban
*Introducción a Kanban de la mano de un [https://jeronimopalacios.com/kanban/ trainer oficial de Lean Kanban University]

== Fuentes ==
* [http://www.proyectosagiles.org/que-es-scrum/ Proyectos Ágiles]

* [http://www.chuidiang.com/ood/metodologia/ scrum.php]

* [http://www.scrum.es/]

* [http://es.wikipedia.org/wiki/ Scrum Wikipedia]

* [http://www.navegapolis.net/ Navegapolis]

[[Category:Informática]]
[[Category:Metodologías_de_desarrollo_de_software]]

Fiestas tradicionales de Marruecos

2019-03-18T21:44:43Z

Youfaska:

{{Fiestas_tradicionales|nombre=Fiestas tradicionales de Marrueco|imagen=marroquitooo.jpg
|descripcion=Fiestas tradicionales|}}
<div align="justify">
'''Fiestas tradicionales de Marrueco '''. No hay duda de que cada nación tiene sus propias ocasiones de celebrar, de expresar su felicidad y su deseo de preservar su patrimonio, y la sociedad marroquí también celebra muchos acontecimientos para llevar a cabo ese propósito. Estas celebraciones tienen un elemento simbólico en el cual se puede apreciar una fusión perfecta entre la simbología islámica y la amazigh.

En Marruecos hay varios tipos de celebraciones. Están las celebraciones religiosas, las Fiestas Nacionales, los Moussems y los Festivales.
Las celebraciones religiosas no tienen fecha fija, ya que se rigen por la hejira, el calendario islámico, basado en el calendario lunar, y no coincide con el gregoriano (tiene alrededor de 11 días menos).
==Principales festejos==
*enero
Año Nuevo – 1° de Enero – Fiesta Nacional.
Manifiesto de la Independencia – 11 de enero - Fiesta Nacional de Marruecos. Se conmemora la presentación del Manifiesto de la Independencia, reclamando la soberanía nacional.
*febrero
Fiesta de los Almendros, en el valle Ameln. Se celebra los últimos días del mes, cuando florecen los almendros, en todos los pueblos de los valles. Hay cantos, bailes y danzas típicas.
*marzo
International Nomads Festival, en M'hamid. La celebración tiene dos epicentros: uno a 20 km del pueblo de Beni Mellal, en un campamento especialmente construido para la ocasión, y el otro en el pueblo mismo. Dura cuatro días y llegan artistas de todas partes del mundo.
*marzo-abril
(de acuerdo al calendario musulmán, no tienen fecha fija)
Festival de Moulay Aisaa Ben Driss, en Beni Mellal.
International Nomads Festival, en M'hamid. La celebración tiene dos epicentros: uno a 20 km del pueblo de Beni Mellal, en un campamento especialmente construido para la ocasión, y el otro en el pueblo mismo. Dura cuatro días y llegan artistas de todas partes del mundo.
Moussem of Sidi Abdallah ibn Hassoun, en Salé. Consiste en una procesión que dura entre 3 y 4 horas, portando velas hacia la Gran Mezquita.
*mayo
Fiesta del Trabajo – 1° de Mayo – Fiesta Nacional.
Festival de las Rosas, en Kelaat Mgouna (Valle de Dades). Coincide con la recolección de las Rosas de Damasco. Durante la fiesta hay danzas, cantos y lluvia de pétalos.
Festival de Música del desierto, en la región de Tafilalet. Dura una semana y se presentan artistas de Arabia y África. La música es variada, desde el blues a composiciones folklóricas tradicionales. Se celebra en las ciudades de Rachidia, Rissani y Meknes en los últimos días del mes.
TANJAzz, Tánger. Es en los últimos días de mayo y participan importantes músicos de Estados Unidos y Europa.
*junio
Festival de arte, Marrakech.
Festival de Jerez, Sefrou.
Festival de Músicas sacras, Fez. Uno de los más populares de Marruecos. Dura nueve días y muchos de los espectáculos son gratuitos. Se presentan artistas de todo el mundo.
Moussem Moulay Abdeslam, Larache.
Moussem de las Cerezas, Sefrou.
Festival de Músicas Étnicas, Essaouira.
Moussem Ben Aïssa, Meknes. Uno de los moussems más tradicionales. Es la reunión anual de la Hermandad Aïssoua. Dura varios días.
*Julio
Fiesta del Trono – 30 de Julio – Fiesta Nacional. Se conmemora la ascensión al trono del Rey Mohammed VI. La fiesta principal se realiza en el palacio, pero hay festejos en todas las ciudades y pueblos del país.
Festival del Camello, Guelmim. Transformado en una atracción turística, conserva sin embargo reminiscencias del festival original ya que todavía se danza la Guedra, en la que una mujer baila al son de un tambor. Se considera una ofrenda a Dios.
Festival de la Miel, Agadir.
Festival de Artes Populares, Marrakech. Del 14 al 19 de Julio. Se trata de una representación artística relacionada con las más profundas raíces culturales marroquíes: música bereber, danzas de los Atlas, música hipnótica del sur de Gnaouas, danza del vientre.
Festival Montreux de Jazz, Marrakech. 28 de Julio.
Festival Cultural Internacional, Asilah. Se ha celebrado durante los últimos 30 años y se presentan personalidades de la cultura mundial.
*agosto
Fiesta de Marruecos del Rey y del Pueblo – 20 de agosto – Fiesta Nacional. Conmemora el regreso al trono del rey Mohammed V, como resultado de la rebelión popular contra el rey impuesto por Francia, y por la liberación de Argelia y Túnez.
Fiesta de la Juventud – 21 de agosto – Fiesta Nacional.
Moussem Setti Fatma, valle de Ourika. Dura 4 días.
Moussem Moulay Abdallah, al sur de El Jadida.
Moussem Moulay Driss Zerhoun, al norte de Meknes.
*septiembre
Moussem Sidi Moussa Ou Quarqour, cerca de Kelaat-Seraghna, al norte de Marrakech. Porcesiones en honor del santo, hijo del Padre Fundador de Marruecos y creador de Fes.
Fiesta del Caballo, Tissa.
Festival de Marreucos Imichil. Esta fiesta dura 3 días. Tradicionalmente, es el momento en que los jóvenes solteros de ambos sexos de la región se reúnen en busca de pareja, como en una multitudinaria cita a ciegas. Su origen es legendario y recuerda a dos jóvenes de diferentes tribus que, habiéndose enamorado, no pudieron unirse por prohibiciones familiares. Su tristeza fue tal que lloraron hasta morir, dando origen a los lagos Issly y Tisslit.
*octubre
Mousses Moulay Idriss II, Fez
Festival de los Dátiles, Erfoud
*noviembre
Aniversario de la Marcha Verde – 6 de noviembre – Fiesta Nacional. Conmemoración de la marcha iniciada el 6 de noviembre de 1975 por ciudadanos y soldados marroquíes, bajo las órdenes del Rey Hassan II, con el fin de invadir y anexar el Sahara Occidental.
Fiesta de Marruecos de la Independencia – 18 de noviembre – Fiesta Nacional. Es la conmemoración del día en que el rey Mohammed V proclamó oficialmente la independencia de Francia y España, obtenida el 2 de marzo de 1956.
*diciembre
Festival de Marruecos Internacional de Cine, Marrakech. Se presentan más de 100 filmes en una semana. Atrae a grandes figuras de Hollywood cada año desde su creación en el 2001.
==Fuentes==
*http://www.turismomarruecos.net/cultura/festividades.html
*http://www.maroc.ma/es/content/fiestas-nacionales-y-religiosas
*http://tourpormarruecos.com/viajes-tematicos/fiestas-festivales-y-eventos-marroquies/
*http://www.marhabaviatges.com/es/Calendario-marruecos-ramadan-festividades-dias+festivos+marruecos+marruecos+calendario+2011
*http://www.dias-festivos.com/country/Marruecos_113.htm
*http://www.turismomarruecos.net/seguridad/recursos/calendario-de-festivales-y-festividades.html
*http://marruecosrutas.com/dias-festivos-en-marruecos/
*http://guia.rehoteles.com/fiestas-y-eventos-en-marruecos/
*http://www.dniwolne.eu/es-%C3%81frica-fiestas-Marruecos.html
*[https://viajar-a-marruecos.org/festivales-en-marruecos/ Festivales en Marruecos]
[[Category:Festividades]]

Metodología Scrum

2019-03-07T20:32:49Z

Youfaska: añadir una referencia de introduccion a kanban

{{Ficha Software
|nombre=El modelo Scrum
|familia=
|imagen=Scrum.jpeg
|tamaño=
|descripción=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.
|imagen2=
|tamaño2=
|descripción2=
|creador=Ikujiro Nonaka e Hirotaka Takeuchi
|desarrollador=
|diseñador=
|modelo de desarrollo=
|fecha de creación=Años 80'
|lanzamiento inicial=
|versiones=
|última versión estable=
|núcleo=
|tipo de núcleo=
|plataformas soportadas=
|género=
|sistemas operativos=
|idioma=
|licencia=
|premios=
|web=
}}
<div align="justify">
'''Scrum ''' es una [[Metodologías Ágiles|metodología]] ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka.

== 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. 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, como en el [[rugby]], donde el equipo entero «actúa como un sólo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro». 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), 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 scrum en su compañía, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla scrum.

En [[1995]] Schwaber y Sutherland, durante el OOPSLA '95 desarrollado en [[Ciudad Austin|Austin]], presentaron en paralelo una serie de artículos describiendo scrum, siendo ésta la primera aparición pública de la metodología. 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. 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 Team que 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. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.

Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. 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.

== Roles en Scrum ==

En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. El nombre de los grupos están inspirados en el chiste sobre un cerdo y una gallina que se relata a continuación. Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La [[gallina]] piensa un poco y contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el [[cerdo]], "Tú sólo estarías involucrada mientras que yo estaría comprometido". De esta forma, los 'cerdos' están comprometidos a través de sus aportes 'directos' en la construcción de software, mientras que las 'gallinas' están involucradas a través de sus aportes 'indirectos'. Las necesidades, deseos, ideas e influencias de los roles 'gallina' se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum. 

=== Roles "Cerdo" ===

Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato".

=== Product Owner ===

 El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog. 

=== ScrumMaster (o Facilitador) ===

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. 

=== Equipo ===

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc). 

=== Roles "Gallina" ===

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint. Análisis de la frase "Rol gallina": La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero. 

=== Usuarios ===

Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software no es usado ¿fue alguna vez escrito?. Stakeholders (Clientes, Proveedores, Inversores) Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint. 

=== Managers ===

Es la gente que establece el ambiente para el desarrollo del producto. 

== Reuniones en Scrum ==

=== Daily Scrum ===

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas: · La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc) · Todos son bienvenidos, pero sólo los "cerdos" pueden hablar.

La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo. · Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta) · La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días. Durante la reunión, cada miembro del equipo contesta a tres preguntas:· ¿Qué has hecho desde ayer? · ¿Qué es lo que estás planeando hacer hoy?· ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos). 

=== Scrum de Scrum ===

Cada día normalmente después del “Daily Scrum” · Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración. · Asiste una persona asignada por cada equipo. La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas: · ¿Qué ha hecho tu equipo desde nuestra última reunión? · ¿Qué hará tu equipo antes que nos volvamos a reunir? · ¿Hay algo que demora o estorba a tu equipo? ·

¿Estás a punto de poner algo en el camino del otro equipo? Reunión de Planificación del Sprint (Sprint Planning Meeting) Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo. · Seleccionar que trabajo se hará · Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo. · Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint · Ocho horas como límite Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint” 

=== Reunión de Revisión del Sprint (Sprint Review Meeting) ===

 · Revisar el trabajo que fue completado y no completado · Presentar el trabajo completado a los interesados (alias “demo”) · El trabajo incompleto no puede ser demostrado · Cuatro horas como límite 

=== Retrospectiva del Sprint (Sprint Retrospective) ===

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas. 

== Documentos ==

=== Product backlog ===

El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI) . Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto. 

=== Sprint backlog ===

El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. 

=== Burn down ===

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos. 

== [[Image:Proceso scrum.JPG|border|right|300x250px|Visión General del Proceso Scrum]] Scrum aplicado al desarrollo de software ==

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en [[1993]] en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En [[1996]] lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en [[2001]] serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son: · Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados. · Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento. · Reuniones: Planificación del sprint, Revisión diaria, Revisión del sprint. · Sprint

== Referencias ==

*(PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams Retrieved March 15, 2007 * (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process Retrieved July 01, 2010 * (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google Retrieved 2007-12-15 * (video) Ken Schwaber in Scrum et al. Retrieved 2008-01-19
*Para más información en [https://cafe-agil.com/ café ágil] hay mucha informacion sobre marcos de y metodos de trabajo agil como Scrum y Kanban
*Introducción a Kanban de la mano de un trainer oficial de Lean Kanban University

== Fuentes ==
* [http://www.proyectosagiles.org/que-es-scrum/ Proyectos Ágiles]

* [http://www.chuidiang.com/ood/metodologia/ scrum.php]

* [http://www.scrum.es/]

* [http://es.wikipedia.org/wiki/ Scrum Wikipedia]

* [http://www.navegapolis.net/ Navegapolis]

[[Category:Informática]]
[[Category:Metodologías_de_desarrollo_de_software]]

Metodología Scrum

2019-03-07T20:17:53Z

Youfaska: he añadid una referencia sobre marcos y metodos de trabajo

{{Ficha Software
|nombre=El modelo Scrum
|familia=
|imagen=Scrum.jpeg
|tamaño=
|descripción=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.
|imagen2=
|tamaño2=
|descripción2=
|creador=Ikujiro Nonaka e Hirotaka Takeuchi
|desarrollador=
|diseñador=
|modelo de desarrollo=
|fecha de creación=Años 80'
|lanzamiento inicial=
|versiones=
|última versión estable=
|núcleo=
|tipo de núcleo=
|plataformas soportadas=
|género=
|sistemas operativos=
|idioma=
|licencia=
|premios=
|web=
}}
<div align="justify">
'''Scrum ''' es una [[Metodologías Ágiles|metodología]] ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka.

== 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. 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, como en el [[rugby]], donde el equipo entero «actúa como un sólo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro». 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), 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 scrum en su compañía, Advanced Development Methods. Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla scrum.

En [[1995]] Schwaber y Sutherland, durante el OOPSLA '95 desarrollado en [[Ciudad Austin|Austin]], presentaron en paralelo una serie de artículos describiendo scrum, siendo ésta la primera aparición pública de la metodología. 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. 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 Team que 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. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.

Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. 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.

== Roles en Scrum ==

En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. El nombre de los grupos están inspirados en el chiste sobre un cerdo y una gallina que se relata a continuación. Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La [[gallina]] piensa un poco y contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el [[cerdo]], "Tú sólo estarías involucrada mientras que yo estaría comprometido". De esta forma, los 'cerdos' están comprometidos a través de sus aportes 'directos' en la construcción de software, mientras que las 'gallinas' están involucradas a través de sus aportes 'indirectos'. Las necesidades, deseos, ideas e influencias de los roles 'gallina' se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum. 

=== Roles "Cerdo" ===

Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamón en el plato".

=== Product Owner ===

 El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog. 

=== ScrumMaster (o Facilitador) ===

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. 

=== Equipo ===

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc). 

=== Roles "Gallina" ===

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint. Análisis de la frase "Rol gallina": La gallina alimenta al proyecto "poniendo huevos", no se ve comprometida como el cerdo que va al matadero. 

=== Usuarios ===

Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software no es usado ¿fue alguna vez escrito?. Stakeholders (Clientes, Proveedores, Inversores) Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del sprint. 

=== Managers ===

Es la gente que establece el ambiente para el desarrollo del producto. 

== Reuniones en Scrum ==

=== Daily Scrum ===

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas: · La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc) · Todos son bienvenidos, pero sólo los "cerdos" pueden hablar.

La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo. · Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta) · La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días. Durante la reunión, cada miembro del equipo contesta a tres preguntas:· ¿Qué has hecho desde ayer? · ¿Qué es lo que estás planeando hacer hoy?· ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos). 

=== Scrum de Scrum ===

Cada día normalmente después del “Daily Scrum” · Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración. · Asiste una persona asignada por cada equipo. La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas: · ¿Qué ha hecho tu equipo desde nuestra última reunión? · ¿Qué hará tu equipo antes que nos volvamos a reunir? · ¿Hay algo que demora o estorba a tu equipo? ·

¿Estás a punto de poner algo en el camino del otro equipo? Reunión de Planificación del Sprint (Sprint Planning Meeting) Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo. · Seleccionar que trabajo se hará · Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo. · Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint · Ocho horas como límite Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint” 

=== Reunión de Revisión del Sprint (Sprint Review Meeting) ===

 · Revisar el trabajo que fue completado y no completado · Presentar el trabajo completado a los interesados (alias “demo”) · El trabajo incompleto no puede ser demostrado · Cuatro horas como límite 

=== Retrospectiva del Sprint (Sprint Retrospective) ===

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas. 

== Documentos ==

=== Product backlog ===

El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI) . Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto. 

=== Sprint backlog ===

El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. 

=== Burn down ===

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos. 

== [[Image:Proceso scrum.JPG|border|right|300x250px|Visión General del Proceso Scrum]] Scrum aplicado al desarrollo de software ==

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en [[1993]] en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En [[1996]] lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en [[2001]] serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son: · Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados. · Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento. · Reuniones: Planificación del sprint, Revisión diaria, Revisión del sprint. · Sprint

== Referencias ==

*(PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams Retrieved March 15, 2007 * (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process Retrieved July 01, 2010 * (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google Retrieved 2007-12-15 * (video) Ken Schwaber in Scrum et al. Retrieved 2008-01-19
*Para más información en [https://cafe-agil.com/ café ágil] hay mucha informacion sobre marcos de y metodos de trabajo agil como Scrum y Kanban

== Fuentes ==
* [http://www.proyectosagiles.org/que-es-scrum/ Proyectos Ágiles]

* [http://www.chuidiang.com/ood/metodologia/ scrum.php]

* [http://www.scrum.es/]

* [http://es.wikipedia.org/wiki/ Scrum Wikipedia]

* [http://www.navegapolis.net/ Navegapolis]

[[Category:Informática]]
[[Category:Metodologías_de_desarrollo_de_software]]