Metodologia scrum

ScrumMetodología Ágil

Objetivo del curso

Busca transmitir a los participantes el enfoque de Scrum de una manera práctica para aplicar en su organización, que les permita implementar este modelo de proceso ágil en el desarrollo de software aprovechando sus ventajas en las tareas de administración de proyecto.

Comprender su metodología, los roles, actividades y artefactos que le componen.

Audiencia

Profesionales que participan en proyectos de desarrollo que deseen una alternativa probada para un desarrollo que responda a las restricciones de tiempo sin sacrificar el control o la calidad.

Ingenieros de procesos que deseen agregar prácticas ágiles a sus procesos de desarrollo des software.

Administradores de Proyectos que requieran utilizar prácticas ágiles de administración de proyectos.

Programadores interesados en desarrollo ágil.

Desarrollo ágil de software

Son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios.

Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos.


El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas.

Cada iteración del ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, revisión y documentación.

Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la meta es tener una «demo» (sin errores) al final de cada iteración.

Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.


Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés).

La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso.

Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

Algunos métodos ágiles

Adaptive Software Development (ASD).

Agile Unified Process (AUP).

Crystal Clear.

Essential Unified Process (EssUP).

Feature Driven Development (FDD).

Lean Software Development (LSD).

Kanban.

Open Unified Process (OpenUP).

Programación Extrema (XP).

Método de desarrollo de sistemas dinámicos (DSDM).

Scrum.

G300.

Manifiesto ágil

Individuos e interacciones

Software que funciona

Colaboración con el cliente

Responder ante el cambio

Procesos y herramientas

Documentación exhaustiva

Negociación de contratos

Seguimiento de un plan

sobre

sobre

sobre

sobre

Principios del desarrollo ágil

Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software que aporte valor.

Aceptamos de buen grado cambios en los requisitos, incluso si llegan tarde al desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.

Entregar con frecuencia software que funcione, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

La gente de negocio y los desarrolladores deben trabajar juntos de forma cotidiana durante todo el proyecto.


Construir proyectos en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en que ellos conseguirán hacer el trabajo.

El método más eficiente y efectivo de comunicar información hacia y dentro de un equipo de desarrollo es la conversación cara a cara.

El software que funciona es la principal medida de progreso.

Los procesos ágiles promueven el desarrollo sostenido.

Los promotores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida.


La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

La simplicidad, el arte de maximizar la cantidad de trabajo que no se hace, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

En intervalos regulares, el equipo reflexiona en cómo ser más efectivo, se afina y ajusta su comportamiento de acuerdo con esto.

Ejercicio

Historia

El concepto de Scrum tiene su origen en un estudio de 1986 sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japón y los Estados Unidos (cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de Honda, ordenadores de HP y otros).

Los equipos que desarrollaron estos productos partían de requisitos muy generales, así como novedosos, y debían salir al mercado en mucho menos del tiempo del que se tardó en lanzar productos anteriores.

Historia

Estos equipos seguían patrones de ejecución de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de Scrum (melé en español).

En la actualidad, Scrum se está utilizando en diferentes tipos de negocio y, especialmente, en el desarrollo de software. La Scrum Alliance es la organización sin ánimo de lucro que se encarga de difundir Scrum en este ámbito.

Principios de Scrum

Comunicación verbal directa entre los involucrados en el proyecto.

Predisposición y respuesta al cambio.

Colaboración estrecha con el cliente.

Desarrollo incremental con entregas funcionales frecuentes.

Motivación y responsabilidad de los equipos por la autogestión, auto-organización y compromiso.

Simplicidad gracias a que sólo se usan artefactos necesarios en la gestión del proyecto.

Prefiere el conocimiento tácito de las personas al explícito de los procesos.

Definición de Scrum

Es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI).

Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.

Fundamentos de Scrum

Es una metodología ágil para desarrollo y mantenimiento de Software.

Basado en un desarrollo iterativo e incremental.

Mantiene grupos auto-organizados y multidisciplinares.

Permite una rápida adaptación a cambios, minimiza costos y tiempos.

Prevé la adaptación continua a las circunstancias de evaluación del proyecto.


El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita).

La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración.

El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.


La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la autoridad necesaria para organizar su trabajo.

La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el cliente.

El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados.

Características

Equipos auto-organizados.

El producto avanza en una serie de “Sprints” de dos semanas a un mes de duración.

No hay prácticas de ingeniería prescritas.

Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos.

Los requisitos son capturados como elementos de una lista de “Product Backlog”.

Beneficios

Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado.

La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.

La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.

Beneficios

Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.

El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

Razón de utilizar Scrum

Con esta metodología 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 sin ningún problema.

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.

Ventajas

Trabaja con iteraciones rápidas.

La idea principal es ponerse a trabajar cuanto antes y que el cliente vaya viendo avances.

Fácil de implantar.

Ofrece ventaja competitiva pues se adapta al cambio.

Evita burocracia y generación de documentos.

Se obtiene Software con requerimientos exigidos de manera rápida.

Creatividad y efectividad del equipo auto administrado y entorno libre de interrupciones.

Reuniones dedicadas a problemas recientes.

Desventajas

Dificultad de aplicación para grandes proyectos.

Existe delegación de responsabilidades con posibilidad de fallo.

Se requiere de un agile champion para monitorizar el desarrollo.

Problemas si el precio y fecha de entrega son cerrados.

Presuposiciones de equipos formados y motivados, clientes involucrados en el desarrollo y su participación, y que la documentación no es necesaria.

Campo de aplicación

Software comercial

Desarrollo de videojuegos

Desarrollos internos

Desarrollos bajo contrato

Aplicaciones financieras

Aplicaciones certificadas ISO 9001

Sistemas críticos de soporte vital

Software de control satelital

Aplicaciones para Handheld

Sitios web

Sistemas embebidos

Ejercicio

Scrum Framework

Roles o Componentes: Product Owner (Propietario del

producto) Scrum Master (Scrum Manager) Scrum Team (Equipo de desarrollo) Stakeholders (Usuarios, Clientes)

Artefectos o Elementos: Product Backlog (Pila de Producto) Sprint Backlog (Pila de Sprint) Burndown Chart Incremento

Meetings o Reuniones: Sprint Planning Sprint Review Sprint Retrospective Daily Scrum Meeting

Roles

Product Owner:

Define las funcionalidades del producto.

Representa a los stakeholders (cliente interno o externo).

Ajusta funcionalidades y prioridades en cada iteración.

Acepta o rechaza el resultado del trabajo del equipo.

Es el responsable de obtener el mayor valor de producto.

Es el que exige y prioriza los requerimientos del producto.

Roles

Scrum Master o Scrum Manager:

Representa a la gestión del proyecto.

Responsable del funcionamiento y productividad del equipo de desarrollo.

Escudo del equipo de interferencias externas.

Responsable de promover los valores y prácticas de Scrum.

Permite la estrecha cooperación en todos los roles y funciones.

Se asegura que se sigan los procesos y del seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer.

Roles

Scrum Team: Equipos de 5 a 9 personas, multidisciplinares y multifuncionales.

Incluye a los desarrolladores, testers, diseñadores, analistas.

Responsables de implementar las funcionalidades del Product Owner.

Los miembros deben ser full-time.

Comprometidos y auto-organizados.

Solo puede haber cambios de miembros entre los sprints.

Grupo de trabajo que desarrollan el producto Sprint a Sprint.

Roles

Stakeholders (Clientes, Usuarios):

Sólo participan directamente en las revisiones del sprint.

Hacen posible el proyecto.

Beneficiarios finales del producto.

Aportan ideas, sugerencias o necesidades basados en el progreso del proyecto.

Artefactos

Product Backlog:

Lista de requisitos de usuario que se origina con la visión inicial del producto.

Idealmente cada tema tiene valor para el usuario o el cliente.

Va creciendo y evolucionando durante el desarrollo por lo que nunca llega a ser una lista definitiva.

Todas las tareas, funcionalidades o requerimientos a realizar.

Marcadas y priorizadas por el Product Owner.

Repriorizadas al comienzo de cada Sprint.

Ejemplo de Product Backlog

Artefactos

Sprint Backlog:

Es una tarea que proviene de una lista de tareas (Actividades) con una breve declaración de cuál será el foco del trabajo durante el sprint.

Deben realizarse entre 2 y 4 semanas.

No pueden ser alteradas o modificadas.

Es la lista de trabajos a realizar por el equipo durante el sprint para generar un avance.

Ejemplo de Sprint Backlog

Artefactos

Burndown Chart:

Gráfico que controla el progreso del sprint y la cantidad restante de trabajo por hacer.

Re-estima las tareas o se añaden nuevas tareas.

Ayuda a la evaluación del proceso de cada sprint por parte de los Stakeholders.

Ejemplo de Burndown Chart

Artefactos

Incremento:

Es el resultado entregado al final de cada Sprint.

Meetings o reuniones

Sprint Planning meeting:

Reunión de planificación del Sprint Backlog y previa para el inicio de un Sprint.

Se priorizan los requerimientos.

Determina el trabajo y objetivos a cumplir en la iteración.

Duración con tiempo máximo de 8 horas.

Participa: Scrum Master, Scrum Team y el Product Owner.


Beneficios del Sprint Planning Meeting:

Productividad mediante comunicación y creación de sinergias: Todos los miembros del equipo tienen una misma visión del objetivo y se ha

utilizado los conocimientos y las experiencias de todos para elaborar la mejor solución entregable en el mínimo tiempo y con el mínimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre tareas, etc.

Potenciación del compromiso del equipo sobre el objetivo común de la iteración:

Es todo el equipo quien asume la responsabilidad de completar en la iteración los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algún impedimento que bloquea el progreso de la iteración, especialmente si cuando se está llegando al final de la iteración es necesaria la participación de todos para poder completar los objetivos comprometidos.

Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que se autoasignó) en los tiempos que proporcionó. Si existe falta de compromiso con respecto al resto de miembros del equipo se hará muy evidente en las reuniones diarias de sincronización del equipo (Scrum daily meeting).

Una estimación conjunta es más fiable, dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de los integrantes del equipo.


Sprint Review meeting:

Reunión informal de revisión del Sprint con duración de 2 a 4 horas.

Se realiza al finalizar un Sprint.

El Scrum Team muestra avances en vivo al Product Owner.

Se presentan nuevas funcionalidades y se genera un feedback del producto.

La revisión del sprint es el análisis y revisión del incremento generado.


Beneficios del Sprint Review:

El cliente puede ver de manera objetiva cómo han sido desarrollados los requisitos que proporcionó, ver si se cumplen sus expectativas, entender más qué es lo que necesita y tomar mejores decisiones respecto al proyecto.

El equipo puede ver si realmente entendió cuáles eran los requisitos que solicitó el cliente y ver en qué puntos hay que mejorar la comunicación entre ambos.

El equipo se siente más satisfecho cuando puede ir mostrando los resultados que va obteniendo. No está meses trabajando sin poder exhibir su obra.


Restricciones del Sprint Review:

Sólo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en función de la velocidad de desarrollo y el resultado realmente completado.

Un requisito no completado quedará como un requisito más a replanificar.


Sprint Retrospective:

Retrospectiva al finalizar un Sprint y dura aprox. 1 hora.

El Product owner revisa con el equipo los objetivos iniciales del Sprint backlog concluido, se aplican cambios y ajustes necesarios.

Se marcan aspectos positivos (para replicarlos) y los aspectos negativos (para evitarlos) del Sprint.


Beneficios del Sprint Retrospective:

Incrementa la productividad en el proyecto, la calidad del producto (cosa que permite hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo de manera sistemática, iteración a iteración, con resultados a corto plazo.

Aumenta la motivación del equipo dado que participa en la mejora de proceso, se siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir eliminando lo que molesta e impide que sea más productivo.


Restricciones del Sprint Retrospective:

En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y recursos para ir mejorando su forma de trabajar y el contexto del proyecto.

Es frustrante encontrar sistemáticamente los mismos obstáculos y no poder solucionarlos.


Daily Scrum Meeting (Reunión Diaria):

Es la primer actividad del día con duración aprox. 15 minutos.

Tarea iterativa todos los días de cada Sprint.

Se verifica el avance de las tareas y sus planificaciones.


Beneficios del Daily Scrum Meeting:

Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto delante del resto:

Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su trabajo o por que hay dependencias (especialmente si existe un retraso).

Los impedimentos con que se encuentra. El resto de miembros del equipo pueden ofrecer ayuda a otros en la realización de tareas o para resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se encargará de solucionar los impedimentos que el equipo no puede solucionar por sí solo o que le quitan tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos.

Las tareas no planeadas que está realizando que el equipo no conoce y puede que no estén alineadas con el compromiso del equipo, aunque él crea que lo que está haciendo es lo mejor que se puede hacer.



Continuación: Cuáles son sus necesidades. Cada miembro entiende las

necesidades de los otros miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar sus trabajos para que den el máximo valor y no realizar tareas que no proporcionan ningún beneficio al resto del equipo.

Cuál es su ritmo de trabajo. Se hace visible si de manera continua un miembro del equipo está realizando tareas por debajo del rendimiento esperado. Se evita que una persona señale con el dedo a otra, dado que la reunión de sincronización pone a todos los miembros del equipo en la misma situación de tener que explicar en qué tareas están trabajando.

Cuáles son los criterios que está utilizando para realizar sus tareas, de manera que estén alineados con los objetivos comunes del equipo.



Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cómo trabajan los otros según sus especialidades y experiencias.

Conocer el estado de la iteración, ver si es posible completar los requisitos a que se comprometió el equipo, en vista de las desviaciones y de las tareas pendientes.


Restricciones del Daily Scrum Meeting:

La reunión diaria de estado y sincronización del equipo no es para resolver problemas, los problemas se resuelven después de la reunión.

No a todos los miembros del equipo les interesan todos los detalles de cada tema.

El equipo debe contar con unos criterios consensuados sobre el proceso de ejecución de las de tareas.

En la reunión los miembros del equipo programan reuniones entre ellos donde colaborar sincronizando tareas, ayudando a resolver problemas, etc.


Restricciones del Daily Scrum Meeting:

No puede haber una persona explicando su estado mientras otras "se han apartado" de la reunión para comentar un tema particular. Si apareciese alguna conversación de interés común (que debe ser rápida), debe poder ser escuchada por todo el equipo sin distraer el principal objetivo de que todos conozcan en qué están trabajando los demás. Si la mini conversación no es del interés de todos, debe hacerse después de la reunión.

El proceso de ejecución de las tareas debe estar consensuado para evitar que cada reunión sea una exposición de discrepancias entre los miembros del equipo.

Ejercicio

Prácticas

Se realizan ciclos (o iteraciones) de duración fija llamadas Sprints. Se recomienda que la duración de un Sprint sea de 2, 3 o 4 semanas.

Durante el Sprint el objetivo del equipo es generar un incremento visible, utilizable, entregable.

Prácticas

Al inicio de cada Sprint se realiza una Planning Meeting durante la cual se revisa el Backlog de proyectos (listado de requisitos de alto nivel pendientes, previamente priorizados por el Product Owner).

En esta reunión el Product Owner identifica los proyectos que quiere resolver y los describe al equipo. Entonces, el equipo determina cuáles de estos proyectos pueden ser comprometidos a completar para el Sprint.

Se identifican tareas y cada una es estimada (1-16 horas).

Realizado colaborativamente, no solo por el Scrum Master.

Prácticas

Durante el transcurso del Sprint no se puede modificar el alcance del mismo, es decir, se intentará mantener congelados los requisitos hasta que el mismo finalice.

En la práctica, nos hemos reservado parte de nuestro tiempo para lidiar con urgencias que no pueden esperar un ciclo para ser resueltas.

Prácticas

Diariamente se realiza una Daily Meeting que no debe durar más de 15 minutos, donde cada persona del equipo comparte las tareas realizadas, lo que piensa hacer hasta la reunión del día siguiente y si se ha topado con algún impedimento que no le permita avanzar de acuerdo a lo comprometido.

Ésta reunión no es para la solución de problemas.

Todos están invitados, pero solo los miembros del equipo, Scrum master y Product Owner pueden hablar.

Ayuda a evitar otras reuniones innecesarias.

Será moderado por el Scrum master, y cada miembro del Scrum Team responde 3 preguntas tomando en cuenta que no es para dar un reporte de status, si no para tratar compromisos:

Qué hice ayer? Qué tengo voy a hacer hoy? Qué dificultades tengo en mi camino?

Prácticas

Al final del Sprint, luego del Deploy / Release / Incremento en el producto, se realiza una Retrospective Meeting durante la cual el equipo comparte libremente opiniones sobre las cosas que salieron bien (y desean repetirse a futuro) y las cosas que salieron mal (y deben evitarse a futuro).

Periódicamente, se echa un vistazo a lo que funciona y lo que no.

Tiempo aproximado de la reunión de 15 a 30 minutos.

Todo el equipo participa (Scrum Master, Product Owner, Scrum Team, posiblemente clientes y otros).

Ejercicio

Historias de usuario

Es una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario.

Son utilizadas en las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación). Cada historia de usuario debe ser limitada, esta debería poderse escribir sobre una nota adhesiva pequeña.

Son una forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos.

Permiten responder rápidamente a los requerimientos cambiantes.

Características de las Historias de Usuario

Independientes unas de otras: De ser necesario, combinar las historias dependientes o buscar otra forma de dividir las historias de manera que resulten independientes.

Negociables: La historia en si misma no es lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.

Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para el desarrollador.

Características de las Historias de Usuario

Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto.

Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo. Generalmente se recomienda la consolidación de historias muy cortas en una sola historia.

Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.

Estructura de la Historia de Usuario

ID: Identificador de la historia de usuario.

TÍTULO: Título descriptivo de la historia de usuario.

DESCRIPCIÓN: Descripción sintetizada de la historia de usuario.

ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo (estas unidades representarán el tiempo teórico de desarrollo/hombre que se estipule al comienzo del proyecto).

DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero a veces es inevitable. En este apartado se indicarían los IDs de las tareas de las que depende una tarea.

Estructura de la Historia de Usuario

PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de las historias de usuario. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW:

M – Must, se debe completar este requerimiento para finalizar el proyecto.

S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él.

C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto.

W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo).

Ejercicio

Fuente de información

Scrum and The Enterprise por Ken Schwaber

Agile Software Development Ecosystems por Jim Highsmith

www.agilemanifiesto.org

www.scrumalliance.org

www.controlchaos.com

www.proyectosagiles.org/historia-de-scrum

Cockburn, Alistair. Agile Software Development. Highsmith Series.

The New New Product Developement Game, por Hirotaka Takeuchi (Hitotsubashi University) y Ikujiro Nonaka. Harvard Business Review, Enero-Febrero de 1986.

Gracias.L.S.C. Karla Leticia AGUILAR LÓPEZ

Metodologia scrum

Software

Transcript of Metodologia scrum