View
0
Download
0
Category
Preview:
Citation preview
Marco ágil para PMI en pequeñas y medianas empresas de desarrollo de software 1
Luis Bastidas2, Álvaro Zapata3
Resumen El presente trabajo de investigación no se desarrolla en una organización en particular dado que los
lineamientos y recomendaciones resultantes serán de utilidad en un marco ágil para PMI en
pequeñas y medianas empresas de desarrollo de software
Las tecnologías de Información juegan un papel clave en esta evolución y presentan nuevas herramientas e iniciativas de apoyo a la administración de proyectos, las cuales deben adoptarse considerando las características y objetivos propios de la organización. Dado el creciente aumento de pequeñas y medianas empresas de software que se constituyen no cuentan con una oficina de proyectos y una metodología ágil que les ayude a desarrollar con orden y eficacia las diferentes etapas y procesos que involucra la dirección general de la empresa (planificación, organización, selección de personal, ejecución y control de las operaciones) y el ciclo de vida de los proyectos que administran, aunado con la influencia de nuevas tecnologías; surge la necesidad de implementar nuevas formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administración de proyectos ágil, sin dejar de lado la colaboración a distancia, el outsourcing, la mejora de calidad, generación y distribución de conocimiento y coordinación de varios proyectos, entre otras. Palabras claves. Metodología tradicional, Metodología Ágil, PMBOK, SCRUM, XP.
1 Esta investigación hace parte del trabajo de investigación de Luis Bastidas y Álvaro Zapata. 2 Candidato a Especialista en Gestión Integral de Proyectos de la Universidad San Buenaventura Seccional Cali. Contador Público de la universidad San Buenaventura E-mail: lcarlos2050@gmail.com 3 Candidato a Especialista en Gestión Integral de Proyectos de la Universidad San Buenaventura Seccional Cali. Ingeniero de Sistema de la Universidad Antonio Nariño, E-mail: azapata0216@hotmail.com
1. Introducción 1.1. Situación
Cerca ya de dos (2) décadas el incremento en el uso de metodologías ágiles y la aplicación de metodologías tradicionales para la administración de proyectos en el desarrollo de software, ha causado un dilema a una gran cantidad de pequeñas y medianas empresas de desarrollo de software: identificar cuál método es más efectivo y eficiente a la hora de desarrollar los proyectos. Esta gran confusión se da debido a que cada método tiene sus propias técnicas, que en ciertos casos son muy afines a los principios de administración de proyectos, pero que en otros casos son muy diferentes y van en contravía con los mismos.
Los métodos ágiles rompen el paradigma de que son solo una forma de desarrollar software, estos van más allá, ya que requieren de la aplicación de enfoques particulares de administración de proyectos. La forma en que son aplicados, cambia las interacciones en que patrocinadores, usuarios y stakeholders se comprometen en un proyecto. De igual forma los enfoques ágiles emplean diferentes procesos para la planificación, ejecución y control. (Letelier Patricio, 2006)
Ante la necesidad de las PYMES de aplicar las técnicas ágiles para el desarrollo de software y cumplir con los principios y las recomendaciones del PMBOK 4TH_EDITION, se elabora este proyecto de investigación para documentar, analizar y proponer un marco de trabajo, que contribuya al desarrollo más ameno en los proyectos. Para lograr el cumplimiento de los objetivos planteados, se espera hacer una revisión del material existente y bibliografía sobre las metodologías agiles y tradicionales existentes para la administración de proyectos de desarrollo de software. El desarrollo de este proyecto de investigación se centra concretamente en identificar los beneficios y características, respecto al uso de metodologías ágiles para la administración de proyectos de software, al alinearlos con el marco de referencia del PMBOK 4TH_EDITION.
1.2. Administración de proyectos bajo PMI
Según el PMBOK 4TH_EDITION, un proyecto es un esfuerzo que se lleva a cabo para crear un producto, servicio o resultado único, y tiene la característica de ser naturalmente temporal, es decir, que tiene un inicio y un final establecidos. (P.M.I., 2008).
1.3. ¿Qué es el PMBOK?
PMBOK es el estándar para la Administración de Proyectos y cuyas siglas significan en inglés Project Management Body of Knowledge (el Compendio del Saber de la Gestión de Proyectos en español).(P.M.I., 2008).
Éste a su vez puede ser entendido como una colección de sistemas, procesos y áreas de conocimiento que son universalmente aceptados y reconocidos como los mejores dentro de la gestión de proyectos.
La tabla No. 1 describe los diferentes conceptos de dirección de proyectos emitidos por distintos autores. Tabla 1. Cuadro conceptual de la dirección de proyectos.
Autor Concepto Descripción
PMI
Desarrollo de estándares para la Administración de
Proyectos.
El PMI desarrolla estándares de la profesión “Project Management” alrededor de todo el mundo. Uno de sus más conocidos estándares la Guide to the Project Management Body of Knowledge (PMBOK® Guide) es mundialmente reconocida y está aprobada como un estándar por el American National Standards Institute (ANSI). El PMI está enfocado en la expansión del conjunto de conocimientos de la profesión “Project Management” a través de encuestas propias, investigaciones externas, una base de datos de información. Adicionalmente, necesidades, información, conocimientos y mejores prácticas son recolectados y distribuidos.
Erly Delgado Expósito
Metodologías de desarrollo de
software. ¿Cuál es el camino?
Hoy en día existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas específicamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran número de proyectos; sobre todo, en aquellos proyectos de gran tamaño (respecto a tiempo y recursos). La experiencia ha demostrado que las metodologías tradicionales no ofrecen una buena solución para proyectos donde el entorno es volátil y donde los requisitos no se conocen con exactitud, porque no están pensadas para trabajar con incertidumbre.
Omar Higinio Caballero Cervantes
Tecnologías de información y
herramientas para la administración de
proyectos de Software.
En el siglo pasado innumerables áreas de Tecnología han tenido progresos considerables, pero una se destaca sobre las demás, no porque haya dejado de existir o por que se haya convertido en una innovación radical, sino porque ha cambiado tanto que apenas es reconocible a la situación en la que se encontraba hace 10 años: la Administración de Proyectos.
Michele Sliger
Relación a las prácticas del
PMBOK prácticas ágiles
Los profesionales PMP de la gestión de proyectos tradicionales atraviesan algunas dificultades a medida que hacen la transición de enfoques impulsados por el plan a las nuevas metodologías ágiles. Irónicamente, para todas las diferencias en Project Management Institute (PMI) y las filosofías ágiles, se ha encontrado que muchas de las prácticas identificadas en la Dirección de Proyectos del Conocimiento (PMBOK) son totalmente compatibles con las prácticas ágiles.
Fuente. Elaboración propia a partir de la lectura de los autores mencionados anteriormente.
1.4. Síntesis de los grupos de procesos del PMBOK.
La tabla No. 2 muestra el nombre del grupo, el objetivo, la descripción y la conclusión de la administración de proyectos basado en las mejores prácticas mencionadas en el PMBOK.
Tabla 2. Grupo de procesos para la administración de proyectos basados en las mejores prácticas del PMBOK.
Grupo Objetivo Descripción Conclusión Iniciación Definir los
procesos para un nuevo proyecto.
Este grupo está compuesto por aquellos procesos realizados para definir un nuevo proyecto o empezar una nueva fase de un proyecto ya existente mediante la autorización para empezar dicho proyecto o fase. En esta fase se define el alcance inicial y se comprometen los recursos financieros iniciales, se identifican los interesados internos y externos que van a interactuar o ejercer una influencia en el proyecto y se selecciona el director del proyecto, toda esta información se documenta en el Acta de Constitución del Proyecto y Registro de Interesados. Cuando el Acta de Constitución es Aprobada el proyecto se considera autorizado.
Involucrar a los clientes o interesados, desde la fase de iniciación, mejora la probabilidad de obtener propiedad compartida, en la aceptación de entregables con la satisfacción del cliente e interesados.
Planificación
Establecer el alcance del proyecto
Es el mayor grupo de procesos pues es donde se define el alcance en base a los requisitos estableciendo la estructura desglosada de trabajo o EDT; se define la secuencia, recursos y duración de las actividades estableciendo el cronograma del proyecto; se estiman los costos estableciendo el presupuesto del proyecto; se identifican los riesgo; y el plan de respuesta para dichos riesgos; además de planificar la calidad, los recursos humanos, las comunicaciones y adquisiciones que luego serán integrados todos juntos en el plan de gestión del proyecto.
Bajo este grupo de procesos se desarrolla el plan para la dirección del proyecto y los documentos que se utilizan para llevarlo a cabo. A medida que se recopilan o comprenden más detalles del proyecto, puede ser necesaria mayor planificación. A estos procesos repetitivos y continuos de planificación se les denomina planificación gradual.
Ejecución
Realizar y/o completar el trabajo definido en el plan para la dirección de proyectos.
Es donde se consumen la mayor cantidad de recursos y del presupuesto del proyecto, coordinando todas las actividades para ejecutar el trabajo del proyecto asegurando que se cumplan todos los objetivos definidos y que la información sea distribuida a todos los interesados según el plan establecido para las comunicaciones.
Éste grupo de procesos implica coordinar personas y recursos, así como integrar y realizar actividades del proyecto en conformidad con el plan para la dirección del proyecto.
Monitoreo y Control
Realizar seguimiento, analizar y regular el progreso y el desempeño del proyecto.
Un aspecto fundamental para la buena marcha de un proyecto son las actividades de supervisión, inspección, análisis y corrección a través de la identificación de aquellos aspectos del proyecto que requieran realizar cambios preventivos o correctivos y así estar mejor preparados para desviaciones que podrían presentarse durante la gestión del proyecto.
- Controlar los cambios y recomendar acciones preventivas para evitar posibles problemas.
- Monitorear las actividades del proyecto, comparándolas con el plan y la línea base para el desempeño del proyecto.
- Influir en los factores que pueden eludir el control integrado de cambios de modo que únicamente se implementen
cambios aprobados.
Cierre
Finalizar todas las actividades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo.
Asegura el cierre formal del proyecto obteniendo la aceptación del cliente o usuario final y consiguiendo que se concluyan todas las actividades comprometidas en el proyecto, realizando la documentación de las lecciones aprendidas y el archivo físico o electrónico de toda la información relacionada a los entregables que se constituirán en los activos de la organización.
- Obtener la aceptación del cliente o del patrocinador.
- Realizar una revisión tras el cierre del proyecto o la finalización de una fase.
- Registrar los impactos de la adaptación de un proceso.
- Documentar las lecciones aprendidas.
- Archivar todos los documentos relevantes del proyecto en el sistema de información para la dirección de proyectos.
- Cerrar las adquisiciones.
Fuente. PMI
1.6. Síntesis de las áreas de conocimiento del PMBOK.
La tabla No. 3 muestra el área, la descripción y objetivo de las áreas de conocimiento basado en las mejores prácticas mencionadas en el PMBOK.
Tabla 3. Áreas del conocimiento de la administración de proyectos
Área Descripción Objetivos
Gestión de la Integración
Describe los procesos requeridos para asegurar que los elementos varios de un proyecto están coordinados apropiadamente. Consiste en el desarrollo de un plan de proyecto, ejecución del plan de proyecto, y el control de cambios en general.
- Integrar y coordinar todo el proyecto, planear y crear un documento constante, coherente.
- Realizar el plan del proyecto, realizando todas las actividades.
- Control a los cambios que coordinan a través del proyecto entero
Gestión del Alcance
Describe el proceso requerido para asegurar que el proyecto incluye todo el trabajo, para completar el proyecto de manera exitosa. Consiste en la iniciación, planeación del alcance, definición del alcance, verificación del alcance, y control de cambio al alcance
- Autorizar el proyecto o la fase. - Desarrollar una declaración escrita del alcance como la
base para las decisiones futuras del proyecto. - subdividir los entregables principales del proyecto en
componentes más pequeños, más manejables. - Formalización de la aceptación del alcance del proyecto. - Cambios que controlan al alcance del proyecto
Gestión del Tiempo
Describe los procesos requeridos para asegurar la terminación a tiempo del proyecto. Consiste en la definición de las actividades, secuencia de las actividades, estimación de duración de las actividades, desarrollo del cronograma y control de la programación.
- Identificar las actividades específicas que se deben realizar en cada una de las fases del proyecto.
- Estimar el número de períodos del trabajo que serán necesarios para terminar actividades individuales.
- Analizar secuencias de la actividad, duraciones de la actividad, y requisitos de recurso de crear el horario del proyecto.
- Controlar cambios al horario del proyecto.
Gestión del Costo Describe los procesos requeridos para asegurar que el proyecto es completado dentro del presupuesto aprobado. Consiste en la planificación de recursos, estimación de costos, presupuesto de costos, y control de costos.
- Determinar qué recursos (gente, equipo, materiales) y qué cantidades de cada uno se deben utilizar para realizar actividades del proyecto.
- Desarrollar una aproximación (estimación) del costo de los recursos que se necesita para terminar actividades del proyecto.
- Controlar al presupuesto de proyecto
Gestión de la Calidad
Describe los procesos requeridos para asegurar que el proyecto satisfaga las necesidades, para lo cual fue desarrollado. Consiste en la planeación de la calidad, seguranza de la calidad, y control de calidad.
- Identificar que estándares de calidad son relevantes al proyecto y determinar cómo satisfacerlos.
- Asegurar que el proyecto satisfaga los estándares de calidad relevantes.
- Supervisar el proyecto para determinar que esté cumpliendo los estándares.
Gestión del Recurso Humano
Describe los procesos requeridos para hacer el uso más eficiente de las personas involucradas en el proyecto. Consiste en la planeación organizacional, adquisición de staff, y desarrollo del equipo.
- Identificar, documentar, y asignar papeles del proyecto, responsabilidades, y relaciones de divulgación.
- Conseguir los recursos humanos necesarios para trabajar en el proyecto.
- Identificar las habilidades del individuo y del grupo para asignar roles en el proyecto.
Gestión de Comunicaciones
Describe los procesos requeridos para asegurar la generación apropiada a tiempo, almacenamiento y la disposición final de la información del proyecto. Consiste en la planeación de la comunicación, distribución de la información, reportes de desempeño, y el cierre administrativo.
- Determinar la información y las necesidades de comunicaciones para el equipo de proyecto (quién, que, cuando y como necesita la información).
- Hacer que la información necesaria esté disponible para proyectarla al equipo del proyecto de una manera oportuna.
- Generar, recolectar, y diseminar la información para formalizar la terminación de la fase o del proyecto.
Gestión del Riesgo
Describe los procesos concernientes con la identificación, análisis, y respuesta al riesgo del proyecto. Consiste en la identificación del riesgo, cuantificación del riesgo, desarrollo de la respuesta al riesgo, y en el control de la respuesta al riesgo.
- Determinar qué riesgos pudieran afectar el proyecto y la documentación de sus características.
- Realizar análisis cualitativo de riesgos y dar prioridad a aquellos que afecte los objetivos del proyecto.
- Medir la probabilidad y las consecuencias de los riesgos y estimar sus implicaciones para los objetives del proyecto.
- Planear respuesta efectivas al posible riesgo
Gestión de Adquisiciones
Describe los procesos requeridos para adquirir bienes y servicios de fuera de la organización ejecutora. Consiste en la planeación de la gestión de la adquisición, planear la selección de proveedores, administración de contratos, y cierre de contratos.
- Determinar qué adquirir y cuando. - Documentar requisitos del producto e identificar fuentes
potenciales. - Identificar el vendedor potencial. - Administrar la relación con el vendedor. - Administrar los contratos. - Cerrar el contrato
Fuente. PMI
1.7. Administración de proyectos con Metodología ágil.
Cada vez más, los estudios y las experiencias demuestran que la forma tradicional, de la
administración de proyecto de desarrollo de software, es errónea en las actuales circunstancias
y necesidades de dinamismo y adaptabilidad de los sistemas de software. Por tal motivo, ha
surgido la necesidad de investigar y desarrollar nuevas técnicas que tienden hacia el rápido
desarrollo de aplicaciones y que la vida útil de un producto sea más corta. En un entorno
dinámico, inestable, que tiene como principal protagonista el cambio y una evolución rápida y
continua, la ventaja competitiva se encuentra en aumentar la productividad para satisfacer las
necesidades del cliente en el menor tiempo posible para agregar valor al negocio (Boehm,
2006).
1.8. El Manifiesto Ágil.
El “Manifiesto Ágil”, promulga “que están poniendo al descubierto mejores métodos para
desarrollar software, haciéndolo y ayudando a otros a que lo hagan”; tras la reunión de Utah, un
documento que resume la filosofía ágil estableciendo cuatro valores y doce principios (Tabla
No. 4).
La tabla No. 4 Describe como el Manifiesto comienza enumerando los principales valores del
desarrollo ágil
Tabla 4. Principales valores del desarrollo Ágil
Fuente: (Letelier Patricio, 2006)
1.9. Conceptos Metodología Ágil.
La tabla No. 5 describe los diferentes conceptos emitidos por distintos autores de metodologías
ágiles.
Tabla 5. Cuadro Conceptual de metodologías agiles
PERIODO AUTORES BREVE DESCRIPCIÓN
ALGUNAS
REFERENCIAS
CLAVES
1980-
1985
Gustavo
Martinez
Muchas metodologías ágiles ya operaban en estos años, pero no
tenían reconocimiento y las empresas o desarrolladores no las
utilizaban, porque no eran confiables y no habían sido probadas.
- Martinez, Gustavo (2011).
1986
Hirotaka
Describieron una nueva aproximación holística que incrementa la
rapidez y la flexibilidad en el desarrollo de nuevos productos
comerciales, denominada SCRUM. Es comparado con el rugby,
donde el equipo entero «actúa como un sólo hombre para intentar
- Chin, Gary (2004).
A los individuos y su interacción, por encima de los proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. En resumen, es más importante construir un buen equipo que construir el entorno.
El software que funciona, por encima de la documentación exhaustiva. Aunque un software sin documentación es un desastre, la regla a seguir es “no producir documentos a menos que sean estrictamente necesarios”.
La colaboración con el cliente, por encima de la negociación contractual. Se evita el fracasar por intentar cumplir unos plazos y unos costos preestablecidos al inicio del proyecto. Por ello, se propone que exista una interacción constante entre el cliente y el equipo de desarrollo.
La respuesta al cambio, por encima del seguimiento de plan. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto, determina también el éxito o fracaso del mismo.
Takeuchi
Ikujiro Nonaka
llegar al otro lado del campo, pasando el balón de uno a otro».
1989 James Womack Daniel T. Jones Daniel Roos
Define un método llamado Lean Development (LD), en el cual los
cambios se consideran riesgosos, pero si se manejan
adecuadamente se pueden convertir en oportunidades que mejoren
la productividad del cliente. Su principal característica es introducir
un mecanismo para implementar dichos cambios.
-Mary Poppendieck, Michael A. Cusumano, "Lean Software Development (2003).
2001 Kent Beck
Impulsa un movimiento, donde diecisiete críticos de los modelos
iterativo e incremental, de desarrollo de software, basados en
procesos, se reunieron en Salt Lake City, Utah, para tratar sobre
técnicas y procesos para desarrollar software; como resultado nace
el Manifiesto ágil, donde a todo el movimiento, se le da el nombre de
Metodologías Ágiles.
-
www.agilemanifiest
o.org
-Letelier Patricio, P.
M. (2006, 01 15).
2001 Miembros del
Manifiesto ágil
Establecen la Alianza Ágil, una organización sin fines de lucro, que
promueve el desarrollo ágil de aplicaciones y da apoyo a todas las
Metodologías Ágiles, que surgen como alternativa a las
metodologías tradicionales.
www.agilealliance.o
rg
Fuente: Elaboración propia a partir de investigaciones de los autores arriba mencionados.
1.10. Metodología ágil Scrum
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. (Albaladejo, 2009). La figura No. 1 se muestra los grupos de procesos utilizados en scrum.
Figura 1. -Grupo de procesos de SCRUM (Ortega, 2010 )
PMBOK SCRUM
Fase Release
Subfase Sprint
En la tabla No. 6 se describe por componente los participantes y el esquema utilizado en Scrum.
Tabla 6. Grupo de componentes para la administración de proyectos con SCRUM. SCRUM
Componentes Participantes Esquema
Roles en
Scrum
Roles Principales
Product Owner: Representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
Scrum Master (o Facilitador): Su trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El Scrum Master no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El Scrum Master se asegura de que el proceso Scrum se utiliza como es debido. El Scrum Master es el que hace que las reglas se cumplan.
Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc). El equipo debe ser Auto - Gestionado Auto - Organizado y Multi – Funcional.
Roles Auxiliares
Son aquellos que no tienen
un rol formal y no se
involucran frecuentemente
en el "proceso Scrum", sin
embargo deben ser
tomados en cuenta.
Stakeholders (Clientes, Proveedores, Vendedores, etc): Se refiere a la gente que hace posible el proyecto y para quienes, el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.
Usuarios (Administradores, otros):
Son aquellas personas para las que se desarrolla el producto.
Reuniones de
Scrum
Participantes: Producto
Owner + Scrum Manager +
Equipo
Duración: 1 jornada de
trabajo.
Planificación del Sprint (Sprint Planning)
Seleccionar qué trabajo se hará.
Preparar, con el equipo completo, el Pila del Sprint (lista de historias incluidas en el Sprint), que detalla el tiempo que tomará hacer el trabajo.
Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint.
Fijar una fecha para la Demo del Sprint.
Participantes: Equipo +
Scrum Manager (los demás
solo pueden mirar)
Duración: 15 minutos (es
dirigida por el Scrum
Manager)
Reunión diaria (Daily Scrum)
La reunión comienza puntualmente a su hora.
Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar.
La reunión debe ocurrir en la misma ubicación y a la misma hora
todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
¿Qué has hecho desde ayer? ¿Qué es lo que harás hasta la reunión de mañana?
¿Has tenido algún problema que te haya impedido alcanzar tu
objetivo?
Participantes: Todos.
Duración: 4 horas
aproximadamente.
Revisión del Sprint (Sprint Review)
Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados (alias “demo”)
El trabajo incompleto no puede ser demostrado
Retrospectiva del Sprint (Sprint Retrospective) Después de cada sprint, se lleva a cabo una retrospectiva del sprint,
en la cual todos los miembros del equipo dejan sus impresiones sobre
el sprint recién superado. El propósito de la retrospectiva es realizar
una mejora continua del proceso.
Artefactos de
Scrum
Pila del producto (Product Backlog) :
Es un documento de alto nivel para todo el proyecto. Contiene
descripciones genéricas de todos los requisitos, funcionalidades
deseables, etc. priorizadas según su retorno sobre la inversión (ROI). Es
abierto y solo puede ser modificado por el product owner. Contiene
estimaciones realizadas a grandes rasgos, tanto del valor para el
negocio, como del esfuerzo de desarrollo requerido. Esta estimación
ayuda al product owner a ajustar la línea temporal (KEV) y, de manera
limitada, la prioridad de las diferentes tareas.
Pila del sprint (Sprint Backlog) :
Es un documento detallado donde se describe el cómo el equipo va a
implementar los requisitos durante el siguiente sprint. Las tareas se
dividen en hora; donde ninguna tarea debe superar a 16 horas. Si una
tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las
tareas en el sprint backlog nunca son asignadas, son tomadas por los
miembros del equipo del modo que les parezca oportuno.
Trabajo pendiente (Burndown chart):
Es una gráfica mostrada públicamente, que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada
Sprint. Dibujando una línea que conecte los puntos de todos los Sprints
completados, podremos ver el progreso del proyecto. Lo normal es que
esta línea sea descendente (cuando los requisitos están bien definidos
desde el principio y no varían nunca) hasta llegar al eje horizontal,
momento en el cual el proyecto se ha terminado (no hay más requisitos
pendientes). Si durante el proceso se añaden nuevos requisitos la recta
tendrá pendiente ascendente en determinados segmentos, y si se
modifican algunos requisitos la pendiente variará.
(Schwaber, 1995) - (Albaladejo, 2009)
1.11. Mapeando las prácticas del PMI al marco de trabajo SCRUM
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Las siguientes tablas describen un mapeo de algunas áreas de conocimiento del PMBOK y las prácticas de SCRUM, esto indica que podría ser posible administrar proyectos de corto y mediano plazo con una metodología ágil pero enfocada en las prácticas mencionadas en el PMBOK.
La tabla No. 7 muestra la práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM. Tabla 7. Práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión de la
Integración
Desarrollar lanzamiento del
proyecto donde se define, justifica
y autoriza el proyecto.
El Product Owner y el equipo desarrollan el Roadmap
del producto, la visión y el Backlog.
Desarrollar un plan formal de
gestión del proyecto
El equipo desarrolla el Release-plan a alto nivel y con
más detalle el plan para el siguiente Sprint.
Dirigir y gestionar la ejecución del
proyecto conforme el plan.
Monitorear y controlar el proyecto.
El equipo ejecuta y entrega. El Scrum Master se encarga
de asegurar que se cumplan los principios de Scrum. En
vez de dirigir y gestionar a los equipos, los equipos se
auto-dirigen usando revisiones de sprint, retrospectiva y
ajustan el proceso (mejora continua).
Realizar el control de cambios del
proyecto.
El Control de cambios se lleva por parte del Product
Owner y el equipo, por medio del Product backlog
ordenado. Hay un constante Feedback durante la
iteración y la revisión.
Cerrar el proyecto o la fase.
Cierres administrativos o auditorios.
Revisiones de Sprint/Retrospectiva del proyecto. Si
hace falta un cierre administrativo, se usará un Sprint n +
1 (en caso de ser necesario).
(P.M.I., 2008) - (Albaladejo, 2009)
Un Director de Proyecto tradicional es responsable de hacer que todos los procesos de esta área de conocimiento se realicen bajo un mismo patrón de gestión. Un Scrum Master tiene una función un poco más ligera, es responsable de hacer que el equipo trabaje para definir la planificación y las iteraciones. El Director de proyecto en un ambiente ágil, deberá aprender a ceder el control.
La tabla No. 8 muestra la práctica mapeada del área de conocimiento Gestión del alcance en PMBOK a su equivalente en SCRUM. Tabla 8. Práctica mapeada del área de conocimiento Gestión del alcance en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión del
Alcance
Identificar los requisitos. Obtener
y documentar los requisitos
funcionales del trabajo a realizar
Desarrollar y ordenar el Product Backlog.
Definir el Alcance. Entregables, lo
que está incluido, lo que no está
incluido, restricciones, excepciones
y dependencias.
Seleccionar los ítems del Product Backlog que se
incluyen en cada release o Sprint.
Crear la WBS. Crear una descomposición de las características para el
reléase, mostrando las que se incluyen en cada reléase.
Descomponer las características por Sprint.
Verificar el Alcance (Aceptación
formal, cambios en los
requerimientos, etc.)
A través de mecanismos de aceptación de las
características del Sprint (por el product owner), se
puede utilizar herramientas de trazabilidad y el propio
Product Backlog.
Control del Alcance. Gestionarlo vía Product Backlog. Proteger la iteración.
(P.M.I., 2008) - (Albaladejo, 2009)
La gestión del alcance es inherente al proceso SCRUM, se gestiona desde el Product Backlog. Scrum mantiene fijo el tiempo y los costos y lo único negociable es el alcance el cual es fijado al inicio del Sprint.
La tabla No. 9 muestra la práctica mapeada del área de conocimiento Gestión del tiempo en PMBOK a su equivalente en SCRUM. Tabla 9. Práctica mapeada del área de conocimiento Gestión del tiempo en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión del Tiempo
Definir Actividades: Identificar las
acciones específicas a ser
realizadas para elaborar los
entregables del proyecto.
El equipo selecciona las características que se van a
incluir en el Sprint, las tareas necesarias para cumplir
con esas funcionalidades son identificadas.
Establecer la Secuencia de las
Actividades: identificar y
documentar las interrelaciones
entre las actividades del proyecto
El equipo durante el Sprint Planning Meeting realiza la
secuencia necesaria de actividades y su estimación.
Estimar las actividades a realizar
Desarrollar el Cronograma:
Analizar la secuencia de las
actividades, su duración, los
requisitos de recursos y las
restricciones del cronograma del
proyecto.
Desarrollar el calendario de lanzamiento y solo las
características que son incluidas en el Sprint se
desarrollan y estiman (Just-in-time planning). Las
estimaciones se refinan basándose en datos empíricos
(velocidad del equipo).
Controlar el cronograma: Hacer
seguimiento al proyecto para
actualizar el avance del mismo y
gestionar cambios a la línea base
del cronograma.
El equipo es el que gestiona las características que
serán desarrolladas en cada sprint.
(P.M.I., 2008) - (Albaladejo, 2009)
SCRUM no plantea un plan definido totalmente desde el inicio del proyecto, sino que se va adecuando a medida que avanza el tiempo.
La tabla No. 10 muestra la práctica mapeada del área de conocimiento Gestión de Costos en PMBOK a su equivalente en SCRUM. Tabla 10. Práctica mapeada del área de conocimiento Gestión de Costos en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión de Costos
Estimar los Costos: Consiste en
desarrollar una aproximación de los
recursos financieros necesarios para
completar las actividades del
proyecto.
Estimar a alto nivel los reléase y los sprint usando
“veocidad”, días ideales, analogías, opiniones de
expertos, etc.
Estimar detallado cada sprint más adelante para
validar las estimaciones a alto nivel.
Refinar las estimaciones cuando el equipo va a
comenzar el trabajo.
Determinar el presupuesto: sumar
los costos estimados de actividades
individuales o paquetes de trabajo
para establecer una línea base de
costos autorizada.
Crear una línea base de costos después de realizar
las estimaciones. Revisar la línea de costos después
de un par de sprint (conocemos ya la velocidad del
equipo).
Controlar los costos: Monitorear la
situación del proyecto para actualizar
el presupuesto del mismo y gestionar
cambios a la línea base de costos.
Usar gráficos de Burndown como ayuda para el
control de los costos.
(P.M.I., 2008) - (Albaladejo, 2009)
El control de los costos es una función del equipo con el product owner involucrado en la estimación junto al equipo. En SCRUM las estimaciones se realizan a alto nivel (top-Down) de todo el proyecto y luego son refinados en el ciclo de vida del proyecto.
La tabla No. 11 muestra la práctica mapeada del área de conocimiento Gestión de la Calidad en PMBOK a su equivalente en SCRUM. Tabla 11. Práctica mapeada del área de conocimiento Gestión de la Calidad en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión de Planificar la calidad: se identifican
los requisitos de calidad y/o normas
La calidad está implícita a lo largo de todo el proceso
de Scrum. (test temprano y frecuente, software que
Calidad para el proyecto y el producto,
documentando la manera en que el
proyecto demostrará el cumplimiento
con los mismos.
funciona, eliminación de impedimentos)
La calidad es responsabilidad de todo el equipo.
Realizar el aseguramiento de la
calidad: auditar los requisitos de
calidad y los resultados de las
medidas de control de calidad.
Asegurar que se utilicen las normas
de calidad.
Generalmente la lleva a cabo el equipo. En entornos
formales puede haber un tercero implicado.
Se usan Sprint/Projects Reviews y retrospectiva.
Realizar el control de calidad: Se
monitorean y registran los resultados
de la ejecución de actividades de
control de calidad, a fin de evaluar el
desempeño y recomendar cambios
necesarios.
Realizado por el propio equipo, usando
herramientas de TDD. El Product Owner también
realiza QA por medio de las revisiones. Test de
aceptación como parte del Product Backlog (las
historias de usuario deben incluir los test de
aceptación).
(P.M.I., 2008) - (Albaladejo, 2009)
La calidad es algo implícito en las prácticas de SCRUM, es muy importante estar mentalizado para construir y mantener software de calidad, para lo que hace falta el esfuerzo y compromiso del equipo. El hecho de usar Ágil no es sinónimo de Calidad. Debemos apoyar las prácticas con herramientas que sirvan para garantizarla, con una buena estrategia de pruebas, con un enfoque a TDD (Test Driven Development) y con la mentalidad del equipo para “hacer las cosas bien a la primera.”.
La tabla No. 12 muestra la práctica mapeada del área de conocimiento Gestión del Recurso Humano en PMBOK a su equivalente en SCRUM. Tabla 12. Práctica mapeada del área de conocimiento Gestión del Recurso Humano en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión del
Recurso Humano
Desarrollar el plan de Recursos
Humanos: Identificar y documentar
los roles dentro de un proyecto,
responsabilidades etc.
En Scrum se define el tamaño del equipo para la
duración completa del proyecto. Los equipos no
suelen ser muy grandes (5 +- 2). Si el proyecto es muy
grande se crearan sub-equipos.
Adquirir el equipo del proyecto:
Confirmar personas, disponibilidad y
formar el equipo para completar las
asignaciones del proyecto.
El equipo es multifuncional. Se crea al inicio del
proyecto y se mantiene intacto hasta el final del mismo.
Desarrollar el equipo del proyecto:
competencias, interacciones de los
Valores Scrum: Compromiso, coraje, respeto, foco y
miembros del equipo y el ambiente
del equipo para lograr un mejor
desempeño del proyecto.
franqueza. Fomentar la auto organización del equipo.
Dirigir el equipo del proyecto:
Desempeño del equipo, proporcionar
retroalimentación, resolver problemas
y gestionar cambios a fin de optimizar
el desempeño del proyecto.
Facilitar un coach que ayude a auto gestionar al
equipo. Juega el rol de un líder.
(P.M.I., 2008) - (Albaladejo, 2009)
Los equipos son dedicados, multifuncionales y auto organizados. El Scrum master actúa como líder.
La tabla No. 13 muestra la práctica mapeada del área de conocimiento Gestión de la Comunicación en PMBOK a su equivalente en SCRUM. Tabla 13. Práctica mapeada del área de conocimiento Gestión de la Comunicación en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión de
Comunicación
Identificar a los interesados:
Registro de los intervinientes y
estrategia para su gestión.
Identificar a los interesados y definir quién es el
representante del negocio (Product Owner) que forma
parte del equipo Scrum.
Plan de comunicación: necesidades
de comunicación de los interesados.
Los gráficos Burndown, los backlog de proyecto y de
Sprint son indicadores visuales del estado del
proyecto
Distribución de Información: Poner
la información a disposición de los
interesados.
Los indicadores visuales del estado del proyecto son los
“radiadores de información”
Gestión de Expectativas. La gestión de los intervinientes es realizado por el
Product Owner que es parte del equipo Scrum.
Información sobre el desempeño:
Recopilar y distribuir la información
sobre el desempeño mediante
informes, gráficos, etc.
Los indicadores visuales de Scrum son los que
informan sobre el estado del proyecto.
(P.M.I., 2008) - (Albaladejo, 2009)
Es una de las principales diferencias entre los Proyectos Tradicionales y los Proyecto Scrum, en los primero los métodos de comunicación son más formales, en Scrum los intervinientes son informados a través de los indicadores visuales y una comunicación cara a cara y frecuente.
La tabla No. 14 muestra la práctica mapeada del área de conocimiento Gestión del Riesgo en PMBOK a su equivalente en SCRUM. Tabla 14. Práctica mapeada del área de conocimiento Gestión del Riesgo en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión del
Riesgo
Planificar la gestión del Riesgo:
Definir el plan de riesgos del
proyecto y las estrategias que se
seguirán, metodologías, categorías,
tolerancias...
Informar el Risk Planning como parte de Sprint/Release
Planning y reuniones de revisión. El quipo entero está
involucrado.
Identificar los Riesgos: Inventariar
todos los posibles riesgos que se
puedan presentar en el proyecto.
Identificar los riesgos en las reuniones diarias,
revisiones de iteraciones y de planificación. Analizar en
conjunto los riesgos.
Realizar el Análisis
Cualitativo/Cuantitativo de
Riesgos.
No se prescriben métodos formales. Se puede usar
cualquier método como por ejemplo probabilidad x
impacto.
Planificar la respuesta al Riesgo Eludir, mitigar, transferir, aceptar: no hay diferencia.
Monitorear y controlar los Riesgos En Scrum es parte de las tareas del equipo en las
revisiones y planificaciones.
(P.M.I., 2008) - (Albaladejo, 2009)
En cuanto a Riesgos, no hay una práctica concreta de Riesgos dentro de un proyecto Scrum. Lo más significativo es que todo el equipo participa en la identificación, seguimiento y mitigación de los riesgos. Uno de los momentos en los que aparecen es en las reuniones diarias de equipo. Lo que de aquí se derive como riesgo, será seguido y controlado por el Scrum Master (disipador de impedimentos, entre otras cosas).
La tabla No. 15 muestra la práctica mapeada del área de conocimiento Gestión de Compras en PMBOK a su equivalente en SCRUM. Tabla 15. Práctica mapeada del área de conocimiento Gestión de Compras en PMBOK a su equivalente en SCRUM.
Área de
Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente
Gestión de
Compras
Planificar adquisiciones:
Documentar las decisiones de
compra para el proyecto,
El equipo proporciona información necesaria para las
adquisiciones usando una iteración temprana o una
especificando la forma de hacerlo e
identificando a posibles vendedores.
Prueba de Concepto (PoC).
Realizar las adquisiciones: Obtener
respuestas de los vendedores,
seleccionar un vendedor y adjuntar
un contrato.
El equipo realiza las evaluaciones y proporciona
información para la contratación. Esta práctica estará
dirigida por el líder del Proyecto.
Administrar las adquisiciones:
Gestionar las relaciones de
adquisiciones, monitorear la
ejecución de los contratos, y efectuar
cambios y correcciones según sea
necesario.
Scrum permite contratos con una cláusula de
“terminación temprana” (money for nothing) en donde
un cliente puede terminar un contrato al final de
cualquier Sprint pagando el 20-30% del valor restante
del contrato.
Otro modelo es Change for free en el cual el cliente
puede hacer cambios en el ámbito sin incurrir en costos
adicionales si el monto total contratado no cambia.
Cerrar las adquisiciones Puede usarse un Sprint adiciona (n+1) para el cierre
formal administrativo.
(P.M.I., 2008) - (Albaladejo, 2009)
Las principales diferencias con los Proyectos Tradicionales se dan en los modelos de contrato. Se elaboran contratos de diversos tipos para proporcionar flexibilidad a los clientes que contratan el proyecto.
Es la gestión de Compras quizás lo más controvertido cuando se habla de un proyecto con Scrum. Se tiene la idea de que la flexibilidad y variabilidad del alcance que está siempre en el “aire” cuando se va a contratar con un proveedor (en el caso de externalizaciones) un proyecto bajo Scrum plantea dificultades de cara a la fijación de un presupuesto entre ambas partes. Hay varios modelos de contrato que se adaptan a los proyectos en ambientes Ágiles, por ejemplo Target Cost es uno de ellos.
2. Metodologia
El alcance de la investigación es de tipo Analitico-Sintetico por que se realiza separación de un todo en sus partes o en sus elementos constitutivos y luego se unen los elementos para formar un todo. Para realiza la recolección de la información, se realizó entrevista a dos Pymes de desarrollo de software que trabajan como terceros para Gases de Occidente, las preguntas se realizadas fueron claves para identificar qué de metodología utilizan en sus proyectos de desarrollo de software. Se realiza investigación sobre cada uno de los procesos definidos como buenas prácticas por el PMBOK y la manera como algunas compañías utilizan la metodología de SCRUM. Con esta información se realiza un mapeo entre cada uno de los procesos del PMBOK y los proceso utilizados en SCRUM. Una vez realizado el mapeo entre PMBOK y SCRUM se procedió a redactar la monografía con el mapeo realizado.
3. Resultados
En primer lugar, aborda el proyecto siempre con enfoque incremental. Hay que romper con la dinámica establecida del ciclo de vida en cascada (waterfall). Puede que esto sea lo que más rompa con la metodología actual de Análisis, Diseño, Construcción y Pruebas. Si ahora cuando se afronta una planificación de un proyecto lo que se debe hacer es que hasta que no finalices una etapa no empiezas la otra, debemos cambiar este concepto. Puede ser complicado al principio, pero enfocarse en crear valor para el usuario/cliente de manera rápida, lo cual se traduce en implementar funcionalidades y características del producto que se está desarrollando antes de haber terminado, por ejemplo todo el análisis del mismo. Es decir, se crea mini-waterfall y entrega producto por incrementos.
Está claro que para hacer esto, en primer lugar se debe disponer de los elementos principales de la arquitectura de un producto con plena operatividad, lo cual obliga a tener implantadas las piezas base, los elementos indispensables del core del proyecto para que sobre ellos pueda desplegar las funcionalidades de manera incremental.
El enfoque de miniwaterfall puede ser útil en entornos de proyecto donde los formalismos de la Gestión del proyecto son más estrictos: administraciones públicas, entidades financieras etc. donde hay unos patrones metodológicos más rígidos que cumplir. Sobre todo piensa en qué cosas son más importantes y aportan más valor para el cliente/usuario para ir desplegando de una manera gradual los incrementos de producto.
Aplicar las técnicas Ágiles poco a poco: puede ser complicado pretender cambiar de golpe y aplicar todas las prácticas al mismo tiempo. Introduce las técnicas de una en una, y una vez que las conozcas todas y se esté familiarizado con ellas, podrá decidir cuáles son las que le pueden dar una mejor aproximación. Ejemplo:
1) La creación de un tablón Scrum donde ir llevando las tareas (tablón físico, con su post-it de colores o un tablón virtual, apóyate en cualquiera de las muchas herramientas que existen en el mercado para este fin).
2) La reunión diaria de equipo alrededor del tablero en donde cada uno de los miembros informa a los demás que lo que ha hecho el día anterior, lo que hará en el siguiente día y los problemas o impedimentos que se ha encontrado para realizar la tarea. Familiarizarse con estas dos prácticas y luego, poco a poco, incluir el resto de prácticas.
Preparase para el cambio total: una vez que se haya preparado el proyecto con enfoque incremental y se haya implantado con éxito las dos o tres prácticas más útiles, piense si el equipo está preparado para realizar un cambio total. Esta es una aproximación con más beneficios que las implementaciones parciales, pero implica un cambio más radical y es algo que no se consigue de la noche a la mañana. Todo lleva su tiempo. Esto requiere un cambio de mentalidad en la organización, pues vas a tener que conseguir “vender” Ágil a tus clientes/usuarios. Necesitará capacitación en otras técnicas Agiles como Técnicas de Planificación de Planning Poker, Técnicas para la definición de Historias de Usuario, Técnicas y herramientas para la elaboración de gráficos de seguimiento y planificación de Sprints, Técnicas para la definición del Backlog o Pila de producto,
Retrospectivas, etc. La recomendación es que si se está empezando con Scrum, se deberá tomar con calma, se aplique poco a poco e ir “inspeccionando y adaptando”.
No hay una receta única, no hay un proyecto único, no hay un equipo único, pero tiene que haber una conciencia de cambio, una mentalidad de aportar valor desde el principio y muchas ganas de mejorar.
4. Conclusiones
Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los momentos cruciales del proyecto, además deben tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovación. Las metodologías de dirección de proyectos son pesadas y que suponen obligatoriamente un “todo o nada”. Las metodologías ágiles son más modernas y más livianas que cualquiera de las tradicionales. Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre de un entorno volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales de dirección de proyectos obligan al cliente a tomar las decisiones al inicio del proyecto. Como último comentario se puede decir que No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.).
5. Glosario Scrum RoadMap - (Que podría traducirse como hoja de ruta) es una planificación del desarrollo de un software con los objetivos a corto y largo plazo, y posiblemente incluyendo unos plazos aproximados de consecución de cada uno de estos objetivos Sprint – que es la unidad básica, el contenedor del proceso de desarrollo, por lo general tiene una duración de 2 semanas, a veces puede ser 3. Product Owner – el director (s) del producto que crea las necesidades de los usuarios. Product Backlog – una lista priorizada de las necesidades de los usuarios, generalmente se ordena con base en el valor generado a la empresa. Sprint Planning Meeting (SPM) – precede a la Sprint y Sprint se inicia con SPM, donde el propietario del producto presenta. Planning Poker – Un juego de la estimación. Para cada caso de usuario una serie de rondas de estimaciones suceda, hasta que sólo queden 2 tarjetas de estimación planteadas. y el valor superior es elegido como el punto de la historia del usuario de que la historia del usuario. Baseline User Story – una historia de usuario que se ha seleccionado como línea de base. Otras historias de los usuarios suelen ser evaluados en relación a esta historia de usuario. Siempre es recomendable escoger una historia de usuario con 3 o 5 puntos de la historia de usuario. Spike – Una investigación. Algo que no es una historia de usuario, pero tiene una consecuencia. Ejemplo incluye, si una historia de usuario no se puede implementar porque hay ciertas incertidumbres. Entonces Spike se organiza cuando el equipo se ve en eliminar las incertidumbres. Sprint Review Meeting (SRM) La reunión con la que el Sprint concluye. En el SRM el equipo presenta las historias de los usuarios para el propietario (s) del producto. User Story – La descripción, por lo general en una frase de lo que el Propietario Usuario / producto quiere lograr, seguido de una lista de criterios de aceptación. También puede incluir imágenes, dibujos. Definition of Done (DoD) – Una lista de criterios que las tareas tiene que encajar con el fin de ser marcado como realizadas. Example: User Story Definition of Done - significa las siguientes tareas deben ser realizadas en un caso de usuario:
Se cumplen todos los criterios de aceptación
Implementación terminado
La revisión de código que lleva a cabo
Pruebas unitarias escritas
La prueba funcional se ha realizado
Las pruebas de integración se escriben / realizadas
Área Regresión prueba se realiza
No Bloqueador Relacionados o bug crítico está abierto Stand up – A diario 15 minutos de pie de encuentro, donde cada miembro del equipo le dice lo que han hecho desde el standup anterior hasta ahora, qué impedimentos tienen ellos, y lo que se puede trabajar hasta la próxima standup Impediment – es un obstáculo, puede ser cualquier cosa que no permite que el equipo sea productivo. Scrum Master es generalmente responsable de la fijación / eliminación de los impedimentos. Scrum Master— una parte importante de la metodología SCRUM. Una persona que se asegura de que el equipo se adhiere a los principios de Scrum y ceremonias SCRUM. Scrum Team— el equipo de desarrollo, Scrum Master y el equipo propietario del producto, junto Sit Down - Un, Mojitos-Amigos reunión inventado informal, donde el equipo se sienta en una sala de reunión y analiza si el Sprint va según lo previsto o no? que necesita ayuda en su tarea, etc Task split – El proceso de división de la historia de usuario en tareas. Por lo general, de un máximo de 6 horas cada una. Task - Tareas de muestra pueden ser "Implementación de la funcionalidad", "creación de pruebas unitarias", "Testing Funcional", "La investigación en el tema", "la creación de pruebas de selenio automatizado" ... etc Por lo general no se limitan y las tareas nuevas se pueden inventar R&D – Una tarea en la que antes de empezar a trabajar en la historia de usuario, el equipo comprueba las diferentes soluciones posibles para ver cuál es el adecuado Scrum Board – un tablero suele dividir a 5 zonas. "Historias de usuario", "Tareas", "tareas en curso", "tareas hechas", "Miscelánea". su actualización por el equipo durante standup de cada día. Visualiza el estado de ejecución del Sprint, y hace que todo sea transparente. Confidence Level – La confianza del equipo en porcentajes, que van a ser capaces de cerrar todas las historias de usuario que se han comprometido a, por lo general se discute en el final del standup. Si está bajo, las medidas apropiadas deben ser llevadas a cabo: por ejemplo, la historia de usuario nuevas prioridades por el dueño del producto. Burn Down Chart – Un gráfico que se actualiza periódicamente para mostrar el número de horas de trabajo que el equipo todavía tiene que gastar en las tareas, y la capacidad del equipo dejó en el momento. Lo ideal sería que el gráfico se incendió y se convierte en 0, en la víspera del día de Sprint reunión de revisión. Incident – algo que no es bien recibida por el equipo, sin embargo, tiene que hacer frente. Un incidente ocurrido en el entorno de producción. Ese es un ay potencial para el éxito de la carrera, ya que el equipo necesita para encontrar las horas extra para gastar en arreglar ese problema. Retrospective– Una reunión ordinaria, celebrada inmediatamente después de la SPM, donde el equipo miembros plantean temas tanto positivos como negativos, y el grupo más tarde los temas a discutir. Retrospective Box – Una caja de papel, donde durante el sprint, los miembros del equipo caen los temas
que quieren discutir en la próxima retrospectiva.
6. Bibliografía
Albaladejo, X. (15 de 05 de 2009). Proyectos ágiles.org. Obtenido de Scrum, la manera ágil de trabajar : http://www.proyectosagiles.org
Boehm, B. (2006). View of 20th and 21st Century Software Engineering. View of 20th and 21st Century Software Engineering, (págs. In: 28th international conference on Software engineering, pp. 12--29.). Shanghai, China.
Boyd, A. (2001). The five maxims of project satisfaction. London: Emerald Group Publishing Limited.
CABALLERO CERVANTES, O. H. (10 de 06 de 2010). Tecnologías de Información y Herramientas para la Administración de Proyectos de Software. Recuperado el 11 de Junio de 2006, de Revista Digital Universitaria: http://www.revista.unam.mx/vol.7/num6/art47/int47.htm
Christiane Gresse von Wangenheim, R. S. (2013). SCRUMIA—An educational game for teaching SCRUM in computing courses. The Journal of Systems and Software, 2675– 2687.
Expósito, E. D. (s.f.). Monografias. Obtenido de http://www.monografias.com/trabajos60/metodologias-desarrollo-software/metodologias-desarrollo-software.shtml
Gonzalez, R. -E. (27 de Julio de 2010). Comparacion de PMI y SCRUM fortaleza y debilidades.
Jeff Sutherland, J. S. (1993). concibieron, ejecutaron y documentaron el primer Scrum para desarrollo ágil de software en 1993.
Jim, H. (2004). Agile Project Management: Creating Innovative Products. Boston: Pearson Education.
JMMERLO. (25 de Octubre de 2012). Be-Klan. Recuperado el Agosto de 2013, de Be-Klan: http://be-klan.com/2012/10/25/metodologias-agiles-lean-y-predictivas-un-poco-de-historia/
Kent Beck, M. B. (2001). Manifiesto por el Desarrollo Ágil de Software. Recuperado el 2013, de Manifiesto por el Desarrollo Ágil de Software: http://www.agilemanifesto.org/
Lacouture, D. J. (01 de 02 de 2010). profesores.fi. Recuperado el 09 de 2013, de profesores.fi: http://profesores.fi-b.unam.mx/jlfl/Seminario_IEE/
Letelier Patricio, P. M. (15 de 01 de 2006). Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP). Recuperado el 15 de 12 de 2005, de Técnica Administrativa, Buenos Aires: http://www.cyta.com.ar/ta0502/b_v5n2a1.htm#(1)
Nonaka, H. T. (1986). The New New Product Developement Game. Harvard Business Review.
Ortega, R. J. (10 de Noviembre de 2010 ). Introducción a SCRUM. Obtenido de http://www.slideshare.net/hhKaoS/scrum-26058110
P.M.I., (. M. (2008). Guía de los Fundamentos para la Dirección de proyectos. Estados Unidos: PMBOK Guía, 4ta Edición.
Qumer, A. H.-S. (2007). An evaluation of the degree of agility in six agile methods and its applicability for method engineering. Journal - Information and Software Technology, 250-295.
Reynoso Carlos, K. N. (10 de 04 de 2004). http://carlosreynoso.com.ar/archivos/carlos-reynoso-metodos-heterodoxos-. Obtenido de carlosreynoso.com.ar.
Sampieri, R. H. (1997). Metodología de la Investigación. En R. H. Sampieri, Metodología de la Investigación (págs. 27-28). MCGRAW-HILL.
Schwaber, K. (1995). En 1995 formalizó el proceso para la industria de desarrollo de software.
Sliger, M. (Agosto de 2006). StickyMinds.com. Recuperado el Agosto de 2013, de StickyMinds.com: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=11133&tth=DYN&tt=siteemail&iDyn=2?
Tangient, L. (2013). METODOLOGIASAGILES. Recuperado el 16 de 07 de 2013, de METODOLOGIASAGILES: http://metodologiasagiles.wikispaces.com/metodos+agiles+vs+metodos+tradicionales
Recommended