modelos de procesos de gestión y desarrollo de software
TRANSCRIPT
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
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
3
Introducción al Proceso de Software
5
Contexto
Plazo
Alcance
CostoCalidad
Productividad
6
Ámbitos de mejora en Ingeniería de Software
Herramientas(IDEs, CASE, …)
Proceso(Metodologías)
Notación(Lenguajes)
7
Calidad del Producto Software
ISO/IEC 9126
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!!
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
10
CMMI: Capability Madurity Model
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
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.
13
Configuración de la metodología
Kanban
Scrum
XP
RUP
Ad-hoc Plan
DoCheck
Act
Otras metodologías
Ágiles
14
“Just Enough Process”
… Ni muy poco
… Ni mucho
Modelos de Proceso y Metodologías
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)
17
Proceso Secuencial
P R D C T D
tiempo
Mejor es solapar trabajo ¿no? …
18
Proceso en Cascada (Waterfall)
P
R
D
C
T
D
tiempo
19
Planificación y seguimiento usando Diagramas Gantt
Realismo (el cambio y el retrabajo existe!) Desarrollo incremental
+ “Divide y vencerás”
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 ? …
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? …
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 …
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? …
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? …
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
26
¿Qué es una Metodología?
Una metodología define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo
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.
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.
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.
30
Elementos de una Metodología
ProcesoSW
Notación
HerramientasPersonas
ArtefactosRoles
Actividades
Metodologías Tradicionales Rational Unified Process (RUP)
32
Fases y actividades
33
Fases e Hitos (Milestones)
tiempo
Objetivos(Vision)
Arquitectura CapacidadOperacionalInicial
Releasedel Producto
Inception Elaboration Construction Transition
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)
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)
36
... Elementos en RUP
Workflow (Disciplina), Workflow Detail, Roles, Actividades y Artefactos
Ejemplo Workflow Detail:Analyse the ProblemWorkflow: Requirements
Actividades
Roles Artefactos
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
… ……
38
Características Esenciales de RUP
Proceso Dirigido por los Casos de
Uso
Proceso Iterativo e Incremental
Proceso Centrado en la
Arquitectura
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
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]
41
... Proceso dirigido por los Casos de Uso
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
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
44
… Proceso Iterativo e Incremental
EnfoqueCascada
EnfoqueIterativo eIncremental
45
... Proceso Iterativo e Incremental
Grado de Finalización de Artefactos
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
47
“Cambia el chip”
48
Metodos Ágiles Una ojeada al agilismo
50
Ser Ágil => actuar según el Manifiesto Ágil (2001)
¿cuál es tu interpretación?
agilemanifesto.org
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
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?
53
Costo de los Cambios en SW
Costodel
cambio
tiempo
Tradicional
Suposición MAs
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
55
Tradicional v/s Ágil
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
57
State of Agile Development (Survey 2010) 1 de 3
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
58
State of Agile Development (Survey 2010) 2 de 3
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
59
Los protagonistas
Kanban
Lean Development
Scrum
Extreme Programming
60
¿De qué estamos hablando?
Métodos Ágiles Extreme Programming
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
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
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
65
Boceto de IU para Historia de Usuario
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
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
?
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
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
70
Esquema de proyecto XP
Métodos Ágiles Lean Development
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!
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
74
Auto- discipl
inaShitsuk
e
ClasificarSeiri
OrdenSeiton
Limpieza
Seiso
Estanda-
rización
Seiketsu
Método 5S – Lean Manufacturing
Métodos Ágiles Kanban
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
77
Kanban elemental
To Do Doing Done
A
B
C
D E
F
G
Flujo
78
Kanban elemental
To Do Doing Done
A
B
C
D EF
G
H
Flujo
79
Kanban elemental
To Do Doing Done
A
B
C
D E
F
G
H
I
Flujo
80
Kanban elemental
To Do Doing Done
A
B
C
D
E
F
G
H
I
J
Flujo
81
Kanban elemental
To Do Doing Done
A
B
C
D
E
F
G
H
I
J
Flujo
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)
83
Ilustrando el concepto WIP
MAGDALENA
PATRICIO
ALEJANDRO
FERNANDO
CATALINA
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)
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)
86
Métodos Ágiles Scrum
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
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
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!
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
Métodos Ágiles Scrum + Kanban
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
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).
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
96
97
Scumban manual (de pared)
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.
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.
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.
Métodos Ágiles Teamwork
102
Cross-Functional ySelf-Organizing Team
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?
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
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
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
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
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
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
…
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
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
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
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.
115
¿Manager … Líder …Facilitador?
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?
117
Gemba – Lugar de trabajo
Métodos Ágiles Herramientas para Gestión Ágil
119
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
Herramientas usadas en proyectos ágiles
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
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
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
123
124
Ejemplo workflow simple “estilo tradicional”
125
… un workflow más complejo
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)
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
128
www.tuneupprocess.com
Métodos Ágiles Planificación y el Product Backlog
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!!
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
132
Esfuerzo estimado versus Capacidad
Sprint
Product Backlog
Esfuerzo
estimado
Capacidad
del equipo
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
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
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
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
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?)
138
Más información en: http://bit.ly/tNeyn7
Métodos Ágiles Seguimiento
140
Planificación y seguimiento de proyectos
Introducción
Alcance
Costo Tiempo
Seguimiento ¿lo conseguiremos?
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
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)
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
144
Visualización del estado del Sprint
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
146
Gráficas Burndown 3 de 4
147
Gráficas Burndown 4 de 4
Soporte para gráficas Burndown en herramientas comerciales
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
149
Gestión Ágil de Requisitos
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
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)
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
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)
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
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
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
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
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
161
Gestión del producto SW
Reintegro
WU «adaptación a
nueva normativa»
Requisitos afectados por la WU
Estructura de requisitos
del producto
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
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
Mejora Continua del Proceso
165
Mejora continua
Retrospectivas
Plan
DoCheck
Act
Sprint
166
Adaptar la metodología al producto y refinarla
Kanban
Scrum
XP
RUP
Ad-hoc Plan
Do
Check
Act
Otras metodologías
Ágiles
167
El Know How está contenido en los WFs
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
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
170
Escalando el agilismo
…
Equipos pequeños < 10 miembros
Scrum de ScrumsUn mismo proyecto
con varios equipos
Conclusiones
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
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
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
175
¿To be or not to be Ágil?
“There is an elephant in the room”
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 …
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
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”
179
El rol de las certificaciones en el contexto ágil
180
Su nombre aquí
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?
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
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?
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
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.
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
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
188
Configuración metodológica para un producto
Kanban
Scrum
XP
RUP
Ad-hoc Plan
Do
Check
Act
Otras metodologías
Ágiles
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
…
Un Plan de Implantación de Prácticas Ágiles
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
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
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
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
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
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
¡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