modelos de procesos de gestión y desarrollo de software
TRANSCRIPT
![Page 1: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/1.jpg)
Modelos de Procesos de Gestión y
Desarrollo de SoftwarePatricio Letelier [email protected]
agilismoatwork.blogspot.comwww.tuneupprocess.com
Departamento Sistemas Informáticos y Computación (DSIC)Universidad Politécnica de Valencia (UPV) - España
![Page 2: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/2.jpg)
2
Introducción al Proceso de Software Modelos de Proceso y Metodologías
Metodologías Tradicionales: Rational Unified Process (RUP) Métodos Ágiles
Gestión Ágil de Requisitos Mejora Continua del Proceso Conclusiones Un Plan de Implantación de Prácticas Ágiles
Contenidos
Scrum + KanbanTeamwork Herramientas para Gestión Ágil Planificación y el Product Backlog Seguimiento
Una ojeada al agilismo Extreme Programming Lean Development Kanban Scrum
![Page 3: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/3.jpg)
3
![Page 4: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/4.jpg)
Introducción al Proceso de Software
![Page 5: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/5.jpg)
5
Contexto
Plazo
Alcance
CostoCalidad
Productividad
![Page 6: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/6.jpg)
6
Ámbitos de mejora en Ingeniería de Software
Herramientas(IDEs, CASE, …)
Proceso(Metodologías)
Notación(Lenguajes)
![Page 7: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/7.jpg)
7
Calidad del Producto Software
ISO/IEC 9126
![Page 8: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/8.jpg)
8
¿Cuánto esfuerzo se ha invertido en un cambio? ¿Cómo se ha distribuido dicho esfuerzo en actividades o agentes? ¿Cuánto re-trabajo se ha producido? ¿Quién, cuándo y qué se decidió respecto de un cambio?¿Qué eventos han afectado nuestro trabajo?
FAQs ¿podemos responderlas ?¿cuánto nos cuesta?
¿En qué tareas estoy participando y en qué estado están? ¿Qué trabajo es el que debería hacer en este momento? ¿Tengo pendiente alguna interacción/comunicación con otros participantes? ¿Cumpliremos con los plazos de entrega? ¿Quién podría encargarse de una nueva tarea?
¿Cuál es el criterio para considerar terminada una actividad?¿Qué cambios se realizan en el producto, tienen dependencias?¿Se está implementando exactamente lo pedido por el cliente? ¿Cuál es la funcionalidad actual del producto y cómo ha evolucionado?
Mejorar e
l
proce
so es
renta
ble,
hazlo!!
![Page 9: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/9.jpg)
9
Modelos de referencia y estándaresCMMI, ISO 9000-3, SPICE, PMBOK
Metodologías TradicionalesRational Unified Process (RUP), Proceso UnificadoMétrica 3
Metodos ÁgilesSCRUMExtreme Programming (XP)…
Modelos y metodologías
![Page 10: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/10.jpg)
10
CMMI: Capability Madurity Model
![Page 11: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/11.jpg)
11
Tiempo de implantación de niveles CMMI
Jornadas Proceso Software
24-Noviembre-2010
Nivel 1 a 2 … 5 mesesNivel 2 a 3 … 19 mesesNivel 3 a 4 … 25 mesesNivel 3 a 5 … 23 meses
![Page 12: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/12.jpg)
12
Adaptar la metodología al contexto
No existe una metodología de software universal. Las características de cada producto/proyecto/equipo exigen que el proceso sea configurable y adaptable.
![Page 13: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/13.jpg)
13
Configuración de la metodología
Kanban
Scrum
XP
RUP
Ad-hoc Plan
DoCheck
Act
Otras metodologías
Ágiles
![Page 14: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/14.jpg)
14
“Just Enough Process”
… Ni muy poco
… Ni mucho
![Page 15: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/15.jpg)
Modelos de Proceso y Metodologías
![Page 16: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/16.jpg)
16
Definiendo “nuestro” modelo de proceso
P
R
D
C
T
D
tiempo
Planificación
Requisitos
Arquitectura & Diseño
Codificación (Programación)
Testing
Despliegue (Deployment)
![Page 17: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/17.jpg)
17
Proceso Secuencial
P R D C T D
tiempo
Mejor es solapar trabajo ¿no? …
![Page 18: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/18.jpg)
18
Proceso en Cascada (Waterfall)
P
R
D
C
T
D
tiempo
![Page 19: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/19.jpg)
19
Planificación y seguimiento usando Diagramas Gantt
Realismo (el cambio y el retrabajo existe!) Desarrollo incremental
+ “Divide y vencerás”
![Page 20: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/20.jpg)
20
Proceso Incremental
P R D
C1 T1
D
tiempo
C2
C3
T2
T3
T
P R
D1 C1 T1
D
tiempo
C2
C3
T2
T3
TD2
D3
¿No es mejor hacer todo incremental ? …
![Page 21: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/21.jpg)
21
… Proceso Incremental
P
R1 D1 C1 T1
D
tiempo
C2
C3
T2
T3
TD2
D3
R2
R3
Pero ¿cómo planificar sin antes saber lo que hay que hacer? …
![Page 22: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/22.jpg)
22
Proceso Incremental con fase de exploración
P
R1 D1 C1 T1
D
tiempo
C2
C3
T2
T3
TD2
D3
R2
R3
R
Validación frecuente → Desarrollo Iterativo …
![Page 23: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/23.jpg)
23
Proceso Iterativo e Incremental
P
R1D1
C1 T1
D
tiempo
R
Fin 1eraIteración
Fin 2daIteración
Fin 3raIteración(Entrega)
InicioConstrucción
D TC2 T2
TP TP
R2D2
C3 T3R3D3
C4 T4R4D4
C5 T5R5D5
C6 T6R6D6
R D C T = Unidad de Trabajo (Work Unit)
y con pruebas de regresión entre iteraciones? …
![Page 24: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/24.jpg)
24
P
R1 D1 C1 T1
D
tiempo
R
Fin 1eraIteración
Fin 2daIteración
Fin 3raIteración(Entrega)
InicioConstrucción
D
TR2 D2 C2 T2
R3 D3 C3 T3T
R4 D4 C4 T4
P
R5 D5 C5 T5
R6 D6 C6 T6
P
T
Pero ¿cómo reflejamos el re
-trabajo
que se producirá debido a la
resolución de defectos? …
![Page 25: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/25.jpg)
25
Modelos de Proceso y Metodologías
Aportan el carácter de disciplina a la Ingeniería de Software
Un modelo de proceso de software es una estrategia global respecto de cómo abordar un proyecto de desarrollo de software
Modelos de proceso de software:Codificar y corregir (code-and-fix)Desarrollo en cascadaDesarrollo evolutivoDesarrollo formal de sistemasDesarrollo basado en reutilizaciónDesarrollo incrementalDesarrollo en espiral
![Page 26: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/26.jpg)
26
¿Qué es una Metodología?
Una metodología define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo
![Page 27: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/27.jpg)
27
… Modelos de Proceso y Metodologías
Las metodologías se basan en alguna combinación de modelos de proceso.
Desde la perspectiva de las técnicas utilizadas para las actividades de análisis, diseño e implementación las metodologías pueden ser clasificadas como: Metodologías Estructuradas o Metodologías Orientadas a Objetos.
Desde la perspectiva de las prácticas utilizadas las metodologías pueden ser clasificadas como: Metodologías Tradicionales o Metodologías Ágiles.
![Page 28: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/28.jpg)
28
Metodologías Estructuradas
Los métodos estructurados comenzaron a desarrollar-se a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño primero y luego para el Análisis. Enfocados a implementaciones usando lenguajes de 3ra generación.
Ejemplos de metodologías estructuradas gubernamentales: MERISE (Francia), MÉTRICA 3 (España), SSADM (Reino Unido).
Ejemplos de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering.
![Page 29: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/29.jpg)
29
Metodologías Orientadas a Objetos (OO)
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto. En los 60’s SIMULA, en los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java, C# y otros. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 aparece el Método Unificado, que posteriormente se reorienta para dar lugar al Unified Modeling Language (UML), la notación OO más popular en la actualidad.
Métodos OO con notaciones predecesoras de UML: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Metodologías orientadas a objetos basadas en UML: Rational Unified Process (RUP), OPEN, MÉTRICA 3.
![Page 30: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/30.jpg)
30
Elementos de una Metodología
ProcesoSW
Notación
HerramientasPersonas
ArtefactosRoles
Actividades
![Page 31: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/31.jpg)
Metodologías Tradicionales Rational Unified Process (RUP)
![Page 32: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/32.jpg)
32
Fases y actividades
![Page 33: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/33.jpg)
33
Fases e Hitos (Milestones)
tiempo
Objetivos(Vision)
Arquitectura CapacidadOperacionalInicial
Releasedel Producto
Inception Elaboration Construction Transition
![Page 34: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/34.jpg)
34
Release, Base Line, Generación
ciclo de desarrollo ciclo de evolución
generación(release final de un ciclo de desarrollo)
release(producto al final deuna iteración)
base line(release asociadaa un hito)
![Page 35: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/35.jpg)
35
Elementos en RUP
Workflows (Disciplinas)
Workflows Primarios Business Modeling (Modado del Negocio) Requirements (Requisitos)Analysis & Design (Análisis y Diseño)Implementation (Implementación)Test (Pruebas)Deployment (Despliegue)
Workflows de ApoyoEnvironment (Entorno)Project Management (Gestión del Proyecto)Configuration & Change Management (Gestión de Configuración y Cambios)
![Page 36: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/36.jpg)
36
... Elementos en RUP
Workflow (Disciplina), Workflow Detail, Roles, Actividades y Artefactos
Ejemplo Workflow Detail:Analyse the ProblemWorkflow: Requirements
Actividades
Roles Artefactos
![Page 37: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/37.jpg)
37
Roles, Artefactos y Actividades de RUP
AnalystBusiness-Process Analyst Business DesignerBusiness-Model Reviewer Requirements ReviewerSystem AnalystUse-Case Specifier User-Interface Designer
DeveloperArchitectArchitecture Reviewer Capsule DesignerCode ReviewerDatabase Designer Design ReviewerDesignerImplementer Integrator
Testing professionalTest DesignerTester
Manager Change Control Manager Configuration ManagerDeployment ManagerProcess EngineerProject ManagerProject Reviewer
OtherCourse Developer Graphic ArtistStakeholderSystem AdministratorTechnical WriterTool Specialist
… ……
![Page 38: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/38.jpg)
38
Características Esenciales de RUP
Proceso Dirigido por los Casos de
Uso
Proceso Iterativo e Incremental
Proceso Centrado en la
Arquitectura
![Page 39: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/39.jpg)
39
Proceso dirigido por los Casos de Uso
RequisitosCapturar, definir y validar los casos de uso
Realizar los casos de uso
Verificar que se satisfacen los casos de uso
Análisis & Diseño
Implementación
Pruebas
Casos de Usointegran el
trabajo
![Page 40: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/40.jpg)
40
... Proceso dirigido por los Casos de Uso
Caso de Uso Realización de Análisis Realización de Diseño
Caso de Prueba
X
«trace» «trace»
«trace»«trace»
Pruebas Funcionales
PruebasUnitarias
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
![Page 41: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/41.jpg)
41
... Proceso dirigido por los Casos de Uso
![Page 42: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/42.jpg)
42
Proceso Iterativo e Incremental
El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes
En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala
Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes
![Page 43: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/43.jpg)
43
... Proceso Iterativo e Incremental
Para cada Caso de Uso implementado en la iteración, sus actividades se encadenan en una mini-cascada
Análisis & Diseño Programación
Pruebas
![Page 44: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/44.jpg)
44
… Proceso Iterativo e Incremental
EnfoqueCascada
EnfoqueIterativo eIncremental
![Page 45: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/45.jpg)
45
... Proceso Iterativo e Incremental
Grado de Finalización de Artefactos
![Page 46: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/46.jpg)
46
Proceso Centrado en la Arquitectura
Arquitectura de un sistema es la organización o estructura de sus partes más relevantes
Un arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades
RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo
Architecture
Inception Elaboration Construction Transition
![Page 47: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/47.jpg)
47
“Cambia el chip”
![Page 48: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/48.jpg)
48
![Page 49: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/49.jpg)
Metodos Ágiles Una ojeada al agilismo
![Page 50: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/50.jpg)
50
Ser Ágil => actuar según el Manifiesto Ágil (2001)
¿cuál es tu interpretación?
agilemanifesto.org
![Page 51: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/51.jpg)
51
Nuestra más alta prioridad es satisfacer al cliente a través de entrega de software temprana y continua. Bienvenidos los cambios en los requisito, incluso tardíamente en el desarrollo, even late in development. Los procesos ágiles capturan el cambio para conseguir las ventajas competitivas del cliente. Entregar frecuentemente software funcionando, en períodos de un par de semanas a un par de meses, con preferencia de los períodos más cortos. Gente del negocio y desarrolladores deben trabajar juntos diariamente durante el proyecto. Construir proyectos en torno a individuos motivados. Darles el entorno y apoyo que necesiten, y confiar en ellos para conseguir hacer el trabajo. El método más eficiente y efectivo para transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara-a-cara.
Software funcionando es la medida principal de avance. Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores, y usuarios deberían ser capaces de mantener una paz constante indefinida. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad. Simplicidad—el arte de maximizar la cantidad de trabajo NO hecho – es esencial. La mejores arquitecturas, requisitos, y diseños emergen desde equipos auto-organizados. A intervalos regulares, el equipo reflexiona acerca de cómo llegar a ser más efectivo, entonces afina y ajusta su comportamiento según esto.
12 Principios del Manifiesto Ágil
![Page 52: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/52.jpg)
52
Dificultades para implantar metodologías tradicionales. Procesos ceremoniosos, herramientas y notaciones de modelado sofisticadas (UML)El enfoque ágil es una solución a medida para un segmento importante de proyectos de desarrollo de software
“Aceptar el cambio” ...Pugna entre comunidades/gurúsBusiness
¿Por qué surgen las metodologías ágiles?
![Page 53: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/53.jpg)
53
Costo de los Cambios en SW
Costodel
cambio
tiempo
Tradicional
Suposición MAs
![Page 54: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/54.jpg)
54
Technical debt (deuda técnica)
Condiciones cambiantes e impedimentos
Estrategia individual y colectiva
La solución más ambiciosa siempre requiere algún sacrificio. Hay que optimizar el resultado (comportamiento ofrecido por el producto) en términos de los plazos y los recursos.
The Hard Choices Game
![Page 55: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/55.jpg)
55
Tradicional v/s Ágil
![Page 56: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/56.jpg)
56
Metodología Ágil Metodología TradicionalOrientada a proyectos pequeños. Corta duración (o entregas frecuentes), equipos pequeños (< 10 integrantes) y trabajando en el mismo sitio. Posibles problemas de escalabilidad en proyectos “grandes”
Aplicables a proyectos de cualquier tamaño, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos. Posibles problemas de adaptabilidad a proyectos “pequeños”
Pocos Artefactos. El modelado es prescindible, modelos desechables.
Más Artefactos. El modelado es esencial, mantenimiento de modelos
Pocos Roles, más genéricos Más Roles, más específicos
Requiere una relación contractual que se adapte a cambios en Alcance, Recursos y/o Plazos
Suele tenerse un contrato cerrado en cuanto a Alcance, Recursos y Plazo.
Cliente es parte del equipo de desarrollo (además in-situ)
El cliente interactúa con el equipo de desarrollo mediante reuniones programadas
La arquitectura se va definiendo y mejorando a lo largo del proyecto
Se promueve que la arquitectura se defina tempranamente en el proyecto
Énfasis en los aspectos humanos: el individuo y el trabajo en equipo
Énfasis en la definición del proceso: roles, actividades y artefactos
Se esperan cambios durante el proyecto Se espera que no ocurran cambios de gran impacto durante el proyecto
Características Ágiles v/s Tradicionales
![Page 57: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/57.jpg)
57
State of Agile Development (Survey 2010) 1 de 3
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
![Page 58: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/58.jpg)
58
State of Agile Development (Survey 2010) 2 de 3
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
![Page 59: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/59.jpg)
59
Los protagonistas
Kanban
Lean Development
Scrum
Extreme Programming
![Page 60: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/60.jpg)
60
¿De qué estamos hablando?
![Page 61: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/61.jpg)
Métodos Ágiles Extreme Programming
![Page 62: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/62.jpg)
62
Historia de XP
Creado por Kent Beck para la plantilla del proyecto C3 en Chrysler
Kent Beck fue contratado para dirigir el proyectoDurante el proceso nació una nueva metodología: eXtreme Programming (XP)C3 concluyó exitosamente en 1997
![Page 63: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/63.jpg)
63
Plantilla sugerida por Mike CohnComo <tipo de usuario>, quiero <algún objetivo> para así <alguna razón>.Ejemplo: “Como usuario del procesador de textos, quiero seleccionar una palabra y especificar que sea itálica, para así poder añadir énfasis a mi escritura”
William Wake, características deseables de una HU INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
Ron Jeffries propone “Card, Conversation, Confirmation”Card—La tarjeta de historia es sólo un título (su nombre) Conversation—Los desarrolladores deben preguntar para aclararla. Los representantes del negocio deben preguntar para confirmar que han sido comprendidos. Confirmation—¿Cómo se puede saber si se ha cumplido la historia? Expresar ejemplos concretos y transformar dichos ejemplos en pruebas de aceptación
Ítem ≈ Historia de Usuario
![Page 64: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/64.jpg)
64
Usuario: Autor Nombre: Enviar artículo
Importancia: Muy Alta Urgencia: Media
Riesgo: Medio Esfuerzo Estimado: 4
Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo.
Historia de Usuario
![Page 65: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/65.jpg)
65
Boceto de IU para Historia de Usuario
![Page 66: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/66.jpg)
66
Prácticas, Roles y Artefactos de XP
Juego de la planificaciónEntregas pequeñas/frecuentesMetáforaDiseño simple PruebasRefactoringProgramación en parejasPropiedad colectivaIntegración continuaSemana de 40 horasCliente in situEstándares de programación
Stand-up MeetingRoles
ClienteManager (Big Boss)CoachProgramadorTester (Pruebas de Aceptación)Tracker
Historias de UsuarioTareas de ProgramaciónPruebas de AceptaciónPlan de la Release
![Page 67: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/67.jpg)
67
Fase de Exploración
Historias de Usuario
Prioridad RiesgoEsfuerzo (puntos)
Spikes (Prototipos)
DefinirHistorias de Usuario
ElaborarSpikes
Estimar Esfuerzo y Riesgo
Identificar Escenarios/Pruebas de Aceptación
?
![Page 68: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/68.jpg)
68
Fase de Planificación de la Entrega
Historias de Usuario
PrimeraIteración
SegundaIteración
ÚltimaIteración
…
N-ésimaIteración
Historiasfuera de laentrega
Velocidad de Proyecto (VP)puntos/semana
Entrega<= 3 meses
2 a 3semanas
![Page 69: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/69.jpg)
69
Fase de ConstrucciónTrabajo durante una iteración
Pruebas deAceptación
Programaciónen Parejas
Tareas de Historias dela iteración
Historias de laIteración
Versión delProducto
DiseñoRefactoringProgramaciónPruebas UnitariasIntegraciónPruebas de IntegraciónPruebas de Aceptación
Validacióncontinua porel cliente
![Page 70: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/70.jpg)
70
Esquema de proyecto XP
![Page 71: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/71.jpg)
Métodos Ágiles Lean Development
![Page 72: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/72.jpg)
72
Impulso Lean Manufactoring al Agilismo
Desarrollo Ágil de Software
Scrum
Sistemas de Producción
Toyota Production System
JIT KaizenPull Systems Kanban
Poka-yoke
Lean Manufactoring…
Extreme Programming
Manifiesto Ágil
Otros métodos ágiles
¡Cuidado con las extrapolaciones en el contexto de producción de software!
![Page 73: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/73.jpg)
73
7 Mudas (Wastes) – Lean Manufacturing
Sobre-producción
Producir mucho o con demasiada
antelación Transporte Cualquier
transporte no esencial es desperdicio
Inventario Cualquier
cantidad por encima del
mínimo necesario
Esperas Por una
pieza , documento, etc.,
Tiempo sin actividad del
personal.
Sobre-proceso Trabajo o
servicio adicional no percibido por
el cliente
Retrabajo Cualquier
repetición de trabajo
Movimientos Cualquier
movimiento que no añada valor
![Page 74: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/74.jpg)
74
Auto- discipl
inaShitsuk
e
ClasificarSeiri
OrdenSeiton
Limpieza
Seiso
Estanda-
rización
Seiketsu
Método 5S – Lean Manufacturing
![Page 75: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/75.jpg)
Métodos Ágiles Kanban
![Page 76: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/76.jpg)
76
Kanban elemental
To Do Doing Done
A B
C
DE
F
G
Toyota Production System
Just-In-TimeLean Manufacturing
Eliminar el “waste”
Pull Systems
Kaizen
![Page 77: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/77.jpg)
77
Kanban elemental
To Do Doing Done
A
B
C
D E
F
G
Flujo
![Page 78: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/78.jpg)
78
Kanban elemental
To Do Doing Done
A
B
C
D EF
G
H
Flujo
![Page 79: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/79.jpg)
79
Kanban elemental
To Do Doing Done
A
B
C
D E
F
G
H
I
Flujo
![Page 80: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/80.jpg)
80
Kanban elemental
To Do Doing Done
A
B
C
D
E
F
G
H
I
J
Flujo
![Page 81: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/81.jpg)
81
Kanban elemental
To Do Doing Done
A
B
C
D
E
F
G
H
I
J
Flujo
![Page 82: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/82.jpg)
82
Kanban elemental
To Do Doing Done
A
B
C
D
E
F G
GH
I
J
K
L
Visibilidad del estado del trabajoConseguir un flujo de producción “Pull”Limitar el WIP (Work in Progress)
![Page 83: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/83.jpg)
83
Ilustrando el concepto WIP
MAGDALENA
PATRICIO
ALEJANDRO
FERNANDO
CATALINA
![Page 84: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/84.jpg)
84
Un Kanban manual (de pared) es un excelente medio para motivar al equipo durante la introducción del agilismo pero a medio y largo plazo no es una forma de trabajo sostenible, debería ser soportado por una herramienta
Ejemplos de Kanban (decenas de ejemplos en http://vimeo.com/16918299)
![Page 85: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/85.jpg)
85
Kanban por niveles
Puede resultar difícil la gestión de un Kanban en sólo un nivel (el de requisitos), mucho más complicado será gestionar y sincronizar Kanban en diferentes niveles de abstacción (en este caso Características y Tareas)
![Page 86: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/86.jpg)
86
![Page 87: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/87.jpg)
Métodos Ágiles Scrum
![Page 88: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/88.jpg)
88
Introducción a Scrum
Creado por Ken Schwaber and Jeff Sutherland, presentado en 1995 en OOPSLA
Documento “oficial“: Scrum Guide, Julio 2011, scrum.org
Scrum es un “framework”
PrincipiosTransparenciaInspecciónAdaptación
![Page 89: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/89.jpg)
89
Prácticas, Roles y Artefactos de Scrum
ReunionesSprint Planning MeetingDaily ScrumSprint Review MeetingSprint Retrospective
Release Planning Meeting
Equipo self-organizing y cross-functional
RolesScrum MasterProduct OwnerDevelopment Team
(3-9 miembros)
Product BacklogSprint BacklogItem (del Backlog)Unidad (del Sprint Backlog)
(Sprint/Release) Burndown
![Page 90: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/90.jpg)
90
Scrum “Core” (Scrum Guide, julio 2010)
“Units” (de menos de un día de trabajo)
A
BC
D
E
F
G
Product Backlog(lista ordenada)
Sprint Backlog
H
I
No más de 4 semanas
A1A3 A4
A2 A5
G1 G2
F1F2
F3F4
Daily Scrum15 min.
SprintReview Meeting
4 hrs.Sprint
RetrospectiveMeeting
3 hrs.
SprintPlanningMeeting
8 hrs.
Ítems seleccionadosdesde el
Product Backlog
Sprint Goal
Sprint “DONE”
Time-box
Capacidad!
![Page 91: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/91.jpg)
91
Software Factory «Ideal»
Product Backlog
“grooming”continuo
Implementaciónen el sprint
Sprinti-2 Sprinti-1 Sprinti
Introducir nuevos ítems
Definir ítems
Dividir ítemsque lo requieran
Estimar ítems
Ordenar ítems
Implementar ítems
Testear ítems
Introducir nuevas ítems
Definir ítems
Dividir ítemsque lo requieran
Estimar ítems
Ordenar ítems
Implementar ítems
Testear ítems
Introducir nuevas ítems
Definir ítems
Dividir ítemsque lo requieran
Estimar ítems
Ordenar ítems
Implementar ítems
Testear ítems
Tiempo
![Page 92: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/92.jpg)
Métodos Ágiles Scrum + Kanban
![Page 93: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/93.jpg)
93
Scrum + Kanban elemental
To Do Doing Done
A
B
C
D
E
F
G
ProductBacklog
Sprint
H
I
J
No más de 4 semanas
Sprint PlanningMeeting
![Page 94: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/94.jpg)
94
Actividades esenciales asociadas a un ítem
TD P
Definición. Especificación del cambio de comporta-miento en el sistema (desde la perspectiva del usuario)
Programación. Implementación del cambio de comportamiento en el producto
Testeo de Aceptación. Aplicación de Pruebas de Aceptación para verificar la correcta implementación del cambio
Ítem de cambio constatable externamente en el producto:
Nuevo RequisitoMejora en un requisito existenteCorrección de un Fallo.
Las actividades esenciales que debe realizar el equipo con estos ítems son: Definición (D), Programación (P) y Testeo de Aceptación (T).
![Page 95: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/95.jpg)
95
Scrumban = Kanban + Scrum con actividades específicas
A
BF
G
To Do Doing
Implementar
To Do Doing
TestearDone
Sprint Backlog
CEF
G
To Do Doing
Definir
I
Done
D
H
J
Todas los ítems que están en actividades asociadas a la
preparación antes de ponerlos en un Sprint.
La columna Done es una lista ordenada, en ella los ítem
estarían ya estimados
SprintPlanningMeeting
Las actividades (columnas principales) dependen del contexto del proyecto. Son actividades realizadas para cada ítem cuando está en el
Product Backlog y luego durante el Sprint
Product Backlog
![Page 96: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/96.jpg)
96
![Page 97: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/97.jpg)
97
Scumban manual (de pared)
![Page 98: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/98.jpg)
98
Debilidades de un Scrumban manual 1 de 21. Un Scrumban manual tiene los inconvenientes obvios asociados
a su mantenimiento en una pared y con post-it, especialmente si el volumen de ítems es alto.
2. Obstáculo si el equipo está distribuido o tiene que desplazarse de su puesto de trabajo para ver el Scrumban.
3. Un post-it ofrece un espacio demasiado limitado para gestionar la información asociada a un ítem.
4. El desarrollador encargado de un ítem no lo debería coger desde el Scrumban para llevárselo a su puesto de trabajo pues el resto del equipo no visualizaría dicho ítem.
5. En caso de trabajar con varios productos a la vez, se tendría que mantener un Scrumban por cada producto.
![Page 99: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/99.jpg)
99
Debilidades de un Scrumban manual 1 de 26. ¿Qué se hace con los ítems de sprints pasados?, por defecto se
desecharían todos los post-it una vez terminado el sprint.7. Normalmente la finalización de un sprint se solapará al menos
para algunos miembros del equipo con el trabajo del siguiente sprint. Esta situación obligaría a tener un Scrumban son dos sprints, uno para la versión actual y otro para la siguiente.
8. El Scrumban de pared no soporta adecuadamente actividades en paralelo o actividades alternativas.
9. Al detectar re-trabajo sólo se puede dar vuelta atrás moviendo el item a la actividad donde se debe hacer el re-trabajo. No es sencillo representar que re-tabajo se está haciendo pero sin mover hacia atrás el ítem. En el caso de adelantar trabajo de una actividad sucede algo similar.
![Page 100: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/100.jpg)
100
Debilidades de un Scrumban manual 1 de 210. Cada producto, tipo de ítem o incluso ítem podrían requerir
unas actividades específicas. Un Scrumban de pared establece un tratamiento igual para todos los ítems.
11. No es sencillo llevar la contabilización de estimaciones, esfuerzo restante, y ello a nivel de precisión de actividades.
12. Todo el registro asociado a los fallos y defectos detectados, o respecto al histórico asociado al ítem no suele considerarse.
13. Reordenamiento de los ítems en el Product Backlog14. Difícil de representar el trabajo de varios equipos actuando en
el mismo producto (Scrum de Scrums)15. Incluir unidades (tareas) asociadas a ítems (como post-it
adicionales) aumenta los problemas de gestión del Kanban.
![Page 101: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/101.jpg)
Métodos Ágiles Teamwork
![Page 102: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/102.jpg)
102
Cross-Functional ySelf-Organizing Team
![Page 103: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/103.jpg)
103
Cross-Functional Team - Definición “Cross-Functional Teams have all competencies needed to accomplish the work without depending on others not part of the team”. [The Scrum Guide, 2011]
“A team consisting of representatives from the various functions involved in product development, usually including members from all key functions required to deliver a successful product. … The team is empowered by the departments to represent each function’s perspective in the development process.” [PDMA Handbook of New Product Development (2nd ed.)]
“A self-managing team that has all the necessary skills to create a done increment”. [The Enterprise and Scrum. Ken Schwaber, Microsoft Press, 2007]
Traducciones comunes de cross-functional: multidisciplinario, interdisciplinar, interfuncional o transversal.
Pero … ¿Cómo se interpreta y se pone en práctica?
![Page 104: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/104.jpg)
104
Roles Ágiles y Tradicionales
Scrum MasterProduct OwnerDevelopment Team
Roles en Scrum
Cliente
Coach Programador
Roles en XP
Jefe deproyecto
Tester(Pruebas de Aceptación)
Analista ProgramadorCliente
Roles en metodologías más tradicionales (p.e. RUP)
…
Tester(Pruebas de Aceptación)
Muchos más
unos pocos más
…Manager
![Page 106: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/106.jpg)
106
Roles de Scrum
Scrum Master
Product Owner
DevelopmentTeam
Roles Scrum
El Product Owner (PO) es responsable de gestionar el Product Backlog, lo cual incluye:
Expresar claramente los items del Product BacklogOrdenar los items del Product Backlog para conseguir objetivos y misión del productoAsegurar el valor del trabajo que realiza el Development TeamAsegurar que el Product Backlog es visible, transparente, y claro para todos, y mostrar en qué es lo que trabajará próximamente el Scrum Team Asegurar que el Development Team entiende los items en el Product Backlog
El PO debe hacer respetar sus decisiones en la organización y proteger al Development Team de las solicitudes o influencias de los stakeholders
Scrum Guide, julio 2010
![Page 107: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/107.jpg)
107
Scrum Master
Product Owner
DevelopmentTeam
Roles Scrum
El Scrum Master (SM) es responsable de asegurar que Scrum es entendido y aplicado. El SM es un sirviente-líder para el Scrum Team.
Servicios del Scrum Master para el Product Owner:
Enseñar técnicas para la gestión efectiva del Product BacklogAyudar a comunicar claramente la visión, objetivos e ítems del Product Backlog al Development TeamEnseñar al Scrum Team a crear claros y concisos ítems del Product BacklogAyudar a comprender la planificación a largo plazo en un ambiente empíricoAyudar a comprender y aplicar agilidadApoyar durante el sprint y las reuniones según se le requiera o sea necesario
Roles de Scrum – Scrum Master 1de 2
Scrum Guide, julio 2010
![Page 108: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/108.jpg)
108
Scrum Master
Product Owner
DevelopmentTeam
Roles Scrum
Servicios del Scrum Master Service para el Development Team
Entrenar en self-organization y cross-functionalityEnseñar y dirigirle hacia la creación de productos de alto valorEliminar los impedimentos para su avance en el trabajoApoyar en sprint y reuniones cuando se le pida o lo considere necesarioEntrenar para enfrentar ambientes organizacionales en los cuales Scrum aún no ha sido completamente adoptado y entendido
Servicios del Scrum Master para la OrganizationLiderar y entrenar la adopción de Scrum en la organizaciónPlanificar implementaciones de Scrum dentro de la organizaciónAyudar a los empleados y usuarios a comprender e implantar Scrum y el desarrollo empírico de productosProvocar cambios que aumenten la productividad del Scrum TeamTrabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización
Roles de Scrum – Scrum Master 2 de 2
Scrum Guide, julio 2010
![Page 109: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/109.jpg)
109
Scrum Master
Product Owner
DevelopmentTeam
Roles Scrum
El Development Team tiene las siguientes caraterísticas:
Es self-organizing. Nadie (ni siquiera el Scrum Master) le dice como convertir el Product Backlog en un incrementos de funcionalidad potencialmente entregableEs cross-functional, tiene como equipo todas las habilidades necesarias para crear un incremento del productoNo tiene títulos más que el de Developer, independiente del trabajo que esté realizando la persona, no hay excepciones a esta reglaLos miembros pueden tener habilidades y áreas de especialización pero ellas cuentan para el Development Team como un todo No contienen sub-teams dedicados a dominios particulares como testeo o análisis de negocioTiene entre 3 y 9 miembros (obviamente sin contar el PO y SM)
Roles de Scrum – Development Team
Scrum Guide, julio 2010
![Page 110: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/110.jpg)
110
Desde roles Tradicionales hacia roles Ágiles
Scrum Master
Product Owner
DevelopmentTeam
Roles Scrum
Jefe deproyecto
Tester(Pruebas de Aceptación)
Analista
Programador
Cliente
Roles Tradicionales
…
![Page 111: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/111.jpg)
111
Entonces …. ¿qué es un Cross-Functional Team?
NO implica que todos los miembros:
Sean expertos en todas las actividadesRealicen siempre las mismas actividadesRealicen juntos todas las actividades de cada ítemRealicen cada uno una actividad de cada ítemRealicen actividades diferentes en cada ítem…
El rol de un miembro es respecto de cada ítem en la que participa, NO tiene por qué ser el mismo rol para todos ellos.
El interés por tener en un equipo personas con roles fijos específicos dependerá del grado de especialización disponible/deseado y del número de miembros del equipo
Otras ActividadesDefinición
Programación Testeo
![Page 112: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/112.jpg)
112
T
D
P
T
D
P
T
D
P
T
D
P
Sólo 1 miembro para un ítem 2 miembros para un ítem
2 miembros para un ítem 3 miembros para un ítem
“Desarrollador” “Analista/Programador” “Tester”
“Tester”
“Analista/Tester”“Programador” “Programador”
“Analista”
Dependiendo del tamaño del equipo de desarrollo:
Algunas Alternativas Actividades-Roles para abordar un mismo ítem
Scrum en lugar de utilizar roles específicos tiene sólo Development Team como rol genérico desempeñado por todos los desarrolladores
![Page 113: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/113.jpg)
113
Ítem8
En un mismo Sprint cada ítem podría tener una estrategia diferente en cuanto a roles-agentes
T
D
P
Carlos María
Ítem1
T
D
P
Carlos María
Ítem2
T
D
P
Ítem4
MaríaCarlos
T
D
PMaría
Carlos
Ítem3
Ítem5
T
D
P
María
Carlos
Javier
Ítem6
T
D
P
JavierMaríaCarlos
T
D
P
María
Marta
Javier
T
D
PMabel
Ítem7
Ítem9
T
D
P
Todo el “Team”
Carlos
Mabel
Mabel
Marta
![Page 114: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/114.jpg)
114
¿Qué es un Self-organizing Team?Los miembros del equipo:
Acuerdan el reparto del trabajo, en conjunto y/o cada miembro se auto-asigna trabajo en la medida que se quede disponible. Proactividad.
Acuerdan cómo realizar el trabajo. Toman las decisiones técnicas necesarias.
Comparten un rol genérico, p.e. “Desarrollador”. No existe el rol Jefe, o si existe es más bien un “facilitador”, el cual no interviene en la asignación de trabajo ni en cómo debe hacerse el trabajo.
![Page 115: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/115.jpg)
115
¿Manager … Líder …Facilitador?
![Page 116: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/116.jpg)
116
Comentarios finales respecto de rolesLos roles son sólo una facilidad para asociar ciertas
actividades. Lo importante no son los roles en sí mismos sino las actividades que se deben realizar y quién se ocupará de ellas en cada ítem.Scrum promueve romper con la especialización extrema, es decir, evitar que cada miembro realice sólo una actividad, pero esto no implica que no deban existir expertos en ciertas actividades.Cada miembro puede realizar diferentes actividades en diferentes ítems. Pueden haber diversas combinaciones en una misma iteración. No existe una combinación apropiada para todas las situaciones de Producto/Cliente/Equipo/Ítem …Buscar su punto de equilibrio entre los extremos: “cada miembro un rol” y la “no necesidad de roles en el equipo”. ¿Todos los miembros realizan todas las actividades con la misma motivación, eficacia y eficiencia?
![Page 117: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/117.jpg)
117
Gemba – Lugar de trabajo
![Page 118: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/118.jpg)
Métodos Ágiles Herramientas para Gestión Ágil
![Page 119: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/119.jpg)
119
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
Herramientas usadas en proyectos ágiles
![Page 120: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/120.jpg)
120
Agilo www.agile42.com/cms/pages/agilo/JIRA www.atlassian.com/software/jira/OnTime www.axosoft.com/ontimePivotal Trackerwww.pivotaltracker.com/Rally www.rallydev.com/ScrumDesk www.scrumdesk.com/Scrumworks danube.com/scrumworks/pro/TargetProcess www.targetprocess.com/Team Concert www-01.ibm.com/software/rational/products/rtc/TinyPM www.tinypm.com/homeVersionOne www.versionone.com/
Herramientas para la gestión ágil de proyectos
![Page 121: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/121.jpg)
121
Proceso Iterativo e Incremental con Scrum
tiempo
P Sprint Planning Meeting R7
R8
R9
R10
R11
R12
P
C5 T5R5D5
C6 T6R6D6 TP
Lista ordenada de próximas WUs (en constante cambio). Requisitos definidos en gran parte antes de que a WU se incluya en una iteración
Product Backlog
R Sprint Review Meeting
P
PreparaciónProduct Backlog
R1D1
C1 T1
TC2 T2
R2D2 R
ImplementaciónSprint
PreparaciónProduct Backlog
C3 T3R3D3
C4 T4R4D4 T R
PreparaciónProduct Backlog
ImplementaciónSprint
![Page 122: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/122.jpg)
122
Kanban + Scrum usando WFs
Cada ítem sigue su WF
Los WF deberían ser configurables en cuanto a actividades, roles y encadenamiento de actividades.
Un producto puede tener asociados varios WFs disponibles para utilizar con sus WUs
![Page 123: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/123.jpg)
123
![Page 124: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/124.jpg)
124
Ejemplo workflow simple “estilo tradicional”
![Page 125: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/125.jpg)
125
… un workflow más complejo
![Page 126: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/126.jpg)
126
Kanban de TUNE-UP
Actividades en lasque puede estar una
WU.Corresponde a la
síntesisDe todo el trabajo en
el que participa el agente, según los
WFs de cada una de las WUs.
Filtro agente
Filtro producto y versión
Estado de las WUs en cada
actividad
Diversas formas de acceder al
detalle de la WU en el WUM (Work Unit Manager)
![Page 127: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/127.jpg)
127
TUNE-UP Kanban
TUNE-UP Kanban y Gestor de WUs (Ítems)
TUNE-UP Work Unit Manager
Agentesresponsables
Tracking dela WU
Definición del cambiomediante pruebas de
aceptación
Actividades en lasque puede estar una WU
(es configurable)
Filtro agenteFiltro producto y versión
![Page 128: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/128.jpg)
128
www.tuneupprocess.com
![Page 129: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/129.jpg)
Métodos Ágiles Planificación y el Product Backlog
![Page 130: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/130.jpg)
130
Planificación Iterativa e Incremental usando Diagrama Gantt
Extrapolar esto a decenas de ítems en cada versión!!
Extrapolar esto a ítems con WFs diferentes y más complejos!!
![Page 131: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/131.jpg)
131
Producto - Ítems de trabajo
Arquitectura en capas
Sprint visto por Cliente (ítems correspondientes
a características externas del producto)
…
…
Sprint visto por equipo de desarrollo
(incluye ítems detrabajo en capas internas)
Producto en desarrollo o
mantenimiento
![Page 132: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/132.jpg)
132
Esfuerzo estimado versus Capacidad
Sprint
Product Backlog
Esfuerzo
estimado
Capacidad
del equipo
![Page 133: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/133.jpg)
133
Planificación Ágil – Sprints y Releases
P
tiempo
SprintX
P P
Sprintx+1 Sprintx+2
P Sprint Planning Meeting
Product Backlog
R Sprint Review Meeting
R R R
Release
![Page 134: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/134.jpg)
134
Gestión de Fallos
WUx
tiempoFin
SprintInicioSprint
WUy
T
WUw
Fallo detectado y resuelto en
versión
Fallo para resolver en
versión futura
Fallo detectado yresuelto en la misma WU
Fallo detectadoen pruebas regresión
WUn
Fallo detectado en versión
previa
WUz
![Page 135: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/135.jpg)
135
“The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.”[Scrum Guide July 2011].
“The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate.” [Scrum Guide July 2011].
La clave: el Product Backlog
![Page 136: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/136.jpg)
136
Alternativas para estimación
Ítem Units (Tareas)Ítems (p.e. Historias de Usuario)
(adaptado de una presentación de Henrik Kniberg)
1. No estimarlas
2. Estimarlas usando tallas de camiseta1. No dividir HU en tareas
2. No estimarlas, sólo contarlas
3. Estimar las tareas en horas o días (ideales)
12h8h4h
S M LS ML
3. Estimar las HU usando Puntos
1p2p
5p
4. Estimar las HU en horas o días (ideales)
10h 30h 45h
![Page 137: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/137.jpg)
137
Planning Poker
2
5
3
8
2
?
Utiliza Puntos como medida de esfuerzo. Es una medida de tamaño relativa.Se corresponde con una velocidad de proyecto también expresada en Puntos.No útil para seguimiento (¿cuántos puntos restan de trabajo en una ítem?)
![Page 138: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/138.jpg)
138
Más información en: http://bit.ly/tNeyn7
![Page 139: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/139.jpg)
Métodos Ágiles Seguimiento
![Page 140: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/140.jpg)
140
Planificación y seguimiento de proyectos
Introducción
Alcance
Costo Tiempo
Seguimiento ¿lo conseguiremos?
![Page 141: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/141.jpg)
141
¿Qué indicadores utilizar para realizar el seguimiento?
utilizar
Esfuerzo restante
Esfuerzo abordable
Estimar el esfuerzoComputar el avance
Conocer disponibilidad futuraConocer productividad
Introducción
Velocidad de proyecto (VP)o Capacidad del equipo
![Page 142: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/142.jpg)
142
Seguimiento del proyecto cuando se usa un enfoque ágil
Proceso iterativo e incremental con entregas frecuentes
Se esperan cambiosComplicidad del cliente (involucrado y negociador)
Introducción
…¿Podría “relajarse” el seguimiento del proyecto?
Depende , Sí, si existen las condiciones de flexibilidad y negociación ideales para el enfoque ágil. Sin embargo, siempre el seguimiento es útil para detectar oportunamente desviaciones significativas y también para obtener información necesaria para una retrospectiva
Seguimiento muy continuo (día a día, en cada Stand Up Meeting / Daily Scrum)
![Page 143: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/143.jpg)
143
Gráficas Burndown protagonistas en Scrum para el seguimiento de las sprints y releases, pero …
“Por lo visto” son muy poco usadas en la práctica. Posibles razones:
Disciplina individual de estimación y registro de avanceEsfuerzo para recolección y síntesis de los datosDificultades para su interpretación
Gráficas Burndown 1 de 4
![Page 144: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/144.jpg)
144
Visualización del estado del Sprint
![Page 145: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/145.jpg)
145
Seguimiento Ágil - Gráficas Burndown
La gráfica Burndown ilustra el Esfuerzo Restante, para el seguimiento éste debe contrastarse con el Esfuerzo Abordable en el período restante del Sprint.
Para recolectar la información necesaria para el seguimiento diario es importante conectar dicha recolección con el trabajo diario de los participantes
![Page 146: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/146.jpg)
146
Gráficas Burndown 3 de 4
![Page 147: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/147.jpg)
147
Gráficas Burndown 4 de 4
Soporte para gráficas Burndown en herramientas comerciales
![Page 148: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/148.jpg)
148
Interpretación de las Gráficas Burndown
Eventos que invalidan la lectura del Esfuerzo Restante
Actividad con estimación sobrepasadaActividad sin estimación
Eventos que provocan una variación del Esfuerzo Restante Ajuste en Estimación - Incremento/Decremento Introducción de estimación faltante Trabajo añadido a iteración (WU nueva o ya existente) Trabajo desestimado, cambiado de iteración o eliminado Trabajo terminado Trabajo asignado/desasignado a/de un agente Corrección del Esfuerzo Invertido
![Page 149: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/149.jpg)
149
![Page 150: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/150.jpg)
Gestión Ágil de Requisitos
![Page 151: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/151.jpg)
151
TDRE: Test-Driven Requirements Engineering
Requisitos
Análisis
Diseño deArquitectur
a
Diseño deMódulos
Programación
Pruebas Unitarias
Pruebas de Integración
Pruebas de Sistema
Pruebas de Aceptación
Especificación y Diseño de Pruebas
Aplicación de Pruebas
![Page 152: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/152.jpg)
152
Desarrollo Test-Driven (TDD)
VersióniVersióni+1
Nuevo requisitoMejoraCorrección de defecto
Cambio en comportamiento
Expresados en términos de Pruebas de Aceptación
Unidades deTrabajo (Wus)
![Page 153: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/153.jpg)
153
Pero …
Plantillas de Casos de Uso Bocetos de IU
Descripción narrativa
Diagramas de Secuencia
Casos de Uso
Especificación de requisitos típica
![Page 154: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/154.jpg)
154
Plantillas de Casos de Uso
Bocetos de IU
Descripción narrativa (muy breve) + atributos
Diagramas de Secuencia
Modelo de Requisitos
… bueno, ¡de acuerdo!, podrían
utilizarse Casos de Uso y otros diagramas de UML
Escenarios → PAs
Propuesta de TUNE-UP: TDRE (Test-Driven Requirements Engineering)
![Page 155: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/155.jpg)
155
Ejemplo de especificación de requisitos Enviar artículo
Usuario: Autor Prioridad: Alta Esfuerzo: Medio Riesgo: Medio Tipo: Nuevo Requisito
Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo.
ATEST 1.1: Obligatorio Título, al menos un tópico asociado, al menos un autor y fichero adjunto.
ATEST 1.2: Título de artículo no repetido con autores coincidentes
ATEST 1.3: Primer autor marcado por defecto como contacto
ATEST 1.4: Autores no repetidos en un mismo artículo
ATEST 1.5: Tamaño del artículo no superior a 5 Mb
ATEST 1.6: Envío exitoso con email de confirmación
![Page 156: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/156.jpg)
156
Definición de Pruebas de Aceptación (PAs)
“Una PA tiene como propósito demostrar al cliente
el cumplimiento de un requisito del software”
Precisando más, una PA:
Describe un escenario, compuesto por una situación del sistema
(condición de ejecución) una secuencia de pasos de uso y el
resultado alcanzado, todo ello desde la perspectiva del usuario
Puede estar asociada a requisitos funcionales o no funcionales
Un requisito tendrá una o más PAs asociadas
Las PAs cubren desde escenarios típicos/frecuentes hasta los más
excepcionales
![Page 157: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/157.jpg)
157
Ejemplo: Requisito ReintegroPruebas de Aceptación (= Escenarios)
Reintegro normalIntento de reintegro con saldo insuficienteFalta de ciertos tipos de billetesCancelación de operaciónAviso de no entrega de reciboFuera de servicio por falta de billetesExcedido tiempo comunicación con bancoExcedido tiempo inactividad usuarioCajero en mantenimiento…
Identificación de Pruebas de Aceptación
![Page 158: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/158.jpg)
158
Definición de Pruebas de Aceptación
Estructura de una PANombreCondición
------
Pasos------
Resultado esperado------
Ejemplo de PA «Intento de reintegro con saldo insuficiente»Condición
Cliente con saldo positivoAcceder a ventana de reintegro
PasosIntroducir cantidad mayor que el saldo
Resultado esperadoMensaje «saldo insuficiente»Se ofrece nueva introducción
![Page 159: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/159.jpg)
159
Ejemplo: WU «Adaptación a nueva normativa». Es una mejora que afectará entre otros requisitos ya implementados al requisito Reintegro
Impacto en requisito Reintegro (en sus Pruebas de Aceptación)Reintegro normalConfiguración monetaria del paísIntento de reintegro con saldo insuficienteSaldo insuficiente con cliente premiumFaltan de ciertos tipos de billetesCancelación de operaciónAviso de no entrega de reciboConfirmación si cantidad de reintegro es altaFuera de servicio por falta de billetesExcedido tiempo comunicación con bancoExcedido tiempo inactividad usuarioCajero en mantenimiento…
Mantenimiento del software basado en PAs
![Page 160: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/160.jpg)
161
Gestión del producto SW
Reintegro
WU «adaptación a
nueva normativa»
Requisitos afectados por la WU
Estructura de requisitos
del producto
![Page 161: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/161.jpg)
162
Proceso de Desarrollo dirigido por PAs
Definen WUsen términos
de PAs
Escribe código para satisfacer
las PAs
Diseña instanciacio
nes y aplica las
PAs
Cambios en la estructura de requisitos y/o
en PAs
WUs
Demo
![Page 162: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/162.jpg)
163
TDRE es rentable, la especificación de requisitos como PAs ofrece las siguiente ventajas:
Facilita la especificación y validación de los requisitosApoya la estimación del esfuerzo de desarrolloSon un instrumento adecuado para Negociar con el clienteSu ordenamiento facilita el trabajo de programadores y testersContribuyen a una mejor especificación de los requisitos. Respecto del estándar IEEE 830, se mejora en cuanto a verificabilidad, mantenibilidad, no ambigüedad, trazabilidad, etc.
TDRE se enmarca en la gestión integral del producto, no sólo en su desarrollo inicial sino también en su posterior mantenimiento
Comentarios finales respecto de TDRE
![Page 163: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/163.jpg)
Mejora Continua del Proceso
![Page 164: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/164.jpg)
165
Mejora continua
Retrospectivas
Plan
DoCheck
Act
Sprint
![Page 165: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/165.jpg)
166
Adaptar la metodología al producto y refinarla
Kanban
Scrum
XP
RUP
Ad-hoc Plan
Do
Check
Act
Otras metodologías
Ágiles
![Page 166: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/166.jpg)
167
El Know How está contenido en los WFs
![Page 167: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/167.jpg)
168
Cada WU puede necesitar un tratamiento específico dependiendo de por ejemplo:
Su tipo: Nuevo requisito, mejora en requisitos existente, corrección de fallo, etc.Actividades específicas, por ejemplo: traducción, pruebas de rendimiento, validaciones adicionales, automatización de pruebas, etc.Cliente solicitante del cambioEl productoEl equipo de desarrollo y su estrategia de organización…
Decisiones respecto de los WFs
![Page 168: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/168.jpg)
169
Decisiones extremas: “Un WF para todas las WUs” v/s “Un WF para cada WU”“WFs con muchas actividades” v/s “WFs ajustados a cada WU”“Pocos WFs” v/s “Muchos WFs”
Decisión recomendada:Comenzar con muy pocos WFs y que sean lo más sencillo posibleCentrar la mejora continua del proceso en la mejora de los WFs (añadiendo, modificando o eliminando actividades y sus relaciones, o incluso añadiendo o eliminando WFs)
Decisiones respecto de los WFs
![Page 169: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/169.jpg)
170
Escalando el agilismo
…
Equipos pequeños < 10 miembros
Scrum de ScrumsUn mismo proyecto
con varios equipos
![Page 170: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/170.jpg)
Conclusiones
![Page 171: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/171.jpg)
172
Expectivas tras el Agilismo
Alcance
Costo Tiempo
Expectativas “Realistas”Satisfacción del cliente. Involucrar al Cliente. Mejora en la gestión de prioridades“Adelgazar” el proceso. Eliminar el “Waste”. Lean DevelopmentDetectar oportunamente situaciones que afectan negativamente al proyectoEstablecer un ritmo de trabajo sostenible-realistaMantener al equipo motivado y comprometido
![Page 172: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/172.jpg)
173
Desarrollo “Tradicional” de Software
Desarrollo Ágil de Software
Agilismo más allá del ámbito del software
Gestión Ágil de Proyectos
PMBOK
Gestión “Tradicional” de Proyectos
?
Técnicas y Herramientas“Tradicionales”
Generalización a otros
ámbitos de proyecto
Metodologías, Técnicas y
Herramientas “Ágiles”
Manifiesto Ágil
SWBOKRUP
UMLCMMI PMO
![Page 173: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/173.jpg)
174
PMOs (Portafolio management Office,Program Management Office, o
Project Management Office)
Agilismo a diferentes niveles
Equipo de trabajo (trabajando en un producto/proyect
o)
Aplicación deprácticas ágiles
![Page 174: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/174.jpg)
175
¿To be or not to be Ágil?
“There is an elephant in the room”
![Page 175: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/175.jpg)
176
…¿To be or not to be Ágil?
Agile's Teenage Crisis? Philippe Kruchten . Enumeración de los “elefantes”. infoq.com/articles/agile-teenage-crisis
“ScrumButs “= práctica no aplicada / excusa / alternativa. scrum.org/scrumbut
¿Necesitamos una evaluación de procesos ágiles ?(¿nivel de madurez?) … espero que no .
Post-Agilismo …
![Page 176: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/176.jpg)
177
Sinergia de Prácticas (en Extreme Programming)
Extreme Programming: Kent Beck
Mientras más prácticas se apliquen y en mayor profundidad mejor es el resultado
![Page 177: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/177.jpg)
178
“By early 2009, there were more than 60,000 CSMs. More organizations were using Agile processes than waterfall processes, and of those employing Agile 84% were using Scrum. However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. Martin Fowler wrote in his blog that he was encountering many instances of "Flaccid Scrum“(martinfowler.com/bliki/FlaccidScrum.html). Teams were using Scrum vocabulary but weren’t able to create a potentially shippable increment of functionality within a single Sprint.” [Ken Schwaber, Scrum.org]
“Flaccid Scrum”
![Page 178: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/178.jpg)
179
El rol de las certificaciones en el contexto ágil
![Page 179: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/179.jpg)
180
Su nombre aquí
![Page 180: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/180.jpg)
181
En 1997 Bertran Meyer escribió una sátira acerca de UML en una edición especial de la revista American Programmer. El artículo se titula “UML: The positive spin”. En ella se presenta una carta ficticia de un alumno que solicitaba a su profesor que le subiera la nota que había obtenido por su trabajo donde hacía una evaluación de UML.
Después de recorrer en forma sarcástica todas las posibles contribuciones de UML respecto de lo ya existente (descartando cada una de ellas), finaliza la carta con esta reflexión:
“My long search had not been in vain. It had led me to a full appreciation of the UML, this admirable self-feeding machine, devoted from A to Z to the creation of a new market, free of any of the difficulties associated with the unpleasant business of software development: UML books! UML courses! Courses on the books! Books on the courses! Books on the books! Introductory courses to prepare for the advanced courses! Courses for those who teach the courses! Revisions! UML journals! Conferences! Workshops! Tutorials! Standards! Committees! T-shirts! The more you think about the possibilities, the more dazzling they look. And for any reader brave or bored enough to read the documents to the end, the grand scheme is all there, laid out in the final paragraph.”
¿Una historia que se repite?
![Page 181: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/181.jpg)
182
State of Agile Development (Survey 2011) 3 de 3
Otras también importantes • Carencia de cliente in-
situ• Contrato poco flexible• Equipo numeroso y/o
disperso• Entorno de trabajo
inapropiado
State of Agile Survey, 2011, http://bit.ly/z32882
![Page 182: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/182.jpg)
183
Mayoritariamente se está promoviendo la “revolución”, con un discurso radical representado por frases tales como: “eres o no ágil”, “sigues o no Scrum”, “eres o no un Scrum Master”, etc.Cada equipo tiene su propia realidad de desarrollo de software (metodología, equipo en sí mismo, productos, clientes, entorno de trabajo, etc.).Es prácticamente imposible llegar a ser 100% ágil. Primero porque no existe una definición rigurosa de ello (ni la necesitamos ) y segundo porque probablemente el contexto del equipo se lo impediráLas prácticas establecidas por Scrum, XP, u otros enfoques constituyen puntos de referencia en cuanto a mejora. No hay que obsesionarse con aplicar todo y menos de inmediato.
Lectura recomendada: http://bit.ly/v0AGmC
¿Revolución o evolución hacia el agilismo?
![Page 183: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/183.jpg)
184
Características NO consideradas ágilesCaracterísticas consideradas ágiles• Modelo de proceso en
cascada• Planificación y seguimiento
con Diagramas Gantt• Entregas NO frecuentes• Gestión de Requisitos
clásica• Jefe autoritario• Muchos roles• Asociación fija de roles-
agentes• Contrato y plan no flexibles• Relación más distante con
cliente• Énfasis en modelado y
especificación• …
• Modelo de proceso iterativo e incremental
• Planificación por iteraciones• Entregas frecuentes (alrededor de un
mes)• Seguimiento continuo (Sprint Burndown)• Gestión del Product Backlog (trabajo
pendiente)• Especificación ágil de Requisitos y
Pruebas de Aceptación• Jefe facilitador, líder. Equipo auto-
organizado• Roles genéricos• No se asignan roles específicos a los
agentes• Disciplina de reuniones frecuentes• Contrato y plan flexibles (tolerancia al
cambio)• Cliente in-situ• Espacio de trabajo
abiertos/colaborativos• Énfasis en pruebas (automatizadas)• Refactorización (mejora continua de
arquitectura)• Integración continua• Estándares de programación• Programación en parejas• Propiedad colectiva• …
¿cómo evolucionar?
Evolución hacia el agilismo
![Page 184: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/184.jpg)
185
Determina tu punto de partida
Características NO ágiles
Características ágiles
Establece un punto de partida “realista” para iniciar tu evolución hacia el agilismo
Requisito mínimo: tu punto de partida debe considerar un proceso iterativo e incremental con entregas frecuentes.
![Page 185: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/185.jpg)
186
Conjugar: Metodología + Herramienta + Contextualización (cliente, equipo, dominio de aplicación, proyecto, tecnología, etc.)
“Un sistema complejo que funciona es la evolución de uno más simple que funcionaba” … ir paso a paso en la mejora del proceso.
“El mantenimiento existe”. “Todo producto exitoso requerirá mantenimiento”. Gestionar el producto
Reflexiones adicionales
![Page 186: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/186.jpg)
187
Mejorar la productividad del equipo a partir de la mejora en la productividad de sus miembros → Disciplina y hábitos individuales de trabajo
… Reflexiones adicionales
![Page 187: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/187.jpg)
188
Configuración metodológica para un producto
Kanban
Scrum
XP
RUP
Ad-hoc Plan
Do
Check
Act
Otras metodologías
Ágiles
![Page 188: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/188.jpg)
189
¿Qué es TUNE-UP?
Adquirir conocimientos, definir metodología, seleccionar
herramienta, e integrar todo
Formación y consultoría,metodología y herramienta
configurables
…
![Page 189: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/189.jpg)
Un Plan de Implantación de Prácticas Ágiles
![Page 190: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/190.jpg)
191
FASE 0: Formación Básica en Agilismo (opcional en caso de ya tenerla)Medio: Aprox. 2 sesiones de 3 horas cada unaActividades
Formación básica que incluye:Introducción al Agilismo Kanban y ScrumPlanificación y seguimiento ágil
ResultadoEl equipo adquiere los conocimientos básicos de Agilismo
Plan de implantación
![Page 191: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/191.jpg)
192
FASE 1: Definición del objetivo metodológico y configuración Medio: aprox. 6 reunionesDuración: aprox. 3 semanasActividades
Seleccionar el producto y el equipo de desarrolloEstablecer el objetivo metodológico (conjunto de prácticas ágiles que se aplicarán) que se alcanzará al final de la implantación, dependiente de la situación de partida y las características del contexto (equipo, producto, cliente, entorno de trabajo, etc.)Instalación de TUNE-UP en servidor y configuración inicial asociada al contexto de implantación
Resultado: Entorno preparado para la implantación
… Plan de implantación
![Page 192: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/192.jpg)
193
FASE 2: Formación y puesta en marchaMedio: Seminario organizado en 4 sesiones de 3 horas cada una. Además, 2 o 3 reuniones. (*)Duración: aprox. 4 semanasActividades
Formación del equipo en metodología y herramienta TUNE-UPConsultoría para la puesta en marcha de la primera iteración. Preparación en TUNE-UP del Product Backlog, estructura inicial del producto y de ítems incluidos en el primer Sprint.
Resultado: Puesta en marcha
(*) En caso de aplicar algunas prácticas posterior al inicio de la Fase 3, su correspondiente formación se distribuiría para que siempre se realice justo antes de comenzar a aplicar cada práctica. Esto permitirá aprovechar oportunamente la formación correspondiente a cada práctica y reducir en lo posible la concentración de conocimientos que deben trasmitirse al equipo al comienzo de la implantación.
… Plan de implantación
![Page 193: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/193.jpg)
194
FASE 3: Asistencia y seguimientoMedio: aprox. 12 reuniones (una cada semana)Duración: aprox. 12 semanas (la idea es aplicar la metodología en al menos 3 Sprints de desarrollo)Actividades
Reuniones de seguimiento del desarrollo, incluyendo la planificación y revisión de cada Sprint.Reuniones de evaluación de la metodología de desarrollo al final de cada Sprint (reuniones de retrospectiva).Asistencia respecto del uso de la herramienta y dudas metodológicas.
Resultado: El equipo alcanza el objetivo metodológico establecido.
… Plan de implantación
![Page 194: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/194.jpg)
195
FASE 4: Evaluación y próximos pasosMedio: aprox. 2 reunionesDuración: aprox. 2 semana (una semana solapada con la Fase 3)Actividades
Reuniones para evaluación de la implantación metodológica y futura mejora del proceso
Resultado: Evaluación y recomendaciones para aplicación de otras prácticas ágiles
… Plan de implantación
![Page 195: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/195.jpg)
196
FASE 0: Formación Básica en Agilismo (6 horas)FASE 1: Diagnóstico y configuración (aprox. 3
semanas)FASE 2: Formación y puesta en marcha (aprox. 4
semanas)FASE 3: Asistencia y seguimiento (aprox. 12 semanas)FASE 4: Evaluación y próximos pasos (aprox. 2
semanas)
Tiempo (cronológico) de la implantación: aprox. 20 semanas
Incluye:Aprox. 23 reuniones de aprox. 2 hrs. cada unaFormación básica en Agilismo , 2 sesiones de 3 hrs. Seminario de formación por videoconferencia, de 4 sesiones de 3 hrs. Horas de asistencia respecto del uso de la herramienta y dudas metodológicas
Resumen del plan
![Page 196: Modelos de Procesos de Gestión y Desarrollo de Software](https://reader038.vdocuments.mx/reader038/viewer/2022103000/55721041497959fc0b8ce40c/html5/thumbnails/196.jpg)
¡Gracias por vuestra atención!Patricio Letelier [email protected]
agilismoatwork.blogspot.comwww.tuneupprocess.com
Departamento Sistemas Informáticos y Computación (DSIC)Universidad Politécnica de Valencia (UPV) - España