Está en la página 1de 71

Desarrollo

de
Software

Lean
Agile

Scrum

Desarrollo gil de software,


Scrum
Pablo Lischinsky
@pablolis

Pablo Lischinsky - Evolucin gil C.A. 2014

Agenda
Antecedentes y motivacin
Agilidad y el Agile Manifesto
Framework Scrum
Manejo de requisitos: User Stories y Backlog
Cmo comenzar
Referencias

Pablo Lischinsky - Evolucin gil C.A. 2014

Redeniendo el xito de un proyecto


Tcnico

Organizacional

Personal

Pablo Lischinsky - Evolucin gil C.A. 2014

Redeniendo el xito de un proyecto


A quines impacta?
Cliente
Usuarios, Interesados
Equipo de desarrollo
Organizacin

Pablo Lischinsky - Evolucin gil C.A. 2014

Project Success Sliders (Mike Cohn)

http://www.mountaingoatsoftware.com/tools/project-success

Pablo Lischinsky - Evolucin gil C.A. 2014

Takeuchi y
Nonaka, HBR,
1986

Desarrollo de
software
iterativo e
incremental

Built-in instability
Self-organizing teams
Overlapping development phases
Multilearning
Subtle control
Organizational transfer of learning

SCRUM
Priorizacin/
Pareto

Pablo Lischinsky - Evolucin gil C.A. 2014

Timeboxing

Priorizacin y el principio de Pareto


O principio del 80/20
20% causas

80% efectos

Pablo Lischinsky - Evolucin gil C.A. 2014

Funcionalidades utilizadas en un software


El 64% Nunca o
rara vez se utiliza

Rarely
19%

Never
45%

Sometimes
16%

El 20% siempre o
frecuentemente se
utiliza

Often
13%

Always
7%

Sources: Standish group study reported at XP2002 by Jim Johnson, Chairman

Pablo Lischinsky - Evolucin gil C.A. 2014

Orgenes de la agilidad
Cmo llegamos aqu?
Buscando resolver la crisis del software nacieron varios mtodos:
Scrum, eXtreme Programming o XP, DSDM, Crystal Clear,
Adaptive SD, etc.
1995 "Scrum Development Process," in OOPSLA Business Object
Design and Implementation Workshop, J. Sutherland, K.
Schwaber.
2001: Agile Manifesto, 17 rmantes de la industria del software.

Pablo Lischinsky - Evolucin gil C.A. 2014

En lugar de trabajar as

h=p://www.w4-bpm.es/principios-maniesto-agil.htm

Preferimos as

Pablo Lischinsky - Evolucin gil C.A. 2014

En lugar de trabajar as

DoD?

h=p://www.w4-bpm.es/principios-maniesto-agil.htm

Preferimos as
DoD?

Pablo Lischinsky - Evolucin gil C.A. 2014

Agile Manifesto

Pablo Lischinsky - Evolucin gil C.A. 2014

Agile Manifesto
www.agilemanifesto.org
Feb 11-13, 2001
Snowbird ski resort, Utah

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt

Ron Jeries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Je Sutherland
Dave Thomas

Pablo Lischinsky - Evolucin gil C.A. 2014

Maniesto por el Desarrollo gil de Software


Estamos descubriendo mejores formas de desarrollar software
tanto por nuestra propia experiencia como ayudando a terceros. A
travs de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas.


Software funcionando sobre documentacin extensiva.
Colaboracin con el cliente sobre negociacin contractual.
Respuesta ante el cambio sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha,
valoramos ms los de la izquierda.
Pablo Lischinsky - Evolucin gil C.A. 2014

12 Principios del Maniesto gil


1. 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 tardas del
desarrollo. Los procesos giles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y un
mes, con preferencia al periodo de tiempo ms 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 conarles la ejecucin del
trabajo.
6. El mtodo ms eciente y efectivo de comunicar informacin al equipo de
desarrollo y entre sus miembros es la conversacin cara a cara.
Pablo Lischinsky - Evolucin gil C.A. 2014

12 Principios del Maniesto gil


7. El software funcionando es la medida principal de progreso.
8. Los procesos giles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indenida.
9. La atencin continua a la excelencia tcnica y al buen diseo mejora la
agilidad.
10.La simplicidad (el arte de maximizar la cantidad de trabajo no realizado), es
esencial.
11.Las mejores arquitecturas, requisitos y diseos emergen de equipos autoorganizados.
12.A intervalos regulares el equipo reexiona sobre cmo ser ms efectivo para
a continuacin ajustar y perfeccionar su comportamiento en consecuencia.
Pablo Lischinsky - Evolucin gil C.A. 2014

Valores giles
Para trabajar en Agilidad se necesita una base rme de valores que
sirvan como fundamento para el proceso y los principios del equipo:
Foco
Coraje/Valor
Apertura
Compromiso
Respeto
Otros valores importantes:
Comunicacin, Feedback/Retroalimentacin, Conanza, Honestidad,
Colaboracin, Empoderamiento.

Pablo Lischinsky - Evolucin gil C.A. 2014

Scrum

Pablo Lischinsky - Evolucin gil C.A. 2014

Scrum no es

http://2.bp.blogspot.com/-SkxCC5L8z40/UXgS3jK_peI/AAAAAAAARII/rNW7UU4qg/s1600/libro+cocina+craft+de+recetas
+laminas+decorativas+hermanas+bolena+1.JPG

Pablo Lischinsky - Evolucin gil C.A. 2014

Scrum
Es un marco de trabajo gil para desarrollar
productos y servicios en dominios complejos, con
requisitos cambiantes o poco denidos, y donde la
innovacin, la exibilidad y la productividad son
fundamentales.
No es una metodologa ni una receta.
Hace visible las disfunciones y el desperdicio en las
organizaciones.
Pablo Lischinsky - Evolucin gil C.A. 2014

Scrum
Scrum es perverso: simple de entender pero difcil de
aplicar y dominar.
Se basa en el control emprico de procesos y sus tres
pilares: transparencia, inspeccin y adaptacin.
Es centrado en las personas y se fundamenta en
valores, principios y prcticas.
Las prcticas incorporan roles, actividades,
artefactos y sus reglas.
Pablo Lischinsky - Evolucin gil C.A. 2014

s:
e
l
o
r
,
m
u
r
c
S
o
Equip
er
n
w
O
t
c
u
d
o
r
P

r
e
t
s
a
M
m
u
r
c
S
r
Team membe
s:
e
n
o
i
n
u
e
R
o
s
e
d
Activida
Sprint anning
l
P
t
n
i
r
p
S
ng
i
t
e
e
m
Daily
w
e
i
v
e
R
Sprint ctive
e
p
s
o
r
t
e
R

rum
c
S
o
p
i
u
q
E

:
s
o
t
c
a
f
e
Art
og
l
k
c
a
B
t
c
u
d
o
r
P

og
l
k
c
a
B
Sprint t
n
e
m
e
r
c
n
I

Transparencia, inspeccin y adaptacin, efecto emergente:


ms que la suma de sus partes
Pablo Lischinsky - Evolucin gil C.A. 2014

Equipo Scrum
El equipo de trabajo se llama el equipo Scrum y consta
de 3 roles:
el Product Owner (PO), responsable de qu es lo que
se va a desarrollar y en qu orden,
el ScrumMaster (SM) es responsable de guiar al
equipo en crear y seguir su propio camino basado en
el marco Scrum,
y el equipo de desarrollo (DT) responsable de
determinar cmo entregar lo que el PO demand
Pablo Lischinsky - Evolucin gil C.A. 2014

Equipo Scrum
cul es el objetivo de cada
jugador?

Pablo Lischinsky - Evolucin gil C.A. 2014

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

Actividades o reuniones de Scrum


Limitadas en tiempo (timebox)
Scrum y la gestin del conocimiento
Moderadas por el ScrumMaster
Inputs y outputs muy claros
Construccin de actas? Dependiendo de las necesidades

Pablo Lischinsky - Evolucin gil C.A. 2014

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

Sprint
Desarrollo superpuesto, no secuencial
Requisitos

Diseo

En lugar de trabajar en
etapas secuenciales ...

Cdigo

Test

... los equipos Scrum


trabajan
transversalmente.

Pablo Lischinsky - Evolucin gil C.A. 2014

Sprint
Desarrollo superpuesto, no secuencial
Requisitos

Diseo

Cmo
hacerlo? Test
Cdigo

Apoyndose en las modernas


prcticas de la Programacin
eXtrema XP! (maana )
En lugar de trabajar en
etapas secuenciales ...
... los equipos Scrum
trabajan
transversalmente.

Pablo Lischinsky - Evolucin gil C.A. 2014

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

Equipo de Desarrollo
72 integrantes
Diverso, multidisciplinario

TM

Autosuciente, responsable de todo el proceso: disear,


construir y probar el producto
Auto-organizado, determina conjuntamente la mejor forma
de trabajar
Propiedad y responsabilidad colectiva del producto
Trabajo de a pares, en espacio comn
Colaboracin, gestin del conocimiento
Pablo Lischinsky - Evolucin gil C.A. 2014

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

ScrumMaster
Gua y mantiene al equipo en el camino de Scrum:
entendimiento de los valores, principios y prcticas.
Falicitador: elimina los obstculos (barreras, impedimentos)
Desarrolla y protege al equipo de interferencias externas

SM

Se asegura de que Scrum sea implementado correctamente


Moderador de las ceremonias
Desarrolla siempre sus habilidades de liderazgo
Agente de cambio hacia agilidad en la organizacin. Equivalente
al entrenador/coach en equipos deportivos
Sin autoridad para ejercer control: lder servil, no PM.
Pablo Lischinsky - Evolucin gil C.A. 2014

Flujo de trabajo Scrum


SM

TM

Pablo Lischinsky - Evolucin gil C.A. 2014 PO

Product Owner
Comprender y compartir la visin del producto

PO

Maximizar el ROI
Priorizar el Product Backlog
Hacer el grooming o renamiento del Product Backlog con el
equipo
Colaborar con el equipo
Hacer con el equipo el Release Planning
Comprender y denir el valor de negocio con los
stakeholders
Hacer de intermediario entre el equipo y el cliente
Disponible para el equipo y SM, participa en reuniones
Pablo Lischinsky - Evolucin gil C.A. 2014

Resumiendo

Los proyectos tradicionales son como una bala de can.

Supuestos:

3) Nada va a
cambiar a lo largo
del camino.

1) El cliente
sabe lo que
quiere.

2) Los
desarrolladores
saben cmo
construirla.
http://www.funciones.webs.com/FuncionCuadratica_archivos/image004.jpg

Pablo Lischinsky - Evolucin gil C.A. 2014

Agile es como un misil.

Supuestos:

1) El cliente
descubre lo
que quiere.

3) Las cosas
cambian a
lo largo del
camino.

Pablo Lischinsky - Evolucin gil C.A. 2014

Timeboxing
Plan

Sem1

A B
C D

Sem2

Sem3

Sem4

Uf!!!...muy tarde

Escenario tradicional

-> Entregamos ABCD en 4 semanas


A

Sem1

Sem2

Sem3

Sem4

Sem5

Sem6

Q
P

Sem1

Sem2

Sem3

Sem4

Sem5

T
Uf!!!, nuestra velocidad es menor de lo que pensbamos.
Parece que slo terminaremos AB en la sem 4.
Qu debemos hacer ahora?

- Evolucin gil C.A. 2014


Pablo Lischinsky

Sem8

Teniendo el software, veo


que CD no son relevantes,
pero requiero E

Escenario gil

Entregamos producto en cada sprint (2 semanas).


No estamos seguros que podemos terminar ABCD en 4 semanas
Siempre entregamos los ms importante primero. A

Sem7

A B
C D


A B
E

Sem6

Benecios de Scrum
Ustedes estn satisfechos con los resultados que obtienen
actualmente?
Creen que entregan suciente valor a sus clientes, a tiempo,
de calidad y dentro de los costos?
Y sus equipos de trabajo? Best place to work?

Pablo Lischinsky - Evolucin gil C.A. 2014

Costo del cambio

Mtodos tradicionales

Tiempo
Pablo Lischinsky - Evolucin gil C.A. 2014

Costo del cambio

Scrum

Tiempo
Pablo Lischinsky - Evolucin gil C.A. 2014

Valor entregado/Riesgo

Pablo Lischinsky - Evolucin gil C.A. 2014

Benecios de Scrum
Clientes + contentos.
Mejor retorno de inversin mediante la entrega
temprana y frecuente de versiones.
Reducen costos
Resultados + rpidos

Conanza en tener xito en un mundo complejo y mas


competitivo

Equipos mas contentos y motivados, empoderados


Pablo Lischinsky - Evolucin gil C.A. 2014

Manejo de Requisitos en Scrum


Los mtodos secuenciales y Scrum tratan los requisitos de forma
muy diferente.
Mtodos secuenciales: los requerimientos son no-negociables, son
detallados de antemano, sin ninguna prioridad y pretenden ser
independientes del resto del proceso.

Scrum: los detalles de los requerimientos son negociados a travs de

conversaciones continuas con el cliente. Se van desarrollando segn su


prioridad, justo a tiempo y slo lo suciente para que el equipo
comience a desarrollar las funcionalidades respectivas.

Pablo Lischinsky - Evolucin gil C.A. 2014

Jerarqua de requisitos por nivel de planicacin y


granularidad

Pablo Lischinsky - Evolucin gil C.A. 2014

Manejo de Requisitos en Scrum: Historias


de Usuario
Las 3 Cs para escribir Historias de Usuario
Card (cha)
Conversation
Conrmation
Pablo Lischinsky - Evolucin gil C.A. 2014

Historia de usuario (User Story): Ficha


ID

<<Descripcin>>
Como <Rol>
Deseo <Actividad>
Para <Lograr un objetivo>

Bussines
Value
points

Pablo Lischinsky - Evolucin gil C.A. 2014

Story
points

Historia de usuario (User Story)


Us1

Escribir historias de usuario


Como

miembro del equipo

Deseo escribir

historias de usuario correctamente


usando la metfora 3C
Para que el esclarecimiento de los requisitos
se d con la mayor transparencia posible.
12

Pablo Lischinsky - Evolucin gil C.A. 2014

Historia de usuario (User Story)


Us1

Escribir historias de usuario

Quin?

Como

miembro del equipo

Qu?

Deseo escribir

historias de usuario correctamente


usando la metfora 3C
Para que el esclarecimiento de los requisitos
Por qu?
se d con la mayor transparencia posible.
12

Pablo Lischinsky - Evolucin gil C.A. 2014

Historia de usuario (User Story)


Us1

Ver lista de oportunidades


Como Gerente Comercial
Deseo ver la Lista de Oportunidades
Para Planear la estrategia comercial
20

Pablo Lischinsky - Evolucin gil C.A. 2014

Historia de usuario (User Story) Reverso Ficha


Criterios de aceptacin
Dado que he ingresado al sistema como Gerente Comercial
Cuando estoy en la seccin de Oportunidades
Entonces debo ver las oportunidades ingresadas por todos
los asesores

Dado que he ingresado al sistema como Gerente Comercial


Cuando selecciono una Oportunidad
Entonces debo ver el monto y la Probabilidad de cumplimiento

Pablo Lischinsky - Evolucin gil C.A. 2014

Historia de usuario (User Story) Reverso Ficha


Criterios de aceptacin
Dado que he ingresado al sistema como Gerente Comercial
Cuando estoy en la seccin de Oportunidades

ATDD!

Entonces debo ver las oportunidades ingresadas por todos


los asesores

Dado que he ingresado al sistema como Gerente Comercial


Cuando selecciono una Oportunidad
Entonces debo ver el monto y la Probabilidad de cumplimiento
Testers escribiendo
HU!
Pablo Lischinsky - Evolucin gil C.A. 2014

Criterio INVEST en buenas Historias de Usuario


Independientes
Negociables
Valuables
Estimables
Small (pequeas)
Testeables

Pablo Lischinsky - Evolucin gil C.A. 2014

Product Backlog (Gestin de requisitos)

Product Backlog Items (PBIs):



Funcionalidades (features)
Defectos
Trabajo tcnico
Formacin/capacitacin

Pablo Lischinsky - Evolucin gil C.A. 2014

Product Backlog (Gestin de requisitos)


PB: DEEP (Roman Pichler)
Detallado apropiadamente
Estimado
Emergente (dinmico)
Priorizado

Pablo Lischinsky - Evolucin gil C.A. 2014

Product Backlog

Prioridad

Detalle

ms detalle, alta
granularidad

GesSn dinmica y priorizada por ROI de


los requisitos

Poco detalle,
desconocido, baja
granularidad
Pablo Lischinsky - Evolucin gil C.A. 2014

Product Backlog

Prioridad

En estado listo o
Ready para entrar al
sprint backlog

Pablo Lischinsky - Evolucin gil C.A. 2014

Dinmica de la priorizacin
Product Backlog

El PO pueden re-priorizar los


PBIs de acuerdo a las
necesidades del cliente o el
ROI

Pablo Lischinsky - Evolucin gil C.A. 2014

Renamiento del Backlog


Dinmica de una pica
Product Backlog

pica
PBI

PBI

PBIListo

Pablo Lischinsky - Evolucin gil C.A. 2014

Cmo comenzar una transformacin


hacia la agilidad y Scrum?
Con ADAPT (Mike Cohn):
1. Reconocimiento de que hay un problema (Awareness)

2. Deseo de adoptar Scrum para intentar resolver el


problema

3. Capacidad y competencia para tener xito (Ability)

4. Promocin de Scrum en la organizacin compartiendo


experiencias y casos de xito.

5. Transferencia del conocimiento e implicaciones del uso de


Scrum a toda la organizacin

Pablo Lischinsky - Evolucin gil C.A. 2014

Cmo comenzar?
Consensuando un Backlog de cambios:
aplicando Scrum para implementar Scrum !

Pablo Lischinsky - Evolucin gil C.A. 2014

Cmo comenzar?
Kaizen
Kaikaku
Scrum Orgnico

Pablo Lischinsky - Evolucin gil C.A. 2014

Bibliografa

Essential Scrum,
Kenneth Robin
Muy recomendable !

Roman Pichler, Sobre el


rol del PO

Pablo Lischinsky - Evolucin gil C.A. 2014

Bibliografa

Pablo Lischinsky - Evolucin gil C.A. 2014

Bibliografa

The Scrum Guide, Ken Schwaber and Je Sutherland, Scrum.org,


2011
Do Better Scrum, Peter Hundermark, 2009
Scrum y XP desde las trincheras, Henrik Kniberg, 2007
Succeeding with Agile, Mike Cohn, 2010.
User Stories Applied for Agile Software Development, Mike Cohn,
2004.
Extreme Programming Explained: Embrace Change, Second
Edition, By Kent Beck, Cynthia Andres, 2004.
Agile Software Development, Robert C. Martin, 2002.
Pablo Lischinsky - Evolucin gil C.A. 2014

Otros recursos

http://www.agilealliance.org/
http://www.scrumalliance.org/
http://www.scrum.org/
http://www.extremeprogramming.org/
http://www.proyectosagiles.org/
http://www.mountaingoatsoftware.com/scrum
http://blog.crisp.se/author/henrikkniberg

Pablo Lischinsky - Evolucin gil C.A. 2014

Otros recursos

Grupos o comunidades

Foro-agiles: http://groups.yahoo.com/neo/groups/foro-agiles/
Agilven: http://groups.google.com/group/agilven y en casi todos los
pases de LatAm
Grupos Agiles y Agilven en Linkedin y muchos otros !
Koans, Katas, Code Retreats Software Craftmanship !

Pablo Lischinsky - Evolucin gil C.A. 2014

Pablo Lischinsky

@pablolis
lis.pablo@gmail.com
http://about.me/pablolischinsky
pablolischinsky.wordpress.com

Pablo Lischinsky - Evolucin gil C.A. 2014

También podría gustarte