27/06/2013

INGENIERA DE SOFTWARE
MARCELO ESTAYNO JUDITH MELES OTOO 2013

Ingeniera de Software: Objetivos parte 1

Reconocer la importancia de los conceptos relacionados con la

Ingeniera de Software y sus disciplinas, tcnicas y herramientas relacionadas. Identificar los procesos de desarrollo y los modelos de procesos ms adecuados para el desarrollo de software en cada situacin particular. Conocer la problemtica que presenta la planificacin y el seguimiento de un proyecto de software. Introducir el uso de mtodos giles para el desarrollo y la gestin de proyectos de software.
2

27/06/2013

Ingeniera de Software: Objetivos parte 2

Entender la problemtica y la importancia de la Ingeniera de

Requerimientos en el contexto de la Ingeniera de Software. Aplicar mtricas y estimaciones en el contexto del desarrollo de software en el mbito de metodologas giles y de metodologas tradicionales. Comprender las problemtica de disear arquitecturas de software. Conocer las actividades relacionadas con el aseguramiento de calidad del proceso de desarrollo de software y de productos de software.
3

Ingeniera de Software: Contenidos parte 1

Introduccin a la Disciplina de Ingeniera de Software Crisis del software Estado Actual y Antecedentes.

Modelos de proceso y ciclos de vida

Procesos predictivos y procesos empricos Desarrollo de software basado en procesos definidos y en

procesos empricos Mtodos giles para desarrollo y gestin de proyectos

4

27/06/2013

Ingeniera de Software: Contenidos parte 2

Ingeniera de Requerimientos Diseo de Arquitecturas de Software Mtricas y Estimaciones de Software para proyectos

tradicionales y para proyectos giles Gestin de Configuracin de Software en ambientes tradicionales de desarrollo y en ambientes giles Aseguramiento de Calidad de Proceso y de Producto
5

27/06/2013

Hardware

Software

Peopleware

Alegras
Hacer cosas
Hacer cosas que le sirvan a

otros Armar cosas como rompecabezas y verlas funcionar Aprender cosas nuevas

27/06/2013

TRISTEZAS
Perfeccin Depender de otros Encontrar errores Riesgo de obsolescencia

Un poco de historia
1968
1975 1978 80 1987 1989 1990 1991 1993 2000 2001

Nace el termino conferencia de la NATO The Mythical Man-Month Frederick Brooks Tom DeMarco introduce Structured Analysis Primeros grandes errores de software conocidos No silver bullet (Brooks). Caractersticas esenciales del software

Managing the Software Process Watts Humphrey

Internet / Object Oriented CMM 1.0 CMM 1.1 CMMI 1.0 Agile Manifiesto
10

27/06/2013

Definicin de Software
Software, en general, es un set de programas y la documentacin que acompaa.
Existen tres tipos bsicos de software. Estos son:
System software Utilitarios Software de Aplicacin
11

Ingeniera de Software
Parmas [1987] defini a la ingeniera en software como

multi-person construction of multi-version software

12

12

27/06/2013

Lo esencial
Qu es lo esencial? Lo esencial es visible? Cmo atacamos lo esencial?

13

"Here is Edward Bear, coming downstairs now, bump, bump, bump on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it, and then he feels that perhaps there isnt."

14

27/06/2013

Lecciones aprendidas
Mucho del progreso se ha hecho en base a caractersticas accidentales Software no se manufactura, se disea La solucin radical para construir software es no construirlo todo Reuso Mercado de Reuso (construir) Integridad conceptual Una nica arquitectura es necesaria

Comunicacin y Coordinacin
Documente sus productos .pero inteligentemente Las organizaciones se acomodan a la gente no vice-versa El efecto del prototipado Hgalo
15

Los 10 esenciales en software

Una especificacin de Un Plan de Calidad
Lista detallada de actividades Gestin de Configuracin de

producto
Un prototipo de la

interfaz detallado
Un cronograma realista Prioridades Explicitas Administracin de
16

Software
Arquitectura de Software Un Plan de Integracin

Riesgos.

http://www.stevemcconnell.com/ieeesoftware/10Essentials.pdf

27/06/2013

Son todos esenciales los puntos anteriores?

Cules estaran ausentes? Cules re-planteara?

17

Componentes de Proyecto de Software

18 18

27/06/2013

Qu es un proyecto?
Estn orientados a objetivos Tienen una duracin limitada en el tiempo, tienen principio y

fin. Implican tareas interrelacionadas basadas en esfuerzos y recursos. Son nicos

19

Orientacin a objetivos
Los proyectos estn dirigidos a obtener resultados y ello se

refleja a travs de objetivos. Los objetivos guan al proyecto Los objetivos no deben ser ambiguos Un objetivo claro no alcanzadebe ser tambin alcanzable.

20

10

27/06/2013

Duracin limitada
Los proyectos son temporarios, cuando se alcanza el/los

objetivo/s, el proyecto termina. Una lnea de produccin no es un proyecto.

21

Tareas interrelacionadas basadas en esfuerzos y recursos

Complejidad sistmica de los problemas.

22

11

27/06/2013

Son nicos
Todos los proyectos por similares que sean tienen

caractersticas que los hacen nicos.

No soy tan popular para ser diferente
Homero Simpson

23

Qu es la administracin de proyectos?
.tener el trabajo hecho. en tiempo, con el presupuesto acordado y habiendo

satisfecho las especificaciones o requerimientos.

Mas acadmicamente administracin de proyectos es la aplicacin de

conocimientos, habilidades, herramientas y tcnicas a las actividades del proyecto para satisfacer los requerimientos del proyecto.

Administrar un proyecto incluye:

Identificar los requerimientos Establecer objetivos claros y alcanzables Adaptar las especificaciones, planes y el enfoque a los diferentes intereses de los

involucrados (stakeholders).

24

12

27/06/2013

La restriccin triple
(The triple constrain)
Objetivos de proyecto: que est el proyecto tratando de alcanzar? Tiempo: cunto tiempo debera llevar completarlo? Costos: cunto debera costar?
El balance de estos tres factores afecta directamente la calidad del proyecto proyectos de alta calidad entregan el producto requerido, el servicio o resultado, satisfaciendo los objetivos en el tiempo estipulado y con el presupuesto planificado.

Es responsabilidad del Lder de proyecto balancear estos tres objetivos (que a menudo compiten entre ellos)
25

La restriccin triple
Alcance
Performance Requerida

Restriccin de Presupuesto

COSTO

Fecha Comprometida 26

Relacin Optima de Tiempo-Costo

13

27/06/2013

Rol del Lder de Proyecto / Equipo

Cliente Lder de Proyecto Niveles Altos de Administracin

Subcontratistas Equipo de Proyecto

Organizaciones Regulatorias Gerentes Funcionales

27

Equipo de Proyecto
Qu es un equipo de Proyecto?
Un grupo de personas comprometidas en alcanzar un conjunto de objetivos de los cuales se sienten mutuamente responsables.

Caractersticas de un equipo de proyecto

Diversos conocimientos y habilidades Posibilidad de trabajar juntos efectivamente / desarrollar sinergia Usualmente es un grupo pequeo Tienen sentido de responsabilidad como una unidad

14

27/06/2013

Qu es el plan de proyecto? Un plan es a un proyecto lo que una hoja de ruta a un viaje

29

Qu es un plan de proyecto?
El plan de proyecto documenta:
Qu es lo que hacemos? Cundo lo hacemos? Cmo lo hacemos? Quin lo va a hacer?

30

15

27/06/2013

Qu implica la planificacin de Proyectos de Software?

31

Definicin del Alcance del Proyecto Definicin de Proceso y Ciclo de Vida Estimacin Gestin de Riesgos Gestin de Recursos (Personas/Software/Hardware) Programacin de Proyectos Definicin de Controles Definicin de Mtricas

Definicin del Alcance

Alcance del Producto:
Son todas las caractersticas que pueden incluirse en un

producto o servicio.
Alcance del Proyecto:
Es todo el trabajo y solo el trabajo que debe hacerse para

entregar el producto o servicio con todas las caractersticas y funciones especificadas.

32

16

27/06/2013

Alcance: Cmo se mide?

El cumplimiento del Alcance del Proyecto:
Se mide contra el Plan de Proyecto (o Plan de Desarrollo de

Software).
El cumplimiento del Alcance del Producto:
Se mide contra la Especificacin de Requerimientos.

33

Requerimientos

Diseo
Implementacin

Definir de proceso y Ciclo de Vida

Prueba
Despliegue y Operacin

Workflows centrales Requerimientos Anlisis Diseo Implementacin Prueba

34

17

27/06/2013

Estimaciones
Tamao Esfuerzo Calendario Costo Recursos Crticos
35

Riesgo.

Problema esperando para suceder Evento que podra comprometer el xito del proyecto
36

18

27/06/2013

Gestin de Riesgos Proactiva

Identificar
Especificacin de riesgos

Analizar
Lista de Riesgos

Aprendizaje Base de Base de Conocimiento Conoc. De Riesgos Riesgos

Planificar

Seg. y Control

Identificar y gestionar Riesgos a travs de todas las fases del proyecto

37

Monitoreo y Control

19

27/06/2013

Cmo se atrasa un proyecto

39

De a un da por vez

Fred Brooks

Mythical man months

40

20

27/06/2013

Comparar lo planificado y lo Real

Hoy
41

Tres factores top para el xito de un proyecto

Monitoreo & Feedback Tener una misin/objetivo claro Comunicacin

42

21

27/06/2013

Causas de fracasos en proyectos

Fallas al definir el problema Planificar basado en datos insuficientes La planificacin la hizo el grupo de planificaciones No hay seguimiento del plan de proyecto Plan de proyecto pobre en detalles Planificacin de recursos inadecuada Las estimaciones se basaron en supuestos sin consultar datos histricos Nadie estaba a cargo

Procesos de Desarrollo de Software y Modelos de Proceso (Ciclos de Vida)

44

22

27/06/2013

No existe mayor signo de demencia que hacer lo mismo una y otra vez y esperar resultados diferentes
Albert Einstein

45

CON QUE
Equipos Materiales

DUEOS DEL PROCESO

CON QUIEN
Habilidad Formacin

ENTRADAS

PROCESO PRINCIPAL
Actividades del Proceso

SALIDAS

Mtodos usados para controlar el proceso

QUE METODO

QUE MIDO
Indicador Eficacia Indicador Eficiencia

23

27/06/2013

ENTRADA:
Puede ser materia prima, materiales, informacin, documentos, personas, etc. Usualmente son salidas de otros procesos.

PROCESO:
Conjunto de actividades mutuamente relacionadas o que interactan, las cuales transforman elementos de

entrada en resultados.

Los procesos de una organizacin son generalmente planificados y puestos en prctica bajo condiciones

controladas para aportar valor.

PRODUCTO / SALIDA:
Resultado de un proceso. Los productos pueden ser servicios, software, hardware y/o materiales procesados.

CLIENTE:
Organizacin o persona que recibe un producto.

El cliente puede ser interno o externo a la organizacin.

PROVEEDOR:
Organizacin o persona que proporciona un producto o servicio Un proveedor puede ser interno o externo a la organizacin.

INDICADOR:
Conjunto de mediciones realizadas al proceso para evaluar tanto las actividades como

los resultados.

24

27/06/2013

Gente
Experiencia Motivacin Disponibilidad Formacin

Herramientas
Infraestructura Funcionalidad Disponibilidad

POLITICA Lecciones Aprendidas Anlisis de rbol de Causas Performance del Proceso Anlisis de Tendencia de Datos Salida

Entrada

PROCESO CONTROLADO

Activos
Lista de Chequeo Plantillas Mejores Ejemplos Datos Histricos

Mtodos
Tcnicas Guas Procedimientos

Mtricas, ej: Tiempo Esfuerzo Costo Tamao Defectos

El proceso de Software

50

Conjunto estructurado de actividades para desarrollar un sistema de software Estas actividades varan dependiendo de la organizacin y el tipo de sistema que debe desarrollarse. Debe ser explcitamente modelado si va a ser administrado.

25

27/06/2013

Definicin de un Proceso de Software

Proceso: La secuencia de pasos ejecutados para un propsito dado (IEEE)

Proceso de Software: Un conjunto de actividades, mtodos, prcticas, y transformaciones que la gente usa para desarrollar o mantener software y sus productos asociados (Sw-CMM)

B A C D Procedimientos y mtodos

Personas con habilidades, entrenamiento y motivacin

51

PROCESO Herramientas y Equipos

A cerca de los Modelos de Ciclo de Vida...

Una herramienta para la planificacin y el monitoreo de

proyectos. Un modelo de progreso del proyecto. Independiente de los mtodos y procedimientos de cada actividad del ciclo de vida. Muy abstracto.
52

26

27/06/2013

Clasificacin de los Ciclos de Vida

Hay tres tipos bsicos de Ciclos de Vida Secuencial Iterativo Recursivo
Nota: Todos los modelos recursivos son iterativos, sin embargo

no todos los modelos iterativos son recursivos.

53

Tipos Bsicos del Ciclo de Vida

Secuenciales: significa que una actividad no inicia sino hasta que ha terminado la

anterior. Una luego de la otra

Iterativos: significa hacer algo una y otra vez (iteracin); como un re-trabajo o

un DO LOOP en un programa.

Recursivos: significa que se comienza con algo en forma completa, como una

subrutina que se llama a si misma en un ciclo completo que comienza nuevamente.

54

27

27/06/2013

El ciclo de vida Incremental construye un poquito cada vez

El incremento trabaja con una idea completamente formada. Y terminar a tiempo requiere realizar una estimacin precisa, desde el comienzo.

El ciclo de vida iterativo construye una versin aproximada, la validad y luego construye la idea lentamente conforme avanza en las iteraciones.
Las iteraciones le permiten moverse de una idea vaga a una idea definitiva, aproximndose mientras avanza.

28

27/06/2013

Uso de Ciclos de Vida: Beneficios

Agilizar su proyecto Mejorar la velocidad de desarrollo Mejorar Calidad Mejorar el seguimiento y control del proyecto Minimizar costos generales (overhead) Minimizar la exposicin de los riesgos Mejorar la relacin con los clientes

Modelo de Cascada Puro

Secuencia de pasos ordenada

Requerimientos Diseo Implementacin

Revisin al final de cada fase Conducida por documentacin Fases discontinuas, no se

superponen

Prueba Operacin y Mantenimiento

58

29

27/06/2013

Modelos de Ciclo de Vida: Espiral

59

Iterativos
Requerimientos Anlisis & Diseo Implementacin Testing Despliegue Requerimientos Anlisis & Diseo Implementacin Testing Despliegue

Requerimientos

Anlisis & Diseo

Implementacin

Testing

Despliegue

Iteracin 1

Iteracin 2

Iteracin 3
Fase Iniciacin Elaboracin Construccin Transicin

Proceso Mini-Cascada
Planif. Iteracin Captura Reqs. Anlisis & Diseo Implementacin Prueba Preparar Release

Conjunto de Requerimientos Conjunto de Diseo Conjunto de Implementacin Conjunto de Despliegue

30

27/06/2013

Eligiendo un Ciclo de Vida

La eleccin depende de muchos factores tales como:

61

Riesgos tcnicos Riesgos de Administracin Volatilidad de los requerimientos Ciclo de tiempo requerido Aspectos del cliente Tamao del Equipo Conocimiento del ciclo de vida

Mtodos giles

31

27/06/2013

Los problemas de las metodologas rigurosas

Baskerville, Travis &Treux, 1992 mtodos orientados a proyectos

grandes (realmente grandes) falta de adaptabilidad

DeMarco & Lister, 1987 la gente puede centrarse ms en la

Tolvanen, 1998 overhead de proceso mtodos difciles de usar y aprender ambigedad

documentacin que en el desarrollo real no se asigna suficiente responsabilidad a los desarrolladores falta de motivacin
enfoques rigurosos ms apropiados

Bohem (2002)

para sistemas crticos. La inercia de un enfoque riguroso no es apropiada para ambientes de cambio y velocidad.

63

Desarrollo gil de Software (Agile)

Un compromiso til entre nada de proceso y demasiado proceso (Fowler, 2001)

64

32

27/06/2013

Manifiesto gil http://www.agilemanifesto.org/iso/es/

Declaracin de principios giles, los cuatro valores :
Individuos e interacciones por sobre procesos y herramientas Software funcionando por sobre documentacin detallada Colaboracin por sobre negociacin con el cliente Responder a cambios por sobre seguir un plan

2001, Kent Beck, Mike Beedle, Arievan Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, 850+ signers
65

Manifiesto Agil
Refinamiento Iterativo
Crear varios modelos en paralelo, por ejemplo diagrama de clase y de secuencia Iterar hacia otros artefactos Es decir, 5% de diagrama de clases, luego 5% de interaccin

Simplicidad
Usar la herramienta ms simple Es decir, pizarrn y cmara video Mostrar modelos de manera simple Es decir, en la pared, no en una pgina WEB

Documentacin
Descartar modelos temporales Es decir, tomar una foto y borrar el pizarrn Actualizar solo donde duela Es decir, desarrollar cdigo es ms importante que mantener un diagrama

Equipo de Trabajo
Modelar con otros Es decir, diagramacin de pares Mostrar modelos pblicamente Es decir, datos de administracin del proyecto, en la pared

66

33

27/06/2013

Individuos e Interacciones
La suposicin de los roles intercambiables

67

Software por sobre documentacin

Foco en la implementacin por sobre el modelado. No significa que no se documenten requerimientos, diseo, etc.

Debate Cmo s que mi proyecto tiene suficiente/demasiada documentacin?

68

34

27/06/2013

Colaboracin del Cliente

Algunas metodologas un poco extremas El espritu es no extorsionar al cliente con un contrato.

Estar dispuesto al cambio, y cerca del cliente para predecirlo. Requirements emergence Cambios a los requerimientos originales pueden tener mayor valor que los relevados inicialmente

69

Los 12 principios del Manifesto(I)

1 - La prioridad es satisfacer al cliente a travs de releases tempranos y frecuentes 2 - Recibir cambios de requerimientos, an en etapas finales 3 - Releases frecuentes (2 semanas a un mes) 4 - Tcnicos y no tcnicos trabajando juntos TODO el proyecto 5 - Hacer proyectos con individuos motivados 6 - El medio de comunicacin por excelencia es cara a cara

70

35

27/06/2013

Los 12 principios del Manifesto(II)

7 - La mejor mtrica de progreso es la cantidad de software funcionando 8 - El ritmo de desarrollo es sostenible en el tiempo 9 - Atencin continua a la excelencia tcnica 10 - Simplicidad - Maximizacin del trabajo no hecho 11 - Las mejores arquitecturas, diseos y requerimientos emergen de equipos auto-organizados 12 - A intervalos regulares, el equipo evala su desempeo y ajusta la manera de trabajar
71

1. Satisfaccin del cliente como prioridad uno

Basado en los releases frecuentes y en etapas tempranas Glass (2001) Cuidado con el manejo de expectativas del

cliente

72

36

27/06/2013

2 - Cambios son bienvenidos

Brooks (1987) ya identific el problema stabilize and synchronize de Microsoft Requirements emergence

Debate
Cmo se factura esto?
73

3 - Entregas frecuentes
Mejor manejo de requerimientos (Cockburn, 2000) Evolucin del modelo en espiral

74

37

27/06/2013

4 - Tcnicos y desarrolladores trabajando juntos

En mi trabajo, tengo los usuarios ms estpidos del mundo Microsoft: managers escriben cdigo Reduccin del gap comunicacional

75

5 - Motivacin
People factor La gente es la mejor oportunidad para mejorar la

productividad (Bohem, 1981) El Principio de Dilbert

Afirma que las compaas tienden a ascender sistemticamente a sus empleados menos competentes a cargos directivos para limitar as la cantidad de dao que son capaces de provocar
76

38

27/06/2013

6 - Comunicacin cara a cara

No es necesariamente informal El espacio fsico debe favorecer la comunicacin Frecuentemente confundido con una reduccin en la

documentacin

77

7 - Software es la mejor medida de progreso

No significa que las metodologas giles no colecten otras

mtricas No confundir funcionalidad con cantidad de software La mayora de las mtricas tradicionales son un epifenmeno de software entregado

78

39

27/06/2013

8 - Ritmo de desarrollo sostenible

DeMarco & Lister (1987) : Ms de 40 horas por semana no

es sostenible en el tiempo Responsabilidad social + efectividad ($) Una de las caractersticas de venta de CMM a desarrolladores es, de hecho, la disminucin del tiempo extra

79

9 - Excelencia tcnica
Revisin continua de la arquitectura/diseo Mejora continua del producto

Peer reviews

80

40

27/06/2013

10 - Maximizar el trabajo no hecho (o Simplicidad)

No implementar ms de lo acordado No debe confundirse con relegar diseo y saltar a la codificacin Refactoring No es good enough quality

Debate Cmo se alinea este principio con la forma de ser del desarrollador argentino?
81

11 - Equipos auto-organizados
Sinergia (DeMarco & Lister) Es un principio que apunta a la organizacin Proceso de reclutamiento

Objetivos - motivacin - satisfaccin con el trabajo

Preservar los equipos de un proyecto a otro

82

41

27/06/2013

12 - Autoevaluacin
Mejora continua del proceso Conocimiento organizacional Los cambios pueden ser un poco errticos si no se aplica un

criterio cuantitativo

83

Para pensar #1
1 - Fundamentar reducciones en el costo de cambio de requerimientos en
una metodologa que cumple los principios de Agile. Comenzar con la curva clsica, de cualquier libro de ingeniera de software. 2 - Evaluar el costo de cambios desde una perspectiva del cliente. Es similar la necesidad del cliente si se usa una metodologa tradicional? 3 - Si vemos un libro de requerimientos como una orden de trabajo, y las correspondientes estimaciones como el presupuesto, el contrato de la empresa de software con su cliente es bastante directo . Bosqueje como sera un contrato usando una metodologa gil que implemente la misma aplicacin.
84

42

27/06/2013

Definido vs. Emprico

Hay 2 alternativas para controlar cualquier proceso
Definido:
Asume que podemos repetir el

mismo proceso una y otra vez, indefinidamente, y obtener los mismos resultados. La administracin y control provienen de la predictibilidad del proceso definido.
85

Definido vs. Emprico

Emprico:

Asume procesos complicados con variables cambiantes. Cuando se repite el proceso, se pueden llegar a obtener resultados diferentes. La administracin y control es a travs de inspecciones frecuentes y adaptaciones Son procesos que trabajan bien con procesos creativos y complejos. (a que suena??)

86

43

27/06/2013

Teora de control de procesos

El desarrollo de sistemas contiene tanta complejidad y es tan impredecible, que debe ser gestionado bajo un modelo emprico de control de procesos

Babatunde Ogannaike Process Dynamics Modeling and Control.

87

Pero qu significa gil?

Balance entre ningn proceso y demasiado proceso. La diferencia

inmediata es la exigencia de una menor cantidad de documentacin, sin embargo no es eso lo ms importante: Los mtodos giles son adaptables en lugar de predictivos. Los mtodos giles son orientados a la gente en lugar de orientados al proceso.

88

44

27/06/2013

Pero qu significa gil?

Los mtodos giles son un subconjunto de los mtodos

iterativos. El modelado gil no es un proceso completo , un mtodo gil, es un conjunto de principios y prcticas para modelado y anlisis de requerimientos, que complementa a la mayora de los mtodos de desarrollo iterativos e incrementales.
89

90

45

27/06/2013

Por qu ir a Agile?

91

Y si vamos, donde vamos?

92

http://www.versionone.com/state_of_agile_development_survey/11/

46

27/06/2013

Cundo Agile es aplicable?

Agile da mejores resultados cuando

los problemas a ser resueltos caen dentro del espacio Complex. El desarrollo de nuevos productos y Knowledge Work tienden a estar en el espacio Complex. Investigacin esta dentro de Anarchy Mantenimiento cae en Simple (siempre????)
93

SCRUM
Un framework para Gestin gil de Proyectos

47

27/06/2013

En un Scrum, hay que actuar como un unidad, no como 8 individuos. Todos tienen un rol. Nunca debemos olvidar que cuando trabajamos juntos como una unidad, el todo es ms que la suma de las partes.
95

The On-Line Rugby Coaching Manual

Autores Scrum
Ken Schwaber: desarroll y formaliz Scrum

para el desarrollo de sistemas

Jeff Sutherland: pensamientos y prcticas iniciales,

previo a su formalizacin con Ken.

Mike Beedle: Utiliz y mejor Scrum,

integrndolo a XP.

96

48

27/06/2013

Qu es SCRUM?
Scrum es un framework que permite crear su propio proceso para

crear nuevos productos.

Scrum es simple, puede ser implementado en pocos das, pero

puede tomar mucho tiempo perfeccionarlo.

Scrum no es una metodologa es un camino Ken Schwaber (Boulder, Co, Nov. 2005)
97

Scrum es emprico
Las metodologas rigurosas se basan en mtodos definidos,

con la idea de lnea de ensamble

El control en Scrum se alcanza con inspecciones frecuentes y

correspondientes ajustes

98

49

27/06/2013

Valores de Scrum
Compromiso Foco Abierto a ideas Respeto

Valenta

99

El ritmo de scrum

100

50

27/06/2013

Cimientos
Empirismo Auto-organizacin Colaboracin Priorizacin Time Boxing

101

Cimientos

Empirismo
El empirismo es una teora filosfica que enfatiza el papel de la experiencia, ligada a la percepcin sensorial, en la formacin del conocimiento. Para el empirismo ms extremo, la experiencia es la base de todo conocimiento, no slo en cuanto a su origen sino tambin en cuanto a su contenido. Se parte del mundo sensible para formar los conceptos y stos encuentran en lo sensible su justificacin y su limitacin.

Procesos definidos y planificacin detallada en las primeras fases son reemplazadas por ciclos de inspeccin y revisin just in time y ciclos adaptativos.
102

51

27/06/2013

Cimientos
Auto organizacin
La auto-organizacin es un proceso en el que la organizacin interna de un sistema, generalmente abierto, aumenta de complejidad sin ser guiado por ningn agente externo. Normalmente, los sistemas auto-organizados exhiben propiedades emergentes. La auto-organizacin es objeto de estudio interdisciplinar, pues es una propiedad caracterstica de los sistemas complejos, ya sean stos matemticos, fsicos, qumicos, biolgicos, sociales o econmicos.

Pequeos grupos de trabajo que manejan su propia carga de tareas y se organizan entre ellos alrededor de un objetivo claro y tomando en cuenta las restricciones.
103

Cimientos
Colaboracin
La colaboracin se refiere abstractamente a todo proceso donde se involucre el trabajo de varias personas en conjunto. Tambin cuando ayuda a una persona a hacer algo que se le dificulte, o en caso de que no pueda hacerlo.

Lideres de Scrum, diseadores de productos y clientes colaboran con los desarrolladores ellos no los gerencian o dirigen.
104

52

27/06/2013

Cimientos
Priorizacin
Dar prioridad a alguna cosa

Trabajar en lo ms importante no perder el tiempo haciendo foco en el trabajo que no tiene y/o agrega valor.
105
105

Cimientos
Time Boxing
Time boxing es una tcnica de planificacin en proyectos, tpicamente de software, donde el schedule (programacin) es dividido en un nmero separado de perodos de tiempo (time box), normalmente entre 2 y 6 semanas, los cuales tienen sus propios entregables, fechas y costos.

Timeboxing crea el ritmo que gua el desarrollo.

106

53

27/06/2013

EntoncesCmo trabaja Scrum?

Equipos pequeos (< 10 personas, ideal 7+-2) Una serie de Sprints (30 das) Incrementos visibles y usables Timeboxing

Auto organizacin
Colaboracin Priorizacin
107

Scrum se siente diferente...

Menos tiempo planeando y definiendo tareas Menos tiempo creando y leyendo reportes Se pasa ms tiempo con el equipo investigando la situacin
Scrum Supone dominios impredecibles No supone un proceso repetible
108

54

27/06/2013

Roles

110

Compromiso vs Involucramiento
55

27/06/2013

Roles en Scrum
Scrum Master Dueo de Producto - Product Owner Equipo de trabajo Scrum Team

111

Product Owner
Controla y gestiona el Backlog. Una persona, no un Comit Nadie puede decirle al equipo una

prioridad diferente
Acciones visibles
112

56

27/06/2013

Scrum Master
Es responsable de que las prcticas, valores y reglas se realicen Nexo entre la gerencia y el equipo Dirige los Scrum diarios, comparando el progreso planeado

113

con lo real. Se asegura que se resuelven los impedimentos y se toman decisiones rpidas Trabaja con la gerencia y el cliente para identificar el dueo del producto El Scrum Master, el dueo del producto y el equipo producen un Backlog de producto

Scrum Master - Actividades

Toma decisiones en reuniones de Scrum

Registra y resuelve problemas

Mantiene el equipo enfocado Realiza el seguimiento de avance
114

57

27/06/2013

Responsabilidades del Scrum Master

Mantener las reuniones diarias cortas mediante la aplicacin

de las reglas:
Hora y lugar fijos en lo posible Los gerentes pueden asistir pero slo los desarrolladores

participan Una reunin de Scrum no es una reunin de diseo

115

El equipo
7+-2 personas. Si hay ms de 8 personas, hacer varios equipos trabajando sobre el

mismo Backlog. Autnomos y auto-organizados. Compromiso de entregar un conjunto de tems del Backlog al final de un Sprint Libertad de accin. Limitado por estndares y convenciones organizacionales. No hay roles Todos codifican

116

58

27/06/2013

El equipo - Dinmica
Scrum pretende ser una sombrilla bajo la cual el equipo puede dar

lo mejor Scrum es emprico, y a veces se alcanza el objetivo reduciendo funcionalidad

117

Ambiente de trabajo
Abierto
El silencio absoluto es un mal signo

Pizarrones El equipo define sus horarios

118

59

27/06/2013

Compromiso vs Involucramiento
Qu roles son Cerditos? Qu roles son Gallinas? Usuarios??? Stakeholders??? Dueo del producto??? Gerencias/Gerentes?? Scrum Master??
119

Conceptos de Scrum

60

27/06/2013

Todo junto

121

El backlog de producto (product backlog)

Es una cola priorizada de funcionalidades tcnicas y de negocio, que necesitan ser

desarrolladas

Ken Schwaber

El Backlog de producto contiene la lista de requerimientos

Se listan caractersticas, funciones, tecnologas, mejoras, bugs, etc., que sern

aplicadas al producto

El Backlog est incompleto inicialmente, aunque solo se necesita lo suficiente

para realizar el primer Sprint de 30 das

122

61

27/06/2013

El backlog se origina en:

Marketing Ventas Desarrollo Soporte al cliente

Caractersticas del Backlog priorizado tambin contiene problemas a ser solucionados, y que son dependencias de otros tems del Backlog
123

Asteroides.. como refino un product backlog?

Trabajar con un backlog de producto es como

jugar a Asteroides Grandes rocas (epics) se rompen en pedazos de rocas ms pequeas (stories) hasta que son lo suficientemente pequeas para ser eliminadas (desarrolladas y entregadas).

124

62

27/06/2013

Estimaciones del Backlog

Las estimaciones son un esfuerzo colaborativo entre las partes Las estimaciones son iterativas Si un tem no puede ser

debidamente estimado, se debe dividir en el Backlog. para la funcionalidad en el Sprint.

Los estimados sirven de base

125

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
Este es el product backlog
126

63

27/06/2013

Ejemplo de Product Backlog

Backlog item
Permitir que un invitado a hacer una reserva. Como invitado, quiero cancelar una reserva. Como invitado, quiero cambiar las fechas de una reserva. Como un empleado de hotel, puedo ejecutar informes de los ingresos por habitacin disponible

Estimacin
3 5 3 8

Mejorar el manejo de excepciones

... ...

8
30 50
127

Backlog del Sprint

El equipo determina que debe hacerse para cumplir el objetivo del Sprint El dueo del producto suele asistir

Se realiza una lista de tareas que tomen de 4 a 16 horas para completarse

El Backlog no se modifica durante el desarrollo Si el equipo descubre que el Backlog no puede realizarse, el Scrum Master y el

dueo del producto determinan si:

128

Algn tem puede ser removido del backlog Alguna funcionalidad puede eliminarse

64

27/06/2013

Ejemplo de Sprint Backlog

Tareas
Codificar UI Codificar negocio Testear negocio Escribir ayuda online Escribir la clase foo Agregar error logging

L
8 16 8 12 8

M
4 12 16 8

M
8 10 16 8 8

J
4 11
8 4

8 8

Sprint
Perodo fijo de tiempo, sugerido 30 das Dentro del Sprint
No se puede cambiar el alcance
No se puede agregar

funcionalidad No se pueden modificar las reglas del equipo

130

65

27/06/2013

Elementos de un Sprint
Reuniones de Scrum Se produce un incremento usable y visible Los incrementos se basan en un producto anterior Compromiso de los miembros a la asignacin

131

Reglas de un Sprint
Foco en la tarea SIN interrupciones

SIN cambios
El mismo equipo puede descubrir ms trabajo a ser hecho

132

66

27/06/2013

Story time
El equipo se rene con el PO para discutir tems del backlog

de alta prioridad, determinar su criterio de aceptacin y asignar la priorizacin a cada nuevo tem. Esto ocurre inicialmente antes del desarrollo y despus iterativamente en cada sprint.

133

Objetivo del sprint

Una declaracin Un objetivo claro a alcanzar

134

67

27/06/2013

Mecnica de los Sprints

En un Sprint se congelan 3 de las 4 variables de un proyecto:
Tiempo: 30 das Costo: salarios + ambiente Calidad: generalmente un estndar organizacional

El Equipo puede cambiar funcionalidad siempre y cuando

cumpla con el objetivo del Sprint.

135

Tareas obligatorias
En un Sprint hay 2 tareas mandatorias
Reuniones Scrum diarias: participan TODOS los miembros del

equipo Backlog del Sprint: debe estar actualizado y con los ltimos estimados de los desarrolladores

136

68

27/06/2013

Reuniones de planeamiento de Sprint

Dos reuniones consecutivas
El equipo se rene con el dueo del producto, la gerencia y los

usuarios para decidir la funcionalidad a implementar El equipo decide COMO llevarlo a cabo
Inputs
Backlog, ltimo incremento, mtricas

137

En resumen, un sprint planning meeting es..

Capacidad del Equipo Product Backlog Condiciones del Negocio Producto Actual

Sprint Planning meeting

Priorizacin

Analizar y evaluar el Product Backlog Seleccionar el objetivo del Sprint

Objetivo del Sprint

Planificacin

Tecnologa

Decidir cmo alcanzar el objetivo del Sprint (diseo) Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog (user stories / features) Estimar Sprint Backlog en horas

Sprint Backlog

69

27/06/2013

Reuniones de Scrum diarias

Cortas (15 -30 min). Se analiza el estado. Facilitador: Scrum Master Asiste todo el equipo. No para soluciones de problemas El Scrum Master pregunta 3 cosas a los asistentes:
Qu se complet desde la ltima reunin? Qu obstculos se presentaron? Qu va a hacer hasta la prxima reunin?

No es dar un status report al Scrum Master Se trata de compromisos delante de pares

139

Beneficios de los Scrums diarios

Mejora la comunicacin Elimina otras reuniones Identifica y remueve obstculos Promueve decisiones rpidas Mejora el conocimiento de todos
140

70

27/06/2013

Cancelacin de un Sprint
Se puede cancelar un Sprint si las circunstancias hacen que no sea

necesario

El objetivo se vuelve obsoleto Las condiciones tcnicas o de mercado cambian

Decidido por el equipo

Porque no se puede alcanzar el objetivo Se encuentra un problema muy grande

Cancelar un Sprint es un costo

141

Sprint review
Reunin informativa de unas 4 horas El equipo presenta el incremento desarrollado a gerentes, clientes, usuarios y el dueo del

producto
Informal
Regla de 2 hs preparacin

No usar diapositivas

Todo el equipo participa Se invita a todo el mundo Se reportan los problemas encontrados CUALQUIER tem puede ser agregado, eliminado, re-priorizado
142

Se estima el nuevo Sprint y se asignan tareas

71

27/06/2013

Sprint retrospective
Peridicamente, se echa un vistazo a lo que funciona y lo que no Normalmente 15 a 30 minutos Se realiza luego de cada sprint Todo el equipo participa
ScrumMaster Product owner Equipo Posiblemente clientes y otros
143

Start / Stop / Continue

Todo el equipo se rene y discute lo que les gustara:

Comenzar a hacer Dejar de hacer

Esto es slo una de las muchas maneras de hacer una retrospectiva.

Continuar haciendo
144

72

27/06/2013

Herramientas de Scrum

TASKBOARD
TARJETA Cdigo del tem Backlog Nmero del Sprint Nombre de la Actividad Iniciales de la Persona Tiempo Estimado en Horas

146

73

27/06/2013

Taskboard

147

Taskboard
TABLERO Story To Do Work In Process To Verify Done

148

74

27/06/2013

Taskboard

149

150

75

27/06/2013

BUENA GRANULARIDAD

MALA GRANULARIDAD
151

Grficos de Backlog
La gerencia necesitas datos acerca de:
Progreso del Sprint Progreso del Release Progreso del producto

El backlog de trabajo es la cantidad de trabajo que queda por ser

realizado

Tendencia del Backlog: trabajo que queda vs. tiempo

152

76

27/06/2013

Tareas
Codificar UI Codificar Negocio Testear Negocio Escribir ayuda online
50 40 30 20 Horas

L
8 16 8 12

M
4 12 16

M
8 10 16

J
7 11

V
8

10
0

BURNDOWN Chart
Diagnstico?

No todo lo incluido en el sprint ser entregado en la fecha propuesta. El backlog no fue modificado para alcanzar la fecha (remover requerimientos o modificar la fecha) Posibles causas: Pobres tcnicas de estimacin Mal manejo de riesgos Rotacin del equipo o renuncias Este grfico muestra que el Scrum Master (SM) y el Product Owner (PO) no reaccionaron para evitar esta situacin. Evite llegar a este estadio!
154

77

27/06/2013

Burndown charts
Diagnstico?

Este BC es mucho mejor que el anterior Al comienzo del sprint hubo problemas, pero en el medio el equipo de trabajo reaccion y tomo medidas correctivas. Por la lnea se nota que el PO quit requerimientos para mantener la fecha de release. Tambin pone en evidencia un mejor manejo de riesgos lo que facilit aumentar la velocidad en la segunda parte del sprint.

155

Burndown charts
Diagnstico?

Este BC tambin tiene caractersticas negativos. Este no es un ejemplo de desarrolladores con las mejores habilidades tcnicas. Demuestra pobres tcnicas de estimacin. El PO y el SM deberan haber agregado ms requerimientos para ese release.

156

78

27/06/2013

Burndown charts
Diagnstico?

Ideal Buenas tcnicas de estimacin. Buena velocidad de desarrollo Buen manejo de impedimentos Todas los requerimientos prometidos son los entregados. Buen manejo de la asignacin de tareas (tareas cortas, reporte diario) Quizsdemasiado bueno para ser verdad
157

BENEFICIOS DE SCRUM

79

27/06/2013

Beneficios de Scrum
Se gestionan los cambios de requerimientos Se incorpora la visin de mercado Los clientes ven incrementos que refinan los requerimientos en un

tiempo razonable

Mejores relaciones con el cliente

159

Algunos usuarios de SCRUM: Microsoft

SCRUM en 100 palabras

Scrum es un mtodo gil que nos permite centrarnos en
ofrecer el ms alto valor de negocio en el menor tiempo. Nos permite rpidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). El negocio fija las prioridades. Los equipos se autoorganizan a fin de determinar la mejor manera de entregar las funcionalidades de ms alta prioridad. Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorndolo en otro sprint.

Yahoo
Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One

BBC
Intuit Nielsen Media First American Real Estate BMC Software 160 John Deere

80

27/06/2013

Se ha utilizado SCRUM para:

Software comercial Desarrollos internos Desarrollos bajo Contrato Proyectos Fixed-price Aplicaciones Financieras Aplicaciones certificadas ISO 9001 Sistemas Embebidos Sistemas con requisitos 7x24 y Desarrollo de video juegos Sistemas crticos de soporte vital,

aprobados por la FDA Software de control satelital Sitios Web Software para Handheld
Telfonos porttiles
Aplicaciones de Network switching Aplicaciones de ISV Algunas de las ms grandes aplicaciones

99.999% de disponibilidad

Joint Strike Fighter

161

en uso

Pensamiento Final
Scrum no es para todos, sino para aquellos que tienen que trabajar con sistemas funcionando con la complejidad de tecnologas inestables y el surgimiento de requerimientos
Ken Schwaber

162

81

27/06/2013

Para pensar.
Por qu la gente est tan emocionada con estas nuevas

metodologas?

Cundo scrum es apropiado? Cundo algo agile es no apropiado? Sino puede aplicar todo, que aplicara?
163

Scrum es bailar!

164

82

27/06/2013

Scrum lo ayudar a fracasar en 30 das o menos.

165

166

27/06/2013 10:17 a.m.

83

27/06/2013

167

27/06/2013 10:17 a.m.

84