Marco ágil para PMI en pequeñas y medianas empresas de desarrollo de software 1

Luis Bastidas2, Álvaro Zapata3

Resumen El presente trabajo de investigación no se desarrolla en una organización en particular dado que los

lineamientos y recomendaciones resultantes serán de utilidad en un marco ágil para PMI en

pequeñas y medianas empresas de desarrollo de software

Las tecnologías de Información juegan un papel clave en esta evolución y presentan nuevas herramientas e iniciativas de apoyo a la administración de proyectos, las cuales deben adoptarse considerando las características y objetivos propios de la organización. Dado el creciente aumento de pequeñas y medianas empresas de software que se constituyen no cuentan con una oficina de proyectos y una metodología ágil que les ayude a desarrollar con orden y eficacia las diferentes etapas y procesos que involucra la dirección general de la empresa (planificación, organización, selección de personal, ejecución y control de las operaciones) y el ciclo de vida de los proyectos que administran, aunado con la influencia de nuevas tecnologías; surge la necesidad de implementar nuevas formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administración de proyectos ágil, sin dejar de lado la colaboración a distancia, el outsourcing, la mejora de calidad, generación y distribución de conocimiento y coordinación de varios proyectos, entre otras. Palabras claves. Metodología tradicional, Metodología Ágil, PMBOK, SCRUM, XP.

1 Esta investigación hace parte del trabajo de investigación de Luis Bastidas y Álvaro Zapata. 2 Candidato a Especialista en Gestión Integral de Proyectos de la Universidad San Buenaventura Seccional Cali. Contador Público de la universidad San Buenaventura E-mail: lcarlos2050@gmail.com 3 Candidato a Especialista en Gestión Integral de Proyectos de la Universidad San Buenaventura Seccional Cali. Ingeniero de Sistema de la Universidad Antonio Nariño, E-mail: azapata0216@hotmail.com

1. Introducción 1.1. Situación

Cerca ya de dos (2) décadas el incremento en el uso de metodologías ágiles y la aplicación de metodologías tradicionales para la administración de proyectos en el desarrollo de software, ha causado un dilema a una gran cantidad de pequeñas y medianas empresas de desarrollo de software: identificar cuál método es más efectivo y eficiente a la hora de desarrollar los proyectos. Esta gran confusión se da debido a que cada método tiene sus propias técnicas, que en ciertos casos son muy afines a los principios de administración de proyectos, pero que en otros casos son muy diferentes y van en contravía con los mismos.

Los métodos ágiles rompen el paradigma de que son solo una forma de desarrollar software, estos van más allá, ya que requieren de la aplicación de enfoques particulares de administración de proyectos. La forma en que son aplicados, cambia las interacciones en que patrocinadores, usuarios y stakeholders se comprometen en un proyecto. De igual forma los enfoques ágiles emplean diferentes procesos para la planificación, ejecución y control. (Letelier Patricio, 2006)

Ante la necesidad de las PYMES de aplicar las técnicas ágiles para el desarrollo de software y cumplir con los principios y las recomendaciones del PMBOK 4TH_EDITION, se elabora este proyecto de investigación para documentar, analizar y proponer un marco de trabajo, que contribuya al desarrollo más ameno en los proyectos. Para lograr el cumplimiento de los objetivos planteados, se espera hacer una revisión del material existente y bibliografía sobre las metodologías agiles y tradicionales existentes para la administración de proyectos de desarrollo de software. El desarrollo de este proyecto de investigación se centra concretamente en identificar los beneficios y características, respecto al uso de metodologías ágiles para la administración de proyectos de software, al alinearlos con el marco de referencia del PMBOK 4TH_EDITION.

1.2. Administración de proyectos bajo PMI

Según el PMBOK 4TH_EDITION, un proyecto es un esfuerzo que se lleva a cabo para crear un producto, servicio o resultado único, y tiene la característica de ser naturalmente temporal, es decir, que tiene un inicio y un final establecidos. (P.M.I., 2008).

1.3. ¿Qué es el PMBOK?

PMBOK es el estándar para la Administración de Proyectos y cuyas siglas significan en inglés Project Management Body of Knowledge (el Compendio del Saber de la Gestión de Proyectos en español).(P.M.I., 2008).

Éste a su vez puede ser entendido como una colección de sistemas, procesos y áreas de conocimiento que son universalmente aceptados y reconocidos como los mejores dentro de la gestión de proyectos.

La tabla No. 1 describe los diferentes conceptos de dirección de proyectos emitidos por distintos autores. Tabla 1. Cuadro conceptual de la dirección de proyectos.

Autor Concepto Descripción

PMI

Desarrollo de estándares para la Administración de

Proyectos.

El PMI desarrolla estándares de la profesión “Project Management” alrededor de todo el mundo. Uno de sus más conocidos estándares la Guide to the Project Management Body of Knowledge (PMBOK® Guide) es mundialmente reconocida y está aprobada como un estándar por el American National Standards Institute (ANSI). El PMI está enfocado en la expansión del conjunto de conocimientos de la profesión “Project Management” a través de encuestas propias, investigaciones externas, una base de datos de información. Adicionalmente, necesidades, información, conocimientos y mejores prácticas son recolectados y distribuidos.

Erly Delgado Expósito

Metodologías de desarrollo de

software. ¿Cuál es el camino?

Hoy en día existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas específicamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran número de proyectos; sobre todo, en aquellos proyectos de gran tamaño (respecto a tiempo y recursos). La experiencia ha demostrado que las metodologías tradicionales no ofrecen una buena solución para proyectos donde el entorno es volátil y donde los requisitos no se conocen con exactitud, porque no están pensadas para trabajar con incertidumbre.

Omar Higinio Caballero Cervantes

Tecnologías de información y

herramientas para la administración de

proyectos de Software.

En el siglo pasado innumerables áreas de Tecnología han tenido progresos considerables, pero una se destaca sobre las demás, no porque haya dejado de existir o por que se haya convertido en una innovación radical, sino porque ha cambiado tanto que apenas es reconocible a la situación en la que se encontraba hace 10 años: la Administración de Proyectos.

Michele Sliger

Relación a las prácticas del

PMBOK prácticas ágiles

Los profesionales PMP de la gestión de proyectos tradicionales atraviesan algunas dificultades a medida que hacen la transición de enfoques impulsados por el plan a las nuevas metodologías ágiles. Irónicamente, para todas las diferencias en Project Management Institute (PMI) y las filosofías ágiles, se ha encontrado que muchas de las prácticas identificadas en la Dirección de Proyectos del Conocimiento (PMBOK) son totalmente compatibles con las prácticas ágiles.

Fuente. Elaboración propia a partir de la lectura de los autores mencionados anteriormente.

1.4. Síntesis de los grupos de procesos del PMBOK.

La tabla No. 2 muestra el nombre del grupo, el objetivo, la descripción y la conclusión de la administración de proyectos basado en las mejores prácticas mencionadas en el PMBOK.

Tabla 2. Grupo de procesos para la administración de proyectos basados en las mejores prácticas del PMBOK.

Grupo Objetivo Descripción Conclusión Iniciación Definir los

procesos para un nuevo proyecto.

Este grupo está compuesto por aquellos procesos realizados para definir un nuevo proyecto o empezar una nueva fase de un proyecto ya existente mediante la autorización para empezar dicho proyecto o fase. En esta fase se define el alcance inicial y se comprometen los recursos financieros iniciales, se identifican los interesados internos y externos que van a interactuar o ejercer una influencia en el proyecto y se selecciona el director del proyecto, toda esta información se documenta en el Acta de Constitución del Proyecto y Registro de Interesados. Cuando el Acta de Constitución es Aprobada el proyecto se considera autorizado.

Involucrar a los clientes o interesados, desde la fase de iniciación, mejora la probabilidad de obtener propiedad compartida, en la aceptación de entregables con la satisfacción del cliente e interesados.

Planificación

Establecer el alcance del proyecto

Es el mayor grupo de procesos pues es donde se define el alcance en base a los requisitos estableciendo la estructura desglosada de trabajo o EDT; se define la secuencia, recursos y duración de las actividades estableciendo el cronograma del proyecto; se estiman los costos estableciendo el presupuesto del proyecto; se identifican los riesgo; y el plan de respuesta para dichos riesgos; además de planificar la calidad, los recursos humanos, las comunicaciones y adquisiciones que luego serán integrados todos juntos en el plan de gestión del proyecto.

Bajo este grupo de procesos se desarrolla el plan para la dirección del proyecto y los documentos que se utilizan para llevarlo a cabo. A medida que se recopilan o comprenden más detalles del proyecto, puede ser necesaria mayor planificación. A estos procesos repetitivos y continuos de planificación se les denomina planificación gradual.

Ejecución

Realizar y/o completar el trabajo definido en el plan para la dirección de proyectos.

Es donde se consumen la mayor cantidad de recursos y del presupuesto del proyecto, coordinando todas las actividades para ejecutar el trabajo del proyecto asegurando que se cumplan todos los objetivos definidos y que la información sea distribuida a todos los interesados según el plan establecido para las comunicaciones.

Éste grupo de procesos implica coordinar personas y recursos, así como integrar y realizar actividades del proyecto en conformidad con el plan para la dirección del proyecto.

Monitoreo y Control

Realizar seguimiento, analizar y regular el progreso y el desempeño del proyecto.

Un aspecto fundamental para la buena marcha de un proyecto son las actividades de supervisión, inspección, análisis y corrección a través de la identificación de aquellos aspectos del proyecto que requieran realizar cambios preventivos o correctivos y así estar mejor preparados para desviaciones que podrían presentarse durante la gestión del proyecto.

- Controlar los cambios y recomendar acciones preventivas para evitar posibles problemas.

- Monitorear las actividades del proyecto, comparándolas con el plan y la línea base para el desempeño del proyecto.

- Influir en los factores que pueden eludir el control integrado de cambios de modo que únicamente se implementen

cambios aprobados.

Cierre

Finalizar todas las actividades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo.

Asegura el cierre formal del proyecto obteniendo la aceptación del cliente o usuario final y consiguiendo que se concluyan todas las actividades comprometidas en el proyecto, realizando la documentación de las lecciones aprendidas y el archivo físico o electrónico de toda la información relacionada a los entregables que se constituirán en los activos de la organización.

- Obtener la aceptación del cliente o del patrocinador.

- Realizar una revisión tras el cierre del proyecto o la finalización de una fase.

- Registrar los impactos de la adaptación de un proceso.

- Documentar las lecciones aprendidas.

- Archivar todos los documentos relevantes del proyecto en el sistema de información para la dirección de proyectos.

- Cerrar las adquisiciones.

Fuente. PMI

1.6. Síntesis de las áreas de conocimiento del PMBOK.

La tabla No. 3 muestra el área, la descripción y objetivo de las áreas de conocimiento basado en las mejores prácticas mencionadas en el PMBOK.

Tabla 3. Áreas del conocimiento de la administración de proyectos

Área Descripción Objetivos

Gestión de la Integración

Describe los procesos requeridos para asegurar que los elementos varios de un proyecto están coordinados apropiadamente. Consiste en el desarrollo de un plan de proyecto, ejecución del plan de proyecto, y el control de cambios en general.

- Integrar y coordinar todo el proyecto, planear y crear un documento constante, coherente.

- Realizar el plan del proyecto, realizando todas las actividades.

- Control a los cambios que coordinan a través del proyecto entero

Gestión del Alcance

Describe el proceso requerido para asegurar que el proyecto incluye todo el trabajo, para completar el proyecto de manera exitosa. Consiste en la iniciación, planeación del alcance, definición del alcance, verificación del alcance, y control de cambio al alcance

- Autorizar el proyecto o la fase. - Desarrollar una declaración escrita del alcance como la

base para las decisiones futuras del proyecto. - subdividir los entregables principales del proyecto en

componentes más pequeños, más manejables. - Formalización de la aceptación del alcance del proyecto. - Cambios que controlan al alcance del proyecto

Gestión del Tiempo

Describe los procesos requeridos para asegurar la terminación a tiempo del proyecto. Consiste en la definición de las actividades, secuencia de las actividades, estimación de duración de las actividades, desarrollo del cronograma y control de la programación.

- Identificar las actividades específicas que se deben realizar en cada una de las fases del proyecto.

- Estimar el número de períodos del trabajo que serán necesarios para terminar actividades individuales.

- Analizar secuencias de la actividad, duraciones de la actividad, y requisitos de recurso de crear el horario del proyecto.

- Controlar cambios al horario del proyecto.

Gestión del Costo Describe los procesos requeridos para asegurar que el proyecto es completado dentro del presupuesto aprobado. Consiste en la planificación de recursos, estimación de costos, presupuesto de costos, y control de costos.

- Determinar qué recursos (gente, equipo, materiales) y qué cantidades de cada uno se deben utilizar para realizar actividades del proyecto.

- Desarrollar una aproximación (estimación) del costo de los recursos que se necesita para terminar actividades del proyecto.

- Controlar al presupuesto de proyecto

Gestión de la Calidad

Describe los procesos requeridos para asegurar que el proyecto satisfaga las necesidades, para lo cual fue desarrollado. Consiste en la planeación de la calidad, seguranza de la calidad, y control de calidad.

- Identificar que estándares de calidad son relevantes al proyecto y determinar cómo satisfacerlos.

- Asegurar que el proyecto satisfaga los estándares de calidad relevantes.

- Supervisar el proyecto para determinar que esté cumpliendo los estándares.

Gestión del Recurso Humano

Describe los procesos requeridos para hacer el uso más eficiente de las personas involucradas en el proyecto. Consiste en la planeación organizacional, adquisición de staff, y desarrollo del equipo.

- Identificar, documentar, y asignar papeles del proyecto, responsabilidades, y relaciones de divulgación.

- Conseguir los recursos humanos necesarios para trabajar en el proyecto.

- Identificar las habilidades del individuo y del grupo para asignar roles en el proyecto.

Gestión de Comunicaciones

Describe los procesos requeridos para asegurar la generación apropiada a tiempo, almacenamiento y la disposición final de la información del proyecto. Consiste en la planeación de la comunicación, distribución de la información, reportes de desempeño, y el cierre administrativo.

- Determinar la información y las necesidades de comunicaciones para el equipo de proyecto (quién, que, cuando y como necesita la información).

- Hacer que la información necesaria esté disponible para proyectarla al equipo del proyecto de una manera oportuna.

- Generar, recolectar, y diseminar la información para formalizar la terminación de la fase o del proyecto.

Gestión del Riesgo

Describe los procesos concernientes con la identificación, análisis, y respuesta al riesgo del proyecto. Consiste en la identificación del riesgo, cuantificación del riesgo, desarrollo de la respuesta al riesgo, y en el control de la respuesta al riesgo.

- Determinar qué riesgos pudieran afectar el proyecto y la documentación de sus características.

- Realizar análisis cualitativo de riesgos y dar prioridad a aquellos que afecte los objetivos del proyecto.

- Medir la probabilidad y las consecuencias de los riesgos y estimar sus implicaciones para los objetives del proyecto.

- Planear respuesta efectivas al posible riesgo

Gestión de Adquisiciones

Describe los procesos requeridos para adquirir bienes y servicios de fuera de la organización ejecutora. Consiste en la planeación de la gestión de la adquisición, planear la selección de proveedores, administración de contratos, y cierre de contratos.

- Determinar qué adquirir y cuando. - Documentar requisitos del producto e identificar fuentes

potenciales. - Identificar el vendedor potencial. - Administrar la relación con el vendedor. - Administrar los contratos. - Cerrar el contrato

Fuente. PMI

1.7. Administración de proyectos con Metodología ágil.

Cada vez más, los estudios y las experiencias demuestran que la forma tradicional, de la

administración de proyecto de desarrollo de software, es errónea en las actuales circunstancias

y necesidades de dinamismo y adaptabilidad de los sistemas de software. Por tal motivo, ha

surgido la necesidad de investigar y desarrollar nuevas técnicas que tienden hacia el rápido

desarrollo de aplicaciones y que la vida útil de un producto sea más corta. En un entorno

dinámico, inestable, que tiene como principal protagonista el cambio y una evolución rápida y

continua, la ventaja competitiva se encuentra en aumentar la productividad para satisfacer las

necesidades del cliente en el menor tiempo posible para agregar valor al negocio (Boehm,

2006).

1.8. El Manifiesto Ágil.

El “Manifiesto Ágil”, promulga “que están poniendo al descubierto mejores métodos para

desarrollar software, haciéndolo y ayudando a otros a que lo hagan”; tras la reunión de Utah, un

documento que resume la filosofía ágil estableciendo cuatro valores y doce principios (Tabla

No. 4).

La tabla No. 4 Describe como el Manifiesto comienza enumerando los principales valores del

desarrollo ágil

Tabla 4. Principales valores del desarrollo Ágil

Fuente: (Letelier Patricio, 2006)

1.9. Conceptos Metodología Ágil.

La tabla No. 5 describe los diferentes conceptos emitidos por distintos autores de metodologías

ágiles.

Tabla 5. Cuadro Conceptual de metodologías agiles

PERIODO AUTORES BREVE DESCRIPCIÓN

ALGUNAS

REFERENCIAS

CLAVES

1980-

1985

Gustavo

Martinez

Muchas metodologías ágiles ya operaban en estos años, pero no

tenían reconocimiento y las empresas o desarrolladores no las

utilizaban, porque no eran confiables y no habían sido probadas.

- Martinez, Gustavo (2011).

1986

Hirotaka

Describieron una nueva aproximación holística que incrementa la

rapidez y la flexibilidad en el desarrollo de nuevos productos

comerciales, denominada SCRUM. Es comparado con el rugby,

donde el equipo entero «actúa como un sólo hombre para intentar

- Chin, Gary (2004).

A los individuos y su interacción, por encima de los proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. En resumen, es más importante construir un buen equipo que construir el entorno.

El software que funciona, por encima de la documentación exhaustiva. Aunque un software sin documentación es un desastre, la regla a seguir es “no producir documentos a menos que sean estrictamente necesarios”.

La colaboración con el cliente, por encima de la negociación contractual. Se evita el fracasar por intentar cumplir unos plazos y unos costos preestablecidos al inicio del proyecto. Por ello, se propone que exista una interacción constante entre el cliente y el equipo de desarrollo.

La respuesta al cambio, por encima del seguimiento de plan. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto, determina también el éxito o fracaso del mismo.

Takeuchi

Ikujiro Nonaka

llegar al otro lado del campo, pasando el balón de uno a otro».

1989 James Womack Daniel T. Jones Daniel Roos

Define un método llamado Lean Development (LD), en el cual los

cambios se consideran riesgosos, pero si se manejan

adecuadamente se pueden convertir en oportunidades que mejoren

la productividad del cliente. Su principal característica es introducir

un mecanismo para implementar dichos cambios.

-Mary Poppendieck, Michael A. Cusumano, "Lean Software Development (2003).

2001 Kent Beck

Impulsa un movimiento, donde diecisiete críticos de los modelos

iterativo e incremental, de desarrollo de software, basados en

procesos, se reunieron en Salt Lake City, Utah, para tratar sobre

técnicas y procesos para desarrollar software; como resultado nace

el Manifiesto ágil, donde a todo el movimiento, se le da el nombre de

Metodologías Ágiles.

-

www.agilemanifiest

o.org

-Letelier Patricio, P.

M. (2006, 01 15).

2001 Miembros del

Manifiesto ágil

Establecen la Alianza Ágil, una organización sin fines de lucro, que

promueve el desarrollo ágil de aplicaciones y da apoyo a todas las

Metodologías Ágiles, que surgen como alternativa a las

metodologías tradicionales.

www.agilealliance.o

rg

Fuente: Elaboración propia a partir de investigaciones de los autores arriba mencionados.

1.10. Metodología ágil Scrum

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. (Albaladejo, 2009). La figura No. 1 se muestra los grupos de procesos utilizados en scrum.

Figura 1. -Grupo de procesos de SCRUM (Ortega, 2010 )

PMBOK SCRUM

Fase Release

Subfase Sprint

En la tabla No. 6 se describe por componente los participantes y el esquema utilizado en Scrum.

Tabla 6. Grupo de componentes para la administración de proyectos con SCRUM. SCRUM

Componentes Participantes Esquema

Roles en

Scrum

Roles Principales

Product Owner: Representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

Scrum Master (o Facilitador): Su trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El Scrum Master no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El Scrum Master se asegura de que el proceso Scrum se utiliza como es debido. El Scrum Master es el que hace que las reglas se cumplan.

Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc). El equipo debe ser Auto - Gestionado Auto - Organizado y Multi – Funcional.

Roles Auxiliares

Son aquellos que no tienen

un rol formal y no se

involucran frecuentemente

en el "proceso Scrum", sin

embargo deben ser

tomados en cuenta.

Stakeholders (Clientes, Proveedores, Vendedores, etc): Se refiere a la gente que hace posible el proyecto y para quienes, el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.

Usuarios (Administradores, otros):

Son aquellas personas para las que se desarrolla el producto.

Reuniones de

Scrum

Participantes: Producto

Owner + Scrum Manager +

Equipo

Duración: 1 jornada de

trabajo.

Planificación del Sprint (Sprint Planning)

Seleccionar qué trabajo se hará.

Preparar, con el equipo completo, el Pila del Sprint (lista de historias incluidas en el Sprint), que detalla el tiempo que tomará hacer el trabajo.

Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.

Fijar una fecha para la Demo del Sprint.

Participantes: Equipo +

Scrum Manager (los demás

solo pueden mirar)

Duración: 15 minutos (es

dirigida por el Scrum

Manager)

Reunión diaria (Daily Scrum)

La reunión comienza puntualmente a su hora.

Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar.

La reunión debe ocurrir en la misma ubicación y a la misma hora

todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

¿Qué has hecho desde ayer? ¿Qué es lo que harás hasta la reunión de mañana?

¿Has tenido algún problema que te haya impedido alcanzar tu

objetivo?

Participantes: Todos.

Duración: 4 horas

aproximadamente.

Revisión del Sprint (Sprint Review)

Revisar el trabajo que fue completado y no completado

Presentar el trabajo completado a los interesados (alias “demo”)

El trabajo incompleto no puede ser demostrado

Retrospectiva del Sprint (Sprint Retrospective) Después de cada sprint, se lleva a cabo una retrospectiva del sprint,

en la cual todos los miembros del equipo dejan sus impresiones sobre

el sprint recién superado. El propósito de la retrospectiva es realizar

una mejora continua del proceso.

Artefactos de

Scrum

Pila del producto (Product Backlog) :

Es un documento de alto nivel para todo el proyecto. Contiene

descripciones genéricas de todos los requisitos, funcionalidades

deseables, etc. priorizadas según su retorno sobre la inversión (ROI). Es

abierto y solo puede ser modificado por el product owner. Contiene

estimaciones realizadas a grandes rasgos, tanto del valor para el

negocio, como del esfuerzo de desarrollo requerido. Esta estimación

ayuda al product owner a ajustar la línea temporal (KEV) y, de manera

limitada, la prioridad de las diferentes tareas.

Pila del sprint (Sprint Backlog) :

Es un documento detallado donde se describe el cómo el equipo va a

implementar los requisitos durante el siguiente sprint. Las tareas se

dividen en hora; donde ninguna tarea debe superar a 16 horas. Si una

tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las

tareas en el sprint backlog nunca son asignadas, son tomadas por los

miembros del equipo del modo que les parezca oportuno.

Trabajo pendiente (Burndown chart):

Es una gráfica mostrada públicamente, que mide la cantidad de

requisitos en el Backlog del proyecto pendientes al comienzo de cada

Sprint. Dibujando una línea que conecte los puntos de todos los Sprints

completados, podremos ver el progreso del proyecto. Lo normal es que

esta línea sea descendente (cuando los requisitos están bien definidos

desde el principio y no varían nunca) hasta llegar al eje horizontal,

momento en el cual el proyecto se ha terminado (no hay más requisitos

pendientes). Si durante el proceso se añaden nuevos requisitos la recta

tendrá pendiente ascendente en determinados segmentos, y si se

modifican algunos requisitos la pendiente variará.

(Schwaber, 1995) - (Albaladejo, 2009)

1.11. Mapeando las prácticas del PMI al marco de trabajo SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Las siguientes tablas describen un mapeo de algunas áreas de conocimiento del PMBOK y las prácticas de SCRUM, esto indica que podría ser posible administrar proyectos de corto y mediano plazo con una metodología ágil pero enfocada en las prácticas mencionadas en el PMBOK.

La tabla No. 7 muestra la práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM. Tabla 7. Práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión de la

Integración

Desarrollar lanzamiento del

proyecto donde se define, justifica

y autoriza el proyecto.

El Product Owner y el equipo desarrollan el Roadmap

del producto, la visión y el Backlog.

Desarrollar un plan formal de

gestión del proyecto

El equipo desarrolla el Release-plan a alto nivel y con

más detalle el plan para el siguiente Sprint.

Dirigir y gestionar la ejecución del

proyecto conforme el plan.

Monitorear y controlar el proyecto.

El equipo ejecuta y entrega. El Scrum Master se encarga

de asegurar que se cumplan los principios de Scrum. En

vez de dirigir y gestionar a los equipos, los equipos se

auto-dirigen usando revisiones de sprint, retrospectiva y

ajustan el proceso (mejora continua).

Realizar el control de cambios del

proyecto.

El Control de cambios se lleva por parte del Product

Owner y el equipo, por medio del Product backlog

ordenado. Hay un constante Feedback durante la

iteración y la revisión.

Cerrar el proyecto o la fase.

Cierres administrativos o auditorios.

Revisiones de Sprint/Retrospectiva del proyecto. Si

hace falta un cierre administrativo, se usará un Sprint n +

1 (en caso de ser necesario).

(P.M.I., 2008) - (Albaladejo, 2009)

Un Director de Proyecto tradicional es responsable de hacer que todos los procesos de esta área de conocimiento se realicen bajo un mismo patrón de gestión. Un Scrum Master tiene una función un poco más ligera, es responsable de hacer que el equipo trabaje para definir la planificación y las iteraciones. El Director de proyecto en un ambiente ágil, deberá aprender a ceder el control.

La tabla No. 8 muestra la práctica mapeada del área de conocimiento Gestión del alcance en PMBOK a su equivalente en SCRUM. Tabla 8. Práctica mapeada del área de conocimiento Gestión del alcance en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión del

Alcance

Identificar los requisitos. Obtener

y documentar los requisitos

funcionales del trabajo a realizar

Desarrollar y ordenar el Product Backlog.

Definir el Alcance. Entregables, lo

que está incluido, lo que no está

incluido, restricciones, excepciones

y dependencias.

Seleccionar los ítems del Product Backlog que se

incluyen en cada release o Sprint.

Crear la WBS. Crear una descomposición de las características para el

reléase, mostrando las que se incluyen en cada reléase.

Descomponer las características por Sprint.

Verificar el Alcance (Aceptación

formal, cambios en los

requerimientos, etc.)

A través de mecanismos de aceptación de las

características del Sprint (por el product owner), se

puede utilizar herramientas de trazabilidad y el propio

Product Backlog.

Control del Alcance. Gestionarlo vía Product Backlog. Proteger la iteración.

(P.M.I., 2008) - (Albaladejo, 2009)

La gestión del alcance es inherente al proceso SCRUM, se gestiona desde el Product Backlog. Scrum mantiene fijo el tiempo y los costos y lo único negociable es el alcance el cual es fijado al inicio del Sprint.

La tabla No. 9 muestra la práctica mapeada del área de conocimiento Gestión del tiempo en PMBOK a su equivalente en SCRUM. Tabla 9. Práctica mapeada del área de conocimiento Gestión del tiempo en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión del Tiempo

Definir Actividades: Identificar las

acciones específicas a ser

realizadas para elaborar los

entregables del proyecto.

El equipo selecciona las características que se van a

incluir en el Sprint, las tareas necesarias para cumplir

con esas funcionalidades son identificadas.

Establecer la Secuencia de las

Actividades: identificar y

documentar las interrelaciones

entre las actividades del proyecto

El equipo durante el Sprint Planning Meeting realiza la

secuencia necesaria de actividades y su estimación.

Estimar las actividades a realizar

Desarrollar el Cronograma:

Analizar la secuencia de las

actividades, su duración, los

requisitos de recursos y las

restricciones del cronograma del

proyecto.

Desarrollar el calendario de lanzamiento y solo las

características que son incluidas en el Sprint se

desarrollan y estiman (Just-in-time planning). Las

estimaciones se refinan basándose en datos empíricos

(velocidad del equipo).

Controlar el cronograma: Hacer

seguimiento al proyecto para

actualizar el avance del mismo y

gestionar cambios a la línea base

del cronograma.

El equipo es el que gestiona las características que

serán desarrolladas en cada sprint.

(P.M.I., 2008) - (Albaladejo, 2009)

SCRUM no plantea un plan definido totalmente desde el inicio del proyecto, sino que se va adecuando a medida que avanza el tiempo.

La tabla No. 10 muestra la práctica mapeada del área de conocimiento Gestión de Costos en PMBOK a su equivalente en SCRUM. Tabla 10. Práctica mapeada del área de conocimiento Gestión de Costos en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión de Costos

Estimar los Costos: Consiste en

desarrollar una aproximación de los

recursos financieros necesarios para

completar las actividades del

proyecto.

Estimar a alto nivel los reléase y los sprint usando

“veocidad”, días ideales, analogías, opiniones de

expertos, etc.

Estimar detallado cada sprint más adelante para

validar las estimaciones a alto nivel.

Refinar las estimaciones cuando el equipo va a

comenzar el trabajo.

Determinar el presupuesto: sumar

los costos estimados de actividades

individuales o paquetes de trabajo

para establecer una línea base de

costos autorizada.

Crear una línea base de costos después de realizar

las estimaciones. Revisar la línea de costos después

de un par de sprint (conocemos ya la velocidad del

equipo).

Controlar los costos: Monitorear la

situación del proyecto para actualizar

el presupuesto del mismo y gestionar

cambios a la línea base de costos.

Usar gráficos de Burndown como ayuda para el

control de los costos.

(P.M.I., 2008) - (Albaladejo, 2009)

El control de los costos es una función del equipo con el product owner involucrado en la estimación junto al equipo. En SCRUM las estimaciones se realizan a alto nivel (top-Down) de todo el proyecto y luego son refinados en el ciclo de vida del proyecto.

La tabla No. 11 muestra la práctica mapeada del área de conocimiento Gestión de la Calidad en PMBOK a su equivalente en SCRUM. Tabla 11. Práctica mapeada del área de conocimiento Gestión de la Calidad en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión de Planificar la calidad: se identifican

los requisitos de calidad y/o normas

La calidad está implícita a lo largo de todo el proceso

de Scrum. (test temprano y frecuente, software que

Calidad para el proyecto y el producto,

documentando la manera en que el

proyecto demostrará el cumplimiento

con los mismos.

funciona, eliminación de impedimentos)

La calidad es responsabilidad de todo el equipo.

Realizar el aseguramiento de la

calidad: auditar los requisitos de

calidad y los resultados de las

medidas de control de calidad.

Asegurar que se utilicen las normas

de calidad.

Generalmente la lleva a cabo el equipo. En entornos

formales puede haber un tercero implicado.

Se usan Sprint/Projects Reviews y retrospectiva.

Realizar el control de calidad: Se

monitorean y registran los resultados

de la ejecución de actividades de

control de calidad, a fin de evaluar el

desempeño y recomendar cambios

necesarios.

Realizado por el propio equipo, usando

herramientas de TDD. El Product Owner también

realiza QA por medio de las revisiones. Test de

aceptación como parte del Product Backlog (las

historias de usuario deben incluir los test de

aceptación).

(P.M.I., 2008) - (Albaladejo, 2009)

La calidad es algo implícito en las prácticas de SCRUM, es muy importante estar mentalizado para construir y mantener software de calidad, para lo que hace falta el esfuerzo y compromiso del equipo. El hecho de usar Ágil no es sinónimo de Calidad. Debemos apoyar las prácticas con herramientas que sirvan para garantizarla, con una buena estrategia de pruebas, con un enfoque a TDD (Test Driven Development) y con la mentalidad del equipo para “hacer las cosas bien a la primera.”.

La tabla No. 12 muestra la práctica mapeada del área de conocimiento Gestión del Recurso Humano en PMBOK a su equivalente en SCRUM. Tabla 12. Práctica mapeada del área de conocimiento Gestión del Recurso Humano en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión del

Recurso Humano

Desarrollar el plan de Recursos

Humanos: Identificar y documentar

los roles dentro de un proyecto,

responsabilidades etc.

En Scrum se define el tamaño del equipo para la

duración completa del proyecto. Los equipos no

suelen ser muy grandes (5 +- 2). Si el proyecto es muy

grande se crearan sub-equipos.

Adquirir el equipo del proyecto:

Confirmar personas, disponibilidad y

formar el equipo para completar las

asignaciones del proyecto.

El equipo es multifuncional. Se crea al inicio del

proyecto y se mantiene intacto hasta el final del mismo.

Desarrollar el equipo del proyecto:

competencias, interacciones de los

Valores Scrum: Compromiso, coraje, respeto, foco y

miembros del equipo y el ambiente

del equipo para lograr un mejor

desempeño del proyecto.

franqueza. Fomentar la auto organización del equipo.

Dirigir el equipo del proyecto:

Desempeño del equipo, proporcionar

retroalimentación, resolver problemas

y gestionar cambios a fin de optimizar

el desempeño del proyecto.

Facilitar un coach que ayude a auto gestionar al

equipo. Juega el rol de un líder.

(P.M.I., 2008) - (Albaladejo, 2009)

Los equipos son dedicados, multifuncionales y auto organizados. El Scrum master actúa como líder.

La tabla No. 13 muestra la práctica mapeada del área de conocimiento Gestión de la Comunicación en PMBOK a su equivalente en SCRUM. Tabla 13. Práctica mapeada del área de conocimiento Gestión de la Comunicación en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión de

Comunicación

Identificar a los interesados:

Registro de los intervinientes y

estrategia para su gestión.

Identificar a los interesados y definir quién es el

representante del negocio (Product Owner) que forma

parte del equipo Scrum.

Plan de comunicación: necesidades

de comunicación de los interesados.

Los gráficos Burndown, los backlog de proyecto y de

Sprint son indicadores visuales del estado del

proyecto

Distribución de Información: Poner

la información a disposición de los

interesados.

Los indicadores visuales del estado del proyecto son los

“radiadores de información”

Gestión de Expectativas. La gestión de los intervinientes es realizado por el

Product Owner que es parte del equipo Scrum.

Información sobre el desempeño:

Recopilar y distribuir la información

sobre el desempeño mediante

informes, gráficos, etc.

Los indicadores visuales de Scrum son los que

informan sobre el estado del proyecto.

(P.M.I., 2008) - (Albaladejo, 2009)

Es una de las principales diferencias entre los Proyectos Tradicionales y los Proyecto Scrum, en los primero los métodos de comunicación son más formales, en Scrum los intervinientes son informados a través de los indicadores visuales y una comunicación cara a cara y frecuente.

La tabla No. 14 muestra la práctica mapeada del área de conocimiento Gestión del Riesgo en PMBOK a su equivalente en SCRUM. Tabla 14. Práctica mapeada del área de conocimiento Gestión del Riesgo en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión del

Riesgo

Planificar la gestión del Riesgo:

Definir el plan de riesgos del

proyecto y las estrategias que se

seguirán, metodologías, categorías,

tolerancias...

Informar el Risk Planning como parte de Sprint/Release

Planning y reuniones de revisión. El quipo entero está

involucrado.

Identificar los Riesgos: Inventariar

todos los posibles riesgos que se

puedan presentar en el proyecto.

Identificar los riesgos en las reuniones diarias,

revisiones de iteraciones y de planificación. Analizar en

conjunto los riesgos.

Realizar el Análisis

Cualitativo/Cuantitativo de

Riesgos.

No se prescriben métodos formales. Se puede usar

cualquier método como por ejemplo probabilidad x

impacto.

Planificar la respuesta al Riesgo Eludir, mitigar, transferir, aceptar: no hay diferencia.

Monitorear y controlar los Riesgos En Scrum es parte de las tareas del equipo en las

revisiones y planificaciones.

(P.M.I., 2008) - (Albaladejo, 2009)

En cuanto a Riesgos, no hay una práctica concreta de Riesgos dentro de un proyecto Scrum. Lo más significativo es que todo el equipo participa en la identificación, seguimiento y mitigación de los riesgos. Uno de los momentos en los que aparecen es en las reuniones diarias de equipo. Lo que de aquí se derive como riesgo, será seguido y controlado por el Scrum Master (disipador de impedimentos, entre otras cosas).

La tabla No. 15 muestra la práctica mapeada del área de conocimiento Gestión de Compras en PMBOK a su equivalente en SCRUM. Tabla 15. Práctica mapeada del área de conocimiento Gestión de Compras en PMBOK a su equivalente en SCRUM.

Área de

Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente

Gestión de

Compras

Planificar adquisiciones:

Documentar las decisiones de

compra para el proyecto,

El equipo proporciona información necesaria para las

adquisiciones usando una iteración temprana o una

especificando la forma de hacerlo e

identificando a posibles vendedores.

Prueba de Concepto (PoC).

Realizar las adquisiciones: Obtener

respuestas de los vendedores,

seleccionar un vendedor y adjuntar

un contrato.

El equipo realiza las evaluaciones y proporciona

información para la contratación. Esta práctica estará

dirigida por el líder del Proyecto.

Administrar las adquisiciones:

Gestionar las relaciones de

adquisiciones, monitorear la

ejecución de los contratos, y efectuar

cambios y correcciones según sea

necesario.

Scrum permite contratos con una cláusula de

“terminación temprana” (money for nothing) en donde

un cliente puede terminar un contrato al final de

cualquier Sprint pagando el 20-30% del valor restante

del contrato.

Otro modelo es Change for free en el cual el cliente

puede hacer cambios en el ámbito sin incurrir en costos

adicionales si el monto total contratado no cambia.

Cerrar las adquisiciones Puede usarse un Sprint adiciona (n+1) para el cierre

formal administrativo.

(P.M.I., 2008) - (Albaladejo, 2009)

Las principales diferencias con los Proyectos Tradicionales se dan en los modelos de contrato. Se elaboran contratos de diversos tipos para proporcionar flexibilidad a los clientes que contratan el proyecto.

Es la gestión de Compras quizás lo más controvertido cuando se habla de un proyecto con Scrum. Se tiene la idea de que la flexibilidad y variabilidad del alcance que está siempre en el “aire” cuando se va a contratar con un proveedor (en el caso de externalizaciones) un proyecto bajo Scrum plantea dificultades de cara a la fijación de un presupuesto entre ambas partes. Hay varios modelos de contrato que se adaptan a los proyectos en ambientes Ágiles, por ejemplo Target Cost es uno de ellos.

2. Metodologia

El alcance de la investigación es de tipo Analitico-Sintetico por que se realiza separación de un todo en sus partes o en sus elementos constitutivos y luego se unen los elementos para formar un todo. Para realiza la recolección de la información, se realizó entrevista a dos Pymes de desarrollo de software que trabajan como terceros para Gases de Occidente, las preguntas se realizadas fueron claves para identificar qué de metodología utilizan en sus proyectos de desarrollo de software. Se realiza investigación sobre cada uno de los procesos definidos como buenas prácticas por el PMBOK y la manera como algunas compañías utilizan la metodología de SCRUM. Con esta información se realiza un mapeo entre cada uno de los procesos del PMBOK y los proceso utilizados en SCRUM. Una vez realizado el mapeo entre PMBOK y SCRUM se procedió a redactar la monografía con el mapeo realizado.

3. Resultados

En primer lugar, aborda el proyecto siempre con enfoque incremental. Hay que romper con la dinámica establecida del ciclo de vida en cascada (waterfall). Puede que esto sea lo que más rompa con la metodología actual de Análisis, Diseño, Construcción y Pruebas. Si ahora cuando se afronta una planificación de un proyecto lo que se debe hacer es que hasta que no finalices una etapa no empiezas la otra, debemos cambiar este concepto. Puede ser complicado al principio, pero enfocarse en crear valor para el usuario/cliente de manera rápida, lo cual se traduce en implementar funcionalidades y características del producto que se está desarrollando antes de haber terminado, por ejemplo todo el análisis del mismo. Es decir, se crea mini-waterfall y entrega producto por incrementos.

Está claro que para hacer esto, en primer lugar se debe disponer de los elementos principales de la arquitectura de un producto con plena operatividad, lo cual obliga a tener implantadas las piezas base, los elementos indispensables del core del proyecto para que sobre ellos pueda desplegar las funcionalidades de manera incremental.

El enfoque de miniwaterfall puede ser útil en entornos de proyecto donde los formalismos de la Gestión del proyecto son más estrictos: administraciones públicas, entidades financieras etc. donde hay unos patrones metodológicos más rígidos que cumplir. Sobre todo piensa en qué cosas son más importantes y aportan más valor para el cliente/usuario para ir desplegando de una manera gradual los incrementos de producto.

Aplicar las técnicas Ágiles poco a poco: puede ser complicado pretender cambiar de golpe y aplicar todas las prácticas al mismo tiempo. Introduce las técnicas de una en una, y una vez que las conozcas todas y se esté familiarizado con ellas, podrá decidir cuáles son las que le pueden dar una mejor aproximación. Ejemplo:

1) La creación de un tablón Scrum donde ir llevando las tareas (tablón físico, con su post-it de colores o un tablón virtual, apóyate en cualquiera de las muchas herramientas que existen en el mercado para este fin).

2) La reunión diaria de equipo alrededor del tablero en donde cada uno de los miembros informa a los demás que lo que ha hecho el día anterior, lo que hará en el siguiente día y los problemas o impedimentos que se ha encontrado para realizar la tarea. Familiarizarse con estas dos prácticas y luego, poco a poco, incluir el resto de prácticas.

Preparase para el cambio total: una vez que se haya preparado el proyecto con enfoque incremental y se haya implantado con éxito las dos o tres prácticas más útiles, piense si el equipo está preparado para realizar un cambio total. Esta es una aproximación con más beneficios que las implementaciones parciales, pero implica un cambio más radical y es algo que no se consigue de la noche a la mañana. Todo lleva su tiempo. Esto requiere un cambio de mentalidad en la organización, pues vas a tener que conseguir “vender” Ágil a tus clientes/usuarios. Necesitará capacitación en otras técnicas Agiles como Técnicas de Planificación de Planning Poker, Técnicas para la definición de Historias de Usuario, Técnicas y herramientas para la elaboración de gráficos de seguimiento y planificación de Sprints, Técnicas para la definición del Backlog o Pila de producto,

Retrospectivas, etc. La recomendación es que si se está empezando con Scrum, se deberá tomar con calma, se aplique poco a poco e ir “inspeccionando y adaptando”.

No hay una receta única, no hay un proyecto único, no hay un equipo único, pero tiene que haber una conciencia de cambio, una mentalidad de aportar valor desde el principio y muchas ganas de mejorar.

4. Conclusiones

Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los momentos cruciales del proyecto, además deben tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovación. Las metodologías de dirección de proyectos son pesadas y que suponen obligatoriamente un “todo o nada”. Las metodologías ágiles son más modernas y más livianas que cualquiera de las tradicionales. Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre de un entorno volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales de dirección de proyectos obligan al cliente a tomar las decisiones al inicio del proyecto. Como último comentario se puede decir que No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.).

5. Glosario Scrum RoadMap - (Que podría traducirse como hoja de ruta) es una planificación del desarrollo de un software con los objetivos a corto y largo plazo, y posiblemente incluyendo unos plazos aproximados de consecución de cada uno de estos objetivos Sprint – que es la unidad básica, el contenedor del proceso de desarrollo, por lo general tiene una duración de 2 semanas, a veces puede ser 3. Product Owner – el director (s) del producto que crea las necesidades de los usuarios. Product Backlog – una lista priorizada de las necesidades de los usuarios, generalmente se ordena con base en el valor generado a la empresa. Sprint Planning Meeting (SPM) – precede a la Sprint y Sprint se inicia con SPM, donde el propietario del producto presenta. Planning Poker – Un juego de la estimación. Para cada caso de usuario una serie de rondas de estimaciones suceda, hasta que sólo queden 2 tarjetas de estimación planteadas. y el valor superior es elegido como el punto de la historia del usuario de que la historia del usuario. Baseline User Story – una historia de usuario que se ha seleccionado como línea de base. Otras historias de los usuarios suelen ser evaluados en relación a esta historia de usuario. Siempre es recomendable escoger una historia de usuario con 3 o 5 puntos de la historia de usuario. Spike – Una investigación. Algo que no es una historia de usuario, pero tiene una consecuencia. Ejemplo incluye, si una historia de usuario no se puede implementar porque hay ciertas incertidumbres. Entonces Spike se organiza cuando el equipo se ve en eliminar las incertidumbres. Sprint Review Meeting (SRM) La reunión con la que el Sprint concluye. En el SRM el equipo presenta las historias de los usuarios para el propietario (s) del producto. User Story – La descripción, por lo general en una frase de lo que el Propietario Usuario / producto quiere lograr, seguido de una lista de criterios de aceptación. También puede incluir imágenes, dibujos. Definition of Done (DoD) – Una lista de criterios que las tareas tiene que encajar con el fin de ser marcado como realizadas. Example: User Story Definition of Done - significa las siguientes tareas deben ser realizadas en un caso de usuario:

Se cumplen todos los criterios de aceptación

Implementación terminado

La revisión de código que lleva a cabo

Pruebas unitarias escritas

La prueba funcional se ha realizado

Las pruebas de integración se escriben / realizadas

Área Regresión prueba se realiza

No Bloqueador Relacionados o bug crítico está abierto Stand up – A diario 15 minutos de pie de encuentro, donde cada miembro del equipo le dice lo que han hecho desde el standup anterior hasta ahora, qué impedimentos tienen ellos, y lo que se puede trabajar hasta la próxima standup Impediment – es un obstáculo, puede ser cualquier cosa que no permite que el equipo sea productivo. Scrum Master es generalmente responsable de la fijación / eliminación de los impedimentos. Scrum Master— una parte importante de la metodología SCRUM. Una persona que se asegura de que el equipo se adhiere a los principios de Scrum y ceremonias SCRUM. Scrum Team— el equipo de desarrollo, Scrum Master y el equipo propietario del producto, junto Sit Down - Un, Mojitos-Amigos reunión inventado informal, donde el equipo se sienta en una sala de reunión y analiza si el Sprint va según lo previsto o no? que necesita ayuda en su tarea, etc Task split – El proceso de división de la historia de usuario en tareas. Por lo general, de un máximo de 6 horas cada una. Task - Tareas de muestra pueden ser "Implementación de la funcionalidad", "creación de pruebas unitarias", "Testing Funcional", "La investigación en el tema", "la creación de pruebas de selenio automatizado" ... etc Por lo general no se limitan y las tareas nuevas se pueden inventar R&D – Una tarea en la que antes de empezar a trabajar en la historia de usuario, el equipo comprueba las diferentes soluciones posibles para ver cuál es el adecuado Scrum Board – un tablero suele dividir a 5 zonas. "Historias de usuario", "Tareas", "tareas en curso", "tareas hechas", "Miscelánea". su actualización por el equipo durante standup de cada día. Visualiza el estado de ejecución del Sprint, y hace que todo sea transparente. Confidence Level – La confianza del equipo en porcentajes, que van a ser capaces de cerrar todas las historias de usuario que se han comprometido a, por lo general se discute en el final del standup. Si está bajo, las medidas apropiadas deben ser llevadas a cabo: por ejemplo, la historia de usuario nuevas prioridades por el dueño del producto. Burn Down Chart – Un gráfico que se actualiza periódicamente para mostrar el número de horas de trabajo que el equipo todavía tiene que gastar en las tareas, y la capacidad del equipo dejó en el momento. Lo ideal sería que el gráfico se incendió y se convierte en 0, en la víspera del día de Sprint reunión de revisión. Incident – algo que no es bien recibida por el equipo, sin embargo, tiene que hacer frente. Un incidente ocurrido en el entorno de producción. Ese es un ay potencial para el éxito de la carrera, ya que el equipo necesita para encontrar las horas extra para gastar en arreglar ese problema. Retrospective– Una reunión ordinaria, celebrada inmediatamente después de la SPM, donde el equipo miembros plantean temas tanto positivos como negativos, y el grupo más tarde los temas a discutir. Retrospective Box – Una caja de papel, donde durante el sprint, los miembros del equipo caen los temas

que quieren discutir en la próxima retrospectiva.

6. Bibliografía

Albaladejo, X. (15 de 05 de 2009). Proyectos ágiles.org. Obtenido de Scrum, la manera ágil de trabajar : http://www.proyectosagiles.org

Boehm, B. (2006). View of 20th and 21st Century Software Engineering. View of 20th and 21st Century Software Engineering, (págs. In: 28th international conference on Software engineering, pp. 12--29.). Shanghai, China.

Boyd, A. (2001). The five maxims of project satisfaction. London: Emerald Group Publishing Limited.

CABALLERO CERVANTES, O. H. (10 de 06 de 2010). Tecnologías de Información y Herramientas para la Administración de Proyectos de Software. Recuperado el 11 de Junio de 2006, de Revista Digital Universitaria: http://www.revista.unam.mx/vol.7/num6/art47/int47.htm

Christiane Gresse von Wangenheim, R. S. (2013). SCRUMIA—An educational game for teaching SCRUM in computing courses. The Journal of Systems and Software, 2675– 2687.

Expósito, E. D. (s.f.). Monografias. Obtenido de http://www.monografias.com/trabajos60/metodologias-desarrollo-software/metodologias-desarrollo-software.shtml

Gonzalez, R. -E. (27 de Julio de 2010). Comparacion de PMI y SCRUM fortaleza y debilidades.

Jeff Sutherland, J. S. (1993). concibieron, ejecutaron y documentaron el primer Scrum para desarrollo ágil de software en 1993.

Jim, H. (2004). Agile Project Management: Creating Innovative Products. Boston: Pearson Education.

JMMERLO. (25 de Octubre de 2012). Be-Klan. Recuperado el Agosto de 2013, de Be-Klan: http://be-klan.com/2012/10/25/metodologias-agiles-lean-y-predictivas-un-poco-de-historia/

Kent Beck, M. B. (2001). Manifiesto por el Desarrollo Ágil de Software. Recuperado el 2013, de Manifiesto por el Desarrollo Ágil de Software: http://www.agilemanifesto.org/

Lacouture, D. J. (01 de 02 de 2010). profesores.fi. Recuperado el 09 de 2013, de profesores.fi: http://profesores.fi-b.unam.mx/jlfl/Seminario_IEE/

Letelier Patricio, P. M. (15 de 01 de 2006). Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP). Recuperado el 15 de 12 de 2005, de Técnica Administrativa, Buenos Aires: http://www.cyta.com.ar/ta0502/b_v5n2a1.htm#(1)

Nonaka, H. T. (1986). The New New Product Developement Game. Harvard Business Review.

Ortega, R. J. (10 de Noviembre de 2010 ). Introducción a SCRUM. Obtenido de http://www.slideshare.net/hhKaoS/scrum-26058110

P.M.I., (. M. (2008). Guía de los Fundamentos para la Dirección de proyectos. Estados Unidos: PMBOK Guía, 4ta Edición.

Qumer, A. H.-S. (2007). An evaluation of the degree of agility in six agile methods and its applicability for method engineering. Journal - Information and Software Technology, 250-295.

Reynoso Carlos, K. N. (10 de 04 de 2004). http://carlosreynoso.com.ar/archivos/carlos-reynoso-metodos-heterodoxos-. Obtenido de carlosreynoso.com.ar.

Sampieri, R. H. (1997). Metodología de la Investigación. En R. H. Sampieri, Metodología de la Investigación (págs. 27-28). MCGRAW-HILL.

Schwaber, K. (1995). En 1995 formalizó el proceso para la industria de desarrollo de software.

Sliger, M. (Agosto de 2006). StickyMinds.com. Recuperado el Agosto de 2013, de StickyMinds.com: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=11133&tth=DYN&tt=siteemail&iDyn=2?

Tangient, L. (2013). METODOLOGIASAGILES. Recuperado el 16 de 07 de 2013, de METODOLOGIASAGILES: http://metodologiasagiles.wikispaces.com/metodos+agiles+vs+metodos+tradicionales