Ingeniera de Requerimientos

SEGUNDA UNIDAD TEMA 12: Metodologas giles en IR

Metodologa SCRUM

Scrum es una metodologa gil de desarrollo de

proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prcticas de produccin por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80. En 1996 se defini por primera vez un patrn para aplicar esos principios de desarrollo en campos de scrum al software. Esta fue la primera definicin de un patrn Scrum aplicado al software, diseada por Jeff Sutherland y Ken Schwaber y presentada en OOPSLA 96.

El Flujo de Scrum

El Flujo de Scrum
Al iniciar cada iteracin, el equipo revisa el trabajo pendiente del proyecto y selecciona la parte que terminar como un incremento de funcionalidad incorporado al software al terminar la iteracin. Al final de la iteracin el equipo presenta el incremento de funcionalidad a las partes implicadas en el proyecto. El equipo revisa los requisitos, considera la tecnologa disponible, evala sus conocimientos, y de forma colectiva determina cmo implementar la funcionalidad.

Por qu Scrum es una Metodologa gil?

Colaboracin estrecha con el cliente Predisposicin y respuesta al cambio Prefiere el conocimiento tcito de las personas al

explcito de los procesos Desarrollo incremental con entregas funcionales frecuentes Comunicacin verbal directa entre los implicados en el proyecto Motivacin y responsabilidad de los equipos por la auto-gestin, auto-organizacin y compromiso. Simplicidad. Supresin de artefactos innecesarios en la gestin del proyecto.

Propietario del producto

Roles en Scrum

Representa a todos los interesados en el producto final. Sus reas de responsabilidad son: Financiacin del proyecto Requisitos del sistema Retorno de la inversin del proyecto Lanzamiento del proyecto
Equipo

Responsable de transformar la pila del sprint (Sprint Backlog) en un incremento de la funcionalidad del software Auto-gestionado Auto-organizado Multi-funcional
Scrum Manager

Responsable del proceso Scrum Formacin y entrenamiento del proceso Incorporacin de Scrum en la cultura de la empresa Garanta de cumplimiento de roles y responsabilidad

Stakeholders en Scrum: Gallinas y Cerdos

Una gallina y un cerdo paseaban por la carretera. La gallina dijo al cerdo: Quieres abrir un restaurante conmigo. El cerdo consider la propuesta y respondi: S, me gustara. Y cmo lo llamaramos?. La gallina respondi: Huevos con jamn. El cerdo se detuvo, hizo una pausa y contest: Pensndolo mejor, creo que no voy a abrir un restaurante contigo. Yo estara realmente comprometido, mientras que tu estaras slo implicada.

Scrum diferencia entre estos dos grupos para garantizar que quienes tienen la responsabilidad tienen tambin la autonoma necesaria para poder lograr el xito, y que quienes no tienen la responsabilidad no producen interferencias innecesarias
COMPROMETIDOS EN EL PROYECTO (cerdos) Propietario del producto Equipo IMPLICADOS EN EL PROYECTO (gallinas) Marketing Comercial Etc.

Sprint
Es el periodo de tiempo durante el que se desarrolla un incremento de funcionalidad. Constituye el ncleo de Scrum, que divide de esta forma el desarrollo de un proyecto en un conjunto de pequeas carreras.

Duracin mxima: 30 das. Durante el sprint no se puede modificar el trabajo que se ha acordado en el Backlog. Slo es posible cambiar el curso de un sprint, abortndolo, y slo lo puede hacer el Scrum Master si decide que no es viable por alguna de las razones siguientes: La tecnologa acordada no funciona. Las circunstancias del negocio han cambiado. El equipo ha tenido interferencias.

Pila del Producto (Product Backlog)

Listado con los requisitos del sistema Es responsabilidad del dueo del producto Contenido Priorizacin Disponibilidad Nunca llega a ser una lista completa y definitiva Es un documento dinmico que incorpora constantemente las necesidades del sistema Se mantiene durante todo el ciclo de vida (hasta la retirada del sistema).

Pila del Producto (Product Backlog)

Estimacin inicial Complejidad

Product Backlog

Estim. ajustada

Trabajo pendiente Sprint

3
0 0 0 0 0 6 0 0 0 0

ID 1 2 3 4 5 6 7

Elemento Nuevo formulario para peticiones de clientes Configuracin de respuestas automticas Envo automtico de respuestas Consulta para los clientes de peticiones enviadas Modificacin del cliente de sus peticiones enviadas Acceso a peticiones slo para clientes del portal jurdico Consulta de peticiones por parte del staff SPRINT 1 2 0.2 2,4 3 0.2 3,6 1 0.2 1,2 1 0.2 1,2 2 0.2 2,4 5 0.2 6 2,4 3,6 1,2 1,2 2,4 6 1,2 18 1,2 3,6 0 0 0 0 0 0 0 0 1,2 3,6 0 0 0 0 0 0 0 0 0 0

1 0.2 1,2 15 18

8 9 10

Insercin de comentarios y reasignacin a peticiones (staff) Consultas por clientes, fechas y temas [Contina].

2 0.2 1,2 3 0,2 3,6

Pila del Sprint (Sprint Backlog)

Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de la funcionalidad. Se recomienda que las tareas reflejadas tengan una duracin comprendida entre las 4 y las 16 horas de trabajo. Las de mayor duracin deben intentar descomponerse en sub-tareas de ese rango de tiempo.

Comunicacin en Scrum

Reunin diaria

Revisin del sprint

Reunin retrospectiva

La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacin cara a cara.

Reunin Diaria
Reunin del equipo con duracin mxima de 15 minutos. Todos los das en el mismo sitio y a la misma hora. Se recomienda que sea la primera actividad del da. Deben acudir todos los miembros del equipo. Moderada por el Scrum Manager, que pregunta a todos los asistentes Cul ha sido el trabajo realizado desde la ltima revisin diaria? Cul es el trabajo previsto para hoy? Hay algo que necesitas, o que te impide realizar el trabajo previsto? No se permite entrar en divagaciones o salirse del guin. Slo habla la persona que informa de su trabajo, el resto escucha y no hay lugar para otras conversaciones. Cuando un miembro informa de algo de inters para otros, o necesita ayuda de otros, estos se renen al terminar la revisin diaria. Las gallinas no pueden intervenir ni distraer, y el Scrum Master puede limitar el nmero de gallinas asistentes si lo considera oportuno.

Revisin del Sprint

Reunin del equipo, Scrum Manager, propietario del producto con todas las personas implicadas en el proyecto (gallinas). Duracin mxima: 4 horas. Finalidad: presentar al propietario del producto y a las gallinas las nuevas funcionalidades implementadas. Las funcionalidades no implementadas no se presentan. En la reunin, los miembros del equipo muestran las nuevas funcionalidades. Al final de la reunin se interroga individualmente a todos los asistentes para recabar impresiones, sugerencias de cambio y mejora, y su relevancia. El propietario del producto trata con los asistentes y con el equipo las posibles modificaciones en la pila de producto.

Reunin Retrospectiva
Acuden el equipo y el Scrum Master, y opcionalmente el Propietario del Producto. Todos los miembros del equipo responden a dos preguntas: Qu cosas fueron bien en el ltimo sprint? Qu cosas se podran mejorar? El Scrum Manager anota todas las respuestas El equipo prioriza las mejoras posibles El Scrum Manager no proporciona respuestas, sino que ayuda al equipo a encontrar la mejor forma de trabajar con Scrum. Las acciones de mejora localizadas que se puedan implementar en el prximo Sprint deben introducirse en la pila de producto como elementos no funcionales.

Metodologa Extreme Programming (XP)

Proceso : conjunto de actividades ordenadas

para lograr una serie de objetivos

Proceso Pesado :
fuerte dependencia de planificaciones se establecen actividades se establecen artefactos se establecen herramientas y notaciones ESTAMOS MUY CONTROLADOS

Extreme Programming - Introduccin Como contraposicin : Mtodologa gil Caractersticas :

A los individuos y su interaccin El software que funciona La colaboracin con el cliente La respuesta al cambio por encima por encima por encima por encima de los procesos y las normas herramientas de la documentacin exhaustiva la negociacin contractual seguimiento de un plan

Extreme Programming - Introduccin Filosofa Estamos menos controlados

Preparados para el cambio Cliente forma parte del equipo Pocos artefactos Ms importante software funcionando que la documentacin

Extreme Programming - Introduccin XP es una Mtodologa gil Desarrollado por Kent Beck
Todo en el software cambia. Los requisitos cambian. El diseo cambia. El negocio cambia. La tecnologa cambia. El equipo cambia. Los miembros del equipo cambian. El problema no es el cambio en s mismo, puesto que sabemos que el cambio va a suceder; el problema es la incapacidad de adaptarnos a dicho cambio cuando ste tiene lugar.

Extreme Programming - Introduccin

Estadsticas : mtodo que ms popularidad ha alcanzado de las metodologas giles Se basa en la suposicin de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo Asume que con un poco de planificacin, un poco de codificacin y unas pocas pruebas se puede decidir si se est siguiendo un camino acertado o equivocado, evitando as tener que echar marcha atrs demasiado tarde.

Extreme Programming - Introduccin Valores que inspiran XP

SIMPLICIDAD FEEDBACK CORAJE COMUNICACIN

Extreme Programming - Introduccin

Simplicidad
La simplicidad consiste en desarrollar slo el sistema que realmente se necesita. Implica resolver en cada momento slo las necesidades actuales.
Los costos y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro.

Con este principio de simplicidad, junto con la comunicacin y el feedback resulta ms fcil conocer las necesidades reales

Extreme Programming - Introduccin

FeedBack
Una metodologa basada en el desarrollo incremental iterativo de pequeas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-informacin valioso para detectar los problemas o desviaciones.
De esta forma fallos se localizan muy pronto. La planificacin no puede evitar algunos errores, que slo se evidencian al desarrollar el sistema. La retro-informacin es la herramienta que permite reajustar la agenda y los planes.

Extreme Programming - Introduccin

Coraje
Implica saber tomar decisiones difciles Reparar un error cuando se detecta Mejorar el cdigo siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora Tratar rpidamente con el cliente los desajustes de agendas para decidir qu partes y cundo se van a entregar

Extreme Programming - Introduccin

Comunicacin
XP pone en comunicacin directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance da a da, y es posible ajustar la agenda y las funcionalidades de forma consecuente.

Extreme Programming Procesos y Fases

1. El cliente define el valor de negocio a implementar 2. El programador estima el esfuerzo necesario para su implementacin 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo 4. El programador construye ese valor de negocio 5. Vuelve al paso 1

Extreme Programming Procesos y Fases

El costo del cambio

Extreme Programming Procesos y Fases

Historias de Usuario
Tcnica para especificar los requerimientos Son tarjetas de papel Debe ser lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas

Extreme Programming Procesos y Fases

Fases
Exploracin Planificacin de la Entrega Iteraciones Produccin Mantenimiento Muerte del Proyecto

Extreme Programming Procesos y Fases

Extreme Programming Roles en XP Los roles siempre presentes en esta metodologa son los siguientes:
Programador Cliente Encargado de pruebas (Tester) Encargado de seguimiento (Tracker) Entrenador (Coach) Gestor (Big Boss)

Extreme Programming Roles en XP Roles Opcionales en los proyectos:

Consultor Doomsayer (Augur de desastres)

Extreme Programming Conclusiones

XP es la metodologa mas popular dentro de la familia surgida luego del manifiesto gil, las cuales buscan simplificar los procesos a travs de la reduccin de irreversibilidad de los mismos . Dicha metodologa ha probado ser de gran utilidad en proyectos pequeos y con requerimientos altamente cambiantes, aunque posee caractersticas que la hacen aplicable en ciertos ambientes nicamente.