Академический Документы
Профессиональный Документы
Культура Документы
Contenidos
Introduccin al Proceso de Software Modelos de Proceso y Metodologas Metodologas Tradicionales: Rational Unified Process (RUP) Mtodos giles
Una ojeada al agilismo Extreme Programming Lean Development Kanban Scrum Scrum + Kanban
Gestin gil de Requisitos Mejora Continua del Proceso Conclusiones Un Plan de Implantacin de Prcticas giles
2
Contexto
Alcance
Productividad
Plazo Costo
Calidad
ISO/IEC 9126
Modelos y metodologas
Modelos de referencia y estndares
CMMI, ISO 9000-3, SPICE, PMBOK
Metodologas Tradicionales
Rational Unified Process (RUP), Proceso Unificado Mtrica 3
Metodos giles
SCRUM Extreme Programming (XP)
9
10
11
12
Configuracin de la metodologa
Scrum
Otras metodologas giles
XP
Kanban
RUP Ad-hoc
Act Plan
Check
Do
13
Ni mucho
14
16
Proceso Secuencial
tiempo
tiempo
18
Desarrollo incremental
19
Proceso Incremental
tiempo
tiempo
Proceso Incremental
tiempo
Pero cmo planificar sin antes saber lo que hay que hacer?
21
tiempo
Inicio Construccin
tiempo
24
Qu es una Metodologa?
Una metodologa define Quin debe hacer Qu, Cundo y Cmo debe hacerlo
26
27
Metodologas Estructuradas
Los mtodos estructurados comenzaron a desarrollar-se a fines de los 70s con la Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas para el Diseo primero y luego para el Anlisis. Enfocados a implementaciones usando lenguajes de 3ra generacin.
Ejemplos de metodologas estructuradas gubernamentales: MERISE (Francia), MTRICA 3 (Espaa), SSADM (Reino Unido).
Ejemplos de mtodos estructurados en el mbito acadmico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering.
28
29
Roles
30
Metodologas Tradicionales
Fases y actividades
32
Inception
Elaboration
Construction
Transition
Objetivos (Vision)
Arquitectura
tiempo
33
release
(producto al final de una iteracin)
base line
(release asociada a un hito)
generacin
(release final de un ciclo de desarrollo)
34
Elementos en RUP
Workflows (Disciplinas)
Workflows Primarios
Business Modeling (Modado del Negocio) Requirements (Requisitos) Analysis & Design (Anlisis y Diseo) Implementation (Implementacin) Test (Pruebas) Deployment (Despliegue) Environment (Entorno) Project Management (Gestin del Proyecto) Configuration & Change Management (Gestin de Configuracin y Cambios)
35
Workflows de Apoyo
Ejemplo
Workflow: Requirements Workflow Detail:Analyse the Problem
Roles Actividades
Artefactos
36
Developer
Testing professional
Manager
Test Designer Tester Change Control Manager Configuration Manager Deployment Manager Process Engineer Project Manager Project Reviewer Course Developer Graphic Artist Stakeholder System Administrator Technical Writer Tool Specialist
Other
37
38
Requisitos
Realizar los casos de uso Verificar que se satisfacen los casos de uso
Pruebas
39
trace
Realizacin de Diseo
Realizacin de Anlisis
trace
X
Caso de Prueba
[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]
40
41
42
43
44
45
Inception
Elaboration
Construction
Transition
Architecture
46
Cambia el chip
47
48
Metodos giles
cul es tu interpretacin?
agilemanifesto.org
50
51
52
Suposicin MAs
tiempo
53
54
55
Metodologa Tradicional
Aplicables a proyectos de cualquier tamao, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos. Posibles problemas de adaptabilidad a proyectos pequeos Ms Artefactos. El modelado es esencial, mantenimiento de modelos Ms Roles, ms especficos Suele tenerse un contrato cerrado en cuanto a Alcance, Recursos y Plazo. El cliente interacta con el equipo de desarrollo mediante reuniones programadas
56
1 de 3
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
57
2 de 3
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
58
Los protagonistas
Extreme Programming
Kanban
59
De qu estamos hablando?
60
Mtodos giles
Extreme Programming
Historia de XP
Creado por Kent Beck para la plantilla del proyecto C3 en Chrysler
Kent Beck fue contratado para dirigir el proyecto Durante el proceso naci una nueva metodologa: eXtreme Programming (XP) C3 concluy exitosamente en 1997
62
Plantilla sugerida por Mike Cohn Como <tipo de usuario>, quiero <algn objetivo> para as <alguna razn>. Ejemplo: Como usuario del procesador de textos, quiero seleccionar una palabra y especificar que sea itlica, para as poder aadir nfasis a mi escritura William Wake, caractersticas deseables de una HU INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable Ron Jeffries propone Card, Conversation, Confirmation CardLa tarjeta de historia es slo un ttulo (su nombre) ConversationLos desarrolladores deben preguntar para aclararla. Los representantes del negocio deben preguntar para confirmar que han sido comprendidos. ConfirmationCmo se puede saber si se ha cumplido la historia? Expresar ejemplos concretos y transformar dichos ejemplos en pruebas de aceptacin
63
Historia de Usuario
Usuario: Autor Importancia: Muy Alta Riesgo: Medio Descripcin: Se introducen los datos del artculo (ttulo, fichero adjunto, resumen, tpicos) y de los autores (nombre, e-mail, afiliacin). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepcin del artculo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artculo. Nombre: Enviar artculo Urgencia: Media Esfuerzo Estimado: 4
64
65
Fase de Exploracin
?
Prioridad Historias de Usuario
Definir Historias de Usuario Estimar Esfuerzo y Riesgo Identificar Escenarios/ Pruebas de Aceptacin
Elaborar Spikes
Spikes (Prototipos)
67
Segunda Iteracin
N-sima Iteracin
ltima Iteracin
2a3 semanas
Fase de Construccin
Historias de la Iteracin
Esquema de proyecto XP
70
Mtodos giles
Lean Development
Sistemas de Produccin
Toyota Production Poka-yoke System JIT Kaizen Kanban Pull Systems Lean Manufactoring
73
Seiri
Estandarizacin
Autodisciplina
Orden
Seiketsu
Shitsuke
Seiton
Limpieza
Seiso
74
Mtodos giles
Kanban
Kanban elemental
To Do
A B
Doing
Done
C
D E F G
Kaizen
Pull Systems
Just-In-Time
Lean Manufacturing
Eliminar el waste
76
Kanban elemental
To Do
A D F G
Doing
C E B
Done
Flujo
77
Kanban elemental
To Do
A D H G F B
Doing
C
Done
Flujo
78
Kanban elemental
To Do Doing
A I H G D B F
Done
C E
Flujo
79
Kanban elemental
To Do
J I H
Doing
A G B
Done
C E F
Flujo
80
Kanban elemental
To Do
J I
Doing
H G B
Done
C E F A
Flujo
81
Kanban elemental
To Do
K L I J
Doing
G
Done
C H A G D B
E F
Visibilidad del estado del trabajo Conseguir un flujo de produccin Pull Limitar el WIP (Work in Progress)
82
Un Kanban manual (de pared) es un excelente medio para motivar al equipo durante la introduccin del agilismo pero a medio y largo plazo no es una forma de trabajo sostenible, debera ser soportado por una herramienta
84
Puede resultar difcil la gestin de un Kanban en slo un nivel (el de requisitos), mucho ms complicado ser gestionar y sincronizar Kanban en diferentes niveles de abstaccin (en este caso Caractersticas y Tareas)
85
86
Mtodos giles
Scrum
Introduccin 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 Principios Transparencia Inspeccin Adaptacin
88
(Sprint/Release) Burndown
89
Scrum Core
Sprint Planning Meeting 8 hrs.
Capacidad!
A C E D H I F G B
A1
A3
A2
A4
A5
Sprint Goal
G1 F1 G2 F3 F2 F4 No ms de 4 semanas
Product Backlog
(lista ordenada)
Sprint
DONE
90
Implementacin en el sprint
Sprinti-2
Sprinti-1
Tiempo
Sprinti
91
Mtodos giles
Scrum + Kanban
To Do
A B G F
Doing
Done
C E D H I J Product Backlog
No ms de 4 semanas
93
D
Definicin. Especificacin del cambio de comporta-miento en el sistema (desde la perspectiva del usuario)
T
Testeo de Aceptacin. Aplicacin de Pruebas de Aceptacin para verificar la correcta implementacin del cambio
94
Sprint Backlog
Implementar
To Do E Doing G F
Testear
Done To Do C B Doing A
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
95
96
97
1 de 2
1. 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. Obstculo 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 informacin asociada a un tem. 4. El desarrollador encargado de un tem no lo debera coger desde el Scrumban para llevrselo a su puesto de trabajo pues el resto del equipo no visualizara dicho tem. 5. En caso de trabajar con varios productos a la vez, se tendra que mantener un Scrumban por cada producto.
98
1 de 2
6. Qu se hace con los tems de sprints pasados?, por defecto se desecharan todos los post-it una vez terminado el sprint. 7. Normalmente la finalizacin de un sprint se solapar al menos para algunos miembros del equipo con el trabajo del siguiente sprint. Esta situacin obligara a tener un Scrumban son dos sprints, uno para la versin 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 slo se puede dar vuelta atrs 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 atrs el tem. En el caso de adelantar trabajo de una actividad sucede algo similar.
99
1 de 2
10. Cada producto, tipo de tem o incluso tem podran requerir unas actividades especficas. Un Scrumban de pared establece un tratamiento igual para todos los tems. 11. No es sencillo llevar la contabilizacin de estimaciones, esfuerzo restante, y ello a nivel de precisin de actividades. 12. Todo el registro asociado a los fallos y defectos detectados, o respecto al histrico asociado al tem no suele considerarse. 13. Reordenamiento de los tems en el Product Backlog 14. Difcil 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 gestin del Kanban.
100
Mtodos giles
Teamwork
102
103
Manager
Cliente Coach
unos pocos ms
Product Owner
Scrum Master
Development Team
Analista
Programador
104
letelier@dsic.upv.es
105
Roles de Scrum
Roles Scrum El Product Owner (PO) es responsable de gestionar el Product Backlog, lo cual incluye: Expresar claramente los items del Product Backlog Ordenar los items del Product Backlog para conseguir objetivos y misin del producto Asegurar el valor del trabajo que realiza el Development Team Asegurar que el Product Backlog es visible, transparente, y claro para todos, y mostrar en qu es lo que trabajar prximamente el Scrum Team Asegurar que el Development Team entiende los items en el Product Backlog
Product Owner
Scrum Master
Development Team
El PO debe hacer respetar sus decisiones en la organizacin y proteger al Development Team de las solicitudes o influencias de los stakeholders
1de 2
El Scrum Master (SM) es responsable de asegurar que Scrum es entendido y aplicado. El SM es un sirviente-lder para el Scrum Team. Servicios del Scrum Master para el Product Owner: Ensear tcnicas para la gestin efectiva del Product Backlog Ayudar a comunicar claramente la visin, objetivos e tems del Product Backlog al Development Team Ensear al Scrum Team a crear claros y concisos tems del Product Backlog Ayudar a comprender la planificacin a largo plazo en un ambiente emprico Ayudar a comprender y aplicar agilidad Apoyar durante el sprint y las reuniones segn se le requiera o sea necesario
Product Owner
Scrum Master
Development Team
2 de 2
Product Owner
Scrum Master
Development Team
Product Owner
Scrum Master
Development Team
Es self-organizing. Nadie (ni siquiera el Scrum Master) le dice como convertir el Product Backlog en un incrementos de funcionalidad potencialmente entregable Es cross-functional, tiene como equipo todas las habilidades necesarias para crear un incremento del producto No tiene ttulos ms que el de Developer, independiente del trabajo que est realizando la persona, no hay excepciones a esta regla Los miembros pueden tener habilidades y reas de especializacin pero ellas cuentan para el Development Team como un todo No contienen sub-teams dedicados a dominios particulares como testeo o anlisis de negocio Tiene entre 3 y 9 miembros (obviamente sin contar el PO y SM)
Cliente
Jefe de proyecto
Product Owner
Analista
Scrum Master
110
Otras Actividades
Sean expertos en todas las actividades Realicen siempre las mismas actividades Realicen juntos todas las actividades de cada tem Realicen cada uno una actividad de cada tem Realicen 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 inters por tener en un equipo personas con roles fijos especficos depender del grado de especializacin disponible/deseado y del nmero de miembros del equipo
111
T
Tester
Scrum en lugar de utilizar roles especficos tiene slo Development Team como rol genrico desempeado por todos los desarrolladores
112
En un mismo Sprint cada tem podra tener una estrategia diferente en cuanto a roles-agentes
tem1
D
tem4
tem7
Mabel
P
Carlos
P
Mara Mara
P
Carlos
tem2
D P
tem5
tem8
Javier Marta Mara Carlos
P
Mara Carlos
P
T
Javier
Mabel
Carlos
Mara
Mabel
tem3
Mara
D P T
Carlos Marta
tem6
Mara
D P T
Carlos Javier
tem9
D P T
Todo el Team
113
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 cmo realizar el trabajo. Toman las decisiones tcnicas necesarias. Comparten un rol genrico, p.e. Desarrollador. No existe el rol Jefe, o si existe es ms bien un facilitador, el cual no interviene en la asignacin de trabajo ni en cmo debe hacerse el trabajo.
114
115
117
Mtodos giles
http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
119
Lista ordenada de prximas WUs (en constante cambio). Requisitos definidos en gran parte antes de que a WU se incluya en una iteracin
121
122
123
124
un workflow ms complejo
125
Kanban de TUNE-UP
Filtro agente Filtro producto y versin
Actividades en las que puede estar una WU. Corresponde a la sntesis De todo el trabajo en el que participa el agente, segn los WFs de cada una de las WUs.
126
TUNE-UP Kanban
Agentes responsables
127
www.tuneupprocess.com
128
Mtodos giles
Sprint visto por Cliente (tems correspondientes a caractersticas externas del producto)
Sprint visto por equipo de desarrollo (incluye tems de trabajo en capas internas)
Arquitectura en capas
Product Backlog
Esfuerzo estimado
Sprint
132
SprintX
Sprintx+1
Sprintx+2
Product Backlog
Release
133
Gestin de Fallos
134
135
1p
2p 30h
5p 45h
8h
12h
10h
136
Planning Poker
8 2
2 5
Utiliza Puntos como medida de esfuerzo. Es una medida de tamao relativa. Se corresponde con una velocidad de proyecto tambin expresada en Puntos. No til para seguimiento (cuntos puntos restan de trabajo en una tem?)
137
138
Mtodos giles
Seguimiento
Introduccin
Planificacin y seguimiento de proyectos
Alcance
Costo Seguimiento
Tiempo
lo conseguiremos?
140
Introduccin
Qu indicadores utilizar para realizar el seguimiento?
utilizar
Estimar el esfuerzo Computar el avance Conocer disponibilidad futura Conocer productividad Velocidad de proyecto (VP) o Capacidad del equipo
141
Introduccin
Seguimiento del proyecto cuando se usa un enfoque gil
Proceso iterativo e incremental con entregas frecuentes Seguimiento muy continuo (da a da, en cada Stand Up Meeting / Daily Scrum) Se esperan cambios Complicidad del cliente (involucrado y negociador) Podra relajarse el seguimiento del proyecto? Depende , S, si existen las condiciones de flexibilidad y negociacin ideales para el enfoque gil. Sin embargo, siempre el seguimiento es til para detectar oportunamente desviaciones significativas y tambin para obtener informacin necesaria para una retrospectiva
142
Grficas Burndown
1 de 4
Grficas Burndown protagonistas en Scrum para el seguimiento de las sprints y releases, pero Por lo visto son muy poco usadas en la prctica. Posibles razones:
Disciplina individual de estimacin y registro de avance Esfuerzo para recoleccin y sntesis de los datos Dificultades para su interpretacin
143
144
Para recolectar la informacin necesaria para el seguimiento diario es importante conectar dicha recoleccin con el trabajo diario de los participantes
145
Grficas Burndown
3 de 4
146
Grficas Burndown
4 de 4
147
148
149
Pruebas de Aceptacin
Pruebas de Sistema Pruebas de Integracin Pruebas Unitarias
Anlisis
Programaci n
Aplicacin de Pruebas
151
Versini+1 Nuevo requisito Expresados en trminos Mejora de Pruebas de Aceptacin Correccin de defecto
152
Diagramas de Secuencia
Pero
Descripcin narrativa
Casos de Uso
Bocetos de IU
153
Modelo de Requisitos bueno, de acuerdo!, podran Plantillas de Casos de Uso utilizarse Casos de Uso y otros diagramas de UML Bocetos de IU
154
ATEST 1.1: Obligatorio Ttulo, al menos un tpico asociado, al menos un autor y fichero adjunto. ATEST 1.2: Ttulo de artculo no repetido con autores coincidentes ATEST 1.3: Primer autor marcado por defecto como contacto ATEST 1.4: Autores no repetidos en un mismo artculo ATEST 1.5: Tamao del artculo no superior a 5 Mb
155
156
157
Ejemplo de PA
Intento de reintegro con saldo insuficiente Condicin Cliente con saldo positivo Acceder a ventana de reintegro Pasos Introducir cantidad mayor que el saldo Resultado esperado Mensaje saldo insuficiente Se ofrece nueva introduccin
Resultado esperado
-----
-----
158
159
161
WUs
Definen WUs en trminos de PAs
162
TDRE se enmarca en la gestin integral del producto, no slo en su desarrollo inicial sino tambin en su posterior mantenimiento
Facilita la especificacin y validacin de los requisitos Apoya la estimacin del esfuerzo de desarrollo Son un instrumento adecuado para Negociar con el cliente Su ordenamiento facilita el trabajo de programadores y testers Contribuyen a una mejor especificacin de los requisitos. Respecto del estndar IEEE 830, se mejora en cuanto a verificabilidad, mantenibilidad, no ambigedad, trazabilidad, etc.
163
Retrospectivas
165
XP
Kanban
RUP Ad-hoc
Act Plan
Check
Do
166
167
168
169
Escalando el agilismo
Un mismo proyecto con varios equipos Scrum de Scrums
Conclusiones
Costo
Expectativas Realistas
Tiempo
Satisfaccin del cliente. Involucrar al Cliente. Mejora en la gestin de prioridades Adelgazar el proceso. Eliminar el Waste. Lean Development Detectar oportunamente situaciones que afectan negativamente al proyecto Establecer un ritmo de trabajo sostenible-realista Mantener al equipo motivado y comprometido
172
?
Tcnicas y Herramientas Tradicionales PMBOK PMO
RUP
PMOs
(trabajando en un producto/proyecto)
Equipo de trabajo
174
To be or not to be gil?
To be or not to be gil?
Agile's Teenage Crisis? Philippe Kruchten . Enumeracin de los elefantes.
infoq.com/articles/agile-teenage-crisis
Post-Agilismo
176
177
Flaccid Scrum
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 werent able to create a potentially shippable increment of functionality within a single Sprint. [Ken Schwaber, Scrum.org]
178
179
Su nombre aqu
180
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.
181
3 de 3
Carencia de cliente in-situ Contrato poco flexible Equipo numeroso y/o disperso Entorno de trabajo inapropiado
183
Modelo de proceso en cascada Planificacin y seguimiento con Diagramas Gantt Entregas NO frecuentes Gestin de Requisitos clsica Jefe autoritario Muchos roles Asociacin fija de roles-agentes Contrato y plan no flexibles Relacin ms distante con cliente nfasis en modelado y especificacin
cmo evolucionar?
Modelo de proceso iterativo e incremental Planificacin por iteraciones Entregas frecuentes (alrededor de un mes) Seguimiento continuo (Sprint Burndown) Gestin del Product Backlog (trabajo pendiente) Especificacin gil de Requisitos y Pruebas de Aceptacin Jefe facilitador, lder. Equipo auto-organizado Roles genricos No se asignan roles especficos 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) Refactorizacin (mejora continua de arquitectura) Integracin continua Estndares de programacin Programacin en parejas Propiedad colectiva
184
185
Reflexiones adicionales
Conjugar: Metodologa + Herramienta + Contextualizacin (cliente, equipo, dominio de aplicacin, proyecto, tecnologa, etc.) Un sistema complejo que funciona es la evolucin de uno ms simple que funcionaba ir paso a paso en la mejora del proceso. El mantenimiento existe. Todo producto exitoso requerir mantenimiento. Gestionar el producto
186
Reflexiones adicionales
Mejorar la productividad del equipo a partir de la mejora en la productividad de sus miembros Disciplina y hbitos individuales de trabajo
187
XP
Kanban
RUP Ad-hoc
Act Plan
Check
Do
188
Qu es TUNE-UP?
Plan de implantacin
FASE 0: Formacin Bsica en Agilismo (opcional en caso de ya tenerla)
Medio: Aprox. 2 sesiones de 3 horas cada una Actividades Formacin bsica que incluye: Introduccin al Agilismo Kanban y Scrum Planificacin y seguimiento gil Resultado El equipo adquiere los conocimientos bsicos de Agilismo
191
Plan de implantacin
FASE 1: Definicin del objetivo metodolgico y configuracin
Medio: aprox. 6 reuniones Duracin: aprox. 3 semanas Actividades Seleccionar el producto y el equipo de desarrollo Establecer el objetivo metodolgico (conjunto de prcticas giles que se aplicarn) que se alcanzar al final de la implantacin, dependiente de la situacin de partida y las caractersticas del contexto (equipo, producto, cliente, entorno de trabajo, etc.) Instalacin de TUNE-UP en servidor y configuracin inicial asociada al contexto de implantacin Resultado: Entorno preparado para la implantacin
192
Plan de implantacin
FASE 2: Formacin y puesta en marcha
Medio: Seminario organizado en 4 sesiones de 3 horas cada una. Adems, 2 o 3 reuniones. (*) Duracin: aprox. 4 semanas Actividades Formacin del equipo en metodologa y herramienta TUNE-UP Consultora para la puesta en marcha de la primera iteracin. Preparacin 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 prcticas posterior al inicio de la Fase 3, su correspondiente formacin se distribuira para que siempre se realice justo antes de comenzar a aplicar cada prctica. Esto permitir aprovechar oportunamente la formacin correspondiente a cada prctica y reducir en lo posible la concentracin de conocimientos que deben trasmitirse al equipo al comienzo de la implantacin.
193
Plan de implantacin
FASE 3: Asistencia y seguimiento Medio: aprox. 12 reuniones (una cada semana) Duracin: aprox. 12 semanas (la idea es aplicar la metodologa en al menos 3 Sprints de desarrollo) Actividades
Reuniones de seguimiento del desarrollo, incluyendo la planificacin y revisin de cada Sprint. Reuniones de evaluacin de la metodologa de desarrollo al final de cada Sprint (reuniones de retrospectiva). Asistencia respecto del uso de la herramienta y dudas metodolgicas.
194
Plan de implantacin
FASE 4: Evaluacin y prximos pasos Medio: aprox. 2 reuniones Duracin: aprox. 2 semana (una semana solapada con la Fase 3) Actividades
Reuniones para evaluacin de la implantacin metodolgica y futura mejora del proceso
195