scrum
TRANSCRIPT
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
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/
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
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
•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 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