scrumb

Lean

Agile

Scrum

Desarrollo gil de software, Scrum

Desarrollo de

Software

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


Redeniendo el xito de un proyecto

Tcnico

Organizacional

Personal


Redeniendo el xito de un proyecto A quines impacta? Cliente Usuarios, Interesados Equipo de desarrollo Organizacin


Project Success Sliders (Mike Cohn) http://www.mountaingoatsoftware.com/tools/project-success


Takeuchi y Nonaka, HBR,

1986

SCRUM

Priorizacin/Pareto

Desarrollo de software

iterativo e incremental

Timeboxing

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


O principio del 80/20

Priorizacin y el principio de Pareto


20% causas 80% efectos

Never 45%

Always 7%

Often 13%

Sometimes 16%

Rarely 19%

Funcionalidades utilizadas en un software

El 64% Nunca o rara vez se utiliza

El 20% siempre o frecuentemente se

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


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.

Orgenes de la agilidad


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

En lugar de trabajar as

Preferimos as


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

En lugar de trabajar as

Preferimos as


DoD?

DoD?

Agile Manifesto


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


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.


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.

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 auto-organizados.

12.A intervalos regulares el equipo reexiona sobre cmo ser ms efectivo para a continuacin ajustar y perfeccionar su comportamiento en consecuencia.

12 Principios del Maniesto gil


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.



Scrum

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

Scrum no es


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.


Scrum

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.


Equipo Scrum, roles: Product Owner Scrum Master Team member

Actividades o Reuniones:

Sprint Sprint Plan

ning

Daily meeting

Sprint Review

Retrospective

Artefactos: Product B

acklog

Sprint Backlog

Increment

Transparencia, inspeccin y adaptacin, efecto emergente: ms que la suma de sus partes

Equipo Scrum


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


Equipo Scrum cul es el objetivo de cada jugador?


Flujo de trabajo Scrum

TM

SM

PO Pablo Lischinsky - Evolucin gil C.A. 2014

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


TM

SM




Sprint Desarrollo superpuesto, no secuencial

En lugar de trabajar en etapas secuenciales ...

... los equipos Scrum trabajan transversalmente.

Requisitos Diseo Cdigo Test


Sprint Desarrollo superpuesto, no secuencial

En lugar de trabajar en etapas secuenciales ...

... los equipos Scrum trabajan transversalmente.

Requisitos Diseo Cdigo Test Cmo hacerlo? Apoyndose en las modernas prcticas de la Programacin eXtrema XP! (maana )

TM

SM



Equipo de Desarrollo 72 integrantes Diverso, multidisciplinario 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

TM


TM

SM



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 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.

SM



Flujo de trabajo

TM

SM

PO


Product Owner Comprender y compartir la visin del producto 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

PO


Resumiendo Los proyectos tradicionales son como una bala de can.

Supuestos:

http://www.funciones.webs.com/FuncionCuadratica_archivos/image004.jpg

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

2) Los desarrolladores saben cmo construirla.

1) El cliente sabe lo que quiere.


Agile es como un misil. Supuestos:

1) El cliente descubre lo que quiere.

3) Las cosas cambian a lo largo del camino.


A BDC

Sem1 Sem2 Sem3 Sem4

Timeboxing Plan

A BDC

Sem1 Sem2 Sem3 Sem4 Sem5 Sem6 Sem7 Sem8

Escenario tradicional

-> Entregamos ABCD en 4 semanas A

TP Q

A

TPQ

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.

Sem1 Sem2 Sem3 Sem4 Sem5 Sem6

AA B A B E

Uf!!!...muy tarde

Teniendo el software, veo que CD no son relevantes,

pero requiero E

Uf!!!, nuestra velocidad es menor de lo que pensbamos. Parece que slo terminaremos AB en la sem 4.

Qu debemos hacer ahora?


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?


Mtodos tradicionales


Costo

del

camb

io

Tiempo


Tiempo

Scrum Co

sto d

el ca

mbio

Valor entregado/Riesgo


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


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.


Jerarqua de requisitos por nivel de planicacin y granularidad


Manejo de Requisitos en Scrum: Historias de Usuario Las 3 Cs para escribir Historias de Usuario Card (cha) Conversation Conrmation


Como

Deseo

Para

ID

Bussines Value points

Story points

Historia de usuario (User Story): Ficha


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.

Us1

12

8

Historia de usuario (User Story)


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.

Us1

12

8


Quin?

Qu?

Por qu?


Ver lista de oportunidades

Como Gerente Comercial

Deseo ver la Lista de Oportunidades

Para Planear la estrategia comercial

Us1

20

8



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

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

Historia de usuario (User Story) Reverso Ficha

ATDD!

Testers escribiendo HU!


Criterio INVEST en buenas Historias de Usuario Independientes Negociables Valuables Estimables Small (pequeas) Testeables


Product Backlog (Gestin de requisitos)

Product Backlog Items (PBIs): Funcionalidades (features) Defectos Trabajo tcnico Formacin/capacitacin


Product Backlog (Gestin de requisitos)

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


-+Prioridad ms detalle, alta granularidad

Poco detalle, desconocido, baja granularidad

Detalle

Product Backlog

GesSn dinmica y priorizada por ROI de los requisitos


-+Prioridad En estado listo o Ready para entrar al sprint backlog

Product Backlog


Product Backlog

Dinmica de la priorizacin

El PO pueden re-priorizar los PBIs de acuerdo a las necesidades del cliente o el ROI


pica

PBI

PBIListo

PBI

Product Backlog

Renamiento del Backlog Dinmica de una pica


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


Cmo comenzar?

Consensuando un Backlog de cambios: aplicando Scrum para implementar Scrum !


Cmo comenzar? Kaizen Kaikaku Scrum Orgnico


Bibliografa

Essential Scrum, Kenneth Robin Muy recomendable !

Roman Pichler, Sobre el rol del PO


Bibliografa


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


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 @pablolis

[email protected] http://about.me/pablolischinsky pablolischinsky.wordpress.com


scrumb

Documents

Transcript of scrumb