Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Metodología Scrum

Una Descripción de el funcionamiento de esta tecnología así como también como se aplica en el desarrollo de sistemas
by

Angel Velasquez

on 19 February 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Metodología Scrum

Un término medio es el ajuste temporal de 2 ó 4 semanas que está basado en la experiencia de muchas personas en muchos proyectos. No es lo mismo reconducir el proyecto perdiendo 2 ó 4 semanas, que reconducirlo perdiendo 6 meses por ejemplo.
La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se pueda reconducir el proyecto en un momento dado, y que afecte lo menos posible a los costes, los tiempos y al equipo de trabajo.
Supongamos el caso de la construcción de un rascacielos o de un edificio. Si con el fin de controlar el proyecto y que no se te escape nada ni metamos la pata en algo, me preguntas cada día en varias ocasiones como estoy haciendo las cosas, como lo llevo y cuales son mis avances, te aseguro que no terminaremos la construcción del edificio en el tiempo planificado ni de broma. Además, seguro que querrás cambiar o modificar algo cada día o incluso varias veces en el mismo día.
Si me preguntas cada 6 meses por ejemplo, avanzaré mucho sin interrupciones, pero a buen seguro que el riesgo de desviaciones es mucho mayor y seguramente si ocurren, reajustar esas desviaciones al proyecto tendrá costes elevados asociados.
Product Owner
Scrum Master
Scrum Team
Usuarios o Clientes
Dos aspectos fundamentales a diferenciar
Los actores
Las acciones.
El Product Owner Conoce y marca las prioridades del proyecto o producto.

El Scrum Master es la persona que asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
Scrum
Conclusiones
Pero Porque esos Tiempos
Actores
Se basa en la filosofía del desarrollo ágil
El mercado actual es altamente competitivo y la tecnología es muy cambiante. En el desarrollo del Software se pide básicamente rapidez, calidad y reducción de costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad.
Los ciclos de desarrollo por otro lado, acostumbran a ser largos, y lo que se exige por otra parte, es que esos ciclos sean lo más cortos posibles.
Scrum obedece a las necesidades anteriormente citadas, y no responde a ninguna moda, sino a una necesidad realmente demandada en el desarrollo del Software.
El Scrum Team son las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner.

Los Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades.
Product Backlog
Sprint Backlog
Daily Scrum Meeting
Acciones
El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar.

El Sprint Backlog corresponde con una o más tareas que provienen del Product Backlog. Las tareas del Sprint Backlog se deben acometer en unas 2 semanas ó 4 semanas. Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas.
que he hecho
que voy a hacer hoy
que ayuda necesito
El Daily Scrum Meeting es una tarea iterativa que se realiza todos los días que dure el Sprint Backlog con el equipo de desarrollo o de trabajo. Se trata de una reunión operativa, informal y ágil, de un máximo de 30 minutos, en la que se le hace 3 preguntas a cada integrante del equipo.
Desarrollo Ágil
Ángel Velásquez
Estuardo Teleguario
Luis Garcia

Programación adaptativa tiene como objetivo el problema de la producción de aplicaciones que se pueden adaptar fácilmente ante las necesidades cambiantes de los usuarios, los deseos, y el medio ambiente.
Programador
Cliente
Tester
Tracker
Entrenador
Consultor
Gestos
Aunque las metodologías ligeras se basan en las ideas de los procesos tradicionales estas usan lo mas importante para el buen desarrollo del proyecto con lógicay dejando atrás el manejo excesivo de artefactos y burocracia.
Desarrollo Ágil
DESARROLLO ADAPTATIVO DE SOFTWARE (DAS)
Actores
El 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.
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
Responder a los cambios más que seguir estrictamente un plan.
Desarrollar software que funciona más que conseguir una buena documentación.

La colaboración con el cliente más que la negociación de un contrato.
Programación organizada.
Menor taza de errores.
Satisfacción del programador
Ventajas
Para reducir el tiempo de desarrollo: 45%
Para mejorar la calidad: 43%
Para reducir costes: 23%
Para alinear el desarrollo con los objetivos de negocio: 39%
Otras razones: 12%.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto.
Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento.
PROGRAMACIÓN EXTREMA
Es el más destacado de los procesos ágiles de desarrollo de software. pone más énfasis en la adaptabilidad que en la previsibilidad.
Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos.
Simplicidad en el código: es la mejor manera de que las cosas funcionen.
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
Desventajas
Apostolado de metodologías exitosas
Aporte de la experiencia práctica a los modelos teóricos
Enfoque de conjunto de prácticas como rompecabezas
Tecnología en expansión
Importancia de revisitar las metodologías desde la experiencia práctica
Conclusiones
ESPECULACIÓN.
En la que se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se irán realizando.
COLABORAR.
Es aquella en la que se construye la funcionalidad definida durante la especulación.
APRENDER.
Consiste en la revisión de calidad que se realiza al final de cada ciclo.
El desarrollo es iterativo e incremental
Todos los cambios durante el desarrollo son reversibles
El alcance de alto nivel y los requerimientos deberían ser base-lined
Las pruebas son realizadas durante todo el ciclo vital del proyecto
La comunicación y cooperación entre todas las partes interesadas en el proyecto
Ningún sistema es construido a la perfección en el primer intento
La entrega del proyecto debería ser a tiempo, respetando presupuestos y con buena calidad

Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible, dicho enfoque no hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción. Sin embargo, fue diseñado para trabajar con otras actividades de desarrollo de software y no requiere la utilización de ningún modelo de proceso específico.
FDD procesos.
1- Develop an Overall Modell (desarrollar modelo general).
2- Build a Features List (construir lista de rasgos).
3- Plan by Feature (planear por rasgos)
4y5- Design and Build by Feature (diseñar y costruir por rasgos).
DSDM solo requiere que cada paso del desarrollo se complete lo suficiente como para que empiece el siguiente paso.
Dueños de clases
Programadores jefe
Dos aspectos fundamentales a diferenciar
Los actores
Las acciones.
El Product Owner Conoce y marca las prioridades del proyecto o producto.

El Scrum Master es la persona que asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
Método de desarrollo de sistemas dinámicos
Se centra en la entrega frecuente de productos, asumiendo que entregar algo temprano es siempre mejor que entregar todo al final. Al entregar el producto frecuentemente desde una etapa temprana del proyecto, el producto puede ser verificado y revisado allí donde la documentación de registro y revisión puede ser tenida en cuenta en la siguiente fase o iteración.
El Scrum Team son las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner.

Los Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades.
Desarrollar un Modelo
Global Construir una Lista de los Rasgos
Planear por Rasgo
Diseñar por Rasgo
Construir por Rasgo

FDD procesos:
El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar.

El Sprint Backlog corresponde con una o más tareas que provienen del Product Backlog. Las tareas del Sprint Backlog se deben acometer en unas 2 semanas ó 4 semanas. Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas.
que he hecho
que voy a hacer hoy
que ayuda necesito
El Daily Scrum Meeting es una tarea iterativa que se realiza todos los días que dure el Sprint Backlog con el equipo de desarrollo o de trabajo. Se trata de una reunión operativa, informal y ágil, de un máximo de 30 minutos, en la que se le hace 3 preguntas a cada integrante del equipo.
Desarrollo Basado en Funcionalidades
Los desarrolladores entran en dos tipos:

Ya tienen una idea del contexto y los requerimientos del sistema.
Desarrollar modelo general:
En dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades evaluadas por el cliente.
Construir lista de rasgos:
En esta etapa se incluye la creación de un plan de alto nivel, en el cual la features list es ordenada en base a la prioridad y a la dependencia entre cada feature
Planear por rasgos:
El diseño y construcción de la funcionalidad es un proceso iterativo durante el cual las features seleccionadas son producidas.
Diseñar y costruir por rasgos:
Full transcript