UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN

141  Descargar (0)

Texto completo

(1)

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN

Estudio de las fortalezas y debilidades que exhiben los métodos ágiles en el contexto chileno de desarrollo de software: 5 casos

RODRIGO ANDRÉS FAÚNDEZ MARIPANGUE

Profesor Guía: Dr. Narciso Cerpa Torres

Memoria para optar al título de Ingeniero Civil en Computación Curicó – Chile

Agosto, 2010

(2)

UNIVERSIDAD DE TALCA FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA CIVIL EN COMPUTACIÓN

Estudio de las fortalezas y debilidades que exhiben los métodos ágiles en el contexto chileno de desarrollo de software: 5 casos

RODRIGO ANDRÉS FAÚNDEZ MARIPANGUE

Profesor Guía: Dr. Narciso Cerpa Torres Profesor Informante 1: Dr. Matthew Bardeen Profesor Informante 2: Pablo Rojas Valdés

Memoria para optar al título de Ingeniero Civil en Computación Curicó – Chile

Agosto, 2010

(3)

I

DEDICATORIA

Dedicado a mis queridos padres y hermano.

(4)

II

AGRADECIMIENTOS

Agradezco a todos quienes de una u otra forma hicieron posible mi travesía universitaria y la realización del presente trabajo, en particular:

 A mis viejos y queridos amigos de siempre, los cuales me han acompañado durante prácticamente toda mi vida. Aquellos con los que fui al colegio, viví en Curicó o compartí una banca y una conversación en la plaza de mi pueblo. Estimados, son los mejores. Los recuerdos que creamos juntos siempre van conmigo y me ayudan en los momentos difíciles.

 A mis nuevos amigos de la universidad, que me brindaron su apoyo y sincera amistad. Gracias a ustedes pude superar muchos de los obstáculos que la vida universitaria me colocó por delante. Espero que sigamos siendo amigos y que la vida les sonría siempre.

 A los profesores que me guiaron durante mi estadía como alumno de esta universidad y me entregaron las herramientas para realizar este trabajo.

 A las empresas que amablemente me recibieron para mostrarme su experiencia en el uso de métodos ágiles. Sin su ayuda mi trabajo no hubiera sido posible. Una vez más gracias.

Finalmente quiero agradecer de forma especial a mis padres, los cuales siempre me entregaron su amor y apoyo incondicional, para ellos siempre me serán escasas las palabras y gestos de gratitud. También le agradezco a mi hermano la paciencia que me tiene.

A todos muchas gracias.

(5)

III

TABLA DE CONTENIDOS

Página Dedicatoria ... I

Agradecimientos ... II Tabla de contenidos ... III Índice de tablas ... VIII Índice de ilustraciones ... X Resumen ... XI

1. Introducción ... 1

1.1. Descripción del contexto ... 1

1.2. Descripción del problema ... 2

1.3. Objetivos ... 3

1.3.1. Objetivo general ... 3

1.3.2. Objetivos específicos ... 3

1.4. Alcances del proyecto ... 4

1.5. Resumen ... 5

2. Marco Teórico ... 6

2.1. Métodos de desarrollo de software ... 6

2.1.1. Actividades comunes de los métodos de desarrollo de software ... 7

2.2. Métodos tradicionales ... 7

2.2.1. Modelos generales ... 8

2.3. Métodos ágiles ... 9

(6)

IV

2.3.1. Valores de los métodos ágiles ... 10

2.3.2. Principios de los métodos ágiles ... 11

2.3.3. Desarrollo ágil ... 13

2.3.4. Técnicas empleadas por los métodos ágiles ... 14

2.3.5. Tamaño de los equipos ... 14

2.3.6. Gestión de personal ... 15

2.3.7. Aplicabilidad de los métodos ágiles a través de distintos dominios de aplicación ... 15

2.3.8. Agilidad de los métodos ágiles ... 16

2.3.9. Resumen de métodos ágiles ... 17

2.4. Enfoque balanceado ... 18

2.4.1. Visiones ... 19

2.4.2. Idea del Balance ... 19

2.4.3. Diferencias entre métodos tradicionales y métodos ágiles ... 19

2.4.4. Observaciones sobre el balance entre agilidad y disciplina ... 21

2.5. Fortalezas y debilidades de métodos ágiles ... 22

2.5.1. Fortalezas y debilidades genéricas de los métodos ágiles respecto a la organización ... 24

2.5.2. Fortalezas y debilidades genéricas de los métodos ágiles respecto a las personas ... 26

2.5.3. Fortalezas y debilidades genéricas de los métodos ágiles respecto al proceso ... 29

2.5.4. Fortalezas y debilidades genéricas de los métodos ágiles respecto a la

técnica ... 31

(7)

V

2.5.5. Fortalezas y debilidades genéricas de los métodos ágiles respecto al

proyecto ... 33

2.5.6. Fortalezas y debilidades particulares de Extreme Programming (XP) ... 34

2.5.7. Fortalezas y debilidades particulares de Feature Driven Development (FDD) ... 36

2.5.8. Fortalezas y debilidades particulares de Scrum ... 38

2.5.9. Fortalezas y debilidades particulares de Adaptive Software Development (ASD) ... 40

2.5.10. Fortalezas y debilidades particulares de Crystal Methods ... 41

2.5.11. Fortalezas y debilidades particulares de Dynamic Systems Development Method (DSDM) ... 42

2.5.12. Fortalezas y debilidades particulares de Lean Development (LD) y Lean Software Development (LSD) ... 43

2.6. Resumen ... 44

3. Metodología de Investigación ... 45

3.1. Fases de la investigación ... 45

3.1.1. Fase de preparación del estudio de casos ... 47

3.1.2. Fase de aplicación del estudio de casos ... 48

3.1.3. Fase de análisis ... 49

3.1.4. Fase de muestra de resultados ... 50

3.2. Resumen ... 50

4. Diseño de la investigación ... 52

4.1. Identificación del problema a investigar ... 52

4.1.1. El problema a investigar... 52

4.1.2. ¿A quienes vamos a investigar? ... 53

(8)

VI

4.2. Interrogantes a resolver con el estudio ... 55

4.2.1. Análisis de la literatura previo a la generación de preguntas para el estudio de casos ... 56

4.2.2. Preguntas del estudio... 59

4.2.3. Herramientas utilizadas durante el proceso de generación de preguntas para el estudio ... 61

4.3. Recolección y manejo de datos ... 62

4.3.1. Recolección y almacenamiento de los datos del estudio ... 62

4.3.2. Disposición de los datos recolectados ... 63

4.3.3. Resumen ... 64

5. Resultados y análisis de resultados ... 65

5.1. Respuestas a las preguntas planteadas en el estudio de casos ... 65

5.1.1. Pregunta Nº1 y sus preguntas secundarias ... 65

5.1.2. Pregunta Nº2 y sus preguntas secundarias ... 71

5.1.3. Pregunta Nº3 y sus preguntas secundarias ... 74

5.1.4. Pregunta Nº4 y sus preguntas secundarias ... 78

5.1.5. Pregunta Nº5 y sus preguntas secundarias ... 80

5.2. Fortalezas y debilidades de los métodos ágiles observadas en la realidad y su relación con la literatura ... 83

5.2.1. Pregunta nº1 y sus preguntas secundarias. Fortalezas y debilidades ... 83

5.2.2. Pregunta nº2 y sus preguntas secundarias. Fortalezas y debilidades ... 85

5.2.3. Pregunta nº3 y sus preguntas secundarias. Fortalezas y debilidades ... 86

5.2.4. Pregunta nº4 y sus preguntas secundarias. Fortalezas y debilidades ... 88

5.2.5. Pregunta nº5 y sus preguntas secundarias. Fortalezas y debilidades ... 89

(9)

VII

5.3. Resumen ... 90

6. Conclusiones ... 91

6.1. Del estudio teórico ... 91

6.2. De la metodología propuesta ... 92

6.3. Del diseño del estudio de casos ... 94

6.4. De las preguntas del estudio ... 94

6.5. De los objetivos trazados ... 101

6.6. Del aprendizaje personal ... 102

6.7. De las contribuciones ... 103

6.8. Del trabajo futuro ... 103

Bibliografía ... 105

7. Anexos ... 115

A. Metodología de investigación ... 116

B. Preguntas para el estudio de casos ... 127

(10)

VIII

ÍNDICE DE TABLAS

Página

Tabla 2.1 - Métodos Ágiles ... 17

Tabla 2.2 - Diferencias entre métodos tradicionales y ágiles ... 20

Tabla 2.3 - Clasificación por dimensiones ... 23

Tabla 2.4 - Fortalezas genéricas de los métodos ágiles respecto a la organización ... 24

Tabla 2.5 - Debilidades genéricas de los métodos ágiles respecto a la organización ... 24

Tabla 2.6 - Fortalezas y debilidades genéricas de los métodos ágiles respecto a las personas ... 26

Tabla 2.7 - Fortalezas genéricas de los métodos ágiles respecto a las personas ... 27

Tabla 2.8 - Debilidades genéricas de los métodos ágiles respecto a las personas ... 28

Tabla 2.9 - Fortalezas y debilidades genéricas de los métodos ágiles respecto al proces .... ... 29

Tabla 2.10 - Fortalezas genéricas de los métodos ágiles respecto al proceso ... 30

Tabla 2.11 - Debilidades genéricas de los métodos ágiles respecto al proceso ... 31

Tabla 2.12 - Fortalezas y debilidades genéricas de los métodos ágiles respecto a la técnica ... 31

Tabla 2.13 - Fortalezas genéricas de los métodos ágiles respecto a la técnica ... 32

Tabla 2.14 - Fortalezas genéricas de los métodos ágiles respecto al proyecto ... 33

Tabla 2.15 - Debilidades genéricas de los métodos ágiles respecto al proyecto ... 34

Tabla 2.16 - Fortalezas y debilidades particulares de Extreme Programming ... 34

Tabla 2.17 - Fortalezas particulares de Extreme Programming ... 35

Tabla 2.18 - Debilidades particulares de Extreme Programming ... 36

Tabla 2.19 - Fortalezas y debilidades particulares de Feature Driven Development... 36

Tabla 2.20 - Fortalezas particulares de Feature Driven Development ... 37

Tabla 2.21 - Debilidades particulares de Feature Driven Development ... 38

Tabla 2.22 - Fortalezas particulares de Scrum ... 38

Tabla 2.23 - Debilidades particulares de Scrum ... 39

Tabla 2.24 – Fortalezas particulares de Adaptive Software Development ... 40

(11)

IX

Tabla 2.25 - Debilidades Particulares de Adaptive Software Development ... 40

Tabla 2.26 - Fortalezas particulares de Crystal Methods ... 41

Tabla 2.27 - Debilidades particulares de Crystal Methods ... 41

Tabla 2.28 - Fortalezas particulares de Dynamic Systems Development Methods ... 42

Tabla 2.29 - Debilidades particulares de Dynamic Systems Development Methods ... 42

Tabla 2.30 - Fortalezas particulares de Lean Development y Lean Software Development ... 43

Tabla 4.1 - Clasificación de los documentos recolectados ... 56

Tabla 4.2 - Clasificación por dimensiones ... 58

Tabla 4.3 – Preguntas desprendidas de la revisión bibliográfica ... 60

Tabla 4.4 - Dispositivos empleados en la recolección de datos ... 62

Tabla 5.1 - Actividades principales de las empresas estudiadas ... 65

Tabla 5.2 - Tipos de empresas estudiadas ... 66

Tabla 5.3 - Personas dedicadas a desarrollar software por medio de métodos ágiles en cada caso ... 67

Tabla 5.4 - Métodos ágiles empleados por las empresas estudiadas ... 68

Tabla 5.5 - Capacitación externa en el uso de métodos ágiles ... 71

Tabla 5.6 - Tamaño de los equipos ... 80

Tabla 6.1 - Errores del estudio ... 93

Tabla 7.1 - Preparación del estudio de casos ... 116

Tabla 7.2 - Aplicación del estudio de casos ... 122

Tabla 7.3 - Análisis ... 124

Tabla 7.4 - Muestra de resultados ... 126

(12)

X

ÍNDICE DE ILUSTRACIONES

Página

Ilustración 2.1 - Ciclo de construcción de valor ... 13

Ilustración 2.2 - Niveles de agilidad ... 16

Ilustración 2.3 - Decisiones y agilidad ... 21

Ilustración 3.1 - Metodología de Investigación... 46

Ilustración 3.2 - Metodología de Investigación... 47

Ilustración 3.3 - Metodología de Investigación... 48

Ilustración 3.4 - Metodología de Investigación... 49

Ilustración 4.1 - Proceso de generación de preguntas para el estudio ... 57

Ilustración 4.2 - Clasificación de las características de los Métodos Ágiles ... 58

Ilustración 4.3 - Relación entre preguntas principales y secundarias ... 59

(13)

XI

RESUMEN

Los métodos ágiles son descritos en la literatura como una alternativa al desarrollo tradicional de software. Algunas de sus características más reconocibles son, una gran capacidad de adaptarse a los cambios que surgen durante un proyecto, la importancia que les dan a las personas, tiempos breves de desarrollo, etc.

En la actualidad las propuestas hechas por los métodos ágiles han sido recogidas

por diversas empresas tanto en Chile como en el extranjero. Entonces nuestro trabajo

consistió en realizar una revisión de la literatura de los métodos ágiles, a fin de crear un

estudio que permitiese conocer las experiencias de diversas empresas que desarrollan

software por medio de estos métodos en Chile. En base a estas experiencias recogidas,

se pudo establecer una serie de fortalezas y debilidades que presentan los métodos ágiles

en la realidad. Además se realizaron recomendaciones a fin de disminuir el impacto de

las debilidades que ellos presentan en los proyectos que se utilizan.

(14)

1

1. Introducción

1.1. Descripción del contexto

En la actualidad, vivimos en un mundo donde la tecnología cambia de manera continua, al igual que el entorno en el cual se desenvuelven las empresas. En la industria del software, estos cambios se han notado de manera significativa, pues ahora los proyectos requieren asimilar estas nuevas condiciones durante su desarrollo [1-3].

En la ingeniería de software, existen los métodos tradicionales o basados en un plan, los cuales prometen estabilidad, predictibilidad y alta fiabilidad de sus procesos al momento de desarrollar software. Por otro lado tenemos a los métodos ágiles, quienes nos hacen la promesa de incrementar los niveles de satisfacción de los clientes, tiempos más cortos de desarrollo, bajas tasas de errores y soluciones rápidas a los cambios en los requisitos de un proyecto [4].

Sin embargo, los métodos tradicionales de desarrollo de software, no han sabido hacer frente de manera adecuada al entorno cambiante que envuelve a los proyectos en la actualidad. Debido a estas razones, han surgido con fuerza los métodos ágiles con una respuesta más apta al problema del desarrollo de software (costos, tiempo, requisitos). Si bien es cierto que los métodos ágiles han mostrado una gran cantidad de fortalezas, y han generado un cambio notable en la forma de producir software durante los últimos quince años, aún siguen presentando debilidades ante determinadas situaciones [1].

Los métodos ágiles han encontrado distintos niveles de acogida dentro de la

comunidad de desarrolladores de software. Por un lado, existen personas que abogan por

una búsqueda de equilibrio entre la agilidad y la disciplina, mientras que otros proponen

un total reemplazo de los métodos tradicionales por los métodos ágiles [5].

(15)

CAPÍTULO 1. INTRODUCCIÓN 2

Debido principalmente a las fortalezas que poseen los métodos ágiles por sobre los tradicionales, es que han sido utilizados en distintos lugares del mundo como una forma válida de desarrollar software, incluido Chile.

Por las razones anteriormente expuestas, se hace interesante entonces un estudio acerca de las fortalezas y debilidades que muestran los métodos ágiles en la industria chilena de desarrollo de software.

1.2. Descripción del problema

Actualmente en Chile existe cierto desconocimiento acerca de los métodos ágiles, pese a que han causado un gran impacto durante los últimos años en la industria del software [1]. Debido a estas razones surge el interés por descubrir que está sucediendo en el contexto chileno con su utilización.

Los métodos ágiles de desarrollo de software, poseen una serie de fortalezas y debilidades, las cuales se revelan de distintas formas cuando son empleadas en los proyectos. Dentro de las fortalezas que la literatura ágil menciona, están la gran capacidad de responder ante los cambios en el entorno y en los requisitos de un proyecto, la disminución de los tiempos de desarrollo, el aumento de los niveles de satisfacción del cliente, etc. Por parte de las debilidades se menciona por ejemplo que poseen poca documentación y planificación lo cual en el transcurso del proyecto puede generar errores irrecuperables, también se habla de la dificultad para manejar equipos grandes, etc. [6].

Como se mencionó con anterioridad, la literatura de los métodos ágiles les

atribuye una serie de fortalezas y debilidades, en este punto, se quiere hacer el nexo

entre la teoría y la realidad específica de Chile. Para ello, es necesario saber cuáles son

las fortalezas y debilidades teóricas de los métodos ágiles que se presentan también en

proyectos chilenos, y cuáles no.

(16)

CAPÍTULO 1. INTRODUCCIÓN 3

1.3. Objetivos

1.3.1. Objetivo general

Consiste en realizar un estudio de casos, con el fin de mostrar cuales son las fortalezas y debilidades que se observan durante la utilización de métodos ágiles, en proyectos de desarrollo de software realizados en Chile.

1.3.2. Objetivos específicos

 Realizar una revisión literaria de los métodos ágiles respecto a su teoría y experiencias ocurridas en otros lugares del mundo con su utilización.

 Diseñar un estudio de casos que conteste las preguntas surgidas a partir de la literatura.

 Aplicar el estudio a empresas que hayan utilizado métodos ágiles en Chile.

 Comparar la información obtenida durante la realización del estudio con la literatura, con el fin de determinar que características de los métodos ágiles son una fortaleza o una debilidad en el contexto chileno de desarrollo de software.

 En base a la comparación de la realidad del medio chileno de desarrollo de software con la literatura, entregar un conjunto de propuestas que permitan aprovechar las fortalezas de los métodos ágiles y disminuir el efecto de las debilidades.

Cuando el presente trabajo esté finalizado, contendrá todas las conclusiones y recomendaciones desprendidas de la observación del uso de los métodos ágiles en Chile.

Además esperamos que esta investigación pueda servir como guía para obtener ventajas

de las fortalezas y disminuir el efecto de las debilidades a quienes pretenden emplear o

emplean métodos ágiles en sus organizaciones. Este conocimiento acerca de las

(17)

CAPÍTULO 1. INTRODUCCIÓN 4

debilidades y fortalezas de los métodos ágiles se podría capitalizar por ejemplo, en una reducción de costos en los procesos de adopción y de desarrollo con este tipo de métodos.

1.4. Alcances del proyecto

A continuación se exponen los alcances de la presente memoria:

 El trabajo está centrado en la experiencia de un conjunto de empresas que al momento de las entrevistas estaban desarrollando software por medio de métodos ágiles en Chile.

 El trabajo no excluyó a empresas que no estaban especializadas en el desarrollo de software. Tampoco excluyó a las empresas por tamaño, tiempo de utilización del método ágil, tipo de método ágil empleado, etc.

 Las experiencias fueron recogidas a través de entrevistas a un grupo de personas que trabajan con métodos ágiles en cada empresa.

 El estudio se encuentra acotado a un marco temporal que va desde diciembre de 2009 a abril de 2010, por lo cual los cambios ocurridos en las empresas fuera de ese período no se ven reflejados en este trabajo.

 Las fortalezas y debilidades de los métodos ágiles expuestas en el presente trabajo, representan una porción y no la totalidad de la fortalezas y debilidades que se pueden encontrar tanto en la realidad como en toda la literatura ágil existente.

 Este trabajo no es de carácter estadístico y sus conclusiones tampoco pueden ser

generalizadas pues solo muestran una porción de la realidad y no representan a todas

las empresas que emplean métodos ágiles en Chile.

(18)

CAPÍTULO 1. INTRODUCCIÓN 5

1.5. Resumen

En este capítulo se ha presentado una descripción general del trabajo a desarrollar en esta memoria. En un comienzo se describió el contexto y el problema que da origen a esta investigación, para luego pasar a definir y acotar los objetivos que se esperan conseguir al finalizar este trabajo.

El siguiente capítulo es una revisión literaria donde se describen las bases

teóricas que dan sustento a esta investigación. En él se describirán los distintos enfoques

propuestos para desarrollar software, además de incluir un análisis en detalle de las

fortalezas y debilidades de los métodos ágiles.

(19)

6

2. Marco Teórico

En el presente capítulo se realizará una revisión literaria acerca de los métodos ágiles. En primer lugar y a modo introductorio se describirán los distintos enfoques utilizados para desarrollar software, para luego centrarnos en el estudio de los métodos ágiles con sus respectivas fortalezas y debilidades consignadas por la literatura.

2.1. Métodos de desarrollo de software

Los métodos de desarrollo son una descripción simplificada del proceso que involucra el desarrollo de software [7]. Definen para cada método un conjunto distinto de actividades, acciones, tareas, fundamentos y productos del trabajo, necesarios para desarrollar software [8].

En un principio, el desarrollo de software era demasiado artesanal, y no permitía

planificar y estimar el esfuerzo de forma adecuada, los proyectos eran bastante

ambiciosos y la ausencia de metodologías generaba en más de una ocasión un caos

durante el desarrollo [9, 10]. Con el objetivo de ordenar el caos existente durante el

desarrollo de software, se comenzó a incorporar metodologías de otras áreas de la

ingeniería, en las cuales también existían procesos, lo cual dio origen a los modelos

prescriptivos del proceso o métodos tradicionales [8, 9]. La idea detrás de esta naciente

propuesta era aplicar procedimientos y documentar durante todo el desarrollo, de modo

tal de poder minimizar los riesgos y controlar la evolución de los proyectos [9]. De esta

forma surgieron los métodos tradicionales y con posterioridad los métodos ágiles como

un intento por superar las debilidades presentes en los primeros [8]. Además han surgido

enfoques orientados al balance entre la agilidad que proponen los métodos agiles y la

disciplina que imparten los métodos tradicionales, aprovechando de esta manera lo

mejor que ambas propuestas poseen [4].

(20)

CAPÍTULO 2. MARCO TEÓRICO 7

2.1.1. Actividades comunes de los métodos de desarrollo de software

Como hemos visto recientemente, a través de la historia de la ingeniería de software, han surgido distintas propuestas a la hora de desarrollar software y pese a sus diferencias existen actividades que les son comunes a todas [7]:

 Especificación de software: Se define la funcionalidad del software y las restricciones en su operación.

 Diseño e implementación del software: Se produce el software, de tal modo que cumpla con su especificación.

 Validación del software: Se valida el software para asegurarse que cumpla con lo que el cliente desea.

 Evolución del software: El software debe estar capacitado para facilitar el trabajo de hacerlo evolucionar, de tal manera que pueda cubrir las necesidades cambiantes del cliente.

2.2. Métodos tradicionales

Los métodos tradicionales

1

fueron propuestos en un principio como una forma de ordenar el caos existente en el desarrollo de software. A través de la historia fueron entregando una serie de estructuras útiles para construir software de una forma razonable [8] [11].

Este tipo de métodos están orientados hacia la planificación y buscan mantener la estructura y orden en sus procesos. Por estas razones requieren procesos definidos,

1 En la literatura, los métodos tradicionales también son denominados como métodos prescriptivos, pesados, orientados al plan, convencionales o clásicos.

(21)

CAPÍTULO 2. MARCO TEÓRICO 8

planificación predictiva, definición de tareas e hitos y documentación como producto intermedio entre las distintas etapas que se suceden durante el desarrollo [8] [10].

Los métodos tradicionales son capaces de soportar naturalmente, proyectos grandes en los cuales el software se puede desarrollar en conjunto con el hardware, y las forma de contrato que poseen son de precio fijo [10].

El proceso de desarrollo de los métodos tradicionales comienza con una fase de análisis de las necesidades de los clientes y usuarios. En base a la información que extraen de los clientes y usuarios, producen una extensa documentación que detalla los requisitos del sistema que se va a construir. El documento con los requisitos es usado posteriormente para generar el diseño de un sistema. Luego los programadores serán los encargados de usar el diseño para construir el sistema. Finalmente el sistema se prueba y despacha [7, 8] [11].

Los métodos tradicionales han sido empleados por muchos años y pueden diferir en algunos aspectos, pero en fondo siguen manteniendo un marco de trabajo que busca mantener el orden y estructura en sus procesos [8].

2.2.1. Modelos generales

A continuación se describen los modelos generales más comunes, en los cuales se basan la mayoría de los métodos tradicionales [7]:

 Cascada: Contempla la mayoría de las actividades del proceso de desarrollo tales como, especificación, desarrollo, validación y evolución. Cada una de ellas se representa de forma separada y se desarrollan de forma lineal.

 Desarrollo evolutivo: Contempla las actividades de especificación, desarrollo y

validación. El sistema se desarrolla inicialmente de forma rápida a partir de

especificaciones abstractas, para luego ser refinado en base a las peticiones del

cliente de modo tal de generar un sistema que satisfaga sus necesidades.

(22)

CAPÍTULO 2. MARCO TEÓRICO 9

 Ingeniería de software basada en componentes: Este enfoque se basa en la existencia de una gran cantidad de componentes reutilizables. Por consecuencia, el desarrollo del producto se enfoca en integrar los componentes en el sistema definitivo, en vez de generar un producto desde cero.

Los modelos presentados aquí no son descripciones definitivas del proceso de desarrollo de software, pero pueden ser utilizadas para explicar en parte los distintos enfoques existentes. Si se prefiere pueden ser considerados como marcos de trabajo, los cuales pueden ser ampliados o adaptados con el fin de ajustarse a necesidades más específicas de los procesos de ingeniería de software [7].

2.3. Métodos ágiles

Los métodos ágiles nacen durante la década de los 90, debido al descontento por parte de algunos desarrolladores de software con los métodos tradicionales. Las principales críticas hacia los enfoques basados en la planificación eran [7]:

 La gran cantidad de esfuerzo que implica a proyectos de pequeña y mediana envergadura el uso de métodos tradicionales, llegando a veces a dominar el proceso de desarrollo.

 La gran cantidad de tiempo que se pasaba pensando en desarrollar el software, antes que invertirlo en el desarrollo y las pruebas.

 La poca flexibilidad de los métodos tradicionales al momento de realizar cambios a los requisitos durante el desarrollo.

En base a las críticas hechas a los métodos tradicionales, los desarrolladores de

software comenzaron a proponer enfoques alternativos al tradicional, dando como

resultado el nacimiento de los métodos ágiles. Esta nueva forma de desarrollar software

se basaba en estrategias adaptativas, iterativas, centradas en las personas, orientadas

(23)

CAPÍTULO 2. MARCO TEÓRICO 10

hacia las prestaciones y hacia la entrega de comunicación intensiva, en la cual se requería que el cliente se involucrara de manera directa con el desarrollo [7] [11, 12].

Actualmente existe una gran variedad de métodos ágiles, dentro de los cuales Extreme Programming (XP) es el más conocido por sobre métodos como Scrum, Feature Driven Development (FDD), Crystal Methods (CM), etc. [7].

2.3.1. Valores de los métodos ágiles

En el 2001, Kent Beck junto a otros 16 expertos firmaron el llamado manifiesto

2

ágil, en el cual establecieron valores relacionados a [7-9] [12-14]:

 Individuos e interacciones por sobre los procesos y herramientas: Las personas son el factor más importante para el éxito de un proyecto, por esta razón cobra mayor relevancia formar un buen equipo antes que construir el entorno. En muchas oportunidades se comete el error de crear primero el entorno y esperar a que las personas se adapten a él. Desde el punto de vista de los métodos ágiles se considera que es mejor crear primero el equipo, y esperar que las personas configuren su propio entorno en base a las necesidades que poseen.

 Software que funciona por sobre la documentación exhaustiva: Los documentos no se crean a menos que sean estrictamente necesarios para tomar una decisión. Los documentos deben ser breves y centrarse en lo fundamental.

 Colaboración con el cliente por sobre la negociación de contratos: Se propone que los clientes se involucren fuertemente a lo largo de todo el proceso de desarrollo, por medio de la constante interacción con el equipo de desarrollo. La colaboración entre ambas partes permitirá mejorar de manera significativa las posibilidades de éxito del proyecto.

2 Es posible revisar el manifiesto ágil en http://www.agilemanifesto.org.

(24)

CAPÍTULO 2. MARCO TEÓRICO 11

 Responder ante el cambio por sobre el seguimiento de un plan: La capacidad de responder frente a los cambios que puedan surgir en los requisitos, en la tecnología, en el equipo, entre otros aspectos de un proyecto puede determinar el éxito o el fracaso del mismo. Por lo tanto la planificación deber ser flexible y no estricta de tal modo que pueda dar cabida a los cambios.

2.3.2. Principios de los métodos ágiles

Los valores recientemente descritos, inspiraron doce principios para quienes deseen alcanzar la agilidad. Además resumen las principales diferencias entre los métodos ágiles y tradicionales. Los dos primeros resumen en gran medida el espíritu subyacente en los métodos ágiles, y el resto se centra en el equipo, las metas y la organización del proceso [8] [14].

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione, en un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar

información dentro de un equipo de desarrollo.

(25)

CAPÍTULO 2. MARCO TEÓRICO 12

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

En la práctica sin embargo estos principios son difíciles de llevar a cabo debido a que [7]:

 El cliente debe estar dispuesto a pasar tiempo con el equipo de desarrollo, además es difícil que pueda representar a cabalidad a todos los interesados del sistema.

 Los participantes de los equipos de desarrollo pueden no tener la personalidad adecuada que se requiere para el trabajo con métodos ágiles.

 Es difícil priorizar los cambios, y más aún cuando hay muchos interesados en el sistema, pues cada uno de ellos puede tener distintas prioridades.

 Finalmente mantener la simplicidad tanto en el desarrollo como en el proceso

requiere de un trabajo extra, el cual bajo presión puede ser difícil de llevar a cabo de

buena forma.

(26)

CAPÍTULO 2. MARCO TEÓRICO 13

2.3.3. Desarrollo ágil

Los métodos ágiles comienzan con una arquitectura muy simple del sistema, la cual está orientada hacia los requisitos que se irán implementando en cada iteración.

Durante el transcurso del proyecto, la arquitectura va evolucionando, con el objetivo de mantenerse simple y poder dar cabida a los cambios que surjan durante este tiempo [15].

A medida que transcurre un proyecto ágil, se producen múltiples interacciones de carácter cíclico entre el cliente y los programadores. En este proceso tanto el cliente como los programadores van definiendo las características del sistema y los costos de su implementación [15], tal como se muestra en la siguiente ilustración.

Ilustración 2.1 - Ciclo de construcción de valor. Adaptado de [15]

(27)

CAPÍTULO 2. MARCO TEÓRICO 14

2.3.4. Técnicas empleadas por los métodos ágiles

Los diferentes métodos ágiles promueven el uso de distintas técnicas y cuyo objetivo es minimizar el costo de realizar cambios [9]. A continuación se describen tres de las más utilizadas:

 Refactorización. Es una técnica utilizada para mejorar el código una vez que ha sido escrito y consiste en cambiar su estructura interna sin modificar su comportamiento externo. Esto permite mejorar el diseño del sistema y facilitar el entendimiento del código [14-18].

 Pruebas automáticas exhaustivas. Consiste en probar el sistema y sus partes de manera continua, de modo de ir eliminando los errores en cuanto son detectados [14, 15].

 Integración continúa. Es una práctica utilizada en el desarrollo de software, en donde los miembros del equipo, integran su código de manera frecuente (por lo general cada persona integra al menos una vez al día), dando como resultado una serie de integraciones por día. En cada integración se llevan a cabo a su vez los procesos de compilación y realización de pruebas, de modo de detectar los errores tan pronto como sea posible [14] [19].

2.3.5. Tamaño de los equipos

La mayoría de los métodos ágiles están orientado al trabajo con equipos pequeños

3

[20-25], lo cual facilita la comunicación directa entre las personas y les ayuda a reducir la cantidad de documentación que necesitan para trabajar [26]. A pesar de ello existen otros métodos como Crystal que entregan soporte a una gama más amplia en lo que se refiere al tamaño de los equipos de desarrollo [20] [26-29].

3 Por ejemplo: Extreme Programming (XP) entrega soporte a equipos pequeños de hasta 16 desarrolladores [26].

(28)

CAPÍTULO 2. MARCO TEÓRICO 15

A menudo el nivel de agilidad de un equipo de desarrollo de software está ligado a su tamaño. Esto se debe a que cuando crece el tamaño de un equipo, crece también la necesidad y la importancia de mantener una mayor cantidad de documentación para compartir los conocimientos y seguir el estado de un proyecto. La razón detrás de este aumento en la necesidad e importancia de la documentación, es que la comunicación directa entre los miembros de un equipo grande no es posible [26].

Debido a las razones recientemente expuestas, los equipos más pequeños tienden a ser más ágiles que los equipos grandes, pero a pesar de ello los principios básicos de la gestión de los métodos ágiles siguen siendo válidos y la mayoría de ellos se pueden emplear en equipos de mayor tamaño [26].

2.3.6. Gestión de personal

Los métodos ágiles confían en las personas tanto para resolver los problemas como para compartir la información [7-9] [12-14]. Sin embargo, el hecho de estar orientados hacia las personas puede representar una de sus principales debilidades, pues no son comunes las habilidades necesarias para conformar buenos equipos ágiles [26].

Los desarrolladores de un equipo ágil deben ser personas altamente calificadas [30], y estar altamente motivadas [21]. Además deben ser capaces de trabajar en equipo, comunicarse e interactuar con sus compañeros de trabajo y clientes, etc. Todas estas habilidades son requeridas debido a que el equipo es auto organizado y no puede hacer referencias a un proceso predefinido y detallado para resolver problemas y compartir los conocimientos [26].

2.3.7. Aplicabilidad de los métodos ágiles a través de distintos dominios de aplicación

Una de las preguntas claves acerca de los métodos ágiles es, si se pueden emplear

en todos los dominios de aplicación. Pregunta que por lo demás aún está bajo

investigación [26].

(29)

CAPÍTULO 2. MARCO TEÓRICO 16

En general, parece ser que los métodos ágiles son valiosos para la creación de software no crítico y con un tamaño limitado [26]. Por contrapartida, el uso de métodos ágiles se hace muy difícil o imposible en muchas áreas, como pueden ser, las aplicaciones críticas de seguridad [24] [31], o aplicaciones que son muy grandes o complejas [26].

Actualmente los investigadores están estudiando el uso de métodos ágiles en otras áreas, donde el comportamiento en tiempo real y las limitaciones de memoria son problemas comunes, como podría ser el caso de los teléfonos móviles y PDAs [26].

2.3.8. Agilidad de los métodos ágiles

Dentro del conjunto de métodos ágiles, podemos encontrar distintos niveles de agilidad entre un método u otro. Esta diferencia, está relacionada con aspectos tales como la simplicidad, adaptabilidad, excelencia técnica, prácticas de colaboración, etc. A continuación se ilustra un gráfico, en el cual se plasma esta diferencia, donde los valores más cercanos a 5 representan un nivel alto de agilidad, y los valores más próximos a 1 señalan un menor nivel de agilidad [14].

Ilustración 2.2 - Niveles de agilidad. Adaptado de [14]

ASD CM DSDM FDD LSD Scrum XP

Nivel de agilidad 4,8 4,5 3,6 3,6 3,9 4,7 4,8

0 1 2 3 4 5

Nivel de agilidad

(30)

CAPÍTULO 2. MARCO TEÓRICO 17

En la ilustración 2.2, se observa que los niveles más altos de agilidad son alcanzados por Adaptive Software Development (ASD) y Extreme Programming (XP).

El nivel intermedio, se encuentra ocupado por métodos tales como Scrum, Crystal Methods (CM) y Lean Software Development (LSD). Finalmente los métodos que presentan los niveles más bajos de agilidad dentro de este grupo son Dynamic Systems Development Method (DSDM) y Feature Driven Development (FDD).

2.3.9. Resumen de métodos ágiles Tabla 2.1 - Métodos Ágiles

MÉTODOS DESCRIPCIÓN

Adaptive Software Development (ASD)

Jim Highsmith 2000.

Método de desarrollo de software iterativo y tolerante a los cambios. Orientado hacia los componentes de software más que a las tareas. Su ciclo de vida consta de tres fases esenciales [14]:

 Especulación: Inicio del proyecto y planificación de las características del software.

 Colaboración: Desarrollo de las características.

 Aprendizaje: Revisión de la calidad del software y entrega al cliente.

Crystal

Methods (CM)

Alistair Cockburn 2001.

Conjunto de métodos centrados en las personas y en la reducción al máximo de los artefactos producidos. El desarrollo se considera un juego cooperativo de invención y comunicación limitado por los recursos. El equipo de desarrollo es el factor clave por lo cual se debe invertir en mejorar sus habilidades y destrezas. El tamaño del equipo define el color del método, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros) [14].

Dynamic Systems Development Method (DSDM)

Jennifer Stapleton 1997.

Método iterativo e incremental donde el usuario y el equipo de desarrollo trabajan

juntos. Consta de 5 fases, estudio de viabilidad, estudio del negocio, modelado

funcional, diseño y construcción, y finalmente implementación. Las tres últimas

fases son iterativas y existe una retroalimentación entre todas ellas [14].

(31)

CAPÍTULO 2. MARCO TEÓRICO 18

2.4. Enfoque balanceado

En la presente sección se exponen algunos de los principales conceptos respecto a la propuesta que busca encontrar el equilibrio entre los métodos tradicionales y ágiles, de tal manera de aprovechar lo mejor de ambos.

Extreme Programming (XP)

Kent Beck 1999.

Método de desarrollo de software iterativo que utiliza un enfoque orientado a objetos [8]. Centrado en potenciar las relaciones interpersonales como la clave para el éxito. Se basa en la retroalimentación continua entre el cliente y el equipo de desarrollo, búsqueda de la simplicidad y coraje para enfrentar los cambios [14].

Feature Driven Development (FDD)

Stephen Palmer y John Felsing 2002.

Método de desarrollo de software basado en iteraciones cortas (hasta 2 semanas).

Centrada en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software [14].

Lean

Development (LD) y Lean Software Development (LSD)

Robert Charette, Mary Poppendieck y Tom Poppendieck, durante los años 80.

Método que considera los cambios como riegos, propensos a transformase en oportunidades que mejoren la productividad del cliente si son manejados de forma adecuada. Su principal característica es introducir un mecanismo para implementar dichos cambios [14].

Scrum

Ken Schwaber y Jeff Sutherland 1995; Ken Schwaber y Mike Beedle 2002.

Método de desarrollo de software iterativo. Cada iteración es denominada sprint y posee una duración máxima de 30 días.

El producto de cada sprint es un incremento

ejecutable, el cual se muestra al cliente. Otra característica de importancia son las

reuniones diarias de 15 minutos, llevadas a cabo por el equipo de desarrollo para

coordinarse [14].

(32)

CAPÍTULO 2. MARCO TEÓRICO 19

2.4.1. Visiones

Los métodos tradicionales y ágiles poseen dos visiones distintas acerca de como se debe producir software. Para los métodos tradicionales, la ausencia de planificación y control no permite alcanzar el éxito en los proyectos que se emprenden, por otro lado los métodos ágiles sostienen que la realidad es cambiante y que la rigidez lleva al fracaso en los proyectos [32]. Ambas visiones no han logrado ser la solución definitiva al problema del desarrollo de software, pues en la ingeniería de software ha sido imposible encontrar una solución que sirva para todos los problemas existentes [33].

2.4.2. Idea del Balance

Pese a que la visión de los métodos tradicionales como ágiles, parecen ser opuestas, ambos métodos pueden ser considerados como herramientas para ser utilizados en contextos específicos [10], de esta forma se aprovechan las ventajas de cada uno de ellos, para compensar las debilidades del otro [4]. El reto consiste entonces en balancear ambos enfoques de tal forma de aprovechar lo mejor de cada uno.

2.4.3. Diferencias entre métodos tradicionales y métodos ágiles

Como hemos mencionado, tanto los métodos tradicionales como ágiles poseen distintas visiones acerca de la forma de producir software, lo cual no necesariamente implica que sean opuestas. Sin embargo la diferencia entre tradicional y ágil afecta aspectos relacionados con el proceso, el contexto del equipo y la organización [14].

Algunas de las diferencias más notables entre los métodos tradicionales y ágiles se

exponen en la siguiente tabla.

(33)

CAPÍTULO 2. MARCO TEÓRICO 20

Tabla 2.2 - Diferencias entre métodos tradicionales y ágiles

MÉTODOS TRADICIONALES MÉTODOS ÁGILES

Basados en normas provenientes de estándares seguidos por el entorno de desarrollo.

Basados en heurísticas provenientes de prácticas de producción de código.

Cierta resistencia a los cambios. Especialmente preparados para cambios durante el proyecto.

Proceso mucho más controlado, con numerosas políticas/normas.

Proceso menos controlado, con pocos principios.

Existe un contrato prefijado. No existe contrato tradicional o al menos es bastante flexible.

El cliente interactúa con el equipo de desarrollo mediante reuniones.

El cliente es parte del equipo de desarrollo.

Grupos grandes y posiblemente distribuidos. Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio.

Más artefactos. Pocos artefactos.

Más roles. Pocos roles.

La arquitectura del software es esencial y se expresa mediante modelos.

Menos énfasis en la arquitectura del software.

Fuente: Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP) [14].

La relación entre la agilidad y el grado de planificación, también es una

importante diferencia, no sólo entre ambas visiones, sino que entre todos los métodos de

desarrollo de software. Esta relación genera un espectro en el cual en un extremo

tenemos a los métodos menos ágiles los cuales poseen un mayor grado de planificación

y ceremonia, y en el otro a los más ágiles con una pequeña cantidad de planificación y

ceremonia. Esto implica que un proceso con más planificación es menos ágil que uno

con menos planificación [9], de forma similar a lo expuesto en la siguiente ilustración.

(34)

CAPÍTULO 2. MARCO TEÓRICO 21

Ilustración 2.3 - Decisiones y agilidad. Adaptado de [9]

2.4.4. Observaciones sobre el balance entre agilidad y disciplina

Con el objetivo de describir un contexto para el enfoque balanceado, a continuación pasamos a resumir una serie de observaciones realizadas por Barry Boehm acerca del equilibrio entre agilidad y disciplina [4]:

 Tanto los métodos tradicionales como ágiles, no han logrado conformar la solución definitiva al problema de cómo desarrollar software, sin embargo son buenas aproximaciones, que permiten resolver parte del problema.

 Existen organizaciones donde un método domina claramente a otro. Esto se debe a que los métodos ágiles tiene mayor éxito en una cultura organizacional donde predomina el caos, a diferencia de los tradicionales que lo hacen en una donde predomina el orden.

 Las futuras aplicaciones necesitarán tanto de la disciplina que les pueda otorgar un

método tradicional, como de la agilidad que les pueda brindar un método ágil. Esto

se debe a que los grandes proyectos ya no podrán contar con bajas tasas de cambio y

planificaciones extensas para el proceso, pues encarecería el costo del producto

debido al rediseño y a la demora en la entrega.

(35)

CAPÍTULO 2. MARCO TEÓRICO 22

 Están surgiendo métodos más equilibrados como es el caso de Crystal Orange, DSDM, FDD y Lean Software Development, lo mismo ocurre con las nuevas y más ligeras versiones de RUP.

 Es mejor utilizar un método simple (como los ágiles) que justifique la relación costo- beneficio, que emplear un método del tipo todo incluido (como los tradicionales).

Esto se debe a que los métodos tradicionales son difíciles de ser adaptados a una situación en particular por personas que no son expertas, además el ocupar a expertos puede ser un gasto innecesario que eleva los costos de un proyecto.

 Los métodos son importantes, pero las posibles soluciones que la ingeniería de software requiere se encuentran en la gestión de personal, los valores de las distintas personas y la comunicación.

2.5. Fortalezas y debilidades de métodos ágiles

Conocer las fortalezas de los métodos ágiles, puede ayudar a diferenciar en que proyectos su utilización resultará más beneficiosa. De la misma manera saber cuáles son sus debilidades nos ayudará a tomar las medidas apropiadas con el fin de prevenir o mitigar las situaciones de riesgo.

En esta sección se dispondrán en tablas, las distintas características de los

métodos ágiles, que pueden representar una fortaleza, una debilidad o ambas

dependiendo de la perspectiva con la cual se observe. Para su mejor visualización cada

tabla representará una dimensión o aspecto distinto de los métodos ágiles, como se

observa a continuación.

(36)

CAPÍTULO 2. MARCO TEÓRICO 23

Tabla 2.3 - Clasificación por dimensiones

DIMENSIÓN RELACIONADA CON

Organización  Compromiso de la administración

 Entorno de la organización Personas  Capacidad del equipo

 Participación del cliente Proceso  Gestión del proyecto

 Definición del proyecto Técnica  Técnicas ágiles de software

 Estrategias de entrega Proyecto  Naturaleza del proyecto

 Tipo de proyecto

 Plan del proyecto

Fuente: A survey study of critical success factors in agile software

projects [34].

(37)

CAPÍTULO 2. MARCO TEÓRICO 24

2.5.1. Fortalezas y debilidades genéricas de los métodos ágiles respecto a la organización Tabla 2.4 - Fortalezas genéricas de los métodos ágiles respecto a la organización

CARACTERÍSTICA FORTALEZA

Permiten la invención y desarrollo de nuevas características en entornos formales y grandes.

 Los métodos ágiles permiten el desarrollo o invención de nuevas características para un producto en un entorno formal y grande [35].

Obtienen mejores resultados donde prospera el caos.

 Los métodos ágiles obtienen mejores resultados en organizaciones donde prospera el caos. En este tipo de organizaciones, las personas cuentan con un mayor grado de libertad que en una donde prospera el orden [4].

Uso en organizaciones emergentes.  Los métodos ágiles son adecuados para ser utilizados en organizaciones emergentes [2].

Tabla 2.5 - Debilidades genéricas de los métodos ágiles respecto a la organización

CARACTERÍSTICA DEBILIDAD

Existen dificultades con las certificaciones ISO y CMMI

 Con el uso de métodos ágiles sólo es posible alcanzar niveles de madurez CMMI entre 2 [29], y 3 [36, 37].

 No garantizan aumentar el nivel de CMMI o ISO 9001 de una organización [38].

 Las áreas del proceso más débiles para obtener una certificación ISO o CMMI son [29]:

o La administración de requisitos.

o La medición y análisis.

o El control del producto y proceso.

(38)

CAPÍTULO 2. MARCO TEÓRICO 25

Adoptar un método ágil requiere de grandes cambios por parte de la organización.

 Adoptar un método ágil no sólo requiere recursos, sino que también implica un cambio cultural por parte de la organización [3] [30] [39-43].

 Distintos métodos ágiles, requieren cambios diferentes, tanto en la administración de la organización, como en la cultura de desarrollo de software de la misma [39].

 Pocas organizaciones son psicológicamente o técnicamente capaces de asumir un enfoque ágil de manera rápida y eficaz [35].

 La migración desde un método tradicional a uno ágil, implica grandes alteraciones en los procedimientos de trabajo, herramientas y técnicas, canales de comunicación, estrategias de solución de problemas y funciones de las personas [30].

 Las culturas y organizaciones que están orientadas hacia la innovación pueden adoptar los métodos ágiles de manera más fácil [30].

 Existe una gran dependencia de las capacidades de liderazgo y gestión ejecutiva dentro de una organización, para poder realizar con éxito una transición hacia un método ágil [35].

Difíciles de adoptar y emplear en organizaciones grandes.

 Al aumentar el tamaño de una organización, aumenta la dificultad para adoptar y utilizar métodos ágiles [25] [52].

Las organizaciones que desean emplear métodos ágiles deben contar con un entono adecuado.

 Para emplear métodos ágiles se debe contar con un entorno que facilite la comunicación entre las personas, para lo cual ubicar a las personas más cerca resulta clave [31].

(39)

CAPÍTULO 2. MARCO TEÓRICO 26

2.5.2. Fortalezas y debilidades genéricas de los métodos ágiles respecto a las personas Tabla 2.6 - Fortalezas y debilidades genéricas de los métodos ágiles respecto a las personas

CARACTERÍSTICA FORTALEZA DEBILIDAD

El equipo de desarrollo tiene la facultad de tomar sus propias decisiones.

 Mejora la organización del equipo y el producto en cual se trabaja [35] [42] [44-48].

 La toma de decisiones se hace más difícil, debido a que tanto el cliente como los desarrolladores toman la mayoría de ellas, lo cual genera un entorno pluralista en el que existen diferentes actitudes, objetivos, disposiciones de los miembros del equipo, etc.

[30].

 Puede requerir un enorme esfuerzo por parte de la organización en cuanto a tiempo y paciencia construir una cultura de confianza y respeto entre sus empleados que permita facilitar la colaboración en la toma de decisiones [30].

Las personas trabajan físicamente más cerca.

 Reduce el costo de mover la información entre personas [49], y el tiempo que transcurre entre la toma de la decisión y el paso a la acción.

[50].

 Mucho contacto con otras personas puede generar distracciones en el trabajo. [44].

El trabajo se realiza junto al cliente.  El cliente al ver la calidad del producto que obtiene, se da cuenta de lo importante que es

 Es difícil utilizar métodos ágiles cuando el cliente tiene restricciones en cuanto a su

(40)

CAPÍTULO 2. MARCO TEÓRICO 27

participar durante todo el proceso de desarrollo de su producto [35].

 Se obtiene una mayor calidad en el software, debido a la constante retroalimentación con el cliente [21] [51, 52].

 El trabajo junto al cliente mejora el flujo de la información hacia los desarrolladores lo cual reduce la necesidad de almacenar grandes cantidades de información [53-55].

 El trabajo junto al cliente garantiza una rápida, continua y flexible retroalimentación [56].

 El trabajo junto al cliente ayuda a la creación de un ciclo de vida para la gestión del proyecto más adaptable [48].

 El trabajo junto al cliente, mejora la estimación de un proyecto [57].

disponibilidad para trabajar en el proyecto [21].

 Si el cliente no participa de manera apropiada en el desarrollo, no se puede generar un producto de calidad [23] [49].

 El principal problema es identificar a una o más personas, adecuadas para asumir el rol de cliente [56].

 La resistencia del cliente a este tipo de prácticas puede resultar en un fracaso del proyecto [20].

Tabla 2.7 - Fortalezas genéricas de los métodos ágiles respecto a las personas

CARACTERÍSTICA FORTALEZA

Tienen una buena acogida por parte de los gerentes y desarrolladores.

 Tanto los gerentes como los desarrolladores encuentran que la adopción de un método ágil es emocionante y a la vez gratificante [35].

 Personas ajenas a los equipos ágiles dentro de la misma organización muestran interés por esta forma de trabajo [35].

(41)

CAPÍTULO 2. MARCO TEÓRICO 28

Requieren una menor capacitación para utilizarlos.

 Las personas que van a trabajar con métodos ágiles requieren de una menor capacitación formal que aquellas que van a emplear métodos tradicionales. Actualmente existe una gran cantidad de material proveniente de distintas fuentes (Internet, libros, etc.) para la capacitación del personal en el uso de métodos ágiles. La información que abunda se centra especialmente en métodos como Crystal, Scrum, FDD y XP [31].

Los equipos son capaces de reconocer y reaccionar ante los errores.

 Los equipos logran reconocer y reaccionar antes los errores, también sacan lecciones de ellos y de los cambios ocurridos en su entorno [20] [43] [48] [58, 59].

Mejoran la interacción entre los miembros de un mismo equipo.

 Los distintos métodos ágiles incorporan diversas técnicas y prácticas para mejorar la proximidad e interacción entre los miembros de un equipo, tales como [49]:

o XP y la programación en pares.

o Crystal, Scrum y ASD, defienden prácticas de colaboración estrechas, libre de barreras.

o Lean Development hace hincapié en la interacción del equipo.

 Aumentan la capacidad de propagación de la información y la conciencia por parte del equipo respecto al estado del proyecto [56].

 Los desarrolladores, muestran una mayor conciencia de las acciones y opiniones de los demás.

Además muestran una mejor comprensión de sus propias opiniones y funciones en relación al resto del equipo [60].

Tabla 2.8 - Debilidades genéricas de los métodos ágiles respecto a las personas

CARACTERÍSTICA DEBILIDAD

El personal hace uso del conocimiento tácito.

 El uso del conocimiento tácito puede generar errores irreparables en la arquitectura del sistema cuando no se tienen los conocimientos o no se sabe que se carecen de los conocimientos suficientes para abordar el problema [6].

(42)

CAPÍTULO 2. MARCO TEÓRICO 29

No todas las personas son adecuadas para trabajar con métodos ágiles.

 Los métodos ágiles requieren personas altamente calificadas [5] [10] [30], y altamente motivadas [21] [26]. Además deben ser capaces de trabajar en equipo, comunicarse e interactuar con sus compañeros de trabajo y clientes, etc. [26].

 El 49,9% de las personas está por debajo, en cuanto a los factores personales (amabilidad, talento, habilidad y comunicación) que exigen algunos métodos ágiles [31].

 Las personas que no poseen buenas habilidades para resolver los problemas, parecen ser mucho menos competentes a los ojos de los métodos agiles [44].

El éxito de un proyecto depende en gran medida de las capacidades de quienes trabajan en él.

 Las personas que trabajan en un proyecto pueden determinar el éxito o fracaso del mismo [14], debido a que las condiciones de los mercados son cambiantes y poco predecibles [49, 50] [59] [61].

2.5.3. Fortalezas y debilidades genéricas de los métodos ágiles respecto al proceso Tabla 2.9 - Fortalezas y debilidades genéricas de los métodos ágiles respecto al proceso

CARACTERÍSTICA FORTALEZA DEBILIDAD

Desarrollo iterativo e incremental.  El desarrollo iterativo e incremental, ayuda a mantener la complejidad de un sistema manejable [7, 8] [38] [48].

 Un riesgo del proceso iterativo e incremental es que el diseño puede ser preciso pero la aplicación puede estar mal diseñada o ser poco fiable. Otro riego de esta forma de desarrollo es que el diseño nunca termina, por lo cual la aplicación tampoco lo hace [62].

(43)

CAPÍTULO 2. MARCO TEÓRICO 30

Tabla 2.10 - Fortalezas genéricas de los métodos ágiles respecto al proceso

CARACTERÍSTICA FORTALEZA

Proceso flexible.  La flexibilidad de los métodos ágiles permite la aceptación y el alojamiento de cambios generados desde un medio interno o externo. Lo cual ayuda por ejemplo: a manejar la inestabilidad de los requisitos durante el ciclo de vida [1, 2] [8, 9] [20] [23] [28] [35] [45] [58] [63-65].

 Los métodos ágiles otorgan una mayor flexibilidad al proceso de desarrollo, lo cual permite cambiar los planes de administración y desarrollo [21].

 Los métodos ágiles tienen un proceso flexible lo cual permite que respondan de manera rápida a los cambios que ocurren en el entorno de un proyecto, y es por ello que promueven culturas adaptativas y auto-organizadas, de tal forma que los equipos puedan actuar de manera acertada ante imprevistos durante el desarrollo [8] [20-23] [26] [34, 35] [37, 38] [41] [47-51] [53-55] [58, 59] [66-72].

Fomentan la creación de conocimiento durante el transcurso de un proyecto.

 Durante el transcurso de un proyecto, fomentan la generación de conocimiento y promueven la búsqueda de soluciones ingeniosas a los problemas que surgen, por parte de los desarrolladores que componen los equipos [25] [42, 43] [45] [58].

Mejoran la productividad.  Los métodos ágiles producen software más rápido [32], y con menores costos que los métodos tradicionales [21] [26] [35] [49] [52] [63] [72-75].

 Los métodos ágiles son más productivos y atractivos para los desarrolladores. Además utilizan procesos y herramientas que permiten agilizar todas las tareas repetitivas, permitiéndole a los desarrolladores concentrase en lo que realmente importa (satisfacer al cliente por medio de la construcción de un software valioso) [74] [76].

Se desarrolla sólo lo que es necesario.  Los métodos ágiles desarrollan sólo lo que el cliente necesita. No intentan predecir los cambios o necesidades futuras, lo cual evita el desarrollo de una arquitectura demasiado general que requiera de un esfuerzo adicional [26] [76].

(44)

CAPÍTULO 2. MARCO TEÓRICO 31

Tabla 2.11 - Debilidades genéricas de los métodos ágiles respecto al proceso

CARACTERÍSTICA DEBILIDAD

El usuario carece de participación explícita en el diseño de la interfaz.

 En los ciclos de vida ágil del software, los usuarios carecen de participación explícita en el cuidado de la interfaz. La razón es que se cree que una buena interfaz de usuario es un subproducto de la retroalimentación de ellos [71].

2.5.4. Fortalezas y debilidades genéricas de los métodos ágiles respecto a la técnica Tabla 2.12 - Fortalezas y debilidades genéricas de los métodos ágiles respecto a la técnica

CARACTERÍSTICA FORTALEZA DEBILIDAD

Refactorización continua.  Ayuda a mantener el diseño simple de una aplicación [7, 8] [13] [42] [45].

 Ayuda a mejorar la estructura del código [17, 18] [51] [53] [77].

 La refactorización continua es un esfuerzo adicional y puede generar sobrecostos y retrasos [7].

Menor cantidad de documentación.  Los métodos ágiles generan una menor cantidad de documentación, lo cual permite concentrarse en la generación de código y alivianar la carga de trabajo del equipo [35]

[55] [73] [77].

 No se pueden emplear los métodos ágiles, cuando se requiere la generación de documentación por una o más partes de los interesados [21].

 No se pueden utilizar métodos ágiles cuando se requiere la entrega de documentación a otros equipos (fuera del lugar de trabajo) que continuarán con el desarrollo del software [21].

Figure

Actualización...

Related subjects :