Estructura

36
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de Metodologías ágiles

description

Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de Metodologías ágiles. Estructura. contextualización. Contextualización. Calidad Productividad Agilidad Desarrollo ágil de software ¿Por qué implementar el desarrollo ágil?. - PowerPoint PPT Presentation

Transcript of Estructura

Page 1: Estructura

Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software

por medio de Metodologías ágiles

Page 2: Estructura

Estructura

Page 3: Estructura

CONTEXTUALIZACIÓN

Page 4: Estructura

Contextualización

• Calidad• Productividad• Agilidad• Desarrollo ágil de software• ¿Por qué implementar el desarrollo ágil?

Page 5: Estructura

Contextualización

• ProductividadRelación entre los resultados y el tiempo utilizado para obtenerlos: cuanto menor sea el tiempo que lleve obtener el resultado deseado, más productivo es el sistema.

Page 6: Estructura

Contextualización

• AgilidadCapacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno.– Innovación

La permanencia de estas empresas depende de su capacidad de innovación continua.

– FlexibilidadEn las circunstancias de velocidad del mercado actual, es importante la capacidad de adaptación y evolución a través de versiones, modificaciones, actualizaciones o ampliaciones.

Page 7: Estructura

Desarrollo ágil de software

• El desarrollo ágil es simplemente la evolución natural del proceso de software para apoyar el acelerado y cambiante entorno empresarial. A través de un enfoque ligero y de baja ceremonia para el desarrollo de software, incorpora un conjunto de mejores prácticas de gestión y de ingeniería para acelerar y mejorar el proceso de entrega.

Page 8: Estructura

¿Por qué es importante el desarrollo ágil?

• Los proyectos de software fallan porque:

– Se pretenden predecir y planear todos los requerimientos de antemano en un entorno cambiante.

– Se solicitan demasiados cambios y los plazos de entrega son ampliados constantemente.

– Los procesos de desarrollo y gestión de cambios son poco flexibles.

Page 9: Estructura

¿Por qué es importante el desarrollo ágil?

– El equipo ve a los entregables y control de cambios como un fin y no como un medio para entregar software funcional.

– Los usuarios no se involucran.– La calidad se sacrifica al tratar de imponer tiempos

poco realistas.– El producto no está debidamente probado.

Page 10: Estructura

¿Por qué es importante el desarrollo ágil?

• Las metodologías ágiles de desarrollo de software proponen simplicidad y velocidad para crear software maximizando su valor, con mayor calidad y en menor tiempo.

Page 11: Estructura

¿Por qué es importante el desarrollo ágil?

• Innovación continua: Para cumplir con las necesidades actuales del cliente.

• Adaptabilidad del producto: Para cumplir con las necesidades futuras del cliente.

• Mejora del tiempo de entrega al mercado: Para satisfacer las ventanas de mercado y mejorar el Retorno de la inversión (ROI).

• Adaptabilidad de personas y procesos: Para responder rápidamente a los cambios de producto y negocio.

• Resultados confiables: Para apoyar el crecimiento de negocio y la rentabilidad.

Page 12: Estructura

Metodologías ágiles

Metodologías ágiles más usadas, según los resultados de la encuesta realizada por la compañía VersionOne.

Page 13: Estructura

Metodologías ágiles

• SCRUM• eXtreme Programming (XP)• Dynamic System Development Method (DSDM)• Feature Driven Development (FDD)• Lean Software Development (LSD)• Adaptive Software Development (ASD)• Agile Unified Process (AUP) • Crystal.

Page 14: Estructura

METODOLOGÍA SWAPYME

Page 15: Estructura

Metodología SWAPyME

• Definición• Enfoque • Principios• Roles• Prácticas • Herramientas

Page 16: Estructura

Metodología SWAPyME

• Framework de gestión de proyectos liviano que tiene como principal objetivo la distribución de software de alta calidad con rapidez y continuidad, en torno a las necesidades del valor de negocio, la participación activa de los usuarios y la adaptación continua, contribuyendo con el aumento de la productividad en la gestión

Page 17: Estructura

Definición

• Framework de gestión de proyectos liviano que tiene como principal objetivo la distribución de software de alta calidad con rapidez y continuidad, en torno a las necesidades del valor de negocio, la participación activa de los usuarios y la adaptación continua, contribuyendo con el aumento de la productividad.

Page 18: Estructura

Enfoque

• Es una metodología iterativa:– Flexibilidad que permite ante los cambios –Genera más valor para el usuario–Contribuye con la corrección temprana de

errores– Es posible tener más control sobre ciertas

características del proyecto disminuyendo riesgos.

Page 19: Estructura

Roles

• Colección de funciones que cumple uno o varios grupos de personas, con el fin de cumplir con actividades que se definen para éste y entregar los artefactos que deben ser elaborados.

Page 20: Estructura

Roles

• Gerente de proyecto: – Planificación del proyecto en la totalidad de su

duración– Asignación de los recursos – Delegación de responsabilidades– Organizar las reuniones– Mantener un control sobre el progreso del proyecto – Definir estrategias para mitigar los riesgos que se

puedan presentar.

Page 21: Estructura

Roles

• Líder de proyecto– Supervisión de la implementación proceso y todas

las actividades que permitan el mejoramiento del mismo.

– Arquitecto del sistema– Mantiene el control y cambios requeridos de la

arquitectura en cada una de las iteraciones.

Page 22: Estructura

Roles

• Grupo de desarrollo: – Codificación de los componentes del desarrollo de

cada iteración– Ejecución de pruebas unitarias– Documentación – Mantener la actualización del código

Page 23: Estructura

Roles

• Grupo de pruebas: – Crear los escenarios de pruebas funcionales– Certificar cada release que vaya a ser entregado al

cliente en cada iteración.

Page 24: Estructura

Roles

• Usuario (stakeholder): – Poseen conocimiento del dominio del sistema en

desarrollo– Aceptarán o rechazarán el sistema de acuerdo a

los requerimientos establecidos en la iteración – Interactúan con los miembros del equipo de

desarrollo para algún propósito del proyecto.

Page 25: Estructura

Principios

• La participación activa del usuario.• Las entregas iterativas e incrementales.• Los requerimientos son tomados como línea base.• Centrarse en actividades de alto valor.• Comunicación y retroalimentación constante.• Gestión del cambio.• Mantener independencia de herramientas y

lenguajes de programación.• Adopción de agilidad en el equipo de trabajo.

Page 26: Estructura

Prácticas

Page 27: Estructura

Prácticas para la gestión del proyecto

• PlanificaciónPara el inicio del proyecto, en la primera iteración que se vaya a realizar, se debe haber elaborado antes un análisis de factibilidad del proyecto donde se determine el alcance y validación tecnológica, operativa y económica del proyecto.

Page 28: Estructura

Prácticas para la gestión del proyecto

Después de la primera iteración, las planificaciones dan inicio al ciclo de cada iteración, llevando a cabo las siguientes tareas:

– Determinar las historias de usuario que van a ser

construidas en la iteración.– Estimar el tiempo que se tomará para la construcción

de las historias de usuario elegidas.– Los integrantes del grupo de desarrollo eligen qué

historias de usuario construirán.

Page 29: Estructura

Prácticas para la gestión del proyecto

• Ambiente colaborativoSe entiende como un espacio virtual donde todas las partes interesadas en el proyecto, incluso si están en diferente tiempo o lugar, pueden negociar, hacer una lluvia de ideas, debatir, compartir conocimientos y en general trabajar en conjunto para llevar a cabo algunas tareas, que permitan realizar seguimiento y mantener el control de los principales componentes del proyecto.

Page 30: Estructura

Prácticas para la gestión del proyecto

• Entregas iterativas e incrementales Consiste en la entrega de funcionalidades principales del sistema máximo cada dos semanas al cliente, lo cual permitirá la retroalimentación inmediata por su parte y aumentará la productividad del proyecto.

Page 31: Estructura

Prácticas para la gestión del proyecto

• Seguimiento y controlPara entregar un proyecto consistente se debe llevar una trazabilidad de los principales aspectos, desde el inicio del proyecto hasta el fin. Dado que el aspecto principal de esta metodología son los requerimientos y el enfoque iterativo, se llevará a cabo la trazabilidad de las historias de usuario por cada iteración y su relación con otras historias de usuario.

Page 32: Estructura

Prácticas para cada iteración

• Definición de requerimientosEn esta actividad de definición de las necesidades del sistema que guiará el desarrollo, se utilizan las historias de usuario para detallar, en un lenguaje cercano al cliente, la funcionalidad que debe satisfacer cada iteración, de forma tal que se logre trazabilidad con el alcance general del proyecto.

Page 33: Estructura

Prácticas para cada iteración

• Diseño del sistemaEl diseño del sistema no será definido inicialmente, por el contrario, para cada iteración se tendrá en cuenta la arquitectura del proyecto y se diseña según el alcance definido en la iteración, en contraste con nuevos requerimientos definidos por el cliente.

Page 34: Estructura

Prácticas para cada iteración

• RefactorizaciónSe refiere a la actividad constante en los desarrollos ágiles, donde, el objetivo es mejorar el diseño y la productividad del proyecto en desarrollo, sin influir en su funcionalidad.

Page 35: Estructura

Prácticas para cada iteración

• Integración continuaSe debe integrar cada cambio introducido al proyecto. Se parte de la base que cuanto más tiempo se espere para integrar más costosa e impredecible será la actividad de integración. Se debe disponer de herramientas que permitan su automatización.

Page 36: Estructura

Prácticas para cada iteración

• Desarrollo basado en pruebasPor medio de esta práctica se implementan las pruebas incluso antes de comenzar a escribir el código de un módulo. De esta forma, ante cada modificación en las iteraciones del proyecto el plan de pruebas es ejecutado completamente.– Pruebas de aceptación del cliente– Pruebas unitarias– Pruebas funcionales