Metodologías SCRUM y XP

De WikiUDO

Metodología de SCRUM


Contenido

INTRODUCCIÓN

A la hora de diseñar metodos de negocios que requieran una alta efectividad al momento de ser aplicadas, el desarrollo de proyectos y software desde el punto de vista de la Ingeniería de Sistemas es sumamente importante para la organización y optimización de las actividades llevadas a cabo por una empresa, por lo cual es necesaria la aplicación de diferentes procesos ágiles de desarrollo de software y gestión de proyectos, de acuerdo a las necesidades y la actividad que sea necesario realizar. Es por esto que en el presente trabajo se abordará el tema del SCRUM y el eXtreme Programming (XP). Se hablará de sus orígenes, características, casos de uso, funcionamiento y ventajas de cada uno para el desarrollo de proyectos y software.

METODOLOGÍAS ÁGILES

Existen numerosas propuestas de metodología para desarrollar software.

Tradicionalmente estas metodologías se centran en el control del proceso, estableciendo rigurosamente las actividades, herramientas y notaciones al respecto, dado estas reglas estas metodologías se caracterizan por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico.

Los objetivos de las metodologías ágiles, entre los cuales se destaca la preferencia de algunos valores por sobre otros, por ejemplo: Individuos e interacciones, sobre procesos y herramientas, Software operativo, sobre documentación extensiva Y Colaboración con el cliente, sobre negociación de Contratos.

ORIGEN DE LA METODOLOGÍA SCRUM

Scrum es una 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 a mediados de los 80. 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.


Hirotaka_Takeuchi_e_Ikujijo_Nonaka.jpg

"Hirotaka Takeuchi e Ikujijo Nonaka Creadores de La Metodología SCRUM"

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.

QUÉ ES LA METODOLOGÍA SCRUM

Según Juan Palacios y Claudia Ruata:

Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro, porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

Como método ágil:

  • Es un modo de desarrollo adaptable, antes que predictivo.
  • Orientado a las personas, más que a los procesos.
  • Emplea el modelo de construcción incremental basado en iteraciones y revisiones.

Comparte los principios estructurales del desarrollo ágil: a partir del concepto o visión de la necesidad del cliente, construye el producto de forma incremental a través de iteraciones breves que comprenden fases de especulación exploración y revisión. Estas iteraciones (en Scrum llamadas sprints) se repiten de forma continua hasta que el cliente da por cerrado el producto.

Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de negocio, y que pueden llevarse a cabo en un periodo de tiempo breve (según los casos pueden tener duraciones desde una semana hasta no más de dos meses). Cada uno de estos periodos de desarrollo es una iteración que finaliza con la entrega de una parte (incremento) operativa del producto.Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución en reuniones breves diarias donde todo el equipo revisa el trabajo realizado el día anterior y el previsto para el siguiente.

En Scrum se realizan entregas parciales y regulares del resultado final del proyecto, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad y la productividad son fundamentales. Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

Según Gustavo Du Mortier:

Scrum es, actualmente, uno de los métodos ágiles para desarrollo de software de mayor difusión en la industria, junto con Extreme Programming (XP). Su nombre proviene del rugby, deporte en el que un scrum es una jugada que permite reiniciar el juego luego de una falta accidental. La elección del nombre busca rescatar el principio de trabajo en equipo que se observa en un scrum de rugby: varios jugadores se toman de los hombros y se esfuerzan para lograr –por sí solos y rápidamente– un objetivo común, que consiste en adueñarse de la pelota y llevarla hacia delante.

El creador de Scrum es Jeff Sutherland, uno de los 17 gurúes agilistas que se reunieron en el año 2001 para establecer los postulados del desarrollo de software ágil, y redactar y firmar el mítico Manifiesto Ágil. En el texto de dicho manifiesto se establecen los objetivos de las metodologías ágiles, entre los cuales se destaca la preferencia de algunos valores por sobre otros, por ejemplo:

  • Individuos e interacciones, sobre procesos y herramientas.
  • Software operativo, sobre documentación extensiva.
  • Colaboración con el cliente, sobre negociación de contratos.

En estos postulados se observa la intención de los agilistas de rebelarse contra los vicios típicos de los procesos tradicionales de desarrollo de software: planes que no se cumplen o que se extienden más allá de los plazos, documentación que exige demasiado trabajo de elaboración y no refleja la realidad del producto final, contratos que terminan perjudicando a una de las dos partes (desarrollador o cliente) o a ambas, entre otros males.

Scrum intenta atacar esos problemas endémicos del desarrollo de software rescatando la filosofía de procesos que llevó a las automotrices japonesas (con Toyota a la cabeza) a abrumar a sus pares estadounidenses, al superarlos en aspectos tales como productividad y eficiencia. El secreto de Toyota era tan simple como dar a cada empleado la posibilidad de crear sus propias reglas, junto con la responsabilidad de maximizar la calidad en la parte del desarrollo que le tocaba llevar a cabo.

La metodología Scrum asume que el proceso de desarrollo de software es impredecible, y lo trata como a una “caja negra” controlada, en vez de manejarlo como un proceso completamente definido.

Ésta es una de las principales diferencias entre Scrum y otras metodologías, como los modelos de espiral o de cascada, en los cuales el proceso de desarrollo se define por completo desde el inicio. Por tratar de planificar el proceso en forma completa desde el principio, las metodologías tradicionales fallan al toparse con algunos problemas habituales del desarrollo de software, como la falta de comprensión de los requerimientos al empezar el proceso, el cambio en los requerimientos durante el proceso, o la dificultad para prever los resultados del uso de nuevas herramientas y tecnologías.

Según Omar Otoniel Soto Romero y Germán Harvey Alférez Salinas:

El término Scrum fue utilizado por primera vez por Takeuchi y Nonaka en 1986. Ellos revisaron las mejores prácticas de negocios para construir nuevos productos, particularmente en las industrias automotrices y de consumo. Además notaron que los equipos pequeños y multifuncionales producían los mejores resultados. En 1993, Jeff Sutherland, entonces jefe de ingenieros en Easel Corporation, se le ocurrió implementar estos conceptos de negocios a la ingeniería a del software, logrando resultados sorprendentes con la generación de nuevos productos de software de alta calidad, listos para entregarse al cliente en los tiempos estipulados. Todo producto de software, durante su creación, enfrenta un proceso complejo de desarrollo debido al ambiente dinámico. A mayor grado de complejidad mayor grado de flexibilidad se requerirá para lograr el éxito. Es entonces donde encaja a la perfección Scrum, ya que es como una caja negra donde seguir un proceso lineal no es la regla. Por el contrario, se está listo para atacar cualquier eventualidad de manera inmediata durante el proceso adaptándose a la nueva realidad. Es ahí donde se encuentra el núcleo y fortaleza de Scrum.

CARACTERÍSTICAS DE LA METODOLOGÍA SCRUM

Según Palacios:

Scrum es una metodología ágil, y como tal:

  • Equipos auto-organizado
  • Es un modo de desarrollo de carácter adaptable más que predictivo.
  • Orientado a las personas más que a los procesos.
  • Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.


Según Gustavo du Mortier:

La metodología Scrum asume que el proceso de desarrollo de software es impredecible, y lo trata como a una caja negra controlada, en vez de manejarlo como un proceso completamente definido. Ésta es una de las principales diferencias entre Scrum y otras metodologías, como los modelos de espiral o de cascada, en los cuales el proceso de desarrollo se define por completo desde el inicio. Por tratar de planificar el proceso en forma completa desde el principio, lasmetodologías tradicionales fallan al toparse con algunos problemas habituales del desarrollo de software, como la falta de comprensión de los requerimientos al empezar el proceso, el cambio en los requerimientos

durante el proceso, o la dificultad para prever los resultados del uso de nuevas herramientas y tecnologías.

Otra diferencia de Scrum con las metodologías tradicionales es que no trata el proceso de desarrollo de software como un proceso lineal, en el que se sigue la secuencia de análisis, diseño, codificación y testing. En Scrum, el proyecto puede iniciarse con cualquier actividad, y

cambiar de una a otra en cualquier momento. Un proyecto administrado mediante Scrum se organiza en iteraciones, llamadas sprints, que normalmente tienen entre dos y cuatro semanas de duración. Al principio de cada sprint se establece una lista de requerimientos llamada backlog, que debe completarse cuando éste finalice. A diario se realizan breves reuniones del equipo de desarrollo, en las que se exponen los avances y los problemas encontrados, y se señalan posibles caminos para resolverlos (la resolución detallada de estos problemas no debe determinarse durante la reunión, para mantener su brevedad).

PRACTICAS DE LA METODOLOGÍA SCRUM

Revisión de las Iteraciones:

Al finalizar cada iteración (sprint) se lleva a cabo una revisión con todas las personas implicadas en el proyecto. Es por tanto la duración del sprint, el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto.

Desarrollo incremental:

Las personas implicadas no trabajan con diseños o abstracciones. El desarrollo incremental implica que al final de cada iteración se dispone de una parte de producto operativa, que se puede inspeccionar y evaluar.

Desarrollo evolutivo:

Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales cómo será el resultado final, y sobre dicha predicción desarrollar el diseño y la arquitectura del producto no es realista, porque las circunstancias obligarán a remodelarlo muchas veces.

¿Para qué predecir los estados finales de la arquitectura o del diseño si van a estar cambiando? Scrum considera a la inestabilidad como una premisa, y se adoptan técnicas de trabajo para permitir la evolución sin degradar la calidad de la arquitectura que también evoluciona durante el desarrollo.

Durante el desarrollo se genera el diseño y la arquitectura final de forma evolutiva. Scrum no los considera como productos que deban realizarse en la primera “fase” del proyecto. (El desarrollo ágil no es un desarrollo en fases.

Auto-organización:

En la ejecución de un proyecto son muchos los factores impredecibles en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos. En Scrum los equipos son auto-organizados (no auto-dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas.

Colaboración:

Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. Ésta es necesaria, porque para que funcione la auto organización como un control eficaz cada miembro del equipo debe colaborar de forma abierta con los demás, según sus capacidades y no según su rol o su puesto.

Visión general del proceso:

Scrum denomina “sprint” a cada iteración de desarrollo y según las características del proyecto y las circunstancias del sprint puede determinarse una duración desde una hasta dos meses, aunque no suele ser recomendable hacerlos de más de un mes.

El sprint es el núcleo central que proporciona la base de desarrollo iterativo e incremental.

¿CUÁNDO SE UTILIZA LA METODOLOGÍA SCRUM?

Con Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración. Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades.

VALORES DE SCRUM

Scrum es una “carrocería” para dar forma a los principios ágiles. Es una ayuda para organizar a las personas y el flujo de trabajo; como lo pueden ser otras propuestas de formas de trabajo ágil: Cristal, DSDM, etc.
  • La carrocería sin motor, sin los valores que dan sentido al desarrollo ágil, no funciona.
  • Delegación de atribuciones (empowerment) al equipo para que pueda auto-organizarse y tomar las decisiones sobre el desarrollo.
  • Respeto entre las personas.
  • Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.
  • Responsabilidad y auto-disciplina (nodisciplina impuesta).
  • Trabajo centrado en el desarrollo de lo comprometido Información, transparencia y visibilidad del desarrollo del proyecto.

PRINCIPIOS DE SCRUM

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.

FASES DE SCRUM

De manera general el proceso de desarrollo del scrum se compone de 5 fases importantes
  • Planes de lanzamientos
  • Distribución, revisión y ajuste de los estándares de producto
  • Sprint
  • Revisión del Sprint
  • Cierre

SPRINT

La fase de Sprint es donde el desarrollo de software se lleva a cabo. Un Sprint consta de las siguientes actividades:

  • Elaborar
  • Integrar
  • Revisar
  • Ajustar.

Esta fase no tiene una secuencia. A veces un elemento del backlog se tiene que desarrollar, integrar, y revisar cuando otras sólo debe ser revisado o ajustado.

REVISIÓN DE SPRINT Cada Sprint es seguido por una revisión de Sprint. Durante esta revisión, el software desarrollado en el Sprint anterior se revisa y si es necesario se le añaden nuevos ítems del backlog. El grupo de revisores pueden ser: las partes interesadas del proyecto, gestores, desarrolladores y, en ocasiones los clientes, ventas y marketing.

Las actividades, y la revisión de Sprint Sprint se repiten hasta que el producto se considera listo para su distribución por los participantes en el proyecto. Luego, el proyecto pasa a la fase de cierre en que el producto se prepara para el lanzamiento y la distribución.

CIERRE En esta fase tienen lugar las actividades de debugging, marketing y promoción. Al acabar esta fase el proyecto quedará cerrado.



ACTIVIDADES


PLANIFICACIÓN DE LA ITERACIÓN

El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes:
  1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.
  2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las tareas.

EJECUCIÓN DE LA ITERACION

Cada día el equipo realiza una reunión de sincronización (15 minutos máximos). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:
  • ¿Qué he hecho desde la última reunión de sincronización?
  • ¿Qué voy a hacer a partir de este momento?
  • ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.

  • Elimina los obstáculos que el equipo no puede resolver por sí mismo.
  • Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

INSPECCIÓN Y ADAPTACIÓN

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:
  1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, re planificando el proyecto.
  2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.


FASES SEGÚN AUTORES


A continuación se muestran las fases de la metodología scrum de acuerdo al criterio de varios autores:

Según Juan Palacios y Claudia Ruata:

El proceso scrum según los autores se desarrolla en 4 fases:

1.Se comienza con una visión general del producto.

2.Se especifican y dan detalles a las funcionalidades o partes del proyecto que tienen mayor prioridad

3.Se desarrolla la iteración.

4.Entrega del incremento.

Según Gustavo Du montier:

480px-Fases_del_scrum.png

Fases de la metodología Scrum

El proceso de desarrollo Scrum se compone de cinco actividades principales: revisión de los planes de release, distribución, revisión y ajuste de los estándares de producto, sprint, revisión de sprint, y cierre .

La fase de sprint es en la que se realiza el desarrollo de software propiamente dicho. Dentro de un sprint se efectúan varias sub-actividades: desarrollo, empaquetado, revisión y ajuste. No existe secuencia dentro de esta fase. Algunas veces, un ítem del backlog debe ser desarrollado, empaquetado y revisado, y otras veces, el ítem sólo debe ser revisado y ajustado; todo depende de las características del ítem en cuestión.

Cada sprint es seguido por un proceso de revisión. Durante esta etapa, se revisa el software desarrollado en el sprint que acaba de finalizar y, de ser necesario, se agregan nuevos ítem en el backlog. El grupo de revisores debe incluir a los stakeholders, los administradores del proyecto, los desarrolladores y los usuarios. Las actividades de sprint y revisión de sprint tienen que repetirse hasta que el producto está en condiciones de ser distribuido por los accionistas. Luego, el proyecto entra en la fase de cierre, tras la cual el producto queda en condiciones para el cierre de versión (release) y distribución.

En la fase de cierre, se realizan las últimas tareas de depuración (debugging), luego de lo cual se construyen los entregables y el proyecto se da por finalizado. Debido a lo imprevisible de los procesos de desarrollo de software, no es posible definir exactamente cuándo ocurrirá la fase de cierre, de modo que los proyectos pueden demorarse más o menos de lo planeado. Pero mediante el uso de los controles que provee Scrum, se pueden hacer estimaciones sobre su duración.



ROLES DE SCRUM

Según Juan Palacios y Claudia Ruata

Todas las personas que intervienen, o tienen relación directa o indirecta con el proyecto, se clasifican en dos grupos: comprometidos e implicados. En círculos de Scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa) “cerdos” y a los segundos “gallinas”.
  • Propietario del producto: El propietario del producto o “product owner” es la persona que toma las decisiones del cliente.
  • Equipo: Se recomienda un tamaño de equipo entre 4 y 8 personas. Más allá de 8 resulta más difícil mantener la agilidad en la comunicación directa, y se manifiestan con más intensidad las rigideces habituales de la dinámica de grupos (que comienzan a aparecer a partir de 6 personas).
  • Scrum Manager – team leader: Es el responsable del funcionamiento de Scrum en el proyecto, cubriendo los aspectos siguientes que la organización necesite según el conocimiento, experiencia con el modelo… o aquellos que no cubra con otras personas con la formación e idoneidad adecuada.
  • Otros interesados.

800px-Roles.png

Roles del Scrum según Juan Palacios y Claudia Ruata

Según Gustavo Du Montier

El método Scrum reconoce tres roles: Dueño del producto, Scrum Master y Equipo. Las responsabilidades del Dueño del producto incluyen definir las características del producto, determinar la fecha de lanzamiento y el contenido, asegurar la rentabilidad del producto, priorizar las características según el valor de mercado, ajustar las características y las prioridades cada treinta días (según sea necesario), y aceptar o rechazar resultados del trabajo. El Dueño delproducto es responsable por la primera de las tres “ceremonias” de Scrum: la planificación.

El Scrum Master es un facilitador y líder de equipo, quetrabaja en contacto estrecho con el Dueño del producto. Sus responsabilidades abarcan asegurar que el equipo se mantenga plenamente funcional y productivo; permitir la cooperación estrecha entre todos los roles y funciones; eliminar las barreras que obstaculicen el desarrollo del proyecto; proteger al equipo de las interferencias externas, y asegurar que el proceso se lleve a cabo correctamente, asegurando la concurrencia de los involucrados a las reuniones diarias de Scrum, a las revisiones de sprint y a las planificaciones de sprint.

Durante las reuniones diarias de Scrum, el Scrum Master debe saber qué tareas han sido completadas, cuáles se han iniciado, qué nuevas tareas se han descubierto y qué estimaciones cambiaron. Esto hace posible mantener actualizado el diagrama de burndown, que muestra, día tras día, el trabajo que queda pendiente. El Scrum Master debe observar cuidadosamente el número de tareas abiertas en progreso, para asegurarse de mantener este número en valores óptimos. Debe sacar a la luz las dependencias y los bloqueos que actúen como impedimentos para el Scrum, determinando sus prioridades y realizando su seguimiento. Es preciso implementar un plan de solución para estos impedimentos en orden de prioridad. Algunos podrán resolverse con el equipo; otro podrán resolverse entre equipos, y otros requerirán la participación de la gerencia, ya que pueden ser cuestiones de la compañía que estén impidiendo a todos los equipos lograr su óptima capacidad de producción.

Por último, el Scrum Master debe detectar problemas personales o conflictos dentro del Scrum que necesiten solución. Estos conflictos deben ser clarificados por él y resueltos mediante el diálogo dentro del equipo, o bien el Scrum Master puede solicitar ayuda a la gerencia o a la oficina de recursos humanos.

El Equipo debe ser polifuncional, compuesto por siete miembros (más/menos dos). Su labor consiste en seleccionar el objetivo final de cada sprint, especificar los resultados del trabajo y llevarlo a cabo. Posee el derecho de realizar lo que sea dentro de los límites que impongan los lineamientos del proyecto– para alcanzar el objetivo final de un sprint. Debido a que opera como una “caja negra”, debe organizarse a sí mismo y a su trabajo, y debe preparar una demo de los resultados para exhibir ante el Dueño del producto.

Personas que intervienen: clientes, administradores, product owner es la persona que toma las decisiones del cliente y Scrum Manager – team leader que es el responsable del funcionamiento de scrum.


Roles_de_scrum.png

PRODUCTOS QUE GENERA LA METODOLOGÍA SCRUM

Según Juan Palacios y claudia Ruata

  • Pila del producto: (product backlog) lista de requisitos de usuario que a partir de la visión inicial del producto crece y evoluciona durante el desarrollo.
  • Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto.
  • Incremento: Resultado de cada sprint.

640px-Productos_del_scrum.png Productos que genera la metodología Scrum

VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA SCRUM

VENTAJAS:

  • Programación organizada.
  • Menor taza de errores.
  • Satisfacción del programador.


DESVENTAJAS:

  • Es recomendable emplearlo solo en proyectos a corto plazo.
  • Altas comisiones en caso de fallar.

PROCESOS DE LA METODOLOGÍA SCRUM

Metodologia_agil.png


HERRAMIENTAS QUE UTILIZA LA METODOLOGÍA SCRUM

  • El gráfico de producto o burn-up: muestra en un vistazo el plan general de desarrollo del producto. A partir de la velocidad del equipo y las estimaciones de trabajo previstas en la pila del producto, representa las fechas o sprints en los que previsiblemente se irán terminando las diferentes versiones.

Grafico_de_producto.png Gráfico de producto o burn-up

  • El gráfico de avance o burn-down: es una herramienta ágil que monitoriza el ritmo de trabajo (normalmente de un sprint). En el eje vertical de un diagrama cartesiano representa el trabajo pendiente a lo largo del tiempo del sprint (eje horizontal).Las desviaciones sobre, o bajo la línea diagonal que representaría el avance ideal del sprint alertan de forma temprana de desviaciones sobre el ritmo de desarrollo previsto.

Grafico_de_avance.png Gráfico de avance o burn-down

  • La estimación de póquer: es una práctica ágil para reducir las dificultades habituales en las reuniones de trabajo para planificación por juicio de expertos.En ella los participantes emplean un juego de cartas para concretar las unidades de esfuerzo que estiman para cada tarea.

Hay dos variantes:

Natural: los participantes pueden estimar el esfuerzo con la cifra exacta que crean más adecuada.

Fibonacci: las estimaciones solo se pueden realizar empleando números de la sucesión de Fibonacci. En cada caso, el juego de cartas empleado tiene la numeración apropiada.

Estimacion.png La estimación de póquer

METODOLOGÍA XP (EXTREME PROGRAMMING)

QUÉ ES LA METODOLOGÍA XP

Según Kent Beck

La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999).Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.


Creador_de_la_metodologia_xp.jpg

Kent Beck, Creador de la Metodología XP

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.


Según Ian Sommerville

La Programación Extrema (XP) es posiblemente el método ágil más conocido y ampliamente utilizado. El nombre fue acuñado por Beck (Beck 2000) debido a que el enfoque fue desarrollado utilizando buenas prácticas reconocidas, como el desarrollo iterativo, y con la participación del cliente en niveles extremos.

En la programación extrema todos los requerimientos se expresan como escenarios llamados historias de usuario los cuales se implementan directamente como una serie de tareas. Los programadores trabajan en parejas y desarrollan pruebas para cada tarea antes de escribir el código. Todas las pruebas se deben ejecutar satisfactoriamente cuando el código nuevo se integre al sistema. Existe un pequeño espacio de tiempo entre las entregas del sistema.

La programación extrema implica varias prácticas que se ajustan a los principios de los métodos agiles:

  • El desarrollo incremental se lleva a cabo a través de entregas del sistema pequeñas y frecuentes y por medio de un enfoque para la descripción de requerimientos basados en las historias de cliente o escenarios que pueden ser la base para el proceso de planificación.
  • La participación del cliente se lleva a cabo a través del compromiso a tiempo completo del cliente en el equipo de desarrollo. Los representantes de los clientes participan en el desarrollo y son los responsables de definir las pruebas de aceptación del sistema.
  • El interés en las personas, en vez de en los procesos, se lleva a cabo a través de la programación en parejas, la propiedad colectiva del código del sistema, y un proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo.
  • El cambio se lleva a cabo a través de las entregas regulares del sistema, un desarrollo previamente probado y la integración continua.
  • El mantenimiento de la simplicidad se lleva a cabo a través de la refactorización constante para mejorar la calidad del código y la utilización de diseños sencillos que no prevén cambios futuros en el sistema.

CARACTERÍSTICAS DE LA METODOLOGÍA XP

  • Se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.
  • Se aplica de manera dinámica durante el ciclo de vida del software.
  • Es capaz de adaptarse a los cambios de requisitos.
  • Los individuos e interacciones son más importantes que los procesos y herramientas.
  • Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.

La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades.

  • Software que funcione es más importante que documentación exhaustiva.
  • Desarrollar software que funciona más que conseguir una buena documentación.

La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental.

  • La colaboración con el cliente es más importante que la negociación de contratos.
  • La colaboración con el cliente más que la negociación de un contrato.

Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

  • La respuesta ante el cambio es más importante que el seguimiento de un plan.


VALORES DE LA METODOLOGÍA XP

Los Valores originales de la programación extrema son: simplicidad, comunicación, retroalimentación (feedback) y coraje. Un quinto valor, respeto, fue añadido en la segunda edición de Extreme Programming Explained. Los cinco valores se detallan a continuación:
  • SIMPLICIDAD:
La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento.

Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece.

También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté auto-documentado.Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente.

Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.
  • COMUNICACIÓN:
La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea.

Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado.

Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad.

Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas.
  • RETROALIMENTACIÓN (FEEDBACK):
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real.

Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programador esa centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos.

Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo.

El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código.Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.
  • CORAJE O VALENTÍA:
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar todo lo demás del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente.


PERSONAS QUE INTERVIENEN EN LA METODOLOGÍA XP

Según Kent Beck

La metodología XP se encuentra en una frecuente integración del equipo de programación con el cliente o usuario: se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo; el cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas.

Según Ian Sommerville

En un proceso XP, los clientes están fuertemente implicados en la especificación y establecimiento de prioridades de los requerimientos del sistema.

Los requerimientos no se especifican como una lista de funciones requeridas del sistema. Más bien, los clientes del sistema son parte del equipo de desarrollo y discuten escenarios con otros miembros del equipo. Desarrollan conjuntamente una tarjeta de historia que recoge las necesidades del cliente. El equipo de desarrollo intentara entonces implementar ese escenario en una entrega futura del software.

La participación del cliente se lleva a cabo a través del compromiso a tiempo completo del cliente en el equipo de desarrollo. Los representantes de los clientes participan en el desarrollo y son los responsables de definir las pruebas de aceptación del sistema.


LOS PASOS DE LA METODOLOGÍA XP

Según Kent Beck

Los Pasos fundamentales inmersos en las fases del método son:

  • Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.

Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.

  • Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorizacion del código: Es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartido: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad del codigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.


Según Ian Sommerville

  • Planificación Incremental: Los requerimientos se registran en tarjetas de historias y las historias a incluir en una entrega se determinan según el tiempo disponible y su prioridad relativa.

Los desarrolladores dividen estas historias en tareas de desarrollo.

  • Entregas Pequeñas: El mismo conjunto útil de funcionalidad que proporcione valor de negocio se desarrolla primero. Las entregas del sistema son frecuentes e incrementalmente añaden funcionalidad a la primera entrega.
  • Diseño Sencillo: Solo se lleva a cabo el diseño necesario para cumplir los requerimientos actuales.
  • Desarrollo previamente probado: Se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas para nuevas funcionalidades antes de que estas se implementen.
  • Refactorizacion: Se espera que todos los desarrolladores refactoricen el código continuamente tan pronto como encuentren posibles mejoras en el código.

Esto conserva el código sencillo y mantenible.

  • Programación en Parejas: Los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro proporcionando la ayuda necesaria para hacer siempre un buen trabajo.
  • Propiedad Colectiva: Las parejas de desarrolladores trabajan en todas las áreas del sistema, de modo que no desarrollen islas de conocimiento y todos los desarrolladores posean todo el código. Cualquiera puede cambiar cualquier cosa.
  • Integración Continua: En cuanto acaba el trabajo en una tarea, se integra en el sistema entero.

Después de la integración, se deben pasar al sistema todas las pruebas de unidad.

  • Ritmo Sostenible: No se consideran aceptables grandes cantidades de horas extras, ya que a menudo el efecto que tienen es que se reduce la cantidad del código y la productividad a medio plazo.
  • Cliente Presente: Debe estar disponible al equipo de la XP un representante de los usuarios finales del sistema (el cliente) a tiempo completo. En un proceso de la programación externa, el cliente es miembro del equipo de desarrollo y es responsable de formular al equipo los requerimientos del sistema para su implementación.


FASES DE LA METODOLOGÍA XP

Según Kent Beck

1ª FASE: Planificación del proyecto.

Historias de usuario:
El primer paso de cualquier proyecto que siga la metodología X.P es definir las historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias: Constan de 3 ó 4 líneas escritas por el cliente en un lenguajeno técnico sin hacer mucho hincapié en los detalles; no se debe hablar ni de posibles algoritmos para su implementación ni de diseños de base de datos adecuados,etc. Son usadas para estimar tiempos de desarrollo de la parte de la aplicación que describen.También se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3 semanas.

Release Planning: .Después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en inglés "Release plan", donde seindiquen las historias de usuario que se crearán para cada versión del programa y las fechas en las que se publicarán estas versiones. Un "Release plan" es una planificación donde los desarrolladores y clientes establecen los tiempos de implementación ideales de las historias de usuario, la prioridad con la que serán implementadas y las historias que serán implementadas en cada versión del programa. Después de un "Release plan" tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las versiones del programa, el número de personas que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo realizado. (*Release plan: Planificación de publicaciones).

Iteraciones: Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que serán implementadas. También se seleccionan las historias de usuario que no pasaron el test de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los programadores.

La Velocidad del Proyecto: es una medida que representa la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el número de historias de usuario que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan".

Programación en Parejas: La metodología X.P. aconseja la programación en parejas pues incrementa la productividad y la calidad del software desarrollado.

El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica haciendo hincapié en la calidad de la función o método que está implementando,el otro analiza si ese método o función es adecuado y está bien diseñado. De esta forma se consigue un código y diseño con gran calidad.

Reuniones Diarias:. Es necesario que los desarrolladores se reúnan diariamente y expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el mundo tiene que tener voz y voto.


2ª FASE: Diseño.

Diseños Simples: La metodología X.P sugiere que hay que conseguir diseños simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y esfuerzo desarrollar.

Glosarios de Términos: Usar glosarios de términos y un correcta especificación de los nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores ampliaciones y la reutilización del código.

Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese problema.

Funcionabilidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.

Refactorizar: Refactorizar es mejorar y modificar la estructura y codificación de códigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados que contienen funcionalidades que no serán usadas y diseños obsoletos.


3ª FASE: Codificación.

Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo; su presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que serán implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada. La codificación debe hacerse ateniendo a estándares de codificación ya creados. Programar bajo estándares mantiene el código consistente y facilita su comprensión y escalabilidad.


4ª FASE: Pruebas.

Uno de los pilares de la metodología X.P es el uso de test para comprobar el funcionamiento de los códigos que vayamos implementando. El uso de los test en X.P es el siguiente:

  • Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo específico para test.
  • Hay que someter a tests las distintas clases del sistema omitiendo los métodos más triviales.
  • Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado anterior se explicó la importancia de crear antes los test que el código.
  • Un punto importante es crear test que no tengan ninguna dependencia del código que en un futuro evaluará.
  • Como se comentó anteriormente los distintos test se deben subir al repositorio de código acompañados del código que verifican.
  • Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario.
  • Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se harán test que analicen partes de las mismas, sino que las pruebas se realizarán para las funcionalidades generales que debe cumplir el programa especificado en la descripción de requisitos.


Fases_XP.jpg Fases de la Metodología XP


Según Ian Sommerville

800px-Fases_XP.png Fases de la Metodología XP

VENTAJAS Y DESVENTAJAS DE LA METODOLOGÍA XP

VENTAJAS:

  • Programación organizada.
  • Menor taza de errores.
  • Satisfacción del programador.


DESVENTAJAS:

  • Es recomendable emplearlo solo en proyectos a corto plazo.
  • Altas comisiones en caso de fallar.

COMPARATIVAS DE LAS METODOLOGÍAS SCRUM y XP

SEMEJANZAS


  • Es un Agile Manifiesto.
  • Existen una Interacción de Usuario a Usuario.
  • Realizan los Proyectos en un Corto Periodo de Tiempo.
  • Trabajan en Equipo.


DIFERENCIAS

SCRUM XP (EXTREME PROGRAMMING)
Las iteraciones de entregas son de 2 a 4 semanas. Las iteraciones de entrega son a 1 a 3 semanas.
Lo que se termina, funciona y este bien, se aparta y ya no se toca. Las tareas q se van entregando a los diferentes clientes son susceptibles a las modificaciones.
Cada miembro del Scrum Team trabaja de forma individual. Los miembros del programan en pareja en un proyecto XP.
El Scrum Team trata de seguir el orden de prioridad q marca el Product Owner en el Sprint Backlog pueden ser modificadas. El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definidas por el cliente.
Esta basada en la administración del proyecto. Se centra mas en la propia programación o creación del producto.

PROCESO DE LA METODOLOGÍAS XP

Xp.png

CONCLUSIÓN

Mediante la realización de esta investigación se pudo llegar a las siguientes conclusiones:

• El SCRUM es usado como modelo para el desarrollo de productos tecnológicos, aunque 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, mientras que el XP se usa de una forma adaptable a cualquier punto de la vida de cualquier proyecto, considerándose capaz de obtener resultados mas realistas y efectivos.

• Tanto el SCRUM como el XP, toman en cuenta los cambios que puedan ir ocurriendo a medida que se vaya desarrollando el proyecto para de esta manera mejorar u optimizar la arquitectura del mismo a medida que este se va llevando a cabo.

• El SCRUM y el XP trabajan de forma iterativa, de manera que en cada una se vaya mejorando la arquitectura del proyecto y se acerque más al resultado esperado.

• Estos procesos ágiles requieren de una persistente comunicación y retroalimentación entre los integrantes desarrolladores del proyecto para que de esta manera se realicen los cambios y se mejore el producto final.

BIBLIOGRAFÍA

Páginas de consultadas:

http://www.proyectosagiles.org/beneficios-de-scrum

http://lisbethmacias.blogspot.com/

http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema

http://www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Presentacion-XP.pdf

http://oness.sourceforge.net/proyecto/html/ch05.html

http://www.davidvalverde.com/blog/category/desarrollo-software/page/3/

Juan Palacios, 2006 http://www.navegapolis.net

Juan Palacios y Claudia Ruata, 2010 http://www.scrummanager.net/files/sm_proyecto.pdf

Hector Hernandez e Ixchel Zazueta, 2011 http://www.slideshare.net/Ixchel_muffin/scrum-10162115

Gustavo du Mortier, 2007 http://www.slideshare.net/cristianjaviergomez/nota-scrumpc-users

http://www.mastersoft.com.ar/MsWeb/otros_archivos/NotaScrumPCUsers.pdf

Omar Otoniel Soto Romero y Germán Harvey Alférez Salinas. Scrum, ¿Un Paradigma de Administración de Proyectos que Cumple lo que Promete?

http://www.academia.edu/528989/Scrum_Un_paradigma_de_administracion_de_proyectos_que_cumple_lo_que_promete

Kent beck, 1999 http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema

http://www.slideshare.net/edgarespinoza/programacion-extrema

Beck, K. Extreme Programming Explained. Embrace Change (2004). Addison Wesley. Segunda Edición. Ebook

http://www.alejandrogoyen.com/MemoriaDeGradoXP.pdf
Ian Sommerville. Ingeniería del software. Séptima edición (2005)
Herramientas personales