Agile Scrum

21
Indice Introducción………………………………………………………………………………3 Método de desarrollo Agile Scrum…………………………………………………….4 Historia…………………………………………………………………………………4 Características del método de desarrollo Agile Scrum……………………………...7 Componentes de Scrum………………………………………………………………...8 Métricas de Scrum………………………………………………………………………13 Conclusión……………………………………………………………………………….15 Bibliografía………………………………………………………………………………..16 1

description

Metodologías Agile Scrum

Transcript of Agile Scrum

Indice

Introduccin3 Mtodo de desarrollo Agile Scrum.4 Historia4Caractersticas del mtodo de desarrollo Agile Scrum...7

Componentes de Scrum...8

Mtricas de Scrum13

Conclusin.15

Bibliografa..16

Introduccin

Scrum es un mtodo de desarrollo gil de software muy simple, especialmente enfocado para proyectos donde se necesita obtener resultados pronto y los requerimientos son cambiantes segn la necesidad del cliente.Scrum tiene como base la creacin de ciclos breves para el desarrollo, llamados iteraciones, en Scrum se llaman Sprint. Este sprint por lo general tienen una duracin de 2 a 4 semanas cada uno. Los sprint, producen un incremento de funcionalidad terminado y operativo. Cada sprint tiene una fecha de finalizacin.Se centra en los requerimientos con ms prioridad y que pueden ser ejecutadas en un periodo corto de tiempo. Scrum gestiona su evolucin a travs de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el da anterior y el previsto para el da siguiente. Scrum es adaptable ms que predictivo. Se enfoca a las personas ms que a los procesos. Scrum tiene los siguientes componentes (elementos) de la metodologa.

Reuniones: Planificacin del Backlog Seguimiento del Sprint Revisin del Sprint

Herramientas Product Backlog Sprint Backlog Incremento

Roles y responsabilidades

A. Son parte fundamental del proyecto. Scrum Master Product Owner Scrum Team

B. No son parte del proceso Scrum. Usuarios Stakeholders Managers

Practicas: Sprints Sprint Planning Meeting Daily Meetings Sprint Review Meeting Design Review Meeting Stabilization Sprints Meta Scrums1

Mtodo de desarrollo Agile Scrum

Historia

El nombre Scrum proviene del deporte de Rugby. Donde se adquiere la idea de formar un grupo de jugadores alrededor del baln y todos trabajan juntos, en ocasiones con violencia para poder moverlo a travs del campo.

Mtodo de desarrollo gil de software concebido por Jeff Sutherland a inicios de loa aos 90 y elaborado ms formalmente por Ken Schwaber. Poco despus Sutherland y Schwaber se unieron para refinar y extender la metodologa SCRUM y ha llegado a ser conocida como una herramienta de hiperproductividad.

Schwaber se dio cuenta de que un proceso necesita aceptar el cambio, en lugar de esperar predictibilidad, esto enfocado en el hecho de que procesos definidos y repetibles slo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles. Tomar el cambio como una forma de entregar al final del desarrollo algo ms cercano a la verdadera necesidad del Cliente fue entonces su solucin.

Scrum es flexible para gestionar el desarrollo de software. Su base consiste en construir primero la funcionalidad de mayor valor para el cliente.Esta metodologa de trabajo promueve la innovacin, motivacin y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un mbito propicio para desarrollar sus capacidades.

Scrum se utiliza para guiar actividades de desarrollo dentro de un proceso de anlisis que tiene las siguientes actividades estructurales: Requerimientos Anlisis Diseo Evolucin Entrega

Dentro de cada actividad las tareas del trabajo ocurren con un patrn del proceso llamado sprint. El trabajo realizado dentro de un sprint se adapta al problema en cuestin, se define y es muy usual que se pueda modificar en tiempo real por parte del equipo.

La siguiente imagen muestra el Proceso Scrum.

Scrum utiliza un conjunto de patrones de proceso del software que son muy eficaces para proyectos con plazos de entrega muy cortos, requerimientos cambiantes y negocios crticos. Cada uno de estos patrones de proceso define un grupo de acciones de desarrollo:

Retraso: Lista de prioridades de los requerimientos del proyecto que dan al cliente. Es posible agregar en cualquier momento otros requerimientos al retraso; de sta manera es como se introducen los cambios. El gerente del proyecto evala el retraso y actualiza las prioridades segn se requiera.

Sprints (iteracin): Unidades de trabajo que se necesitan para alcanzar un requerimiento definido en el retraso que debe ajustarse en una caja de tiempo predefinida (das). Durante el sprint no se introducen cambios. Permite a los miembros del equipo trabajar en un ambiente de corto plazo pero estable. Las reuniones de seguimiento de cada sprint deben ser diarias.

Reuniones Scrum: Son reuniones breves (15 minutos) que el equipo efecta a diario, dirigida por un lder llamado Maestro Scrum, que tambin evala las respuestas de cada persona. Hay tres preguntas clave que se pide que respondan todos los miembros del equipo, las cuales son: Qu hiciste desde la ltima reunin del equipo? Qu obstculos ests encontrando? Qu planeas hacer mientras llega la siguiente reunin del equipo?

La junta Scrum ayuda al equipo a descubrir los problemas potenciales tan pronto como sea posible.

Demostraciones preliminares: Entregar el avance de software al cliente de modo que la funcionalidad que se haya implementado pueda demostrarse al cliente y ste pueda evaluarla. Es importante aclarar que las demostraciones preliminares no contienen toda la funcionalidad planeada, sino que stas se entregarn dentro de la caja de tiempo establecida.

Una caja de tiempo: Trmino de la administracin de proyectos que indica el tiempo que se ha asignado para cumplir alguna tarea.

Caractersticas del mtodo de desarrollo agile-Scrum.

Flexibilidad a cambios: Diseado para permitir realinear el software con los objetivos de negocio de su empresa en cualquier momento, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteracin sin ningn problema.Reduccin del Time to Market:El cliente puede empezar a utilizar las funcionalidades ms importantes del proyecto antes de que est finalizado por completo.Mayor calidad del software:Versin funcional despus de cada iteracin, ayuda a la obtencin de un software de calidad superior.

Mayor productividad: Scrum divide un proyecto en iteraciones 15-30 das. Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto.

Maximiza el retorno de la inversin (ROI):Produccin de software nicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorizacin por retorno de inversin.Predicciones de tiempos: Durante cadasprint, un periodo entre 15 y 30 das, el equipo crea un incremento de softwarepotencialmente entregable(utilizable). Reduccin de riesgos:Llevar a cabo las funcionalidades de ms valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada.

Inters departe del Cliente: Con la metodologa Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteracin a iteracin. El equipo desarrollador tiene una comunicacin constante con el cliente.

Sencillo: Scrum es muy fcil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. Tambin se enfoca principalmente en la planeacin iterativa y el seguimiento del proceso.

Orientado a personas: Scrum es orientados a objetos y no orientado a procesos.

Entre otras caractersticas:

Equipos autodirigidos Utiliza reglas para crear un entorno gil de administracin de proyectos No prescribe prcticas especficas de ingeniera Los requerimientos se capturan como tems de la lista Product Backlog El producto se construye en una serie de Sprints de un mes de duracin.

Componentes de Scrum:

Reuniones Planificacin del Backlog:

Reunin previa al comienzo de cada sprint: a) Requisitos del sistema por prioridades.b) En el Sprint 0 se indican los objetivos a cumplir en esta iteracin. c) Intervienen todos los roles. d) Sprint Backlog o lista de tareas que se van a realizar y el objetivo ms importante del Sprint.

Seguimiento del Sprint:Breve reunin diaria para repasar cada una de las tareas y el trabajo previsto de la jornada.1. Solo interviene el equipo de desarrollo.2. Cada miembro responde a tres preguntas fundamentales:

a) Trabajo realizado desde la reunin anterior.b) Trabajo que se va a realizar hasta la prxima reunin de seguimiento.c) Problemas que se deben solucionar para realizar el trabajo propuesto.

Revisin del Sprint: a) Anlisis y revisin al finalizar el Sprint del incremento generado.b) Presentacin de resultados, como demo o versin, esto ayudar al mejorar el feedback con el cliente.

Elementos: Product Backlog:

a) Todos los integrantes del equipo de desarrollo pueden acceder a l y aportar ideas.b) Lista creada por el cliente con ayuda del Scrum Master.c) Lista de requisitos o necesidades del cliente.d) Funcionalidades o requisitos en forma de lista priorizada, que el producto ir adquiriendo en sucesivas iteraciones.

Sprint Backlog:

a) Lista de trabajos que realizar el equipo durante el sprint.b) Incremento previsto para el sprint.c) Compromiso de ejecucin.d) Asignacin de tareas a cada persona, con estimaciones de tiempo y recursos necesarios.

Incremento:

a) Demostracin de los objetivos alcanzados en cada sprint.b) Asistencia de todos los roles.c) Segn los resultados mostrados, el cliente puede ir haciendo cambios necesarios e ir replanteando el proyecto.d) Solo el Scrum Master puede abortar un sprint debido a que la tecnologa seleccionada no funciona o es incompatible con los objetivos definidos, cambian las circunstancias del negocio, el Scrum Team ha tenido inferencias.

Roles y responsabilidades Personas que estn comprometidas con el proyecto y el proceso Scrum. Scrum Master: a) Selecciona los procesos y trabaja de forma similar al director de proyecto. b) Los equipos son conformados por 10 personas con jerarquas, estametodologa es aplicada a proyectos que involucran a ms de 600personas.c) Responsable del rea de gestin de proyectos, tiene el conocimiento sobre desarrollo gil y facilita los recursos necesarios. d) Comprueba que el modelo y metodologa funciona.e) Interacta con el cliente. f) Indica al cliente el coste estimado para completar cada requisito.g) Velar por el buen funcionamiento del equipo de desarrollo.

Product Owner: a) Conoce sobre el entorno del negocio del cliente y la visin del producto. b) Propietario del Producto.c) Responsable de la Financiacin del Proyecto.d) Representa a losstakeholders(clientes externos o internos). e) Se encarga de escribir las ideas del cliente y las ordena por prioridad.f) Crea y mantiene en detalle el product backlog. Scrum Team: a) Grupo pequeo que van desde 5 9 personas.b) Incluye a los desarrolladores. c) Se auto-gestionan y se auto-organizan.d) Cubren todas las habilidades necesarias para generar el resultado.

No son parte del proceso Scrum, pero son importantes para la retroalimentacin de la salida del proceso y de esa manera planear y revisar cada Sprint.

a) Usuarios: Destinario final del producto.

b) Stakeholders: Personas a las que el proyecto les producir un beneficio. Participan en las revisiones de los Sprints.

c) Managers: Toma las decisiones finales participando en la seleccin de los objetivos y de los requisitos.

Mtricas de Scrum

Las mtricas constituyen un disparador para analizar la productividad y el desempeo del equipo con el fin de detectar falencias y aciertos. Estas mtricas fueron tiles para ganar previsibilidad en los trabajos o proyectos a desarrollar y as cumplir los objetivos del proyecto y lograr sobre todo la satisfaccin del cliente y evitar el fracaso en el proyecto. Puesto que uno de los principales motivos es la falta o inadecuada planificacin y un punto crucial en las planificaciones es la estimacin del tamao del producto.

En Scrum se suele utilizar user stories como unidad de requerimiento (registrarlos) aunque el rol especifico lo tiene el product owner que es el encargado de transmitir oralmente los deseos, necesidades y expectativas, los user story son usados en la sesin de planning y en daily meeting para que el equipo pueda determinar la funcionalidad y conozca en que grado se encuentra. Las mismas se pueden estimar a travs de una medida de tamao relativa: story points.

Con el fin de disponer de mtricas para tener conocimiento del rendimiento del equipo y lograr mejorarlo, Sutherland et al [7] definieron e implementaron el siguiente conjunto de mtricas:

Velocity. Determina qu tamao de software (que satisfaga al product owner)el equipo puede conseguir en un sprint. Es la suma de los story pointsoriginalmente estimados para cada story, pero considerando solamente las user stories que fueron aprobadas por el product owner.Work capacity. Determina el tamao del trabajo que puede hacer un equipo en unsprint. El equipo puede haber dedicado esfuerzo a user stories que no fueron aceptadas por el product owner, y work capacity es la suma de todo el esfuerzo reportado durante el sprint, haya resultado en una user story aceptada o no.Focus factor. Determina qu porcentaje del esfuerzo invertido termina siendo aceptado por el cliente. Se define como velocity / work capacity.Adopted work. El equipo es el que determina qu user stories se comprometea realizar, por lo cual, esta medida se define como el cociente entre el esfuerzo realizado por encima de lo originalmente comprometido.Found work. Se define como la diferencia entre lo originalmente estimado y lo finalmente reportado, dividido lo originalmente comprometido.Accuracy of estimation. Mide la precisin con que se estim el tamao de cada una de las user stories. Se define como la suma de todos los deltas (tamao final reportado menos el tamao original estimado), dividindolo por la suma total de lo reportado, para finalmente restar a 1 este valor.Accuracy of commitment. Establece el margen de error sobre la porcin detrabajo que compromete el equipo. Se define como el cociente entre la suma de todas las estimaciones iniciales por un lado, y por otro la suma de las estimaciones iniciales, adopted work y found work.Las lecciones aprendidas de la experiencia de implantacin de las mediciones basadas en tamao con el fin de utilizar las mtricas descriptas son dos:

1. La importancia de la piedra angular para registrar el avance. 2. Cmo registrar el avance cuando no hay avance.Piedra angular: Es el punto de referencia a partir del cual y por comparacin se realizan las estimaciones de tamao relativo de los distintos productos a construir.

Ejemplos de mediciones reales

A continuacin se exponen algunos indicadores de proyectos Scrum, los cuales en la vida real es lo que se entrega a lder. Bajo el enfoque predictivo tradicional, elnfasisest en medir el progreso del proyecto, en relacin con la fecha y presupuesto comprometido originalmente, mientras que bajo el desarrollo gil, se colocanfasisen medir el desempeo del equipo en funcin de historias e items de retrasos, deuda tcnica y velocidad, en iteraciones de tiempo y esfuerzo fijas.

1. Medidas para analizar y mejorar la productividad del equipo.

2. Comparacin de Velocity y Work Capacity a lo largo del proyecto.

Conclusin

Vivimos en un mundo de datos e informacin. Algunas personas tienen una forma de pensar que los nmeros diagnostican todos los problemas. Recordemos que solo muestran los datos". Sin embargo, muchos directivos sugieren ver de indicadores concretos de productividad y la eficiencia del equipo de Scrum. De otro modo tomara mucho tiempo observar el desarrollo del proceso, pocos lderes estn dispuestos a tomar este tiempo, delegan esta tarea sntesis informacin a los administradores a travs de la solicitud tpica informe.

El ciclo de vida definido por Scrum es incremental iterativo y se caracteriza por ser muy adaptable. Fomenta el surgimiento de equipos autodirigidos cooperativos y aplica inspecciones frecuentes como mecanismo de control.Sin embargo Scrum funciona bien slo si las entradas estn perfectamente definidas y el ruido, ambigedad o cambio es muy pequeo. Por lo tanto, resulta ideal para proyectos con requerimientos inestables, ya que fomenta el surgimiento de los mismos.

Desde este punto de vista, en todo proceso es importante las evaluacin de proyectos, en el caso del desarrollo aplicando Agil Scrum no es la excepcin. Por lo tanto, lo cierto es que aplicar desarrollo gil no significa que las mediciones van a desaparecer, simplemente cambiaremos lo que se medir y como.Nos guste o no, las mtricas y los reportes a los niveles superiores en las organizaciones son parte de la vida profesional.

Bibliografa

Ingeniera del software, Un Enfoque Prctico, Sptima Edicin, Roger S. Pressman.

http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-scrum.html

ingenieriadesoftware.mex.tl

Aplicacin para la gestin de proyectos giles con Scrum, Jess Mara Eraso Lerena, Universidad de la Rioja.Gestin de proyectos informticos, metodologa Scrum, Manuel Trigas Gallego.

SCRUM Metodologa de trabajo gil, Jess Cceres Tello, Universidad de Alcal.

Mtricas de scrum http://agilemanifesto.org/

Sutherland J, Downey S (2010) Scrum metrics for hyper productive teams. Agile 2010 Conference. Orlando, Florida. Disponible en: http://www.agile2010.org/

Video recomendado para el uso del mtodo de desarrollo de Scrum.https://www.youtube.com/watch?v=PlLHc60egiQ11