Mejora de La Metodologia Scrum-Martin Casamayor

M E J O R A D E L A

Metodología Scrum

Por Martín Alejandro Casamayor

Carrera: 502

Matricula: 9804

Tutora: Paula Angeleri.

Buenos Aires, febrero de 2010

Contacto: [email protected]

Firma del alumno

Universidad de Belgrano

Facultad de Tecnología Informática

Ingeniería en Informática

Tesina de Grado

MEJORA DE LA METODOLOGÍA SCRUM Martín A. Casamayor

1

Resumen

Scrum es el nombre de una metodología ágil de gestión de proyectos formulada en el

año 1989 por Horitaka Takeuchi y Ikujiro Nonaka.

Sobre la base del conocimiento ganado en la carrera de grado acerca de metodologías

de desarrollo de software, la investigación realizada más dos años experiencia personal en su

utilización intensiva, el presente trabajo se propone descubrir y analizar sus puntos débiles, con

el fin de identificar oportunidades de mejora.

Como resultado, se espera ofrecer las empresas y grupos de personas que desean

utilizarla, orientaciones para aplicarla con mayor eficiencia y para resolver mejor los problemas

que enfrentan, minimizando así las probabilidades de fracaso.


2

Índice

RESUMEN ......................................................................................................... 1

ÍNDICE ............................................................................................................... 2

ÍNDICE DE FIGURAS Y TABLAS ........................ ............................................. 5

1 INTRODUCCIÓN: ........................................................................................ 6

1.1 Planteamiento y contexto del problema y trabajos re lacionados .............................. 7

1.2 Objetivo .......................................... .................................................................................. 8

1.3 Justificación ..................................... ................................................................................ 8

1.4 Delimitaciones .................................... ............................................................................. 8

2 MARCO TEÓRICO .................................................................................... 10

2.1 Metodología ágil .................................. .......................................................................... 10 2.1.1 El Manifiesto Ágil ......................................................................................................... 10 2.1.2 Principios: producto, cliente y equipo .......................................................................... 11 2.1.3 Metodología Tradicional versus Metodología Ágil ...................................................... 12

2.2 Scrum ............................................. ................................................................................ 17 2.2.1 La historia de Scrum.................................................................................................... 17 2.2.2 La metodología ............................................................................................................ 18 2.2.3 Datos generales de Scrum .......................................................................................... 18

2.2.3.1 Las reuniones .................................................................................................. 19 Los elementos ......................................................................................................... 20 2.2.3.2 .............................................................................................................................. 20 2.2.3.3 Los roles o responsabilidades ......................................................................... 20 2.2.3.4 Responsabilidad del producto: El propietario del producto ............................. 20 2.2.3.5 Responsabilidad del desarrollo: El equipo ...................................................... 21 2.2.3.6 Responsabilidad del funcionamiento de Scrum (Scrum Manager) ................. 21

2.2.4 Reglas de Scrum ......................................................................................................... 21 2.2.4.1 Las reglas de Scrum (I): El Sprint Planning Meeting ...................................... 22 2.2.4.2 Las reglas de Scrum (II): Durante el Sprint ..................................................... 23 2.2.4.3 Las reglas de Scrum (III): El Sprint Review Meeting ....................................... 24 2.2.4.4 Las reglas de Scrum (y IV): El Sprint Retrospective Meeting (Reuniones retrospectivas) ................................................................................................................. 26

2.2.5 Burn Down ................................................................................................................... 29 2.2.6 Herramientas para la gestión de proyectos ................................................................ 30 2.2.7 Modelo de proceso de Scrum actual ........................................................................... 31

3 ANÁLISIS .......................................... ........................................................ 33


3

3.1 Análisis comparativo entre metodologías ........... ....................................................... 33 3.1.1 Scrum versus XP ......................................................................................................... 33

3.2 Inconvenientes de Scrum ........................... .................................................................. 34 3.2.1 Inconvenientes al utilizar Scrum .................................................................................. 34

3.3 ¿Qué intentamos realizar? ......................... .................................................................. 36

4 DISEÑO ..................................................................................................... 39

4.1 ¿Cómo saber si Scrum está funcionando? Puntos clave s y débiles de la metodología ....................................... ........................................................................................ 39

4.1.1 La falta de atención a los detalles ............................................................................... 39 4.1.2 Entender y formar el equipo multidisciplinario ............................................................ 40 4.1.3 Crear y mantener un Product Backlog ........................................................................ 41 4.1.4 Recursos humanos no dedicados ............................................................................... 41 4.1.5 Integración de las tareas de soporte y mantenimiento ............................................... 42 4.1.6 Estimación ................................................................................................................... 42 4.1.7 Documentación ............................................................................................................ 43 4.1.8 Calidad ........................................................................................................................ 43

4.2 Mejora de la metodología de Scrum ................. ........................................................... 44 4.2.1 Requisitos .................................................................................................................... 44

4.2.1.1 Ingeniería de Requisitos (IE): .......................................................................... 44 4.2.1.2 En qué podría mejorar Scrum con IE .............................................................. 47

4.2.2 El equipo: ..................................................................................................................... 48 4.2.2.1 El Product Owner ............................................................................................ 48 4.2.2.2 Esfuerzos Individuales..................................................................................... 49

4.2.3 Desarrollo .................................................................................................................... 50 4.2.3.1 Test Driver Development (TDD) ...................................................................... 50 4.2.3.2 Pair Programming ............................................................................................ 50 4.2.3.3 Diseño incremental .......................................................................................... 51 4.2.3.4 Integración continua ........................................................................................ 52 4.2.3.5 Propiedad colectiva del código ........................................................................ 52 4.2.3.6 Ambiente de trabajo informativo ...................................................................... 52 4.2.3.7 Estándares de codificación ............................................................................. 53 4.2.3.8 Ritmo sostenido ............................................................................................... 53

4.2.4 Calidad ........................................................................................................................ 54 4.2.4.1 Quality Assurance (QA) ................................................................................... 54 4.2.4.2 Por qué la calidad no es negociable ............................................................... 55

4.2.5 Diagrama de función de Scrum para tareas ............................................................... 56 4.2.6 Nuevas Reglas ............................................................................................................ 57

4.2.6.1 Las reglas de Scrum (VI): Procesos y herramientas de ingeniería de software 57

5 CONCLUSIÓN ........................................................................................... 60

6 GLOSARIO .......................................... ...................................................... 61


4

7 BIBLIOGRAFÍA ...................................... ................................................... 63

8 ANEXO 1 ................................................................................................... 66 8.1.1 Modelo iterativo e incremental .................................................................................... 66

8.1.1.1 Etapa de inicialización ..................................................................................... 66 8.1.1.2 9.1.2 Etapa de iteración................................................................................... 66 8.1.1.3 Lista de control de proyecto ............................................................................ 67


5

Índice de figuras y tablas

Tabla 2.1.3-1 Metodología ágil vs Metodología Tradicional (José H. Canós P. L.). .............. 13 Tabla 2.1.3-2 Uso de las metodologías ágiles ........................................................................ 14 Gráfico 2.1.3-1 Uso de las metodologías ágiles ..................................................................... 14 Tabla 2.1.3-3 Comparación de metodologías (Schwaber, SCRUM Development Process, págs. 10-11) ............................................................................................................................ 16 Gráfico 2.2.3-1 El flujo de trabajo en Scrum ........................................................................... 19 Gráfico 2.2.4.1-1 Sprint Planning Meeting .............................................................................. 22 Gráfico 2.2.4.4-1 Ciclo de Scrum ............................................................................................ 28 Gráfico 2.2.5-1 Burn Down detallado ...................................................................................... 29 Gráfico 2.2.5-2 Burn Down ...................................................................................................... 30 Gráfico 2.2.7-1 Proceso actual de Scrum según reglas (Autor M. Casamayor) ..................... 32 Tabla 3.1.1-1 Scrum Vs XP ..................................................................................................... 34 Gráfico 3.3-1 Mejora de productividad de software ................................................................ 37 Gráfico 4.1.6-1 Scrum enfocado a proyectos informáticos - Autor: Martín Casamayor. ........ 56


6

1 Introducción:

En el inicio de todo proyecto informático es necesario averiguar de qué manera van a

ser gestionadas todas las tareas a realizar. Esto es lo que se conoce como gestión de

proyectos de software. Existen numerosas herramientas, métodos y técnicas que ayudan a

lograr una mayor precisión en cuanto a los plazos, costos, esfuerzo y riesgos que puede

implicar la tarea (Garreta, 2003). Este gran número se debe a que no hay una única

metodología que resulte óptima para todos los proyectos, sino que cada proyecto puede

funcionar mejor con una determinada metodología que con otra, ya sea por alcance,

dimensiones del proyecto, por la cantidad de personas involucradas, por el tema de que se

trata, tecnología a utilizar, etc. (Charvat, 2003).

Al optar por una metodología, para llevar a cabo su implementación se requerirá tiempo

y esfuerzo: se hace necesario comprar o conseguir las herramientas adecuadas y además

capacitar al personal. Esto también ocurre –en algunos casos en menor grado–, si ya se está

aplicando una determinada metodología y se decide cambiar por otra. Es por eso que, antes de

decidirse por una metodología es conveniente estudiarla y evaluar si será la más adecuada

para el desarrollo de nuestro proyecto.

Dentro de la gran variedad existente, encontramos metodologías tradicionales

(conocidas como metodologías pesadas por su gran cantidad de documentación) y

metodologías ágiles. Las metodologías ágiles tienen como característica su tendencia a

enfocarse más en el producto final –sin concentrarse tanto en la documentación, el análisis y el

diseño exhaustivo, etc.– para que, de esta forma, el proyecto pueda entrar cuanto antes en la

fase de producción.

La tendencia demuestra que, en general, debido a su nivel de complejidad, al tiempo

necesario para desarrollarlos y a la cantidad de personal requerido, los proyectos pequeños

suelen aplicar metodologías ágiles, mientras que los proyectos de gran envergadura son

tratados con metodologías tradicionales. Entre las metodologías ágiles encontramos la

Metodología Scrum la cual, en la actualidad, es aplicada con mucha frecuencia a la gestión de

proyectos.

Como ocurre con toda metodología o proceso, al aplicar Scrum se descubren

problemas, dificultades con las reglas o dudas acerca de cómo aplicarlas correctamente. En

muchas oportunidades se observa que son los propios equipos los que modifican las reglas,

adaptándolas para utilizarlas mejor o descartando aquéllas que no estiman útiles para un

proyecto en particular (Abrahamsson, 2008) (Rossberg, 2008). Esto no siempre resulta

conveniente ya que, a veces, la intención de mejorar la metodología de un proyecto termina por

generar un problema aún mayor.

Esto llevó a pensar en una nueva forma de aplicarla, agregando a la forma actual de la

Metodología Scrum, reglas y procesos propios de la ingeniería de software, propuesta que se

desarrolla a lo largo del presente trabajo.


7

Por tratarse de una metodología nacida a mediados de la década de los ‘80, existe

sobre el tema una rica bibliografía y abundantes acreditaciones internacionales. Existen

también herramientas informáticas para administrar los proyectos de desarrollo de software que

aplican Scrum. Esto dio lugar al surgimiento de múltiples foros de discusión, en los cuales se

puede obtener información, lo cual contribuye a llevar a Scrum un paso más adelante.

1.1 Planteamiento y contexto del problema y trabajo s relacionados

Scrum es una metodología de gestión de proyectos relativamente reciente. A pesar de

esto, ya son muchos los equipos que la han implementado. Así se hizo conocida como una

metodología valiosa para proyectos pequeños y cambiantes. Su buena reputación en relación

con ese tipo de proyectos contribuyó también a que sus desventajas hayan sido menos

conocidas o analizadas.

La documentación existente acerca de una metodología pocas veces describe

experiencias de aplicación; más escasa aún en este caso, por tratarse de una metodología

joven. Muchas veces no se especifica ni estudian detalladamente sus posibilidades de

aplicación al proyecto que se emprende, al tipo de personal y de cliente que se tiene, o a la

tecnología que se implementará. También suele suceder que, por tratarse de una metodología

ágil, se aplique la regla de priorizar el producto terminado a la documentación, resultando que

la documentación al final del proyecto es escasa o nula, lo cual generará inconvenientes en el

futuro.

Con la experiencia de haber aplicado esta metodología a distintos proyectos de

software, adoptando los roles de desarrollador como de Scrum Master, se hizo evidente que no

existen acerca de ella herramientas y procesos de la ingeniería para el desarrollo, o existen

poca cantidad de experiencias documentadas, que permitan decidir las acciones a tomar ante

sucesos inesperados, cómo detener una tarea a raíz de cambios o cuándo no es necesario o

no conviene hacerlo. Ninguna de estas circunstancias está prevista en la metodología y sólo se

aprenden a partir de la experiencia y de la modificación de algunas de sus reglas o

características.

En la actualidad la cantidad de foros de discusión acerca de temas relacionados con

Scrum se ha incrementado, así como también los trabajos relacionados con el problema de la

documentación, la no existencia de procesos de ingeniería o la forma de utilizar partes de otras

metodologías para cubrir alguna falencia de ésta. Sin embargo, aun cuando toda la información

necesaria está disponible, con frecuencia se recurre a ella cuando el proyecto está en marcha y

enfrenta problemas graves.


8

1.2 Objetivo

Buscar y encontrar alternativas para mejorar la implementación de la Metodología ágil

Scrum, de manera que resulta más eficaz en sus primeras etapas de implementación en un

equipo nuevo.

1.3 Justificación

Las metodologías ágiles son un recurso relativamente nuevo. No fue sino hasta

mediados de la década de los ‘90 cuando Scrum surgió como una metodología ágil para

proyectos de software. Sin embargo, a pesar de ser relativamente nueva, el uso de Scrum ha

crecido significativamente.

Al momento de comenzar a utilizar una metodología ágil, comienzan a surgir

eventualidades que no favorecen al desarrollo del proyecto. En el ámbito del desarrollo

informático se suele decir que, por tratarse de una metodología ágil, hay muchos aspectos en

los cuales las decisiones quedan a criterio de quien la esté implementando. Un ejemplo de esto

es la documentación.

La “libertad” propia de este tipo de metodologías genera muchas veces un resultado

negativo, ya que no existe una solida base sobre la cual referenciarse, lo que conduce a

entregas tardías, con calidad mediocre, disconformidad del cliente y/o del equipo, etc.

Por otra parte, a pesar que en este tipo de metodologías existen reglas, éstas se

pueden aplicar de diferente manera según el proyecto o el equipo de que se trate. Esto no

debería ocurrir, ya que una regla debe ser invariable. Sin embargo, la variación en cuanto a la

forma de aplicación de las reglas se observa constantemente en los diferentes equipos. Estos

son, precisamente, los puntos que llevan a replantear el tema y proponer una solución.

La solución consiste en establecer una base más robusta y sólida, en la cual no existan

ambigüedades ni tal grado de libertad que dé lugar confusión o errores en el equipo.

Asimismo,, se procurará reducir los retrasos, las deficiencias en la calidad y todo otro tipo de

inconvenientes en los desarrollos que aplican Scrum.

Se espera lograr este objetivo por medio de la incorporación a la Metodología Scrum de

buenas prácticas como la Ingeniería de Requisitos de Desarrollo, utilizada por otras

metodologías y teniendo en cuenta otras exigencias de calidad propias de los proyectos de

software.

1.4 Delimitaciones

Las recomendaciones que surgen de este trabajo se basan en la experiencia personal

y en el análisis detenido de las cuestiones planteadas. Sin embargo, no han sido puestas a

prueba debido a que aplicar una metodología requiere de un proyecto adecuado, así como de

tiempo suficiente para adaptar un equipo y para pulir detalles que estas recomendaciones

necesiten, todo lo cual excede el periodo de preparación de una tesina.


9

La última delimitación consiste en la tecnología de codificación a emplear para el

desarrollo del proyecto. En la Metodología Scrum, la programación deberá ser Programación

Orientada a Objetos (POO). Esto se debe a que las tareas pueden ser divididas y fácilmente

reflejadas en código como objetos o métodos específicos.


10

2 Marco Teórico

2.1 Metodología ágil

Para comenzar a hablar de Scrum es necesario definir, en primer lugar, qué es una

metodología ágil y en qué aspectos difiere de una tradicional. Las metodologías tradicionales

se dividen en fases que son, por lo general, � Análisis, � Diseño, � Desarrollo, � Implementación

y � Mantenimiento.

Las metodologías ágiles, por su parte, se dividen en pequeños proyectos que se van

llevando a cabo en forma incremental. A continuación se presentan las bases y significado de

las metodologías ágiles.

2.1.1 El Manifiesto Ágil

En el año 2001 un grupo pionero en las metodologías ágiles reunió y estableció las

bases para desarrollarlas. Este enunciado se conoce como ”Manifiesto Ágil” (Kent Beck, 2001)

(Larman, Agile and iterative development: a manager's guide, 2004) (Doug Rosenberg, 2005) y

propone:

� Dar más importancia a la interacción entre personas, que a los procesos y

herramientas.

� Dar más importancia a los productos que funcionan, que a la documentación

extensiva.

� Incentivar la colaboración con el cliente, más que la negociación del contrato.

� Responder al cambio es mejor que seguir el plan.

Existen también doce principios para el desarrollo ágil de software, redactados por los

mismos autores. Estos son:

� La prioridad es satisfacer al cliente mediante tempranas y continuas entregas

de software que le aporte valor.

� Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente

tenga una ventaja competitiva.

� Entregar frecuentemente software que funcione desde un par de semanas a un

par de meses, con el menor intervalo de tiempo posible entre entregas.

� La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del

proyecto.

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

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

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


11

� Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener constante

armonía.

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

� La simplicidad es esencial.

� Las mejores arquitecturas, requisitos y diseños surgen de los equipos

organizados que se organizan a sí mismos.

� Periódicamente, el equipo reflexiona acerca de cómo ser más eficaces, y ajusta

su conducta en consecuencia.

2.1.2 Principios: producto, cliente y equipo

El principio de metodología ágil también modifica el concepto de lo que se conoce

como producto, cliente y equipo. Otorga prioridades y significados diferentes según los

mencionados doce principios expresados para el desarrollo ágil de software (Castro,

Metodología de Trabajo Ágil y Eficiente: El método Scrum aplicado a la Gestión de Proyectos

en general). Estos son:

Cliente

� La mayor prioridad es satisfacer al cliente a través de la entrega temprana y

continua de productos con valor.

� Se aceptan requisitos cambiantes, incluso en etapas avanzadas. Esto es una

ventaja competitiva de los procesos ágiles.

� Los responsables del negocio y los empleados deben trabajar juntos

diariamente, a lo largo de todo el proyecto.

Producto

� El producto que funciona es la principal medida del progreso.

� Se entregan productos con frecuencia.

� La simplicidad es esencial.

� Los procesos ágiles promueven el desarrollo sostenible.

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

agilidad.

Equipo

� Se construyen proyectos con profesionales motivados.

� Se prioriza la comunicación cara a cara.

� Las mejores propuestas, requisitos y diseños surgen de los equipos que se

auto-organizan.

� Periódicamente, el equipo reflexiona acerca de cómo ser más efectivo.


12

2.1.3 Metodología Tradicional versus Metodología Á gil

Hasta hace poco, la tarea de desarrollo llevaba asociado un marcado énfasis sobre el

control del proceso por medio de una rigurosa definición de roles, actividades y artefactos,

incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el

desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño

(en cuanto a tiempo y recursos), en los cuales, por lo general, se exige un alto grado de

formalidad en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para

muchos de los proyectos actuales, donde el entorno del sistema es muy cambiante, y en los

cuales se exige reducir drásticamente los tiempos de desarrollo, manteniendo una alta calidad.

Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de

tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir de las reglas de las

“buenas prácticas” de la ingeniería del software, asumiendo el riesgo que esto implica. En este

escenario, las metodologías ágiles surgen como una alternativa para llenar ese vacío

metodológico. Por estar especialmente orientadas a proyectos pequeños, las metodologías

ágiles representan una solución a medida para ese entorno, aportando una notable

simplificación que, sin embargo, no renuncia a las prácticas esenciales para asegurar la calidad

del producto.

Las metodologías ágiles son uno de los temas que en la actualidad despiertan gran

interés en la ingeniería de software, y están ganando espacio en la mayoría de las conferencias

y workshops. Su impacto es tan grande que, inclusive, son el tema central de muchas

conferencias internacionales. (Ciencia y Técnica Administrativa). En la comunidad de la

ingeniería del software, se está viendo con frecuencia un debate abierto entre los que siguen

las metodologías tradicionales y aquellos que apoyan las ideas del “manifiesto ágil”.

La mayoría de los ingenieros de software y de los usuarios de estas nuevas prácticas

sienten que las metodologías ágiles tienen un gran futuro por delante en el campo del

desarrollo de software y en el ámbito industrial. Por un lado, para muchos equipos de trabajo

las metodologías tradicionales representan algo muy diferente de la forma de trabajo actual,

considerando las dificultades para introducirlas y la inversión que implican en cuanto a

capacitación y equipos. Por otra parte, las características de los proyectos para los cuales las

metodologías ágiles han sido especialmente pensadas, se ajustan a un amplio rango de

proyectos industriales de desarrollo de software. Precisamente aquellos en los cuales los

equipos de desarrollo son pequeños, con plazos reducidos, requisitos y alcances cambiantes, y

basados en nuevas tecnologías. (José H. Canós P. L.)

¿Se debe a esto que está siendo tan investigada y utilizada por grupos de desarrollo y

gestión de proyectos? Actualmente la gran mayoría de los proyectos de software son proyectos

de pequeños a medianos, con plazos menores de un año para cumplir las etapas de análisis,

diseño, desarrollo e implementación. Además, no se puede comenzar por hacer un análisis de

los requisitos del momento actual porque, por lo general, cambiarán en el transcurso del


13

desarrollo. Los requisitos no sólo cambian de manera rápida, sino que también es muy difícil

definirlos por la cantidad de información de que se dispone en la actualidad (José H. Canós).

A continuación se presenta una tabla comparativa entre ambos tipos de metodología.

Metodología Ágil Metodología Tradicional

En qué se basa Basada en heurísticas provenientes de prácticas de producción de código.

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

Cambios durante el proyecto Especialmente preparada para los cambios durante el proyecto

Cierta resistencia a los cambios.

Quién la impone Impuesta internamente (por el propio equipo)

Impuesta por un tercero.

Procesos Procesos menos controlados, más libertad a la hora de aplicar procesos, pocos principios.

Procesos muchos más controlados con numerosas políticas / normas.

Tipo de contratos existentes No existen contratos tradicionales.

Existe un contrato prefijado.

Como actúa el cliente en el proyecto

El cliente es parte del equipo de desarrollo.

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

El equipo Grupos pequeños (menos de 15 integrantes).

Grupos grandes y probablemente distribuidos.

Artefactos Pocos artefactos. Muchos artefactos.

Roles Pocos roles. Muchos roles.

Diseño y arquitectura Menos énfasis en la arquitectura del software.

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

Entregas El cliente ve progresos en intervalos cortos de tiempo.

El cliente ve solo la versión final.

Definición de requisitos Los requisitos pueden cambiar.

Los requisitos se establecen al principio sin poderse cambiar.

Tabla 2.1.3-1 Metodología ágil vs Metodología Tradi cional (José H. Canós P. L.).


14

En consecuencia, en líneas generales, una metodología ágil puede resultar muy útil

para corregir requisitos mal formulados, mal definidos o incompletos. Por otra parte, al ser más

libre y no basarse tanto en el cumplimiento de normas, su costo tiende a ser menor.

A continuación se presenta un gráfico sobre la cantidad de proyectos que utilizan

metodologías ágiles. Agile journal (N°1, Marzo-2006 )1.

Tabla 2.1.3-2 Uso de las metodologías ágiles

Gráfico 2.1.3-1 Uso de las metodologías ágiles

En esta encuesta, también se consultó por qué utilizan estas metodologías. Las

respuestas fueron las siguientes:

� Para reducir el tiempo de desarrollo: 45%

� Para mejorar la calidad: 43%

� Para reducir costes: 23%

� Para alinear el desarrollo con los objetivos de negocio: 39%

� Otras razones: 12%.

¿Y cuál es el ranking de preferencias entre los modelos ágiles? Estos fueron los

resultados:

1. Extreme Programming (28%)

2. FDD (26%)

3. Scrum (20%)

4. Crystal (6%)

1 Encuesta realizada por CM Crossroad en el año 2006 en los Estados Unidos. (CM Crossroad).


15

5. DSDM (4%)

Llegada la hora de elegir una metodología ágil, estas encuestas permiten prever cuáles

son las metodologías que probablemente tendrán mayor soporte en foros de debate y grupos,

así como documentación acerca de casos ocurridos.

Todas estas consideraciones resultan muy valiosas al momento de decidirse por una.

Sin embargo, existen otros aspectos a tener en cuenta.

Cuando se pretende cambiar de una metodología de desarrollo por otra, el costo del

cambio resulta, por lo general, grande. Este costo, expresado en tiempo y dinero, comprende:

� Capacitación: Del equipo que va a emplear la metodología, del cliente en caso

de que éste participe en el equipo, y a su vez para informarlo de cómo serán

las entregas de versiones del producto, etc.

� Tiempo de adaptación de las personas del equipo .

� Tiempo de adaptación del cliente , si es que este pasa a involucrarse

directamente con el equipo de desarrollo.

Sin embargo, los estudios realizados también revelan que, si se utilizan metodologías

tradicionales que implican normas y políticas a cumplir, aunque comenzar a utilizar una

metodología ágil implica un costo inicial mediano, éste tiende a ser bajo a largo plazo, ya que

las metodologías ágiles en general son gratuitas, hay mucho software para implementarlas y

herramientas para aplicarlas que son gratuitos, todo lo cual representa grande ventajas.

A continuación se presenta un cuadro que refleja las diferencias entre Scrum y otro tipo

de metodologías no ágiles.

Comparación de procesos

Cascada Espiral Iterativo Scrum

Procesos definidos

Requerido Requerido Requerido Planificación y acercamiento

Producto final Determinado durante la planificación

Determinado durante la planificación

Determinada durante el desarrollo


Costo del proyecto


Variable parcialmente



Fecha de finalización


Variable parcialmente



Estudio del impacto del contexto

En etapa de planificación únicamente

En la planificación principalmente

Al final de cada iteración

En todo momento


16

Cascada Espiral Iterativo Scrum

Flexibilidad y creatividad del equipo

Limitado Limitado Limitado Ilimitado durante las iteraciones

Transferencia de conocimiento

El entrenamiento es más importante para el proyecto



El equipo trabaja en conjunto durante el proyecto

Probabilidad de éxito

Baja Media - Baja Media Alta

Tabla 2.1.3-3 Comparación de metodologías (Schwaber, SCRUM Development Process, págs. 10-11)


17

2.2 Scrum

Scrum (Schwaber, 2004) (Ken, 2007) (Ken Schwaber, 2001) (Cohn, 2004) es una

metodología de gestión de proyectos de software iterativa e incremental. Se aplica sobre la

base de reglas propias, que se deben aplicar en todo momento. También incluye dentro del

equipo de desarrollo a un usuario o dueño del proyecto (Product Owner) y a un líder de

proyecto (Scrum Master).

En la metodología se plantean todas las reglas necesarias para saber si se está

gestionando correctamente un proyecto. Sin embargo, no se plantea ninguna práctica ni

proceso de ingeniería de software para aplicarla. Esto se debe a que Scrum no se enfoca en la

gestión de proyectos de una rama específica, sino que puede aplicarse a proyectos de

informática, de electrónica, de construcción de automóviles, etc.

En la actualidad, Scrum resulta exitosa en el desarrollo de proyectos de informática, ya

que plantea reglas claras acerca de cómo gestionarlos y ofrece libertad a la hora de utilizar

prácticas de ingeniería de software. Esto último puede representar tanto una ventaja como una

dificultad. En varias experiencias se ha visto que surgen problemas al momento de decidir

cuáles procesos de la ingeniería de software aplicar, o qué herramientas para el desarrollo de

la aplicación se va a utilizar, ya que Scrum no recomienda ni menciona ninguna en particular.

Esto puede traer como consecuencia que un equipo sin experiencia en una nueva metodología

utilice, tal vez, herramientas y procesos de la ingeniería que no son los más adecuados o, peor

aún, no utilice ninguno.

A continuación se explicará qué es Scrum en la actualidad, y cuáles son sus diferencias

y similitudes con otras metodologías existentes. A partir de estas definiciones, se procurará

encontrar formas de reducir las desventajas que presenta la metodología al momento de iniciar

la gestión de un proyecto informático.

2.2.1 La historia de Scrum

Scrum es una metodología ágil de gestión de software, que ayuda a administrar,

controlar y desarrollar la gestión de un proyecto por medio de un proceso iterativo. Es por esto

que Scrum es una metodología que se aplica en proyectos de toda índole.

Surge en el año 1986 cuando Hirotaka Takaeuchi e Ikijiro Nonaka describieron una

nueva forma que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos

comerciales. El término Scrum proviene del vocabulario del Rugby, y en ella el desarrollo del

producto emerge de una constante interacción de mano en mano, donde los miembros de un

equipo multidisciplinario trabajan en conjunto, desde el principio hasta el final. (Rossberg, Pro

Visual Studio Team System Application Lifecycle Management, 2008)


18

En el año 1993 se aplicó por primera vez Scrum2 en un desarrollo de software y luego,

en el año 1995, se formalizó3.

Desde entonces, miles de proyectos en todo el mundo han utilizado Scrum, tanto en

pequeñas empresas, como en grandes multinacionales.

En la actualidad, Scrum se está utilizando en diferentes tipos de negocio y,

especialmente, en el desarrollo de software. Existen organizaciones, como Scrum Alliance o

Scrum Management, que se encargan de difundir esta metodología en el ámbito de la

Informática.

2.2.2 La metodología

Scrum se basa en reglas para saber si se está aplicando correctamente la gestión del

proyecto. Estas reglas son la guía para poder aplicar y gestionar la metodología de manera

correcta, de manera que nos diga cómo aplicarlas en los proyectos, al realizar las reuniones,

reaccionar a los cambios de requisitos (Schwaber, 2004) (Corral, 2006).

A continuación se presentan datos generales de Scrum. De esta forma se tiene un

concepto más completo de la metodología para poder comprender de mejor manera las reglas

antes mencionadas.

2.2.3 Datos generales de Scrum 4

Las mencionadas reglas –que presentaremos más adelante– sirven para llevar a cabo

el proyecto. Sin embargo, es necesario saber cómo comenzar a gestionar un proyecto con

Scrum.

Antes de presentar las reglas se relevarán los datos generales de Scrum como el

vocabulario propio de la metodología, los roles que se involucran y los puntos básicos que cada

uno de éstos implica. Una vez presentada esta información, se tratará con mayor detalle cada

punto.

2 Jeff Sutherland, John Scumniotales y Jeff McKenna fueron los primeros en concebir, ejecutar y documentar el

desarrollo ágil en proyectos de software en el año 1993. 3 En 1995 Ken Schwaber formalizó el proceso para la industria de desarrollo de software.

4 Otros datos que son útiles, tipos de reuniones, duraciones y reglas dentro de estas. (10)


19

Gráfico 2.2.3-1 El flujo de trabajo en Scrum

Los componentes y conceptos empleados en Scrum son:

2.2.3.1 Las reuniones

� Planificación del sprint:

Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál es el

trabajo y los objetivos que se deben cubrir con esa iteración.

Esta reunión genera la “sprint backlog” o lista de tareas que se van a realizar, y en ella

también se determina el “objetivo del sprint”: lema que define la finalidad de negocio que se va

a lograr.

� Seguimiento del sprint:

Breve reunión diaria para dar repaso al avance de cada tarea, y al trabajo previsto para

la jornada. Sólo interviene el equipo, y cada miembro responde a tres preguntas:

1. Trabajo realizado desde la reunión anterior.

2. Trabajo que se va a realizar hasta la próxima reunión de seguimiento.

3. Problemas que es necesario resolver para poder realizar el trabajo.


20

� Revisión de sprint:

Análisis y revisión del incremento generado. Esta reunión no debe tomarse como un

“acontecimiento especial” sino como la presentación normal de los resultados.

2.2.3.2 Los elementos

Product Backlog: Requisitos del sistema. Se parte de la visión del resultado que se

desea obtener; y evoluciona durante el desarrollo. Es el inventario de características que el

propietario del producto desea obtener, ordenado por orden de prioridad. Es un documento

“vivo”, en constante evolución. Es accesible a todas las personas que intervienen en el

desarrollo. Todos pueden contribuir y aportar sugerencias. El responsable del product backlog

es una única persona y se la denomina: propietario del producto.

Sprint Backlog: Lista de los trabajos que realizará el equipo durante el sprint para

generar el incremento previsto. El equipo asume el compromiso de la ejecución. Las tareas

están asignadas a personas, y tienen estimados el tiempo y los recursos necesarios.

Incremento: Resultado de cada sprint. Se trata de un resultado completamente

terminado y en condiciones de ser utilizado.

2.2.3.3 Los roles o responsabilidades

El grado de funcionamiento de Scrum en la organización depende directamente de

estas tres condiciones:

� Características del entorno (organización y proyecto), adecuadas para

desarrollo ágil.

� Conocimiento de la metodología de trabajo por parte de todas las personas de

la organización y las personas implicadas por el lado del cliente.

� Asignación de responsabilidades:

o Sobre el producto.

o Sobre el desarrollo.

o Sobre el funcionamiento de Scrum

2.2.3.4 Responsabilidad del producto: El propietario del producto

En el proyecto hay una persona –y sólo una– conocedora del entorno de negocio del

cliente y de la visión del producto. Representa a todos los interesados en el producto final y es

el responsable del Product Backlog.

Se le suele denominar “propietario del producto” y es el responsable de obtener el

resultado de mayor valor posible para los usuarios o clientes.

Es responsable de la financiación necesaria para el proyecto, de decidir cómo debe ser

el resultado final, del lanzamiento y del retorno de la inversión.

En desarrollos internos, quien asume este rol puede ser el Product Manager (o el

responsable de marketing).


21

En desarrollos para clientes externos lo más aconsejable es que sea el responsable del

proceso de adquisición del cliente.

2.2.3.5 Responsabilidad del desarrollo: El equipo

Todo el equipo de desarrollo, incluido el propietario del producto conoce la

metodología Scrum, y son los auténticos responsables del resultado.

Es un equipo multidisciplinario, que incluye todas las habilidades necesarias para

generar el resultado.

Se auto-gestiona y auto-organiza, y dispone, dentro de la organización, de atribuciones

suficientes para tomar decisiones sobre cómo realizar su trabajo.

2.2.3.6 Responsabilidad del funcionamiento de Scrum (Scrum Manager)

La organización debe garantizar el funcionamiento de los procesos y metodologías que

emplea, y en este sentido Scrum no es una excepción.

En el modelo de Scrum definido por Jeff Sutherland, esta responsabilidad se garantiza

integrando en el equipo a una persona con el rol de.

Considerando que las realidades de unas y otras empresas pueden ser muy diferentes,

y que siempre que sea posible es mejor optar por adaptar las prácticas de trabajo a la empresa,

y no al revés, en ocasiones puede resultar más aconsejable:

� Que en lugar de una persona con la función de “Scrum Master”, sean las

personas y puestos más adecuados en cada organización los que reciban la

capacitación adecuada y asuman las funciones necesarias para cubrir esta

responsabilidad.

� Que al compromiso de funcionamiento del proceso se sume también la

dirección de la empresa, con el conocimiento de gestión y desarrollo ágiles, y

facilitando los recursos necesarios.

Scrum Manager designa por tanto, más que el rol, la responsabilidad de

funcionamiento del modelo. Puede ser al nivel del proyecto o al nivel de la organización. En

algunos casos resultará más apropiado un rol exclusivo (tipo Scrum Master), mientras que en

otros puede ser mejor que las responsabilidades de funcionamiento sean asumidas por los

responsables del Departamento de Calidad o Procesos, o del área de Gestión de Proyectos.

2.2.4 Reglas de Scrum

Las reglas de Scrum son claras, simples y fáciles de implementar. En general, se sabe

que si hay un problema con las reglas, hay un problema con la gestión del proyecto. Sin

embargo, el principal problema que suele aparecer es que algunos integrantes no se saben

adaptar a las reglas.

A continuación se resumen las reglas de Scrum.


22

2.2.4.1 Las reglas de Scrum (I): El Sprint Planning Meeting

Gráfico 2.2.4.1-1 Sprint Planning Meeting

La Reunión de Planificación del Sprint (o Sprint planinng meeting) tiene una duración

máxima de 8 horas, divididas en dos partes. La Primera Parte sirve para seleccionar cual será

el Product Backlog y en la Segunda Parte se prepara el Sprint Backlog con el cual se trabajará.

� Los asistentes obligatorios son el equipo, incluyendo al Scrum Master y el

Product Owner. Además puede haber otras personas como los usuarios –que

conocen las necesidades– o personas que puedan brindar más información

acerca del negocio o la tecnología. Sin embargo, estas personas deberán

retirarse una vez que proporcionen la información.

� El Product Owner debe preparar el Product Backlog antes de la reunión. De

estar ausente el Product Owner, será reemplazado por el Scrum Master.

� El objetivo de la primera parte –es decir, de las primeras 4 horas– es que el

Equipo seleccione aquellos elementos del Product Backlog que cree que puede

comprometerse a transformar en un incremento de funcionalidad

potencialmente entregable. El Equipo deberá mostrar este incremento de

funcionalidad al Product Owner y a los involucrados en la Reunión de revisión

de sprint (o Sprint review meeting) al final del Sprint.

Sprint Planning Meeting

Product Backlog

Capacidades del

equipo

Condiciones de

negocio

Tecnología

Metas del Sprint

Sprint Backlog

Producto actual

Product Owner Equipo de Scrum Clientes

Gestión / Management


23

o El Equipo puede hacer sugerencias, pero la decisión acerca de qué

elementos del Product Backlog pueden formar parte del Sprint es

responsabilidad del Product Owner.

� El Equipo es responsable de determinar qué parte del Product Backlog,

seleccionado por el Product Owner para ese Sprint, va a tratar de implementar

durante el mismo.

� Limitar el tiempo de la Primera Parte a 4 horas significa que éste es todo el

tiempo disponible para analizar el Product Backlog. Un análisis más profundo

debe ser realizado durante el Sprint. Si el Product Backlog no es muy detallado

y está detallado en un muy alto nivel, es probable que no sea comprendido con

suficiente profundidad durante esta parte de la Reunión de Planificación del

Sprint y que, como consecuencia, el equipo no sea capaz de completar todos

los elementos del Product Backlog que seleccione.

� La Segunda Parte del Sprint Planning Meeting ocurre inmediatamente después

de la Primera y durará también 4 horas, como máximo.

� Durante la Segunda Parte, el Product Owner debe estar disponible para el

Equipo para fin de responder aquellas dudas que el Equipo pueda tener acerca

del Product Backlog.

� Es labor del Equipo actuar solamente en su propio nombre y sin ninguna

dirección externa al mismo, para encontrar durante esta Segunda Parte cómo

transformar la parte seleccionada del Product Backlog en un incremento de

funcionalidad potencialmente entregable. Nadie más tiene permiso para hacer

nada que no sea observar o preguntar para obtener más información.

� El resultado de la Segunda Parte del Sprint planning meeting es una lista –

llamada Sprint Backlog– de tareas, estimaciones de tareas y asignaciones, que

dará comienzo al trabajo del Equipo para desarrollar la funcionalidad. La lista

de tareas puede no ser exhaustiva, pero debe ser lo suficientemente completa

como para reflejar el compromiso mutuo por parte de todos los miembros del

Equipo y guiarlos durante la primera parte del Sprint, etapa en la cual el Equipo

puede encontrar más tareas a añadir en el Sprint Backlog.

2.2.4.2 Las reglas de Scrum (II): Durante el Sprint

Después de hablar de las reglas relativas al Sprint planning meeting le toca el turno a

las reglas que rigen lo que ocurre durante un Sprint:

El Sprint se limita en el tiempo a 30 días corridos. Sin considerar otros factores, ésta es

la cantidad de tiempo necesaria para que un Equipo pueda construir algo de interés

significativo para el Product Owner y los involucrados, y llevarlo a un estado en que sea

potencialmente entregable. Este es también el máximo tiempo que se puede asignar sin que el

Equipo tenga que hacer tanto trabajo que requiera artefactos y documentación para soportar su


24

proceso de razonamiento. Es también el máximo tiempo que la mayoría de los involucrados

esperarán sin perder interés en el progreso del equipo y sin perder la convicción de que el

Equipo está haciendo por ellos algo importante.

� Durante el Sprint el equipo puede buscar consejo, ayuda, información y soporte

fuera de sí mismo.

� Nadie puede proporcionar consejo, instrucciones, comentarios o dirección al

Equipo durante el Sprint. El Equipo es completamente autogestionado.

� El Equipo se compromete con el Product Backlog durante el Sprint planning

meeting. No se permite que nadie cambie el Product Backlog durante el Sprint.

El Product Backlog está “congelado” hasta el final del Sprint.

� Si se demuestra que el Sprint no es viable, el Scrum Master puede clausurarlo

e iniciar un nuevo Sprint planning meeting para comenzar un nuevo Sprint. El

Scrum Master puede hacer este cambio por voluntad propia o a pedido del

Product Owner. El Sprint puede no ser viable si la tecnología planteada no se

puede utilizar, si las condiciones del negocio cambian de manera tal que el

Sprint no le resultará de valor, o si el Equipo sufre interferencias de personas

ajenas a él mismo durante el Sprint.

� Si el equipo se siente incapaz de completar todo el Product Backlog

comprometido durante el Sprint, puede consultar con el Product Owner acerca

de qué elementos quitar del Sprint actual. Si se eliminan tantos elementos que

el Sprint pierde su valor y significado, el Scrum Master puede clausurar el

Sprint.

� Si el Equipo determina que puede abordar más Product Backlog durante el

Sprint que el seleccionado durante el Sprint planning meeting, puede consultar

al Product Owner acerca de qué elementos adicionales del Product Backlog

pueden ser añadidos al Sprint.

� Los miembros del Equipo tienen dos responsabilidades administrativas durante

el Sprint: Acudir al Daily Scrum meeting, y mantener actualizado y

públicamente disponible el Sprint Backlog. Se pueden añadir tareas nuevas al

Sprint Backlog a medida que se detecte la necesidad; asimismo, es necesario

mantener permanentemente actualizada la estimación diaria para cada tarea.

2.2.4.3 Las reglas de Scrum (III): El Sprint Review Meeting

El Sprint review meeting proporciona un punto de corte para evaluar el progreso del

proyecto al final de cada Sprint. Sobre la base de esta evaluación es posible hacer

adaptaciones en el proyecto. El Equipo estimó antes en qué punto debía encontrarse al final

del Sprint y estableció su camino hasta allí. Al final del Sprint, el equipo presenta el incremento

del producto que ha sido capaz de implementar. Los gestores, clientes, usuarios y el Product


25

Owner determinan el incremento del producto. Se escucha al Equipo acerca de lo sucedido

durante el Sprint, mientras se expone qué cosas fueron positivas y cuáles negativas. Después

de esto, estarán capacitados para tomar una decisión basada en información, acerca de qué

hacer después. En otras palabras, determinarán el mejor camino a tomar para alcanzar las

metas propuestas.

� La duración del Sprint review meeting se limita a 4 horas.

� El propósito del Sprint review meeting es que el Equipo presente al Product

Owner y a todos los involucrados, la funcionalidad que se ha completado.

Aunque el significado de "completado" puede variar de una organización a otra,

habitualmente significa que la funcionalidad está completamente desarrollada

y, potencialmente, podría ser entregada o implementada. Si "completado" tiene

otro significado, debemos estar seguros de que el Product Owner y los

involucrados lo entienden. En caso de existir más de un equipo, se realiza la

presentación por parte de cada uno.

� La funcionalidad que no está "completa" no puede ser presentada. Se destaca

el término “completa” ya que, para que cada tarea esté “completa”, debe

respetar los puntos establecidos en el principio del Sprint.

� No es posible presentar artefactos que no son funcionales no pueden ser

presentados excepto cuando se usan para mejorar el entendimiento de alguna

funcionalidad demostrada en alguna demonstración. Los artefactos no pueden

ser mostrados como productos de trabajo, y su uso debe ser minimizado para

evitar confundir a los involucrados o exigir que estos entiendan cómo funciona

el desarrollo del sistema.

� La funcionalidad deberá ser presentada en las máquinas de los miembros del

Equipo y ejecutada desde un servidor lo más parecido posible a uno de

producción; por lo general, un servidor del entorno de Aseguramiento de la

Calidad.

� El Sprint review meeting comienza con la presentación de las metas del Sprint,

el Product Backlog comprometido y el Product Backlog completado, por parte

de uno de los miembros del equipo. Los distintos miembros del equipo pueden

alternarse para comentar qué fue lo que anduvo bien y qué fue lo que anduvo

mal en el Sprint.

� La mayor parte del tiempo que insume el Sprint review meeting se utiliza para

que los miembros del Equipo encargados de presentar la funcionalidad puedan

responder a las preguntas de los involucrados y descubran los cambios que

éstos desean.

� Al final de la presentación, se les pregunta a los involucrados, uno por uno,

acerca de sus impresiones, de los cambios que desean y de la prioridad que le

otorgan a esos cambios. Por lo general, se hace con el Scrum Master, aunque


26

es preferible que se encuentre presente todo el equipo, así todos entienden

qué es lo que se quiere. Esto no debe llevar a cambios en el alcance ni a

nuevos requerimientos.

� El Product Owner discute con los involucrados y con el Equipo el potencial

cambio del Product Backlog, sobre la base de las impresiones que recibe

feedback.

� Los involucrados son libres de realizar en voz alta cualquier comentario,

observación o crítica sobre el incremento de funcionalidad potencialmente

entregable entre presentaciones.

� Los involucrados pueden identificar una funcionalidad que no ha sido

entregada o que no ha sido entregada según sus expectativas, y solicitar que

dicha funcionalidad sea incluida en el Product Backlog para su priorización.

� Los involucrados pueden identificar cualquier funcionalidad que se les ocurra

durante la presentación y solicitar que dicha funcionalidad sea añadida al

Product Backlog para su priorización.

� El Scrum Master debe intentar determinar el número de personas que se

espera que asistan al Sprint review meeting, y organizar la reunión para darles

cabida.

� Al final del Sprint review meeting, el Scrum Master anuncia al Product Owner y

a los involucrados el lugar y la fecha del siguiente Sprint review meeting.

2.2.4.4 Las reglas de Scrum (y IV): El Sprint Retrospective Meeting (Reuniones retrospectivas)

El Sprint retrospective meeting es una reunión promovida por el Scrum Master en la

cual el Equipo discute el Sprint inmediatamente anterior y determina qué se puede cambiar

para que el siguiente Sprint sea más divertido y productivo. Mientras que el Sprint review

meeting se centra en 'qué' está construyendo el Equipo, el Sprint retrospective meeting se

centra en “cómo” lo está haciendo. La motivación para realizar esta reunión es lograr la mejora

continua del proceso de desarrollo. Scrum no es una metodología prescriptiva sino un marco

metodológico que debe ser continuamente adaptado a cada proyecto, equipo o empresa.

En caso de que haya más de un equipo, lo mejor es que cada uno de ellos se reúna y

realice la tarea descripta más arriba. Luego de esto, las personas que iban a ver a los otros

equipos a la hora de la Daily Meeting se reúnen y hacen lo mismo. En caso de encontrar una

mejor manera de realizar los pasos siguientes, se tomará una decisión junto con el Scrum

Master y se la comunicará a cada uno de los equipos.

� La duración del Sprint retrospective meeting se limita a 3 horas.

� Sólo asisten el Equipo, el Scrum Master y el Product Owner (la presencia de

este último es opcional).


27

� Al comienzo de la reunión todos los miembros del equipo contestan las

siguientes preguntas: ¿Qué ha ido bien durante el último Sprint? ¿Qué se

puede mejorar en el próximo Sprint? ¿Qué fallas o problemas se encontraron?

� El Scrum Master anota las respuestas del Equipo en un formulario de resumen.

� El Equipo establece en qué orden de prioridades quiere tratar las posibles

mejoras.

� El Scrum Master no está en esta reunión para dar respuestas, sino para

facilitar la búsqueda del equipo de las mejores maneras de funcionamiento de

Scrum para ellos.

� Aquellos puntos que merezcan especial atención pueden ser añadidos al

siguiente Sprint, considerado como un Backlog no funcional de alta prioridad.

Las reuniones retrospectivas que no aportan nada, que sólo se hacen “para

cumplir” resultan frustrantes y negativas –y pueden ser un síntoma de que algo

no está funcionando bien–.

Además de esto, las reuniones retrospectivas son un excelente momento para

averiguar si Scrum está funcionando o no: bastará con escuchar al equipo, para saber si Scrum

los está ayudando o no. Si Scrum no ayuda al equipo, significa que no está funcionando. Toda

metodología que no ayude al equipo de desarrollo a trabajar mejor y con más facilidad, sufrirá

el rechazo de los desarrolladores. De esta manera, por más que se presione para que el

equipo de desarrollo utilice una metodología, si no le resulta efectiva, la rechazarán.


28

Gráfico 2.2.4.4-1 Ciclo de Scrum

Cabe destacar que, por más que se trata de respetar y cumplir todas estas reglas,

muchas veces Scrum no funciona. En general, los problemas que aparecen no son

consecuencia de las reglas escritas de Scrum sino de aquellas no-escritas. Por ejemplo: Scrum

no específica ningún proceso de software. Por lo tanto no tiene ninguna regla al respecto. Por

esta razón, el presente trabajo no se enfocó en las reglas que actualmente tiene Scrum, sino

en qué es lo que necesita para transformarla en una metodología de gestión ágil para

proyectos de software.

Product Backlog

Sprint Planning Meeting

Sprint Backlog

Fin de Sprint

Sprint Review

Sprint Retrospective

Inicio

Metas del

Sprint

Daily Scrum Meeting

24Hs – 15 a 30 min.

Cerrar Sprint. Mostrar

Demo (avances)

Cambios y

ajustes


29

2.2.5 Burn Down

Scrum tiene un gráfico típico llamado Burn Down (Hughes, 2008). Este gráfico se

muestra abiertamente a todos los que participan en el proyecto y refleja la cantidad de

requisitos del Backlog del proyecto que están pendientes al comienzo de cada Sprint.

Si se traza una línea que conecte los puntos de todos los Sprint completados,

podremos apreciar el progreso del proyecto. Así también, trazando una línea entre las tareas

de un Sprint que está en desarrollo, podemos saber de manera simple ”cómo viene” el

proyecto. Lo normal es que esta línea sea descendente (cuando “todo va bien” en el sentido de

que los requisitos fueron bien definidos desde el principio y no variaron nunca, y la estimación

se realizó de manera correcta), hasta llegar al eje horizontal, momento en el cual el proyecto se

ha terminado (no hay más requisitos pendientes, a completar en el Sprint). Si durante el

proceso se añaden nuevos requisitos, la línea mostrará una pendiente ascendente en

determinados segmentos; mientras que, si se modifican algunos requisitos, la pendiente variará

o incluso valdrá cero en algunos tramos. A continuación se presentan algunos casos como

ejemplo:

Gráfico 2.2.5-1 Burn Down detallado

Como se puede ver, en el gráfico 2.2.5-1 se permite apreciar lo que es básicamente el

Burn Down. La línea gris recta representa lo esperado, o el ideal según el cual se debe llevar a

cabo el proyecto. El eje vertical expresa el esfuerzo, o Story points calculados para el Sprint,

mientras que el eje horizontal representa el tiempo en el cual se lleva a cabo. Aparece,

además, una la línea gruesa que no se desarrolla en línea recta y representa “lo real”, lo que va

ocurriendo en el proyecto. Tal como se observa, el gráfico da una idea de cuándo puede haber

problemas (luego, si se desea, es posible identificar por medio del Sprint Backlog cuáles son

las tareas que están ocasionando problemas.


30

Gráfico 2.2.5-2 Burn Down

En el gráfico 2.2.5-2 aprecia la situación real de un Sprint en curso. La línea gris

punteada expresa lo estimado y la línea azul representa lo que ocurrió en la realidad. Antes de

comenzar el proyecto, la fecha de finalización estimada era el 12/11; sin embargo, se avanzó

más rápidamente de lo esperado, por lo que el programa prevé que, si se mantiene esa

velocidad de ejecución, ese Sprint estará terminado el 6/11.

2.2.6 Herramientas para la gestión de proyectos

Para aplicar la metodología existen varias herramientas que dan soporte a la gestión de

proyectos que utilizan metodologías ágiles. En general estas herramientas se pueden aplicar a

cualquier metodología ágil, ya que su forma en si es similar: sólo varían las reglas o procesos

que utilizan, las que no se ven reflejadas en el software.

Estas incluyen, por lo general, las siguientes funcionalidades:

� Visión general del proyecto.

� Seguimiento de control.

� Búsqueda de tareas.

� Lanzamientos por release y planificación por iteración.

� Foros internos de discusión.

� Posibilidad de describir tareas, en forma global o detallada.

� Reporte de errores, defectos y correcciones.

Muchos de estos softwares también incluyen otras herramientas, como la posibilidad de

realizar el gráfico de Burn Down según los datos disponibles del proyecto, con detalles sobre

fechas e hitos, exportación de tareas y realización de gráficos de avance, gráficos de esfuerzos

del equipo y detalle de cada miembro, realización de informes de errores, etc.


31

Algunos de los softwares más difundidos son:

� Team foundation Server.

� AccuRev.

� AgileBuddy.

� Anthill Pro.

� Bugzilla

� ScrumWorks Pro.

� Version One.

� Cruise Control.

� Electric Cloud.

� Out System.

� SubVersion.

� WorkLenz.

Estos son algunos de los muchos que existen. Varios de éstos son gratuitos o tienen

sus versiones básicas gratuitas. Otros son open source.

Además de existir software para la utilización de metodologías ágiles, también existen

formas de implementarlas manualmente, con papel, recordatorios tipo post-it, y algunos

marcadores. Otra forma es hacerlo en hojas de cálculo, utilizando sus funciones para realizar

los reportes.

2.2.7 Modelo de proceso de Scrum actual

En el gráfico 2.2.7-1 se muestra el proceso que se lleva a cabo para realizar las tareas

en Scrum, según el texto de Hunt (Hunt, 2005). Estos son los pasos a seguir si se están

aplicando correctamente las reglas de la metodología.

A dicho diagrama se le agregarán los pasos necesarios para que la metodología

ofrezca mayor calidad para terminar una tarea y más precisión en los tiempos estimados (Hunt,

2005).


32

Gráfico 2.2.7-1 Proceso actual de Scrum según reglas (Autor M. Casamayor)

Uno de los inconvenientes de este proceso consiste en que, si se agrega una nueva

tarea al Product Backlog –el cual tiene duración determinada en horas–, existe la posibilidad de

que esta tarea se sub-divida en varias sub-tareas con una duración total en horas mayor que la

original. Aunque en este diagrama no se muestra, luego de una situación como la descripta hay

que actualizar el Product Backlog para adecuarlo a la realidad.

Otro gran inconveniente que existe es que se considera que si la tarea realizada paso

los test está correctamente realizada. Sin embargo, a veces ocurre que aunque la afirmación

anterior es cierta, la calidad con que se realizó la tarea es baja. Sería necesario, pues, agregar

la condición de “buena calidad” dentro del término Done; sin embargo, esta condición

representa algo más que una propiedad.


33

3 Análisis

3.1 Análisis comparativo entre metodologías

3.1.1 Scrum versus XP

Como se sabe, existen numerosas metodologías ágiles además de Scrum. Se eligió

Scrum ya que es la metodología más conocida en mi experiencia pero, además, por ser una de

las implementadas con mayor frecuencia dentro de la gran cantidad que actualmente existe, y

por estar siendo difundida cada día en más empresas.

Scrum posee una gran cantidad de reglas que procuran la aplicación correcta de la

metodología. Las reglas dejan en claro la manera de gestionar la metodología y gestionar un

grupo. Sin embargo, hace falta conocer algo más: qué herramientas de software se han de

aplicar. Presenta además otros problemas, que con frecuencia desconciertan al usuario.

Por eso resultará del mayor interés comparar la metodología Scrum con otra

metodología ágil muy utilizada, eXtreme Programming (o “XP”). El porqué es simple, ambas

metodologías se a pesar de ser ágiles, se complementan en diferentes aspectos. Scrum se

enfoca en el control y la gestión del proyecto, mientras que XP se enfoca en los procesos,

herramientas y técnicas para desarrollar el proyecto. Si se mira lo que le hace falta a cada una,

Scrum no posee procesos, herramientas ni técnicas para el desarrollo, mientras que XP está

muy centrado en el desarrollo, sin importar tanto la gestión del proyecto.

EXtreme Programming (XP): La metodología XP es un enfoque de la ingeniería de

software formulado por Kent Beck. Kent es el autor del primer libro sobre la materia, Extreme

Programming Explained: Embrace Change (1999).

El primer proyecto llevado a cabo con esta metodología fue desarrollado en el año

1996. Es el más destacado de los procesos ágiles de desarrollo de software. Resulta exitosa

debido a su permanente búsqueda de la satisfacción del cliente. Impulsa a los desarrolladores

a responder de forma segura a los cambios propuestos por los clientes o usuarios, incluso

cuando el proyecto se encuentra en una etapa final. (Extreme Programming: A gentle

Introduction)

Otra razón para comparar Scrum con XP es que esta última no se basa tanto en reglas

acerca de cómo gestionar o qué hacer para la gestión, sino que se enfoca en aplicar bien las

herramientas que incluye por defecto. De marera simple se podría expresar así:

Scrum se enfoca en la gestión y organización del proyecto mientras que XP se enfoca,

en su mayor parte, sobre las actuales prácticas de programación

A continuación se presenta un cuadro (tabla 3.1.1-1) comparativo entre Scrum y XP:


34

Scrum XP

Documentación Requiere una documentación mínima para comenzar a construir el Product Backlog, pero luego no es profundizada.

Puede tener o no documentación. Lo principal es el desarrollo de la aplicación.

Procesos e ingeniería de software que se aplican

No se aplica ninguno en particular. Sólo especifican reglas acerca de cómo gestionar el proyecto, pero no indica nada relacionado con prácticas de ingeniería de software.

Incluye muchas prácticas de ingeniería. Por ejemplo, desarrollo manejado por tests, arreglos de errores, programación de a pares, diseños simples, etc.

Errores luego de cada Sprint y mantenimiento

Para resolverlos se aplica nuevamente Scrum, muchas veces realizando un Sprint de corrección de errores o mantenimiento. En general, no duran más de 1 semana

Se aplica lo mismo que Scrum pero durante menos tiempo ya que, en general, los errores se corrigen o el mantenimiento se realiza antes de la entrega, gracias a los tests que ya posee la metodología.

Cambios de requisitos

Son bienvenidos. En caso de que el cambio en los requisitos impacte sobre el actual Sprint, el Scrum Master puede tomar la decisión de finalizarlo, para analizar el cambio de requerimiento y estudiar sus impactos.

No está tan preparado como Scrum para los cambios de requerimientos. Igualmente los acepta, aunque en muchos casos es necesario programar nuevos Sprints para contemplar el cambio. Es por eso que esta metodología sólo se desarrolla para necesidades actuales y no tan futuras. Si el cambio es muy drástico, puede llegar a afectar el proyecto de manera significativa.

Tabla 3.1.1-1 Scrum Vs XP

3.2 Inconvenientes de Scrum

3.2.1 Inconvenientes al utilizar Scrum

Hoy en día Scrum está siendo utilizada muy ampliamente, habida cuenta de lo reciente

que es la metodología. Gracias a esto se puede encontrar más documentación acerca de cómo

utilizarla , cuáles son las debilidades e inconvenientes que presenta, y cuáles casos con los

que nos podemos enfrentar, todo lo cual ayuda a quien lo conozca, a evitar problemas e

incluso fracasos en los proyectos.

Sin embargo, también existen puntos de debilidad por el hecho de que no existen

herramientas de software preparados por defecto para la metodología, lo que conduce a que

con frecuencia se la aplique sin utilizar ninguna, sin aplicar métricas, según sea más cómodo,

aunque no resulte lo más conveniente para el proyecto. Como afirmó Dean Wampler5, “Scrum,

sin las prácticas de ingeniería no funcionará en el largo plazo.”

Es por esto que incorporar prácticas y proceso de la ingeniería de software a la

metodología Scrum daría una notable mejora. Se vería muy reflejado en proyectos en los 5 Líder técnico para equipos de desarrollo de software(www.deanwampler.com)


35

cuales la metodología nunca fue aplicada anteriormente, ya que la posibilidad de fracaso sería

menor.

Si no se cuenta con un excelente Scrum Master que guie todo el proceso, que conozca

esta metodología, sepa cómo respetar las reglas y cómo aplicar las prácticas de la ingeniería

de software, la obtención de buenos resultados será improbable.

A poco que se investigue, se observará también que son muchos los que advierten que

no recurrir a los procesos y prácticas de la ingeniería genera problemas. La solución a este

obstáculo no existe formalmente, ya que en ninguna parte de la metodología se dan

indicaciones o explicaciones acerca de esto.

De vez en cuando se ha tratado de aplicar “parches” a la metodología, adaptándole un

par de procesos con intención de mejorarla; sin embargo, al no tener la metodología reglas

básicas escritas, tampoco estas innovaciones parciales se respetan y, luego de un corto

tiempo, aparecen nuevamente dificultades en los proyectos (el tiempo estimado no es el

correcto, hay problemas de definición de requerimientos, etc.).

Entonces, ¿Qué habría que modificar para que la metodología resulte más útil? ¿Qué

respuesta dar a este problema, ya conocido pero aún sin resolver formalmente? Ese es,

precisamente, el propósito de este trabajo.

En primer lugar, se detallarán los problemas que presenta Scrum. Luego se darán

puntos claves a tener en cuenta para saber si la metodología funciona correctamente o no y,

por último, se aplicarán reglas y se le agregarán procesos de la ingeniera de software de

manera que los proyectos que la aplican tengan mayores probabilidades de éxito.

Entre los puntos a tratar para mejorar la metodología, se cuentan los siguientes:

� Cambios de requerimientos: Cómo afrontar de diferente manera los cambios

que se producen en los requerimientos, en el curso de un proyecto. Por lo

general, son excesivos y generan retrasos apreciables en su desarrollo.

� Errores de desarrollo: Ver tiempo necesario para la corrección de errores, así

como también prever los mismo con tiempos de contingencia que se agrega en

las estimaciones. También tiempos de test y otros tipos de forma para

minimizar los mismos.

� Estimación de tiempos: Se propondrán vías alternativas para estimar con

mayor precisión los tiempos asignados a las tareas.

� Equipo: Se estudiará qué perfiles resultan necesarios para llevar adelante el

proyecto con éxito. Además de los perfiles, se apreciarán las aptitudes que

pueden presentar el grupo y cada uno de sus integrantes.

� Documentación: Aunque se sabe que las metodologías ágiles están

principalmente enfocadas a mantener en marcha una aplicación antes que a

que contar con la documentación completa, frecuentemente –la mayoría de las

veces– esta última es omitida por completo. De esta forma, gran parte de los

proyectos realizados terminan con documentación inexistente. Si luego de


36

cierto tiempo de terminado el proyecto, surge un error en la aplicación o es

necesario realizar una modificación se pierde mucho tiempo en recopilar

nuevamente toda la información relativa al proyecto, más aún si las personas

que lo implementaron no están presentes.

� Calidad: Puesto que las metodologías ágiles se implementan para acelerar el

tiempo de desarrollo, muchas veces se pasan por alto las deficiencias en la

calidad debido a que alcanzar la excelencia requiere tiempo. La calidad no es

en la teoría algo negociable, pero no sucede lo mismo en la práctica. En

consecuencia, se procurará asegurar la calidad de los proyectos que utilicen la

metodología, sin menoscabo de su brevedad.

Entre las propuestas a formular se detallarán, cuando sea posible, herramientas de

software que incluyan la metodología por defecto, de forma que se agilice la aplicación de la

modificación. También se agregarán las reglas necesarias para saber de qué forma se

gestionan estas modificaciones.

3.3 ¿Qué intentamos realizar?

Hasta el momento se ha explicado las reglas, la forma en que se utiliza y las

desventajas que Scrum presenta, las cuales impactan en el proyecto, por ende en la

productividad que tiene el equipo para desarrollar el software. Cuando nos referimos al

“Equipo” en Scrum, estamos hablando del Equipo de desarrollo, el cliente, quienes definen los

requisitos.

Según el siguiente gráfico6, las oportunidades para mejorar la productividad en equipos

de diseño de sistemas se basa en varios aspectos. Cada uno de estos puntos tiene sus

factores clave. A continuación se muestran, en el gráfico, los puntos en los cuales es posible

mejorar la productividad, y cuáles de ellos serán tratados.

6 El gráfico corresponde a la mejora de productividad de software expuesta por Barry W. Boehm´s. (Boehm´s, 2007)


37

Mejoras de productividad

Obtener lo mejor de las personas

Staff

Facilidades

Gestion del personal.

Optimizar la forma de realización de las

tareas

Herramientas de software y ambientes.

Estaciones de trabajo.

Automatizaciones.

Eliminar pasos inecesarios.

Automatizar la documentación.

QA.

Automatizar la programación.

Eliminar el re trabajo.

Asistencia de softwares de

conocimientos (Wikis, documentación, etc).

Practicas modernas de programación.

Ocultamiento de la correcta información.

Desarrollos iterativos e incrementales.

Construcción de productos simples.

Modelos de procesos.

Prototipados rapidos.

Componentes y recursos.

Librerias de componentes.

Generadores de aplicaciones.

Lenguajes de 4ta generación.

Gráfico 3.3-1 Mejora de productividad de software


38

De todos estos puntos expuestos en el gráfico que antecede, sólo algunos están

comprendidos en la gestión de una metodología. Por ejemplo: la tecnología a utilizar está muy

definida, ya que se sabe que Scrum y otras varias metodologías ágiles están diseñadas para

paradigmas orientados a objetos. Esto se debe a que es posible separar muy bien el código de

cada tarea bien definida. De esta manera, resulta fácil mantener el orden y una administración

de lo realizado.

Por otro lado, hay otros aspectos mejor cubiertos por otras metodologías ágiles. La

más importante, muy utilizada y con ciertas similitudes respecto a Scrum es XP. En

consecuencia, la combinación de estas dos metodologías ágiles, nos puede ofrecer un

complemento único. Esa combinación es, precisamente, la que se describirá a continuación,

con la suma de algunos factores no tenidos en cuenta por ninguna de ambas.


39

4 Diseño

Scrum es una excelente metodología para llevar adelante proyectos de cualquier

índole, definiendo reglas para la gestión de proyectos. Sin embargo, como se explicó más

arriba, no define herramientas ni procesos para su utilización. En la comparación con la

metodología XP se observa que ambas presentan grandes similitudes. Ambas metodologías

son ágiles y abiertas a los posibles cambios que puedan surgir. La diferencia esta dada en que

XP se basa en el desarrollo, procesos y el testeo de la aplicación y el código respectivo,

mientras que Scrum se basa en la gestión del proyecto en sí.

Dado que XP tiene rasgos que complementan a Scrum, se intentó alcanzar una

integración entre ambas, dejando como punto principal la gestión del proyecto –que es lo que

realiza Scrum–, pero agregándole las reglas y objetivos propios de otros puntos que presenta

XP.

Se advierte, no obstante, que algunos de los puntos débiles de Scrum también lo son

en XP. Por ejemplo, la documentación. En consecuencia, en cuanto a este aspecto no nos

referiremos a ninguna de las dos.

A continuación se presentan puntos a tener en cuenta para saber si la metodología

funciona correctamente y las posibles mejoras de los puntos débiles de Scrum.

4.1 ¿Cómo saber si Scrum está funcionando? Puntos claves y débiles de la metodología

Cuando se comienza a aplicar la metodología Scrum por primera vez existe una

pregunta constante. ¿Cómo saber si Scrum está funcionando? (Corral, Geeks, 2008) La

verdad es que Scrum es simple, ya que se basa en sus reglas para gestionar el proyecto. En

consecuencia, si se respetan las reglas, se puede estar casi seguro de que se el proyecto está

llevando de manera correcta. De todas maneras, se necesita un período de aprendizaje, más

aún si la mayoría de los miembros del Equipo están implementando Scrum por primera vez.

Existen numerosos casos de fracasos al implementar metodologías nuevas que, por lo

general, siempre definen reglas y formas de aplicación. Esto no es ajeno a Scrum. Entonces, si

se respetan las reglas, ¿Por qué se puede fracasar utilizando Scrum?

Aquí es necesario hablar de las dificultades presentes en los equipos que la

implementan, ver qué detalles se observan y hacerlos objeto de análisis. Las principales

dificultades que surgen son generalmente las más básicas y se describen a continuación:

4.1.1 La falta de atención a los detalles

Muchos equipos fracasan en la implantación de Scrum porque no le prestan atención a

los detalles. En Scrum, los detalles son vitales. Sin la Daily Scrum, no hay Scrum. Sin Product


40

Backlog, no hay Scrum. Sin Product Owner, sin Equipo y sin Scrum Master, no hay Scrum. Sin

Sprint Planning Meeting, no hay Scrum. Sin Sprint Review, no hay Scrum.

En definitiva, sin seguir de manera estricta las reglas de Scrum, no hay Scrum. La

solución para este problema es simple: seguir rigurosamente las reglas de Scrum. Es fácil caer

en la tentación de hacer adaptaciones a la metodología para cubrir los aspectos que no son

satisfactorios en el proyecto. Sin embargo, cuando esto sucede en un equipo que es nuevo en

la metodología es probable que resulte contraproducente.

Si se contara con procesos de ingeniería de software que ayuden, las cuales se tengan

que cumplir mediante reglas de la metodología, es altamente factible que no exista necesidad

de realizar modificaciones en la metodología cuando se comienza a utilizar. Si bien es posible

realizar estas adaptaciones, no es recomendable. Es mejor volver al procedimiento normal ya

que, por lo general, luego de una adaptación que no funciona, se trata de adaptar otra cosa y

así sucesivamente, hasta que se deja de aplicar Scrum por completo. El que más atento debe

estar a todo esto es el Scrum Master.

4.1.2 Entender y formar el equipo multidisciplinari o

Construir un equipo es muy difícil y construir uno multidisciplinario aún más. Es una de

las metas que se debe alcanzar para poder lograr utilizar Scrum y es una tarea muy dura.

Un equipo multidisciplinario es muy productivo y, además, minimiza los riesgos

asociados a la rotación de personal. Los miembros de este equipo se deben llevar bien entre

sí, colaborar, y cada uno de ellos debe asumir los roles que les corresponden. Sólo de esta

manera se puede decir que esta tarea está cumplida. Además, cada integrante del equipo

debe poner la misma cantidad de esfuerzo en el proyecto. Y ninguna persona debe restar

motivación a las demás.

Cuando se va a asignar una tarea a un miembro del equipo, es necesario tratar de que

éste resulte conforme con la tarea que debe desarrollar. Es posible que esto no siempre ocurra

pero, si se puede, es lo recomendable. De esta forma, el Scrum Master logrará que, al estar

conforme con la tarea que está desarrollando, la calidad del producto de la tarea de cada uno

sea superior. Por otra parte, es importante tratar de evitar los cambios de tareas una vez que

éstas fueron iniciadas. Aunque las reglas de Scrum prohíben esto, la realidad es que ocurre

muchas veces.

Una tarea muy importante del Scrum Master es mantener al equipo constantemente

motivado. Debe encontrar la forma de hacerlo en todo momento, de modo que todos sigan

enfocados en el proyecto. Además de esto, debe mantenerse atento a cualquier detalle o

síntoma que el equipo o cualquier miembro del mismo manifieste. Algunos libros (como “Agile

Project Management with Scrum” por Ken Schwaber) ofrecen consejos recomendaciones de

suma utilidad respecto de este punto.


41

4.1.3 Crear y mantener un Product Backlog

Construir y estimar el Product Backlog es una tarea compleja. Es acá cuando se

capturan todos los requisitos de alto nivel, y es tarea del equipo de Scrum hacerlo de manera

correcta. Según mi experiencia, la captura de requisitos suele ser difícil, pero la mayor dificultad

está a la hora de mantener actualizado e ir refinándolo de manera continua.

Cuando se comienza a trabajar en las tareas del Product Backlog, por lo general

aparecen algunas tareas nuevas que no estaban previstas por desconocimiento del sistema o

del negocio, o por algún otro motivo. A veces se decide dividir estas tareas nuevas en sub-

tareas. Si estas nuevas tareas o sub-tareas no se insertan en el Product Backlog, este último

deja de ser real, ya que habrá horas trabajadas que no quedarán reflejadas en él. De esta

forma, al final del Sprint, probablemente no se alcanzará a realizar todas las tareas, a pesar

que éstas aparentemente no debían demandar más horas de las previstas. Lo mismo ocurre si

una tarea demanda más horas que las estimadas; en ese caso, éstas deben ser actualizadas

en el Product Backlog.

Por otra parte, cada vez que se realicen tareas de mantenimiento o soporte, éstas

también deberían ser agregadas en un Product Backlog. Si el proyecto es muy grande y luego

de varios Sprint queda varias tareas por implementar o corregir, se debe agregar al nuevo

Sprint o, en caso de ser necesario, armar un Sprint solo para la realización de las mismas.

4.1.4 Recursos humanos no dedicados

Muchas empresas no son capaces de mantener recursos dedicados a un proyecto. Si

no se mantienen recursos dedicados se tiene a dañar la productividad por los continuos

cambios de contexto. Muchas organizaciones pasan por alto el costo que representan los

cambios de contexto, y no lo incluyen de sus planificaciones. Sin embargo, los cambios de

contexto son el problema silencioso de muchos equipos de desarrollo.

Un equipo que es sometido continuamente a cambio de contexto, de enfoque, de

alcance, difícilmente resultará productivo. La solución a esto está fuera del alcance del equipo

de Scrum, debido a que pasa en general por culturas o situaciones de las empresas.

Según Stephen R. Covey (Covey, 1989) hoy en día las empresas e individuos tienden

a priorizar lo urgente, reemplazandolo por lo importante. Y es esto lo que se cree que sucede.

Debido a la costumbre de tratar todas las cuestiones como “prioritarias”, atendiendo en cada

momento el asunto que más “ruido” provoca y dejando de lado, con este comportamiento, a la

posibilidad de establecer una planificación razonable. Y la ausencia de esta lleva a problemas

de productividad relacionadas con la ausencia de objetivos.


42

4.1.5 Integración de las tareas de soporte y manten imiento

Existe una gran dificultad en integrar las tareas de mantenimiento con el nuevo

desarrollo, ya sea de tareas o de proyectos. En general los problemas se deben también a los

recursos no dedicados.

Aquí lo fundamental también es minimizar los cambios de contexto. Lo ideal sería que

quienes realizan mantenimiento de los proyectos pasados sea un equipo diferente al que

realiza el desarrollo de los nuevos. Por el contrario, si se trata de corrección y mantenimiento

de un proyecto reciente lo ideal es que el mismo equipo que lo desarrollo sea el encargado de

esta tarea ya que todavía se tiene en conocimiento como se desarrollo el mismo.

Sin embargo, esto no es siempre posible. Otra táctica habitual consiste repartir el día

entre actividades; por ejemplo, dedicar las mañanas para desarrollar un nuevo producto y las

tardes para las tareas de mantenimiento o soporte de versiones o productos anteriores.

Evidentemente, a la hora de planificar un Sprint, tendremos que restar de la capacidad de

nuestro equipo el esfuerzo que estimamos que será necesario dedicar a tareas de

mantenimiento y soporte.

Se debe tener en cuenta que una tarea a desarrollar a la hora de elaborar un nuevo

producto es la documentación, la cual tiene mucha importancia para el mantenimiento, como

así también para el soporte.

4.1.6 Estimación

La estimación de proyectos es una tarea compleja, este es uno de los puntos más

críticos en todo proyecto de software, ya que si no se hace se es considerablemente preciso,

puede conducirlo al fracaso.

En Scrum, al igual que en otras metodologías, la estimación es un aspecto central y se

trata de mejorarla Sprint tras Sprint. Estimamos el Product Backlog y estimamos las tareas de

cada Sprint. La estimación es el primer paso para todo el proceso de planificación, tanto a

mediano como a corto plazo. Aquí el principal problema con en el que nos encontramos es que

los equipos no tienen experiencia en estimar, sea porque nunca estimaron o porque no

conocen la tecnología o la aplicación sobre la cual van realizar un desarrollo y, por lo tanto, se

les vuelve costoso hacerlo con acierto. Esta dificultad hace que muchos equipos omitan las

actividades que Scrum propone en relación con la estimación.

Resulta imposible hacer una planificación realista sin realizar las actividades de

estimación. Ejecutar los procesos de estimación propuestos por Scrum permite obtener una

estimación realista y, además, aprovechar el propio proceso de estimación para obtener

información acerca de qué debemos y qué se pretende construir.


43

Existen muchos libros acerca de cómo estimar correctamente, algunos de ellos

redactados específicamente para metodologías ágiles8. Sin embargo, a menos que se

conozcan y se tenga idea de cuáles son las mejores técnicas a aplicar, es conveniente seguir

las pautas básicas que proporciona Scrum y aplicar métricas avanzadas para asegurarnos de

que las estimaciones realizadas son acertadas. (Schwaber, SCRUM Development Process,

pág. 18).

4.1.7 Documentación

El Manifiesto Ágil afirma que hay que preferir el software desarrollado por sobre la

documentación completa y correcta. La fórmula para analizar el retorno de inversión de Scrum

es la siguiente:

Valor Generado / Costo = RIO (Retorno de inversión) .

Este RIO se calcula por cada tarea. Consecuentemente, las principales tareas serán

aquellas que tienen un RIO mayor. Este valor producido es establecido por el cliente. Y he aquí

que la documentación, especialmente la documentación técnica, es algo que al cliente le

genera un valor nulo.

Sin embargo, este punto de vista cambia cuando piensa ve a mediano o largo plazo.

De surgir la necesidad de modificar el software desarrollado hace ya algún tiempo o de

implementar en él nuevas funcionalidades, el valor de tener una documentación clara y real es

muy alto. Porque evita perder tiempo (que implica un mayor costo) en desentrañar cómo

funciona la aplicación desde el punto de vista técnico.

Por lo general, se documentan datos básicos como métodos, alto los principales rasgos

y algunos procesos del negocio. No obstante, con frecuencia, el código fuente termina por ser

la única documentación acerca de la aplicación. Es por eso que, por lo general, se deberían

agregar tareas orientadas a documentar con sus respectivas horas, o bien agregar a la

definición de “terminado” la documentación acerca de lo realizado.

La documentación también puede ser útil para el usuario final. Aunque se piense que el

usuario aprenderá de la aplicación por medio de la experiencia, no todos proceden así. Cuando

esto sucede, es bueno disponer de documentación para el usuario, como un manual de la

aplicación, de forma que se facilite el aprendizaje. En muchas empresas esta tarea forma parte

del rol del usuario cuando reciben el producto terminado; en otras, del Área de Sistemas;

mientras que en otras no se realiza nunca.

4.1.8 Calidad

La calidad de un proyecto de software es uno de sus valores más importantes por lo

que siempre debe incorporarse. En la calidad de un proyecto intervienen todos sus

8 Agile retrospectives


44

participantes, como ser las personas que toman los requerimientos, quienes los comunican,

quienes desarrollan, etc. La forma en que hacen conocer los requerimientos, el modo en que

éstos se traducen a una forma técnica para que los desarrolladores puedan llevar a cabo el

proyecto, es algo fundamental que también requiere de un proceso, como la ingeniería de

requisitos, capaz de garantizar cierto grado de calidad y éxito.

Hay muchas formas de proporcionar calidad a lo largo de todos estos pasos. En la

realidad suele suceder que ante atrasos que surgen en un proyecto, la calidad es la primera en

ser sacrificada, apresurando la toma de requerimientos, haciendo nulos controles de cambios y

desarrollando apresuradamente sin aplicar los patrones y practicas correspondientes.

En tales momentos, es necesario recordar que, ya sea con apuro o sin él, es necesario

trabajar correctamente para darle calidad a lo realizado. Aunque no sea una tarea fácil, menos

aún si hay presión por retrasos y cuando la base de Scrum no posee prácticas de ingeniería de

software, es necesario vigilar que se trabaje lo mejor posible en este punto.

4.2 Mejora de la metodología de Scrum

Dentro de la mejora se abarcaran los principales puntos débiles de la metodología.

Estos son algunos de los antes mencionados.

4.2.1 Requisitos

Los requisitos son un tema problemático en todo proyecto, ya sea que se gestione con

una metodología ágil o no. Las metodologías ágiles se mantienen abiertas a los cambios de

requisitos o a la llegada tardía de éstos, y esto muchas veces genera problemas.

Todos los atrasos, modificaciones y reformas en los requisitos se deben por lo general

a que no se ha aplicado en ningún momento proceso alguno para la captura de aquéllos. Sin

embargo, la aplicación de la Ingeniería de Requisitos ayudaría a mejorar la captura,

minimizando los cambios, la aparición de requisitos tardíos, o su mala captura, todo lo cual

genera demoras en el desarrollo del código. A continuación se explica cómo se desarrolla la

Ingeniería de Requisitos y como se aplicaría a las metodologías ágiles.

4.2.1.1 Ingeniería de Requisitos (IE):

La Ingeniería de Requisitos constituye la conexión con las necesidades reales de los

usuarios. Consiste en un conjunto de actividades y transformaciones que pretenden

comprender a los usuarios de un sistema de software y convertir la declaración de estos

necesidades en una descripción completa, precisa y documentada de los requerimientos del

sistema siguiendo un determinado estándar.9

9 Blog de discusión acerca de la ingeniería de requisitos. (José Manuel Márquez (Docente de la Universidad de

Valladolid), 2008)


45

En Scrum los requisitos de negocio se obtienen al principio del proyecto. Con éstos se

arma el Product Backlog una vez que el cliente les asigna un valor, el cual deriva del el que le

generará una vez realizado. El equipo, por su parte, también les asigna un valor, pero en este

caso el valor representa el costo de realizarlo. De esta forma se obtiene el RIO.

Los requisitos hasta aquí mencionados son los requisitos generales del negocio. Se

seleccionan para el próximo Sprint aquellos que tengan RIO mayor y, de esta manera, el

Equipo comienza a subdividir estas tareas generales en tareas técnicas. Cuando esto sucede,

el Product Owner debería estar presente ya que, en caso de que se presente alguna duda

sobre una tarea, el Product Owner es la mejor persona para aclararla. Sin embargo, no siempre

está.

Entonces, ¿Por qué la propuesta de aplicar a Scrum la Ingeniería de Requisitos? Si se

analiza la cantidad de cambios de requisitos en un proyecto que utiliza la metodología, se

puede descubrir que el número es alarmante. Se estima que un 35% de los requisitos cambian

constantemente, y que 65% de las funcionalidades implementadas no se usan casi nunca

(Garrido, 2009). Si a esto le sumamos una toma de requisitos mediocre, la posibilidad de

cambios por mala toma es muy grande. A pesar de que la metodología da la bienvenida a

estas modificaciones, el exceso de cambios permanentes hace que el proyecto se atrase, o su

alcance varíe constantemente (Frauke Paetsch, pág. 1).

La Ingeniería de Requisitos especifica que el costo de un requisito mal especificado en

una metodología tradicional, va de un 2% a un 10% en la fase de análisis y diseño, mientras

que en la etapa de desarrollo puede llegar a costar entre 5 a 100 veces más del total

previsto.10

En Scrum, los cambios de requisitos pueden llegar cuando el requisito afectado fue

desarrollado, está siendo desarrollado o todavía no fue desarrollado. Cuando los cambios de

requisitos impactan sobre elementos ya desarrollados o que están en proceso de desarrollo, el

costo es mayor. A pesar de que estos cambios de requisitos impactan sobre el desarrollo y, en

consecuencia, sobre el tiempo restante para la finalización del proyecto, muy pocas veces

existe la intención de mover la fecha de finalización o de reducir el alcance del proyecto. Este

es el punto en el cual, dadas las circunstancias, se comienza desarrollar con apresuramiento.

La atención del Equipo en tales momentos no suele ponerse en evaluar si lo que se cambió o

lo que se realizará es o no totalmente correcto, sino en qué es lo que hay que finalizar con

mayor urgencia. Este error conduce comúnmente a que la necesidad de hacer nuevos

cambios, generando aún mayores retrasos. Cabe destacar que, además de retrasos, la

situación genera también un desgaste en el Equipo.

Muchas veces este factor depende del Scrum Master. Sin embargo, sse implementa de

manera eficiente la Ingeniería de Requisitos los miembros del Equipo podrán confiar en que los

10

Dato obtenido del grupo de investigación Kybele (Carlos)


46

requisitos que se van a desarrollar son los correctos, evitándose de esta forma tener que

corregir en un futuro el sistema a raíz de malos entendidos.

Tomar erróneamente los requisitos erróneos y advertirlo luego de realizado el

desarrollo son dos hechos que nunca deberían suceder según Scrum, ya que el Product Owner

debería estar acompañando el desarrollo del proyecto constantemente. Sin embargo, la

realidad es algo diferente. En general, es prácticamente imposible que el Product Owner esté el

100% del tiempo con el equipo de desarrollo, por lo cual la tarea de comprender cabalmente

los requisitos continua siendo responsabilidad del Scrum Master.

Algunas técnicas para la toma de requisitos que se pueden aplicar son las siguientes:

� JAD (Joint Application Development): es una técnica popular que consiste

en incluir a los usuarios como participantes activos en el desarrollo del

software.

Durante las sesiones de JAD, los desarrolladores y los usuarios revisan y

ponen en claro las características de la aplicación. Este tipo de charlas o

encuentros suelen ser muy productivos si durante la sesión se logra evitar que

la conversación se desvíe del tema principal. El objetivo de JAD es definir un

proyecto especifico en diferentes niveles de detalles, diseñar una solución y

monitorear el proyecto hasta que esté terminado. Los participantes son jefes,

líderes de proyectos, usuarios, expertos en sistemas y desarrolladores. De esta

manera, se cuenta con múltiples puntos de vista, lo cual permite hacer un

sistema más específico, con menos probabilidades a fallar a causa de una

mala definición de los requisitos.

� Modelado: El Modelado de Sistemas es un importante paso entre el análisis y

el proceso de diseño. Algunos métodos aplican diferentes técnicas de

modelado para describir los requerimientos de los sistemas. Las técnicas más

conocidas son los Modelos de Flujo de Datos, los Modelos de Datos

Semánticos y los Modelos Orientados a Objetos. Aplicar alguna de estas

técnicas puede ayudar a entender mejor los requisitos.

� Documentación: El propósito de la Documentación de Requisitos es lograr

que éstos sean comunicados entre los interesados o dueños del proyecto y los

desarrolladores. La Documentación de Requisitos es la línea de base para

evaluar posibles futuros productos y procesos del sistema (documentación de

diseño, testing, verificación y validación de actividades) y para el control de

cambios. Una buena documentación en una metodología ágil debería tener

datos claves del negocio, modelado del mismo (ya que sin este en general es

muy difícil ver la complejidad de la aplicación a desarrollar), y documentación

de código, el cual no lleva mucho tiempo.


47

� Validación: El propósito de la Validación de Requisitos es verificar que la

descripción de los mismos resulta aceptable para su implementación. La

entrada de datos para el proceso de validación es la documentación de los

requisitos, estándares organizacionales y el conocimiento organizacional. La

salida es una lista que contiene los problemas reportados con la

documentación de los requisitos y las acciones necesarias para abarcar los

errores reportados.

Las técnicas utilizadas para la validación de requisitos son la revisión de

requisitos y el testing de los mismos.

4.2.1.2 En qué podría mejorar Scrum con IE

La mejora particular que experimentaría Scrum con la aplicación de la Ingeniería de

Requisitos se ve reflejada en varios de los puntos puestos a mejorar, a pesar de que muchos

partidarios de las metodologías ágiles se niegan a aplicar este tipo de procesos alegando que

representan una pérdida de tiempo. En realidad, si se aplica la Ingeniería de Requisitos tal

como es, resultaría demasiado estructurada para la metodología pudiera seguir siendo

considerada ágil.

Sin embargo, aplicarla de manera no tan rígida ni profunda generaría una mejora

fundamental (Requirements Engineering and Agile Software Development, 2003).

El Product Backlog juega un papel muy importante en Scrum. Todos los requisitos y

elementos útiles que aportan valor al proyecto están aquí. Contiene una lista priorizada de

todas las necesidades, funciones, errores y mejoras que hay que realizar o fueron realizadas.

Todo esto se comparar con una lista incompleta y cambiante de requisitos, que contiene

información para el desarrollo y para el futuro de la aplicación también.

Las metodologías ágiles tienen la ventaja que el cliente se encuentra, en general,

participando constantemente en el proyecto. Entonces se puede mejorar la obtención de

requisitos de las siguientes maneras:

Modelado del proyecto: En la Ingeniería de Requisitos se realizan modelos en los

diferentes niveles de análisis y diseño, de manera de realizar una abstracción de la aplicación.

Por lo general, todos estos modelos terminan por ser parte de la documentación del sistema.

Es por eso que modelar de forma un poco más profunda cada iteración resultaría fundamental,

evitando quedarse con el análisis básico del Product Owner para luego ponerse a desarrollar.

Documentación: Para comenzar el proyecto, Scrum necesita cierto nivel de

documentación que exprese de qué se trata cada tarea. Sin embargo, el grado de detalle de

estas descripciones suele ser pobre, permitiendo traslucir una idea de lo que se debía hacer sin

transmitir lo que se hizo y de qué manera.

La documentación se utiliza para compartir conocimiento entre las personas. Por

ejemplo: si se incorpora un nuevo miembro al equipo, probablemente tendrá muchas preguntas

que hacer, la mayoría de las cuales encontrarán respuesta en una buena documentación, sin


48

necesidad de utilizar el valioso tiempo de otros miembros del grupo. Además, la buena

documentación reduce el riesgo de pérdida de información cuando algún integrante del Equipo

deja de ocupar su puesto.

Por lo general, esta clase de problemas se manifiestan en el mediano o el largo plazo.

La necesidad de documentación aparece cuando el cliente consulta acerca de un tema y la

persona que lo desarrolló no se encuentra presente o disponible.

Una documentación significativa en Scrum debe incluir documentación de código (con

herramientas como “Javadoc”), documentación de negocio de las tareas, cambios de requisitos

y modelados realizados. Estas son tareas que no consumen prácticamente nada de tiempo si

se va realizando a medida que se realizan las tareas. Y el resultado final es una documentación

solida y útil para un futuro.

Gestión de cambios: La Ingeniería de Requisitos establece que debería ser posible

rastrear los cambios de requisitos, diseño o documentación, a fin de conocer la razón de estos

cambios. Hacer posible esta trazabilidad en los requerimientos, enriquece mucho el aspecto

relacionado con la documentación y es algo que no demanda mucho tiempo.

Aunque muchas herramientas para la gestión de metodologías ágiles –tales como Jira,

Bugzilla, Version One– ofrecen esta posibilidad, son pocos los Equipos que utilizan estas

ventajas que los programas ofrecen. Sin embargo, éste es un punto en el cual la aplicación una

buena práctica puede llegar a significar una gran diferencia en poco tiempo.

En Scrum, el Product Backlog se maneja por versiones, eliminándose por lo general las

versiones más antiguas. Esto debería dejar de ser así ya que mantener las versiones

superadas permite rastrear los cambios en los requerimientos.

4.2.2 El equipo:

4.2.2.1 El Product Owner

Scrum es una metodología que otorga prioridad y valor al Equipo, por sobre todas las

cosas. Este Equipo debe ser multidisciplinario, sin distinción entre el grupo de desarrolladores,

el grupo de analistas, etc. Por lo tanto, es probable que a cada miembro le toque realizar tareas

diferentes, para algunas de las cuales podría no estar tan preparado.

El Equipo debe mantenerse lo más unido posible. La unificación del Equipo permite que

el proyecto tenga una mejor “salud”, debido a la mayor comunicación que existe entre cada uno

de sus miembros. Esto incluye también al Scrum Master y al Product Owner.

Por definición, Scrum pide que el Product Owner sea un miembro más, que permanece

constantemente con el Equipo. Este mandato no siempre se lleva a la práctica debido a que

esta persona suele tener responsabilidades que dificultan cumplir lo prescripto por Scrum. Y el

hecho de que el Product Owner no se encuentra siempre con su equipo como debería, acarrea

problemas en la definición de requisitos.


49

La solución a este problema reside en entender que lo pedido por Scrum es algo ideal.

Al mismo tiempo, asimilar la idea de que el Product Owner no un miembro del Equipo, si no

alguien que le proporciona soporte y definiciones. Comprenderlo así permitiría tomar los

requisitos con cierta cautela, ya que siempre se asume que, si se presenta un error, el Product

Owner tiene la razón porque se trata de su sistema.

4.2.2.2 Esfuerzos Individuales

Por lo general, al principio cuesta que todos los miembros del Equipo pongan el mismo

esfuerzo. Con frecuencia uno de ellos sobresale en este aspecto y, luego de unos pocos días o

semanas, el resto comienza a seguirlo.

El problema es que algunos individuos terminan de adaptarse y se limitan a realizar lo

que ellos consideran un nivel de esfuerzo “correcto”. En estos casos, el Scrum Master debería

identificarlos y tomar una decisión al respecto, ya que muchas veces también este individuo o

individuos pueden llevar a otras personas a hacer lo mismo, de manera que la desmotivación y

las pocas ganas de trabajar se extienden al resto, la metodología no se aplica de manera

correcta y la tarea no se cumple en los plazos previstos.

Por otro lado, algunos indicios permiten prever cuándo una persona, un grupo de

personas o el equipo no van a “funcionar”. Por ejemplo: si el equipo no se comunica, si hay

poca interacción o retrospectiva en las reuniones diarias, significa que pronto puede

presentarse un problema.

Que existan retrasos es algo posible. Puede ocurrir que una tarea nos lleve un poco

más de tiempo de lo estimado. Sin embargo, existen casos en que una persona demora en

realizar una tarea el triple del tiempo estimado. Esto puede ser un indicio de problema. El

Scrum Master debe detectar rápidamente estos casos e investigar si el problema surgió a raíz

de una complicación al realizar la tarea, si la persona que la llevó o lleva a cabo carece de los

conocimientos necesarios, o si no está participando ni trabajando como corresponde. En este

último caso, es necesario conversar con este miembro del Equipo para averiguar qué le

sucede, ya que una persona que no esté motivada no sirve al grupo.

Situaciones de este tipo se pueden prever si el equipo y el Scrum Master están

antentos. Scrum es eficiente si el Equipo lo es. Y para serlo se necesita un Scrum Master

excelente, que pueda llevar motivado a un Equipo a realizar las tareas.

Situaciones como la descripta –y otras análogas que pueden llegar prsentarse– son

signos que permiten anticipar problemas.

Una buena forma de aprender a gestionar equipos e incorporar pautas acerca de cómo

se aplican, son los que se obtienen del libro “Agile Retrospectives: Making Good Teams Great”

por Esther Derby, Diana Larsen y Ken Schwaber, donde se describen pautas muy útiles, fáciles

de aplciar en todo momento11.

11

Libro enfocado a la motivación del Equipo en proyectos con metodologías ágiles.


50

4.2.3 Desarrollo

Si para el desarrollo de la aplicación se toma como referencia XP, al momento de

desarrollar es posible utilizar las prácticas que ésta implementa.

4.2.3.1 Test Driver Development (TDD)

Test Driver Development es la práctica que consiste en escribir un test automático y,

luego, escribir el código suficiente para que el test resulte “positivo”. A continuación, se

refactoriza el código para mejorar su legibilidad y eliminar duplicaciones (Henrik Kniberg, 2007)

(Beck, 2003). Esto ayuda a mantener el código fuente legible, correcto y no duplicado.

De manera análoga, encontramos en Java la utilidad JUnit. Este tipo de utilidades

permite además, luego de desarrollar más módulos de código para una aplicación, correr todos

los test. De esta manera, sabremos si hay alguna falla que corregir.

Esto acelera los ciclos de desarrollo, compilación y pruebas. Al mismo tiempo, actúa

como una red de seguridad, proporcionando a los desarrolladores la confianza necesaria para

refactorizar y mantener el código limpio y simple mientras el sistema crece.

TDD en código nuevo:

Se hace TDD para todos los desarrollos nuevos, incluso si eso implica que el arranque

del proyecto tardará más tiempo ya que, no obstante, esta práctica traerá beneficios muy

grandes en el futuro.

TDD en código viejo:

Se intenta hacer el TDD sobre la base del código. Cuando hay una base que no tiene

TDD desde el principio, la tarea resulta algo más difícil habida cuenta de que es posible que no

se conozca cómo probar ciertas partes del código, no haya documentación acerca de cómo

hacerlo o cómo se realizaba, o que los creadores de esos módulos no estén más.

Aunque esta tarea resulta muy difícil, finalmente quedará demostrado que valió la pena.

De esta manera cada vez que se desee probar la aplicación, habrá formas de asegurar que su

base está en correcto funcionamiento. Mucho más si se trata un sistema antiguo, para el cual la

base será, seguramente, lo más importante.

4.2.3.2 Pair Programming

En muchos equipos esta modalidad no está muy adaptada. Sin embargo, se ha

demostrado que no se pierde el doble de tiempo para una misma tarea sino que sirve para

ganar conocimiento y resolver las formas de manera más inteligente, generando calidad,

ahorrando esfuerzo, etc.

Algunas conclusiones sacadas de equipos que lo aplicaron (Henrik Kniberg, 2007) son

las siguientes:

� La programación por parejas mejora efectivamente la calidad del código.


51

� La programación por parejas mejora efectivamente la concentración del Equipo

(por ejemplo, cuando una persona está realizando la tarea y se pregunta si lo

que se está realizando es realmente necesario para este Sprint).

� Sorprendentemente, muchos de los desarrolladores que están en totalmente

en contra de la programación por parejas ni siquiera la han probado, pero

comienzan a apreciarla rápidamente una vez que la prueban.

� La programación por parejas resulta agotadora y no debería realizarse durante

todo el día.

� Es bueno cambiar de parejas frecuentemente. La programación por parejas

mejora efectivamente la distribución de conocimiento entre los miembros del

Equipo, de manera sorprendentemente rápida.

� Algunas personas simplemente no se sienten a gusto haciendo programación

por parejas. No obstante, no hay que prescindir de un programador excelente

por el solo hecho de que no se siente a gusto programando por parejas.

� La revisión de código es una alternativa aceptable a la programación por

parejas.

� El “navegante” (la persona que no usa el teclado) debería tener también un

ordenador propio. No para desarrollar, pero sí para hacer pequeñas tareas

cuando sea necesario, consultar documentación si el “piloto” (quien que usa el

teclado) se atasca, etc.

� No es bueno presionar al personal para que realice programación por parejas.

Es mejor animar a las personas y proporcionales las herramientas adecuadas,

permitiéndoles experimentar con esta forma de programación a su propio ritmo.

Por lo tanto, podemos afirmar que la programación por parejas ayuda a mejorar la

calidad, a optimizar los plazos de desarrollo, a aumentar la capacitación acerca del sistema, las

metodologías, prácticas y paradigmas entre los desarrolladores, todo lo cual hace conveniente

su aplicación en el desarrollo ágil de sistemas.

4.2.3.3 Diseño incremental

Esta práctica supone mantener el diseño simple desde el principio y mejorarlo

continuamente, en lugar de pretender que todo funcione desde el principio para entonces

“congelarlo”.

Si, en lugar de plantear un diseño único al principio –lo cual exigirá demorarse en el

análisis de todas las variantes posibles–, se invierte una cantidad razonable de tiempo en

refactorizar y mejorar los diseños existentes, se acortará el plazo de desarrollo del proyecto.

En algunos casos existen ciertos riesgos. Por ejemplo, cuando un diseño inestable está

fuertemente ligado a la aplicación, por lo que la refactorización y mejora del mismo es

prácticamente un proyecto en sí mismo. No obstante, es un esfuerzo que muchas veces vale la

pena.


52

En particular, afirmamos que la mejora continua del diseño es un beneficio secundario

inmediato de la aplicación de TDD.

4.2.3.4 Integración continua

Muchísimos sistema de software cuentan con un sofisticado entorno de integración. Por

esa razón en la actualidad existen sistemas para automatizarlo, tales como Maven o

QuickBuild. Esto resulta extremadamente valioso y ahorra muchísimo tiempo. De esta manera,

se soluciona el típico problema: “–Si en mi maquina funciona… ¿Por qué no funciona en esta

otra?”

Cada vez que alguien chequea algo en el sistema de control de versiones, el servidor

de compilación continua arranca, compila todo desde cero en un servidor compartido y corre

todas las pruebas. Si algo va mal, notifica por correo electrónico a todo el equipo que la

compilación ha fallado, incluyendo información acerca de qué parte exactamente del código

falló la compilación, enlaces a los informes de prueba, etc.

Todos los días el servidor de compilación continua reconstruye el producto desde cero

y envía los binarios o compilados, la documentación, los informes de pruebas, los informes de

cobertura de pruebas, los informes de dependencias, etc., a una URL propia del proyecto de

documentación. Algunos productos también se instalarán automáticamente en un entorno de

pruebas.

Montar un sistema como éste implica un trabajo inicial; sin embargo, este esfuerzo

resulta de gran utilidad para todos los proyectos que se realizarán luego, ya que todos ellos

pueden trabajar conjuntamente, despreocupados respecto de problemas de versiones, de por

qué no funciona en una máquina y en otra sí, etc.

4.2.3.5 Propiedad colectiva del código

Si bien se apoya el concepto de propiedad colectiva del código, no todos los equipos lo

han adoptado aún. Hemos encontrado que la programación por parejas con una rotación

frecuente de las parejas conduce a un nivel elevado de propiedad colectiva del código.

Los equipos que tienen un alto nivel de propiedad colectiva del código han demostrado

ser muy sólidos. Por ejemplo, sus Sprints no fallan simplemente porque una persona clave esté

enferma.

4.2.3.6 Ambiente de trabajo informativo

Todos los equipos tienen acceso a pizarras y espacios vacíos en las paredes, y hacen

buen uso de ellos. En la mayoría de los lugares de trabajo las paredes se ven cubiertas con

toda clase de información acerca del producto y el proyecto. Un problema que esto plantea es

la acumulación de información vieja sobre las paredes. Por eso, para que esta práctica resulte

útil, alguien debe ocuparse de mantener actualizada esta información, haciendo limpieza de la

información vieja y remplazándola por la vigente.


53

No obstante, si bien se promueve el uso de paneles de tareas, pero no todos los

equipos lo han adoptado todavía. (Ver “Cómo distribuimos la Sala del Equipo”.)

4.2.3.7 Estándares de codificación

La definición de estándares de codificación es algo muy útil y siempre conviene

realizarla cuanto antes. Prácticamente no cuesta nada en términos de tiempo: se trata de

comenzar con algo simple, que vaya creciendo con el tiempo. Se debe escribir únicamente

material que no sea obvio y que, dentro de lo posible, esté relacionado con el material

existente.

La mayoría de los programadores tienen su estilo de programación propio y distintivo.

Pequeños detalles como la forma en la que tratan las excepciones, cómo comentan el código,

cuándo devuelven un valor nulo, etc. En algunos casos, estas diferencias no importan; en

otros, sin embargo, pueden conducir a una severa inconsistencia en el diseño del sistema y a

un código difícil de leer. Un estándar de codificación ayuda a que esto no ocurra

invariablemente.

Cada tecnología tiene sus estándares básicos, por lo cual su aplicación depende de

todo el equipo y es necesario ponerse de acuerdo para buscar, adoptar y mantener un

estándar común.

4.2.3.8 Ritmo sostenido

Mucha bibliografía sobre desarrollo ágil de software afirma que las jornadas extendidas

son contraproducentes para el desarrollo de software. Una experiencia que figura en un libro

(Henrik Kniberg, 2007) nos cuenta lo siguiente:

Hace cosa de un año, uno de nuestros equipos (el más grande) estaba

trabajando un número insalubre de horas extra. La calidad de la base de código era

pésima y habían pasado la mayor parte del tiempo “apagando incendios”. El equipo de

pruebas (que también estaba haciendo horas extra) no tenía ninguna posibilidad de

hacer aseguramiento de la calidad en esas condiciones. Nuestros usuarios estaban

enojados y la prensa nos estaba comiendo vivos.

Después de unos meses, conseguimos disminuir las horas de trabajo a un nivel

decente. La gente comenzó a trabajar en horarios normales (excepto durante algunas

crisis de proyecto, a veces). Y, oh sorpresa, la productividad y la calidad mejoraron

notablemente.

Por supuesto, reducir las horas de trabajo no fue en absoluto el único aspecto

que condujo a la mejora, pero todos estamos convencidos de que tuvo mucho que ver.

De esta manera, se puede apreciar que el resultado del trabajo no depende de la

cantidad de horas que se aplique al proyecto, sino la calidad que confiere durante ese tiempo.


54

Si un equipo trabaja muy forzado, bajo mucha presión, sin ver resultados y encontrando cada

vez más problemas, es probable que intente hacer las cosas lo más rápido posible, con calidad

nula, haciendo que la corrección de problemas sea un parche, antes que una corrección bien

hecha. Esto termina generando un código malo y hace también que el ambiente de trabajo no

sea el mejor.

4.2.4 Calidad

Aunque Scrum y XP mencionan que los proyectos tienen que ser de buena calidad,

superiores a lo que el cliente exige, una forma de asegurarnos es aplicar QA.

4.2.4.1 Quality Assurance (QA)

El termino Quality Assurance o QA (Thomas Pyzdek, 2003) (Jeff Tian, 2005) se refiere

a proceso sistemático de producción que provee la seguridad de que un producto es el

adecuado y correcto para lo que se necesita. Consisten en un conjunto de actividades con el

propósito de asegurar que el cliente quedará satisfecho con lo que se realiza o lo que se va a

realizar. Por lo tanto, QA se aplica no sólo al proceso final, cuando el proyecto está terminado,

sino también en la etapa de obtención de los requisitos. Sin embargo, si bien QA mejora la

calidad, su aplicación no garantiza un producto de calidad.

La calidad es un conjunto de propiedades esenciales a un objeto que le dan capacidad

para satisfacer necesidades implícitas o explícitas. La calidad de un producto o servicio es la

percepción que el cliente tiene del mismo; es un juicio del consumidor que asume conformidad

con dicho producto o servicio y con la capacidad del mismo para satisfacer sus necesidades.

Por tanto, debe definirse en el contexto que se esté considerando; por ejemplo, la calidad del

servicio postal, del servicio dental, del un producto con una finalidad, de vida.

En consecuencia, la calidad de un sistema o servicio informático es muy importante y

necesaria, ya se trate de un producto que se vendió o de un recurso para lograr un avance en

una empresa. Se sabe que contratar personal para realizar QA resulta costoso; sin embargo,

este costo no es excesivo si se considera a largo plazo y garantiza una mayor satisfacción del

cliente, además de una menor probabilidad de fracaso del proyecto.

Scrum nada dice acerca de personal para garantizar la calidad en el proyecto, pero

pretende que las cosas se hagan con calidad. La experiencia me ha demostrado que existe

una gran diferencia entre tener y no tener una persona dedicada a QA. Siempre que se trabajó

con personas de QA, aunque sea una sola en el equipo, las cosas parecían terminar de mejor

manera; aunque tal vez se descubrían más errores, el cliente quedó siempre mucho más

satisfecho.

El QA se puede aplicar como una herramienta de ingeniería, de manera que no pueda

existir forma de no aplicarla. De esta forma, el costo de implementar Scrum en términos

económicos sería mayor, pero se podría garantizar mejor el éxito del proyecto, y la mayor


55

satisfacción del cliente. Esto es lo que Scrum plantea en principio: satisfacer al cliente, ofrecerle

un mejor producto antes que documentación. En consecuencia, desde cualquier perspectiva,

aplicar QA en la metodología es lo mejor que se puede hacer.

4.2.4.2 Por qué la calidad no es negociable

La calidad se puede considerar desde dos puntos de vista: calidad interna y calidad

externa (Henrik Kniberg, 2007).

� Calidad externa: es lo que perciben los usuarios del sistema. Una interfaz de

usuario lenta y poco intuitiva es un ejemplo de baja calidad externa.

� Calidad interna: se refiere a aquellos aspectos que normalmente no son

visibles para el usuario, pero que tienen un fuerte efecto sobre la posibilidad del

mantenimiento del sistema. Incluye aspectos como la consistencia del diseño

del sistema, la cobertura de pruebas, la legibilidad del código, la

refactorización, etc.

En líneas generales, un sistema con alta calidad interna puede, aun así, tener una baja

calidad externa. Pero un sistema con baja calidad interna rara vez tendrá buena calidad

externa ya que resulta difícil construir algo sólido sobre malos cimientos.

La calidad externa se trata como parte del alcance. En algunos casos puede tener

sentido, desde el punto de vista de negocio, liberar una versión del producto que sea lenta y sin

mucha estética visual, y más tarde liberar una versión mejorada. Aun así, se trata de un

aspecto relacionado con el alcance de un proyecto que su dueño debe decidir.

Sin embargo, la calidad interna es algo que no se puede discutir. Es responsabilidad

del Equipo mantener la calidad del sistema bajo toda circunstancia y, simplemente, no es

negociable.

Una gran pregunta suele ser cómo diferenciar la calidad interna de la externa en un

proyecto. Supongamos que el Dueño de Producto aprueba estimaciones de valor de 6 tory

points, pero dice estar seguro de que se podría haber alguna forma rápida para hacerlo en la

mitad del tiempo, si lo piensan mejor. Esto puede convertirse en un gran problema, porque se

pretende las cosas más rápido, en desmedro de la calidad interna. No siempre es así y hay que

hacer un análisis, pero se podrá reducir la estimación si el análisis es correcto.

El sacrificio de la calidad interna es en la práctica una muy mala idea. El tiempo que se

ahorra es mucho menor que el costo, tanto a corto como a largo plazo. Si se permite que una

base de código comience a deteriorarse, resultará muy difícil recuperar su calidad original más

adelante.

Si es muy importante la entrega inmediata del producto, se puede optar por reducir el

alcance del proyecto en lugar de reducir el tiempo de desarrollo.

Una vez que el dueño y el Equipo de desarrollo aprenden que la calidad no es

negociable, se descubren otras formas de reducir plazos, alcance y demás variables para

poder realizar el proyecto en tiempo y con calidad.


56

4.2.5 Diagrama de función de Scrum para tareas

Según el gráfico 2.2.7-1 la metodología no posee por defecto QA, test, aunque se

pueden agregar, al igual que la actualización de tareas, las cuales se deben realizar siempre.

Luego de presentar las modificaciones necesarias en la metodología, se vuelve a definir el

diagrama de función para llevar a cabo las tareas y gestionar la metodología de manera

diferente.

En el gráfico 4.1.6-1 se presenta el nuevo esquema:

Gráfico 4.1.6-1 Scrum enfocado a proyectos informáti cos - Autor: Martín Casamayor.


57

4.2.6 Nuevas Reglas

Tal como se dijo, primero se implementarán reglas. Estas reglas servirán para poder

saber cuándo se podrá cambiar los procesos o herramientas de ingeniería de software tratando

de esta manera que siempre se esté aplicando alguna. En caso de no funcionar con las que

traerá por defecto, tener alternativas, tratamientos de problemas generales y demás

eventualidades que puedan suceder.

Cabe destacar que estas reglas están pensadas para lograr un mejor funcionamiento

de la metodología. Como en el caso de las reglas anteriores, Éstas pueden ser modificadas

siempre y cuando haya una razón importante que, de no resolverse, impida el avance del

proyecto.

Las reglas nuevas tienen como objetivo respetar las herramientas de la ingeniera que

se acaban de presentar. También explican cuándo se pueden modificar las mismas en caso

que exista la necesidad. A continuación se presentan las nuevas reglas para el mejoramiento

de Scrum.

4.2.6.1 Las reglas de Scrum (VI): Procesos y herramientas de ingeniería de software

La metodología cuenta con reglas acerca de cómo hacer funcionar, cumplir y

eventualmente modificar los procesos y herramientas con los que cuenta. Estas se deben

respetar según indique cada herramienta o proceso, haciendo que se cumplan tanto las reglas

dictadas a continuación como las propias de cada proceso o herramienta.

� La metodología cuenta con procesos y herramientas de ingeniería de software

que son necesarias aplicar. Son las siguientes:

o Ingeniería de Requisitos: Se deberá aplicar Ingeniería de Requisitos

para la etapa de armado del Product Backlog y el Sprint Planning. Se

deberá aplicar siempre.

o Cambios de Requisitos: Se deberá llevar control de los cambios,

aplicando gestión de cambios de requisitos. Al aparecer un cambio de

requisito el Scrum Master deberá evaluar el RIO del mismo. Si tiene un

RIO importante, deberá considerar de congelar el Sprint, ver que

impactos tiene en las tareas que se están desarrollando y volver a

armar un Sprint con estos cambios.

o Pair Programming: En los casos que haya miembros del Equipo con

poca experiencia, los miembros de mayor experiencia deberán trabajar

según el modelo de Pair Programming durante los dos primeros

Sprints, dos veces por semana durante tres hora diarias. De esta

forma, los de menor experiencia adquirirán nuevos conocimiento más

rápidamente.


58

o Test Driven Development (TDD): se deberá aplicar en todo momento

mientras se desarrolle código, ya se trate del desarrollo de un código

nuevo o de la modificación de un código viejo.

o QA: Un miembro del Equipo debe ser especialista en QA. Esto ayudará

a que el cliente quede más satisfecho con lo que se va realizando y a

asegurar la factibilidad del proyecto.

o Documentación: Se deberá preparar la documentación y ésta no

deberá limitarse al código fuente. La documentación se deberá aplicar

en el Product Backlog. Aquí por cada tarea se deberá comentar que

fue lo que se conocía antes de comenzar la tarea, y eventualidades

que sucedan durante la realización de la misma. También se deberá

documentar el código con herramientas como “Javadoc”.

� Para poder modificar los procesos o herramientas que existen, es necesario

contar con la aprobación de la mayoría del Equipo, es decir el Scrum Master y

todos sus integrantes. Además de la aprobación del Equipo, debe existir una

lógica de cambio y también determinar cuál es la mejor alternativa. El cambio

de herramientas, por su parte, requiere una experiencia razonable, no sólo

porque no resulta “cómodo”. Si no se cuenta con suficiente experiencia, la

aparente necesidad de cambiar la herramienta puede deberse a que se ignora,

en realidad, cómo aplicarla.

� Una vez modificadas, se deberá agregar a las preguntas básicas si se notaron

cambios de metodología y si funciona o no, sin entrar en muchos detalles. En

caso de existir una suma urgencia por el cambio y éste requiera de más tiempo

se organizará una nueva reunión llamada Tools Meeting. En ésta deberán estar

presentes todos los miembros del Equipo y también el Scrum Master. En ella

se debaten qué problemas se plantean con las nuevas herramientas o

procesos que existen en la metodología, si ha habido mejoras. Esta reunión no

deberá durar más de una hora, de forma que se defina rápidamente qué lo

mejor que se puede hacer a continuación.

� Una vez decidido el cambio de una metodología, el Scrum Master deberá dar a

conocer a los integrantes del Equipo cómo aplicarla, buscando datos básicos,

mejores prácticas, etc. De esta forma, logrará que todos se informen lo mejor

posible respecto de la metodología nueva.

� Si hubo Sprints que no lograron su objetivo y el Equipo se siente

decepcionado, un recurso útil consiste en aplicar nuevas ideas. Cada

integrante es convocado a dar nuevas ideas, comentando su experiencia y

expresando qué le gustaría cambiar. Una vez conocido lo que cada uno piensa,

entre todos elegirán las tres mejores ideas para aplicarlas en el próximo Sprint.

La elección se hará de este modo: que cada integrante expresará cuáles son a


59

su juicio las dos mejores ideas; las seleccionadas serán las que acumulen

mayor puntaje.

� Cuando se quieran encontrar formas nuevas de pensar soluciones, suele

resultar productivo cambiar de lugar de la reunión. Ir a nuevos lugares ayuda a

pensar en cosas nuevas. De esta forma pueden aparecer nuevas soluciones.

� Agregar a la definición de Done (Terminado) de las tareas, por defecto, Test.

Estos tests son de programación. Una tarea testeada garantiza mayor calidad.

De esta manera, en futuras entregas, sólo será necesario correr los tests para

saber si continúan funcionando de manera adecuada.


60

5 Conclusión

Las metodologías ágiles se están difundiendo día tras día. De esta forma, Scrum

también se vuelve más popular. Muchas personas que nunca utilizaron metodologías ágiles –

mucho menos Scrum– comenzarán a gestionar sus proyectos con estas metodologías, sin

poseer experiencia previa. Esta inexperiencia puede llevar a que el costo de adaptación sea

alto debido a que en principio, probablemente, requiera mucho esfuerzo. También es posible

que se produzcan problemas al momento de gestionarla.

Esto es lo que lleva generalmente a utilizar Scrum adaptando reglas, cometiendo

errores que son comunes y que se afirme que Scrum “es muy buena en gestión pero le hacen

falta mayores herramientas”.

Se prevé que permitirá aumentar la precisión en la estimación de los tiempos y reducir

la probabilidad de problemas con los requisitos, y que las recomendaciones sobre la

documentación y los consejos para superar los problemas serán de gran utilidad. Esto será

más evidente en la cantidad de fracasos en proyectos que aplican a la metodología por primera

vez.

De esta manera, los proyectos llevados a cabo actualmente con Scrum –e inclusive con

XP– podrán aplicar esta mejora para gestionar los proyectos, en la convicción de que si se la

aplica respetando todas las reglas – las que ya poseía y las nuevas–, se podrá gestionar e

implementar un mejor proyecto de software.


61

6 Glosario

� Artefacto: Es un producto tangible resultante de un proceso de desarrollo de

software. Ayudan a la descripción de las funciones, la arquitectura y el diseño

de software.

� CMMI (Capability Maturity Model Integration): Es un modelo para la mejora y

evaluación de procesos para el desarrollo, mantenimiento y operación de

sistemas de software.

� Daily meeting / Daily Scrum Meeting: Reunión diaria que se realiza en Scrum

para ver el estado de trabajo. La dirige el Scrum Master. Tienen que estar

presente todos los miembros del equipo, incluso el Product Owner de ser

posible. Debe durara 15 minutos como máximo. Aquí todos los miembros

deben responder tres preguntas básicas:

o ¿Qué se hizo desde ayer?

o ¿Qué es en lo que vas a trabajar hoy?

o ¿Ha habido algún problema que te haya retrasado o impedido alcanzar

tu objetivo?

� Ingeniería de Requisitos: La Ingeniería de Requisitos consiste en un conjunto

de actividades y transformaciones que pretenden comprender las necesidades

de un sistema software y convertir la declaración de estas necesidades en una

descripción completa, precisa y documentada de los requerimientos del

sistema siguiendo un determinado estándar.

� JAVA: Lenguaje de programación de tercera generación orientado a objetos.

Fue desarrollado por Sun Microsystems a principio de la década del 90.

� Javadoc: Es una utilidad desarrollada para la generación de documentación en

formato HTML a partir del código fuente en JAVA.

� JUnit: Test unitarios. Son test que se desarrollan para probar de manera

controlada y por unidades (clases, paquetes de negocio, etc.) el

funcionamiento del código Java.

� Product Backlog: Documento de alto nivel para todo el proyecto el cual

contiene las tareas de negocio, funcionalidades deseables, etc. Que se quieren

alcanzar en el proyecto. Cada tarea está estimada en Story Points.

� Product Owner: Dueño del proyecto, es quien representa al cliente en Scrum.

� QA (Quality assurance): Programa para el monitoreo y evaluación de varios

aspectos de un proyecto o servicio para asegurar estándares de calidad.

� Scrum Master: Individuo que en Scrum representa un papel parecido a un líder

de proyecto. Esta encargado de comunicarse principalmente con el Product

Owner, de motivar al equipo y de solucionar cualquier inconveniente que se

presente respecto a información del proyecto.


62

� Sprint: Ciclo de trabajo en Scrum. Estos pueden ser de un periodo una a cuatro

semanas por lo general.

� Sprint Backlog: Documento detallado a nivel técnico de las tareas a realizar en

el Sprint. Estas están estimadas en horas.

� Sprint planning Meeting: Reunión realizada para definir las tareas a llevar a

cabo en el Sprint que va a comenzar.

� Sprint review meeting: Reunión realizada al final de cada Sprint para revisar el

trabajo que fue y no completado. Se presenta también lo completado al Product

Owner. Esta presentación se conoce como Demo. Tiempo máximo de la

reunión de 4 horas.

� Story Points: Puntaje que se le da a las tareas del Product Backlog. Este

puntaje se obtiene según la formula de RIO (Retorno de inversión).

� Procesos de ingeniería / Proceso de la ingeniería:

� RIO: Retorno de inversión. En Scrum la fórmula para obtener el retorno de

inversión de una tara de negocio es la siguiente:

Valor Generado / Costo = RIO (Retorno de inversión) .

� XP (eXtreme Programming): Metodología ágil de desarrollo de software

formulada por Kent Beck en el 1999.


63

7 Bibliografía

(s.f.). Recuperado el 10 de 02 de 2009, de http://genobraker.spaces.live.com/blog/cns!F45E3DFD1A71CD5A!835.entry

Abrahamsson, P. (2008). Agile Processes in Software Engineering and Extreme Programming. Página 22: Springer.

Acosta, W. (01 de 07 de 2001). Gestiopolis. Recuperado el 05 de 26 de 2009, de Gestiopolis: http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/pertcpm.htm

Beck, K. (2003). Test-driven development: by example. Addison-Wesley.

Boehm´s, B. W. (2007). Softwaer Engineering. Willey-Interscience.

Carlos, U. R. (s.f.). Kybele. Recuperado el 26 de 02 de 2009, de Kybele: http://kybele.escet.urjc.es/Documentos/ISI/Ingenieria%20de%20Requisitos.pdf

Castro, P. M. (s.f.). Metodología de Trabajo Ágil y Eficiente: El método Scrum aplicado a la Gestión de Proyectos en general. Fundación Antonio Nebrija .

Castro, P. M. PROGRAMA FORMATIVO DE POSTGRADO "Competencias para la incorporación laboral y profesional. España: Fundación Antonio de Nebrija.

Charvat, J. (2003). Project management methodologies: selecting, implementing, and supporting methodologies and processes for projects. John Wiley and Sons.

Ciencia y Técnica Administrativa. (s.f.). Recuperado el 26 de Marzo de 2009, de ca: http://www.cyta.com.ar/ta0502/v5n2a1.htm#1

CM Crossroad. (s.f.). Recuperado el 15 de 04 de 2009, de http://www.cmcrossroads.com/

Cohn, M. (2004). User stories applied.

Corral, R. (09 de 06 de 2008). Geeks. Recuperado el 11 de 02 de 2009, de Geeks: http://geeks.ms/blogs/rcorral/archive/2008/06/09/191-c-243-mo-hacer-funcionar-scrum-191-c-243-mo-saber-si-scrum-est-225-funcionando.aspx

Corral, R. (19 de 11 de 2006). Geeks.ms. Recuperado el 17 de 01 de 2009, de http://geeks.ms/blogs/rcorral/archive/2006/11/19/las-reglas-de-scrum-i-el-sprint-planning-meeting.aspx

Covey, S. R. (1989). 7 habitos de la gente altamente efectiva. Paidós Ibérica.

Doug Rosenberg, M. S.-C. (2005). Agile development with ICONIX process: people, process, and pragmatism. Apress.

Extreme Programming: A gentle Introduction. (s.f.). Obtenido de Extreme Programming: A gentle Introduction: http://www.extremeprogramming.org/


64

Frauke Paetsch, D. A. (s.f.). Requirements Engineering and Agile Software Development. Recuperado el 08 de Julio de 2009, de http://www2.enel.ucalgary.ca/People/eberlein/publications/WETICE_03.pdf

Garreta, J. S. (2003). Ingeniería de proyectos informáticos.

Garrido, R. S. (2009). Scrum and the World Crisis. Scrum Aliance.

Henrik Kniberg, P. d. (2007). Scrum y XP desde las trincheras. Info Q.

Hughes, R. (2008). Agile Data Warehousing. iUniverse.

Hunt, J. (2005). Agile software construction. Springer.

Jeff Tian, C. S. (2005). Software quality engineering.

José H. Canós, P. L. Métodologías Ágiles en el Desarrollo de Software. Universidad Politécnica de Valencia.

José H. Canós, P. L. Métodologías Ágiles en el Desarrollo de Software. DSIC -Universidad Politécnica de Valencia.

José Manuel Márquez (Docente de la Universidad de Valladolid), I. L. (27 de 03 de 2008). Daniel’s Blog. Recuperado el 10 de 03 de 2009, de Daniel’s Blog: http://danielvn7.wordpress.com/category/ingenieria-de-requisitos/

Ken Schwaber, M. B. (2001). Agile Software Development with Scrum.

Ken, S. (2007). The Enterprise and Scrum.

Kent Beck, J. G. (2001). Manifesto For Agile Software Development. Recuperado el 2 de Julio de 2009, de http://agilemanifesto.org/

Larman, C. (2004). Agile and iterative development: a manager's guide. Addison-Wesley, 2004.

Larman, C. Applying UML and Patterns.

Larsen, E. D. Agile Retrospectives.

N°1. (Marzo-2006). Agile Journal .

(2003). Requirements Engineering and Agile Software Development. IEEE Computer Society.

Rossberg, J. (2008). Pro Visual Studio Team System Application Lifecycle Management. Páginas 68 - 70: Apress.

Rossberg, J. (2008). Pro Visual Studio Team System Application Lifecycle Management. Apress.

Schwaber, K. (2004). Agile Project Management with Scrum.


65

Schwaber, K. (s.f.). SCRUM Development Process. Recuperado el 23 de Mayo de 2009, de http://www.jeffsutherland.com/oopsla/schwapub.pdf

Scrum Alliance. (s.f.). Recuperado el 26 de 02 de 2009, de http://www.scrumalliance.org/articles/68-what-scrum-can-and-cannot-fix

Thomas Pyzdek, P. A. (2003). Quality Engineering Handbook.

Wikipeadi. (s.f.). Recuperado el 20 de 01 de 2009, de http://es.wikipedia.org/wiki/RUP

Wikipedia. (s.f.). Recuperado el 15 de 12 de 2008, de http://es.wikipedia.org/wiki/Scrum

Wikipedia. (s.f.). Recuperado el 16 de 01 de 2009, de http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema

Wikipedia. (s.f.). Recuperado el 26 de 04 de 2009, de http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente


66

8 Anexo 1

8.1.1 Modelo iterativo e incremental

El modelo iterativo e incremental es un proceso de desarrollo de software creado en

respuesta a las debilidades del modelo tradicional de cascada. Para apoyar el desarrollo de

proyectos por medio de este modelo se han creado frameworks de los cuales los dos más

famosos son RUP (Rationa Unified Process y DSDM (Dynamic Systems Development Method).

El desarrollo incremental e iterativo también es una parte esencial de un tipo de metodología

llamadas metodologías ágiles, a las cuales pertenecen Scrum y Extreme Programming (XP)

entre otros.

La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de

programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha

aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema.

El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea

posible). Los pasos claves en el proceso son comenzar con una implementación simple de los

requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta

que el sistema completo esté implementado. En cada iteración, se realizan cambios en el

diseño y se agregan nuevas funcionalidades y capacidades al sistema.

El proceso en sí mismo consiste de:

� Etapa de inicialización.

� Etapa de iteración.

� Lista de control de proyecto

8.1.1.1 Etapa de inicialización

Se crea una versión del sistema. La meta de esta etapa es crear un producto con el

que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una

muestra de los aspectos claves del problema y proveer una solución lo suficientemente simple

para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración, una lista

de control de proyecto se crea, y esta lista contiene un historial de todas las tareas que

necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas,

y áreas de rediseño de la solución ya existente. Esta lista de control se revisa periódica y

constantemente como resultado de la fase de análisis.

8.1.1.2 9.1.2 Etapa de iteración

Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de

proyecto, y el análisis de la versión más reciente del sistema. La meta del diseño e

implementación de cualquier iteración es ser simple, directa y modular, para poder soportar el

rediseño de la etapa o como una tarea añadida a la lista de control de proyecto. El código


67

puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis

de una iteración se basa en la retroalimentación del usuario y en el análisis de las

funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad,

usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del

proyecto se modifica bajo la luz de los resultados del análisis.

8.1.1.3 Lista de control de proyecto

Las guías primarias que guían la implementación y el análisis incluyen:

� Cualquier dificultad en el diseño, codificación y prueba de una modificación

debería apuntar a la necesidad de rediseñar o recodificar.

� Las modificaciones deben ajustarse fácilmente a los módulos fáciles de

encontrar y a los aislados. Si no es así, entonces se requiere algún grado de

rediseño.

� Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si

dicha modificación no ocurre rápidamente, se debe aplicar algo de rediseño.

� Las modificaciones deben ser más fáciles de hacer conforme avanzan las

iteraciones. Si no es así, hay un problema primordial usualmente encontrado

en un diseño débil o en la proliferación excesiva de parches al sistema.

� Los parches normalmente deben permanecer solo por una o dos iteraciones.

Se hacen necesarios para evitar el rediseño durante una fase de

implementación.

� La implementación existente debe ser analizada frecuentemente para

determinar que tan bien se ajusta a las metas del proyecto.

� Las facilidades para analizar el programa deben ser utilizadas cada vez para

ayudar en el análisis de implementaciones parciales.

� La opinión del usuario debe ser solicitada y analizada para indicar deficiencias

en la implementación referida por él.

Mejora de La Metodologia Scrum-Martin Casamayor

Documents

Transcript of Mejora de La Metodologia Scrum-Martin Casamayor