Procesos Ágiles de Desarrollo de Software

Transcripción

1 Universidad Técnica Federico Santa María Departamento de Informática PROGRAMA: Magister en Tecnologías de la Información (modo ejecutivo) Universidad Técnica Federico Santa María Departamento de Informática Procesos Ágiles de Desarrollo de Software 1

2 Métodos Ágiles [1]! " # $ %&'( ' & #$ $ Métodos Ágiles [2] ) * &#& +* $ #,-* )!$ *. $ / '* # 0$# $& 2

3 Principios Ágiles [1] 1- --$% %- --% &%&# 2 - " & &$ 3 $ $&& )& 5 " % $ 5 $ --$ $$ &$ 5- % --- $7 6$7 & &38& - - & $$-% - - 7# Principios Ágiles [2] 1- & - &% - &$ 99 & 25 - $% $ $ $ # &$ 31- $ &$ -## $ % - ( - % $%: -(' - 5 : 1- #-" 9 ' &- - # &- 7 #-& % 3

4 Principales Métodos Ágiles,(0 ;0 %.%.9)& ) $& )&$ )) / /$ +<0 Agilidad vs. Proceso = #7- & * $% #& >%;0$ $ $ * &3 ' 7 $#7 $* " $7$ $ * $% * $ 4

5 Dudas y Desafíos Ágiles? $@ ) $ "# # ) $ $* $ %- $* $* $ * %$* Extreme Programming (XP) [1] * + * $ 7 0 $ + * +$ # 1#7 $ 5

6 Extreme Programming (XP) [2],$ (. $" 3,;0& # - 3 $%;0# # $ $ &#%$"!3 Extreme Programming (XP) [3],$ (.,($*.0 *. %,.0*.. 6

7 Extreme Programming (XP) [4] Extreme Programming (XP) [5] 00*,(!! " 7

8 Extreme Programming (XP) [6] 0 / > # $>BC9-5 19& &$ $ 0 $ & -$ $- + Universidad Técnica Federico Santa María Departamento de Informática Propuesta de Herramientas para Implantación de XP 8

9 Identificación Prácticas Ágiles [1],# * $ $ ;0"$ "$ * $ ' $ ;03 0 *,7$ * # 0"!D# $ Identificación Prácticas Ágiles [2] )! )!$% 0# 0#'& 9

10 Identificación Prácticas Ágiles [3] ) 0* $0 $ 0$&* ' '(, * ' Identificación Prácticas Ágiles [4] ) * ' ) $)$ #(* ' 10

11 Herramientas Propuestas [1] $ - $$ * 0 8 * ;038 0 (38 0$ * 38 $ * - 3 8>1$,* -38>1$ 0 $'* - 3 8>1$ $7&$%3 8>1$ Herramientas Propuestas [2] 0 8>1$ $ 1$ + & 0 * $ D# 8>1$ $ * $* 8>1$ 0 #* 8>1$ $ #* 31$ -5$$* -5 11

12 Herramientas Propuestas [3] $) $- 1 8$!$8 & $ * 7 + 8>1$ * 8>1$ 0# $* (8 ) $ * $# $* 8>1$ ) $ * $# 8>1$ -5$* $#3-5 Herramientas Propuestas [4] 0 0 0* 0 + 8$$* $$8,# $* 8>1$ 8$$ * 8 & / -$ 8$$$&* 8 8$$ * 8 ) * * 8>1$ 8$&# * 8 12

13 Herramientas Propuestas [5] # 0 0 # / 9 9 8$$ $ #8 &"# 8-5$* -5 Universidad Técnica Federico Santa María Departamento de Informática Implantación de Herramientas Estudio de un Caso 13

14 Descripción del Caso 6 )&* "% E * $ 0% /#7&, <%&- ' #& & 7%& 7 $#& $ $* ( '* Descripción del Trabajo Realizado &0& 0$* *, * ) *, * 0"!D# &0 * D# $ * 10* 14

15 Selección de las Herramientas [1] 0"!D# 0 D#* 0 D#* -50$* 0* $0 8$0* $0,# 10* ) Selección de las Herramientas [2] 1 + * 0#1 0*,( 8$$ * + 8$&# * 15

16 Implantación de Herramientas [1] &0 * 10* )DD 25 $ $ 0 % D#* 0#* ) $ $ $&$#* #* 0$#* " # # Implantación de Herramientas [2] 0 % D#* 0 # & F& #* $- #%$ #* % & $ 1D#* -#3 ' 1)) :0* $0 :+ :1 16

17 Análisis Caso de Estudio [1] Primera Liberación Dias T1 ST1 ST2 Tareas de Programación Tiempo Real Tiempo Planificado Análisis Caso de Estudio [2] Segunda Liberación 4 Días T4 Tareas de Programación Tiempo Real Tiempo Planificado 17

18 Análisis Caso de Estudio [3] Tercera Liberación Días T6 Tareas de Programación Tiempo Real Tiempo Planificado Análisis Caso de Estudio [4] +,$%7 7 &"# $ 6 D- $ * % % # #* $ $ - G,# 1 ) H $$ $* $$ $ * & 'IIJI 18

19 Adopción de XP [1] +,"$( % $ 0* $0 $ * $% $ * $$$ F$ $#6 $)$ #, * $ * - $* $# #" 0 & - Adopción de XP [2] $$ I3 K0 * 0"!D# L3 0* $0 $ * $% 7 $ 7 * J3 + 7 $ $# B3 1 0$ $$ ( +&* * 0# 19

20 Universidad Técnica Federico Santa María Departamento de Informática SCRUM SCRUM Por qué? +',-($8$ - IMMB JI3IN$% $ OL3PN $%( $$ $IQMN!" #$ )IR3LN$%( $% $$ $ * "#% &! 20

21 SCRUM Historia D$! 57'%5() S1- F F 0)&$ 8S*#+,* QRIIRIJP9IBR # &.'' /(< &%0IMMO$ $#% $&&$ $ 7 $ '* %* $&# ( $% # *3 SCRUM Historia )$ -.#*#,)/$ $ /#7 8$/8 $% &+< 0 1)#21) 3%4+#3 21

22 SCRUM Cómo se diferencia D # $" $* *#7 %$ ' > #" ' $ $$* %$ 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. SCRUM espera el cambio el resultado final será un producto más cercano a las necesidades del usuario en el final del desarrollo. SCRUM tiene también estructura y mecanismos de control. 22

23 SCRUM Principios básicos +< $ $# (5!,"$$%& 9 * 9 & RP$ 3,"$$ - " & $$$ #3-6*! D #$% ##& & % #* #7 *!&#3 SCRUM Estructura del proyecto! 23

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

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

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 aplicaciones críticas 26

27 Referencias ---$>>3 3> / 01 -$>>3($ 3> +<-$>>3-3> 27