Tema 1 Desarrollo Rápido de Software en Equipo

Instituto Tecnológico Superior de Huatusco

Docente: MSC. Olivia Labastida Puertos

Tema 1: Desarrollo Rápido de Software en Equipo E-mail: olabastidap@huatusco.tecnm.mx

Competencia Específica:

Conoce los elementos para el desarrollo de habilidades

colaborativas con SCRUM para la creación de software.

1.1 Objetivos de trabajo y estructura lógica de la memoria La memoria es un recurso importante que debe ser cuidadosamente gestionado. A todo programador de

gustaría poder contar con una memoria infinitamente grande, rápida y que fuese además no volátil.

1.1 Objetivos de trabajo y estructura lógica de la memoria Administración de memoria

Es una tarea realizada por el sistema operativo que consiste en gestionar la jerarquía de memoria, en cargar y descargar procesos en memoria principal para que sean ejecutados.

1.1 Objetivos de trabajo y estructura lógica de la memoria Para ello el sistema operativo gestiona lo que se conoce como MMU o Unidad de Administración de Memoria, el

cual es un dispositivo hardware que transforma las direcciones lógicas en físicas.

1.1 Objetivos de trabajo y estructura lógica de la memoria Su trabajo es seguir la pista de que partes de la memoria están en uso y cuales o lo están, con el fin de poder

asignar memoria a los procesos cuando la necesiten, y recuperar esa memoria cuando dejen de necesitarla, así como gestionar el intercambio entre memoria principal y

el

disco

cuando

la

memoria

principal

resulte

demasiado pequeña para contener a todos los procesos.

1.1 Objetivos de trabajo y estructura lógica de la memoria Objetivos de la Gestión de Memoria

• Ofrecer a cada proceso un espacio lógico propio.

• Proporcionar protección entre los procesos, • Permitir que los procesos compartan memoria.

• Maximizar el rendimiento del sistema.

1.1 Objetivos de trabajo y estructura lógica de la memoria Requisitos de la Gestión de Memoria

• Reubicación: En un sistema multiprogramado la memoria

se

encuentra

compartida

por

varios

procesos, por lo tanto, los procesos deber ser cargados y descargados de memoria.

1.1 Objetivos de trabajo y estructura lógica de la memoria Requisitos de la Gestión de Memoria

• Protección: En un sistema con multiprogramación es necesario proteger al sistema operativo y a los otros procesos de posibles accesos que se puedan realizar a sus espacios de direcciones.

1.1 Objetivos de trabajo y estructura lógica de la memoria Requisitos de la Gestión de Memoria

• Compartición:

En

ciertas

situaciones,

bajo

la

supervisión y control del sistema operativo, puede ser provechoso que los procesos puedan compartir memoria.

1.1 Objetivos de trabajo y estructura lógica de la memoria Requisitos de la Gestión de Memoria

• Organización lógica: Tanto la memoria principal como la secundaria presentan una organización física similar, como un espacio de direcciones lineal y unidimensional.

1.1 Objetivos de trabajo y estructura lógica de la memoria Requisitos de la Gestión de Memoria

• Debe existir una cierta correspondencia entre el sistema operativo y el hardware al tratar los datos y los programas de los usuarios de acuerdo a la estructura lógica que ellos presenten.

1.1 Objetivos de trabajo y estructura lógica de la memoria Requisitos de la Gestión de Memoria

• Organización

Física:

Debe

ser

parte

de

la

administración de memoria, la organización del flujo de información entre la memoria principal y la memoria secundaria.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM A la hora de poner en marcha un proyecto, toda empresa debe asegurar que el equipo implicado conoce

sus tareas y plazos de tiempo de entrega. Scrum es una metodología de trabajo que nos ayuda a conseguirlo y que, además, permite agilizar la entrega de valor al cliente en iteraciones cortas de tiempo.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM La metodología Scrum es un marco de trabajo o framework que se utiliza dentro de equipos que

manejan proyectos complejos.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM Es decir, se trata de una metodología de trabajo ágil que tiene como finalidad la entrega de valor en períodos

cortos de tiempo y para ello se basa en tres pilares: la transparencia, inspección y adaptación. Esto permite al cliente, junto con su equipo comercial, insertar el producto en el mercado pronto, rápido y empezar a

obtener ventas (Sales enablement).

1.2 Descripción de Proceso de Desarrollo de Software SCRUM Al estar enmarcada dentro de las metodologías agile, Scrum se basa en aspectos como:

• La flexibilidad en la adopción de cambios y nuevos requisitos durante un proyecto complejo.

• El factor humano.

• La colaboración e interacción con el cliente.

• El desarrollo iterativo como forma de asegurar buenos resultados.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM Los pilares o características de la metodología Scrum más importantes son 3:

1.2 Descripción de Proceso de Desarrollo de Software SCRUM 1. Transparencia

Con el método Scrum todos los implicados tienen conocimiento de qué ocurre en el proyecto y cómo ocurre. Esto hace que haya un entendimiento “común” del proyecto, una visión global.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM 2. Inspección

Los

miembros

inspeccionan

el

del

equipo

progreso

Scrum para

frecuentemente

detectar

posibles

problemas. La inspección no es un examen diario, sino una forma de saber que el trabajo fluye y que el equipo

funciona de manera auto-organizada.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM 3. Adaptación

Cuando hay algo que cambiar, el equipo se ajusta para conseguir el objetivo del sprint. Esta es la clave para conseguir el éxito en proyectos complejos, donde los requisitos son cambiantes o poco definidos y en donde

la adaptación, la innovación, la complejidad y flexibilidad son fundamentales.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM Roles en el equipo Scrum

Con la metodología Scrum, el equipo tiene como foco entregar valor y ofrecer resultados de calidad que permitan cumplir los objetivos de negocio del cliente.

Para ello, los equipos de Scrum son auto-organizados y multifuncionales.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM Es decir, cada uno es responsable de unas tareas determinadas

y

de

terminarlas

en

los

tiempos

acordados. Esto garantiza la entrega de valor del equipo completo, sin necesidad de ayuda o la supervisión minuciosa de otros miembros de la organización.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM En Scrum existen 3 roles muy importantes : Product Owner, Scrum Master y Equipo de desarrollo.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM 1. Product owner:

Es el responsable de maximizar el valor del trabajo del equipo de desarrollo. La maximización del valor del trabajo viene de la mano de una buena gestión del Product Backlog, el cual explicaremos más adelante.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM El

Product

owner

es

el

único

perfil

que

habla

constantemente con el cliente, lo que le obliga a tener

muchos conocimientos sobre negocio.

Para finalizar, un equipo Scrum debe tener solo un Product Owner y este puede ser parte del equipo de desarrollo.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM 2. Scrum Master:

Es el responsable de que las técnicas Scrum sean comprendidas y aplicadas en la organización. Es el manager de Scrum, un líder que se encarga de eliminar impedimentos o inconvenientes que tenga el equipo

dentro de un sprint (que ya revisaremos en detalle más adelante), aplicando las mejores técnicas para fortalecer el equipo de marketing digital.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM Dentro de la organización, el Scrum Master tiene la labor de ayudar en la adopción de esta metodología en todos

los equipos.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM 3. Equipo de desarrollo:

Son los encargados de realizar las tareas priorizadas por el Product Owner. Es un equipo multifuncional y autoorganizado. Son los únicos que estiman las tareas del product backlog, sin dejarse influenciar por nadie.

1.2 Descripción de Proceso de Desarrollo de Software SCRUM Los equipos de desarrollo no tienen sub-equipos o especialistas. La finalidad de esto es transmitir la

responsabilidad compartida si no se llegan a realizar todas las tareas de un sprint.

1.3 Visión Global de SCRUM Hitos de la Metodología de Trabajo Scrum

La gráfica describe los hitos dentro del proceso Scrum.

1.3 Visión Global de SCRUM El desarrollo iterativo se realiza en un sprint, que contiene los siguientes eventos: sprint planning, daily

meeting, sprint review y sprint retrospective.

1.3 Visión Global de SCRUM 1. Sprint

El sprint es el corazón de Scrum, es el contenedor de los demás hitos del proceso. Todo lo que ocurre en una iteración para entregar valor está dentro de un sprint.

1.3 Visión Global de SCRUM La duración máxima es de un mes, el tiempo se determina en base al nivel de comunicación que el

cliente quiere tener con el equipo. Los sprints largos pueden hacer que se pierda feedback valioso del cliente y poner en peligro el proyecto.

1.3 Visión Global de SCRUM 2. Sprint planning

En esta reunión todo el equipo Scrum define qué tareas se van a abordar y cuál será el objetivo del sprint. La primera reunión que se hace en el sprint puede llegar a tener una duración de 8 horas para sprints de un mes.

1.3 Visión Global de SCRUM El equipo se hace las siguientes preguntas:

• ¿Qué se va a hacer en el sprint? En base a ello, se eligen tareas del Product backlog.

• ¿Cómo lo vamos a hacer? El equipo de desarrollo define las tareas necesarias para completar cada ítem elegido del Product Backlog.

1.3 Visión Global de SCRUM La definición de qué se va a hacer implica que el equipo tenga un objetivo y se encuentre comprometido con la

entrega de valor que se hará al cliente al final del sprint.

A esto se le llama sprint goal.

El resultado de esta reunión es el sprint goal y un sprint backlog.

1.3 Visión Global de SCRUM 3. Daily meeting

Es una reunión diaria dentro del sprint que tiene como máximo 15 minutos de duración. En ella debe participar, sí o sí, el equipo de desarrollo y el Scrum Master. El Product Owner no tienen necesidad de estar presente.

1.3 Visión Global de SCRUM En esta reunión diaria el equipo de desarrollo hace las siguientes tres preguntas: • ¿Qué hice ayer?

• ¿Qué voy a hacer hoy?

• ¿Tengo algún impedimento que necesito que me solucionen?

1.3 Visión Global de SCRUM Esta

reunión

es

la

más

oportuna

para

poder

inspeccionar el trabajo y poder adaptarse en caso de

que haya cambio de tareas dentro de un sprint.

1.3 Visión Global de SCRUM 4. Sprint review

La review del valor que vamos a entregar al cliente se hace en esta reunión, al final de cada sprint. Su duración es de 4 horas para sprints de un mes, y es la única reunión de Scrum a la que puede asistir el cliente.

1.3 Visión Global de SCRUM En ella el Product Owner presenta lo desarrollado al cliente

y

el

equipo

de

desarrollo

muestra

su

funcionamiento. El cliente valida los cambios realizados y además brinda feedback sobre nuevas tareas que el Product Owner tendrá que agregar al Product backlog.

1.3 Visión Global de SCRUM 5. Sprint retrospective

La retrospectiva es el último evento de Scrum, tiene una duración de 3 horas para Sprints de un mes, y es la reunión del equipo en la que se hace una evaluación de cómo se ha implementado la metodología Scrum en el

último sprint.

1.3 Visión Global de SCRUM Es una gran oportunidad para el equipo Scrum de inspeccionarse a sí mismo, proponiendo mejoras para el

siguiente sprint.

El resultado: una lista de mejoras que debe aplicar el siguiente día, ya que al finalizar la retrospectiva, inmediatamente comienza un nuevo sprint, que incluye

el sprint planning, daily meeting, sprint review y la ya mencionada sprint retrospective.

1.4 Marco de Integración de la Usabilidad En el desarrollo de software está incrementándose el reconocimiento de la usabilidad como atributo de

calidad clave para el éxito de un producto. Sin embargo, las

técnicas

(Interacción

pertenecientes

al

Persona-Ordenador),

campo las

de

la

cuales

IPO nos

permiten alcanzar un nivel adecuado de usabilidad en el

producto de software, se aplican en el marco de métodos IPO, y no en el proceso de desarrollo habitual.

1.4 Marco de Integración de la Usabilidad Por otra parte, la construcción de software según los métodos y prácticas de la IS (Ingeniería de Software) no

trata de forma adecuada la usabilidad a lo largo del proceso de desarrollo. Es por ello que se presenta un ciclo de vida de tareas prácticas de usabilidad y técnicas para estructurar el proceso de diseño de buenas

interfaces de usuario para aplicaciones de software tradicionales o páginas web y subprogramas.

1.4 Marco de Integración de la Usabilidad

1.5 Instanciación de Marco de Integración Computación centrada en el ser humano

La computación basada en humanos es una técnica informática en la que un proceso computacional desempeña su función mediante la externalización de ciertos pasos hacia el ser humano.

1.5 Instanciación de Marco de Integración Este enfoque utiliza las diferencias en las capacidades y los costos alternativos entre los seres humanos y los

agentes

informáticos

para

simbiótica humano-ordenador.

lograr

una

interacción

1.5 Instanciación de Marco de Integración Para tareas computacionalmente difíciles, como el reconocimiento de imágenes, la computación basada

en humanos juega un papel central en el entrenamiento de

sistemas

de

inteligencia

artificial

basados

en

aprendizaje profundo. En este caso, la computación basada en humanos se ha denominado inteligencia

artificial asistida por humanos.

1.5 Instanciación de Marco de Integración Interacción humano-computadora (HCI)

La

interacción

persona-computadora

o

persona-

ordenador (IPO) se podría definir formalmente como: «La disciplina dedicada a diseñar, evaluar e implementar sistemas informáticos interactivos para el uso humano, y

a

estudiar

significativos»

los

fenómenos

relacionados

más

1.5 Instanciación de Marco de Integración Otra definición, aunque similar, es la que ofrecen Myers, Hollan y Cruz: «El estudio sobre cómo se diseñan,

implementan

y

usan

los

sistemas

informáticos

interactivos y la manera que influyen los ordenadores en los individuos, las organizaciones y la sociedad»

1.5 Instanciación de Marco de Integración Estos estudios son una especialización dentro de la ergonomía, el campo multidisciplinar que actúa sobre el

diseño de las máquinas y del entorno de trabajo para facilitar su uso y adecuarlo a las condiciones fisiológicas, anatómicas, psicológicas y capacidades del usuario.

1.5 Instanciación de Marco de Integración Finalmente, una tercera definición más específica es la que proponen Helander, Landauer y Prabhu: «En la IPO,

el conocimiento sobre las capacidades y las limitaciones del operador humano se utilizan para diseñar sistemas, tareas, herramientas, entornos y organizaciones. El propósito es mejorar la productividad y a la misma vez

proporcionar una experiencia segura, confortable y satisfactoria para el operador»

1.5 Instanciación de Marco de Integración En términos generales, es la disciplina que estudia el intercambio de información mediante software entre las

personas y las computadoras. Esta disciplina se encarga del diseño, evaluación e implementación de los aparatos tecnológicos interactivos, estudiando el mayor número de casos que les pueda llegar a afectar.

1.5 Instanciación de Marco de Integración El objetivo es que el intercambio sea más eficiente: minimizar errores, incrementar la satisfacción, disminuir

la frustración y, en definitiva, hacer más productivas las tareas que rodean a las personas y los computadores.

1.5 Instanciación de Marco de Integración Es muy importante diseñar sistemas que sean efectivos, eficientes y sencillos a la hora de utilizarlos, dado que la

sociedad disfrutará de estos avances. La dificultad viene dada por una serie de restricciones que obligan a los equipos de diseño a hacer algunos sacrificios en este.

1.5 Instanciación de Marco de Integración Algunas de las aplicaciones de esta disciplina podrían ser:

la

creación

de

librerías

digitales

donde

los

estudiantes pueden encontrar manuscritos medievales virtuales de hace centenares de años; herramientas para el campo de la medicina, como uno que permita a un equipo de cirujanos conceptualizar, alojar y monitorizar

una compleja operación neurológica;

1.5 Instanciación de Marco de Integración los mundos virtuales para el entretenimiento y la interacción social, servicios del gobierno eficientes y

receptivos, que podrían ir desde renovar licencias en línea hasta el análisis de un testigo parlamentario; o bien teléfonos inteligentes que saben donde están y cuentan con la capacidad de entender ciertas frases en

un idioma.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida En el marco de trabajo Scrum, denominamos Artefacto a aquellos elementos físicos que se producen como

resultado de la aplicación de Scrum. Los tres principales artefactos o herramientas Scrum son: el Product Backlog, Sprint Backlog y el Incremento.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Las herramientas que se utilizan en Scrum están definidas para maximizar la transparencia dentro del

equipo; es decir, que todos tengan una misma visión de lo que está ocurriendo en el proyecto.

Las herramientas principales de Scrum son: product backlog y sprint backlog.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Product Backlog

El Product Backlog es un inventario que contiene cualquier tipo de trabajo que haya que hacer en el producto: requerimientos, casos de uso, tareas y dependencias.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Es la principal fuente de información sobre el producto en Scrum, una lista, en cualquier formato, que contiene

todos los requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con el cliente, los distintos stakeholders, sponsors, comités, etc, y refleja el estado real del trabajo

pendiente de implementar en el producto, así como el ya realizado.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida El Product Backlog debe ser gestionado en exclusiva por el Product Owner, siendo su principal función la de

priorizar aquellos elementos que tienen más valor en cada etapa y detallarlos para que el equipo de desarrollo sea capaz de valorarlos y ejecutarlos.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Al comenzar a utilizar Scrum, no es necesario una lista completa y exhaustiva de todos los requerimientos. Es

recomendable

empezar

con

los

dos

o

tres

requerimientos más urgentes arriba e ir añadiendo elementos

conforme

vamos

necesidades de nuestro producto.

descubriendo

más

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Un Product Backlog contiene distintos elementos:

• Funcionalidades • Bugs • Historias

de

usuario:

una

forma

de

expresar

elementos de un Product Backlog. Para obtener el máximo valor de una historia de usuarios es necesario expresarlas desde el punto de vista del usuario.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida • Tareas técnicas • Trabajo de investigación

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Sprint Backlog

¿A qué denominamos Sprint Backlog? Se trata de una lista de elementos en los que trabajar durante la etapa de Sprint. Estos elementos normalmente se componen de

tareas

técnicas

más

pequeñas

que

permiten

conseguir un incremento de software terminado.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Todo el trabajo que el Development Team haya seleccionado para hacer durante el siguiente Sprint

pasa al Sprint Backlog. Este artefacto es un elemento para visualizar el trabajo a realizar durante cada Sprint y está gestionado por el equipo de desarrollo. Su propósito es mantener la transparencia dentro del desarrollo,

actualizándolo durante toda la iteración especialmente a través de los daily Scrums.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida El Sprint Backlog permite visualizar, durante cada Sprint, aquellos elementos que aún no han empezado a

desarrollarse, aquellos que sí y quiénes están trabajando en los mismos, así como aquellos que están esperando a desplegarse o están completamente terminados.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Este artefacto permite entender cuál es la evolución del trabajo durante el Sprint, así como hacer un análisis de

riesgos. Dado que cada Sprint tiene una meta específica (p.e. permitir que los usuarios se registren en la app móvil) y hay elementos seleccionados del Product Backlog que tienen más o menos valor, el Sprint

Backlog permite analizar hasta donde se ha cumplido el objetivo y que se podría eliminar. De esta forma, maximizamos el retorno de la inversión en desarrollo.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Incremento

Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de software terminado en cada Sprint.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Un Incremento es el resultado del Sprint, es la suma de

todas las tareas, casos de uso, historias de usuario y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software, aportando un valor de negocio al

producto que se está desarrollando.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Construir software de manera ágil se basa en hacerlo de manera iterativa e incremental. Mediante las iteraciones,

nos aseguramos que todo el ciclo de vida del software (planificación, diseño, desarrollo, testeo y entrega) ocurre en 4 semanas o menos. Por supuesto, no podemos construir toda la funcionalidad que queremos

en solo cuatro semanas y tenemos que buscar la manera de ir entregando los componentes necesarios justo a tiempo.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida Otros artefactos

El marco de trabajo Scrum destaca los 3 elementos expuestos

previamente

como

imprescindibles.

Sin

embargo, hay otros que, a pesar de no formar parte del core, son necesario para asegurar la calidad de la

metodología Scrum.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida • Definition of Done (DoD): La DoD es un documento

que define qué se considera hecho en un equipo Scrum. La idea es establecer una serie de criterios comunes para especificar cuando un ítem está completamente terminado y que aplique a todos los

ítems que forman parte del incremento.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida • Definition of Ready (DoR): El DoR es un documento

que define cuándo un requerimiento (historia de usuario o similar) se considera listo para que el equipo de desarrollo pueda entenderlo, valorarlo e incluirlo en un Sprint Planning con idea de acometerlo en un

Sprint.

1.6 Actividades y Ubicación de Técnicas seleccionadas en SCRUM en los Tres Momentos de Vida • Burndown Chart: El Burndown Chart es un gráfico de

trabajo pendiente a lo largo del tiempo que muestra la velocidad a la que se están completando los objetivos, requisitos, o historias de usuarios. Permite extrapolar si el equipo podrá completar el trabajo en

el tiempo estimado.

1.7 Ventajas e Inconvenientes Una vez sabemos cómo funciona esta metodología, hablemos de sus ventajas y desventajas:

1.7 Ventajas e Inconvenientes Ventajas de la metodología Scrum

• Scrum es muy fácil de aprender: los roles, hitos y herramientas son claros y tienen un objetivo por lo que es un método muy relacionado con nuestra manera diaria de trabajar.

• El cliente puede comenzar a usar el producto rápidamente.

1.7 Ventajas e Inconvenientes Ventajas de la metodología Scrum

• Se agiliza el proceso, ya que la entrega de valor es muy frecuente.

• Menor probabilidad de sorpresas o imprevistos, porque el cliente está viendo frecuentemente el proyecto.

1.7 Ventajas e Inconvenientes Desventajas de la metodología Scrum

• Aunque Scrum sea fácil de aprender, es muy difícil implementarlo. Esto supone una predisposición y un cambio de cultura de la organización que debe ir desde los altos mandos hasta los clientes.

1.7 Ventajas e Inconvenientes Desventajas de la metodología Scrum

• La necesidad de tener equipos multidisciplinares puede ser un problema, ya que es difícil encontrar personas que sean capaces de hacer todo el trabajo de un equipo.

1.7 Ventajas e Inconvenientes Desventajas de la metodología Scrum

• El equipo puede tender a realizar el camino más corto para conseguir el objetivo de un sprint, el cual no siempre ofrece resultados de calidad.

Conclusión En definitiva, Scrum es especialmente interesante para proyectos en los que el objetivo es la entrega de valor

continua al cliente para poder empezar a ver resultados lo antes posibles. Además, esta metodología permite agilizar procesos, practicar la transparencia y motivar al equipo a través de la autonomía y la independencia.

Fuentes de Consulta 1.

Pressman, R. S. (2010), Ingeniería del Software un enfoque práctico. México: MC Graw-Hill.

2. Oktaba, H.,Piattini M.G, (2008) Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies. Editorial Information Science Reference. (ISBN 9781599049083).

3. Mayhew, D.J. The usability Engineering Lifecycle.

Morgan Kaufmann, San Francisco CA. 1999.