Tema II – Métodos ÁgilesPS... · METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS...

06/10/2011

1

Procesos de Software www.kybele.urjc.es

Tema II – Métodos Ágiles

Dr. Javier Garzás

[email protected]

Universidad Rey Juan Carlos


2

ÍNDICE

METODOLOGÍAS ÁGILES VS TRADICIONALES

2 METODOLOGÍAS HÍBRIDAS

3 SCRUM

4

1

PRÁCTICAS ÁGILES

5 OTRAS METODOLOGÍAS ÁGILES

6 CONSIDERACIONES SOBRE METODOLOGÍAS ÁGILES

06/10/2011

2

¿Se puede desarrollar softwaredesarrollar softwareigual que industrialmente se construyen coches o casascoches o casas?

“La ingeniería softwareingeniería softwareera igual igual que la hardwarehardware. Aquellos tiempos, todos eran ingenieros hardware hardware o matemáticos”o matemáticos”

B. Boehm

1955

06/10/2011

3

1968

2010

06/10/2011

4

2005

Diseño previo e previo e inamovible…inamovible…

06/10/2011

5

…antes de laConstrucciónConstrucción

Predictibilidad…

06/10/2011

6

Ciclo de vida en CascadaCascada…

06/10/2011

7

06/10/2011

8

==

% avance

06/10/2011

9

Software

Tradicional

Diseño Construcción

V1V1

V2V2

V3V3

06/10/2011

10

Predicción vs Evolución

06/10/2011

11

EL CICLO DE VIDA ITERATIVO INCREMENTAL (I)

21

Se va liberando parte del producto periódicamente y cada entrega es un

incremento respecto a la anterior . Cada fasese realiza varias veces . Lo cual difiere del

desarrollo en cascada , donde las fases del ciclo de vida se realizan (en teoría) una única vez, y el inicio de una fase no comienza hasta

que termina la fase que le precede

ITERATIVO = INCREMENTAL

22

http://jan-so.blogspot.com/2008/01/difference-between-iterative-and.html

06/10/2011

12

EL CICLO DE VIDA ITERATIVO INCREMENTAL (II)

23

la construcción del

Se comenzó a aplicar en 1950, en la construcción del avión cohete X-15

En 1960 es aplicado por la

NASA en el proyecto Mercury

06/10/2011

13

1. Nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y

contínua de software con valor.

2. Aceptamos requisitos cambiantes, incluso en etapas avanzadas. Los procesos ágiles

aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software frecuentemente, con una periodicidad desde un par de semanas

a un par de meses, con preferencia por los periodos más cortos posibles.

4. Los responsables de negocio y los desarrolladores deben trabajar juntos diariamente

a lo largo del proyecto.

5. Construimos proyectos con profesionales motivados. Dándoles el entorno y soporte

que necesitan, y confiando en ellos para que realicen el trabajo.

Principios Ágiles

6. El método más eficiente y efectivo de comunicar la información a un equipo de

desarrollo y entre los miembros del mismo es la conversación cara a cara.

7. Software que funciona es la principal medida de progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Esponsores,

desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de

forma indefinida.

9. La atención continua a la excelencia técnica y los buenos diseños mejoran la

agilidad.

Principios Ágiles

06/10/2011

14

10. Simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de equipos que se

autoorganizan.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo, entonces

mejora y ajusta su comportamiento de acuerdo a sus conclusiones.

Traducción realizada por Agile Spain del original en Inglés. Éste pueden encontrarse en http://www.agilemanifesto.org/principles.html

Principios Ágiles

06/10/2011

15


HAY 3 TIPOS DE METODOLOGÍAS

29

ÁgilesTradicionales

Híbridas


30


Híbridas

METODOLOGÍAS ÁGILES VS METODOLOGÍAS TRADICIONALES

06/10/2011

16


31

Cambiabilidad:

Las metodologías ágiles están preparadas para adaptarse a cambios ,

mientras que las tradicionales presentan cierta resistencia a los mismos



32

Metodologías tradicionales:

conceptos característicos de

la fabricación industrial o la

arquitectura


06/10/2011

17


33

�Producción en cadena -> Trabajo repetible, generalmente más manual que

intelectual y operario sustituible

�División del trabajo y métodos Tayloristas (“Principles of Scientific

Management” (1912)) Actividades diferenciadas: el diseño y la construcción.

�Construcción: poca actividad intelectual y más manual.

�Los costes de la construcción (y sus cambios) son muy superiores a los del

diseño.

�Por ello el diseño pretende controlar el 100% la construcción

�Diseño basado en matemáticas - física



34

PERO EN SOFTWARE ¿ES LO MISMO?

•¿CUÁNDO SABEMOS QUÉ SOFTWARE QUERÍAMOS CONSTRUIR?

•¿CUESTA LO MISMO CAMBIAR UNA COLUMNA QUE UNA LÍNEA DE CÓDIGO?

•¿EXISTE UNA BASE MATEMÁTICA – CIENTÍFICA?


06/10/2011

18


CHOQUES ENTRE “OLAS”: ADAPTATIVO VS. PREDICTIVO


36

Algunas diferencias entre ágil y tradicional…

Algunas diferencias entre ágil y tradicional…


06/10/2011

19


37

Contrato:

En las metodologías tradicionales normalmente existe un contrato cerrado , mientras que en las ágiles no existe este tipo de contrato o, si existe, es bastante

flexible



38

Interacción con el cliente:

En las metodologías tradicionales, el cliente interactúa con el equipo de desarrollo mediante reuniones . Sin

embargo, en las metodologías ágiles el cliente forma parte del equipo de

desarrollo


06/10/2011

20


39

Tamaño de los grupos:

Las metodologías ágiles están definidas para grupos pequeños (menos de 10

integrantes) que trabajan en el mismo sitio. Sin embargo, las metodologías

tradicionales se definen para grupos grandes y posiblemente distribuidos



40

Arquitectura del software:

Para las metodologías tradicionales la arquitectura del software es esencial y se

expresa mediante modelos . Las ágiles, por su parte, ponen un menor énfasis en

la arquitectura del software


06/10/2011

21


41

documentación en los procesos ágiles

Documentación:

La documentación en los procesos ágiles es más relajada , mientras que en los

procesos tradicionales es más exhaustiva .


Procesos de Software www.kybele.urjc.es 42

1. Gran cambiabilidad de los requisitos

2. Necesidad de una arquitectura robusta

3. Documentación muy detallada

4. Un contrato cerrado

5. Se necesita interacción con el cliente

6. Tamaño equipo pequeño

7. Se necesita predicción

8. Se necesita Reacción - Adaptación

ÁGIL / TRADICIONAL

EJERCICIO: ¿CUÁL ES MÁS ADECUADO?

06/10/2011

22


43

ÍNDICE



3 SCRUM

4

1

PRÁCTICAS ÁGILES




METODOLOGÍAS HÍBRIDAS

44


Híbridas

06/10/2011

23


45


La realidad en las empresas refleja posturas moderadas en la implantación

de metodologías ágiles , hibridas y orientadas por la necesidad, al negocio y mejor práctica para cada organización y

proyecto


46


Consisten en adaptaciones de las Metodologías Ágiles , muchas veces

incorporándole prácticas formales , como, por ejemplo, el robustecer y hacer menos

iterativa la fase de diseño de la arquitectura software

06/10/2011

24


CUATRO MÉTODOS DE DESARROLLO

47

El intercambio de la cultura organizacional

y la estabilidad del proyecto sugieren dos

métodos nuevos de desarrollo además de

los métodos formales y ágiles


48

ÍNDICE



3 SCRUM

4

1

PRÁCTICAS ÁGILES



06/10/2011

25


SCRUM

49

Metodología ágil que proporciona un marco para la gestión de proyectos . Está especialmente indicada para proyectoscon un cambio rápido en los requisitos


SCRUM

50

Basada en entregas parciales priorizadas por el beneficio que aporta al receptor del

proyecto

06/10/2011

26


SCRUM

51

Permite obtener resultados tempranos y que permite adaptarse a los cambios en

los requisitos


CARACTERÍSTICAS PRINCIPALES

52

Desarrollo software mediante

iteraciones

Reuniones a lo largo del

proyecto

06/10/2011

27


EL PROCESO DE SCRUM

53


SPRINT

54

A cada iteración se le denomina sprint . El sprint es

un periodo de corta duración (2-4 semanas) en el

que se crea un producto potencialmente entregable

06/10/2011

28


PRIMER PASO: PRODUCT BACKLOG

55

Las características que van a implementarse en el sprint provienen de la Pila del

Producto (Product Backlog), que contiene una serie de

requisitos priorizados para su aplicación



56

HISTORIAS DE USUARIO

El product backlog debe ser una lista priorizada y estimada de historias

de usuario

Como xxx, quiero hacer yyy con el objetivo de

zzz

06/10/2011

29



57

PRIORIZACIÓN: ESTIMACIÓN Y VALOR

Planning Poker

Secuencia de Fibonacci



58

http://www.proyectosagiles.org/introduccion-estimacion-planificacion-agil#historias-usuario

PRIORIZACIÓN: RESPONSABILIDAD DEL PRODUCT OWNER (CLIENTE)

06/10/2011

30


SPRINT BACKLOG

59

Una vez seleccionadas las características que van a desarrollarse en el Sprint ,

se conforma la Pila del Sprint (Sprint Backlog), que se mantendrá inamovible durante toda la iteración


SPRINT BACKLOG

60

•Velocidad: cantidad de storypoints o historias de usuario que terminan por iteración .

• Burndown charts

06/10/2011

31


HIS

TO

RIA

S


LAS REUNIONES

62

Son una parte importantedentro de Scrum. Se definendiversos tipos de reuniones :

• Daily Scrum

• Sprint Planning Meeting

• Sprint Review Meeting

• Sprint Retrospective

06/10/2011

32


REUNIÓN DIARIA (DAILY SCRUM)

63

Reunión de no más de 15 minutos en la que se presenta que hizo ayer cada

miembro del equipo , que va a hacer hoy y que problemas se ha encontrado


REUNIÓN DE PLANIFICACIÓN DEL SPRINT (SPRINT PLANNING MEETING)

64

Se realiza al principio de cada Sprint , definiendo en ella que se va a realizar en

ese Sprint. Esta reunión da lugar al Sprint Backlog . Su duración no debe ser mayor

de 8 horas

06/10/2011

33


REUNIÓN DE REVISIÓN DEL SPRINT (SPRINT REVIEW MEETING)

65

Se realiza al final del Sprint . Durante la misma se indica qué ha podido

completarse y qué no , presentando el trabajo realizado a los implicados. No debe

durar más de 4 horas


RETROSPECTIVA DEL SPRINT (SPRINT RETROSPECTIVE)

66

sobre Se realiza al final del Sprint , sirve para que los implicados den sus impresiones sobre el Sprint que acaba de terminar . Se utiliza para la mejora del proceso . Esta reunión

debería durar 4 horas

06/10/2011

34


RESUMEN

67

•Scrum: Metodología ágil que proporciona un marco para la gestión de proyectos, indicada especialmente para proyectos con un cambio rápido en los requisitos.

•Sprint: Período de corta duración (2-4 semanas) en el que se crea un producto potencialmente entregable.

•Product backlog: Lista priorizada que contiene una serie de los requisitos del producto priorizados para su realización.

•Sprint backlog: Lista con las características que van a desarrollarse en el Sprint.


RESUMEN

68

•Daily Scrum: Reunión de no más de 15 minutos en la que se presenta que hizo ayer cada miembro del equipo, que va a hacer hoy y los problemas que se ha encontrado.

•Sprint planning meeting: Reunión de no más de 8 horas realizada al principio de cada Sprint, en la que se define que se va a realizar en el mismo.

•Sprint review meeting: Reunión de no más de 4 horas realizada al final del Sprint, en la que se presenta el trabajo realizado a los implicados.

•Sprint retrospective: Reunión de no más de 4 horas que se realiza al final del Sprint, realizada para recoger las impresiones de los implicados respecto al Sprint realizado.

06/10/2011

35


69

ÍNDICE



3 SCRUM

4

1

PRÁCTICAS ÁGILES




Automated builds

Continuous integration

Unit testing

Refactoring

Iterative development

Pair programming

Daily meetings

On-site customer

06/10/2011

36


71

ÍNDICE



3 SCRUM

4

1

PRÁCTICAS ÁGILES




OTRAS METODOLOGÍAS ÁGILES

72

eXtreme Programming

Dynamic Systems Development Method

Adaptive Software Development

Feature-Driven Development

Lean Development (LD)

Kanban

06/10/2011

37



73

eXtreme Programming





Kanban


eXtreme Programming (XP)

74

Centrada en potenciar las relaciones interpersonales . Se basa en la

realimentación continua entre el cliente y el equipo de desarrollo , la comunicación

fluida entre todos los participantes, la simplicidad en las soluciones implementadas y el coraje para

enfrentarse a los cambios

06/10/2011

38


CARACTERÍSTICAS DE eXtreme Programming (XP)

75

El juego de la planificación : hay una comunicaciónfrecuente entre el cliente y los programadores. Los técnicosestiman el esfuerzo requerido para la implementación,mientras que los clientes deciden sobre el tiempo de cadaiteración.

Entregas pequeñas : una entrega no debería tardar más detres meses, tiempo en el que debe desarrollarse una versióndel sistema que sea operativa aunque no cuente con toda lafuncionalidad del sistema.

Metáfora : es una historia que describe el funcionamiento delsistema. El sistema es definido por una metáfora o unconjunto de ellas compartidas por el cliente y el equipo dedesarrollo.



76

Diseño simple : se debe diseñar la solución más simple quepueda funcionar.

Pruebas : la producción del código está dirigida por pruebasunitarias.

Refactorización : la reestructuración del código es necesariapara la mejora de la calidad del mismo. Se mejora la estructurainterna del código sin alterar su comportamiento externo.

Programación por pares: la producción se hace en parejas, loque conlleva evitar errores, mejorar el diseño, etc.

Propiedad colectiva del código: cualquier programador puedecambiar cualquier parte del código en cualquier momento.

06/10/2011

39



77

Integración continua :Integración continua: cada parte del código es integrada enel sistema una vez que está lista.

40 horas por semana: de debe trabajar un máximo de 40horas semanales, y no realizar horas extra durante dossemanas seguidas. Si esto ocurre, algo está realizándosemal.

Cliente in-situ: el cliente debe estar presente y disponibletodo el tiempo para el equipo, conduciendo el trabajo hacia loque aportará mayor valor de negocio.

Estándares de programación: la comunicación entreprogramadores se realiza a través del código, por lo que esimportante que se sigan unas reglas para mantener el códigolegible.



78

eXtreme Programming





Kanban

06/10/2011

40


DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)

79

Primera metodología ágil (1994) y la mas próxima

a los métodos tradicionales. Metodología iterativa e

incremental en el que equipo de desarrollo y

usuario trabajan juntos. Propone cinco fases :

estudio de viabilidad, estudio del negocio, modelado

funcional, diseño y construcción y por último

implementación. Las tres últimas fases son

iterativas, y existe realimentación entre cada fase.



80

eXtreme Programming





Kanban

06/10/2011

41


ADAPTIVE SOFTWARE DEVELOPMENT (ASD)

81

Metodología iterativa, orientada a los

componentes software más que a las tareas y

tolerante a los cambios . Su ciclo de vida consta de

tres fases : especulación , en la que se inicia el

proyecto y se planifican las características del

software; colaboración , en la que se desarrollan las

características; y aprendizaje , en la que se revisa su

calidad y se entrega al cliente.



82

eXtreme Programming





Kanban

06/10/2011

42


FEATURE-DRIVEN DEVELOPMENT (FDD)

83

Metodología iterativa que consta de 5 pasos .

Las iteraciones son cortas , centrándose en

las fases de diseño e implementación del

sistema partiendo de una lista de

características que debe reunir el software



84

eXtreme Programming





Kanban

06/10/2011

43


LEAN DEVELOPMENT (LD)

85

Los cambios se consideran riesgos , pero si

se manejan adecuadamente se convierten en

oportunidades que mejoren la

productividad del cliente . Es necesario

introducir un mecanismo que permita

implementar dichos cambios



86

eXtreme Programming





Kanban

06/10/2011

44


KANBAN

87

Metodología que ayuda a controlar de modo

armónico la fabricación de productos en la

cantidad y tiempo necesarios en cada uno de

los procesos


KANBAN

88

•Divide el trabajo en bloques , se escribe cada elemento en unatarjeta/post-it y se coloca en una superficie visible (pizarra,pared, etc.)

•Utiliza columnas con nombre para indicar en que lugar delflujo de trabajo se encuentra cada elemento .

•Limita el Work in Progress (trabajo en curso). Asigna límitesconcretos a los elementos que están en progreso en cadaestado del flujo de trabajo.

•Mide el lead time (tiempo de ciclo). Optimiza el proceso paraque el tiempo de ciclo sea lo más pequeño y predecible posible.

06/10/2011

45


KANBAN

89

PENDIENTE DESARROLLO PRUEBA ENTREGA FINALIZADO

FLUJO

A

B

C

DE

F

G

H

I

J

K

L

3 3 2 1 3


90

ÍNDICE



3 SCRUM

4

1

PRÁCTICAS ÁGILES



06/10/2011

46


Number of people involved

Crit

ical

ity

(def

ects

cau

se lo

ss o

f...)

Comfort(C)

Essentialmoney

(E)

Life(L)

+20%

Prioritized for Legal Liability

1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000

C6 C20 C40 C100 C200 C500 C1000

D6 D20 D40 D100 D200 D500 D1000

E6 E20 E40 E100 E200 E500 E1000

L6 L20 L40 L100 L200 L500 L1000

Prioritized for Productivity & Tolerance

Different methodologies are possible & needed (project size, system criticality, priorities, fears)

Discretionarymoney

(D)

Alistair Cockburn


¿Y QUE OCURRE CON LA DOCUMENTACIÓN?

92

06/10/2011

47


DOCUMENTAR, DE MANERA ÁGIL, PERO DOCUMENTAR

93

encuentran útil, pero… ¿No era el objetivo principal

[…] Frecuentemente escucho a los desarrolladores

decir que no les gusta documentar , que no lo

encuentran útil, pero… ¿No era el objetivo principal

de documentar el ayudar a otros? ¿Cómo es

posible una visión tan distorsionada de la

documentación?

“Agile Documentation, Anyone?” por Bran Selic IEEE Software de noviembre (Diciembre, 2010)


DOCUMENTAR, DE MANERA ÁGIL, PERO DOCUMENTAR

94

[…] El propósito de la documentación es enseñar a quienes no

están familiarizados con un sistema cómo este se estructura,

funciona y los motivos que llevaron a decidirse por ese diseño.

Los principales usuarios de la documentación de dis eño

son los futuros responsables del mantenimiento del

sistema . La única alternativa a no tener documentación de

diseño es explorar directamente el sistema , buscar un camino

a través de una selva sin mapa ni brújula. Así, mientras que

documentar tiene un coste, la inversión, si se hace

correctamente, vale la pena […]

“Agile Documentation, Anyone?” por Bran Selic IEEE Software de noviembre (Diciembre, 2010)

06/10/2011

48



06/10/2011

49



98

Cuando preparo una batalla,

encuentro que los planes son

inútiles, pero la planificación es

indispensable”

“

Dwight Eisenhower

En la batalla…

06/10/2011

50


¿QUÉ hacer? MODELO DE PROCESOS

¿CÓMO hacerlo? METODOLOGÍAS

CMMI-DEV

ISO 12207

CMMI-ACQ

CMMI-SVC


Tema II – Métodos ÁgilesPS... · METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS...

Documents

Transcript of Tema II – Métodos ÁgilesPS... · METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS...