taller: scrum - osvaldo comelli

12/02/15

1

® ©

™ O

sval

do C

omel

li ®

© ™

Osv

aldo

Com

elli

Scrum

12-02-15

Taller ®

© ™

Osv

aldo

Com

elli

Bienvenida

Congreso Nacional de Software 2015 Scrum

2

12/02/15

2

® ©

™ O

sval

do C

omel

li

Locura: Hacer la misma cosa una y otra vez y esperar

resultados diferentes.

Albert Einstein Físico Alemán

(1879-1955)


3

® ©

™ O

sval

do C

omel

li

Presentación


4

12/02/15

3

® ©

™ O

sval

do C

omel

li

1.  Su nombre 2.  Su organización y su rol 3.  Sus expectativas sobre el taller 4.  Su reto actual más grande en temas de

desarrollo de software


5

® ©

™ O

sval

do C

omel

li

1.  Osvaldo Comelli 2.  Buró de Crédito / Subdirector de Desarrollo y

Mantenimiento de Software 3.  Compartir mi experiencia en metodología de

desarrollo de software ágil empleando Scrum 4.  Relación inconexa entre los marcos de TI, y

relación inconexa entre el “negocio” y TI


6

12/02/15

4

® ©

™ O

sval

do C

omel

li

Reglas


7

® ©

™ O

sval

do C

omel

li

1.  Horario de inicio y fin 2.  Recesos 3.  Uso de celulares y laptops 4.  Se invita (forzosamente) a la participación y

discusión en grupo


8

12/02/15

5

® ©

™ O

sval

do C

omel

li

Programa


9

® ©

™ O

sval

do C

omel

li

1.  Ingeniería de Software 2.  El proceso de Desarrollo de Software 3.  Scrum 4.  Sesión práctica


10

12/02/15

6

® ©

™ O

sval

do C

omel

li

Objetivos


11

® ©

™ O

sval

do C

omel

li

1.  Comprender la terminología, estructura y conceptos básicos de Scrum

2.  Comprender los objetivos clave de las prácticas de Scrum para el Desarrollo de Software


12

12/02/15

7

® ©

™ O

sval

do C

omel

li

Programa Ingeniería de Software


13

® ©

™ O

sval

do C

omel

li

Temas curiosos…historias de horror… 1.  103-year-old man told to bring parents for eye test (2002) 2.  Mars Climate Orbiter (1999) 3.  Ariane 5 (1996) 4.  USS Yorktown (1998) 5.  Denver baggage handling system (1994) 6.  Therac-25 linear accelerator machines (1985-1987)


14

12/02/15

8

® ©

™ O

sval

do C

omel

li

Características y evolución del software Primeras décadas: •  desarrollar el hardware •  reducir costos de procesamiento y almacenamiento Década de los ochenta: •  desarrollo de la microelectrónica •  mayor potencia de cálculo y reducción de costos Objetivo actual: mejorar la calidad de las soluciones software


15

® ©

™ O

sval

do C

omel

li

Características y evolución del software Software •  programas, archivos de configuración •  documentación de la estructura del sistema •  manuales de instalación y uso •  sitios web con información y actualizaciones

Tipos de Software •  productos genéricos •  sistemas producidos por una organización y que se venden en el mercado abierto •  sistemas manejadores de bases de datos, procesadores de texto, paquetes gráficos,... •  la organización controla la especificación

•  productos personalizados •  desarrollados específicamente para un cliente •  aplicaciones de negocio, sistemas de control de tráfico aéreo, control de procesos de fabricación,... •  el cliente controla la especificación de la aplicación


16

12/02/15

9

® ©

™ O

sval

do C

omel

li

Características y evolución del software

El software desde una perspectiva industrial… El valor del software: de “elemento añadido” a principal elemento de costo Algunas preguntas: •  ¿por qué se tarda tanto? (y casi siempre más de lo previsto) •  ¿por qué la productividad es tan baja? •  ¿por qué cuesta tanto? •  ¿por qué siempre quedan errores sin localizar?


17

® ©

™ O

sval

do C

omel

li

Características y evolución del software

El software como elemento lógico. Se desarrolla, no se fabrica: •  calidad del diseño •  costos más importantes en la ingeniería •  gestión especial de los proyectos Se “deteriora” con el mantenimiento… La “crisis” del software: problemas que aparecen al desarrollarlo, mantenerlo y atender la demanda de nuevas aplicaciones


18

12/02/15

10

® ©

™ O

sval

do C

omel

li

Ingeniería (DRAE): “conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la utilización de la materia y de las fuentes de energía. Profesión y ejercicio del ingeniero” Ingeniero (DRAE): “persona que profesa o ejerce la ingeniería” …pero no definen el término Ingeniería de Software…


19

® ©

™ O

sval

do C

omel

li

Ingeniería de Software… “Ingeniería de Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software” (Zelkovitz, 1978) “Ingeniería de Software es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar, operar (funcionar) y mantenerlos” (Bohem, 1976) “Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener de modo rentable que sea fiable y trabaje en máquinas reales” (Bauer, 1972) “La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software; es decir, la aplicación de ingeniería al software” (IEEE, 1993)


20

12/02/15

11

® ©

™ O

sval

do C

omel

li

Proceso de Software… “Es un proceso definido paso a paso, que facilita la especificación, el diseño, la implementación y las pruebas de una solución de software, para un conjunto de requisitos explícitos, de modo eficiente y eficaz” Esto requiere que al empezar el proceso se tenga: •  objetivos claros •  planes para lograr los objetivos •  procedimientos que implementan los planes •  procedimientos de monitoreo y control de los planes •  un ambiente conducente al logro de los objetivos


21

® ©

™ O

sval

do C

omel

li

Proceso de Software…


22

12/02/15

12

® ©

™ O

sval

do C

omel

li

Proceso de Software… •  debemos analizar y ENTENDER el contexto y el problema antes de plantear una

solución •  no se debe plantear una solución en busca de un problema…escenario común •  debemos separar los problemas complejos en sub-problemas más simples •  aseguraremos que las relaciones entre los sub-problemas están acotadas

no evitemos el cambio, administrémoslo


23

® ©

™ O

sval

do C

omel

li

Proceso de Software… •  especifiquemos y controlemos la calidad del producto que se está desarrollando •  hay que desarrollar una visión compartida del proyecto…entre todos los involucrados •  no perdamos de vista a los usuarios y a los clientes. Identifiquémoslos y modelémoslos

(casos de uso, user stories, etc.) y validemos en forma permanente con ellos…. eso nos dará una comprensión completa y válida del problema

guiemos el proceso…no vayamos a la deriva


24

12/02/15

13

® ©

™ O

sval

do C

omel

li


Tengamos en cuenta: •  los objetivos y necesidades de los usuarios y de los clientes •  la dedicación de los usuarios/clientes al proyecto (contraparte) •  el feedback periódico que el usuario/cliente espera tener, de parte del equipo

desarrollador •  que distintos usuarios/clientes pueden tener requisitos contradictorios, que requieren ser

alineados •  los temores/desconfianza del usuario… •  el esfuerzo* de probar…se requiere tiempo de los usuarios…y a veces se requieren

“pruebas masivas” •  el esfuerzo de aprender y de usar (incluir las actividades sin equipo de cómputo) •  el agrado/desagrado de uso del software esfuerzo*: costo y tiempo (asociado al desarrollador y/o usuario/cliente) vinculado a la realización de una tarea


25

® ©

™ O

sval

do C

omel

li


A pesar de que la industria del software es hoy en día uno de los motores de la economía mundial, numerosos problemas aún persisten... •  el desarrollo del hardware siempre aventaja al software asociado •  la demanda por nuevos productos no puede ser satisfecha (diversidad de

escenarios, donde se deben proveer servicios) •  el software no es confiable por naturaleza (y somos cada vez más

dependientes de él) •  los proyectos raramente terminan en las fechas previstas •  los proyectos raramente terminan costando lo previsto •  proyectos terminados, que jamás se usan •  proyectos que se usan, pero usuarios altamente insatisfechos •  costo exorbitante de mantenimiento


26

12/02/15

14

® ©

™ O

sval

do C

omel

li

Estadísticas globales… fuente: CHAOSManifesto2013 & http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf


27

® ©

™ O

sval

do C

omel

li

Se requiere… burocracia “a la medida” (útil y efectiva, tediosa pero vital) manejo formal del proceso de desarrollo documentación formal detallada tanto interna como externa: •  puede pensarse en términos de contratos cliente/proveedor, etc. trazabilidad •  ¿de quién es este código? •  ¿cuándo se agregó esta parte? manejo de la configuración y control de versiones


28

12/02/15

15

® ©

™ O

sval

do C

omel

li

Se requiere… •  el software es un producto intangible el cual se logra a través de un

proceso creativo, ya que programar es un arte, el cual no puede ser sistematizado del todo

•  porque es importante el desarrollo de proyectos de forma Metodológica

•  el software es cada vez más complejo y costoso que se compara con construir un edificio


29

® ©

™ O

sval

do C

omel

li

Programa Scrum


30

12/02/15

16

® ©

™ O

sval

do C

omel

li

Manifiesto ágil & http://www.agilemanifesto.org 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 herramientas •  software que funciona sobre documentación exhaustiva •  colaboración con el cliente sobre negociación de contratos •  responder ante el cambio sobre el 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


31

® ©

™ O

sval

do C

omel

li

Principios… •  nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y

continua de software con valor •  aceptamos requisitos cambiantes, incluso en etapas avanzadas •  entregamos software frecuentemente •  los responsables de negocio y los desarrolladores deben trabajar juntos diariamente a lo

largo del proyecto •  construimos proyectos con profesionales motivados •  conversación cara a cara •  software que funciona es la principal medida de progreso •  los procesos ágiles promueven el desarrollo sostenible •  la atención continua a la excelencia técnica y los buenos diseños mejoran la agilidad •  simplicidad es esencial •  las mejores arquitecturas, requisitos y diseños surgen de equipos que se auto-organizan •  a intervalos regulares el equipo reflexiona sobre cómo ser más efectivo


32

12/02/15

17

® ©

™ O

sval

do C

omel

li

Principios… Highsmith & Cockburn 2001 “lo que es nuevo en los procesos ágiles no son las prácticas que usan, sino que reconozcan a las personas como primeros implicados en el éxito de un proyecto, además de un intenso foco en la efectividad y la manejabilidad. Esto genera una nueva combinación de valores y principios que definen una visión ágil del mundo”


33

® ©

™ O

sval

do C

omel

li

Principios… Hawrysh & Ruprecht 2000 “una sola metodología no puede funcionar para todo el espectro de proyectos, en vez de eso el administrador de cada proyecto debería identificar la naturaleza especifica de cada proyecto y seleccionar la mejor metodología de desarrollo aplicable” McCauley 2001 “hay una necesidad de ambos métodos [ágiles y orientados a procesos] ya que no hay un modelo de desarrollo que se ajuste a todos los propósitos imaginables”


34

12/02/15

18

® ©

™ O

sval

do C

omel

li

Principios… el desarrollo de software es ágil cuando es… •  incremental liberaciones pequeñas y ciclos rápidos •  cooperativo

clientes y desarrolladores trabajando juntos •  simple y directo

el método es fácil de aprender y modificar •  adaptativo

es posible realizar cambios de último momento


35

® ©

™ O

sval

do C

omel

li

Scrum…


36

12/02/15

19

® ©

™ O

sval

do C

omel

li

Scrum… •  Scrum es una metodología ágil de desarrollo de proyectos que toma

su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80

•  en 1996 se definió por primera vez un patrón para aplicar esos principios de desarrollo al software

•  esta fue la primera definición de un patrón Scrum aplicado al software, diseñada por Jeff Sutherland y Ken Schwaber y presentada en OOPSLA 96


37

® ©

™ O

sval

do C

omel

li

Scrum…en 100 palabras •  Scrum es un proceso ágil que nos permite centrarnos en ofrecer el

más alto valor de negocio en el menor tiempo •  nos permite rápidamente y en repetidas ocasiones inspeccionar

software real de trabajo (cada dos semanas o un mes) •  el negocio fija las prioridades. Los equipos se auto-organizan a fin de

determinar la mejor manera de entregar las funcionalidades de más alta prioridad

•  cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorándolo en otro Sprint


38

12/02/15

20

® ©

™ O

sval

do C

omel

li

Scrum…ha sido utilizado por…


39

•  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

® ©

™ O

sval

do C

omel

li

Scrum…ha sido utilizado para…


40

•  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 videojuegos •  sistemas críticos de soporte vital,

aprobados por la FDA •  software de control satelital •  sitios Web •  software para handheld •  teléfonos móviles e inteligentes •  aplicaciones de network

switching •  aplicaciones de ISV

12/02/15

21

® ©

™ O

sval

do C

omel

li

Scrum…características… •  equipos auto-organizados •  el 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 prescritas •  utiliza normas generativas para crear un entorno ágil para la entrega

de proyectos •  es uno de los “procesos ágiles”…


41

® ©

™ O

sval

do C

omel

li

Scrum…características…


42

12/02/15

22

® ©

™ O

sval

do C

omel

li

Scrum…Sprints… •  en Scrum los proyectos avanzan en una serie de Sprints •  análogo a las iteraciones en AUP •  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 producto es diseñado, codificado y probado durante el Sprint


43

® ©

™ O

sval

do C

omel

li

Scrum…framework…


44

• Product owner• ScrumMaster• Equipo

Roles

• Sprint planning• Sprint review• Sprint retrospective• Daily Scrum meeting

Reuniones

• Product backlog• Sprint backlog• Burndown charts

Artefactos

12/02/15

23

® ©

™ O

sval

do C

omel

li



45


Roles


Reuniones


Artefactos

® ©

™ O

sval

do C

omel

li

Scrum… 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


46

12/02/15

24

® ©

™ O

sval

do C

omel

li

Scrum… Scrum Master •  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


47

® ©

™ O

sval

do C

omel

li

Scrum… Equipo •  típicamente de 5 a 9 personas •  multi-funcional:

•  pogramadores, testers, analistas, diseñadores, etc. •  los miembros deben ser full-time

•  puede haber excepciones (ej.: Infraestructura, 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


48

12/02/15

25

® ©

™ O

sval

do C

omel

li



49


Reuniones


Roles


Artefactos

® ©

™ O

sval

do C

omel

li

Scrum…Sprint planning meeting


50

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

12/02/15

26

® ©

™ O

sval

do C

omel

li

Scrum…Daily Scrum •  parámetros:

•  diaria •  dura 15 minutos •  de pie •  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


51

® ©

™ O

sval

do C

omel

li

Scrum…Sprint review / retrospective •  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 hrs. preparación •  no usar diapositivas •  todo el equipo participa •  se invita a todo el mundo


52

12/02/15

28

® ©

™ O

sval

do C

omel

li



55

® ©

™ O

sval

do C

omel

li



56


Artefactos


Roles


Reuniones

12/02/15

29

® ©

™ O

sval

do C

omel

li

Scrum…Product backlog •  los requisitos •  una lista de todos los trabajos deseados en el proyecto •  idealmente cada tema tiene valor para el usuarios o el cliente •  priorizada por el Product Owner •  repriorizada al comienzo de cada Sprint


57

® ©

™ O

sval

do C

omel

li

Scrum…Product backlog


58

Backlog item EstimaciónPermitir a un invitado a hacer una reserva. 3Como invitado, quiero cancelar una reserva. 5Como invitado, quiero cambiar las fechas de una reserva.

3

Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitación

8

Mejorar el manejo de excepciones 8... 30... 50

12/02/15

30

® ©

™ O

sval

do C

omel

li

Scrum…Sprint backlog •  los individuos eligen las tareas •  el trabajo nunca es asignado •  la estimación del trabajo restante es actualizada diariamente •  cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint

Backlog •  el trabajo para el Sprint emerge •  si el trabajo no está claro, definir un tema del Sprint Backlog con una

mayor cantidad de tiempo y subdividirla luego •  actualizar el trabajo restante a medida de que más se conoce


59

® ©

™ O

sval

do C

omel

li

Scrum…Sprint backlog


60

TareasCodificar UI

Codificar negocio

Prurbas unitarias

Escribir ayuda online

Escribir las clases

L8

168

128

M4

1216

8

M J

411

84

V

8

8Agregar logging

81016

88

12/02/15

31

® ©

™ O

sval

do C

omel

li

Scrum…Burndown charts


61

Hor

as

40

30

20

100 Lun Mar Mier Juev Vier

50

® ©

™ O

sval

do C

omel

li

Scrum…¿dónde seguir? Agile and Iterative Development: A Manager’s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber User Stories Applied for Agile Software Development by Mike Cohn Artículos semanales en www.scrumalliance.org


62

12/02/15

32

® ©

™ O

sval

do C

omel

li

Programa Sesión práctica


63

® ©

™ O

sval

do C

omel

li

Scrum…¿cuánto se tarda en escribir un nombre?

•  ronda 1: escribe “n” nombres al mismo tiempo y mide el tiempo por nombre y en total

•  estimar cuánto se tarda en escribir un nombre •  “n” clientes y 1 desarrollador •  política corporativa: “nunca tengas al cliente esperando” porque eso

es un mal negocio. Podríamos perder a un cliente que tiene que esperar

•  proceso: 1.  entrega tu tarjeta al desarrollador y dile tu nombre 2.  espera a que el desarrollador escriba tu nombre y te lo entregue 3.  comprueba el cronómetro y anota el tiempo de entrega sobre la tarjeta 4.  si hay un error (tal como una falta de ortografía) no apuntes el tiempo todavía. En su lugar, devuelve la

tarjeta para su corrección. La entrega no se considera hecha hasta que sea correcta 5.  puedes hablar con el desarrollador y responder sus preguntas. Pero no puedes escribir letras


64

12/02/15

33

® ©

™ O

sval

do C

omel

li

Scrum…¿cuánto se tarda en escribir un nombre? •  ronda 1: escribe n nombres al mismo tiempo y mide el tiempo por

nombre y en total


65

® ©

™ O

sval

do C

omel

li

Scrum…¿cuánto se tarda en escribir un nombre? •  ronda 1: escribe “n” nombres al mismo tiempo y mide el tiempo por

nombre y en total •  retrospectiva: ¿qué factores influyen en la duración?


66

12/02/15

34

® ©

™ O

sval

do C

omel

li

Scrum…¿cuánto se tarda en escribir un nombre? •  ronda 2: escribe “n” nombres, uno cada vez. Mide de nuevo. •  “n” clientes y 1 desarrollador (cambio) •  política corporativa: limitar el WIP (trabajo en progreso). Y el límite

actual pasa a ser 1. •  proceso:

1.  entrega tu tarjeta al desarrollador y dile tu nombre 2.  espera a que el desarrollador escriba tu nombre y te lo entregue 3.  comprueba el cronómetro y anota el tiempo de entrega sobre la tarjeta 4.  si hay un error (tal como una falta de ortografía) no apuntes el tiempo todavía. En su lugar,

devuelve la tarjeta para su corrección. La entrega no se considera hecha hasta que sea correcta

5.  puedes hablar con el desarrollador y responder sus preguntas. Pero no puedes escribir letras


67

® ©

™ O

sval

do C

omel

li

Scrum…¿cuánto se tarda en escribir un nombre? •  ronda 2: escribe “n” nombres y mide el tiempo por nombre y en total


68

12/02/15

35

® ©

™ O

sval

do C

omel

li

Scrum…¿cuánto se tarda en escribir un nombre? fuente: http://www.crisp.se/henrik.kniberg/multitasking-name-game

•  ronda 2: escribe “n” nombres y mide el tiempo por nombre y en total •  retrospectiva:

•  ¿cómo te hacen sentir estas dos rondas tanto como desarrollador como cliente? •  ¿qué se siente al ser el último cliente en la 2ª ronda en comparación con la 1ª ronda? •  ¿qué piensas acerca de la afirmación "si empezamos pronto vamos a terminar antes”? •  ¿cómo influye esta planificación de entregas? por ejemplo, ¿qué sabemos después de

10 segundos en la 1ª ronda frente a la 2ª? •  ¿qué hubiera pasado si el desarrollador fuese perfecto en el cambio entre tareas? •  ¿cómo influye esto con la calidad del producto? •  ¿este problema sobre la multitarea suena familiar? ¿quién lo está experimentando en

este momento? ¿quién lo ha experimentado en el pasado? •  ¿qué nos lleva a hacer esto? ¿por qué es tan común este problema? •  ¿qué puedes hacer para combatir este problema en tu entorno?


69

® ©

™ O

sval

do C

omel

li

¿dudas?

¿comentarios?

[email protected]


70

taller: scrum - osvaldo comelli

Documents