Por Que SCRUM(Indagación)

POR QUÉ UNA METODOLOGÍA EN LUGAR DE OTRA?

Metodologías ÁgilesLa planificación del trabajo sólo comprende el ciclo en el que se está trabajando (normalmente 30 días).

Descubrimiento progresivo de requisitos, e incorporación de cambios en cualquier iteración del desarrollo.

“Refactorización” de código como modelo de trabajo compatible con el punto anterior.

Comunicación directa entre los integrantes del equipo (incluidos cliente y usuarios) prefiriendo la verbal directa.

Equipos auto-gestionados.

No existe contrato tradicional o al menos es bastante flexible.

El cliente es parte del equipo de desarrollo.

Grupos pequeños (hasta 20 integrantes) y trabajando en el mismo sitio.

Pocos artefactos.

Pocos roles.

Menos énfasis en la arquitectura del software.

POR QUÉ UNA METODOLOGÍA EN LUGAR DE OTRA?

Metodologías TradicionalesTrabajo y gestión guiada por un plan general del proyecto que comprende todo su ciclo de desarrollo.

Conocimiento detallado de los requisitos antes de comenzar el diseño del proyecto.

“Hacerlo bien a la primera”. Evitar la re-codificación y el re-trabajo que supone una pérdida de eficiencia.

Comunicación formal según el plan de comunicación del proyecto.

Gestión de equipos y personas centralizada en el gestor del proyecto.

Existe un contrato prefijado.

El cliente interactúa con el equipo de desarrollo mediante reuniones.

Grupos grandes y posiblemente distribuidos.

Más artefactos.

Más roles.

La arquitectura del software es esencial y se expresa mediante modelos.

POR QUÉ SCRUM?? .

SCRUM: http://hipertextual.com/archivo/2012/12/proyectos-agiles-scrum/Está orientada a la obtención de resultados a pesar de que el entorno sea cambiante y los requisitos estén sujetos a cambios o no estén muy bien definidos.

Permite obtener un producto desde el primer momento e, iteración tras iteración, ir haciéndolo crecer añadiendo nuevas funcionalidades vinculadas a los requisitos definidos.

La idea, de manera resumida, es dividir los requisitos (denominado Pila de productos) en sprints, es decir, requisitos que vamos a cumplir en cada una de las fases o iteraciones en las que hemos dividido el proyecto. Desde el final de la primera fase obtendremos un producto funcional y, con cada iteración, el producto irá creciendo y cumpliendo la pila de requisitos definidos. Gracias a esta división en iteraciones, el producto puede adaptarse fácilmente a los cambios en los requisitos y sus ajustes puesto que, al iniciar una nueva iteración, se puede revisar el trabajo realizado o ajustar las idefiniciones que se arrastran en la pila de productos.

.

Característica XP

Heredan modelos X X - -

Independiente de tecnologías - X - X

Documentación estricta X X - -

Estrictamente sistemático X - X -

Más enfocado en los procesos X X - -

Más enfocado en las personas - - X X

Resultados rápidos - - X X

Cliente activo - - X X

Manejo del tiempo X X X X

R e f a c t o r i z a c i ó n del código - - X -

Iterativo X X X X

Respuesta a los cambios - - X X

CONTRASTE DE FORTALEZAS Y DEBILIDADES DE ALGUNAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE

RUP

MSF

SCRUM

Beneficios de la metodología SCRUM: http://blog.gfi.es/gestion-agil-de-proyectos-con-la-metodologia-scrum/Los beneficios que se obtienen son amplios y afectan a todos los actores del proyecto:

Existe una mayor adaptación y flexibilidad ante entornos y requisitos cambiantes, permitiendo la reducción del tiempo de desarrollo de los productos.

Mayor control y transparencia por parte de los Stakeholders sobre el proyecto. El cliente realiza un seguimiento más cercano sin tener que esperar a la entrega del producto, minimizando el riesgo de que el resultado final no le convenza.

Fomento del trabajo en equipo. Se trata de un modelo basado en la autodisciplina y la autogestión repercutiendo en la responsabilidad y en la comunicación entre los distintos miembros del equipo.

Beneficios de la metodología SCRUM: http://blog.gfi.es/gestion-agil-de-proyectos-con-la-metodologia-scrum/

PROCESO "ÁGIL" PARA UN PROYECTO GENÉRICO.

http://teamgantt.com/blog/2014/03/how-to-use-gantt-charts-for-your-agile-project/

http://teamgantt.com/blog/2014/03/how-to-use-gantt-charts-for-your-agile-project/

PROCESO "ÁGIL" PARA UN PROYECTO GENÉRICO.

Proceso de desarrollo a través de una Estructura de División del Trabajo para verlo gráficamente.

PLANIFICACIÓN OBJETIVO:

TAREA:

ENTREGABLE:

ANÁLISIS

OBJETIVO:

TAREA:

ENTREGABLE:

DISEÑO

OBJETIVO:

TAREA:

ENTREGABLE:

CONSTRUCCIÓN Y PRUEBA

OBJETIVO:

TAREA:

ENTREGABLE:

IMPLEMENTACIÓN

http://www.um.edu.ar/catedras/claroline/backends/download.php?url=L01ldG9kb3NfQWdpbGVzL01ldG9kb19BZ2lsX1NjcnVtLnBkZg%3D%3D&cidReset=true&cidReq=II0162004

En esta etapa es importante aclarar que, al comienzo, la planificación se realiza en forma general para determinar el alcance, la duración y el precio del proyecto, una vez que el cliente decide llevarlo a cabo, las siguientes planificaciones son a nivel de iteración, se planifica el Sprint.


IMPLEMENTACIÓN

OBJETIVO:

TAREA:

ENTREGABLE:

Definir proyecto propiamente dicho.

Documento de alcance, casos de uso y sus respectivas descripciones.

El entregable principal es el incremento de software funcionando.


En esta etapa es importante aclarar que, al comienzo, la planificación se realiza en forma general para determinar el alcance, la duración y el precio del proyecto, una vez que el cliente decide llevarlo a cabo, las siguientes planificaciones son a nivel de iteración, se planifica el Sprint.

Relevamiento preliminar de los procesos del negocio, definición y secuenciamiento de actividades, definición del alcance, estimación de tiempos, definición de recursos, análisis de riesgos, estimación de costos.

Documento de definición del proyecto o del Sprint.

Obtener todas las definiciones y especificaciones funcionales para poder llevar adelante las fases de Diseño y Construcción. Es una etapa clave ya que el alcance y las características de la solución quedan acordados, lo cual permite mitigar los principales riesgos de un proyecto.

Afianzamiento de las definiciones funcionales, definición de los requisitos a través de casos de uso, planificación de las etapas posteriores y ajuste de los tiempos preestablecidos.

Generar el modelo de datos para que la solución cumpla con los requerimientos definidos. El diseño generado deberá contemplar las posibles modificaciones futuras, crecimiento de la solución, mayor carga e incorporación de nuevas funcionalidades.

Diagrama Entidad Relación (DER), diseño de las interfaces de usuario, diseño de las integraciones a realizar. Durante esta etapa también se realizan pruebas para puntos críticos del proyecto.

Entre los entregables típicos de esta etapa se encuentran: DER, esqueleto del software armado, guía de diseño, diseño de la infraestructura, y la planificación ajustada con la evolución y avances obtenidos.

Construir la solución del Release (Sprint), cumpliendo con las definiciones y especificaciones de los documentos de alcance. Generalmente es la etapa de mayor duración y con mayor dinámica de trabajo.

Programación y desarrollo de todos los componentes y funcionalidades. Implementación de las estructuras de datos, y sus procedimientos, elaboración de documentación técnica y ajustes funcionales, implementación de las integraciones y todas las actividades necesarias para poner en marcha la solución. En esta etapa se realizaránlas pruebas de usabilidad, funcionalidad y carga de datos.


Disponer del sistema productivo con sus ambientes de producción, metodología de trabajo y manuales operativos. Se incluye, de ser necesario, el personal operativo capacitado. Obtención de nuevas funciones a agregar o posibles errores a reparar.

Puesta en marcha de la aplicación en el ambiente de producción, elaboración de manuales operativos, y todas las actividades relacionadas al éxito del lanzamiento como la integración del ambiente de producción con terceras partes, etcétera.

El sistema productivo con sus manuales operativos, de mantenimiento y de procedimientos. Esquemas de auditoria y seguridad. Integraciones con terceras partes operativas. Sistema totalmente probado.

SPRINT

PLANIFICACIÓN

SE REPITEN POR CADA SPRINT

ANÁLISIS

DISEÑO

CONSTRUCCIÓN Y PRUEBA

IMPLEMENTACIÓN

IMPLEMENTACIÓN

SE REPITEN POR CADA SPRINT

Desarrollo de las fases de un proyecto en SCRUM

3. El desarrollo del SPRINT.

1. Preparación del Proyecto. (SPRINT 0).

2. Planificar un SPRINT.

Desarrollo de las fases de un proyecto en SCRUM

1.1 Las Estimaciones del Backlog.

2.1 La Estimación del SPRINT.2.1.1 Planificación de Póker.2.1.2 Mantener el Blacklog del SPRINT.2.1.3 Interpretación del diagrama de Burndown.

3. El desarrollo del SPRINT.3.1 Reuniones del SPRINT.

3.1.1 Reunión de Planificación (Sprint Planning Meeting)3.1.2 Reunión Diaria (Sprint Daily Meeting)3.1.3 Reunión Revisión del SPRINT (Sprint Review Meeting)3.1.4 Reunión de Retrospectiva (Sprint Retrospective Meeting)

1. Preparación del Proyecto. (SPRINT 0).

2. Planificar un SPRINT.

Por Que SCRUM(Indagación)

Documents

Transcript of Por Que SCRUM(Indagación)