gerencia Ágil de proyectos de software con base en...
TRANSCRIPT
Gerencia Ágil de proyectos de software con base en ambientes
colaborativoscolaborativos
María Consuelo [email protected]
Universidad Javeriana2011
pg.1
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.
pg.2
la previsión y en la gestión.
¿Cómo automatizar entonces los procesos del desarroll o de proyectos de software siguiendo metodologías ági les?
Esta conferencia trata de resolver este interrogante mediante un uso adecuado de ambientes colaborativos de desarrolloque convierta en acción efectiva los principios y prácticas las metodologías ágiles.
La realidad de los proyectos de software : de software :
no se logra disminuir su complejidad ni
dominar su gestión
pg.3
25 años de evolución de la arquitectura (hacia una mayor complejidad)
Batch programs
Monolitic systems
pg.4
Interactive systems 1982 => ...
Client / Server systems 1995 => ...
Web multi-tier systems 2000 => ...
Service Oriented Architecture 2004 => ...
Fully integrated & flexible systems 2007=>..
Hoy: Arquitectura empresarial Arquitectura empresarial Orientada a
Servicios
pg.5
Desarrollar software es cada vez MÁS DIFICIL
Proceso de Desarrollo
Buenas prácticas
Framework Global
pg.6
Programación en algún lenguaje(Java, C#, ...)
Principios, modelos, metodologías, ...
Buenas prácticas
Arq
uite
ctur
aTe
cnol
ógic
a(J
ava
EE
, .N
ET,
...)
Her
ram
ient
as
Libr
ería
s es
tánd
ar
Otr
as te
cnol
ogía
s
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 conjunto de
+–
pg.7
Actividades Entregables(documentos,
código, manuales,...)
Herramientas
asignación de Responsabilidades y
Roles
dinámica de Interacción entre los miembros del grupo
un mecanismo de planeación, control y
seguimiento
+
++
Madurez de un Proceso de Desarrollo
• Un Proceso Desarrollo de Software es MADURO
(según CMMI) en la medida que :– Está documentado– 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
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)• 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
pg.9
Fuentes: 1- Standish Group International Inc. Welcome to the Standish Group International. http://www.standishgroup.com
2- ACIS: Encuesta de Gerencia de Proyectos en TI, 2005
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 • 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
pg.10
Fuente: Booch, G., & Brown, A. W “Collaborative Development Environments”, Cupertino, CA, USA. 2002
Metodologías Agiles:
primera parte de la solución para lograr un desarrollo
efectivo y ágil de los proyectos de software
pg.11
¿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 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
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)
� Propiedad corporativa del código (collective ownership)
� Pruebas automáticas permanentes (test driven
development)
� Integración permanente
pg.13
design)
� Metáfora (lenguaje común)
(metaphore)
� Estandarización del código (coding standard)
� Programación por pares (pair programming)
� Integración permanente (continuous integration)
� El cliente al lado (Onsite customer
=> customer tests)
� “Refactoring” frecuente (frequent
refactoring)
� 40 horas de trabajo (sustainable
pace)
Las prácticas XP pretenden resolver los problemas del desarrollo de proyectos de software
Entregas frecuentes
Planear el desarrollo a “corto” plazo
Propiedad corporativadel código
Refactoring
Metáfora
Expectativas no realistas
Requerimientos incompletos
Cronogramas irreales Cambios frecuentes
en Requerimientos
pg.14pg. 14
Entregas frecuentes y pequeñas
Diseños simples
Integración permanente
Estandarización del código
Programación por pares
del código
Pruebas automáticas permanentes
El cliente al lado
40 horas de trabajo
Metáfora
Escasa participación de los usuarios
Defectuosa comunicación
Control deficiente a los cambios
Problemas en la calidad y mantenibilidad del código
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– 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
• 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– dispersión de los documentos intercambiados
• la comunicación entre el gerente y los
desarrolladores es informal
– típicamente hay intercambio verbal o de emails
– 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
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 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
pg.17
Fuente: Leigh Williamson, “The Rational approach to automation”, IBM, 2009
Ambientes colaborativos para el desarrollo de proyectos de
software: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
Qué es un ambiente colaborativo para el desarrollo de proyectos de software ?
Servidor deBase de Datos
Servidorde Aplicaciones
Repositorio deVersionesTopic Replies Author
Forums
WikisDocs
Releases
Trackers
Ambiente colaborativo
pg.19Espacio 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)
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 – 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
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 • 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, http://pegasus.javeriana.edu.co/~CIS0910IS05/ pg.21
(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
de un caso de uso), guías y estándares
• Wikis: edición compartida de nuevas guías para un proyecto
• Noticias y avisos del gerente:
pg.23
• Lista de versiones liberadas del software de un proyecto– software y manuales listos para ser descargados por el cliente
pg.24
• 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 sistemasistema
– etc.
pg.25
(2) Facilidades ofrecidas por un ambiente colaborativo para la
Gestión diaria de un proyecto
• Acople del ambiente colaborativo con el • 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
• 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 trackers definidos de forma flexible (por ej: tracker de requerimientos, tracker 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
• Ilustración de trackers e items en GForge:– lista de trackers de un proyecto:
pg.28
– Lista de los items de un tracker (ej: tracker de desarrollo)
pg.29
Contenido(1) de un item
de un tracker(ej: un CU)
Estimación de •fecha inicio•fecha final (alimenta el Gantt)
Producto(release) asociado
Participantes asignados
pg.30
estadoactual(campo Status)
archivos anexos
Contenido(2) de un item de un tracker
historial cambios
historialcommits
pg.3131
dependencias(alimenta el Gantt)
registro tiempo
trabajado
• 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
- Ilustración de la definición del workflow de un tracker en GForge:el workflow definirá transiciones de estado de cualquier item, modelando el campo “Status”
pg.33posteriormente se definirá el workflow como transiciones de Status
permite definir los valores del campo Status
campos del tracker
- definición de los posibles estados de un item (valores posibles del campo Status)
pg.34
transiciones de estado
- definición del workflow: transiciones de estado, roles asociados y notificaciones automáticas
pg.35
pg. 35
la notificación llega a los participantes del rol indicado que hayan sido asignados a un item
• Seguridad: un ambiente colaborativo debe permitir
– definir los roles de participantes para un proyecto específico
–específico
– los derechos asociados a cada rol
– inscribir cada participante en uno o varios roles
pg.36
- Definición de Roles para un proyecto
pg.37
pg. 37
A cada rol se le asignan permisos sobre trackers y demás elementos del ambiente
- Inscripción en roles de los participantes del proyecto
pg.38
- Autocontrol : cada participante debe poder ver las actividades pendientes en que está involucrado
pg.39
(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
- Reportes de estimación de tiempos y recursos del proyecto:
diagrama Gantt correspondiente a las actividades planeadas
pg.41generado a partir de fecha inicio y final de cada item y de precedencia entre items
- Reportes de ejecución del proyecto: tiempos y recursos realmente
utilizados
a. Reporte de tiempo invertido en las actividades de los trackers
pg.42
b. Reporte de estado de avance de los productos del proyecto
pg.43
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: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
• Estados del workflow de un caso de uso desarrollado en una rama
pg.45
• 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
Guías metodológicas para usar adecuadamente un Ambiente colaborativo para el desarrollo
de proyectos de software:de proyectos de software:
Ejemplo: Guía ConstruColectiva
pg.47
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, http://pegasus.javeriana.edu.co/~CIS0910IS05/
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 – 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
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
Procesos e iteraciones consideradas por ConstruColectiva
Cada iteración consiste en un conjunto de casos de uso desarrollados, probados, integrados y entregados al cliente
pg.50
=> procesos que participan en una iteración:
� Desarrollo� Pruebas y proceso
de integración� Entrega al cliente
y pruebas por parte del cliente
� Bugs
Ejemplo del workflow propuesto para un proceso
Workflow para el proceso de Desarrollo
pg.51
• 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
Formatos de documentos
PROCESO DOCUMENTODiagrama de casos de uso
Proceso 1: Análisis de Requerimientosy casos de uso Requerimientos y especificación inicial de casos de usos
Contrato segunda fase del proyectoProceso 2: Planeación del desarrollo delproyecto Software Project Management Plans – SPMP
Proceso 3: Arquitectura y diseño Software Architecture Description – SAD
Especificación de un caso de uso
Entrega para pruebas
Plan de pruebas funcionalesProceso 4: Desarrollodocumentos
propuestos
pg.52
Plan de pruebas funcionalesProceso 4: Desarrollo
Reporte de defectos e incidentes en las pruebas funcionales
Proceso 5: Pruebas y proceso deintegración Plan de pruebas de integración
Proceso 6: Entrega al cliente y pruebaspor parte del cliente
Requerimientos asociados a los casos de uso entregadosReporte de defectos detectados por el cliente
Proceso 7: Bugs Descripción del bug
Proceso 8: Extensiones Descripción de la extensión
Plan de capacitación
Manual de instalación
Manual técnicoProceso 9: Puesta en operación
Manual de usuario
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• 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
ConclusionesConclusiones
pg.54
• 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 clientey 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
• 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 – 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
• Metodologías ágiles:
– http://www.extremeprogramming.org
– http://www.xprogramming.com
– Craig Larman, "Agile and Iterative Development: A Manager's Guide".
Addison Wesley, 2004.
Referencias
Addison Wesley, 2004.
• Ambientes colaborativos para el desarrollo de proyectos de
software:
– Booch, G., & Brown, A. W “Collaborative Development Environments”,
Cupertino, CA, USA. 2002
– Leigh Williamson, “The Rational approach to automation”, IBM, 2009
– htpp://www.gforge.com : “GForge AS User Manual”, version 5.4, GForge
Group, L.L.C., 2005-2007pg.57
• 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, Olaya. Memoria del trabajo de grado en Ingeniería de Sistemas,
Universidad Javeriana, 2010.
– Productos disponibles de ConstruColectiva: leer instrucciones en
http://orion.javeriana.edu.co:81/gf/
pg.58