Scrum. Framework ágil de procesos

Transcripción

1 Scrum Framework ágil de procesos

2 Definición Scrum is an Agile (incremental and iterative) process framework for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. Scrum allows organizations to continuously direct the project toward early delivery of real business value through the frequent and regular delivery of high quality software.

3 Definición Es un esquema simple para manejar proyectos complejos y de diverso tipo. Se basa en un set mínimo de reglas y prácticas claras y directas. Su enfoque asombra por la falta de prescripción (muy abierto). Engloba buenas prácticas de ingeniería. Maneja conflictos de intereses y necesidades, y tiene un modelo de equipo.

4 Motivación A diferencia de enfoques tradicionales, se busca manejar la complejidad de proyectos al descentralizar el control. Se busca disminuir el ciclo de interacción entre cliente y desarrollador, entre lista de deseos e implementación. En escenarios simples, es fácil predecir, pero en escenarios complejos, se debe ajustar la visión a medida que se avanza. Defined Process Control vs. Empirical Process Control

5 Empirical Process Control Problemas complejos se comportan en forma impredecible. Cuando se conocen los detalles y son repetibles: son definidos. Si no se conocen, se adopta enfoque empírico. Tres elementos: Visibilidad: aspectos del proceso que afectan el resultado están claros y entendidos por todos. Inspección: revisión frecuente (lo justo y necesario para no sobrepasar la tolerancia). Adaptación: si en la inspección se determina que hay aspectos fuera de los límites, se deben hacer cambios lo más pronto posible.

6 Historia de Scrum Primer enfoque: The New New Product Development Game (Harvard Business Review 1986) Segundo enfoque: The Knowledge Creating Company (Oxford University Press, 1995) Ambos de Ikujiro Nonaka y Hirotaka Takeuchi, bajo un trabajo denominado Controlled-Chaos Software Development. Se presentó como modelo de desarrollo de software al Object Management Group en 1995, por Jeff Sutherland y Ken Schwaber. Desde entonces se ha hecho evolucionar a cumplir con los desafíos en la práctica de diversas empresas, desarrollando software nuevo o haciendo reingeniería sobre proyectos legados.

7 Scrum Workflow

8 Scrum

9 Preparación Caso de negocio y financiamiento. Visión. Entendimiento de la esencia del proyecto. Product Backlog inicial. Plan inicial de entregas. Involucramiento de los Stakeholders correctos. Assemble team. Logistics.

10 Roles Principales: Scrum Master Product Owner Team Otros: Stakeholders Users Son representados por PO

11 Procesos

12 Artefactos Product Backlog Sprint Backlog Product Burndown Chart Sprint Burndown Chart Product Backlog Delta Report

13 Product Backlog Descripción Estimac. inicial Ajuste Estimac. ajustada Iter 1 Iter 2 Iter 3 Llenar formulario de datos de cotización 3 0,2 3,6 3,6 0 0 Modificar datos de cotización Consulta/Búsqueda de cotizaciones por cliente y por fecha 3 0,2 3,6 0 1,8 1,8...

14 Burndown Chart

15 Sprint Backlog Descripción Origen Responsable Estado Iter 1 Iter 2 Iter 3 Crear BD Pedro Pedro Termina da Crear Tablas Modelo 1 Pedro Jorge Termina da Instalar servidor Web y configurar seguridad Implementar Proc. Almacenados de para Cotizaciones José José En progreso Pedro Jorge No iniciada

16 Reglas Sprint Planning Meeting Dos sesiones de cuatro horas. La primera se define el Backlog y en la segunda se prepara el Sprint. Si se pasan las 4 horas, mayor análisis se hace durante el sprint. Sólo participan SM, PO, T. Invitados puntuales. PO prepara el backlog antes de la reunión. T puede sugerir backlog, pero el que corta es PO. T define cuánto se puede hacer en un sprint Sprint Backlog.

17 Reglas Daily Scrum Meeting 15 minutos, nada más. Al comienzo del día. Mismo lugar, misma hora. Puntual! Todos deben ir. Si alguien falta, se debe poner al día lo antes posible. SM dirige y pregunta a c/u: Qué hiciste desde el último Scrum Meeting? Qué harás antes del próximo? Qué obstáculos visualizas? Respuestas precisas por parte del T. Si hay temas que analizar en detalle, se define reunión separada. Chickens: no participan ni opinan. Son limitados en su asistencia y se les puede prohibir.

18 Reglas Sprint 30 días calendario. T puede recibir ayuda externa, pero es autosuficiente respecto al equipo de proyecto. Se compromete el Prod. Backlog y PO no lo puede cambiar en los 30 días. El T puede solicitar eliminación/adición de funcionalidades si lo considera necesario. Si hay justificación mayor, SM puede abortar Sprint. Obligaciones del T: ir al Daily Scrum, mantener Sprint Backlog al día y visible.

19 Reglas Sprint Review Meeting Duración 4 horas. Preparación 1 hora. T presenta al PO y stakeholders la funcionalidad entregada y nada más. Idealmente, se muestra en PC del T y ojalá en ambiente QA. Se presenta la meta del Sprint y lo realizado (Backlogs). Stakeholders opinan 1 x 1 al final. PO comenta con stakeholders y T posibles mejoras.

20 Opiniones y comparación n XP Scrum for VSTS I like agile (but not really XP) methodologies, so it's intriguing news to see Scrum for Team System released. Now we have an almost extreme methodology for the heavy weight version of Visual Studio. Let's see what it becomes. There is nothing extreme about Scrum. Furthermore, Scrum is not enough by itself. It does nothing for the development team and one month iterations are too long. Scrum offers some benefit to the project manager (Scrum Master) and to the customer in that it increases visibility. But honestly, most people "like Scrum" over XP simply because it's easier. It's easier because there's less discipline, fewer practices and overall thre's really nothing to it. Quite honestly, you can't even compare Scrum to XP. Truly agile teams require the disciplines of XP in my opinion...