1

MARCO ÁGIL PARA PMI EN PEQUEÑAS Y MEDIANAS EMPRESAS DE

DESARROLLO DE SOFTWARE

Elaborado por:

Álvaro Eduardo Zapata Ramírez. 1131065

Luis Carlos Bastidas Guerrero. 1131186

Doctor:

Ronald Rojas Alvarado

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

ESPECIALIZACIÓN EN GESTIÓN INTEGRAL DE PROYECTOS SANTIAGO DE CALI

2014

2

MARCO ÁGIL PARA PMI EN PEQUEÑAS Y MEDIANAS EMPRESAS DE

DESARROLLO DE SOFTWARE

Álvaro Eduardo Zapata Ramírez. 1131065

Luis Carlos Bastidas Guerrero. 1131186

Monografía para optar el titulo Especialista en Gestión Integral de Proyectos

Asesor

PhD. Ronald Rojas Alvarado

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

ESPECIALIZACIÓN EN GESTIÓN INTEGRAL DE PROYECTOS SANTIAGO DE CALI

2014

3

Tabla de contenido

1. INTRODUCCIÓN. .....................................................................................................................7

1.1. DESCRIPCIÓN DEL PROBLEMA .............................................................................................7

1.2. PREGUNTA GENERADORA DE LA INVESTIGACIÓN ...............................................................9

1.3. JUSTIFICACIÓN DEL PROBLEMA ...........................................................................................9

1.4. OBJETIVO GENERAL ........................................................................................................... 10

1.5. OBJETIVOS ESPECÍFICOS.................................................................................................... 10

1.6. VARIABLES DE INVESTIGACIÓN ......................................................................................... 10

1.6.1. Dependientes ................................................................................................................ 11

1.6.2. Independientes ............................................................................................................. 11

2. MARCO REFERENCIAL ....................................................................................................... 11

2.1. Marco Conceptual ............................................................................................................. 11

2.1.1. Administración de proyectos bajo PMI ......................................................................... 11

2.1.1.1. Concepto de Proyecto. .............................................................................................. 11

2.1.1.2. ¿Qué es el PMBOK? ................................................................................................... 12

2.1.1.3. Administración de Proyectos según PMI. ................................................................. 12

2.1.1.4. Grupos de Proceso en la Gestión Tradicional de Proyectos basados en PMI ........... 13

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

2.1.2.1 ¿Qué significa ágil? ........................................................................................................ 18

2.1.2.2. Introducción al modelo ágil. ..................................................................................... 18

2.1.2.3. El Manifiesto Ágil ...................................................................................................... 19

2.1.2.4. Metodología ágil Scrum ............................................................................................ 22

2.2. Antecedentes y Marco Teórico ......................................................................................... 25

2.2.1 Gestión Tradicional de Proyectos bajo PMI ................................................................. 25

2.2.2 Gestión de proyectos bajo metodologías agiles ........................................................... 27

3. MARCO METODOLÓGICO.................................................................................................. 30

3.1. Investigación Aplicada ...................................................................................................... 30

3.2. Fuentes de Información .................................................................................................... 30

3.3. Técnicas de Investigación .................................................................................................. 32

4

4. DESARROLLO ....................................................................................................................... 33

4.1. Comparación PMBOK vs SCRUM ...................................................................................... 33

4.2. Ciclo de Vida de un Proyecto ............................................................................................ 35

4.3. Características de los Autores ........................................................................................... 36

4.4. Diferencias y Similitudes ................................................................................................... 38

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

5. Analizando algunos artículos sobre metodologías ágiles .............................................. 48

5.1. Una década de metodologías ágiles: Hacia la explicación del desarrollo ágil de ............. 48

5.2. SCRUMIA- Un juego educativo para la enseñanza de SCRUM ........................................ 48

6. CONCLUSIONES ................................................................................................................... 50

7. Bibliografía............................................................................................................................... 51

8. Glosario Scrum ....................................................................................................................... 53

9. Anexos ..................................................................................................................................... 56

Anexo 1: CRONOGRAMA .............................................................................................................. 56

Anexo 2: ENCUESTA DE METODOLOGÍA ....................................................................................... 57

5

ÍNDICE DE FIGURAS

Figura 1. -Grupo de Procesos de la Dirección de Proyectos ....................................... 15

Figura 2. -Grupo de procesos de SCRUM ............................................................... 21

Figura 3. Fases del Ciclo de Vida del Proyecto ............................................................ 33

Figura 4. Fases y sub-fases del ciclo de vida de un proyecto ...................................... 34

Figure 5: PMBOK Project Management Process Groups mapped................................ 39

6

ÍNDICE DE TABLAS

Tabla 1. Cuadro comparativo entre Metodologías .......................................................... 6

Tabla 2. Cuadro de variables ......................................................................................... 9

Tabla 3. Cuadro Conceptual Dirección de Proyectos ................................................... 10

Tabla 4. Grupo de procesos para la administración de proyectos ................................ 12

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

Tabla 6. Principales valores del desarrollo Ágil. ........................................................... 17

Tabla 7. Cuadro Conceptual de metodologías agiles ................................................... 18

Tabla 8. Grupo de componentes para la administración de proyectos ........................ 21

Tabla 9. Cuadro de Estructura de Antecedentes .......................................................... 24

Tabla 10. Ejemplos de empresas que implementaron metodología ágil ...................... 25

Tabla 11. Cuadro de Estructura de Antecedentes ........................................................ 26

Tabla 12. Cuadro de Fuentes de Información por objetivos del proyecto ..................... 29

Tabla 13. Cuadro de Técnicas de Investigación .......................................................... 31

Tabla 14. Cuadro comparativo entre los componentes del marco .............................. 31

Tabla 15. Cuadro comparativo entre los autores del marco de referencia ................ 34

Tabla 16. Cuadro comparativo de las características de los autores del marco .......... 36

Tabla 17. Práctica mapeada del área de conocimiento Gestión de la integración ........ 39

Tabla 18. Práctica mapeada del área de conocimiento Gestión del alcance ................ 40

Tabla 19. Práctica mapeada del área de conocimiento Gestión del tiempo .................. 41

Tabla 20. Práctica mapeada del área de conocimiento Gestión de Costos .................. 42

Tabla 21. Práctica mapeada del área de conocimiento Gestión de la Calidad ............. 42

Tabla 22. Práctica mapeada del área de conocimiento Gestión del Recurso ............... 43

Tabla 23. Práctica mapeada del área de conocimiento Gestión de la Comunicación ... 44

Tabla 24. Práctica mapeada del área de conocimiento Gestión del Riesgo ................. 44

Tabla 25. Práctica mapeada del área de conocimiento Gestión de Compras ............... 45

7

1. INTRODUCCIÓ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.1. DESCRIPCIÓN DEL PROBLEMA

En la última década se ha dado un creciente aumento de pequeñas y medianas empresas de software que se constituyen y no cuentan con una oficina de proyectos y una metodología que les ayude a desarrollar con orden y planificación

8

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; en dicho escenario surge la necesidad de implementar nuevas formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administración de proyectos, sin dejar de lado la colaboración a distancia, el outsourcing, la mejora de la calidad, la generación y distribución de conocimiento y coordinación de varios proyectos, entre otras. Los principales problemas que enfrentan dichas empresas se encuentran que (Boehm, 2006):

Se utilizan metodologías ágiles pero no de manera estructura, lo que quiere decir que no es fácil identificar qué tipo de metodología utilizan (Scrum, Xp etc.).

Los encargados y participantes de los proyectos no tienen claramente definidos sus roles y funciones formalmente y por escrito, se realizan por costumbre y según la necesidad del momento.

Los proyectos no tienen una metodología estándar para el control y seguimiento en cuanto a su alcance, costo, tiempo, comunicaciones y calidad

Generalmente no existe plantillas adecuadas para llevar un control de cambios formal en el alcance, ni para la planificación en el seguimiento de la calidad del producto del proyecto.

La gestión del tiempo del proyecto se limita a un cronograma de trabajo inicial y posiblemente uno final, no utilizándose herramientas adecuadas de control de cambios del mismo.

No hay plantillas ni herramientas para documentar las lecciones aprendidas.

Generalmente no se trabaja enfocado en la rentabilidad del proyecto. Sin base objetiva para evaluar la calidad o para resolver problemas. Inexistencia o reducción de las actividades de mejora de la calidad.

Nótese una analogía entre Metodologías Ágiles vs Metodologías Tradicionales La tabla No.1, evidencia la diferencia entre los conceptos de metodologías agiles y metodologías tradicionales. Tabla 1. Cuadro comparativo entre Metodologías Ágiles vs Metodologías Tradicionales:

MÉTODOS AGILES MÉTODOS TRADICIONALES

Basadas en heurísticas provenientes de

prácticas de producción de código.

Basadas en normas provenientes de

estándares y mejores prácticas

seguidos por el entorno de desarrollo

Impuestas internamente (por el equipo). Impuestas externamente.

9

Proceso menos controlado, con pocos

principios

Proceso mucho más controlado, con

numerosas políticas/normas.

No existe contrato tradicional o al

menos es bastante flexible.

Existe un contrato prefijado.

El cliente es parte del equipo de

desarrollo.

El cliente interactúa con el equipo de

desarrollo mediante reuniones.

Grupos pequeños (<10 integrantes) y

trabajando en el mismo sitio.

Grupos grandes y posiblemente

distribuidos.

Pocos artefactos. Más artefactos.

Pocos roles Más roles.

Menos énfasis en la arquitectura del

software.

La arquitectura del software es esencial

y se expresa mediante modelos.

(Letelier Patricio, 2006)

1.2. PREGUNTA GENERADORA DE LA INVESTIGACIÓN ¿Se puede diseñar un marco de trabajo que permita aplicar técnicas de desarrollo

de software ágiles y cumplir con un lineamiento a las recomendaciones del

PMBOK 4TH_EDITION?

1.3. JUSTIFICACIÓN DEL PROBLEMA En la actualidad los proyectos de desarrollo de software presentan retos únicos para los administradores de proyectos. En primer lugar, el software es un producto intangible y difícil de explicar bien; en contadas ocasiones un mismo sistema se construye dos veces, lo que hace que cada vez los desarrollos de software sean diferentes. En este sentido, el desarrollo de software de forma repetida ha surgido como una técnica para minimizar este tipo de problemas por medio de la utilización del uso regular de puntos de revisión. Adicionalmente, una colaboración más estrecha entre el usuario y los equipos de desarrollo permiten obtener una retroalimentación más inmediata, permitiendo responder a las distintas necesidades de negocio de una forma más efectiva. Existen precedentes que evidencian que el uso tradicional de un modelo para la administración de proyectos de software es poco efectivo. Ya que éste asume que la construcción del software se puede dar de forma continua y lineal. Las metodologías ágiles surgen precisamente para eliminar este problema, identificando de forma efectiva, en un modelo de colaboración cercano al cliente y bajo principios específicos la administración de un proyecto de software como lo sugiere el PMBOK. Es por este motivo que la elaboración de este trabajo cobra vital importancia, ya que pretende involucrar las mejores técnicas, herramientas y procesos de PMBOK

10

4TH_EDITION e interrelacionarlas con metodologías Agiles para así, obtener lo mejor de SCRUM con el marco de referencia del PMBOK y en consecuencia demostrar con este trabajo que se puede gestionar proyectos de corto y mediano plazo involucrando estos dos marcos de trabajo. Las empresas están migrando a procesos Ágiles porque el mercado de tecnología exige que sus proveedores tengan la habilidad de responder rápidamente a los cambios. Para poder competir en la economía global, las empresas tienen que cambiar rápidamente y así suministrar soluciones para una base de clientes que cada vez tiene más y más opciones disponibles. Las iniciativas Ágiles prometen entregas más rápidas de códigos funcionando, mayor calidad y un equipo de desarrollo dedicado, capaz de cumplir con sus compromisos. El modelo cascada (waterfall) tradicional, con sus fases largas y grandes inversiones “en las fases iniciales de los proyectos”, no tiene la flexibilidad para responder rápidamente al mercado.

1.4. OBJETIVO GENERAL Elaborar una investigación que permita identificar como los procesos de cada una de las áreas de conocimiento del PMBOK 4TH_EDITION, pueden ser mapeadas en metodologías ágiles como SCRUM.

1.5. OBJETIVOS ESPECÍFICOS

Comparar y relacionar los elementos esenciales de las prácticas ágil/scrum y prácticas PMI.

Identificar las técnicas utilizadas en las prácticas ágil/scrum y prácticas PMI.

Demostrar por medio de una investigación, que es posible administrar proyectos de desarrollo de software con Scrum basados en las mejores prácticas del PMBOK.

1.6. VARIABLES DE INVESTIGACIÓN

La tabla No. 2 expone las variables de investigación que sirvieron de guía para la

elaboración de este trabajo.

11

Tabla 2. Cuadro de variables

Dependientes Independientes

Aplicación de técnicas para la

gestión de proyectos bajo

PMI y metodologías

ágiles/SCRUM, para el

desarrollo de software.

- Los beneficios que pueda aportar la administración de un proyecto de software.

- Realizar esquema de administración de proyecto alineado a las necesidades empresariales y los principios dictados por el PMBOK 4TH_EDITION.

- Demostrar la posibilidad de administrar proyectos con metodologías ágiles asociadas a las mejores prácticas del PMBOK 4TH_EDITION.

Elaboración propia a partir del libro PMBOK 4TH_EDITION y THE SCRUM

PRIMER.

1.6.1. Dependientes

Aplicación de técnicas para la gestión de proyectos bajo PMI y metodologías ágiles/SCRUM, para el desarrollo de software.

1.6.2. Independientes

Los beneficios que pueda aportar la administración de un proyecto de software.

Realizar esquema de administración de proyecto alineado a las necesidades empresariales y los principios dictados por el PMBOK 4TH_EDITION.

Demostrar la posibilidad de administrar proyectos con metodologías ágiles aunados a las mejores prácticas del PMBOK 4TH_EDITION.

2. MARCO REFERENCIAL

2.1. Marco Conceptual

2.1.1. Administración de proyectos bajo PMI

2.1.1.1. Concepto de Proyecto.

Según el PMBOK (2008), 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).

12

2.1.1.2. ¿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). É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. (P.M.I., 2008)

2.1.1.3. Administración de Proyectos según PMI.

Es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para cubrir las necesidades o superar las expectativas de los diversos stakeholders.

La administración de proyectos consiste en aplicar e integrar los grupos de procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre (ciclo de vida del proyecto). El director de proyecto es el responsable de lograr los objetivos del proyecto.

La tabla No. 3 describe los diferentes conceptos de dirección de proyectos emitidos por distintos autores.

Tabla 3. Cuadro Conceptual 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

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

13

es el camino?

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.

Elaboración propia a partir de investigaciones de los autores anteriormente

mencionados.

2.1.1.4. Grupos de Proceso en la Gestión Tradicional de Proyectos basados en PMI

Dado que la Administración de Proyectos “consiste en la aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades de un proyecto” (PMI, 2008, p.6), con el fin primordial de satisfacer, cumplir y superar las necesidades y expectativas de los involucrados. Se logra mediante la aplicación e integración adecuadas de los 42 procesos de la dirección de proyectos, agrupados lógicamente, que conforman los 5 grupos de procesos. Estos 5 grupos de procesos son:

Iniciación, Planificación, Ejecución, Seguimiento y Control, y Cierre.

La tabla No. 4 describe la conclusión de cada uno los grupos de procesos del PMBOK

14

Tabla 4. 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

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

É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

15

proyectos. los objetivos definidos y que la información sea distribuida a todos los interesados según el plan establecido para las comunicaciones.

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.

(P.M.I., 2008) La tabla No. 5 describe el objetivo de cada uno de las áreas de conocimiento del PMBOK Tabla 5. Á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

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

- Realizar el plan del proyecto, realizando

16

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.

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

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

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

17

organizacional, adquisición de staff, y desarrollo del equipo.

- 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

(P.M.I., 2008) La figura No. 1 describe los procesos de seguimiento y control:

Figura 1. -Grupo de Procesos de la Dirección de Proyectos (P.M.I., 2008)

18

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

2.1.2.1 ¿Qué significa ágil? La definición de “ágil” según la Real Academia Española es: Capaz de moverse con ligereza y facilidad. Pero ¿cuál es la definición de ágil desde el punto de vista de desarrollo de software? Según Qumer y Henderson-Sellers (2007, p. 280 – 295): La agilidad es un comportamiento persistente o habilidad, de entidad sensible, que presenta flexibilidad para adaptarse a cambios, esperados o inesperados, rápidamente; persigue la duración más corta en tiempo; usa instrumentos económicos, simples y de calidad en un ambiente dinámico; y utiliza los conocimientos y experiencia previos para aprender tanto del entorno interno como del externo.

2.1.2.2. Introducción al modelo á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).

Dentro de los principales problemas que se pueden destacar de las metodologías convencionales se encuentran:

Se desgastan en el cumplir requisitos del proyecto, porque lo ven como una fase previa al desarrollo del mismo que, una vez completada, debe proporcionar una fotografía exacta de qué desea el cliente.

Se vuelven muy rígidos en evitar que se produzcan cambios en el conjunto de requisitos inicial, puesto que a medida que avanza el proyecto resulta más costoso solucionar los errores detectados o introducir modificaciones.

En la mayoría de las ocasiones el cliente no conoce sus propias necesidades con la profundidad suficiente como para definirlas de forma exacta a priori y, a menudo, estas necesidades y sus prioridades varían durante la vida del proyecto.

La forma tradicional de desarrollo de software, utiliza demasiada documentación, que en muchas ocasiones no siempre es muy útil.

19

Las Fases de un Proyecto Ágil:

Imaginar: Se genera una visión colectiva sobre el producto de software a desarrollar.

Especular: Se establecen hipótesis sobre las especificaciones del producto, sabiendo que conforme el proyecto avance, estas especificaciones irán evolucionando.

Explorar: Se implementan las especificaciones de forma iterativa. Adaptar: Se analizan los resultados de dichos experimentos y se realizan los ajustes necesarios para las siguientes iteraciones. Se evalúan cuatro aspectos: funcionalidad del producto, calidad técnica del producto, estatus del proyecto, y desempeño del equipo. Cerrar: El cierre de cada iteración sirve para dar un pequeño break y tomar fuerza para la siguiente. (Gonzalez, 2010).

2.1.2.3. 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. 6) La tabla No. 6 Describe como el Manifiesto comienza enumerando los principales valores del desarrollo ágil: Tabla 6. Principales valores del desarrollo Ágil.

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.

(Letelier Patricio, 2006)

20

Los valores anteriores inspiran los doce principios del manifiesto. Estos principios son las características que diferencian un proceso ágil de uno tradicional. Estos son:

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

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Los cambios deben verse como algo positivo.

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

IV. Los integrantes del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

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

VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso. VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener un ritmo constante.

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

X. La simplicidad es esencial. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos.

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos auto-organizados.

XII. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo, y según esto ajusta su comportamiento.

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

Tabla 7. 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 Takeuchi

Describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales,

- Chin, Gary (2004).

21

Ikujiro Nonaka

denominada SCRUM. Es comparado con el rugby, donde el equipo entero «actúa como un sólo hombre para intentar 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).

1990 Alistair

Cockburn

Desarrolla un conjunto de metodologías llamadas Crystal Methodology, que se caracterizan por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar.

- Cockburn, Alistair. (2004). - Cockburn (2001).Estudio en IBM

1991

Ken Schwaber

Jeff Sutherland

Desarrollaron una aproximación más certera de Scrum, la cual la llevaron a poner en práctica en diferentes compañías.

- Rising, L., Janoff, N.S. (2000).

1994

Consorcio de DSDM

Reino Unido

Se define el marco para desarrollar un proceso de producción de software, basado en el desarrollo rápido de aplicaciones, denominado Método de Desarrollo Dinámico de Sistemas- Dynamic Systems Development Method (DSDM). Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación.

-Coleman and Verbruggen, (1998

-Stapleton, Jennifer (2003)

1995

Ken Schwaber

Jeff

Sutherland

Durante un encuentro desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo Scrum, siendo ésta la primera aparición pública de la metodología.

-Schwaber. Ken. Agile Project Management with Scrum. 2004. -Jeff Sutherland in Scrum Tuning.

1996 Kent Beck

Creó el método de Programación Extrema (usualmente conocida como XP). Centrado en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, y simplicidad en las soluciones implementadas.

-Kent Beck - Extreme Programming Explained: Embrace Change (1999). -Solís, M. (2003). Una explicación de la programación extrema (XP)

22

1997

Jeff De Luca

Peter Coad

Impulsan una disciplina denominada Desarrollo Dirigido por Modelos -Feature Driven Development (FDD), en la cual definen un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software.

- Palmer, S. R., & Felsing, M. (2001). A practical guide to feature driven development.

1998 Jim

Highsmith

Propuso el modelo de desarrollo de software adaptativo -Adaptive Software Development (ASD); se centra en la colaboración humana y la organización del equipo. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. Tiene tres fases esenciales: especulación, colaboración y aprendizaje.

-Sommerville, I. (2005). Ingeniería del software. -Highsmith, J. A. (2000). Adaptive software development. New York

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.agilemanifiesto.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.org

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

2.1.2.4. 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).

23

La figura No. 2 se muestra los grupos de procesos utilizados en scrum.

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

En la tabla No. 8 se describe por componente los participantes y el esquema

utilizado en Scrum.

Tabla 8. 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 -

24

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

25

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)

2.2. Antecedentes y Marco Teórico

2.2.1 Gestión Tradicional de Proyectos bajo PMI

PMI Internacional fue fundado en 1969 con socios voluntarios. Durante los años

setenta PMI se desarrolló principalmente en el campo de la ingeniería, mientras

tanto el mundo de los negocios desarrollaba sus proyectos a través de

especialistas de la misma empresa y formaban grupos de trabajo llamados “Task

Force”. Para los años ochenta, el mundo de los negocios comenzó gradualmente

a dirigir sus esfuerzos por proyectos. (P.M.I., 2008)

26

Durante este tiempo el PMI, a través del comité de estándares y colaboradores

(entre ellos empresas, universidades, asociaciones de profesionales, especialistas

y consultores en proyectos) realizó el estudio, evaluación y revisión de los

estándares generalmente aceptados a nivel internacional, dando como resultado

los estándares que representan el cuerpo de conocimientos de la Dirección de

Proyectos, cuyo título original es “Project Management Body of Knowledge”

(PMBOK). En 1987 se publicó su primera edición. (P.M.I., 2008)

A través de la tabla No. 9 se describe el objetivo, que necesidades satisface y

conclusiones de la gestión tradicional de proyecto bajo PMI.

Tabla 9. Cuadro de Estructura de Antecedentes.

Autor Objetivos Médelo ¿Qué necesidades Satisface? Conclusiones PMI • Promover

la dirección de proyectos.

• Compartir la experiencia internacional y todo el conocimiento a través del desarrollo de profesionales.

• Desarrollar calidad en los recursos humanos para la dirección de proyectos.

• Consolidar estándares internacionales.

• Certificación de profesionales en

Marco de trabajo

del PMBOK

Administrativas. Los proyectos son una forma de organizar las actividades que no pueden ser tratadas dentro de los límites operativos de la organización. Las mejores prácticas integradas en PMBOK ayudan a los proyectos en general a lograr los resultados esperados de forma más efectiva, garantizando que éstos sirven como inductores para la consecución de los objetivos definidos en el plan estratégico. Regulación. Comprender y aplicar los conocimientos, habilidades, herramientas y técnicas generalmente reconocidas como mejores prácticas; no es suficiente por sí solo para garantizar el éxito de un proyecto. Aunque la regulación a la que está sujeta la empresa es independiente de la administración de los proyectos; las mejores prácticas definidas en el PMBOK pueden ser tomados como referencia para la planeación, organización y control de las actividades de los proyectos destinados a garantizar el cumplimiento de los requerimientos regulatorios. Control. PMBOK contempla un capítulo especialmente integrado para facilitar los procesos involucrados en el desarrollo y

El generar conocimiento por cada experiencia que se tiene de las actividades laborales contribuye a una mejor preparación, ya que la práctica va conformando habilidades y cualidades para cubrir muchos aspectos como el orden, el control, las decisiones, entre otras. Por tal motivo la persona con mayor capacidad y conocimiento, es nombrada como director de dicho proyecto. Así, para el control de los proyectos o tener los estándares adecuados para ser un Director de Proyecto, nos apoyamos en PMI y considerando los

27

proyectos reconocidos a nivel mundial.

gestión de los riesgos asociados a un proyecto. Seguridad. Las mejores prácticas compiladas en el PMBOK ayudan a la empresa a administrar los proyectos que tienen por objetivo garantizar la disponibilidad, confidencialidad e integridad de la información, ya que proporciona prácticas probadas para mejorar los procesos de administración de los proyectos de seguridad.

objetivos de dicho instrumento permitirá una preparación para un mejor desarrollo y control del proyecto.

(P.M.I., 2008)

2.2.2 Gestión de proyectos bajo metodologías agiles Algo de Scrum El concepto de Scrum tiene su origen en un estudio de 1986, sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japón y los Estados Unidos (cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de Honda, ordenadores de HP, entre otros). Los equipos que desarrollaron estos productos partían de requisitos muy generales, así como novedosos, y debían salir al mercado en mucho menos tiempo, del que se tardó en lanzar productos anteriores. Estos equipos seguían patrones de ejecución de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de Scrum (melé en español). (Nonaka, 1986) Desde 1995 miles de proyectos en todo el mundo han utilizado Scrum para el desarrollo de productos, tanto en empresas pequeñas, “startups” con tan sólo 5 personas desarrollando un producto, como en multinacionales, entre las que se encuentran en la siguiente tabla No 10: La Tabla No. 10 muestra ejemplos de empresas que utilizan metodologías ágiles como Scrum. Tabla 10 ejemplos empresas que implementado metodología ágil

Sectores Nombres

Media y Telcos BBC, BellSouth, British Telecom, DoubleYou, Motorola, Nokia, Palm, Qualcomm,Schibsted, Sony/Ericsson, Telefonica I+D, TeleAtlas, Verizon

28

Software, Hardware Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailén, IBM, Intel, Microfocus, Microsoft, Novell, OpenView Labs, Plain Concepts, Primavera, Proyectalis,Softhouse, Valtech, VersionOne.

Internet Amazon, Google, mySpace, Yahoo

ERP SAP

Banca e Inversión Bank of America, Barclays Global Investors, Key Bank, Merrill Lynch

Sanidad y Salud Patientkeeper, Philips Medical

Defensa y Aeroespacial

Boeing, General Dynamics, Lockheed Martin

Juegos Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic Arts

Otros 3M, Bose, GE, UOC, Ferrari

(Albaladejo, 2009) A través de la tabla No. 11 se describe el objetivo, que necesidades satisface y conclusiones de la gestión tradicional de proyecto bajo SCRUM Tabla 11. Cuadro de Estructura de Antecedentes en Metodología Ágil.

Autor Objetivos Modelo ¿Qué necesidades Satisface?

Conclusiones

Ken Schwaber

Jeff Sutherland

• Promover la agilidad en el desarrollo de proyectos.

• Facilitar la entrega de productos de calidad a tiempo.

• Crear equipos altamente productivos y motivados.

• Utilizar un proceso de gestión ligero aún en proyectos complejos.

• Gestión

Metodología ágil

SCRUM

Administrativas: Las metodologías agiles son una forma de organizar y realizar eficientemente las actividades que permiten el desarrollo de los proyectos en las organizaciones. Mediante 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. Regulación: El solo hecho de tener equipos auto-organizados y auto-gestionados, permite comprender y aplicar todos los conocimientos, habilidades,

El generar equipos auto-organizados y gestionados, en un clima organizacional donde sus principios son la transparencia, inspección y la adaptación; que involucran un alto grado de innovación, Competitividad, flexibilidad y productividad son fundamentales para garantizar

29

regular de las expectativas del cliente y basada en resultados tangibles.

• Flexibilidad y adaptación respecto a las necesidades del cliente.

• Gestión sistemática del Retorno de Inversión (ROI).

• Alineamiento entre el cliente y el equipo de desarrollo.

• Crear equipos altamente productivos.

herramientas y técnicas para desarrollar de manera ágil los proyectos. Control: 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 para garantizar el éxito de un proyecto. Seguridad: En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. Todo esto velando por la confidencialidad e integridad de la información.

el éxito de un proyecto. Por otro lado Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costos se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias en el proyecto.

(Schwaber, 1995) - (Albaladejo, 2009)

30

3. MARCO METODOLÓGICO

3.1. Investigación Aplicada El procedimiento metodológico para una investigación define los elementos para el desarrollo de la investigación, en éste se define el tipo de investigación a utilizar, los tipos de fuentes de información, las técnicas y la forma en que se recolectarán datos y se analizarán para interpretarlos. También conocida como práctica o empírica, busca la aplicación o utilización de los conocimientos que se adquieren; ésta, depende de los avances y resultados de la investigación básica, lo que le interesa al investigador son las consecuencias prácticas. Para éste trabajo se utilizará el método denominado analítico-sintético, donde la investigación documental será la principal fuente de información, para su desarrollo.

3.1.1. Método Analítico: Este método implica el análisis (del griego análisis, que significa descomposición), esto es la separación de un todo en sus partes o en sus elementos constitutivos. Se apoya en que para conocer un fenómeno es necesario descomponerlo en sus partes.

3.1.2. Método Sintético: Implica la síntesis (del griego synthesis, que significa reunión), esto es, unión de elementos para formar un todo.

El juicio analítico implica la descomposición del fenómeno, en sus partes constitutivas. Es una operación mental por la que se divide la representación totalizadora de un fenómeno en sus partes. En consecuencia, el presente trabajo utilizará los aspectos de metodología que a continuación se describen.

3.2. Fuentes de Información Para la siguiente investigación serán utilizadas las siguientes fuentes de información, ya que serán insumos que examinarán, describirán y explicaran los hechos de la investigación:

3.2.1. Fuentes Primarias: Constituyen el objetivo de la investigación bibliográfica o revisión de la literatura y proporcionan datos de primera mano (Dankhe, 1986). Un ejemplo de éstas son los libros, antologías, artículos de publicaciones periódicas, monografías, tesis y disertaciones, documentos oficiales, reportes de asociaciones, trabajos

31

presentados en conferencias o seminarios, artículos periodísticos, testimonios de expertos, películas, documentales y videocintas. (Sampieri, 1997) En la presente investigación se utilizarán las siguientes fuentes de investigación primarias:

Publicaciones en Internet.

Documentos Originales

Apuntes de investigación

Autobiografías

3.2.2. Fuentes Secundarias: Consisten en compilaciones, resúmenes y listados de referencias publicadas en un área de conocimiento en particular (son listados de fuentes primarias). Es decir, reprocesan información de primera mano. Por ejemplo: la American Business Communication Association y la International Communication Association, publican desde 1974 —anualmente el libro titulado “Organizational Communication”, en el cual se reportan y comentan brevemente los artículos, libros, tesis y disertaciones y otros documentos relevantes dentro del campo de la comunicación en las organizaciones (publicados básicamente en inglés, aunque también se incluyen referencias en otros idiomas). (Sampieri, 1997) Y las siguientes fuentes de investigación secundarias son:

Libros de texto como el PMBOK 4TH_EDITION, tesis, documentos relacionados

Artículos de revistas

Enciclopedias

Biografías Después de escribir las diferentes fuentes de información que serán utilizadas en el desarrollo de la investigación del presente trabajo. A continuación se presenta la tabla No. 12 que describe los objetivos planteados en el proyecto y sus respectivas fuentes de información:

Tabla 12. Cuadro de Fuentes de Información por objetivos del proyecto

Objetivos Fuentes de información

Primarias Secundarias

Comparar y relacionar los elementos esenciales de las prácticas ágil/scrum y

Publicaciones en Internet.

PMBOK 4TH_EDITION, tesis, documentos

32

prácticas PMI. relacionados

Identificar las técnicas utilizadas en las prácticas ágil/scrum y prácticas PMI.

Publicaciones en Internet.

PMBOK 4TH_EDITION, tesis, documentos relacionados

Diseñar modelo ágil para proyectos de desarrollo de software basados en prácticas PMI.

Publicaciones en Internet.

PMBOK 4TH_EDITION, tesis, documentos relacionados

Elaboración propia a partir del libro PMBOK 4TH_EDITION

3.3. Técnicas de Investigación

La investigación es un proceso que requiere de una selección adecuada del tema objetivo, de un buen planteamiento de la problemática a solucionar y de la definición del método científico que se utilizará para llevar a cabo dicha investigación. Sumado a esto, se requiere de técnicas y herramientas que auxilien la realización de la investigación, en este caso al desarrollo de su tesis. Entre las técnicas más utilizadas y conocidas se encuentran (Lacouture, 2010):

La investigación documental.

La investigación de campo.

3.3.1. Investigación documental

La investigación de carácter documental se apoya en la recopilación de antecedentes a través de documentos gráficos formales e informales, cualquiera que éstos sean, donde el investigador fundamenta y complementa su investigación con lo aportado por diferentes autores. Los materiales de consulta suelen ser las fuentes bibliográficas, iconográficas, fonográficas y algunos medios magnéticos (Lacouture, 2010).

3.3.2. Investigación de campo

La investigación de campo es la que se realiza directamente en el medio donde se presenta el fenómeno de estudio. Entre las herramientas de apoyo para este tipo de investigación se encuentran (Lacouture, 2010):

El cuestionario.

La entrevista.

La encuesta.

La observación.

La experimentación

33

A continuación se presenta la tabla No. 13 que resume la técnica de investigación que será utilizada por cada uno de los objetivos definidos: Tabla 13. Cuadro de Técnicas de Investigación utilizadas por objetivos

Objetivos Técnicas de investigación

Comparar y relacionar los elementos esenciales de las prácticas ágil/scrum y prácticas PMI.

Para alcanzar el objetivo planteado se utilizará las técnicas de investigación documental.

Identificar las técnicas utilizadas en las prácticas ágil/scrum y prácticas PMI.

Para alcanzar el objetivo planteado se utilizará las técnicas de investigación documental y observación no participativa.

Demostrar por medio de una investigación, que es posible administrar proyectos de desarrollo de software con Scrum basados en las mejores prácticas del PMBOK.

Para alcanzar el objetivo planteado se utilizará las técnicas de investigación documental.

4. DESARROLLO

4.1. Comparación PMBOK vs SCRUM

La tabla No. 14 muestra una comparación entre cada uno de los componentes del marco de trabajo PMBOK y el marco de trabajo SCRUM. Tabla 14. Cuadro comparativo entre los componentes del marco de trabajo PMBOK y el marco de trabajo SCRUM.

ÍTEM PMBOK SCRUM

Etapas Fase

Sub-Fase

Release

Sprint

Modelo Especialización: Miembros de

equipo y roles bien delimitados y casi independientes lo que no considera una interacción cercana entre roles.

Fases: Delimitadas y rígidamente definidas, por lo que las tareas se concluyen en una fase y la acción de los roles se encuentra encasillada en una o más fases.

Requisitos detallados: Los

requerimientos llegan al equipo de desarrollo a través de un

Directriz: Equipo y roles

definidos, todo el equipo es auto-organizado y es muy cercana su interacción.

Actividades: Se ejecutan en

el momento en que se requieren, son más libres, no rígidas.

Requisitos: Llegan al equipo

por una pila de productos. El cliente interactúa

34

artefacto. El cliente no interactúa estrechamente con el producto durante su desarrollo.

Seguimiento del plan: No se

experimenta con opciones atractivas que se puedan presentar durante el transcurso del proyecto sino que se controla rígidamente el plan establecido.

estrechamente en todo el desarrollo del proyecto.

Planificación: Es permitido ajustarla e incluso poder reformular el alcance; lo que

permite actualizar los requerimientos del proyecto.

Elementos

Claves

Áreas de Conocimiento

Gestión de la Integración.

Gestión del Alcance.

Gestión del Tiempo.

Gestión de Costos.

Gestión de Calidad.

Gestión de Recursos Humanos.

Gestión de Comunicaciones.

Gestión del Riesgos.

Gestión de Adquisiciones.

Productos: Lista de Objetivos/Requisitos

priorizados (Backlog Products).

Lista de Tareas de la iteración (Sprint Backlog).

Gestión del Tiempo.

Incremento del Producto.

Reuniones: Planificación de la iteración

(Sprint Planning).

Monitoreo de la iteración (Sprint Meeting).

Revisión de la iteración (Sprint Review).

Roles: Scrum Master (Coordinador).

Scrum Team (Equipo de Trabajo).

Product Owner (Interesados del

Proyecto).

Beneficios

Conjunto de buenas prácticas generales para el proyecto.

Es un estándar orientado a procesos.

Las lecciones aprendidas tienen un valor especial para la empresa.

Se hace un estudio de los stakeholders.

Al no ser una receta puede adecuarse a metodología administrativa de proyectos de la empresa.

El trabajo se realiza en iteraciones y estas son definidas por la prioridad del cliente.

Permite que funcionalidades ya desarrolladas pasen a producción sin finalizar todo el proyecto.

Al avanzar el proyecto se pueden definir mejor los requerimientos.

Fortaleza en comunicación cara a cara con los tres tipos de reuniones sugeridas.

Se recortan los tiempos muertos por una buena comunicación.

35

Limitaciones

Es necesario capacitar al personal sobre administración de proyectos con énfasis en PMI.

Fortalecer los conocimientos de administración que fomenten una cultura de proyectos.

No es una metodología.

No establece ningún guion a seguir.

No es fácil de implementar en proyectos cortos o microempresas.

Los contratos con montos fijos no son los mejores para la metodología.

Se prefiere contratar a un equipo de trabajo para un grupo de iteraciones.

Poca disponibilidad del cliente para atender consultas del equipo de desarrollo.

Se basa en la confianza del cliente en el equipo de desarrollo y no en el conjunto final que se obtiene.

Se genera un documento a nivel de especificación y no de diseño.

Adaptación a

los cambios

Se trata en la mayor medida de lo posible evitar los cambios.

Existe el control integrado de cambios.

La incertidumbre es observada constantemente y se trata de evitar al máximo para evitar costos adicionales.

Se da la bienvenida a los cambios y estos pueden ser modificados, dejados de lado o cambiados.

La modificación de un requisito no existe como tal, ya que no ha existido la fase de requisitos tradicional, sino que se ve enriquecida para concretar la visión del producto.

La incertidumbre es observada constantemente y por eso se permite el descubrimiento de mejoras para el proyecto.

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

4.2. Ciclo de Vida de un Proyecto El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto con su fin, es la secuencia de actividades necesarias hasta alcanzar el producto del proyecto cuyo nombre y número son determinados por las necesidades de control de la organización u organizaciones involucradas en el proyecto. El PMBOK describe esta secuencia con una fase de inicio, seguido por una serie de fases intermedias y terminando con una fase final. A continuación en la figura No. 3 se presenta una gráfica que representa el Ciclo de Vida de un proyecto:

Figura 3. Fases del Ciclo de Vida del Proyecto (PMI, 2008)

36

Al interpretar “traspaso” para definir que al momento de entregar un incremento en código funcionando es revisado y aprobado por el cliente y el equipo de trabajo, podríamos concluir que una metodología ágil se alinea a los lineamientos y prácticas del PMBOK. Como se muestra en la Figura No.4 se puede identificar como el ciclo de vida de un proyecto (según el PMBOK), pude ser mapeado al ciclo de vida de un proyecto bajo una Metodología Ágil. Incluso bajo una Metodología Ágil, el ciclo de vida de un proyecto es repetitivo. Cada iteración tiene una fase inicial donde la clave es la planificación, las fases intermedias y la fase final. En la fase final es donde se tiene una retrospectiva (aprendizajes de errores y logros). (Tangient,

2013)

Figura 4. Fases y sub-fases del ciclo de vida de un proyecto bajo una metodología ágil.

Es de tener en cuenta que en las Metodologías Ágiles el involucramiento activo de los stakeholders y el sponsor o representante debe ser alto durante la ejecución del proyecto, esto es un factor importante ya que ellos definirán la dirección del producto en el inicio del proyecto. En el PMBOK, se define la participación de los interesados al inicio del proyecto y luego disminuye su participación en el resto del mismo (PMI, 2008, p. 24).

4.3. Características de los Autores La tabla No. 15 muestra una mirada de los pensamientos de autores del marco de referencia PMBOK y de Metodologías agiles. Tabla 15. Cuadro comparativo entre los autores del marco de referencia PMBOK y de Metodologías agiles.

AUTORES PENSAMIENTO

37

MIKE COHN

LETELIER PATRICIO

Extreme Programming Desde las Trincheras El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Por otro lado están las metodologías agiles que se centran en otras dimensiones, como por ejemplo el factor humano o el producto software. Se enfocan en que las iteraciones sean cortas y de duración fija. En entregar código funcional en tiempos muy cortos, en general los equipos XP se enfocan en que las cosas se hagan.

JEFF SUTHERLA

ND

Principios y valores de Agile Desarrollo ágil es un término que se deriva el manifiesto ágil, que fue escrito en 2001. El manifiesto ágil estableció un conjunto común global de valores y principios para todas las metodologías ágiles individuales en el tiempo. El manifiesto detalles cuatro valores fundamentales para permitir que los equipos de alto desempeño se desarrollen.

PETE DEEMER

The scrum primer

Es un marco de trabajo iterativo e incremental; estructura el desarrollo en ciclos de trabajos llamados sprint, los cuales tienen iteraciones de 1 a 4 semanas. Son de duración fija, terminan cuando es la fecha acordada, sus reuniones son muy breves y en ellas comunican sus avances y motivos de retraso.

Asif Qumer, Brian

Henderson-Sellers

Una evaluación del grado de agilidad en seis métodos ágiles Mientras que los métodos ágiles están en uso en la industria, la investigación se ha llevado a cabo en lo que se quiere decir con la agilidad y la forma en como un supuesto del método ágil, puede ser evaluado en cuanto a su veracidad y pertenecer a esta categoría de los enfoques metodológicos de desarrollo de software. Aquí, un marco analítico, llamado 4-DAT, se desarrolló y aplicó a seis métodos ágiles bien conocidos y, para

comparación, dos métodos tradicionales.

JIM HIGHSMITH

Agile Project Management Los métodos tradicionales de desarrollo de software se esfuerzan por mantenerse al día con el ritmo acelerado y el cambio rápido de desarrollo de Internet. Varios "metodologías ágiles " se han desarrollado en respuesta - y estos enfoques para el desarrollo de software están mostrando promesa excepcional. Jim, comienza con la introducción de los valores y principios compartidos por casi todos los métodos de desarrollo de software ágil. Presenta estudios de caso detallados de las organizaciones que los han utilizado, así como entrevistas con los autores principales de cada método o

profesionales líderes.

Rita Mulcahy

Preparación para el Examen PMP Fue presidente y fundadora de RMC Project Management, Inc., y autora de

renombre mundial de gestión de proyectos, formadora y conferencista.

Pablo Lledo Cómo aprobar el PMP® sin morir en el intento Se graduó como Master of Science in Project Analysis (University of York, Inglaterra), es MBA en Dirección de Proyectos (Universidad Francisco de

38

Vitoria, España) y posee la certificación internacional de Project Management Professional (PMP). Ha publicado 8 libros sobre Gestión de Proyectos y es Consultor internacional de Project Management en importantes empresas Latinoamericanas.

Fernando Hurtado

Una Introducción con Base en el Marco Del PMI En estos últimos años se ha enfocado en la aplicación de la ingeniería de software al desarrollo de frameworks para desarrollo de aplicaciones de negocios que aprovechen las ventajas de la computación móvil. Actualmente se desempeña como consultor en temas de ingeniería y dirección de proyectos de software.

Eduardo Caamaño

Project Management Practice Licenciado en Administración y Dirección de Empresas por la Escuela Superior de Propaganda y Marketing - ESPM (Rio de Janeiro, Brasil), Posgraduado en Dirección y Gestión de Recursos de la Información por la Universidad Oberta de Catalunya - UOC, MBA Executive de Administración y Dirección de Empresas por la Escuela Internacional de Formación de Madrid y certificado como Project Manager Profesional -

PMP por el Project Management Institute.

PMI

Project Management Institute Es una organización internacional sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos. Desde principios de 2011, es la más grande del mundo en su rubro, dado que se encuentra integrada por más de 380.000 miembros en cerca de 170 países. La oficina central se encuentra en la localidad de Newtown Square, en la periferia de la ciudad de Filadelfia, en Pennsylvania(Estados Unidos).

Elaboración propia a partir de las diferentes literaturas de los autores anteriormente mencionados.

4.4. Diferencias y Similitudes La tabla No. 16 muestra las características de cada uno de los autores del marco de referencia PMBOK y de Metodologías agiles. Tabla 16. Cuadro comparativo de las características de los autores del marco de referencia PMBOK y de Metodologías agiles.

AUTORES

CARACTERÍSTICAS

Procesos Actividades /Alcance

Responsabilidad

Herramientas/Tareas

Ser Humano

KENT BECK

(Scrum)

*Por iteraciones entre el cliente y el programador

*Exploración *Planificación de la Entrega *Iteraciones *Producción *Mantenimiento *Muerte del Proyecto.

*Cliente *Programador *Encargado de pruebas *Encargado de seguimiento *Entrenador *Consultor *Gestor

*Definir el valor de negocio a implementar * Estimar el esfuerzo necesario. * selecciona qué construir.

*Se enfoca más en el cliente y el equipo

JEFF *se centra en *Definir las *Cliente *Respeto por el *Que la

39

SUTHERLAND (PMI)

la comunicación entre los individuos

pruebas de aceptación al definir la característica. *Implemente las características consecutivamente y en orden de prioridad. *Ejecute las pruebas de aceptación en cada característica.

*Equipo valor de cada persona *Veracidad en cada comunicación *Transparencia de todos los datos. *Confianza en el equipo. *Compromiso con el equipo.

comunicación sea muy fluida.

PETE DEEMER (Scrum)

*Se ejecuta en bloques. *Por iteraciones cortas y fijas.

*Planificación de la iteración (Sprint Planning) *Ejecución de la iteración (Sprint) *Reunión diaria de sincronización del equipo (Scrum Daily Meeting) *Demostración de los requisitos completados (Sprint Review) *Retrospectiva (Sprint Retrospective)

*Cliente (Product Owner) *Facilitador (Scrum Master) *Equipo (Team)

*Lista de requisitos priorizada *Lista de tareas de la iteración *Gráficos de trabajo pendiente

*Trabaja en equipo *Se enfoca en el individuo

Asif Qumer, Brian

Henderson-Sellers

(PMI)

Se enfocan mediante el uso de un enfoque de ingeniería método.

Adaptable y muy flexible al cambio.

El equipo en general con todos sus involucrados.

Priorizan la agilidad, la abstracción, el proceso, las personas, los productos.

Todo es enfocado desde una visión compartida.

JIM HIGHSMIT

H (Scrum)

Su funcionamiento es cíclico y reconoce que en cada iteración se producirán cambios e incluso errores.

Adaptación continúa al cambio. Muy predispuesto al cambio.

Cliente Equipo.

Hace énfasis en aplicar las ideas que se generaron en el mundo de los sistemas complejos.

Participación activa de todos los usuarios

Rita Mulcahy (PMI)

Estructuración de procesos según las

Es necesario realizar estudios especializados en Dirección de

Director de proyecto. Equipo

Utilización de Casos de Estudios para comprender y no

Se enfoca que en la persona aprenda y comprenda, no

40

mejores prácticas del PMI

Proyectos memorizar memorice.

Pablo Lledo (PMI)

Planifica la gestión del recurso humano. Desarrolla el equipo.

Es necesario realizar estudios especializados en Dirección de Proyectos

El equipo y todos sus interesados.

- Utilización de Organigrama.

- Descripción de cargos.

- Asignación Previa.

- Negociación.

Busca las habilidades interpersonales.

Fernando Hurtado

(PMI)

Se enfoca en las condiciones del entorno para mejorar o transformar problemas a solucionar.

El alcance lo define basado en el marco de referencia del PMBOK.

Utilización de Lecciones aprendidas.

Enfocado en concientizar la optimización de recursos que puedan afectar el medio ambiente.

PMI

Se enfoca en dos categorías de procesos: - dirección de proyectos comunes a la mayoría de los proyectos.

- orientados al producto: especifican y crean el producto del proyecto

Dependiendo de la necesidad del mercado, cada 3 o 6 años realiza actualización de las mejores prácticas plasmadas en su libro PMBOK

Director de proyecto. Equipo

Por cada uno de sus áreas de conocimiento utiliza varias herramientas para la gestión de proyectos como: - Juicio de

experto. - Control de

cambios. - Administración

de la información.

- Etc.

Se enfoca a que la persona tenga una base de buenas prácticas en la gestión de proyectos.

Eduardo Caamaño

(PMI)

Se basa en el modelo de madurez de capacidades (CMM)

El alcance lo define basado en el marco de referencia del PMBOK.

Director de proyecto. Equipo

Contempla las herramientas mencionadas en el PMBOK

Se enfoca en que el lector siga una secuencia de actividades, pero que comprenda para que sirva.

Elaboración propia a partir de las diferentes literaturas de los autores

anteriormente mencionados.

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

Teniendo como base todo lo descrito en este documento sobre las prácticas del PMI y el marco de trabajo SCRUM, se mencionará en esta sección el cómo:

41

transformar las 9 áreas de conocimiento PMBOK en prácticas concretas del marco de trabajo SCRUM. Una primera correlación entre los grupos de procesos del PMBOK para la gestión de proyectos y Metodología ágil, la definió Jim Highsmith con - Agile Project Management – donde evaluó el ciclo de vida de un proyecto (Figura 5). Aquí identifica las fases del PMBOK y reconfigura estas fases para reflejar mejor la realidad de cómo el software está realmente desarrollado con metodología ágil.

PMBOK AGILE Iniciación Imaginar

Planificación Especular

Ejecución Explorar

Control Adaptar

Cierre Cerrar

Figure 5: PMBOK Project Management Process Groups mapped to Jim Highsmith's Agile Project Management framework

Para entender la transformación se parte de la siguiente analogía:

PMBOK SCRUM

Fase Release

Subfase Sprint

En los siguientes cuadros se puede ver en detalle, el mapeo de las diferentes áreas del conocimiento del PMBOK y su equivalente en SCRUM. La tabla No. 17 muestra la práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM. Tabla 17. Práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM.

42

Á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. 18 muestra la práctica mapeada del área de conocimiento Gestión del alcance en PMBOK a su equivalente en SCRUM. Tabla 18. 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

43

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. 19 muestra la práctica mapeada del área de conocimiento Gestión del tiempo en PMBOK a su equivalente en SCRUM. Tabla 19. 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. 20 muestra la práctica mapeada del área de conocimiento Gestión de Costos en PMBOK a su equivalente en SCRUM.

44

Tabla 20. 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 “velocidad”, 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. 21 muestra la práctica mapeada del área de conocimiento Gestión de la Calidad en PMBOK a su equivalente en SCRUM. Tabla 21. 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 Calidad

Planificar la calidad: se identifican los requisitos de calidad y/o normas para el proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento con los mismos.

La calidad está implícita a lo largo de todo el proceso de Scrum. (test temprano y frecuente, software que 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: Realizado por el propio equipo, usando

45

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.

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. 22 muestra la práctica mapeada del área de conocimiento Gestión del Recurso Humano en PMBOK a su equivalente en SCRUM. Tabla 22. 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 miembros del equipo y el ambiente del equipo para lograr un mejor desempeño del proyecto.

Valores Scrum: Compromiso, coraje, respeto, foco y 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, auto-gestionados y auto organizados. El Scrum master actúa como líder.

46

La tabla No. 23 muestra la práctica mapeada del área de conocimiento Gestión de la Comunicación en PMBOK a su equivalente en SCRUM. Tabla 23. 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 el 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. 24 muestra la práctica mapeada del área de conocimiento Gestión del Riesgo en PMBOK a su equivalente en SCRUM. Tabla 24. 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 No se prescriben métodos formales.

47

Cualitativo/Cuantitativo de Riesgos.

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. 25 muestra la práctica mapeada del área de conocimiento Gestión de Compras en PMBOK a su equivalente en SCRUM. Tabla 25. 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, especificando la forma de hacerlo e identificando a posibles vendedores.

El equipo proporciona información necesaria para las adquisiciones usando una iteración temprana o una 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.

48

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.

En estos casos, el riesgo del proyecto es compartido, pueden cambiarse unas características o funcionalidades por otras, pero sigue siendo compartido. Se basa en una relación de confianza mutua y aplicando los principios Ágiles de entrega de valor temprano, ambas partes están incentivadas para reducir el alcance y el costo del proyecto.

5. Analizando algunos artículos sobre metodologías ágiles

5.1. Una década de metodologías ágiles: Hacia la explicación del

desarrollo ágil de software

Desde que el manifiesto ágil, creado en 2001, la comunidad científica ha dedicado una gran atención al desarrollo de software ágil. Una década después de la publicación del manifiesto ágil, cinco ediciones especiales y una sección especial en el desarrollo ágil de software han sido publicados, incluyendo 32 artículos. Los métodos ágiles más comunes descritos han sido XP y Scrum.

Al igual que con cualquier disciplina naciente, los primeros años de desarrollo ágil estuvieron marcados por la exuberancia de unos pocos y por el escepticismo de muchos. Estos incluyen Extreme Programming (XP), scrum, el desarrollo ágil de software, desarrollo de funciones conducido (FDD) y metodologías de cristal, al nombrar sólo algunos. En términos generales, todos estos métodos se esforzaron para hacer frente a los principios básicos del manifiesto. (Torgeir Dingsoyr, 2012)

5.2. SCRUMIA- Un juego educativo para la enseñanza de SCRUM en los

cursos de informática

Debido a la creciente utilización de los métodos ágiles, enseñar SCRUM como metodología de gestión de proyectos agiles, se ha vuelto más y más importante. Con el fin de enseñar a los estudiantes para que sean capaces de aplicar SCRUM en situaciones concretas, se utilizan (simulaciones) Juegos a menudo educativos. Por lo tanto la adopción de SCRUM como gestión de proyectos agiles, en proyectos de desarrollo de software, es cada vez mayor, por tal motivo la comprensión de SCRUM y desarrollar competencias, tien e que convertirse en una parte esencial en la educación de profesionales (Abrahamsson et al., 2002).

49

Se desarrolla un juego manual para reforzar y enseñar la aplicación de SCRUM; siguiendo un proceso de diseño instructivo sistemático y basado en la experiencia de educadores. En él, evalúan la motivación, la experiencia del usuario y la contribución del juego para aprender a través de estudios que fomentan el grado de reacción, aprendizaje, comportamiento y resultados en los estudiantes. Los primeros resultados indicaron el potencial del juego, para contribuir al aprendizaje de SCRUM de una manera atractiva, eficaz, eficiente y manteniendo al estudiantes inmerso en la tarea de aprendizaje. (Christiane Gresse von Wangenheim, 2013)

50

6. CONCLUSIONES A continuación se presentan las conclusiones a las que se llegó después de la elaboración de este proyecto: Se puede decir entonces que la agilidad es un comportamiento persistente, en la gestión de proyectos desde organizaciones pequeñas hasta empresas multinacionales. Los administradores de proyectos pueden utilizar las prácticas ágiles para gestionar con éxito la administración del proyecto, donde la simplicidad, adaptación, eficacia, calidad, el control de cambios y enfocarse en crear valor para el cliente en el producto resultante del proyecto, son características específicas.

Las organizaciones que implementan prácticas ágiles generan valor, por las siguientes características:

Las metodologías agiles de dirección de proyectos son livianas y permiten hacer entregas periódicas del producto, para tener software produciendo sin que haya terminado el 100% del proyecto.

Se tiene una mejor disposición a las necesidades cambiantes del mercado, lo que permite a la organización poder agregar, modificar o eliminar los requerimientos.

Las metodologías ágiles son más modernas y mejores que cualquiera de las tradicionales.

Las actividades “de calidad” van implícitas en las metodologías agiles, por tal motivo, no quitan tiempo de tareas técnicas (reprogramar, etc.), se gana tiempo para dedicarlo a otras actividades.

Las metodologías ágiles son precisas para aplicar en proyectos donde existe mucha incertidumbre, en 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, las agiles permiten tomar decisiones en el camino.

Una ventaja de las metodologías agiles es que el cliente se involucra casi en un 100% con el en el equipo de trabajo, lo que permite una continua y anticipada retroalimentación. Esto mejora exponencialmente la calidad y aceptación del producto.

Por medio de este trabajo, se ha demostrado que es posible gestionar un proyecto basado en metodologías ágiles siguiendo los lineamientos enmarcados por el PMBOK. Se sabe que existen diferencias, pero estas son más de forma que fondo.

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

51

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

52

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&Obj

ectId=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+tradicional

es

Tecnologies, S. (Enero de 2003). SHINE TECHNOLOGIES AGILE METHODOLOGIES

Survey Results. Recuperado el 16 de 07 de 2013, de SHINE TECHNOLOGIES

AGILE METHODOLOGIES Survey Results:

http://www.shinetech.com/agile_survey_results.jsp

Torgeir Dingsoyr, S. N. (2012). A decade of agile methodologies: Towards explaining agile

software development. The Journal of Systems and Software, 1213– 1221.

53

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

54

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

55

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.

56

9. Anexos

Anexo 1: CRONOGRAMA

EDT Nombre Duración Comienzo Fin Predecesoras

Demora

permisible

0 Marco Ágil para PMI en Pequeñas y Medianas Empreas de Desarrollo de SW41 días 06/12/13 09:00 a .m. 14/02/14 07:00 p.m. 0 días

1 Inicio 2 días 06/12/13 09:00 a .m. 09/12/13 07:00 p.m. 0 días

1.1 Aceptación y aprovación del tema 2 días 06/12/13 09:00 a.m. 09/12/13 07:00 p.m. 0 días

2 Planificación de l a lcance de la propuesta 25 días 10/12/13 09:00 a .m. 27/01/14 07:00 p.m. 0 días

2.1 Documento introductorio de la Investigación 10 días 10/12/13 09:00 a .m. 06/01/14 07:00 p.m. 0 días

2.1.1 Inicio(Investigación) 5 días 10/12/13 09:00 a.m. 16/12/13 07:00 p.m. 2 0 días

2.1.2 Definición del alcance del documento y procedimientos 5 días 17/12/13 09:00 a.m. 06/01/14 07:00 p.m. 5 0 días

2.2 Contenido temático de la Investigación 15 días 07/01/14 09:00 a .m. 27/01/14 07:00 p.m. 0 días

2.2.1 Inicio(Investigación) 10 días 07/01/14 09:00 a.m. 20/01/14 07:00 p.m. 6 0 días

2.2.2 Definición de l Alcance de la Investigación 5 días 21/01/14 09:00 a .m. 27/01/14 07:00 p.m. 0 días

2.2.2.1 Definición Practicas PMI 5 días 21/01/14 09:00 a.m. 27/01/14 07:00 p.m. 8 0 días

2.2.2.2 Definicón Marco de trabajo Ágil 5 días 21/01/14 09:00 a.m. 27/01/14 07:00 p.m. 8 0 días

2.2.2.3 Definición Prácticas PMI a Practicas Agil 5 días 21/01/14 09:00 a.m. 27/01/14 07:00 p.m. 8 0 días

3 Ejecución Propuesta 10 días 28/01/14 09:00 a .m. 10/02/14 07:00 p.m. 0 días

3.1 Procesos PMBOK 5 días 28/01/14 09:00 a.m. 03/02/14 07:00 p.m. 9 9 días

3.2 Actividades SCRUM 5 días 28/01/14 09:00 a.m. 03/02/14 07:00 p.m. 9 9 días

3.3 Mapeo Prácticas PMI al Marco de trabajo de Scrum 10 días 28/01/14 09:00 a.m. 10/02/14 07:00 p.m. 9 0 días

4 Monitoreo y Control 27 días 07/01/14 09:00 a .m. 12/02/14 07:00 p.m. 2 días

4.1 Validar el Alcance de la Propuesta 2 días 07/01/14 09:00 a.m. 08/01/14 07:00 p.m. 6 27 días

4.2 Controlar el Alcance de la Propuesta 2 días 07/01/14 09:00 a.m. 08/01/14 07:00 p.m. 6 27 días

4.3 Controlar las comunicaciones 2 días 07/01/14 09:00 a.m. 08/01/14 07:00 p.m. 6 27 días

4.4 Evaluar posibles riesgos de interpretación 2 días 11/02/14 09:00 a.m. 12/02/14 07:00 p.m. 16 2 días

4.5 Controlar al Equipo de trabajo 2 días 11/02/14 09:00 a.m. 12/02/14 07:00 p.m. 16 2 días

4.6 Validar Brechas Entre PMBOK y SCRUM 2 días 11/02/14 09:00 a.m. 12/02/14 07:00 p.m. 16 0 días

5 Cierre 2 días 13/02/14 09:00 a .m. 14/02/14 07:00 p.m. 0 días

5.1 Entrega Investigación 1 día 13/02/14 09:00 a.m. 13/02/14 07:00 p.m. 23 0 días

5.2 firmar acta entre las partes (Universidad y Estudiantes) 1 día 14/02/14 09:00 a.m. 14/02/14 07:00 p.m. 25 0 días

57

Anexo 2: ENCUESTA DE METODOLOGÍA EN EMPRESAS PYME DE DESARROLLO

DE SOFTWARE

Personas responsable de la encuesta:

Luis Carlos Bastidas

Álvaro Eduardo Zapata

Datos Iníciales: Nombre del encuestador: Álvaro Eduardo Zapata Fecha de la encuesta: 13-01-2014

- El área objetivo de la encuesta es saber que metodologías de desarrollo utilizan

las PyMEs.

- La persona que responda la encuesta ha de ser la Gerente o la persona encargada del área de desarrollo o con amplios conocimientos del Proceso desarrollado.

58

ENCUESTA CAPACIDAD TECNOLÓGICA

Esta encuesta es para uso único y exclusivo académico, tiene como fin establecer las bases de PMI de las empresas PyMes del sector de desarrollo de software, la información aquí contenida es estrictamente con fines educativos y se guardará la confidencialidad de las fuentes. Si la empresa considera tener una copia se entregara una fotocopia de la misma.

INFORMACIÓN EMPRESARIAL

Fecha de Realización: 13-01-2014

Empresas: OLSoftware - Arquitect Soft.

Dirección: Centro Comercial Chipichape Bodega 2 local XXXX

NIT: XXXXXXXX

Teléfono: XXXXXXX

e-mail: xxxxx@gmail.com

Nombre Empresario:

- Orlando Lara Cargo: Gerente OLsoftware. - Diego Rodriguez: Accionista Arquitect Soft

Principales productos:

- 1: Desarrollo de Software a la Medida. - 2: Soporte aplicaciones terceros.

EMPRESA

1. Su Empresa es: Unipersonal __ Sociedad Anónima S __ Ltda._X__ En Comandita ___

2. Su Empresa está constituida hace: 1– 6 meses ___ 6 – 12 meses ___ 1-3 años __ 3-5 años _X_ 5-10 años ___ 10–15

3. ¿A qué Mercado están dirigidos los servicios que presta su empresa? Local _X_ Regional _X_ Nacional _X_ Internacional ___

4. Áreas Funcionales que componen la empresa: (Coloque una X enfrente) Planeación. Comercialización / Ventas. Contabilidad. Diseño – Ingeniería: X Calidad. Talento Humano: X

59

5. La Servicio que presta su empresa depende de: _X_ Los pedidos del Cliente. _X_ Pronóstico de la demanda. ___Mantenimiento de un inventario Mínimo. _X_ Préstamo de servicios a otras empresas. ___Otra. ¿Cuál?___________________________

6. 8. La Capacidad de Servicio de su empresa depende de: _X_ La demanda de los clientes ___De la contratación de los empleados ___De la situación económica del país _X_ De la capacidad de diseño de la empresa ___De la capacidad real de la empresa ___De la compra de los insumos para la fabricación

7. ¿Cuáles de las siguientes Prioridades Competitivas tiene en cuenta su empresa? (Enumere de mayor a menor). _X_ Costos _X_ Calidad ___ Entregas _X_ Flexibilidad _X_ Servicio _X_ Innovación _X_ Responsabilidad

8. ¿Qué metodología usan para el desarrollo de software?

Utilizamos metodología de cascada.

9. ¿Cómo evalúan el documento RFP (Request For Proposal) entregado por los clientes?

- Con acta de reunión realizada con el cliente.

10. ¿Qué valor agregado le dan a los clientes con la metodología actual? - Entrega de los desarrollos a tiempo y con calidad.

11. ¿Cuáles son los principales problemas que ha identificado en la empresa

sobre el desarrollo de software? - Problemas en el cumplimiento de cronogramas. - Cambios de Alcance a la necesidad fuera de los tiempos.

12. ¿Cómo hacen para controlar los proyectos grandes?

- Nuestra metodología de desarrollo se basa en cascada por ende el control de nuestros proyectos lo realizamos por medio de un acta de reunión y un cronograma acordado con el cliente.

13. ¿Cómo aseguran la calidad de sus productos de desarrollo de software?

- Pruebas unitarias realizadas por el desarrollador. - Pruebas funcionales realizadas por el cliente.

60

14. ¿Cómo cree que mejoraría la satisfacción del cliente si se realiza entregas tempranas y continuas?

- Le generaríamos valor agregado al cliente con nuestro servicio ya que al realizar entregas con mayor frecuencia sin haber terminado la totalidad del desarrollo, el cliente podría ver el retorno de su inversión de manera más temprana.

15. ¿Cómo se maneja la comunicación entre el equipo de desarrollo?

Tenemos coordinadores por equipos de desarrollo quienes están realizando seguimiento y entregas al cliente.

16. ¿Cuál es el porcentaje de proyectos exitosos en su empresa? - Actualmente lo tenemos en un 60%. La idea es garantizarle al cliente un

85%-90% de éxitos en los proyectos.

Conclusión de la encuesta.

De acuerdo a las preguntas y respuestas de la encuesta, entendemos que:

No saben cómo crecer: Por lo general, las pymes parten de un crecimiento bastante fuerte, pero llegan a un punto, que se estancan.

Las consume el día a día: “Lo urgente supera a lo importante”. Estas empresas están inmersas en un contexto sumamente demandante de tareas que les impiden visualizar las acciones que les permiten proyectar un crecimiento.

Poca división empresa/persona: Por lo general, son empresas familiares, lo que acarrea una serie de problemas relacionados con los afectos de la propia familia.

Fuertes liderazgos in-habilitantes: Los gerentes o dueños de las pymes son personas con un carácter fuerte y formado, les gusta que las cosas se hagan a su manera, por lo cual no permiten que otros que tienen la capacidad indiquen ciertos lineamientos que pueden ser útiles a lo largo de las diferentes etapas involucradas en el crecimiento de la empresa.

Mala gestión integral: Los dueños y/o gerentes de pymes son personas técnicamente muy capaces en su materia, pero no a nivel de gestión empresarial, es decir, dejan de lado aspectos humanos, financieros, administrativos, comerciales, entre otros.

Deficiente control de gestión: Aunque una línea de servicios sea muy buena, muy pocas empresas cuentan con indicadores que muestren el funcionamiento de cada parte de la empresa, lo que impide ejercer un adecuado control de los avances de cada tarea.

Mala comunicación interna: El punto anterior implica necesariamente que las personas no se están comunicando de manera adecuada en la organización. Por ello, nacen roces y dificultades que no se resuelven a tiempo y terminan por afectar el buen funcionamiento de la empresa.