scrum

39
SCRUM Carlos Uscamayta

Upload: carlos-uscamayta

Post on 12-Apr-2017

34 views

Category:

Software


0 download

TRANSCRIPT

SCRUMCarlos Uscamayta

¿Por que fallan los proyectos?

¿Por qué fallan los suyos?

La cruda realidad

Causa de Fracasos en los Proyectos

Cronogramas poco realistas Personal inadecuado Cambios en los requerimientos Trabajo de pobre calidad Creer en magia

Winning with Software: An Executive Strategy. Watts S. Humphrey

¿VIAJARÍA USTED EN UN AVIÓN AL QUE USTED LE ESCRIBIÓ EL

SOFTWARE DE NAVEGACIÓN?

Manifiesto ÁgilEstamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientasSoftware funcionando sobre documentación extensivaColaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,valoramos más los de la izquierda.

http://agilemanifesto.org/iso/es/

Los 12 Principios1. Nuestra mayor prioridad es satisfacer al cliente mediante la

entrega temprana y continua de software con valor.2. Aceptamos que los requisitos cambien, incluso en etapas

tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

http://agilemanifesto.org/iso/es/

Los 12 Principios8. Los procesos Ágiles promueven el desarrollo sostenible. Los

promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10.La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11.Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12.A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

http://agilemanifesto.org/iso/es/

Valores

CompromisoEnfoque y FocoApertura y transparenciaRespetoCoraje

Objetivo: Pasar a la otra orilla a pie sin mojarse (sin usar un puente, etc, etc.)

Crecimiento orgánico (iterativo e incremental)

Una mujer con una pradera atrás

Diferencias entre enfoque iterativo y enfoque orgánico (iterativo e incremental)

SCRUM“El Arte de Amar los Lunes”.

Alan Cyment

Scrum es una framework metodológico para la gestión de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New New Product Development Game[Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que: El mercado competitivo de los productos tecnológicos,

además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.

Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.

El mercado exige ciclos de desarrollo más cortos.

SCRUM

Scrum ha sido utilizado por:•Microsoft•Yahoo•Google•Electronic Arts•High Moon Studios•Lockheed Martin•Philips•Siemens•Nokia•Capital One•BBC•Intuit

•Intuit•Nielsen Media•First American Real Estate•BMC Software•Ipswitch•John Deere•Lexis Nexis•Sabre•Salesforce.com•Time Warner•Turner Broadcasting•Oce

Scrum ha sido utilizado para:

Software comercial Desarrollos internos Desarrollos bajo

Contrato Proyectos Fixed-price Aplicaciones Financieras Aplicaciones

certificadas ISO 9001 Sistemas Embebidos Sistemas con requisitos

7x24 y 99.999% de disponibilidad

Joint Strike Fighter

•Desarrollo de video juegos•Sistemas críticos de

soporte vital, aprobados por laFDA

•Software de control satelital

•Sitios Web•Software para Handheld•Teléfonos portátiles•Aplicaciones de Network

switching•Aplicaciones de ISV•Algunas de las más

grandes aplicaciones en uso

CaracterísticasEquipos auto-organizadosEl producto avanza en una serie de

“Sprints" de dos semanas a un mes de duración

Los requisitos son capturados como elementos de una lista de “Product Backlog"

No hay prácticas de ingeniería prescritasUtiliza normas generativas para crear un

entorno ágil para la entrega de proyectosUno de los “procesos ágiles”

Sprints

En Scrum los proyectos avanzan en una serie de “Sprints” Análogo a las iteraciones en XP

La duración típica es 2–4 semanas o a lo sumo un mes calendario

La duración constante conduce a un mejor ritmo

El product es diseñado, codificado y testeado durante el Sprint

Scrum Framework

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Reuniones

•Product backlog•Sprint backlog•Burndown charts

Artefactos

Scrum framework

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Reuniones

•Product backlog•Sprint backlog•Burndown charts

Artefactos

•Product owner•ScrumMaster•Team

Roles

Product Owner

Define las funcionalidades del producto Decide sobre las fechas y contenidos de los releases Es responsable por la rentabilidad del producto (ROI) Prioriza funcionalidades de acuerdo al valor del

mercado/negocio Ajusta funcionalidades y prioridades en cada iteración si es

necesario  Acepta o rechaza los resultados del trabajo del equipo

Product Owner

El espiritu de Scrum. Alan Cyment

El ScrumMaster

Representa a la gestión del proyecto Responsable de promover los valores y

prácticas de Scrum Remueve impedimentos Se asegura de que el equipo es

completamente funcional y productivo Permite la estrecha cooperación en todos los

roles y funciones Escudo del equipo de interferencias externas

El TeamTípicamente de 5 a 9 personasMulti-funcional:

◦ Programadores, testers, analistas, diseñadores, etc.Los miembros deben ser full-time

◦ Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)

Los equipos son auto-organizativos◦ Idealmente, no existen títulos pero a veces se utilizan

de acuerdo a la organización Solo puede haber cambio de miembros entre los sprints

Interacción entre los roles

Fuente: El espiritu de Scrum. Alan Cyment

•Product owner•ScrumMaster•Team

Roles

Scrum Framework

•Product backlog•Sprint backlog•Burndown charts

Artefactos

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Reuniones

Sprint Planning meeting

Priorización• Analizar y evaluar el Product

Backlog• Seleccionar el objetivo del

Sprint

Planificación• Decidir como alcanzar el

objetivo del Sprint (diseño)• Crear el Sprint Backlog

(tareas) en base a los temas del Product Backlog (user stories / features)

• Estimar Sprint Backlog en horas

Objetivo del Sprint

SprintBacklog

Condiciones del Negocio

Capacidad del Equipo

Product Backlog

Tecnología

Producto Actual

Planificación del Sprint El equipo selecciona los temas a partir del Product

Backlog que pueden comprometerse a completar Se crea el Sprint Backlog

Se identifican tareas y cada una es estimada (1-16 horas) Realizado colaborativamente, no solo por el ScrumMaster

El diseño de Alto Nivel es considerado

YO COMO planificador de vacaciones, QUIERO ver fotos de los hoteles. PARA poder mostrar diferentes sitios a mis clientes

Codificar la capa intermedia (8 hs)Codificar la interfaz de usuario (4)Escribir los test fixtures (4)Codificar la clase foo (6)Actualizar test de performance (4)

Daily Scrum Parámetros

Diaria Dura 15 minutos Parados

No para la solución de problemas Todo el mundo está invitado Sólo los miembros del equipo, ScrumMaster y Product Owner,

pueden hablar Ayuda a evitar otras reuniones innecesarias

Todos responden 3 preguntas

No es dar un status report al Scrum Master Se trata de compromisos delante de pares

¿Qué hiciste ayer?1

¿Qué vas a hacer hoy?2

¿Hay obstáculos en tu camino? 3

Sprint review

El equipo presenta lo realizado durante el sprint

Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente

Informal◦ Regla de 2 hs preparación◦ No usar diapositivas

Todo el equipo participaSe invita a todo el mundo

Sprint retrospective

Periódicamente, se echa un vistazo a lo que funciona y lo que no

Normalmente 1 hora Se realiza luego de cada sprint Todo el equipo participa

ScrumMaster Product owner Equipo Posiblemente clientes y otros

Retrospective Por lo general se evalua

Felicidad

Productividad

CalidadEsto es sólo una de las muchas maneras de hacer una retrospectiva.

•Product owner•ScrumMaster•Team

Roles

Scrum framework

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Reuniones

•Product backlog•Sprint backlog•Burndown charts

Artefactos

Ejemplo de Product Backlog

Ejemplo de Sprint Backlog

TareasCodificar UICodificar negocioTestear negocioEscribir ayuda onlineEscribir la clase foo

L8

168

128

M4

1216

8

M J

411

84

V

8

8Agregar error logging

81016

88

Scrum estar acompañado de

buenas prácticas de ingeniería.

Scrum = reglas + espíritu + buenas prácticas