5 jorge maestre

Desarro ágil con Scrum o De Pollos y cerdospor jorge maestrevi.vu

6.nov.2007

[vi.vu] - [Scrum: de pollos y cerdos] 2

¿Quién soy?


¿Quién soy?

Jorge MaestreDirector i+d

dnxPrincesa 29, 3ºD28008 MadridTlf.: 91 308 08 90Fax: 91 319 27 95http://www.dnxgroup.comhttp://vi.vu/


Scrum: de pollos y cerdos

Índice:

(1) ¿Scrum?(2) ¿Y qué es el desarrollo ágil?(3) Scrum(4) Scrum en vi.vu(5) ¿Y los pollos y cerdos?



(1) ¿Scrum?


¿Scrum?

¿Qué no es?


¿Scrum?

SCRUM


¿Scrum?

S.C.R.U.M.


¿Scrum?

Scrum!


¿Scrum?

¿Qué es?


¿Scrum?

Scrum = Melé


¿Scrum?


Scrum

Ah! Scrum, ¿y?


Scrum

¿Y qué más es?

Es un método ágil de gestión de proyectos


Scrum

¿Y qué más es?


Descrito por primera vez por Takeuchi y Nonaka en "The New Product Development Game" (Harvard Business Review, Jan-Feb 1986)


Scrum

¿Y qué más es?



Los proyectos con equipos pequeños y multifuncionales históricamente producen mejores resultados


Scrum

¿Y qué más es?




El nombre lo recibe de la similitud entre la melé y las minireuniones diarias propuestas


Scrum

¿Y qué más es?




El nombre lo recibe de la similitud entre la melé y las minireuniones diarias propuestas

Puede ser aplicado en cualquier contexto en el que un grupo de personas necesite trabajar conjuntamente para conseguir una meta común


Scrum

Premisa: Los retos empíricos no pueden ser atendidos satisfactoriamente bajo un control de procesos tradicional


Scrum

Premisa: Los retos empíricos no pueden ser atendidos satisfactoriamente bajo un control de procesos tradicional

Scrum adopta una aproximación empírica aceptando que el problema no puede ser totalmente comprendido o definido, centrándose en maximizar la habilidad del equipo para responder de manera ágil a los desafíos emergentes



(2) ¿Y qué es el desarrollo ágil?


Desarrollo Ágil


Desarrollo Ágil

Situaciones típicas

Es raro especificar todas las características y requisitos de una vez


Desarrollo Ágil



Nadie quiere un cliente que no tiene claros sus requisitos


Desarrollo Ágil




La mayoría de veces se convierte en una entrega incremental a costa de que no sea aceptable para el cliente


Desarrollo Ágil





El cliente no suele ser el usuario final


Desarrollo Ágil






Lo que quiere el usuario final dista de lo que pide el cliente y mucho más de lo que entrega el proveedor


Desarrollo Ágil






Lo que quiere el usuario final dista de lo que pide el cliente y mucho más de lo que entrega el proveedor

El cliente es el enemigo y el usuario también


Desarrollo Ágil

Veamos los principios ágiles...


Desarrollo Ágil

Principios (1):

Satisfacción del cliente por la rápida y continua entrega de software funcional


Desarrollo Ágil


Desarrollo Ágil

Principios (1):


Software completamente funcional liberado frecuentemente (en semanas en vez de meses)


Desarrollo Ágil

“Out of the box”


Desarrollo Ágil

Principios (1):



El software en funcionamiento es la principal medida de progreso


Desarrollo Ágil

Principios (1):




Los cambios de última hora en requerimientos son bienvenidos


Desarrollo Ágil

Principios (1):




Los cambios de última hora en requerimientos son bienvenidos

Cooperación cercana, diaria entre la gente de negocio y los desarrolladores


Desarrollo Ágil

Principios (2):

La mejor comunicación es la comunicación cara a cara


Desarrollo Ágil

Principios (2):


Los proyectos se construyen con gente motivada en los que se confía


Desarrollo Ágil

Principios (2):



Atención continua a la excelencia técnica y al buen diseño


Desarrollo Ágil

Principios (2):




Simplicidad, KISS (Keep It Simple, Stupid)


Desarrollo Ágil

Principios (2):





Equipos auto-organizativos


Desarrollo Ágil

Principios (2):





Equipos auto-organizativos

Adaptación regular a circunstancias cambiantes


Desarrollo Ágil

En definitiva...


Desarrollo Ágil

Una familia feliz...


Desarrollo Ágil

Manifiesto por el Desarrollo Ágil de Software

Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientasSoftware que funciona sobre documentación exhaustivaColaboración con el cliente sobre negociación de contratosResponder ante el cambio sobre seguimiento de un plan

Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda.

Ver Agile Manifesto (http://agilemanifesto.org/)

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler

James GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian Marick

Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas


Desarrollo Ágil

Porqué funciona el desarrollo iterativo:

El 80% del valor de un producto depende del 20% de sus funcionalidades

El cliente obtiene antes un producto funcional

Cuanto antes despliegues un producto antes entra en Beneficios

Tener antes las funcionalidades permite responder mejor a las necesidades reales y futuras

El valor del producto se incrementa frecuentemente con cada iteración

El cliente participa activamente


Desarrollo Ágil

Desarrollo típico de un proyecto


Desarrollo Ágil

Desarrollo de un proyecto ágil


Desarrollo Ágil

¿Dónde está tu proyecto?

Anarquía

Difícil

Sencillo

Complejo

Tecnología

Requisitos

Lejos del acuerdo

Cerca del acuerdo

Cerca de la certeza

Lejos de la certeza


Desarrollo Ágil

Hazlo simple:

Enfréntate al problema poco a poco, en sucesivas iteraciones


Desarrollo Ágil

Hazlo simple:


Parte de lo sencillo, de las cosas pequeñas que aporten valor


Desarrollo Ágil

Hazlo simple:



No hace falta llegar al 100%, de hecho es posible que a priori no se sepa qué es ese 100%


Desarrollo Ágil

Hazlo simple:




Simplifica, reduce la complejidad


Desarrollo Ágil

Hazlo simple:




Simplifica, reduce la complejidad

Lleva tu problema complejo a problemas sencillos



(3) Scrum


Scrum

Carácterísticas (1):

Equipos multidisciplinares y auto-organizativos que favorecen la comunicación verbal entre todos los miembros del equipo y entre de todas las disciplinas involucradas


Scrum



El cliente es parte del equipo de desarrollo


Scrum




Entregas funcionales frecuentes e incrementales ofrecen la oportunidad de validar y verificar cada poco tiempo en vez de al final, reduciendo el coste de reparación


Scrum




Entregas funcionales frecuentes e incrementales ofrecen la oportunidad de validar y verificar cada poco tiempo en vez de al final, reduciendo el coste de reparación

Monitorización y gestión continua por el propio equipo; planes de riesgo y mitigación del mismo conocidos por todos


Scrum


Charlas diarias con el equipo (cumplido, por cumplir, riesgos); de pie y preferiblemente antes de comer si el horario es flexible, preguntando a cada uno de los miembros


Scrum



Transparencia en la planificación y en el desarrollo de módulos, que todos sepan que están haciendo los demás y para cuando


Scrum




Ningún problema se deja debajo de la alfombra; nadie es penalizado por reconocer o identificar un nuevo problema


Scrum




Ningún problema se deja debajo de la alfombra; nadie es penalizado por reconocer o identificar un nuevo problema

Potenciar el puesto y las horas de trabajo, evitar trabajar más horas


Scrum

Roles:

El Dueño del Producto (Product Owner), posiblemente el Product Manager, Sponsor, alguien de marketing o cliente interno


Scrum

Roles:


El ScrumMaster, elimina impedimentos para alcanzar la meta en el Sprint. No es el líder, es más bien el facilitador


Scrum

Roles:


El ScrumMaster, elimina impedimentos para alcanzar la meta en el Sprint. No es el líder, es más bien el facilitador

El Equipo, multidisciplinar y auto-organizado, de no más de 9 personas: QA, desarrolladores, diseñadores, etc.


Scrum

Artefactos:

Pizarra de Producto (Product backlog), lista viva con un listado de todos los trabajos a realizar priorizados según su valor


Scrum

Pizarra de producto (Product Backlog)

55RAUser Acceptance of BPR modelTest124

55IFUser Acceptance of BPR modelTest114

33CMDevelop business process reengineer modelRationalise103

33DBDevelop business process reengineer modelRationalise93

33LPDevelop business process reengineer modelRationalise83

33LPEvaluate analysts outputDelivery72

33CMEvaluate analysts outputEvaluate62

33DBEvaluate analysts outputEvaluate52

22CMAttend Analysis - London West EndAnalysis41

11CMAttend Analysis - NewcastleAnalysis31

11CMAttend Analysis - AberdeenAnalysis21

22LPInterview AnalystsInterview11

Remaining (days)

Estimate (days)OwnerBacklog Item IDSprint


Scrum

Artefactos:


Pizarra de Sprint (Sprint Backlog), lista de los trabajos a realizar en el Sprint en curso, confeccionada a partir de la Pizarra de Producto por el propio Equipo y el ScrumMaster, apoyados por el Dueño del Producto


Scrum

Pizarra de Sprint (Sprint Backlog)


Scrum

Artefactos:


Pizarra de Sprint (Sprint Backlog), lista de los trabajos a realizar en el Sprint en curso, confeccionada a partir de la Pizarra de Producto por el propio Equipo y el ScrumMaster, apoyados por el Dueño del Producto

Burndown Charts, gráficos de seguimiento para cada Sprint; indican las horas restantes para finalizar las tareas de la Pizarra de Sprint, de manera que el último día debieran ser exactamente cero. Dan una idea de la "velocidad de desarrollo". Se podrían mostrar por miembro del equipo, por tarea, etc.


Scrum

Burndown chart ideal


Scrum

Burndown chart lento


Scrum

Burndown chart rápido


Scrum

El Proceso:

El Dueño ajusta la Pizarra de Producto


Scrum

El Proceso:


El Equipo junto al Dueño crean la Pizarra de Sprint


Scrum

El Proceso:



Melé o Minireuniones diarias de pie (máximo 15 min):


Scrum

El Proceso:



Melé o Minireuniones diarias de pie (máximo 15 min):Progreso realizado > ¿Qué has hecho desde ayer?


Scrum

El Proceso:



Melé o Minireuniones diarias de pie (máximo 15 min):Progreso realizado > ¿Qué has hecho desde ayer?Siguiente trabajo a realizar > ¿Qué vas a hacer mañana?


Scrum

El Proceso:



Melé o Minireuniones diarias de pie (máximo 15 min):Progreso realizado > ¿Qué has hecho desde ayer?Siguiente trabajo a realizar > ¿Qué vas a hacer mañana?Avisar de impedimentos > ¿Algún problema para cumplir tu objetivo?


Scrum

El Proceso:




Breve sesión de planificación para determinar la Pizarra de Sprint de la siguiente iteración


Scrum

El Proceso:




Breve sesión de planificación para determinar la Pizarra de Sprint de la siguiente iteración

Breve sesión retrospectiva en la que todos los miembros del Equipo reflexionan sobre el último Sprint realizado


Scrum

El Proceso:



(4) Scrum en vi.vu


Scrum en vi.vu

vivu (esperanto)

1. viv/i vida 2. tra~i experiencia, sobrevivir 3. vivu! larga vida! 4. ~teni apoyo

.vu

Dominio para la nación isleña del Pacífico llamada Vanuatu, el lugar más feliz del mundo según The Happy Planet Index


Scrum en vi.vu

¿Qué es vivu?

Vi.vu persigue ayudar a mejorar la vida de la personas, hacerlo fácilmente, hacerlo sin fronteras (globalmente), hacerlo colaborativamente, … hacerlo bien.

El equipo que forma vi.vu ha decidido centrarse en el ser humano (el usuario), como eje central del cambio de los procesos de las empresas vinculadas con la salud y bienestar de las personas.

Vivu ofrece el poder, la posibilidad de tener una mejor vida, basada en la colaboración entre personas para acceder a servicios sanitarios de calidad.


Scrum en vi.vu

http://vi.vuhttp://blog.vi.vu


Scrum en vi.vu

¿Por qué nos va bien?

Scrum es una metodología flexible y adaptativa para el desarrollo de software.

La posibilidad de ajustarla tras cada iteración a las preferencias del equipo, a la cultura de la empresa o a ciertos momentos de interés, permiten que el punto de partida no sea necesariamente relevante.

Nuestro objetivo es que el laboratorio sea fiel a la realidad y por eso hemos planeado 5 o 6 interacciones antes de salir al mercado, ya con el producto fuera aportaremos mejoras con cada iteración.


Scrum en vi.vu

Ejemplo de Sprint de 4 semanas (20 días laborables)

Día 1. Reunión de planificación del Sprint, 1º segmento - 3.5 horas

Día 1. Reunión de planificación del Sprint, 2º segmento - 3.5 horas

Cada día de trabajo entre 1 y 20. Reunión diaria de pie antes de comer.

Día 20. Reunión de revisión del Sprint - 3.5 horas

Día 20. Reunión retrospectiva del Sprint - 3.5 horas


Scrum en vi.vu

Historias de usuario (1)

El primer paso es crear la Pizarra de Producto:

Capturar los requisitos en forma de “historias de usuario”: breve descripción de funcionalidades relevantes


Scrum en vi.vu




Retardar el análisis detallado todo lo que se pueda


Scrum en vi.vu





Se analizarán en detalle cuando se vayan a implementar


Scrum en vi.vu






Dan la información necesaria para que desarrolladores y clientes se entiendan


Scrum en vi.vu






Dan la información necesaria para que desarrolladores y clientes se entiendan

Permiten estimaciones iniciales (en NUTs) y priorización de funcionalidades


Scrum en vi.vu


Aproximación más humana para clientes y desarrolladores


Scrum en vi.vu



El cliente puede descubrir nuevas funcionalidades e incorporarlas como nuevas historias a priorizar en la siguiente iteración


Scrum en vi.vu




Minimiza la pérdida de tiempo de análisis y documentación de problemas que pueden ser no válidos cuando el equipo se enfrenta a ellos


Scrum en vi.vu




Minimiza la pérdida de tiempo de análisis y documentación de problemas que pueden ser no válidos cuando el equipo se enfrenta a ellos

Lo que interesa es aportar más valor, ¿no?


Scrum en vi.vu

Funcionalidades en vez de actividades (1)

En cada iteración, al crear la Pizarra de Sprint:

Define en detalle las funcionalidades del Sprint a partir de las historias de usuario


Scrum en vi.vu




El estado de proyecto se mide por funcionalidades acabadas


Scrum en vi.vu





Tras cada ciclo, una funcionalidad está acabada o no lo está


Scrum en vi.vu





Tras cada ciclo, una funcionalidad está acabada o no lo está

Acabada quiere decir que funciona, satisface los requisitos del cliente y está lista para desplegar con la documentación necesaria


Scrum en vi.vu


Con el cliente utiliza listas de funcionalidades en vez de plan de proyecto


Scrum en vi.vu



Cuando exista algún problema comunícalo cuanto antes al cliente, tu trabajo es que no parezca un idiota ante sus jefes


Scrum en vi.vu




Deja a los miembros de equipo elegir la tarea en la que trabajar


Scrum en vi.vu





Deja a los miembros del equipo realizar la estimación de sus tareas


Scrum en vi.vu






Trabajar en parejas(peer programming) también minimiza riesgos y ayuda a difundir el conocimiento


Scrum en vi.vu






Trabajar en parejas(peer programming) también minimiza riesgos y ayuda a difundir el conocimiento

Actualización diaria del estado de las funcionalidades



(5) ¡Espera! ¿Y los pollos y cerdos?


¿Y los pollos y cerdos?

La historia dice algo así...



Un pollo y un cerdo estaban hablando sobre montar un negocio juntos. El cerdo le pregunta al pollo:

¿Qué tipo de negocio montamos?



El pollo se lo piensa un momento y dice:

¿Qué te parece un restaurante?



Al cerdo le parece bien la idea y pregunta:

¿Y qué damos de comer?



Huevos con jamón



Entonces el cerdo, contrariado, se niega a continuar el trato más allá y el pollo confundido le pregunta:

¿Por qué te enfadas?



A lo que responde el cerdo:

Pues porque mientras tu tan sólo estarás implicado, yo estaré

totalmente comprometido



Moraleja: “O nos implicamos todos, o

esto no sale”



¿Quién es el pollo y quién es el cerdo?

Cerdos: aquellos que tiene alguna tarea de desarrollo asignada (desarrolladores, diseñadores, administradores o probadores)

Pollos: implicados que no tienen tareas (cliente, dueño del proyecto, colaboradores, etc)


No lo olvides

Frases míticas y otras yerbas:

Ken Schwaber, co-fundador de Scrum, al ser preguntado en Abril de 2004 en Viena: “Don’t procrastinate, do something, no matter how small…” > “No lo demores, haz algo, por poco que sea...”

“Scrum: the ethos of simplicity and the art of the possible” > “Scrum: el Ethos de la sencillez y el Arte de lo posible”

“Olvida las especificaciones, el análisis, la documentación, incluso el propio método... Lo importante es crear algo que aporte valor” - Yo


No lo olvides

Resumiendo...

Asume el cambio como parte del proyecto1.


No lo olvides

Resumiendo...

Asume el cambio como parte del proyecto1.El cliente es parte de tu equipo2.


No lo olvides

Resumiendo...

Asume el cambio como parte del proyecto1.El cliente es parte de tu equipo2.Haz lo que sea, pero hazlo3.


No lo olvides

Resumiendo...

Asume el cambio como parte del proyecto1.El cliente es parte de tu equipo2.Haz lo que sea, pero hazlo3.La propia metodología es cuestionable4.

Para más información...


Enlaces de interés

List of software development philosophies: http://en.wikipedia.org/wiki/List_of_software_development_philosophiesAgile Manifesto: http://agilemanifesto.org/Agile software development: http://en.wikipedia.org/wiki/Agile_software_developmentAgile Alliance: http://www.agilealliance.org/Scrum en Wikipedia: http://en.wikipedia.org/wiki/Scrum_(management)Extreme Programming en Wikipedia: http://en.wikipedia.org/wiki/Extreme_ProgrammingKISS: http://en.wikipedia.org/wiki/KISS_principleScrum Alliance: http://www.scrumalliance.org/Control Caos: http://www.controlchaos.com/Adaptive Project Management Using Scrum: http://www.methodsandtools.com/archive/archive.php?id=18The Scrum Development Process: http://www.mountaingoatsoftware.com/scrumFeature Driven Development (FDD): http://en.wikipedia.org/wiki/Feature_Driven_Development


Libros

Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-XAgile Software Development with Scrum, Ken Schwaber and Mike Beedle, Prentice Hall, 2001, 150pp, ISBN 0130676349Agile Estimating and Planning, Mike Cohn, Prentice Hall PTR, November 2005, 368pp, ISBN-10: 0131479415The Enterprise and Scrum, Ken Schwaber, Microsoft Press, June 2007, 240pp, ISBN-10: 0735623376Agile Project Management: Creating Innovative Products, Jim Highsmith, Addison-Wesley Professional, April 2004, 312pp, ISBN-10: 0321219775


Derechos

5 jorge maestre

Documents