Tema 5. Gestión de Proyectos (ISG3)

Transcripción

1 Tema 5. Gestión de Proyectos (ISG3) Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual España 1

2 Planificación 1ª Clase: Presentación y Conceptos Generales 2ª Clase: Concreción en Entorno de Trabajo 3ª Clase: Revisión de Avance y Dudas 4ª Clase: Defensa y Evaluación Metodológica 2

3 Repaso 3

4 Analista Stakeholder Probador Desarrollador penup Jefe de Proyecto Arquitecto 4

5 Colaboración y Objetivos (Niveles) 5

6 Fases 6

7 Fases Comienzo Visión + Características Plan Inicial Elaboración Arquitectura y (Análisis + Diseño + Código) Construcción Diseño + Código Finaliza en primera Beta Transición Betas Sucesivas 7

8 Formas de los Requisitos La Visión define el punto de vista del stakeholder sobre el producto Los Casos de Uso definen escenarios de usuario Cualquier requisitos basado en escenarios lo haría Los Requisitos de Soporte cubren aspectos técnicos y otros no referentes al uso del producto Los Work Items (elementos de trabajo) referencian requisitos del producto con más detalle 8

9 Definición Iterativa de Requisitos La Visión define el producto La identificación de los Casos de Uso define el alcance de una release (versión, liberación) Los detalles de los casos de uso conducen el trabajo dentro de una iteración Los Requisitos de Soporte se gestionan a lo largo de todo el ciclo de vida 9

10 Objetivo: Casos de Pruebas Casos de Pruebas Están alineados con requisitos y errores Especifican las condiciones que deben validarse Esbozan los datos necesarios Por su parte los Script de Pruebas (de los subprocesos de la Solución) Están alineados con los Casos de Pruebas Son instucciones detalladas paso a paso Coomplementados por datos de pruebas Es mejor que estén automatizados Los Casos de Pruebas son una forma de Test First Design (TFD) (Diseño guiado por las pruebas) 10

11 Roles Orientados al Objetivo Analista Captura, organiza y prioriza requisitos Stakeholder Conduce el objetivo; el proyecto debe satisfacer sus necesidades Probador Define los criterios para aceptar una solución EL Jefe de Proyecto actualizará la Lista de Work Items con elementos (items) agrupados y priorizados El Arquitecto y el Desarrollador producirán una solución que cumpla con el objetivo 11

12 Hitos de Gestión Terminación Planificada 1 Comienzo 2 Elaboración Construcción Comprendemos Comprendemos el problema? la solución? Características completadas? Transición Listo para Liberar? Betas Espacio de Satisfacción del Stakeholder 12

13 Priorizar y Gestionar el Trabajo Alta Prioridad Los work items de alta prioridad deberían estar bien definidos Los work items de baja prioridad pueden ser vagos En cada iteración se implementan los work items de mayor prioridad Se pueden añadir nuevos work items en cualquier momento Los work items se pueden repriorizar en cualquier momento Se pueden eliminar work items en cualquier momento Baja Prioridad Lista de Work Items 13

14 Conceptos Clave: Estimación Ágil Tamaño (puntos): Para cada work item, esimamos lo grande que es. Nos enfocamos en su tamaño relativo, así que es clave ser consistentes dentro de nuestra lista de work items. Velocidad Una medida de cuantos puntos se liberan (entregan) en cada iteración Esfuerzo (días o horas): Estimación del esfuerzo real. 14

15 Planifica Tu Iteración Especifica la velocidad objetivo (deseada) y esboza los objetivos de la iteración en el Plan de Iteración Analiza el Work Item de mayor prioridad Estima el esfuerzo en horas Si es demasiado grande para caber en la iteración, divídelo en work items menores Añádelo al Plan de Iteración Analiza el siguiente work item por orden de prioridad hasta que el Plan de Iteración esta lleno Especifica las pruebas y otros criterios de evaluación (assessment) Estimar y añadir al plan de iteración Objetivos de la Iteración Lista de Work Items de la Iteración Resultados de Medidas y Pruebas Plan de Iteración Lista de Work Items 15

16 Representación de la Arquitectura No se requieren documentos pesados Gran parte de la arquitectura se puede: Seleccionar en vez de diseñar Referenciar en vez de describir Vamos a usar el Patrón Cadena de Responsabilidad para tal cosa Hemos seleccionado Oracle porque cumple los requisitos de prestaciones y el cliente ya tiene licencia y administradores cualificados Vamos a aplicar la siguiente arquitectura de red. Estamos aplicando estos esquemas J2EE Distribuiremos los componentes entre las capas de la siguiente manera 16

17 Diseño Pasos Comprender los requisitos, identificar un escenario Identificar sus elementos Determinar como colaboran esos elementos Refinar las decisiones, los aspectos internos del diseño Comunicarlo Aprueba un análisis? Si es apropiado. Diseño visual? Si es apropiado. Usar una herramienta de diseño? Si es apropiado. Diseño de larga duración? Si es apropiado. 17

18 Desarrollo Guiado por Work Items Seleccionar uno de los work item de los asignados a la actual iteración Colaborar con el equipo si es necesario descomponerlo en otros menores Identificar el contexto de requisitos Adjuntos: Casos de uso, requisitos de soporte, información de bugs errores, casos de prueba Recolectar cualquier información adicional Repetir hasta completar: Construir una pequeña solución que se verifique con pruebas de desarrollo (developer tests) Comprobar que se ha completado utilizando las puebas detema sistema 5. Gestión de Proyectos (ISG3) 18

19 Diseño basado en pruebas Diseñar la solución Definición de la interfaz a probar Crear pruebas para la solución Las pruebas deben ejecutarse y fallar Implementar la solución Las pruebas deben ejecutarse y pasarse ok Trabajar en incrementos tan pequeños como sea posible 19

20 Roles Relevantes a la Solución Desarrollador Diseña e implementa la solución Arquitecto Toma las decisiones técnicas claves y estructura la solución Probador Implementa y conduce las pruebas que verifican la solución EL Jefe de Proyecto monitoriza el desarrollo El Stakeholder participa en la verificación de la solución El Analista suministra información adicional 20

21 Entorno de Trabajo Google Code 21

22 Project Hosting 22

23 Create Project 23

24 Project Home 24

25 Downloads 25

26 Wiki 26

27 Wiki New Page 27

28 Issues (work-item-list) 28

29 Issues New 29

30 Issues New Type 30

31 Issues New Status 31

32 Issues New Priority 32

33 Issues y la Work Item List Alta Prioridad Accepted Started Fixed - Verified Los work items de alta prioridad deberían estar bien definidos New Priority-Critical, High, Medium, Low Los work items de baja prioridad pueden ser vagos WontFix, Invalid, Duplicated Baja Prioridad Lista de Work Items 33

34 Source 34

35 Source 35

36 Control de versiones (Subversion) Jerarquía trunk tags branches Estructura de proyecto (nombre/trunk) src doc 36

37 Ciclo de control de versiones carga inicial svn checkout URL proyecto actualización svn update svn commit creación de tags svn copy URL-trunk URL-tags/nombretag 37

38 Admin. Proyecto 38

39 Miembros y Propietarios 39

40 Etiquetas Entregables 40

41 Disciplinas 41

42 Etiquetas 42

43 43

44 44

45 Ciclos Guiados por Work Items Fases Hitos - Entregables Requisitos Prioridad Casos de Uso y Tests Codificación Arquitectura, Interfaz, Pruebas, Código, Tests Downloads por hito de fase 45

46 Recomendaciones Etiquetas us.es-isg de la práctica Milestones (en hitos y tags): Milestone-Comienzo Milestone-Elaboracion-it0.. Milestone-Elaboracion-itN... Disciplinas Asignación de propiedad a la LSI Pasar todo a work items 46

47 Referencias Manifesto for Agile Software Development. The Agile Alliance. Agile Modeling / EUP Open UP ReadySet: Free Software Foundation Open Source Initiative Agile Testing. Google Code Project Hosting FAQ, 47

48 Gracias!.. Preguntas? 48