Gerencia Ágil de proyectos de software con base en ambientes

Transcripción

1 Gerencia Ágil de proyectos de software con base en ambientes colaborativos María Consuelo Franky Universidad Javeriana 2011 pg.1

2 Temática Hemos oído de metodologías ágiles durante varios años pero los proyectos de software siguen teniendo retrasos y fallas en la previsión y en la gestión. Cómo automatizar entonces los procesos del desarrollo de proyectos de software siguiendo metodologías ágiles? Esta conferencia trata de resolver este interrogante mediante un uso adecuado de ambientes colaborativos de desarrollo que convierta en acción efectiva los principios y prácticas las metodologías ágiles. pg.2

3 La realidad de los proyectos de software : no se logra disminuir su complejidad ni dominar su gestión pg.3

4 25 años de evolución de la arquitectura (hacia una mayor complejidad) Batch programs Monolitic systems Interactive systems 1982 =>... Client / Server systems 1995 =>... Web multi-tier systems 2000 =>... Service Oriented Architecture 2004 =>... Fully integrated & flexible systems 2007=>.. pg.4

5 Hoy: Arquitectura empresarial Orientada a Servicios pg.5

6 Desarrollar software es cada vez MÁS DIFICIL Proceso de Desarrollo Framework Global Buenas prácticas Librerías estándar Arquitectura Tecnológica (Java EE,.NET,...) Herramientas Otras tecnologías Programación en algún lenguaje (Java, C#,...) Principios, modelos, metodologías,... pg.6

7 Proceso de desarrollo de Software Es la forma como se organiza un grupo de personas para hacer un proyecto: secuencia + de Actividades conjunto de Entregables (documentos, código, manuales,...) + conjunto de Herramientas + asignación de Responsabilidades y Roles un mecanismo de planeación, control y seguimiento + dinámica de Interacción entre los miembros del grupo + pg.7

8 Madurez de un Proceso de Desarrollo Un Proceso Desarrollo de Software es MADURO (según CMMI) en la medida que : Está documentado Es usado por TODOS los miembros del grupo Cubre todas las etapas: Análisis/Diseño/Programación/Pruebas/Mantenimiento Es efectivo Es eficiente Es repetible, medible, optimizable,... pg.8

9 Problemas frecuentes de la gestión de los proyectos de software Objetivos poco claros Expectativas NO realistas Requerimientos y especificaciones incompletas (=> sobrecostos) Cronogramas irreales (=> atrasos) Falta de soporte ejecutivo Escasa participación de los usuarios Defectuosa comunicación. Cambios frecuentes en los requerimientos y especificaciones Control deficiente a los cambios Problemas para asegurar la calidad y mantenibilidad del código Fuentes: 1- Standish Group International Inc. Welcome to the Standish Group International ACIS: Encuesta de Gerencia de Proyectos en TI, 2005 pg.9

10 Problemas relativos a la automatización de los proyectos de software Procesos sin automatizar en la gestión de proyectos de software Desconocimiento de las herramientas y ambientes que apoyan el desarrollo colaborativo Multiplicidad y dispersión de las herramientas con las que se trabaja La dispersión geográfica de los participantes dificulta la automatización Fuente: Booch, G., & Brown, A. W Collaborative Development Environments, Cupertino, CA, USA pg.10

11 Metodologías Agiles: primera parte de la solución para lograr un desarrollo efectivo y ágil de los proyectos de software pg.11

12 Qué es Extreme Programming (XP)? XP es una disciplina de desarrollo ágil de software basada en los valores de simplicidad, comunicación, realimentación y coraje, que organiza al grupo de desarrollo en torno a 12 prácticas concretas, las cuales permiten saber cómo va el proyecto afinar las prácticas a la situación particular. pg.12

13 Las 12 prácticas de XP Planear el desarrollo a corto plazo (planning game) Entregas frecuentes y pequeñas (small releases) Diseños simples (simple design) Metáfora (lenguaje común) (metaphore) Estandarización del código (coding standard) Programación por pares (pair programming) Propiedad corporativa del código (collective ownership) Pruebas automáticas permanentes (test driven development) Integración permanente (continuous integration) El cliente al lado (Onsite customer => customer tests) Refactoring frecuente (frequent refactoring) 40 horas de trabajo (sustainable pace) pg.13

14 Las prácticas XP pretenden resolver los problemas del desarrollo de proyectos de software Expectativas no realistas Requerimientos incompletos Cronogramas irreales Cambios frecuentes en Requerimientos Planear el desarrollo a corto plazo Refactoring Escasa participación de los usuarios Defectuosa comunicación Metáfora El cliente al lado Entregas frecuentes y pequeñas Pruebas automáticas permanentes Integración permanente Programación por pares Propiedad corporativa del código Estandarización del código 40 horas de trabajo Diseños simples Control deficiente a los cambios Problemas en la calidad y mantenibilidad del pg.14 código pg. 14

15 Problemas para automatizar los proyectos de software siguiendo las prácticas XP Multiplicidad y dispersión de las herramientas y documentos con las que se trabaja: repositorio de versiones del software plantillas y formatos para las diferentes etapas del proceso de desarrollo: especificación de requerimientos descripción de la arquitectura del sistema diseño de cada caso de uso libreto de pruebas para cada caso de uso especificación de un defecto reportado por el cliente etc. generadores de código herramientas para pruebas (testing) pg.15

16 El cronograma no sirve como herramienta de control: es un documento que rápidamente se vuelve obsoleto la comunicación entre el cliente y el grupo de desarrollo es informal dispersión de los documentos intercambiados la comunicación entre el gerente y los desarrolladores es informal típicamente hay intercambio verbal o de s el aviso de cuál es la siguiente actividad para un integrante depende de una gestión manual el control de si las actividades están a tiempo depende de la supervisión manual del gerente pg.16

17 El desarrollo de los proyectos de software se encuentra en plena revolución industrial Hace una década el software era totalmente artesanal: cada porción de software era escrito totalmente a mano (igual que una novela) como una pieza única para una situación específica Hoy se empiezan a aplicar métodos repetibles para producir software explotando la colaboración del equipo que participa en un proyecto automatizando las actividades mediciones y análisis permanentes Fuente: Leigh Williamson, The Rational approach to automation, IBM, 2009 pg.17

18 Ambientes colaborativos para el desarrollo de proyectos de software: segunda parte de la solución para lograr un desarrollo ágil de los proyectos de software con automatización que apoya la gestión pg.18

19 Qué es un ambiente colaborativo para el desarrollo de proyectos de software? Forums Topic Replies Author Ambiente colaborativo Repositorio de Versiones Trackers Servidor de Base de Datos Servidor de Aplicaciones Wikis Docs Releases pg.19 Espacio web común para la comunicación, el seguimiento y control de las actividades de los proyectos de software (los participantes pueden estar dispersos geográficamente)

20 Tres tipos de facilidades que ofrecen estos ambientes colaborativos Facilidades para la comunicación entre desarrolladores y clientes el poder contactar y compartir de manera ágil eleva la velocidad de la producción global Facilidades para apoyar la gestión diaria de un proyecto automatizando el seguimiento de las actividades para elevar el cumplimiento y la calidad de la producción Facilidades para apoyar el control y proyección de un proyecto mediante reportes permanentes de mediciones sobre el progreso de un proyecto, que permiten al gerente corregir la gestión global pg.20

21 Ejemplos de ambientes colaborativos para el desarrollo de proyectos de software Asynchrony, Freepository, GBorg, GForge, Savannah, SEUL, SourceForge, IBM (Jazz, Rational),... Distintas características respecto a popularidad: número de miembros y proyectos alojados costos y tipo de licencia cuando se usa dentro de una empresa seguridad (roles y registro de participantes de cada rol) facilidades (adicionales al repositorio de versiones, forums y trackers) Ver estudio comparativo en: John Diaz, Juan Felipe Olaya, ConstruColectiva: Guía metodológica para la gestión de proyectos de software basados en metodologías ágiles, utilizando ambientes de desarrollo colaborativo. Caso de estudio: Gforge, tesis de pregrado U. Javeriana, pg.21

22 (1) Facilidades ofrecidas por un ambiente colaborativo para la comunicación entre desarrolladores y clientes (ilustración con Gforge) Documentos de un proyecto de interés para el cliente: descripción de requerimientos, inventario de casos de uso, contrato, etc. de interés para los desarrolladores: formatos para las distintas etapas del proyecto (ej: formato de especificación de un caso de uso), guías y estándares pg.22

23 Wikis: edición compartida de nuevas guías para un proyecto Noticias y avisos del gerente: pg.23

24 Lista de versiones liberadas del software de un proyecto software y manuales listos para ser descargados por el cliente pg.24

25 Forums de distintos tipos (relativos a un proyecto) para la solución de problemas entre desarrolladores para que el cliente reporte anomalías encontradas en el software liberado para que el cliente solicite cambios o nuevas opciones para el sistema etc. pg.25

26 (2) Facilidades ofrecidas por un ambiente colaborativo para la Gestión diaria de un proyecto Acople del ambiente colaborativo con el repositorio de versiones de un proyecto (por ej. CVS o SubVervion) permite : configurar permisos sobre el repositorio para cada participante en el proyecto obtener el historial de versiones del proyecto obtener el historial del trabajo de cada participante en términos de commits sobre el repositorio pg.26

27 Manejo de trackers e Items: las actividades de un proyecto se deben registrar en el ambiente para poder controlar su desarrollo las actividades similares se agrupan por trackersdefinidos de forma flexible (por ej: tracker de requerimientos, tracker de casos de uso,etc.) en cada tracker se registran uno o varios items, cada uno con la información referente a una actividad cada item asociado a una actividad permitirá saber en qué estado se encuentra su desarrollo quiénes participan en la actvidad tiempos planeados y tiempos reales invertidos en la actividad commits sobre el repositorio de versiones asociados con la actividad pg.27

28 Ilustración de trackers e items en GForge: lista de trackers de un proyecto: pg.28

29 Lista de los items de un tracker (ej: tracker de desarrollo) pg.29

30 Contenido(1) de un item de un tracker (ej: un CU) Estimación de fecha inicio fecha final (alimenta el Gantt) Participantes asignados Producto (release) asociado estado actual (campo Status) pg.30

31 Contenido(2) de un item de un tracker archivos anexos historial cambios historial commits dependencias (alimenta el Gantt) registro tiempo trabajado 31 pg.31

32 Automatización del flujo de trabajo de cada actividad del proyecto: mediante la definición del workflow de cada tracker se definen los estados por lo cuales pasa el desarrollo de cada item de un tracker se indica el rol de participantes que trabaja en cada estado de un item se configura la notificación automática que se enviará a los participantes involucrados cuando el item progresa a un nuevo estado pg.32

33 - Ilustración de la definición del workflowde un tracker en GForge:el workflow definirá transiciones de estado de cualquier item, modelando el campo Status campos del tracker posteriormente se definirá el workflow como transiciones de Status permite definir los valores del campo Status pg.33

34 - definición de los posibles estados de un item (valores posibles del campo Status) transiciones de estado pg.34

35 - definición del workflow: transiciones de estado, roles asociados y notificaciones automáticas la notificación llega a los participantes del rol indicado que hayan sido asignados a un item pg.35 pg. 35

36 Seguridad: un ambiente colaborativo debe permitir definir los roles de participantes para un proyecto específico los derechos asociados a cada rol inscribir cada participante en uno o varios roles pg.36

37 - Definición de Roles para un proyecto A cada rol se le asignan permisos sobre trackers y demás elementos del ambiente pg.37 pg. 37

38 - Inscripción en roles de los participantes del proyecto pg.38

39 - Autocontrol : cada participante debe poder ver las actividades pendientes en que está involucrado pg.39

40 (3) Facilidades ofrecidas por un ambiente colaborativo para apoyar el control y proyección de un proyecto Mediante reportes permanentes que permiten hacer medición y análisis, el gerente puede conocer el estado global del proyecto, proyectar y corregir la gestión pg.40

41 - Reportes de estimación de tiempos y recursos del proyecto: diagrama Gantt correspondiente a las actividades planeadas generado a partir de fecha inicio y final de cada item y de precedencia entre items pg.41

42 - Reportes de ejecución del proyecto: tiempos y recursos realmente utilizados a. Reporte de tiempo invertido en las actividades de los trackers pg.42

43 b. Reporte de estado de avance de los productos del proyecto pg.43

44 Prácticas que enfatizan la automatización del desarrollo de proyectos de software Disciplina de desarrollar cada caso de uso en una rama indepediente del repositorio de versiones: los participantes a cargo del CU se aislan para no afectar a los demás permite el desarrollo en paralelo de múltiples CU el tronco se mantiene siempre estable listo para hacer la siguiente entrega al cliente cada rama es responsable de actualizarse respecto al tronco antes de integrarse al mismo tronco pg.44

45 Estados del workflow de un caso de uso desarrollado en una rama pg.45

46 Utilización de un framework de generación: Múltiples generadores que aceleran la producción de software aseguran un código estándar de los proyectos de una empresa particular incorporan patrones de software incorporan las buenas prácticas de la empresa reducen el tiempo de entrenamiento de nuevos desarrolladores Generadores de: esqueleto inicial del sistema de software acoplamiento de un módulo de seguridad casos de uso CRUD esqueleto de un caso de uso de negocio pg.46

47 Guías metodológicas para usar adecuadamente un Ambiente colaborativo para el desarrollo de proyectos de software: Ejemplo: Guía ConstruColectiva Referencia: John Diaz, Juan Felipe Olaya, ConstruColectiva: Guía metodológica para la gestión de proyectos de software basados en metodologías ágiles, utilizando ambientes de desarrollo colaborativo. Caso de estudio: Gforge, tesis de pregrado U. Javeriana, pg.47

48 Necesidad de tales guías metodológicas Un ambiente colaborativo para el desarrollo de proyectos de software: ofrece muchas opciones y alternativas para manejar los proyectos de software no indica un orden para su uso adecuado en la gestión de un proyecto puede ser confuso para los participantes si no se conoce bien, el gerente termina utilizando solo las facilidades de comunicación pero no las que permiten automatizar y controlar la gestión pg.48

49 Elementos de la Guía ConstruColectiva Objetivo: orientar al gerente en la gestión de un proyecto bajo metodologías ágiles apoyándose en un ambiente colaborativo como GForge Indica para cada proceso del desarrollo del proyecto cómo representarlo a través de un tracker del ambiente con el workflow adecuado formatos propuestos para los documentos asociados (entregables) Ilustración con un proyecto demo Flexibilidad para cambiar la definición de trackers, su workflow y los formatos de documentos pg.49

50 Procesos e iteraciones consideradas por ConstruColectiva Cada iteración consiste en un conjunto de casos de uso desarrollados, probados, integrados y entregados al cliente => procesos que participan en una iteración: Desarrollo Pruebas y proceso de integración Entrega al cliente y pruebas por parte del cliente Bugs pg.50

51 Ejemplo del workflow propuesto para un proceso Workflow para el proceso de Desarrollo Cada item corresponde a la tarea de desarrollar un caso de uso y tiene los siguientes documentos asociados Especificación y diseño del caso de uso Entrega para pruebas Plan de pruebas funcionales Reporte de defectos e incidentes pg.51

52 Formatos de documentos propuestos PROCESO Proceso 1: Análisis de Requerimientos y casos de uso Proceso 2: Planeación del desarrollo del proyecto Proceso 3: Arquitectura y diseño Proceso 4: Desarrollo Proceso 5: Pruebas y proceso de integración Proceso 6: Entrega al cliente y pruebas por parte del cliente Proceso 7: Bugs Proceso 8: Extensiones Proceso 9: Puesta en operación DOCUMENTO Diagrama de casos de uso Requerimientos y especificación inicial de casos de usos Contrato segunda fase del proyecto Software Project Management Plans SPMP Software Architecture Description SAD Especificación de un caso de uso Entrega para pruebas Plan de pruebas funcionales Reporte de defectos e incidentes en las pruebas funcionales Plan de pruebas de integración Requerimientos asociados a los casos de uso entregados Reporte de defectos detectados por el cliente Descripción del bug Descripción de la extensión Plan de capacitación Manual de instalación Manual técnico Manual de usuario pg.52

53 Uso ágil de la guía ConstruColectiva Instalación del ambiente Gforge la guía provee un manual adecuado Restauración del backup del proyecto demo Creación de un nuevo proyecto a partir de la clonación del proyecto demo automatiza la configuración de trackers y workflow del nuevo proyecto! También pueden clonarse un tracker o item Disponibilidad de la guía y de todos sus subproductos (ver referencias) pg.53

54 Conclusiones pg.54

55 La revolución industrial del desarrollo de proyectos de software requiere metodologías ágiles y ambientes colaborativos las metodologías ágiles promueven calidad, comunicación y agilidad en la entrega del producto al cliente los ambientes colaborativos permiten explotar la colaboración del equipo que participa en un proyecto, automatizar las actividades y controlar la gestión mediante mediciones y análisis permanentes pg.55

56 Para llevar a cabo una gestión ágil de proyectos de software sobre un ambiente colaborativo es útil seguir una guía metodológica como ConstruColectiva: la guía ilustra cómo usar de forma ordenada las facilidades del ambiente aporta un proyecto demo totalmente configurado en términos de trackers y workflow para las distintas etapas del proyecto mediante clonación se obtiene de forma inmediata un nuevo proyecto configurado como el demo pero con posibilidad de adaptarlo a los estándares de la empresa pg.56

57 Metodologías ágiles: Referencias Craig Larman, "Agile and Iterative Development: A Manager's Guide". Addison Wesley, Ambientes colaborativos para el desarrollo de proyectos de software: Booch, G., & Brown, A. W Collaborative Development Environments, Cupertino, CA, USA Leigh Williamson, The Rational approach to automation, IBM, 2009 htpp:// : GForge AS User Manual, version 5.4, GForge Group, L.L.C., pg.57

58 Guía ConstruColectiva: "ConstruColectiva: Guía metodológica para la gestión de proyectos de software basados en metodologías ágiles, utilizando ambientes de desarrollo colaborativo. Caso de estudio: GForge". John Diaz, Juan Felipe Olaya. Memoria del trabajo de grado en Ingeniería de Sistemas, Universidad Javeriana, Productos disponibles de ConstruColectiva: leer instrucciones en pg.58