Este documento presenta un resumen de tres oraciones de la tesis "Aplicación para la gestión de proyectos ágiles con Scrum" de Jesús María Eraso Lerena. Primero, analiza las metodologías ágiles como Scrum y su funcionamiento. Segundo, detalla el desarrollo de una aplicación para gestionar proyectos usando Scrum. Tercero, la aplicación utiliza conceptos de Scrum como historias de usuario, sprints y product backlog para dirigir el proyecto.
Este documento presenta un manual de Microsoft Project 2007. Explica las funciones básicas del software, incluyendo etiquetas inteligentes y elementos de visualización. Detalla cómo crear y administrar proyectos, asignar recursos, realizar un seguimiento y ajustes, y utilizar herramientas de análisis. El manual proporciona instrucciones paso a paso sobre cómo usar las diferentes funciones de Project para gestionar proyectos de manera efectiva.
Este documento presenta la Guía Scrum de noviembre de 2020 escrita por Ken Schwaber y Jeff Sutherland. Explica que Scrum es un marco ágil para ayudar a personas y equipos a generar valor a través de soluciones adaptables para problemas complejos. Define los roles, eventos y artefactos de Scrum, así como sus valores y principios fundamentales como la transparencia, inspección y adaptación.
Este documento presenta la Guía Scrum de noviembre de 2020 escrita por Ken Schwaber y Jeff Sutherland. Explica que Scrum es un marco ágil para ayudar a equipos a generar valor a través de soluciones adaptables para problemas complejos. Describe los valores, roles, eventos y artefactos de Scrum, así como su teoría basada en la transparencia, inspección y adaptación. El propósito de la guía es ayudar a las personas a entender y aplicar correctamente Scrum.
Este documento describe las diferentes reuniones que se llevan a cabo en Scrum, incluyendo: el Sprint, la reunión de planificación, la reunión diaria, la retrospectiva, la revisión/demo y el refinamiento. Explica los objetivos, estructura y propósito de cada una de estas reuniones clave para el framework de Scrum.
Scrum es una metodología ágil para el desarrollo de productos que se basa en iteraciones cortas llamadas sprints, en las que un equipo multifuncional trabaja para crear un incremento del producto. Scrum define roles como el Product Owner, que representa los intereses de los clientes, y el equipo de desarrollo. También incluye artefactos como el product backlog y el sprint backlog, y eventos como la planificación del sprint y la revisión del incremento.
Este documento presenta conceptos básicos sobre agilismo, Scrum y Extreme Programming (XP). Explica los valores y principios de cada marco, como la comunicación, simplicidad y retroalimentación en XP. También describe técnicas ágiles como personas y escenarios, poker de planificación, tablero de tareas y desarrollo guiado por pruebas. El objetivo es proporcionar una introducción a estas metodologías ágiles para el desarrollo de software.
***** Arinbide v3.0 ************************
Metodología de desarrollo de aplicaciones software que contempla:
* Enfoque predictivo (basado en Métrica v3)
* Enfoque adaptativo (Scrum y XP)
Documentación complementaria:
>>> ARINbide-Adaptativo
Guías:
- Gestión de proyectos e Ingeniería del software: ARINbide – Adaptativo
- Gestión de proyectos e Ingeniería del software: ARINbide – Adaptativo. Anexo: Conceptos básicos
Plantillas:
- Visión del producto
- Normas, participantes y procedimientos
- Plan de entregas
- Pila de Producto
- Pila de Sprint
- Pila de Impedimentos
- Retrospectiva
- Manual de usuario
- Diseño técnico
- Acta de reunión
- Monitorización
- Defectos y errores
Kanban es un método para gestionar flujos de trabajo visualizando el trabajo a través de tarjetas en un tablero. Se basa en limitar el trabajo en progreso para mejorar el flujo continuo. Kanban se utiliza comúnmente para la productividad personal y para gestionar equipos de trabajo donde se da un servicio como la selección de personal.
Este documento presenta un manual de Microsoft Project 2007. Explica las funciones básicas del software, incluyendo etiquetas inteligentes y elementos de visualización. Detalla cómo crear y administrar proyectos, asignar recursos, realizar un seguimiento y ajustes, y utilizar herramientas de análisis. El manual proporciona instrucciones paso a paso sobre cómo usar las diferentes funciones de Project para gestionar proyectos de manera efectiva.
Este documento presenta la Guía Scrum de noviembre de 2020 escrita por Ken Schwaber y Jeff Sutherland. Explica que Scrum es un marco ágil para ayudar a personas y equipos a generar valor a través de soluciones adaptables para problemas complejos. Define los roles, eventos y artefactos de Scrum, así como sus valores y principios fundamentales como la transparencia, inspección y adaptación.
Este documento presenta la Guía Scrum de noviembre de 2020 escrita por Ken Schwaber y Jeff Sutherland. Explica que Scrum es un marco ágil para ayudar a equipos a generar valor a través de soluciones adaptables para problemas complejos. Describe los valores, roles, eventos y artefactos de Scrum, así como su teoría basada en la transparencia, inspección y adaptación. El propósito de la guía es ayudar a las personas a entender y aplicar correctamente Scrum.
Este documento describe las diferentes reuniones que se llevan a cabo en Scrum, incluyendo: el Sprint, la reunión de planificación, la reunión diaria, la retrospectiva, la revisión/demo y el refinamiento. Explica los objetivos, estructura y propósito de cada una de estas reuniones clave para el framework de Scrum.
Scrum es una metodología ágil para el desarrollo de productos que se basa en iteraciones cortas llamadas sprints, en las que un equipo multifuncional trabaja para crear un incremento del producto. Scrum define roles como el Product Owner, que representa los intereses de los clientes, y el equipo de desarrollo. También incluye artefactos como el product backlog y el sprint backlog, y eventos como la planificación del sprint y la revisión del incremento.
Este documento presenta conceptos básicos sobre agilismo, Scrum y Extreme Programming (XP). Explica los valores y principios de cada marco, como la comunicación, simplicidad y retroalimentación en XP. También describe técnicas ágiles como personas y escenarios, poker de planificación, tablero de tareas y desarrollo guiado por pruebas. El objetivo es proporcionar una introducción a estas metodologías ágiles para el desarrollo de software.
***** Arinbide v3.0 ************************
Metodología de desarrollo de aplicaciones software que contempla:
* Enfoque predictivo (basado en Métrica v3)
* Enfoque adaptativo (Scrum y XP)
Documentación complementaria:
>>> ARINbide-Adaptativo
Guías:
- Gestión de proyectos e Ingeniería del software: ARINbide – Adaptativo
- Gestión de proyectos e Ingeniería del software: ARINbide – Adaptativo. Anexo: Conceptos básicos
Plantillas:
- Visión del producto
- Normas, participantes y procedimientos
- Plan de entregas
- Pila de Producto
- Pila de Sprint
- Pila de Impedimentos
- Retrospectiva
- Manual de usuario
- Diseño técnico
- Acta de reunión
- Monitorización
- Defectos y errores
Kanban es un método para gestionar flujos de trabajo visualizando el trabajo a través de tarjetas en un tablero. Se basa en limitar el trabajo en progreso para mejorar el flujo continuo. Kanban se utiliza comúnmente para la productividad personal y para gestionar equipos de trabajo donde se da un servicio como la selección de personal.
Este documento presenta la Guía de Scrum, un marco de trabajo para el desarrollo y mantenimiento de productos complejos. Describe los valores, roles, eventos y artefactos de Scrum, incluyendo el Equipo Scrum compuesto por el Dueño de Producto, el Equipo de Desarrollo y el Scrum Master. También explica los principios de transparencia, inspección y adaptación en los que se basa Scrum, y cómo los eventos como la Planificación del Sprint, el Scrum Diario, la Revisión del Sprint y la Retrospectiva del
El documento describe Scrum, un marco ágil para gestionar proyectos complejos. Explica que Scrum utiliza equipos multifuncionales y autoorganizados para entregar valor de forma iterativa a través de sprints cortos. También destaca que Scrum se ha popularizado y ahora se utiliza en diversas industrias más allá del desarrollo de software.
Este documento presenta el proyecto SCAFFCH, cuyo objetivo es desarrollar un sistema de control de asistencia para el personal de la Institución Educativa "Francisco Flores Chinarro". Se describe la situación actual sin un sistema computarizado y cómo el proyecto busca optimizar el registro de ingresos y salidas del personal a través de una aplicación web. Además, se incluye información sobre la historia y autoridades de la institución educativa.
Este documento explica diferentes métodos para estimar el trabajo en proyectos ágiles, incluyendo el uso de días ideales, puntos de historia y Planning Poker. Se describe que las estimaciones son aproximaciones útiles pero no compromisos definitivos. También cubre tipos de estimaciones como desglosar tareas o estimar directamente los productos del backlog, y provee enlaces a recursos adicionales.
Este documento presenta el Manifiesto Ágil, que establece los valores y principios fundamentales de las metodologías ágiles. Los valores incluyen individuos e interacciones sobre procesos y herramientas, software funcionando sobre documentación extensiva, y colaboración con el cliente sobre negociación contractual. Los doce principios guían la implementación de los valores en proyectos ágiles. El documento explica que los valores y principios deben ser la base para las decisiones diarias en proyectos ágiles.
Este documento describe los principales artefactos de Scrum. Explica la Pila de Producto, que contiene los elementos de trabajo priorizados llamados PBIs. Los PBIs pueden tener el formato de Historias de Usuario, aunque no es obligatorio. También describe el Incremento de Producto resultante de cada Sprint, y la Pila del Sprint planeada para cada iteración.
Especializado en Gestión de Proyectos bajo las buenas practicas del PMBOK(PMI®) , metodología PRINCE2® y Gestión de servicios enfocados a ITIL.
Cuento con la siguientes certificaciones a nivel internacional :
PRINCE2® Practitioner Certificate in Project Management, Scrum Fundation Certified (SFC), Scrum Developer Certified(SDC), Scrum Master Certified (SMC), Scrum Product Owner Certified (SPOC) SCRUMstudy Certified Trainer (SCT), Cobit5 Foundation ,Agile Service Projects, Agile Scrum, Cloud Computing, ITIL® Service Strategy , ITIL® Service Design, ITIL® Service Transition, ITIL® Service Operation, ITIL® Continual Service Improvement, ITIL® Managing Across the Lifecycle, ITIL® Expert, Information Security ISO/IEC 27002, Secure Cloud Services, Diplomado en Gestión de Proyectos bajo las buenas practicas del PMBoK.
Este documento presenta una introducción a las metodologías ágiles. Explica el contexto histórico del surgimiento de estas metodologías, incluyendo conceptos como la revolución industrial, la era digital y la necesidad de adaptarse rápidamente al cambio. También describe principios clave como el ciclo de Deming, el triángulo de hierro, el cono de incertidumbre y el desarrollo iterativo e incremental. El objetivo final es establecer el contexto para comprender mejor las metodologías ágiles.
Este documento establece las políticas y procedimientos para las operaciones de construcción de pozos de Pluspetrol. Incluye definiciones de pozos críticos y de alta presión y alta temperatura. Detalla los requisitos para la planificación, materiales, equipos, operaciones de perforación, cementación, pruebas y control de pozos. También cubre temas como gestión ambiental, seguridad industrial y abandono de pozos.
Este documento analiza la situación actual de la empresa de impresión "Impresos Nicas" y propone posibles soluciones. Actualmente la empresa carece de controles de órdenes de trabajo, lo que causa insatisfacción de clientes e incursión en gastos extras. El documento identifica los elementos del sistema de la empresa, modela el sistema usando metodologías de sistemas suaves, determina el problema aplicando metodologías de determinación de problemas, y realiza una planificación sistémica para definir una solución óptima.
G4 mpe2 guía para la innovación de procesos en el icbf v2Diego Garcia
Este documento presenta una guía metodológica para la innovación de procesos en el ICBF. Describe 6 etapas para la innovación: 1) identificación de problemas u oportunidades, 2) ideación creativa, 3) evaluación y selección de soluciones, 4) elaboración del proyecto, 5) implementación, y 6) gestión del conocimiento. Explica técnicas para cada etapa como análisis causa-raíz, lluvia de ideas, TRIZ y matrices de evaluación. El objetivo es impulsar una cultura de
Este documento presenta una guía de formación sobre Scrum Manager. Explica brevemente los orígenes y principios de Scrum como marco para la gestión ágil de proyectos. Está organizado en varias partes que cubren los conceptos básicos de Scrum, su aplicación avanzada y ampliaciones sobre ingeniería de requisitos ágil. El propósito es ofrecer información para la implantación y mejora de Scrum en la gestión de proyectos, equipos y organizaciones.
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015Lucía Garrido Martínez
Este documento presenta el Manual de Calidad de Software de Panel Sistemas. El manual recopila los mejores artículos sobre buenas prácticas en aseguramiento de calidad de software publicados en el blog de Panel Sistemas durante 2015. El manual está dividido en tres partes: Cultura y SQA, Procesos y SQA, y Herramientas y SQA. La introducción explica que la calidad de software depende de la cultura, los procesos y las herramientas utilizadas, y que los cambios culturales producen avances más rápidos que los camb
Crystal Clear es una metodología ágil apropiada para proyectos pequeños desarrollados por equipos pequeños de hasta 8 personas. Se enfoca en la comunicación entre los miembros del equipo, la entrega frecuente de software y la retroalimentación de los usuarios. Requiere mucha documentación y no es adecuada para proyectos grandes o complejos.
Este documento propone el diseño y creación de una cubierta para el chasis de los computadores utilizando guadua con el fin de reducir la gran cantidad de basura electrónica generada por los aparatos actuales. El objetivo general es diseñar una cubierta de madera de guadua para prevenir la contaminación causada por los desechos tecnológicos de los computadores obsoletos. Los objetivos específicos incluyen reducir la basura tecnológica, utilizar un material como la guadua que se adapte al beneficio ecológ
Este documento presenta una introducción a las metodologías ágiles en el desarrollo de software. Brevemente describe algunas metodologías ágiles como XP, Scrum, FDD, ASP y Crystal Clear, destacando sus principales características y procesos. También compara las metodologías ágiles con las metodologías tradicionales, resaltando que las ágiles se enfocan más en la interacción, comunicación y entrega rápida de software funcional.
Metodologias de gestion de proyestos de desarrollo de softwareBrayan Seña
Este documento describe diferentes metodologías para el desarrollo de software, incluyendo la metodología en cascada, metodologías ágiles como Scrum y Kanban, y herramientas para la gestión de proyectos ágiles. Explica que las metodologías han evolucionado de métodos inicialmente empíricos a enfoques más estructurados y luego a metodologías ágiles para adaptarse mejor a requisitos cambiantes. También incluye preguntas sobre conceptos clave como Scrum, Sprints, roles en Scrum y razones para la
Este documento presenta los resultados de una investigación sobre la gestión de proyectos mediante metodologías ágiles. Describe varias metodologías ágiles como Scrum, Kanban y Lean y explica sus ventajas como mejorar la calidad del producto, mayor satisfacción del cliente y motivación de los trabajadores. Se detalla el proceso Scrum, incluyendo las etapas de planificación, ejecución e inspección de iteraciones. Finalmente, concluye que combinar diferentes metodologías ágiles y de gestión de proyectos puede cubrir todo el
Este documento presenta información sobre metodologías ágiles. Detalla tres métodos ágiles populares: Scrum, que se basa en iteraciones cortas llamadas "sprints" para entregar valor al cliente de forma continua; Extreme Programming (XP), que se centra en las relaciones interpersonales y la retroalimentación continua; y Kanban, que utiliza tarjetas visuales para regular el flujo de trabajo. También describe las ventajas de adoptar metodologías ágiles como mejorar la satisfacción del cliente y la productividad.
Este documento proporciona una introducción a la metodología Scrum para el desarrollo de software. Explica que Scrum es un proceso ágil que se basa en iteraciones cortas llamadas sprints para entregar incrementos de valor al cliente. Describe los principales roles como el Product Owner, el Scrum Master y el equipo de desarrollo, y las actividades clave como las reuniones diarias y las reuniones de revisión. También resume algunas ventajas y desventajas de Scrum.
Metodología, roles, actividades y artefactos que componen el modelo de proceso ágil SCRUM en el desarrollo de software y cómo lleva a maximizar el retorno de la inversión en la empresa (ROI).
Este documento presenta la Guía de Scrum, un marco de trabajo para el desarrollo y mantenimiento de productos complejos. Describe los valores, roles, eventos y artefactos de Scrum, incluyendo el Equipo Scrum compuesto por el Dueño de Producto, el Equipo de Desarrollo y el Scrum Master. También explica los principios de transparencia, inspección y adaptación en los que se basa Scrum, y cómo los eventos como la Planificación del Sprint, el Scrum Diario, la Revisión del Sprint y la Retrospectiva del
El documento describe Scrum, un marco ágil para gestionar proyectos complejos. Explica que Scrum utiliza equipos multifuncionales y autoorganizados para entregar valor de forma iterativa a través de sprints cortos. También destaca que Scrum se ha popularizado y ahora se utiliza en diversas industrias más allá del desarrollo de software.
Este documento presenta el proyecto SCAFFCH, cuyo objetivo es desarrollar un sistema de control de asistencia para el personal de la Institución Educativa "Francisco Flores Chinarro". Se describe la situación actual sin un sistema computarizado y cómo el proyecto busca optimizar el registro de ingresos y salidas del personal a través de una aplicación web. Además, se incluye información sobre la historia y autoridades de la institución educativa.
Este documento explica diferentes métodos para estimar el trabajo en proyectos ágiles, incluyendo el uso de días ideales, puntos de historia y Planning Poker. Se describe que las estimaciones son aproximaciones útiles pero no compromisos definitivos. También cubre tipos de estimaciones como desglosar tareas o estimar directamente los productos del backlog, y provee enlaces a recursos adicionales.
Este documento presenta el Manifiesto Ágil, que establece los valores y principios fundamentales de las metodologías ágiles. Los valores incluyen individuos e interacciones sobre procesos y herramientas, software funcionando sobre documentación extensiva, y colaboración con el cliente sobre negociación contractual. Los doce principios guían la implementación de los valores en proyectos ágiles. El documento explica que los valores y principios deben ser la base para las decisiones diarias en proyectos ágiles.
Este documento describe los principales artefactos de Scrum. Explica la Pila de Producto, que contiene los elementos de trabajo priorizados llamados PBIs. Los PBIs pueden tener el formato de Historias de Usuario, aunque no es obligatorio. También describe el Incremento de Producto resultante de cada Sprint, y la Pila del Sprint planeada para cada iteración.
Especializado en Gestión de Proyectos bajo las buenas practicas del PMBOK(PMI®) , metodología PRINCE2® y Gestión de servicios enfocados a ITIL.
Cuento con la siguientes certificaciones a nivel internacional :
PRINCE2® Practitioner Certificate in Project Management, Scrum Fundation Certified (SFC), Scrum Developer Certified(SDC), Scrum Master Certified (SMC), Scrum Product Owner Certified (SPOC) SCRUMstudy Certified Trainer (SCT), Cobit5 Foundation ,Agile Service Projects, Agile Scrum, Cloud Computing, ITIL® Service Strategy , ITIL® Service Design, ITIL® Service Transition, ITIL® Service Operation, ITIL® Continual Service Improvement, ITIL® Managing Across the Lifecycle, ITIL® Expert, Information Security ISO/IEC 27002, Secure Cloud Services, Diplomado en Gestión de Proyectos bajo las buenas practicas del PMBoK.
Este documento presenta una introducción a las metodologías ágiles. Explica el contexto histórico del surgimiento de estas metodologías, incluyendo conceptos como la revolución industrial, la era digital y la necesidad de adaptarse rápidamente al cambio. También describe principios clave como el ciclo de Deming, el triángulo de hierro, el cono de incertidumbre y el desarrollo iterativo e incremental. El objetivo final es establecer el contexto para comprender mejor las metodologías ágiles.
Este documento establece las políticas y procedimientos para las operaciones de construcción de pozos de Pluspetrol. Incluye definiciones de pozos críticos y de alta presión y alta temperatura. Detalla los requisitos para la planificación, materiales, equipos, operaciones de perforación, cementación, pruebas y control de pozos. También cubre temas como gestión ambiental, seguridad industrial y abandono de pozos.
Este documento analiza la situación actual de la empresa de impresión "Impresos Nicas" y propone posibles soluciones. Actualmente la empresa carece de controles de órdenes de trabajo, lo que causa insatisfacción de clientes e incursión en gastos extras. El documento identifica los elementos del sistema de la empresa, modela el sistema usando metodologías de sistemas suaves, determina el problema aplicando metodologías de determinación de problemas, y realiza una planificación sistémica para definir una solución óptima.
G4 mpe2 guía para la innovación de procesos en el icbf v2Diego Garcia
Este documento presenta una guía metodológica para la innovación de procesos en el ICBF. Describe 6 etapas para la innovación: 1) identificación de problemas u oportunidades, 2) ideación creativa, 3) evaluación y selección de soluciones, 4) elaboración del proyecto, 5) implementación, y 6) gestión del conocimiento. Explica técnicas para cada etapa como análisis causa-raíz, lluvia de ideas, TRIZ y matrices de evaluación. El objetivo es impulsar una cultura de
Este documento presenta una guía de formación sobre Scrum Manager. Explica brevemente los orígenes y principios de Scrum como marco para la gestión ágil de proyectos. Está organizado en varias partes que cubren los conceptos básicos de Scrum, su aplicación avanzada y ampliaciones sobre ingeniería de requisitos ágil. El propósito es ofrecer información para la implantación y mejora de Scrum en la gestión de proyectos, equipos y organizaciones.
El manual de la calidad software - Panel Ssistemas - 2ªedicion2015Lucía Garrido Martínez
Este documento presenta el Manual de Calidad de Software de Panel Sistemas. El manual recopila los mejores artículos sobre buenas prácticas en aseguramiento de calidad de software publicados en el blog de Panel Sistemas durante 2015. El manual está dividido en tres partes: Cultura y SQA, Procesos y SQA, y Herramientas y SQA. La introducción explica que la calidad de software depende de la cultura, los procesos y las herramientas utilizadas, y que los cambios culturales producen avances más rápidos que los camb
Crystal Clear es una metodología ágil apropiada para proyectos pequeños desarrollados por equipos pequeños de hasta 8 personas. Se enfoca en la comunicación entre los miembros del equipo, la entrega frecuente de software y la retroalimentación de los usuarios. Requiere mucha documentación y no es adecuada para proyectos grandes o complejos.
Este documento propone el diseño y creación de una cubierta para el chasis de los computadores utilizando guadua con el fin de reducir la gran cantidad de basura electrónica generada por los aparatos actuales. El objetivo general es diseñar una cubierta de madera de guadua para prevenir la contaminación causada por los desechos tecnológicos de los computadores obsoletos. Los objetivos específicos incluyen reducir la basura tecnológica, utilizar un material como la guadua que se adapte al beneficio ecológ
Este documento presenta una introducción a las metodologías ágiles en el desarrollo de software. Brevemente describe algunas metodologías ágiles como XP, Scrum, FDD, ASP y Crystal Clear, destacando sus principales características y procesos. También compara las metodologías ágiles con las metodologías tradicionales, resaltando que las ágiles se enfocan más en la interacción, comunicación y entrega rápida de software funcional.
Metodologias de gestion de proyestos de desarrollo de softwareBrayan Seña
Este documento describe diferentes metodologías para el desarrollo de software, incluyendo la metodología en cascada, metodologías ágiles como Scrum y Kanban, y herramientas para la gestión de proyectos ágiles. Explica que las metodologías han evolucionado de métodos inicialmente empíricos a enfoques más estructurados y luego a metodologías ágiles para adaptarse mejor a requisitos cambiantes. También incluye preguntas sobre conceptos clave como Scrum, Sprints, roles en Scrum y razones para la
Este documento presenta los resultados de una investigación sobre la gestión de proyectos mediante metodologías ágiles. Describe varias metodologías ágiles como Scrum, Kanban y Lean y explica sus ventajas como mejorar la calidad del producto, mayor satisfacción del cliente y motivación de los trabajadores. Se detalla el proceso Scrum, incluyendo las etapas de planificación, ejecución e inspección de iteraciones. Finalmente, concluye que combinar diferentes metodologías ágiles y de gestión de proyectos puede cubrir todo el
Este documento presenta información sobre metodologías ágiles. Detalla tres métodos ágiles populares: Scrum, que se basa en iteraciones cortas llamadas "sprints" para entregar valor al cliente de forma continua; Extreme Programming (XP), que se centra en las relaciones interpersonales y la retroalimentación continua; y Kanban, que utiliza tarjetas visuales para regular el flujo de trabajo. También describe las ventajas de adoptar metodologías ágiles como mejorar la satisfacción del cliente y la productividad.
Este documento proporciona una introducción a la metodología Scrum para el desarrollo de software. Explica que Scrum es un proceso ágil que se basa en iteraciones cortas llamadas sprints para entregar incrementos de valor al cliente. Describe los principales roles como el Product Owner, el Scrum Master y el equipo de desarrollo, y las actividades clave como las reuniones diarias y las reuniones de revisión. También resume algunas ventajas y desventajas de Scrum.
Metodología, roles, actividades y artefactos que componen el modelo de proceso ágil SCRUM en el desarrollo de software y cómo lleva a maximizar el retorno de la inversión en la empresa (ROI).
Metodología scrum-Ingeniería de Software 2Germán Aguilar
Este documento describe la metodología SCRUM, una de las más conocidas metodologías ágiles para la gestión de proyectos. SCRUM se basa en iteraciones cortas llamadas "sprints" para entregar versiones funcionales del producto de forma incremental. Ofrece beneficios como la satisfacción del cliente, la adaptación a cambios, una mayor productividad y calidad del software. Define roles clave como el Product Owner, ScrumMaster y el equipo de desarrollo.
Metodologias de gestion_de_proyectos_de_desarrollo_de_software-convertidoRudyErickAlarconAyar1
El documento describe la evolución histórica de las metodologías de desarrollo de software, comenzando con enfoques empíricos en las primeras computadoras y progresando hacia metodologías más estructuradas como la Cascada. Más recientemente, surgió la necesidad de metodologías ágiles como Scrum y Kanban para adaptarse a proyectos con requisitos cambiantes, dando lugar a una revolución en la gestión de proyectos a través de herramientas como Trello y Asana.
Este documento presenta las mejores prácticas para gestionar con éxito proyectos de software, incluyendo la planificación, estimación de costos, control de calidad y pruebas. Explica que alrededor del 70% de los fracasos en proyectos de TI se deben a la falta de implementación de prácticas esenciales. También destaca la importancia de medir el producto y proceso de software para mejorar continuamente. El documento proporciona una guía completa para la gestión efectiva de proyectos de software.
Este documento presenta las mejores prácticas para gestionar con éxito proyectos de software, incluyendo la planificación, estimación de costos, control de calidad y pruebas. Resalta que el setenta por ciento de los fracasos de proyectos de TI se deben a la falta de implementación de prácticas esenciales. Además, explica diversos modelos para la estimación de esfuerzos, como COCOMO, puntos de función y características, así como técnicas para el control y aseguramiento de la calidad
Este documento presenta la metodología Scrum para gestionar proyectos de desarrollo. Scrum es una metodología ágil que se basa en iteraciones cortas llamadas sprints para entregar incrementos de valor al cliente. Los sprints incluyen eventos como la planificación, reuniones diarias y revisión. El documento explica los roles, artefactos y eventos de Scrum así como su ciclo de vida que consiste en pre-juego, juego y pos-juego. Finalmente, destaca las ventajas de Scrum como la programación organiz
La metodología Scrum es un proceso ágil para el desarrollo de proyectos y software. Se basa en iteraciones cortas llamadas "sprints" de uno a dos meses, al final de cada una se entrega un incremento del producto. Los equipos son auto-organizados y colaborativos. Scrum es flexible para adaptarse a entornos cambiantes e inestables y produce resultados rápidamente manteniendo alta calidad.
La metodología Scrum es un enfoque ágil para el desarrollo de software que se basa en iteraciones cortas, equipos auto-organizados y entregas frecuentes de funcionalidad al cliente. Scrum utiliza sprints, reuniones diarias y una lista de producto para priorizar los requisitos y entregar valor al cliente de forma incremental.
El documento describe las metodologías ágiles para el desarrollo de software, específicamente eXtreme Programming (XP). Explica que las metodologías ágiles surgen como alternativa a los procesos tradicionales que son rígidos y centrados en la documentación. Las metodologías ágiles valoran más al individuo, la colaboración con el cliente y el desarrollo incremental, lo que las hace efectivas para proyectos con requisitos cambiantes. Luego, describe los principios y valores del Manifiesto Ágil y se enfoca en detall
Itsa metodologias de desarrollo de software (alejandra virrueta mendez)virrueta
El documento describe varias metodologías de desarrollo de software, incluyendo: (1) El modelo en cascada, (2) El modelo en espiral, (3) El proceso Racional Unificado (RUP), (4) Programación extrema (XP), (5) Desarrollo dirigido por características (FDD), (6) El marco de soluciones de Microsoft (MSF), (7) Desarrollo incremental, y (8) Desarrollo rápido de aplicaciones (RAD). Explica los principios, fases y procesos clave de cada metodolog
Integración de Diseño Centrado en el Usuario y metodologías ágiles en el desa...Víctor Manuel García Luna
Este documento resume una presentación sobre la integración del Diseño Centrado en el Usuario y las metodologías ágiles en el desarrollo móvil. Explica las similitudes y diferencias entre ambos enfoques, así como varios esquemas propuestos para integrarlos de manera efectiva a través de un proceso iterativo que equilibre la investigación de usuarios y el desarrollo rápido de funcionalidades. El objetivo final es lograr experiencias de usuario memorables aplicando los principios de ambas disciplinas.
Este documento presenta una introducción al concepto de Lean Manufacturing Software. Explica que Lean Software Development fue acuñado por los hermanos Tom y Mary Poppendieck en 1993 con su publicación "Lean Software Development: An Agile Toolkit". Lean es aplicable a todos los ámbitos del desarrollo de software, desde el propio desarrollo hasta la empresa, pasando por clientes y proveedores. Las metodologías ágiles desde la perspectiva Lean son prácticas válidas. El documento también resume algunos de los principios básicos de Lean como la mejora continua a
El documento describe las metodologías ágiles en el desarrollo de software. Explica que las metodologías tradicionales se centran en el control del proceso, mientras que las metodologías ágiles dan más importancia al individuo, la colaboración con el cliente y el desarrollo incremental. Las metodologías ágiles surgen como alternativa para proyectos con requisitos cambiantes y tiempos de desarrollo cortos. La Programación Extrema es la metodología ágil más popular, enfocándose en el trabajo en equipo, la simplic
Metodologías ágiles en el desarrollo de softwareprinceos
Este documento describe las metodologías ágiles para el desarrollo de software. Explica que las metodologías tradicionales se centran en el control del proceso, mientras que las ágiles dan más importancia al individuo, la colaboración con el cliente y el desarrollo incremental. La metodología ágil más popular es eXtreme Programming (XP), la cual enfatiza el trabajo en equipo, la comunicación continua con el cliente y la capacidad de adaptarse rápidamente a los cambios.
Metodología - Proyecto de ingeniería "Dispensador automático"cristiaansabi19
Esta presentación contiene la metodología del proyecto de la materia "Introducción a la ingeniería". Dicho proyecto es sobre un dispensador de medicamentos automáticos.
1. Introduccion a las excavaciones subterraneas (1).pdfraulnilton2018
Cuando las excavaciones subterráneas son desarrolladas de manera artesanal, se conceptúa a la excavación como el “ que es una labor efectuada con la mínima sección posible de excavación, para permitir el tránsito del hombre o de
cémilas para realizar la extracción del material desde el
frontón hasta la superficie
Cuando las excavaciones se ejecutan controlando la sección de excavación, de manera que se disturbe lo menos posible la
roca circundante considerando la vida útil que se debe dar a la roca, es cuando aparece el
concepto de “ que abarca,
globalmente, al proceso de excavación, control de la periferia, sostenimiento, revestimiento y consolidación de la excavación
Equipo 4. Mezclado de Polímeros quimica de polimeros.pptxangiepalacios6170
Presentacion de mezclado de polimeros, de la materia de Quimica de Polímeros ultima unidad. Se describe la definición y los tipos de mezclado asi como los aditivos usados para mejorar las propiedades de las mezclas de polimeros
Equipo 4. Mezclado de Polímeros quimica de polimeros.pptx
Scrum
1. Jesús María Eraso Lerena
Aplicación para la gestión de proyectos ágiles con Scrum
Jesús María Aransay Azofra
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2012-2013
Título
Autor/es
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
3. 3
Agradecimientos
Gracias a todos vosotros los que siempre estáis ahí, para lo bueno y para lo malo, por
ayudarme a desconectar, por enseñarme vuestra mejor sonrisa, por saber sacar una sonrisa
cuando hace falta, por enseñarme las lecciones de la vida que realmente importan.
Gracias todos los que formáis parte de esta etapa, todos influís en esta memoria de forma
directa o indirecta.
Gracias a mi tutor, Jesús Mª Aransay, por dirigirme otro proyecto más y seguir formándome
como Ingeniero.
Y por ultimo Gracias a mis padres y mi hermano que siempre están ahí.
4. 4
Resumen
El objeto de este proyecto surge de la necesidad de gestionar los proyectos durante su
desarrollo. Para ello se analizan en detalle las metodologías ágiles.
En primer lugar realizamos un análisis exhaustivo de las metodologías ágiles, sus ventajas
frente a las metodologías tradicionales y las técnicas asociadas. Para entrar en detalle se
nombran varias metodologías ágiles y en concreto se explica el funcionamiento de Scrum.
En segundo lugar y con el objetivo de poner en práctica y afianzar aun más los conceptos de
las metodologías ágiles, se detalla la creación de una aplicación para la gestión de proyectos
ágiles utilizando Scrum como metodología con la que dirigir nuestro proyecto. Para ello se han
utilizado los conceptos y herramientas que nos proporciona Scrum (Historias de usuario,
Sprints, Product Backlog...).
Palabras Clave: Metodologías Ágiles, Scrum, Software de Gestión de proyectos.
5. 5
Abstract
The goal of this project is originated from need to manage projects during the process of their
development. To achieve this goal we analyzed in detail agile methodologies.
First of all we make an analysis of agile methodologies and their advantages over traditional
methodologies, as well as their realated techniques. We explain several agile methodologies,
and more specifically Scrum.
Secondly, and in order to implement and strengthen even more the concepts of agile
methodologies, we detail the creation of an application for agile project management using
Scrum to manage this project. To do this we use the concepts and tools provided by Scrum
(User Stories, Sprints, Product Backlogs ...).
Key words: Agile Methodologies, Scrum, Project Management Sofware
6. 6
Índice
Licencia...................................................................................................................................... 2
Agradecimientos ........................................................................................................................ 3
Resumen ................................................................................................................................... 4
Abstract...................................................................................................................................... 5
Índice......................................................................................................................................... 6
Introducción ............................................................................................................................... 8
Metodología ........................................................................................................................... 8
Definición de metodología:.................................................................................................. 8
Metodologías Ágiles...........................................................................................................10
Extreme Programming: ......................................................................................................12
Desarrollo ágil con Scrum: .................................................................................................13
Tiempos y Métricas............................................................................................................17
Conclusión.........................................................................................................................19
Kanban ..............................................................................................................................19
Escenario...........................................................................................................................21
Alcance..............................................................................................................................22
Product Backlog.................................................................................................................23
Estudio de mercado...............................................................................................................27
Detalle de las aplicaciones destacadas..............................................................................27
Aspectos éticos y de seguridad .............................................................................................28
Planificación y metodología...................................................................................................30
Desarrollo .................................................................................................................................34
Historias de Usuario ..............................................................................................................34
Iteración 0 .............................................................................................................................35
8. 8
Introducción
Metodología
Definición de metodología:
Una metodología de desarrollo es un marco de trabajo usado para estructurar, planificar y
controlar un proceso de desarrollo de sistemas software. Todo esto engloba el enfoque de un
proceso de desarrollo de software y un conjunto de herramientas, modelos y técnicas para
desarrollar software de buena calidad. Definición de Wikipedia.
Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que se
realizan o suceden (alternativa o simultáneamente) bajo ciertas circunstancias con un fin
determinado. Definición de Wikipedia.
Un procedimiento es un conjunto de acciones u operaciones que tienen que realizarse de la
misma forma, para obtener siempre el mismo resultado bajo las mismas circunstancias.
Definición del blog parasitovirtual.wordpress.com.
Partiendo de estas tres definiciones genéricas podemos decir que una metodología trata de
organizar en la medida de lo posible los procedimientos a realizar durante la ejecución de los
procesos que conlleva un proyecto. Los procesos de las metodologías tradicionales implican
una planificación muy detallada resultando muy costoso el trabajo de planificación, diseño y
documentación. Esto no era lo que se necesitaba para proyectos pequeños o medianos en los
que el esfuerzo invertido en estas tareas superaba con creces la programación del sistema
software.
Partimos de que la ingeniería informática es una ingeniería nueva o muy reciente a diferencia
de la ingenierías industriales que ya han alcanzado su grado de madurez a lo largo de los años.
Esto ha provocado que en sus inicios se utilizaran metodologías existentes en otras áreas para
la gestión de proyectos informáticos.
Conforme van aumentando los proyectos informáticos en muchos de ellos nos encontramos
con problemas de planificación. Los objetivos del producto van surgiendo a medida que el
cliente se da cuenta que necesita algo nuevo y el proyecto se ve afectado. Esto hace que
vayan surgiendo nuevas metodologías o metodologías aplicadas en otros campos que dan
buenos resultados en la gestión de proyectos software. Varios de los creadores de estas
nuevas metodologías se reúnen en el 2001 y crean el manifiesto ágil [1] donde consiguen
poner en común una serie de principios que deberíamos tener en cuenta a la hora de gestionar
los proyectos software ágiles. Con este manifiesto se acuña el término “Metodologías Ágiles”.
9. 9
La planificación tradicional o con enfoque predictivo parte de tareas. Tiene un control
predictivo de las tareas que se van a realizar y la planificación de dichas tareas en las primeras
fases del proyecto. Esto conlleva el esfuerzo extra de predecir las posibles tareas que puedan
surgir a medio y largo plazo cuando menos información del proyecto tenemos. Posteriormente
pasamos a redactar las especificaciones en un documento que entregaremos al cliente y este
deberá validar. Si esta validación no es correcta los requisitos cambiarán durante el progreso
del proyecto y nuestra planificación habrá cambiado lo que conlleva que se alarguen los plazos,
el presupuesto y/o la calidad disminuya. Como consecuencia muchas veces la fase de pruebas
suele quedar en un segundo plano y se ve disminuido el tiempo asignado en la planificación
para esta fase.
Por el contrario la planificación ágil parte de los objetivos de negocio, es decir, objetivos
necesarios para el cliente una vez se le entrega el software. Se da por supuesto que existen
variables que no controlamos y los objetivos pueden cambiar, por ello se basa en lo empírico,
en lo que tenemos en el momento y lo que vamos realizando. Para ello deberá realizarse un
control permanente analizando qué falta por hacer.
En las metodologías ágiles también se redacta documentación pero a diferencia de las
metodologías en cascada, la documentación es más escasa, cobra menos importancia en favor
de obtener producto funcional. Sin embargo una metodología tradicional simplemente entrega
documentación de cómo va a ser el producto final.
A pesar de estas diferencias de concepto tan grandes, las metodologías tradicional y ágil tienen
características comunes. Comparten tres conceptos, los objetivos del proyecto, el tiempo y los
costes. Estos términos forman el Triángulo de hierro ya que se ven relacionados entre sí, de
modo que si uno de ellos cambia los demás se ven afectados. Es decir, si tenemos menos
tiempo es necesario reducir los objetivos o aumentar los costes. Si añadimos objetivos
aumentarán los costes y el tiempo. Si el presupuesto es muy limitado, los objetivos se reducirán
y el tiempo aumentará. Si esto no se produce, entonces comprometemos la calidad del
proyecto.
10. 10
Metodologías Ágiles
Principios de las metodologías ágiles.
● Individuos e interacciones sobre procesos y herramientas
● Software funcionando sobre documentación extensiva
● Colaboración con el cliente sobre negociación contractual
● Respuesta ante el cambio sobre seguir un plan
En estos 4 valores se resumen los 12 principios del manifiesto agil. La intención es detallar las
partes más prioritarias sobre las que son menos prioritarias cuando tratamos con un proyecto
ágil [1]. Hay que proporcionar una motivación en los individuos y confiarles la ejecución del
proyecto. Aunque se utilicen herramientas para la gestión del proyecto, el método más efectivo
y eficiente de comunicación es el cara a cara.
Es aquí donde nace nuestro proyecto; aunque existe comunicación en el equipo y la
metodología se conoce, es necesaria una herramienta software que nos ayude a gestionar los
proyectos y su documentación. Deberá permitir la consulta de estos datos por los miembros de
los equipos y por usuarios externos. Actualmente esto se hace de un modo no controlado
mediante documentos, directorios y correos electrónicos.
Para calcular las horas de los proyectos debemos revisar la documentación y esto no resulta
fácil. En muchas ocasiones sólo se conoce el coste estimado y no el coste real ya que no
tenemos un control del mismo. Además el hecho de compartir la información con el resto de
departamentos hace inmanejable trabajar con las distintas versiones de los documentos y no
tenemos constancia de qué versión dispone cada usuario y se hace necesaria una herramienta
que nos ayude.
La planificación ágil intenta organizar un equipo autogestionado de la forma más dinámica
posible pero con total control para tomar decisiones. No impone nada de serie. Partimos de
funcionalidades de negocio o historias de usuario que no deben contener especificación
alguna. Eso no implica que el equipo o un desarrollador en concreto cuando vaya a tomar la
ejecución de funcionalidad realice la documentación que para él sea necesaria, teniendo en
cuenta que lo prioritario es que funcione. La documentación se queda en un segundo plano. Si
es necesaria se hará. Por ejemplo, un manual puede ser parte de la entrega de una reunión
periódica. Otro ejemplo puede ser el diseño de la base de datos que genera un ingeniero con
los correspondientes diagramas, pero estos no son el objetivo.
Historia de usuario ¿Es lo mismo que objetivo de negocio? En primer lugar tenemos los
objetivos de negocio, los impone el cliente. Se puede decir que son lo que pretende el cliente
para sacar un beneficio (negocio). El conjunto de objetivos forma la definición del proyecto. Y
las historias de usuario son los objetivos expresados de tal forma que identifican quién, el qué y
11. 11
porqué puede hacer algo. Ejemplo: "Como cliente del banco, quiero pedir un préstamo para
poder comprar una casa" . Estas historias de usuario generan el Product Backlog. Es el primer
paso a realizar en una metodología ágil [2].
Como hemos comentado antes la planificación ágil tiene en cuenta revisiones periódicas,
siguiendo un ciclo de mejora continua o ciclo de vida iterativo. Para nuestro cliente es más
sencillo revisar y entender el producto (software) a medida que este va creciendo. Enseñárselo
cuando ya ha sido acabado supone un mayor esfuerzo y es muy probable que muchas de las
funcionalidades críticas no se correspondan con lo que él necesita.
¿Cuándo utilizar metodologías ágiles? Hay que tener en cuenta que esto no siempre es
válido. Es necesario estar dentro de un contexto y ser capaz de adaptar las metodologías a
nuestras necesidades. También dependerá del tipo de proyectos que realizamos, el escenario
no siempre acompaña para poder utilizar este tipo de metodologías al 100%. La planificación
tradicional no tiene que desaparecer, simplemente es más o menos adecuada para según qué
tipo de proyectos. Puede ser el caso de proyectos en los que tenemos el escenario controlado
y los requisitos del productos son específicos e invariables.
En las metodologías ágiles podemos encontrar una serie de prácticas o técnicas habituales a la
hora de afrontar la ejecución de un proyecto. Por ejemplo, a la hora de hacer reuniones tienen
que ser rápidas y frecuentes, lo suficientemente rápidas (ágiles) como para no perder el tiempo
pero con una frecuencia suficiente para que los integrantes del equipo estén informados de
todo. Suelen ser reuniones diarias. Cuando se trata de una reunión de planificación de iteración
en la que hay una parte del producto para entregar se re-planifica la siguiente iteración a partir
del feedback obtenido del cliente. El intervalo de tiempo entre entregas se denomina iteración.
Como se puede deducir en este tipo de reuniones participa el cliente, al que se considera uno
más del equipo.
A la hora de afrontar el desarrollo del software se puede emplear técnicas y combinarlas entre
sí. Es el caso del pair programming y test driven development. Se pueden aplicar en función de
nuestras necesidades y de nuestras posibilidades.
El pair programing consiste en programación por parejas. Mientras uno programa otro puede
estar realizando la definición de una clase y viceversa. Se sugiere cambiar los papeles cada
media hora o una hora [6]. Para muchas organizaciones esto puede resultar complicado o
imposible, ya sea por falta de personal, por mentalidad de la organización o por las
circunstancias del momento.
Test Driven Development (TDD) pretende conseguir un software de mayor calidad. La calidad
compuesta por los tres vértices del triángulo de hierro, es uno de los objetivos en las
metodologías ágiles. Con las numerosas retrospectivas se evita que el producto no sea
probado hasta el último momento y con técnicas como TDD conseguimos que nuestra
12. 12
programación, algo artesanal, solo haga lo que tiene que hacer, pasar un test. TDD o la
traducción al español, desarrollo guiado por pruebas, consiste en escribir un test automático, en
primer lugar hacemos fallar el test, en segundo lugar programamos el código suficiente para
que dicho test funcione. Por último refactorizamos1
el código para mejorar legibilidad.
Finalmente para gestionar los proyectos las metodologías ágiles también cuentan con métricas.
Pero no siempre hay que incluir todas, de hecho cuantas más métricas se usan, el coste de
recoger e interpretar datos también aumenta.
Aunque en general no se definen métricas ágiles concretas, existe un objetivo que persiguen
las métricas ágiles. Este consiste en que no se pretende medir el trabajo realizado, sino el
trabajo que queda por realizar. En el siguiente apartado veremos las métricas concretas que se
aplican en una metodología ágil concreta, en este caso Scrum.
Ejemplos de metodologías Ágiles
Algunos ejemplos de metodologías ágiles conocidas son Extreme Programming y Scrum. Son
dos metodologías adoptadas por la comunidad de desarrolladores con bastante éxito. Si bien
tienen diferencias, ambas se rigen por los principios ágiles que hemos concretado
anteriormente, y por lo tanto tienen puntos en común. Sin embargo XP se centra más en las
prácticas de desarrollo y Scrum en la organización y gestión [3].
En primer lugar vamos a ver una breve explicación de Extreme Programming, entraremos en
detalle con Scrum y por último hablaremos de la gestión visual a través de una herramienta
concreta, Kanban, herramienta que puede ser utilizada por ambas metodologías.
Extreme Programming:
Extreme Programming (XP) se rige sobre la suposición de que es posible obtener software de
gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asunción
es que con un poco de planificación, un poco de codificación y unas pocas pruebas, se puede
decidir si se está siguiendo un camino acertado o equivocado, evitando tener que echar marcha
atrás demasiado tarde [4].
Esta metodología entiende que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. En un principio se regía por 4
1
Refactorización: técnica de reestructuración de código fuente alterando su estructura pero sin cambiar
su comportamiento externo. Fuente Wikipedia.
13. 13
valores principales: Simplicidad, comunicación, retroalimentación y coraje. Pero en una
segunda edición de Extreme Programming Explained2
fue añadido el quinto, respeto.
Estos valores son aplicados en todos los aspectos que unifican el proyecto. Simplicidad, en la
documentación, en el desarrollo. Comunicación, a la hora de desarrollar las técnicas de
programación (como test unitarios, vitales en XP). La retroalimentación necesaria y fácil de
obtener ya que se incluye al cliente como parte del equipo. Coraje para afrontar prácticas que
no son gratificantes, como reescribir código, eliminar funcionalidades que no sirven para nada
después de un gran esfuerzo y además enfrentándonos con los problemas o dificultades que
nos podamos encontrar en un momento determinado pero que resolveremos si somos
persistentes. Y por último respeto al trabajo realizado por los distintos miembros del equipo. La
calidad del software es una premisa por la que todos trabajan y para ello tenemos que respetar
al equipo.
Scrum vs XP
Una característica que diferencia XP de Scrum es que los cambios son naturales y aunque en
Scrum también se contemplan, Scrum marca la reunión de revisión del sprint como
herramienta/momento en el que se deben solicitar dichos cambios. Sin embargo en XP estos
se pueden hacer en el momento en que se conocen, tenemos total flexibilidad de parar una
funcionalidad a mitad de la iteración.
Desarrollo ágil con Scrum:
Scrum parte de la esencia del desarrollo ágil. Se centra en las funcionalidades con más
prioridad y que pueden ser ejecutadas en un periodo corto de tiempo. Los ciclos de desarrollo,
llamados sprints en Scrum, producen un incremento de funcionalidad terminado y operativo.
El Product Backlog es la lista de requisitos priorizada que representa la visión del cliente
respecto a los objetivos del proyecto. Es un documento en constante evolución, aunque parte
de unos requisitos iníciales, se modifica durante el desarrollo en las reuniones de revisión del
Sprint. Para su elaboración todo el que está implicado en una tarea puede aportar sugerencias
pero se define un único responsable, llamado propietario del producto, Product Owner.
Como es un documento que varía a lo largo de las iteraciones no es necesario que esté
completado para proceder con la primera iteración. Basta con una identificación de los
requisitos que tenemos en esta fase y un detalle de los más prioritarios, es decir, por cada
requisito tenemos que detallar al menos su valor, coste estimado, una breve descripción... El
coste estimado y el valor, nos permiten conocer el retorno de inversión y serán utilizadas para
asignar un valor de prioridad a cada historia de usuario.
2
Libro escrito por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Fue uno de los 17 firmantes originales del Manifiesto Ágil en 2001.
14. 14
A través del Product Backlog también planificamos las iteraciones, agrupando de forma
coherente funcionalidades de modo que no implique un esfuerzo extra completar todos los
objetivos. Con esto acordamos que se entiende por producto completado al final de cada
iteración, garantizando que el cliente puede probar los resultado de la iteración sin problemas.
A esto hay que añadir condiciones de satisfacción por cada objetivo para lo cual se hacen
casos de prueba de aceptación durante la creación del propio Product Backlog.
Fuente: Flexibilidad con Scrum
Product Owner, propietario del producto, es la persona conocedora del entorno del cliente y de
la visión del producto. Es el responsable de obtener el mayor valor posible para el cliente o los
usuarios; también responsable de la financiación necesaria del proyecto, de la finalización y del
retorno de inversión. Si la comunicación con el cliente es muy fluida pero el cliente carece de
las habilidades necesarias para formar parte del equipo, puede ser un miembro de nuestra
organización el que haga el papel de Product Owner.
Como ya hemos dicho crea y mantiene el Product Backlog. Replanifica el proyecto antes de
cada iteración en función del valor de los requisitos. Además colabora con el equipo en la
planificación, revisión y detalle de los objetivos de cada iteración. A veces es necesario que el
proveedor se ponga en la piel de cliente e interiorice sus necesidades además de mantener en
todo momento un comunicación fluida con el cliente final.
Siguiendo la imagen anterior, el inicio de una iteración viene marcado por la reunión de
planificación, donde reunido todo el equipo se consensua el trabajo y los objetivos para esa
iteración concreta. Como resultado obtenemos el Sprint Backlog, lista de tareas a realizar
durante la iteración. Y el objetivo del sprint, funcionalidad a conseguir en ese sprint.
En Scrum la evolución de una iteración se revisa con reuniones de seguimiento diarias, en las
que se reúne todo el equipo de desarrollo, comenta el trabajo que ha terminado, el trabajo que
tiene por terminar y los impedimentos que hayan podido surgir. En estas reuniones se trabaja
con el Sprint Backlog, donde actualizamos la lista.
15. 15
El fin de una iteración o sprint conlleva la revisión del proyecto a través de otra reunión
(Revisión del Sprint) con todas las personas implicadas y comprometidas en el proyecto.
Durante la reunión se produce la oportunidad de reconducir el proyecto si algo ha cambiado,
plazos, funcionalidades, mercado actual... Como hemos comentado, en una iteración se
entrega el incremento, que debería ser un producto listo para inspeccionar, evaluar y sacar al
mercado.
Fuente: Flexibilidad con Scrum
Cabe destacar la diferencia entre personas implicadas y comprometidas. Una persona
implicada está relacionada con el proyecto, como puede ser el usuario concreto que hará uso
de la aplicación software. Sin embargo este no realiza tareas para el desarrollo del software.
Una persona comprometida se relaciona y forma parte de la ejecución del proyecto. Un ejemplo
de esta separación en el ámbito del TFG sería: las personas comprometidas con el proyecto, el
alumno y el director, frente a las personas implicadas, en este caso el tribunal.
Scrum toma la inestabilidad como premisa. No se considera que la definición detallada del
producto, ni la arquitectura software tengan que estar en una primera fase del proyecto. Como
metodología ágil que es, no será un desarrollo por fases. Esto hace que al aplicar Scrum para
desarrollo de software la práctica de refactorización es de obligado cumplimiento en las tareas
de diseño y codificación [5]. Es decir, en cada iteración se van añadiendo las nuevas
funcionalidades y se hace necesario modificar la estructura de las funcionalidades
implementadas para adoptar las nuevas sin modificar el resultado que ya teniamos.
Mientras que en una metodología predictiva la responsabilidad de las circunstancias no
planificadas las tendrá el gestor de proyectos, en Scrum se parte de equipos auto-organizados
con suficiente margen para tomar las decisiones oportunas.
16. 16
Para que todo esto funcione es necesario el Scrum Manager. En Scrum se define un rol para
que se cumpla el funcionamiento de todos los procesos y metodologías que hemos descrito
anteriormente. Tiene que garantizar que se cumplen las siguientes normas:
● Todos los involucrados deberán seguir y colaborar con las normas definidas por Scrum
en nuestra organización. Asegurar la lista de requisitos, preparar y moderar las
reuniones, guiar al equipo en la autogestión.
● Proteger al equipo de las interrupciones externas que surgen durante una iteración. Y
quitar los impedimentos que el equipo pueda tener para llegar al objetivo de la iteración.
A modo de resumen y antes de seguir con otros conceptos enumeramos los principales
términos de Scrum que hemos detallado hasta ahora.
Reuniones:
○ Planificación del Sprint
○ Seguimiento del Sprint
○ Revisión del Sprint
Elementos:
○ Product Backlog
○ Sprint Backlog
○ Incremento
Roles:
○ El propietario, Product Owner.
○ Equipo
○ Scrum Manager
Fuente: Flexibilidad con Scrum
17. 17
Tras este pequeño resumen que nos ayuda a clarificar los conceptos básicos proseguimos con
las métricas y los conceptos relacionados que define Scrum.
Tiempos y Métricas
Los siguientes conceptos surgen del funcionamiento de Scrum. Son necesarios para la
planificación y la supervisión continua del proyecto. Como resultado obtendremos los gráficos
Burn-up y Burn-down de los que hablaremos más adelante.
● Tiempo real: El tiempo efectivo de trabajo. Se mide en horas o días.
● Tiempo teórico: El tiempo ideal para realizar un trabajo.
● Puntos de función: Unidad de medida relativa para determinar la cantidad de trabajo
necesaria para construir una funcionalidad del product backlog.
● Estimaciones: Cálculo del esfuerzo que se prevé necesario.
Existen multitud de técnicas para estimar el coste de las tareas.
● Velocidad absoluta: La cantidad de producto construida en un sprint. Se mide con la
misma unidad relativa que las estimaciones.
● Velocidad relativa: En este caso no se mide en unidades relativas sino en la unidad de
medida del tiempo de trabajo; horas de trabajo, semana de trabajo real.
En base a estas definiciones se trabaja la planificación y las constantes revisiones del proyecto.
Generamos una unidad de medida abstracta conocida para todos los miembros del equipo
(puntos de función). Ej: coste de desarrollar un login de usuario en PHP. En base a esta unidad
asignaremos el coste de realizar cada historia de usuario entre todos los miembros para que
sea algo consensuado.
Como métodos de estimación 3
se pueden utilizar el método de póquer, la sucesión de
Fibonacci... Estos métodos favorecen la participación y que nadie se quede sin opinar además
de resolver los posibles malentendidos en los objetivos. Una vez estimadas las historias de
usuarios el Product Owner se encargará de priorizarlas por valor de negocio. Este orden puede
variar y ser primero el Product Owner quien asigna prioridad a las historias de usuario.
Ahora a partir de nuestra unidad de medida abstracta podemos calcular la velocidad absoluta y
velocidad relativa que vienen a ser la velocidad de producto construido en un sprint y velocidad
de producto construido en una unidad de tiempo de trabajo.
Estas métricas se pueden representar en los gráficos Burn-up y Burn-down, dos gráficos que
reflejan la gestión y avance del producto y del sprint correspondientemente. Para conocer la
estimación de cuándo acabaremos tenemos el gráfico Burn-down que nos puede ayudar con
esto.
3
Metodos de Estimacion: http://www.proyectosagiles.org/
18. 18
Burn-down chart o gráfico de trabajo pendiente que nos permite conocer si acabaremos el
proyecto en la fecha indicada. Muestra la velocidad a la que se van cumpliendo los objetivos.
Existen dos versiones de este gráfico, una se centra en ver el trabajo pendiente del proyecto
global y en la segunda se refiere al trabajo del sprint en el que nos encontramos.
En el siguiente gráfico observamos el trabajo pendiente en horas de la iteración en curso.
Fuente: www.proyectosagiles.org
En el caso del gráfico Burn-up permite conocer al Product Owner las versiones previstas, las
funcionalidades de cada una, velocidad estimada, fechas previstas, margen de error y
velocidad real.
Fuente: Flexibilidad con Scrum
19. 19
Este gráfico se representa con el esfuerzo estimado y los sprints planificados. Conocido el
esfuerzo de cada una de las versiones o funcionalidades nos permite visualizar el momento o
sprint en el que llegamos a nuestro objetivo en función de la velocidad a la que avancemos.
Conclusión
Tras esta introducción a Scrum tenemos claros los conceptos que a partir de este momento
podremos utilizar en nuestro proyecto. Los conceptos serán de aplicación tanto para la gestión
de nuestro proyecto, como para definir los objetivos del proyecto.
Para finalizar es importante señalar que estas son simples prácticas ágiles agrupadas en un
nombre (Scrum). Utilizar una de ellas estrictamente no es algo flexible y perdería su esencia.
Se pueden combinar y adaptar prácticas ágiles de una y otra metodología en función de
nuestro escenario y nuestros requisitos.
Nuestro objetivo es encontrar flexibilidad y esta se consigue conociendo todas nuestras
posibilidades y emplearlas de la forma más adecuada a las circunstancias de cada proyecto y/o
de cada empresa.
Kanban
Kanban es una herramienta muy utilizada en la gestión ágil que no viene asociada a una
metodología concreta pero que resulta muy útil en combinación con las metodologías ágiles
como herramienta de gestión visual. En ningún caso se debe entender como una metodología
en sí misma, sino una técnica para comunicar información relativa a los trabajos que
realizamos.
Gestión Visual: Toda la información relevante debe estar a la vista. Uno de los primeros
sectores en utilizarla fue el automovilismo en su propio proceso de construcción y
posteriormente se trasladó para comunicar las normas de circulación (Señales de tráfico).
Teniendo en cuenta la gestión visual, Kanban se define como sistema de señalización para
comunicar información relativa y necesaria en la ejecución o monitorización de trabajos. [6]
El hecho de que sea tan visual y físico hace que sea óptimo para proyectos ágiles y cada vez
hay más adaptaciones de proyectos Scrum que adaptándolo a sus necesidades utilizan
Kanban para representar los elementos que forman Scrum. Esto se produce entre otras cosas
gracias a que Kanban no define un formato cerrado de tarjetas o tableros Kanban. Esto no
daría la flexibilidad necesaria para adaptar las técnicas a las características de una
organización concreta.
Si enmarcamos Kanban dentro de los proyectos ágiles, se le pueden atribuir características que
favorecen el cumplimiento de los principios ágiles. Favorece la comunicación, la cultura del
equipo y colaboración. Facilita el control o gestión del proyecto ya que los elementos gráficos
reflejan esta información en todo momento.
20. 20
Puede ser un elemento a tener en cuenta dentro de aplicaciones informáticas mejorando la
comunicación con los usuarios y en nuestro caso concreto dando a conocer la información
global de uno o varios proyectos con una primera consulta visual.
21. 21
Descripción del producto a desarrollar
Escenario
Vistos los distintos tipos de metodologías que se contemplan, entramos a describir el entorno
del cliente, el modo de trabajo, los equipos de trabajo, la estructura organizativa y el objetivo de
producto para el cliente.
Se trata de una mediana empresa en la que el departamento de Sistemas de la Información
está compuesto por dos áreas separadas de trabajo, Hardware y Software. En este caso
concreto el departamento está formado por 10 miembros.
La gestión de proyectos se realiza con metodologías ágiles adaptadas. Esto quiere decir que
no siempre tenemos equipos multidisciplinares como pueden exigir algunas metodologías
inicialmente. No siempre te puedes permitir el pair programing debido a las dimensiones del
departamento. Los integrantes de cada equipo pueden variar en función del proyecto/s en
curso. En determinadas fases de un proyecto se puede echar mano de otro compañero, ya sea
del mismo área o no, es decir hay miembros del equipo que se incorporan para unas tareas
concretas y no durante todo el proyecto.
Solo el departamento IT utilizará la aplicación para la gestión de proyectos que pretendemos
desarrollar. El resto de departamentos o no necesita esta gestión o ya tiene sus propias
herramientas.
Teniendo en cuenta este tipo de limitaciones y otras muchas que iremos detallando, el principal
objetivo del cliente es poder medir. El propio departamento necesita conocer los costes de
tomar unas u otras decisiones, permitiendo analizar los resultados y mejorar en la toma de
decisiones. Además otros departamentos como el de administración necesitan conocer los
costes económicos de un desarrollo interno, soporte técnico, deuda técnica4
, etc. Es decir,
tenemos el mismo personal para la ejecución de proyectos, para resolver dudas técnicas,
resolución de incidencias, o bugs provenientes de otros desarrollos.
Actualmente no hay una gestión controlada de estas interrupciones y ante estas situaciones es
necesario establecer prioridades y proceder, el equipo es autosuficiente para tomar las
decisiones que considere oportunas. Como consecuencia los proyectos se pueden ver
afectados en alguno de los tres conceptos del triángulo de hierro.
Por parte del departamento de IT y siguiendo con los principios ágiles, los integrantes del
equipo no necesitan conocer cuánto tiempo han empleado en realizar un tarea, sprint, iteración,
un proyecto...Lo necesario para ellos es conocer cuánto falta para llegar al objetivo.
4
La deuda técnica es un eufemismo tecnológico que hace referencia a las consecuencias de un
desarrollo apresurado de software o un despliegue descuidado de hardware.
22. 22
El cliente no impone ninguna restricción del tipo de proyecto a acometer, si tiene que ser una
aplicación propietaria, una aplicaciones base que podamos adoptar o un servicio SaaS
(Software as a Service).
Alcance
En una primera aproximación se detectan los objetivos de negocio que detallaremos a
continuación. Estos vienen determinados por ramas bien diferenciadas. En primer lugar los
objetivos del propio departamento de IT, que necesita de una herramienta para gestionar
proyectos con Scrum y en segundo lugar para departamentos externos que lleven el control de
costes y análisis de proyectos internos.
La aplicación gestiona proyectos, usuarios y equipos. Los usuarios con un perfil personal se
agrupan en equipos con un rol determinado. A su vez un equipo tiene asignado un proyecto. Y
los proyectos contienen toda la información relacionada: actas, historias de usuarios, contratos,
planificación, coste real, etc. Aunque no es un requisito propio de la metodología, es muy útil la
posibilidad de tener la información asociada al proyecto.
Siguiendo la definición de Scrum, el cliente forma parte del equipo, pero por ahora no se sabe
si este tiene que poder utilizar la aplicación o no.
Una vez procesados los objetivos de negocio, tenemos las tareas agrupadas por historias de
usuario. Es necesario que estas tareas sean asignadas a los miembros del equipo. Para que se
pueda asignar una tarea tiene que estar completa, con coste estimado de realización. Los
miembros del departamento IT tienen una restricción de productividad: Les impide tener varias
tareas en ejecución. A medida que las tareas estén completas, a los usuarios se les van
asignando otras en ejecución. Además todo esto debe permitir recoger la duración real del
proyecto.
En numerosas ocasiones los usuarios interrumpen la ejecución de una tarea para realizar otra
más urgente. Es el caso de bugs informáticos, nuevas funcionalidades en proyectos anteriores,
que tienen mayor prioridad que el proyecto en curso y es necesario cambiar de tarea.
Los errores o tareas clasificadas con prioridad “urgente” se gestionan del siguiente modo.
Cuando se decide qué tenemos que hacer, la tarea se asigna a uno de los empleados del Dpto.
y este valorará su alcance, pudiendo llegar a ser un proyecto nuevo o una versión de otro
anterior. Si se trata de un error o algo de menor alcance se decide quién la ejecuta y se
procede. Puede ser necesaria la intervención de varios compañeros.
Como ya hemos comentado anteriormente, debemos conocer el avance y coste de cada
proyecto, incluso de los que están en ejecución, teniendo en cuenta que para el equipo Scrum
lo necesario será conocer qué falta por hacer.
23. 23
Por ahora tampoco se contempla que la documentación se gestione de forma interna con
herramientas de colaboración. Puede ser necesario adjuntar archivos a los proyectos e incluso
solventar los problemas de versión de archivos de un modo transparente. Un ejemplo de
documentación a añadir pueden ser los manuales de usuario.
Para mostrar la información de control se debe tener la posibilidad de exportar en distintos
formatos que nos permitan trabajar con los datos. A través de los informes también podremos
conocer el origen, los costes y toda la información relacionada con los trabajos ejecutados por
el equipo.
Respecto a las métricas que deberá permitir, partimos de dos requisitos, uno viene dado por la
gestión de proyectos ágiles, permitir estimar el coste de los objetivos. Y el segundo requisito,
dado por el cliente, es que debe permitir conocer las horas invertidas en cada tarea y/o el coste
final real de cada tarea. Aunque se tiene claro que el cálculo de los costes es un requisito
prioritario, por ahora no existe una decisión unilateral de qué métrica utilizar.
Podríamos utilizar el tiempo en horas pero no para todo el mundo significa lo mismo una hora
de su tiempo. Podemos asignar un coste monetario a una hora de trabajo. O concretar una
hora de trabajo y un usuario específico. Pero las tareas luego no tienen el mismo valor, los
empleados tienen un coste variable...Entramos en un escenario que no tenemos claro y
tomaremos una decisión durante la marcha del proyecto. Por ahora tomamos la decisión de
que controlamos únicamente el tiempo.
Product Backlog
A continuación detallamos la primera versión de nuestro Product Backlog. Conforme vayamos
completando las historias de usuarios este podrá sufrir modificaciones en cada iteración. Se
han divido en dos tipos de historias de usuarios, las historias que aportan funcionalidad y valor
al usuario y las historias no funcionales pero que de algún modo aportan valor y hemos
considerado oportuno que aparezcan.
27. 27
Estudio de mercado
Antes de pasar a desarrollar el proyecto, se analizará el mercado para ver las soluciones
existentes y ver si es necesario realizar un desarrollo propio, o adaptar alguna aplicación que
ya exista en el mercado.
Actualmente el desarrollo del software avanza cada vez más rápido y es posible que si
investigamos a fondo soluciones que ya tenemos en el mercado puedan resultar
completamente funcionales para nuestro cliente y únicamente tengamos que gestionar su
implantación después de verificar que los objetivos de nuestro cliente están cubiertos.
En esta primera fase de investigación de mercado detectamos las siguientes aplicaciones que
están relacionadas con alguno de los objetivos del proyecto. A partir de la definición de
nuestras historias de usuario, se procederá con el análisis de las mismas para revisar qué
aspectos no son cubiertos y comparar con las prioridades asignadas por nuestro Product
Owner en los objetivos del mismo. Si en algún caso no se cubren las historias de usuarios con
mayor prioridad esta aplicación será descartada inmediatamente.
Detalle de las aplicaciones destacadas
Trello.com
Se podría definir como un tablero virtual, nos permite configurar varios tableros, añadir otros
usuarios con los que compartir nuestros tableros y un historial de cambios así como
notificaciones. En definitiva es una pizarra Kanban a la que podemos acceder vía web. Al ser
únicamente tableros deja a un lado la parte de gestión de proyectos, historias de usuarios y su
posterior análisis.
Jira
Bastante más complejo que el anterior ya que no se trata de un simple aplicación web. Cuenta
con multitud de plugins que nos permiten añadir funcionalidad adicional en base a nuestros
requisitos, podemos desarrollar nuestros propios plugins e incluso comercializarlos. La mayor
dificultad de esta opción sería el adecuarnos a una forma concreta de hacer las cosas. Aunque
sea personalizable siempre existe la posibilidad de que el método de trabajo no sea el que
busca el cliente. Respecto al precio por ahora estaríamos hablando de 50$ mensuales
permitiendo hasta 15 usuarios, totalmente escalable si crecemos en usuarios.
Esta opción nos obligaría a formarnos en dicha herramienta o contratar alguien con
experiencia, además de formarnos como usuarios para poder implantar la solución en nuestro
cliente.
28. 28
Groupcamp.es
Se presenta como una aplicación web para el trabajo en equipo añadiendo la gestión del
tiempo y los presupuestos. Permite conectarse con otras aplicaciones como Office, Google,
email interno. La falta de plugins o acceso a un API, nos impediría modificar la aplicación y/o
añadir nuevas funcionalidades específicas. Además aunque la aplicación permite la gestión de
proyectos y una amplio abanico de funcionalidades relacionadas no trata una metodología
concreta como es nuestro caso.
Detalladas las tres aplicaciones que más nos han interesado durante el análisis de mercado y
en un principio nos podrían ayudar, tras un segundo análisis más exhaustivo nos encontramos
una aplicación que no gestiona proyectos, otra aplicación que gestiona proyectos sin seguir una
metodología y una tercera aplicación, plataforma con plugins y api, muy completa la cual no
conocemos y sería necesaria formación y/o ayuda externa y que además podría añadir
complejidad con opciones que nuestro cliente no tiene intención alguna de utilizar por ahora.
Aspectos éticos y de seguridad
A la hora de llevar a cabo el proyecto deberemos tener presente una serie de aspectos legales,
éticos y de seguridad que pueden influir en los requisitos del mismo.
Desde el punto de vista Ético, la aplicación trata relaciones laborales del grupo de desarrollo
con otros miembros de la empresa del mismo rango o superior.
Aunque la propia empresa no persiga la finalidad de controlar a los empleados, estos pueden
pensar lo contrario. Pueden llegar a dudar de la privacidad ante otros compañeros, etc.
Además para la empresa puede resultar muy tentador comparar las métricas de uno u otro
empleado. Esto influye directamente en una de las historias de usuario proyectadas (A7) según
la cual solo debemos ver nuestro control de tiempos y un coste total del resto de usuarios.
Si durante la ejecución del proyecto surgen otras cuestiones relacionadas con los aspectos
éticos deberemos tenerlas en cuenta para garantizar a las partes implicadas que se cumplen
estas condiciones y su privacidad está asegurada en la medida de lo posible.
Como toda aplicación informática deberá tener presente en todo momento la seguridad. Una
vez esté concretado el tipo de aplicación (extranet, intranet, escritorio), se tendrán en cuenta
las medidas de seguridad más adecuadas. Por ahora se conoce que la aplicación manejará
datos de empleados, de proyectos internos de la empresa, de clientes y proveedores que
29. 29
deberán confiar en la herramienta que les proporciona nuestro cliente. En este punto contamos
con cierta incertidumbre, es decir, lo que para alguien se considera inseguro puede ser una
garantía de seguridad para otro. Aclaramos este punto con el siguiente ejemplo. Una aplicación
basada en software libre y mantenida por una amplia comunidad de usuarios nos da las
garantías de que un fallo en la seguridad será notificado y solucionado con bastante premura.
Pero a su vez esto hace que un posible atacante pueda aprovecharlo para conocer nuestras
debilidades antes de ser subsanadas.
Otro aspecto de vital importancia serán los aspecto legales. Estamos realizando una página
web con datos personales de clientes, proveedores y empleados, es decir deberemos cumplir
la LOPD. En este caso debemos incluir una referencia de los datos personales que trata la
página web (nombre y correo electrónico), explicando el uso que haremos de estos datos. La
LOPD también nos obliga a cumplir una serie de políticas de seguridad y registrar nuestro
fichero de datos personales en la AEPD, Agencia Española de Protección de Datos [7].
Una medida de seguridad a la hora de utilizar un mecanismo de identificación mediante usuario
y contraseña será aplicar un mecanismo de cifrado con salt 5
y a su vez un algoritmo de cifrado
concreto que por ahora no se considere inseguro en caso de que alguien acceda al
almacenamiento de nuestras contraseñas. El uso de salt criptográfico añade una dificultad
extra a la hora de intentar crackear un hash almacenado en la base de datos.
En cuanto a la seguridad física, se podrá dar el caso de que tengamos que elegir un proveedor
u otro si los datos requieren de un hardware específico para garantizar mayor nivel de
seguridad, contratar un hardware específico (Ej: firewalls), o incluso instalar la aplicación en un
servidor propio del cliente de modo que éste tenga el control de los mismos. Por ahora estos
requisitos no se conocen y se plantean durante la ejecución del proyecto.
5
Salt Criptográfico: Un salt criptográfico es un dato que se utiliza durante el proceso de hash para
eliminar la posibilidad de que el resultado pueda buscarse a partir de una lista de pares precalculados de
hash y sus entradas originales. Fuente: php.net.
30. 30
Planificación y metodología
En primer lugar detallar que la metodología a seguir se basa en las metodologías ágiles que
hemos descrito en este capítulo, concretamente Scrum. Siguiendo el guión6
predefinido para
Trabajos Fin de Grado, describiremos la ejecución del proyecto con los conceptos definidos por
la metodología que realmente nos resulten útiles buscando el objetivo principal de las
metodologías ágiles, no utilizar una metodología rígida sino adaptarla a nuestras necesidades.
Para afrontar la ejecución del desarrollo se han identificado los objetivos de negocio en
historias de usuario, asignado un coste aproximado, un valor de negocio y priorizando en
función de estos valores. Para estimar el coste no se han utilizado técnicas específicas como
las mencionadas en la descripción de la metodología, debido a que el equipo se compone de
una única persona y las ventajas que nos ofrecen son fomentar la participación y evitar los
malentendidos entre los miembros de un equipo. Para dar prioridad hemos tenido en cuenta
que nuestros objetivos de negocio no son los mismos que para un cliente real. En vez de un
beneficio económico, se busca un beneficio académico.
Otro punto a diferenciar entre Scrum y nuestra ejecución son las reuniones. Aunque se han
celebrado reuniones después de cada iteración (reunión de revisión y de preparación) y se ha
ido revisando avance del sprint durante su ejecución (reunión diaria), en ambos casos no se
han seguido al pie de la letra las recomendaciones que implica Scrum; es decir, realizar la
reunión de forma automática, sin tener en cuenta que es la primera tarea del día, juntar
reuniones de revisión con reuniones de preparación, etc.
Respecto a la planificación hay que tener en cuenta que hay establecidas las siguientes
limitaciones: 300 horas y entrega a mediados del mes de Junio. Con una dedicación de 19
horas a la semana en 4 meses cumpliríamos la horas estipuladas y dejaríamos un pequeño
margen para posibles interrupciones. Dentro de la planificación de sprints o iteraciones
tenemos en cuenta que disponemos de un tiempo limitado y para obtener un producto con una
funcionalidad aceptable los sprints no deben superar la duración de 1 semana. A partir de la
duración de 1 semana por sprint hemos asignado coste estimado en el Product Backlog y la
velocidad media de desarrollo debería ser de 1000 puntos por semana.
6
Guión predefinido por la Facultad de Ciencias, Estudios Agroalimentarios e Informática de la
Universidad de La Rioja
31. 31
En el gráfico anterior se representa la línea de tiempo planificada. Al comienzo del mismo está
la fase de documentación, compuesta por la exposición del problema y documentación sobre el
tema del proyecto que formará el primer mes. La segunda parte, Análisis, nos ocupa la primera
mitad del segundo mes, que continúa con el desarrollo de la aplicación durante 2 meses. Y
para finalizar dejamos 2 semanas como mínimo para la redacción de la memoria final, sacar
conclusiones y finalizar el proyecto.
Ahora para reflejar la correspondiente planificación haciendo uso de las herramientas que nos
proporciona Scrum vamos a utilizar el gráfico Burn-up.
32. 32
El Burn-up anterior nos muestra la comparativa de una estimación ideal frente a una optimista y
otra pesimista. Para realizar esta comparativa se ha aumentado y disminuido en 300 puntos la
velocidad por semana estimada anteriormente. Además permite conocer en qué momento de
una u otra estimación tendremos disponibles las distintas versiones. Para ello se estima que la
primera versión utilizable será después de la 2ª iteración en los 4000 puntos (Alpha) y una
segunda versión de prueba más estable a los 8000 puntos (Beta). Ahora la gráfica nos permite
conocer cómo la versión “Beta” puede acabar retrasándose hasta las 11 o 12 semanas de
duración. Una vez este gráfico empiece a dibujar la línea de la duración real nos iremos
haciendo una idea de cuál es nuestra velocidad y estimar en cada momento cuál será nuestra
fecha fin para cada versión.
33. 33
Dada la planificación anterior podemos definir los sprints agrupando historias de usuario según
su prioridad. La siguiente tabla nos muestra las historias de usuario priorizadas hasta la fecha y
agrupadas por iteraciones hasta la iteración 2 que forman la versión Alpha. El resto de historias
priorizadas o no serán analizas e incluidas en próximas revisiones del Product Backlog.
N Sprint
Identificador
Objetivo Descripción
Coste
estimado
Valor
aportado Prioridad
Iteración 0 B6
Tecnología y
Herramientas 800 1100 1
800
Iteración 1 B1 Login de usuarios 400 1100 2
B5 TDD 600 1100 3
B2 Crear usuarios 200 1100 4
A1 Dar alta proyecto 300 1000 5
A2
Eliminar/Finalizar
proyectos 300 200 6
B4
Definir y crear una
interfaz gráfica 200 200 7
2000
Iteración 2 A3
Alta Historia de
Usuario 200 1000 8
A4
Modificar Historia de
Usuario 200 500 9
A6 Creación de tareas 400 1000 10
A7 Procesar tareas 400 1000 11
1200
Versión Alpha 4000
A8
Acceso Director,
Proyectos 300 600 12
A5
Acceso cliente,
Historias Usuario 300 500 13
A9
Representación visual
de los datos 1200 500 ?
Destacar cómo en algunos casos no se llega a la planificación estimada y en otros la
sobrepasamos. Aunque podríamos mezclar historias de usuario se ha preferido dejar las
historias de usuario agrupadas siguiendo la prioridad asignada inicialmente. La iteración 1 tiene
un coste estimado de 2000 puntos y aunque podemos separarla creando otra iteración se
prefiere dejar estas historias en la misma iteración puesto que son la toma de contacto con el
framework de acceso a datos y TDD.
34. 34
Desarrollo
En esta sección vamos a detallar cómo hemos afrontado el proyecto, la descomposición de las
historias de usuario en tareas, entrando en detalle de las tareas que se consideren oportunas y
detallando la evoluciones, describiendo así la organización y metodología seguidas para el
desarrollo.
Historias de Usuario
En el Product Backlog se han incluido las historias de usuario funcionales que enumeramos
como resultado de los objetivos de negocio y en segundo lugar historias de usuario especiales
que contienen requisitos no funcionales o que se dan por supuesto. Destacar que en el Product
Backlog no se ha tenido en cuenta las primeras fase del TFG, la ejecución de la memoria,
algunos aspectos de formación e investigación en metodologías ágiles ni la preparación de la
defensa final.
Durante la creación del Product Backlog y descomposición de historias de usuario en tareas,
nos hemos perdido una parte valiosa de la metodología que es poder ejecutar esta tareas en
equipo, permitiendo contrastar opiniones y detectar posibles errores. Como base para
comenzar estas tareas se han tenido en cuenta algunos consejos, malas prácticas,
consejos...como por ejemplo:
● Escribir qué se debe hacer y no cómo se debe hacer.
● Las tareas deben seguir los principios INVEST7
.
7
INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable [8]
35. 35
Iteración 0
Esta primera iteración denominada “Iteración 0” recibe este nombre por el hecho de la historia
de usuario (B6) que agrupa. Se ha dudado si incluirla en el Product Backlog. Finalmente
después de varias reflexiones se cree conveniente que quede reflejado ya que se considera
como un punto igual o más importante que el resto y el Product Owner o cliente debe ser
consciente de ello.
Backlog Tarea Tipo Descripción Responsable Estimación
B6 Tarea 1 Investigación Brainstorming de
tecnologías/herramient
as
J.M 20%
B6 Tarea 2 Investigación Brainstorming de
requisitos técnicos
J.M 20%
B6 Tarea 3 Investigación Documentarse sobre
las ideas destacadas
J.M 30%
B6 Tarea 4 Investigación Toma de decisiones J.M 20%
B6 Tarea 5 Investigación Control de versiones &
Scrum
J.M. 10%
En primer lugar detallar cómo se ha rellenado la columna de estimación en este y el resto de
sprints backlogs. En este caso y debido al entorno y variabilidad que podemos obtener en las
horas dedicadas en un día se ha decidido incluir un porcentaje de la duración completa del
Sprint. Dado el tipo de tareas que tratamos en esta iteración, la duración real de la misma no
será muy valiosa para verificar las estimaciones realizadas.
Respecto a esta iteración cabe destacar la tarea 4, "Toma de decisiones". Partiendo de los
requisitos del cliente, conocemos que deberá ser accesible desde varias organizaciones; por
ello podemos concretar que vamos a desarrollar una aplicación web ya que facilita dicho
requisito. Este tipo de aplicaciones se ven más expuestas a posibles ataques y la información
puede estar expuesta, pero aplicando la medidas oportunas durante la fase de desarrollo se
asume el posible riesgo.
Una vez conocido el tipo de aplicación las tecnologías a utilizar son más concretas aunque
seguimos teniendo muchas posibilidades. En este punto y teniendo en cuenta el contexto y los
plazos de ejecución, la experiencia del equipo será un punto a tener en cuenta a la hora de
36. 36
elegir la tecnología. Por ello se cierran las opciones a programar con PHP valorando si
seleccionar un framework conocido o no. Las últimas opciones a elegir son Silex 8
y
Codeigniter9
. El primero se trata de un microframework que destaca por su gran velocidad de
desarrollo con multitud de librerías y su gran modularidad para seguir desarrollando
aplicaciones más complejas. Además se basa en Symphony10
, otro framework PHP que ha se
ha ganado un nombre en la comunidad de desarrolladores durante los últimos años; sin
embargo su curva de aprendizaje es muy elevada. En este punto y teniendo en cuentas otros
objetivos tomamos la decisión de utilizar Codeigniter con el fin de ahorrar tiempo para
documentación e investigación de otros temas, ya que este framework es conocido por el
equipo.
Una vez seleccionado el framework buscamos un ORM11
que nos facilite la implementación en
la capa de acceso a datos. En este caso elegimos Datamapper12
, no se conoce ningún ORM
anteriormente por lo que la decisión está basada en la documentación encontrada del propio
ORM ya que está pensado únicamente para utilizar con Codeigniter y su instalación es muy
sencilla. Otros ORM como Doctrine más conocidos pueden resultar más complejos
inicialmente.
En segundo lugar y para el almacenamiento de los datos que conectará con el ORM utilizamos
MySQL13
, simplemente por ser el SGBD más conocido por el equipo y su facilidad de uso.
Para llevar a cabo la implementación de las distintas funcionalidades y teniendo en cuenta que
estamos utilizando una metodología ágil vamos a profundizar en el desarrollo guiado por test o
más conocido como Test Driven Development (TDD). Por ello en esta fase nos hemos
adentrado en su filosofía y cuál es el método a seguir sin centrarnos en cómo implementarlo en
PHP. Para ello se ha incluido una historia de usuario específica en la siguiente iteración.
Por último detallar que para llevar un control del desarrollo utilizaremos software de control de
versiones, concretamente GIT. El resto de opciones son desconocidas y esta nos permite una
instalación descentralizada y no requiere configuraciones complejas. Siguiendo el objetivo
principal el flujo de trabajo con GIT vendrá dado por la metodología ágil. De este modo con
cada historia de usuario crearemos un rama (branch) a partir de la cual iremos creando otras
ramas por cada tarea dentro de la misma historia y que fusionamos a la rama principal de la
historia una vez esté terminada la funcionalidad concreta de la tarea. Posteriormente podemos
eliminar las ramas de las tareas, guardando una referencia a la rama eliminada con una
etiqueta. Este método será seguido a su vez con la ramas que hacen referencia a las historias
de usuario. Una vez que son aprobadas, pasan a la rama principal de desarrollo14
.
8
http://silex.sensiolabs.org
9
http://ellislab.com/codeigniter
10
http://symfony.com
11
ORM: Object-Relational mapping [9]
12
http://datamapper.wanwizard.eu/
13
http://www.mysql.com/
14
Se dan por supuestos los términos y conocimientos propios de los Sistemas de control de versiones.
37. 37
En el siguiente diagrama podemos ver el ciclo de creación de ramas junto con las etiquetas que
se crean al fusionar una rama en otra y ser eliminadas. Ej: La rama task1 se fusiona con la
rama “historia de usuario” y creamos una etiqueta #task1 antes de seguir con la siguiente tarea
en la rama task2.
38. 38
Iteración 1
En esta segunda iteración (considerada la primera desde el punto de vista de los requisitos del
cliente) vamos a tratar las historias de usuario A1, A2, B1, B3 y B4. Estas historias se
descomponen en el siguiente Sprint Backlog. Como vemos en el tabla, el número de tareas
respecto a la iteración anterior ha aumentado considerablemente. Teniendo en cuenta el
número de tareas y que existen temas desconocidos para el encargado de las mismas,
ampliaremos la duración de esta iteración a 2 semanas (coincidiendo con el esfuerzo estimado
y planificación del mismo).
Backlog Tarea Tipo Descripción Responsable Estimación
B1 Tarea 1 Análisis y diseño Modelo de datos J.M 10%
B1 Tarea 2 Implementación Crear clases MVC J.M 5%
B2 Tarea 3 Implementación Creación de
formularios y
métodos
J.M 5%
B5 Tarea 3 Documentación TDD y PHP J.M 20%
B5 Tarea 4 Implementación Creación de test
unitarios
J.M 10%
A1 Tarea 5 Implementación Implementar MVC
para proyectos
J.M 10%
B5 Tarea 6 Pruebas Creación de test
unitarios
J.M 15%
A2 Tarea 7 Implementación Implementar
funcionalidad
J.M 5%
A2 Tarea 8 Pruebas Creación de test
unitarios
J.M 10%
B4 Tarea 9 Implementación Programar la
estructura y diseño
de las vistas
J.M 10%
Descompuestas las tareas de las historias que comprenden esta iteración vamos a detallar los
aspectos más importantes a la hora de llevar a cabo la iteración.
Las historias B1 y B2 son la base para comprender el funcionamiento del ORM seleccionado. A
través de un ejemplo que implementa un mecanismo de Login y creación de usuarios creamos
39. 39
nuestros modelos y controladores. Al mencionar modelos y controladores estamos
refiriéndonos al patrón MVC15
, a través del cual estructuramos la aplicación.
En la siguiente historia de usuario (B5) comenzamos con la búsqueda de la herramientas
necesarias para llevar a cabo los test unitarios de forma más cómoda. Los test unitarios es la
primera tarea que implica la técnica TDD. En este caso y debido que es nuestra primera
aproximación a esta técnica, partimos de un desarrollo ya realizado sobre el que crearemos los
test unitarios. Como framework principal para test unitarios en PHP tenemos PHPUnit; a la hora
de abordar los tests sobre nuestras clases y métodos específicos para el framework elegido,
utilizaremos otra librería externa, my-cuinit16
que nos facilite la creación de test entre PHPUnit y
CodeIgniter.
Obviando los pasos de instalación y configuración nos centraremos en un ejemplo de test
unitario con el fin de clarificar su funcionamiento. En este ejemplo vamos a testear el método
privado encrypt de la clase modelo User.
Dado un nombre de campo (valor del campo $field) y un salt aleatorio guardará en la propiedad
que se corresponde con el valor del campo el contenido de dicha propiedad concatenado con el
salt y encriptado mediante el algoritmo sha512. Si el contenido de la propiedad es vacío no se
hace nada y si no tenemos un salt generamos uno aleatorio y encriptamos.
15
MVC o Modelo Vista Controlador: Patrón de arquitectura de software.
16
Framework para test unitarios con PHPUnit y Codeigniter 2.1.0 Fuente
40. 40
Definido el funcionamiento del método podemos testear las siguientes condiciones:
● Si la propiedad a la que referencia el parámetro $field está vacía/empty (no tiene valor)
la propiedad deberá seguir vacía.
● Si la propiedad salt está vacía al ejecutar el método se creará un salt y almacenará el
valor en la propiedad.
● Si la propiedad salt tiene un valor este será el mismo después de ejecutar el método.
41. 41
● Si la propiedad que pasamos como parámetro tiene valor, después de ejecutar el
método no será el mismo.
● Tras ejecutar el método el valor almacenado en la propiedad que hace referencia el
valor del campo $field deberá ser igual a la concatenación del salt con el valor de la
propiedad encriptados con el algoritmo sha512.
En este punto hemos creado 5 test unitarios que verifican el correcto funcionamiento del
método encrypt. La finalidad de los test unitarios es testear la única responsabilidad de un
método, en este caso encriptar la cadena correspondiente cuando se cumplen las condiciones.
Un test está formado por tres partes, que se denominan con las siglas AAA: Arrange, Act,
Assert, es decir, preparar, actuar y afirmar. Esto hace que en muchos test la fase de Arrange
sea la misma y los frameworks nos proporcionan los mecanismos para no tener que reescribir
el mismo estado por cada test. Un ejemplo es el método setUp(), de la clase UserModelTest
que hereda de CUInit_TestCase. Nos permite ejecutar cualquier sentencia con anterioridad e
independencia entre nuestros tests. Respecto a la parte de Act, se refiere a la ejecución de
nuestro método a implementar. Y por ultimo en la parte de assert, a través de los métodos
proporcionados por el framework aseguramos que el resultado de la fase de actuación es el
esperado.
A la hora de testear un método debemos asegurarnos que estamos testeando una única
responsabilidad. Por ello los métodos deberán tener una única responsabilidad y si hay más
deberemos separar cada responsabilidad en un método nuevo. Hasta este punto hemos estado
42. 42
testeando, validación de estado. Pero en determinados casos no es posible y es necesario
realizar validación de iteración. Un ejemplo de validación de iteración es cuando nos
encontramos con elementos que modifican el estado del sistema, como por ejemplo las clases
que acceden a bases de datos.
Los test de validación tienen como objetivo evaluar la interacción entre las partes sin que se
llegue a realizar el acceso a la base de datos. Es entonces cuando utilizamos objetos mocks
que nos proporciona el framework. La filosofía de estos métodos es proporcionar una interfaz
que define todos los métodos que implementa nuestra clase de acceso a BD, de modo que en
la validación verificaremos la iteración de nuestros métodos con los distintos métodos que
acceden a la BD pero llamando a los métodos que define la interfaz del objeto mock (es decir
sin acceder realmente a la BD, simplemente verificando que se efectúa la llamada [10]).
Tras esta pequeña introducción a los test unitarios hemos visto un claro ejemplo de test unitario
de estado ejecutado durante esta iteración junto con otros test de estado. Al continuar con los
test unitarios de la clase User, nos encontramos con el método Login que pasa a utilizar
métodos de acceso a BD y deberemos testar su iteración. La complejidad de los test de
iteración, añadida al desconocimiento de los frameworks de test y la escasa documentación
encontrada hace que la duración de la iteración se vea comprometida y debemos tomar una
decisión. En este punto se decide finalizar la iteración con las siguientes tareas y poder
entregar el resultado funcional y no testado que tenemos hasta el momento, perdiendo calidad
pero asegurándonos cierto margen de entrega.
Finalizada la iteración en un pequeño ejercicio de análisis, revisión del sprint, se decide seguir
adelante con la 2º iteración dando prioridad a las historias de usuario que componen la
siguiente iteración frente a la historias de usuario B4.
Como ya hemos adelantado en párrafos anteriores la planificación de esta iteración, aun siendo
estimada para dos semanas se ha alargado la duración de la misma en un 100% debido a la
falta de conocimientos en TDD y la formación necesaria.
43. 43
Iteración 2
El resultado de esta iteración planificada para una sola semana ya debería darnos como
resultado una versión Alpha de la aplicación sobre la que el cliente ya puede ir viendo el futuro
de la misma y si nos estamos desviando del objetivo final.
Backlog Tarea Tipo Descripción Responsable Estimación
A3, A4,
A6, A7
Tarea 1 Análisis y diseño Modelo de datos J.M 30%
A3 Tarea 2 Implementación Crear clases,
métodos MVC
J.M 20%
A4 Tarea 3 Implementación Creación de
formularios y
métodos
J.M 10%
A6 Tarea 4 Implementación Crear clases y
métodos MVC Task
J.M 20%
A7 Tarea 5 Implementación Crear clases y
métodos MVC Timer
J.M 20%
En esta iteración empezamos con el análisis y diseño del modelo de datos que deberemos
ampliar respecto al creado en la iteración anterior. Estas relaciones afectan también a nuestros
objetos de tipo Modelo (clase de tipo modelo siguiendo el patrón MVC, implementado por los
frameworks que hemos seleccionado). En ellas se reflejan todas las relaciones entre entidades
en ambos sentidos y en este caso se han configurado para disponer de los objetos
relacionados automáticamente. Es decir, al cargar los datos de un registro en un objeto, en la
misma instrucción estamos cargando los datos de los registros relacionados en la propiedad
correspondiente. Un caso real dentro de nuestra implementación son los objetos User_story y
Task. Ambos están relacionados y esto se refleja en la propiedades al definir cada clase. Ahora
al cargar una historia de usuario (User_story) en la misma sentencia estamos cargando los
datos de las tareas (Task) relacionadas en la propiedad task del objeto User_story
Por ahora el modelo de datos es sencillo y el número de usuarios está controlado, de modo que
no afectará al rendimiento de la aplicación de un modo drástico.
En la 2º tarea así como en otras tareas similares, que implementan la funcionalidad necesaria
para enviar datos del usuario a la aplicación, se ha utilizado validación de datos en dos
sentidos, es decir, en el lado del cliente y en el del servidor. En el lado del servidor utilizamos la
validación de HTML5 y en el servidor los métodos proporcionados por el ORM.
En la reunión de revisión del Sprint nos encontramos con una aplicación centrada en las
historias de usuario, las tareas y el control de tiempos. Pero se ha perdido el foco de la
44. 44
metodología, que la propia aplicación nos invite a seguir los pasos básicos que conlleva utilizar
Scrum. Esto puede ser causa de una mala identificación y definición de las historias de usuario.
Revisaremos los criterios de aceptación que darán lugar a un iteración intermedia; antes de
proseguir con las siguientes historias de usuario debemos garantizar que están finalizadas las
historias ejecutadas hasta el momento.
Criterios de validación:
Los dos primeros requisitos de la historia A2 (eliminar/finalizar proyectos) se cumplen,
pero en el segundo se puede ser más específico. O incluso añadir un nuevo requisito, al
intentar eliminar/dar de baja un proyecto que no está finalizado o con datos deberá
mostrar un mensaje de error al usuario. Además el tercer criterio no se cumple y
tampoco se ha definido en qué consiste la finalización de un proyecto.
El primer criterio de la historia A7 (procesar tareas) es erróneo. Aunque haya otros
miembros asignados se pueden seguir asignando miembros. Además en el segundo
criterio debería concretar qué datos son los que se reflejan.
Falta un criterio de aceptación que verifique el resultado de cambiar el estado de una
tarea.
Los criterios de la tarea B4 (definir y crear una interfaz gráfica) no son válidos. Esto ha
hecho que en la iteración 1 no se detecten errores y en este momento sí. Un criterio
válido puede ser: La aplicación deberá permitir conocer la situación del usuario en todo
momento dentro de la plataforma de forma inequívoca y por varios métodos.
Antes de comenzar con la iteración de revisión, se ha incluido un gráfico Burn-down para
analizar el esfuerzo realizado durante la ejecución de las primeras iteraciones.
45. 45
En el gráfico anterior podemos ver cómo la iteración 1 tiene un gran descenso de los puntos de
esfuerzo ejecutados. Esto refleja el retraso que tiene la iteración durante la ejecución de las
tareas 3, 4 y 6 de dicha iteración. Una vez eliminado el causante del retraso la velocidad se
recupera e incluso supera la velocidad estimada.
Iteración 2B
En la reunión de preparación del Sprint se prepara el Sprint Backlog y se concreta el
funcionamiento de las tareas a ejecutar.
Backlog Tarea Tipo Descripción Responsable Estimación
B4 Tarea 1 Implementación Aplicar las correcciones
visuales en la
estructura de las
páginas.
J.M 15%
A2 Tarea 2 Análisis y diseño Definir los estados de
un proyecto
J.M 10%
A2, A7 Tarea 3 Diseño Redefinir el modelo de
datos
J.M 10%
A2 Tarea 4 Implementación Implementar los
estados de un proyecto
J.M 15%
A2 Tarea 5 Implementación Implementar acciones
automáticas según
estado de un proyecto
J.M 25%
A7 Tarea 6 Implementación Limitar permisos de
modificación de tareas
durante su ejecución
J.M 25%
Se han detallado las tareas resultantes de analizar los criterios de aceptación correspondiente
a la iteración 1 y 2 aunque lo correcto hubiera sido revisar los criterios de la iteración 1 antes de
comenzar con la iteración, si no son validos no se debería dar por terminada la iteración y en
consecuencia no debemos empezar una iteración nueva.
En este punto hemos alcanzado la situación actual del proyecto. Esta iteración continuará
cuando terminamos la documentación del proyecto y el resultado será reflejado en la aplicación
resultante al finalizar la iteración.
46. 46
Revisión Product Backlog
Antes de proseguir con las iteraciones se ha realizado una actualización del Product Backlog
con el fin de mejorar los objetivos de negocio y su ejecución.
Una vez eliminadas las historias de usuarios finalizadas se han reescrito algunas historias de
usuario y sus criterios de validación. Con el objetivo de centrarnos únicamente en la siguiente
iteración solo se han dado prioridad objetiva a las 4 siguientes historias. La siguiente iteración
estará formada por las tareas A8 (acceso director, proyectos), A5 (acceso cliente, historias de
usuario) y B3 (dar de baja usuarios) que juntas hacen un esfuerzo estimado de 900. El hecho
de no llegar a los mil punto se debe que por ahora no tenemos una velocidad estable, en las
anteriores iteraciones no se ha mantenido el ritmo y no se ha llegado a una velocidad de 1000
puntos semana.
En el siguiente Burn-up podemos ver reflejado el cambio de estimación, planificando a una
velocidad media de 900 puntos por semana y con un margen de error de ± 250 puntos de
esfuerzo. Debido a que nuestra velocidad real alcanzada ha tenido muchos altibajos como
podemos observar en el gráfico Burn-down17
no sirve base real para calcular la velocidad
media que se acerca a los 700 puntos por semana. Superados los problemas que nos han
frenados estas primeras iteraciones se espera aumentar la velocidad pero teniendo en cuenta
que 1000 puntos por semana era una estimación optimista.
17
Página 44
47. 47
Este grafico Burn-up, actualiza la anterior planificación18
realizada a 1000 puntos por semana.
En esta planificación partimos de las 7ª semana de ejecución habiendo conseguido una
ejecución de 4000 puntos de esfuerzo.
Replanificando observamos cómo la fecha idea para la versión beta se ha pasado hasta la
mitad de la semana 11, mientras que al principio estaba planificada para la semana 8. Sin
embargo cabe destacar que la iteración pesimista inicial coincide con la nueva planificación.
Dicho esto podemos observar como aun tenemos otras dos líneas de planificación pesimista y
optimista. Puesto que se trata de nuestros inicios en la metodología no tenemos suficiente
información para poder disminuir el margen de error. En este caso se ha reducido en 50 puntos
con el objetivo de acotar la planificación y ser más explícitos. Aunque tenemos en cuenta que el
error anterior ha sido importante y tampoco podemos pasarlo por alto.
En la siguiente tabla observamos la actualización de historias de usuario y sus criterios de
aceptación. Puesto que hemos priorizado únicamente las 4 siguientes historias, una vez esté
finalizada la iteración 3, será necesaria otra actualización del Product Backlog y
obligatoriamente priorizar las siguientes historias. De este modo seremos más conscientes de
los posibles cambios y las necesidades antes de seguir con el desarrollo, y podemos tener en
cuenta los posibles errores o aciertos que hemos ido teniendo a lo largo del proyecto.
Las historias de usuario no ejecutadas son el reflejo del trabajo futuro que puede tener este
proyecto. Funcionalidades como la generación de gráficos automáticamente en base al trabajo
será de gran aporte al proyecto, esto se refleja en el Product Backlog. Junto a esta se han
quedado a la espera otras historias de usuario que aportan el valor de la metodología a la
aplicación. Teniendo esto como principal meta, también hay que mencionar la necesidad de
crear una aplicación de calidad y esto implicara documentarse lo necesario para realizar los
test unitarios para testear el funcionamiento de lo que tenemos hasta el momento y continuar el
desarrollo con TDD.
18
Página 31
49. 49
Conclusiones
En esta última sección de la memoria, vamos a detallar las conclusiones que hemos obtenido
de la ejecución del TFG.
El objetivo marcado era crear una aplicación para la gestión ágil de proyectos dirigidos
utilizando Scrum. Para ello nos hemos adentrado en el mundo de las tecnologías ágiles
concretando el funcionamiento de Scrum que para entenderlo y poder reflejarlo mejor se ha
utilizado como metodología para dirigir y ejecutar nuestro proyecto.
Es cierto la aplicación se ha quedado en una versión Alpha, que no refleja al 100% nuestro
objetivo final por las dificultades encontradas durante la ejecución del proyecto. Por otro lado
hemos obtenido una formación y visión de las metodologías ágiles entendiendo los valores que
defiende y sus indicaciones, gracias a la puesta en marcha de las mismas en un proyecto real.
Estas dificultades han venido dadas por la necesidad de documentación previa en la
metodologías y las áreas que se abren dentro de un proyecto ágil, entre ellas el desarrollo
guiado por test, TDD. Entendidos los principios y las ventajas de esta "técnica" de desarrollo
apenas hemos podido poner en marcha y ver las ventajas en nuestro propio proyecto. Los test
que hemos podido poner en práctica nos garantizan que nuestra programación testada será de
mayor calidad y en caso de existir un error podremos excluir esa parte como la causa del
mismo.
El hecho de utilizar metodologías ágiles no implica la falta de un método, sino que simplemente
se rigen por unos principios más flexibles y orientados a la situación real de algunos proyectos
que están expuestos a un cambio constante y/que en su fase inicial no están definidos ni se
conocen las posibles dificultades que podemos encontrarnos. Además de esto, en todo
momento se tiene en cuenta la calidad de lo que hacemos y entiende que estamos realizando
un trabajo artesanal que puede tener errores. Por ello incluye como técnica de desarrollo TDD.
Respecto a Scrum y los pasos que nos indica son la base para una ejecución ágil, si no
tenemos experiencia en la dirección de proyectos son el mejor punto de partida que
posteriormente podremos adaptar a nuestro entorno y experiencia. La herramientas que nos
proporciona pueden resultar un poco abstractas y complejas. En particular la descomposición
de los objetivos en historias de usuario totalmente independientes y con un lenguaje coloquial,
compartido por el Product Owner y el equipo. La descomposición de las historias en tareas
independientes nos ayuda a organizar el trabajo en equipo y aunque no ha sido aplicable en
nuestro entorno, la descomposición en tareas ha resultado un aspecto bastante abstracto.
Viniendo de las metodologías tradicionales en las que no se hace referencia a estos conceptos,
50. 50
es complicado descomponer las funcionalidades en tareas totalmente independientes sin una
experiencia previa, de modo que nos hemos basado en la documentación previa a partir de la
cual tomar nuestras decisiones.
Un ejemplo puede ser la creación del modelo de datos. En nuestro Product Backlog no hay una
historia de usuario que refleje la creación del modelo de datos. En un principio hemos llevado al
extremo la independencia de las historias y en cada una se define el modelo de datos para las
funcionalidades que indica. En la segunda iteración se decide crear un modelo de datos que
refleje todas las historias de usuario de la iteración. Finamente después de esta experiencia
empezaríamos un proyecto con una historia de usuario para el modelo de datos general. En
ella deberíamos identificar las entidades y relacionarlas entre sí. Esto se complementaría con
una tarea específica que identifique las propiedades de las entidades implicadas en la iteración
que estamos ejecutando.
Otra característica de Scrum y que inicialmente hemos dejado de lado son las reuniones. Al no
ser un proyecto en equipo, o el equipo estar compuesto por un solo miembro y un director tutor,
que ha compartido el rol de Product Owner con el alumno, las reuniones sin el tutor no tenían
lugar como tales. Por ello en la segunda iteración se concreta la reunión de revisión en la que
sí se han revisado los criterios expuestos en el Product Backlog y posteriormente se han
tomado las medidas oportunas para cumplir los criterios. Las revisiones de sprint sirven de
utilidad para conocer el estado del proyecto día a día. En nuestro caso se reflejan aún más sus
ventajas puesto que la dedicación en este proyecto no es 100% día a día y se hace más
necesaria una revisión y planificación de lo que hemos hecho y lo que nos queda por hacer.
Para terminar destacar que la experiencia ha sido satisfactoria, sacando en claro muchos
aspectos de las metodologías agiles y el porqué plantearse utilizarlas al inicio de un proyecto.
En este caso debido a la naturaleza de nuestro proyecto, dirigir proyectos ágiles, y al
desconocimiento de área que aborda, era de vital importancia conocer desde nuestro punto de
vista la metodología. Esto ha propiciado que la planificación no sea lo más acertada y nos
hayamos desviado, no llegando al esfuerzo estimado medio que inicialmente se planificó. Aun
así, sí que estamos dentro del margen definido en aquella primera planificación, haciendo así
que seamos conscientes de las complicaciones que pueden surgir durante la ejecución del
proyecto. Esto nos da un claro ejemplo de lo importantes y útiles que resultan los elementos
que nos ofrecen Scrum.
51. 51
Bibliografía
Referencias bibliográficas:
1. http://agilemanifesto.org
2. http://www.proyectosagiles.org/
3. Scrum y XP desde las trincheras. Autor: Henrik Kniberg
4. Flexibilidad con Scrum. Autor: Juan Palacio
Principios de diseño e implantación de campos de Scrum
5. http://www.navegapolis.net
6. Gestión visual: Kanban
Apuntes Curso ScrumManager
7. http://www.bonillaware.com/
8. jmbeas.es
9. Wikipedia
10. Diseño Ágil con TDD: Carlos Blé Jurado y Colaboradores
Otras referencias
javiergarzas.com
queridointernet.wordpress.com
devnettips.blogspot.com.es
www.genbetadev.com
Documentación técnica
http://ellislab.com/codeigniter
http://datamapper.wanwizard.eu/
http://www.mysql.com/
http://git-scm.com/book/en/
http://www.php.net