Procesos Ágiles de Desarrollo de Software

(1)

Universidad Técnica Federico Santa María

Departamento de Informática

Departamento de Informática Versión 2006

PROGRAMA: “Magister en

Tecnologías de la Información”

(modo ejecutivo)

Universidad Técnica Federico Santa María

Procesos Ágiles de Desarrollo de

Software

(2)

Métodos Ágiles [1]

!

"

#

$

%

& '

(

'

&

#

$

Métodos Ágiles [2]

)

*

&

# &

+

*

$

#

,

-

*

)

!

$

(3)

Principios Ágiles [1]

1- - -

$

%

% -

-

%

& %

&

#

2 -

"

&

$

3 $

-

4 $

&

) &

5 "

%

$

5 $

-

- $

-

-6

$ $

&

$

5 -

%

-

- $ 7

6 $ 7

&

3 8& -

-&

$$

- %

-- 7#

Principios Ágiles [2]

1-

&

-

& %

-

&

$

9 9

&

2 5

- $

%

$

#

&

$

3 1-$

&

$

-

#

$

%

-

(

-

%

$

%: -

(

'

-

5 :

1- #

-

"

9 '

&

-

#

&

-

7 # - &

%

(4)

Principales Métodos

Ágiles

,(

0 ;0

%

.

%

.

9) &

)

$ &

) &

$

) )

/

/$

+<0

Agilidad vs. Proceso

=

# 7 -

&

*

$

%

#

&

>

%;0$

$

* & 3

'

7

(5)

Dudas y Desafíos Ágiles

?

;0$

7 $

$

@

?A

*

@

?

@?

$

@

)

$

"

#

)

$

*

$

%-

$

*

$

*

$

* %

$ *

*

+

*

$

7

0 $

+

* + $

#

1 # 7

$

Extreme Programming

(XP) [1]

(6)

, $

(

.

$

"

3 ,

;0

&

#

-3

$ % ;0 # # $ $ & # %$ " ! 3

Extreme Programming

(XP) [2]

, $

(

.

,($

*

.

0 *

.

%,

.

0 *

.

Extreme Programming

(XP) [3]

(7)

Extreme Programming

(XP) [4]

0

0 * ,(

!

"

Extreme Programming

(XP) [5]

(8)

Extreme Programming

(XP) [6]

0 / 9

2-0

>

# $

>BC9-

5

1

9 &

&

$

0 $

&

-$

$-+

Universidad Técnica Federico Santa María

Propuesta de Herramientas para

Implantación de XP

(9)

Identificación Prácticas

Ágiles [1]

,

#

*

$

;0 "

$

" $

*

$

'

$

;03

0 *

, 7

$

*

#

0 " !

D#

$

)

!

)

!

$

%

0 #

'

&

Identificación Prácticas

Ágiles [2]

(10)

)

0 * $ 0

$

0 $

&

*

'

(

,

*

'

Identificación Prácticas

Ágiles [3]

)

*

'

)

$ ) $

#

( *

'

Identificación Prácticas

Ágiles [4]

(11)

Herramientas Propuestas

[1]

$

-$

$

*

$ 7 & $ % 3 8 >1 $ 0 $ ' * - 3 8 >1 $ , * - 3 8 >1 $ $ * - 3 8 >1 $ 0 $ * 3 8 0 8 0 ( 3 8 * ;03 8 - 5 $ $ * - 5 $ # * 3 1 $ 0 # * 8 >1 $ $ * $ * 8 >1 $ & 0 * $ D# 8 >1 $ + $ 1 $ 0 8 >1 $

Herramientas Propuestas

[2]

(12)

Departamento de Informática Versión 2006 * 8 >1 $ $-- 5 $ * $ # 3 - 5 ) $ * $ # 8 >1 $ ) $ * $ # $ * 8 >1 $ 0 # $ * ( 8 1 & $ * 7 + 8 >1 $ 8 $ ! $ 8 $ )

Herramientas Propuestas

[3]

8 $ $ $ & * & 8 $ $ * 8 + , # $ * 8 >1 $ 8 $ $ * $ $ 8 0 0 0 * 0

Herramientas Propuestas

[4]

(13)

Departamento de Informática Versión 2006 - 5 $ * - 5 / 9 9 & " # 8 8 $ $ $ # 8 # 0 0 #

Herramientas Propuestas

[5]

Universidad Técnica Federico Santa María

Implantación de Herramientas –

Estudio de un Caso

(14)

Descripción del Caso

6 )& *

"

%

E

*

$

0 %

/#7 &

,

<

% &

-'

#

&

7 %

&

7 $ #

&

$

*

(

' *

Descripción del Trabajo

Realizado

&

0 &

0 $

*

) * , * , *

(15)

Selección de las

Herramientas [1]

, # 1 0 * ) - 5 0 $ * 8 $ 0 * $ 0 0 D# * 0 * $ 0 0 D# * 0 " ! D# * 8 $ & # * 8 $ $ * + + 0 # 1 0 * ,( 1

Selección de las

Herramientas [2]

(16)

Implantación de

Herramientas [1]

&

0 *

1

0 *

)DD

2 5

$

0 %

D#

*

0 #

*

)

$

$ &

$ # *

#

*

0 $ #

*

"

#

0 %

D#

*

0 #

&

F &

#

*

$

-#

%

$

#

* %

&

$

1 D#

*

-

#

3 '

Implantación de

Herramientas [2]

(17)

Análisis Caso de Estudio

[1]

Primera Liberación 0 1 2 3 4 5 6 7 8 T1 ST1 ST2 Tareas de Programación D ia s Tiempo Real Tiempo Planificado Segunda Liberación 0 1 2 3 4 T4 Tareas de Programación D ía s Tiempo Real Tiempo Planificado

Análisis Caso de Estudio

[2]

(18)

Departamento de Informática Versión 2006 Tercera Liberación 0 1 2 3 4 5 6 T6 Tareas de Programación D ía s Tiempo Real Tiempo Planificado

Análisis Caso de Estudio

[3]

+

, $ %

7

7 &

"

#

$

6 D

-

$

* %

%

#

*

$

Análisis Caso de Estudio

[4]

(19)

Adopción de XP [1]

+

," $

(

%

$

0 * $ 0

$

*

$ %

$

*

$ $ $

F

$

#

6

$ ) $ # , *

$

*

-$ *

$ # # " 0 &

-$

$

I3

K

0 *

0 " !

D#

L3

0 * $ 0

$ * $ % 7 $ 7 * J3

+

7 $ $ # B3

1

0 $ $ $ ( + & * * 0 #

Adopción de XP [2]

(20)

Universidad Técnica Federico Santa María

SCRUM

SCRUM – ¿Por qué?

+ ',-( $

8 $

-

IMMB

JI3IN

$ %

$

OL3PN

$ %

(

$

IQMN

! " #

$

) IR3LN

$ %

(

(21)

SCRUM – Historia

D

$

!

5 7

'

%

5 (

)

S

1- F

F

0 ) &

$

8 S

* #+

, *

QRIIRIJP9IBR

#

&

.

'

/(

< &

%0

IMMO $

$

#%

$

& &

$

7 $

' * %

*

$

&

#

(

$ %

#

*

3 SCRUM – Historia

)

$

-.#*

#,

)/

$

/#7

8 $ / 8

$

%

&

+<

0 1 )

# 2

1 ) 3

%

4 +

#

3

(22)

SCRUM – Cómo se

diferencia

D

#

$

"

$

*

# 7

%$

'

>

#

"

'

$

6

1

0 $

$

*

% $

3 SCRUM – Cómo se

diferencia

SCRUM asume que los baselines cambiarán

significativamente durante el proyecto

En ambientes impredecibles, se debe usar métodos empíricos para

monitorear el progreso y el cambio

, en vez de métodos definitivos

que intentan

predecir el progreso y detener el cambio

.

(23)

SCRUM – Principios

básicos

+<

$

#

(

5 !

, " $

$ %

&

9 *

9 &

R P$

3 , " $ $

-

"

&

$

$ $

# 3

-

6 *

!

D

#

$ %

#

# &

&

%

#

*

# 7

*

! & #

3

!

SCRUM – Estructura del

proyecto

(24)

SCRUM – Controles de

gestión

Los proyectos SCRUM no están fuera de control y, de

hecho, tienen muchos elementos de control y gestión:

Encuentros Diarios

. reunión diaria de todos los miembros del

equipo para un Sprint

o generalmente breve (unos 15 minutos)

o el propósito es actualizar al project manager y miembros del equipo sobre progreso alcanzado y plantear inquietudes que el project manager u otro miembro pueda resolver

o tres preguntas a contestar por cada participante: – ¿Qué hice en las últimas 24 horas?

– ¿Qué tengo planeado hacer en las siguientes 24 horas? – ¿Qué obstáculos detecto en mi camino??

SCRUM – Controles de

gestión

Demostración Visible de Progreso

. Al finalizar el Sprint, el cliente

y todos los miembros del equipo de proyecto ven una demostración

visual del progreso a la fecha.

o se obtiene feedback del cliente en etapas tempranas del desarrollo, reduciendo en consecuencia los costos

o el progreso del proyecto global es muy visible y fácil de monitorear por medio de function/feature checklists, puntos de función u otros medios

(25)

SCRUM – Controles de

gestión

Sprint Burndown Charts

. En las reuniones diarias, el equipo hace

estimación actualizada de horas/días para completar el trabajo

o el project manager usa este dato para construir un Sprint Burndown Chart mostrando el progreso en un Sprint

o las horas totales proyectadas para un Sprint usualmente se incrementa en sus primeros días por que aparecen dificultades y trabajo adicional, pero rápidamente declinan cuando el trabajo empieza

SCRUM – Controles de

gestión

Accelerated Customer Approval

. Debido a que los clientes

revisan los entregables visibles al final de cada Sprint y brindan un

feedback en ese momento, junto con el hecho de que el Sprint

siguiente se basa en el trabajo de los Sprints anteriores, la salida

final no debería contener ninguna sorpresa para el cliente ya que

contendrá el grueso de este feedback. Esto implica una más rápida

aceptación/aprobación de los entregables por parte del cliente.

(26)

SCRUM – Alineamiento

con metodología

Como SCRUM no es realmente una metodología de

desarrollo de software, sino de gestión de proyectos de

desarrollo, no determina prácticas de desarrollo de software

por tanto, la mayoría de los métodos de desarrollo de

software pueden ser gestionados usando SCRUM sin

mayores conflictos.

SCRUM – Cuándo no

usarlo

SCRUM no es apropiado para todas las situaciones,

especialmente:

grandes equipos

estructuras organizacionales complejas de equipos

equipos distribuidos geográficamente

(27)

Referencias

-

- $>>

3

3 >

/

0

1 - $>>

3($

3 >

+<

- $>>

3 -

3 >