Modelos de Procesos de Gestin y Desarrollo de Software

Patricio Letelier Torres letelier@dsic.upv.es agilismoatwork.blogspot.com www.tuneupprocess.com

Departamento Sistemas Informticos y Computacin (DSIC) Universidad Politcnica de Valencia (UPV) - Espaa

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

Teamwork Herramientas para Gestin gil Planificacin y el Product Backlog Seguimiento

Gestin gil de Requisitos Mejora Continua del Proceso Conclusiones Un Plan de Implantacin de Prcticas giles
2

Introduccin al Proceso de Software

Contexto

Alcance

Productividad
Plazo Costo

Calidad

mbitos de mejora en Ingeniera de Software

Calidad del Producto Software

ISO/IEC 9126

FAQs podemos responderlas ?cunto nos cuesta?

En qu tareas estoy participando y en qu estado estn? Qu trabajo es el que debera hacer en este momento? Tengo pendiente alguna interaccin/comunicacin con otros participantes? Cumpliremos con los plazos de entrega? Quin podra encargarse de una nueva tarea? Cul 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? Cul es la funcionalidad actual del producto y cmo ha evolucionado? Cunto esfuerzo se ha invertido en un cambio? Cmo se ha distribuido dicho esfuerzo en actividades o agentes? Cunto re-trabajo se ha producido? Quin, cundo y qu se decidi respecto de un cambio? Qu eventos han afectado nuestro trabajo?
8

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

CMMI: Capability Madurity Model

10

Tiempo de implantacin de niveles CMMI

Nivel 1 a 2 5 meses Nivel 2 a 3 19 meses Nivel 3 a 4 25 meses Nivel 3 a 5 23 meses

Jornadas Proceso Software 24-Noviembre-2010

11

Adaptar la metodologa al contexto

No existe una metodologa de software universal. Las caractersticas de cada producto/proyecto/equipo exigen que el proceso sea configurable y adaptable.

12

Configuracin de la metodologa
Scrum
Otras metodologas giles

XP

Kanban

RUP Ad-hoc
Act Plan

Check

Do
13

Just Enough Process

Ni muy poco

Ni mucho

14

Modelos de Proceso y Metodologas

Definiendo nuestro modelo de proceso

Planificacin
Requisitos Arquitectura & Diseo Codificacin (Programacin) Testing Despliegue (Deployment) tiempo

16

Proceso Secuencial

tiempo

Mejor es solapar trabajo no?

17

Proceso en Cascada (Waterfall)

tiempo

18

Planificacin y seguimiento usando Diagramas Gantt

Realismo (el cambio y el retrabajo existe!) + Divide y vencers

Desarrollo incremental
19

Proceso Incremental

tiempo

tiempo

No es mejor hacer todo incremental ?

20

 Proceso Incremental

tiempo

Pero cmo planificar sin antes saber lo que hay que hacer?
21

Proceso Incremental con fase de exploracin

tiempo

Validacin frecuente Desarrollo Iterativo

22

Proceso Iterativo e Incremental

= Unidad de Trabajo (Work Unit)

y con pruebas de regresin entre iteraciones?

23

Inicio Construccin

Fin 1era Iteracin

Fin 2da Iteracin

Fin 3ra Iteracin (Entrega)

tiempo

24

Modelos de Proceso y Metodologas

Aportan el carcter de disciplina a la Ingeniera de Software Un modelo de proceso de software es una estrategia global respecto de cmo abordar un proyecto de desarrollo de software Modelos de proceso de software: Codificar y corregir (code-and-fix) Desarrollo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo basado en reutilizacin Desarrollo incremental Desarrollo en espiral
25

Qu es una Metodologa?
Una metodologa define Quin debe hacer Qu, Cundo y Cmo debe hacerlo

26

 Modelos de Proceso y Metodologas

Las metodologas se basan en alguna combinacin de modelos de proceso.
Desde la perspectiva de las tcnicas utilizadas para las actividades de anlisis, diseo e implementacin las metodologas pueden ser clasificadas como: Metodologas Estructuradas o Metodologas Orientadas a Objetos. Desde la perspectiva de las prcticas utilizadas las metodologas pueden ser clasificadas como: Metodologas Tradicionales o Metodologas giles.

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

Metodologas Orientadas a Objetos (OO)

Su historia va unida a la evolucin de los lenguajes de programacin orientada a objeto. En los 60s SIMULA, en los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y actualmente Java, C# y otros. A fines de los 80s comenzaron a consolidarse algunos mtodos Orientadas a Objeto. En 1995 aparece el Mtodo Unificado, que posteriormente se reorienta para dar lugar al Unified Modeling Language (UML), la notacin OO ms popular en la actualidad. Mtodos OO con notaciones predecesoras de UML: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Metodologas orientadas a objetos basadas en UML: Rational Unified Process (RUP), OPEN, MTRICA 3.

29

Elementos de una Metodologa

Actividades Personas Herramientas

Proceso SW Artefactos Notacin

Roles

30

Metodologas Tradicionales

Rational Unified Process (RUP)

Fases y actividades

32

Fases e Hitos (Milestones)

Inception

Elaboration

Construction

Transition

Objetivos (Vision)

Arquitectura

Capacidad Operacional Inicial

Release del Producto

tiempo

33

Release, Base Line, Generacin

ciclo de desarrollo ciclo de evolucin

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

... Elementos en RUP

Workflow (Disciplina), Workflow Detail, Roles, Actividades y Artefactos

Ejemplo
Workflow: Requirements Workflow Detail:Analyse the Problem

Roles Actividades

Artefactos
36

Roles, Artefactos y Actividades de RUP

Analyst
Business-Process Analyst Business Designer Business-Model Reviewer Requirements Reviewer System Analyst Use-Case Specifier User-Interface Designer Architect Architecture Reviewer Capsule Designer Code Reviewer Database Designer Design Reviewer Designer Implementer Integrator

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

Caractersticas Esenciales de RUP

Proceso Dirigido por los Casos de Uso

Proceso Iterativo e Incremental

Proceso Centrado en la Arquitectura

38

Proceso dirigido por los Casos de Uso

Capturar, definir y validar los casos de uso
Casos de Uso integran el trabajo

Requisitos

Anlisis & Diseo

Implementacin

Realizar los casos de uso Verificar que se satisfacen los casos de uso

Pruebas

39

... Proceso dirigido por los Casos de Uso

trace
Caso de Uso

trace
Realizacin de Diseo

Realizacin de Anlisis

trace

trace Pruebas Unitarias Pruebas Funcionales

X
Caso de Prueba

[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

40

... Proceso dirigido por los Casos de Uso

41

Proceso Iterativo e Incremental

El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes

42

... Proceso Iterativo e Incremental

Para cada Caso de Uso implementado en la iteracin, sus actividades se encadenan en una mini-cascada
Anlisis & Diseo Programacin Pruebas

43

 Proceso Iterativo e Incremental

Enfoque Cascada

Enfoque Iterativo e Incremental

44

... Proceso Iterativo e Incremental

Grado de Finalizacin de Artefactos

45

Proceso Centrado en la Arquitectura

Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes
Un arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo

Inception

Elaboration

Construction

Transition

Architecture
46

Cambia el chip

47

48

Metodos giles

Una ojeada al agilismo

Ser gil => actuar segn el Manifiesto gil (2001)

cul es tu interpretacin?

agilemanifesto.org
50

12 Principios del Manifiesto gil

Nuestra ms alta prioridad es satisfacer al cliente a travs de entrega de software temprana y continua. Bienvenidos los cambios en los requisito, incluso tardamente 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 perodos de un par de semanas a un par de meses, con preferencia de los perodos ms 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 mtodo ms eficiente y efectivo para transmitir informacin hacia y dentro de un equipo de desarrollo es la conversacin caraa-cara. Software funcionando es la medida principal de avance. Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores, y usuarios deberan ser capaces de mantener una paz constante indefinida. La atencin continua a la excelencia tcnica y el buen diseo mejora la agilidad. Simplicidadel arte de maximizar la cantidad de trabajo NO hecho es esencial. La mejores arquitecturas, requisitos, y diseos emergen desde equipos auto-organizados. A intervalos regulares, el equipo reflexiona acerca de cmo llegar a ser ms efectivo, entonces afina y ajusta su comportamiento segn esto.

51

Por qu surgen las metodologas giles?

Dificultades para implantar metodologas tradicionales. Procesos ceremoniosos, herramientas y notaciones de modelado sofisticadas (UML) El enfoque gil es una solucin a medida para un segmento importante de proyectos de desarrollo de software Aceptar el cambio ... Pugna entre comunidades/gurs Business

52

Costo de los Cambios en SW

Tradicional
Costo del cambio

Suposicin MAs
tiempo
53

The Hard Choices Game

Technical debt (deuda tcnica) Condiciones cambiantes e impedimentos Estrategia individual y colectiva La solucin ms ambiciosa siempre requiere algn sacrificio. Hay que optimizar el resultado (comportamiento ofrecido por el producto) en trminos de los plazos y los recursos.

54

Tradicional v/s gil

55

Caractersticas giles v/s Tradicionales

Metodologa gil
Orientada a proyectos pequeos. Corta duracin (o entregas frecuentes), equipos pequeos (< 10 integrantes) y trabajando en el mismo sitio. Posibles problemas de escalabilidad en proyectos grandes Pocos Artefactos. El modelado es prescindible, modelos desechables. Pocos Roles, ms genricos Requiere una relacin contractual que se adapte a cambios en Alcance, Recursos y/o Plazos Cliente es parte del equipo de desarrollo (adems in-situ)

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

La arquitectura se va definiendo y mejorando a lo largo del proyecto

nfasis en los aspectos humanos: el individuo y el trabajo en equipo Se esperan cambios durante el proyecto

Se promueve que la arquitectura se defina tempranamente en el proyecto

nfasis en la definicin del proceso: roles, actividades y artefactos Se espera que no ocurran cambios de gran impacto durante el proyecto

56

State of Agile Development (Survey 2010)

1 de 3

http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
57

State of Agile Development (Survey 2010)

2 de 3

http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
58

Los protagonistas

Extreme Programming

Scrum Lean Development

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

tem Historia de Usuario

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

Boceto de IU para Historia de Usuario

65

Prcticas, Roles y Artefactos de XP

Juego de la planificacin Entregas pequeas/frecuentes Metfora Diseo simple Pruebas Refactoring Programacin en parejas Propiedad colectiva Integracin continua Semana de 40 horas Cliente in situ Estndares de programacin
Stand-up Meeting Roles Cliente Manager (Big Boss) Coach Programador Tester (Pruebas de Aceptacin) Tracker Historias de Usuario Tareas de Programacin Pruebas de Aceptacin Plan de la Release
66

Fase de Exploracin
?
Prioridad Historias de Usuario

Riesgo Esfuerzo (puntos)

Definir Historias de Usuario Estimar Esfuerzo y Riesgo Identificar Escenarios/ Pruebas de Aceptacin

Elaborar Spikes

Spikes (Prototipos)
67

Fase de Planificacin de la Entrega

Velocidad de Proyecto (VP) puntos/semana Historias de Usuario Primera Iteracin

Segunda Iteracin

N-sima Iteracin

ltima Iteracin

Historias fuera de la entrega

2a3 semanas

Entrega <= 3 meses

68

Fase de Construccin

Trabajo durante una iteracin

Historias de la Iteracin

Tareas de Historias de la iteracin

Pruebas de Aceptacin Programacin en Parejas

Diseo Refactoring Programacin Pruebas Unitarias Integracin Pruebas de Integracin Pruebas de Aceptacin
69

Validacin continua por el cliente

Versin del Producto

Esquema de proyecto XP

70

Mtodos giles

Lean Development

Impulso Lean Manufactoring al Agilismo

Desarrollo gil de Software
Manifiesto gil Extreme Programming Scrum Otros mtodos giles

Sistemas de Produccin
Toyota Production Poka-yoke System JIT Kaizen Kanban Pull Systems Lean Manufactoring

Cuidado con las extrapolaciones en el contexto de produccin de software!

72

7 Mudas (Wastes) Lean Manufacturing

Sobre-produccin Producir mucho o con demasiada antelacin
Movimientos Cualquier movimiento que no aada valor

Transporte Cualquier transporte no esencial es desperdicio

Inventario Cualquier cantidad por encima del mnimo necesario Esperas Por una pieza , documento, etc., Tiempo sin actividad del personal.

Retrabajo Cualquier repeticin de trabajo

Sobre-proceso Trabajo o servicio adicional no percibido por el cliente

73

Mtodo 5S Lean Manufacturing

Clasificar

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

Toyota Production System

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

Ilustrando el concepto WIP

MAGDALENA PATRICIO ALEJANDRO FERNANDO

CATALINA
83

Ejemplos de Kanban (decenas de ejemplos en http://vimeo.com/16918299)

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

Kanban por niveles

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

Prcticas, Roles y Artefactos de Scrum

Reuniones Sprint Planning Meeting Daily Scrum Sprint Review Meeting Sprint Retrospective Roles Scrum Master Product Owner Development Team (3-9 miembros) Product Backlog Sprint Backlog Item (del Backlog) Unidad (del Sprint Backlog)

Release Planning Meeting

Equipo self-organizing y cross-functional

(Sprint/Release) Burndown
89

Scrum Core
Sprint Planning Meeting 8 hrs.

(Scrum Guide, julio 2010)

tems seleccionados desde el Product Backlog

Daily Scrum 15 min.

Time-box Sprint Backlog

Units
(de menos de un da de trabajo)

Sprint Review Meeting 4 hrs.

Sprint Retrospective Meeting 3 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

Software Factory Ideal

Introducir nuevos tems Ordenar tems Product Backlog grooming continuo Dividir tems que lo requieran Definir tems Estimar tems Introducir nuevas tems Ordenar tems Dividir tems que lo requieran Definir tems Estimar tems Introducir nuevas tems Ordenar tems Dividir tems que lo requieran Definir tems Estimar tems

Implementacin en el sprint

Implementar tems Testear tems

Implementar tems Testear tems

Implementar tems Testear tems

Sprinti-2

Sprinti-1
Tiempo

Sprinti

91

Mtodos giles

Scrum + Kanban

Scrum + Kanban elemental

Sprint
Sprint Planning Meeting

To Do
A B G F

Doing

Done

C E D H I J Product Backlog

No ms de 4 semanas

93

Actividades esenciales asociadas a un tem

tem de cambio constatable externamente en el producto: Nuevo Requisito Mejora en un requisito existente Correccin de un Fallo. Las actividades esenciales que debe realizar el equipo con estos tems son: Definicin (D), Programacin (P) y Testeo de Aceptacin (T).

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

Programacin. Implementacin del cambio de comportamiento en el producto

94

Scrumban = Kanban + Scrum con actividades especficas

Product Backlog
Definir
To Do Doing Done I G J D F H
Todas los tems que estn en actividades asociadas a la preparacin antes de ponerlos en un Sprint. La columna Done es una lista ordenada, en ella los tem estaran ya estimados

Sprint Planning Meeting

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

Scumban manual (de pared)

97

Debilidades de un Scrumban manual

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

Debilidades de un Scrumban manual

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

Debilidades de un Scrumban manual

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

Cross-Functional y Self-Organizing Team

102

Cross-Functional Team - Definicin

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 functions 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 Cmo se interpreta y se pone en prctica?

103

Roles giles y Tradicionales

Roles en XP
Roles en Scrum

Manager
Cliente Coach

Programador Tester (Pruebas de Aceptacin)

unos pocos ms

Product Owner

Scrum Master

Development Team

Roles en metodologas ms tradicionales (p.e. RUP)

Muchos ms
Cliente Jefe de proyecto

Analista

Programador

Tester (Pruebas de Aceptacin)

104

Una analoga un tanto molesta

Separacin entre comprometidos e involucrados

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

Scrum Guide, julio 2010

106

Roles de Scrum Scrum Master

Roles Scrum

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

Scrum Guide, julio 2010

107

Roles de Scrum Scrum Master

Roles Scrum

2 de 2

Servicios del Scrum Master Service para el Development Team

Entrenar en self-organization y cross-functionality Ensear y dirigirle hacia la creacin de productos de alto valor Eliminar los impedimentos para su avance en el trabajo Apoyar en sprint y reuniones cuando se le pida o lo considere necesario Entrenar para enfrentar ambientes organizacionales en los cuales Scrum an no ha sido completamente adoptado y entendido

Product Owner

Scrum Master

Servicios del Scrum Master para la Organization

Liderar y entrenar la adopcin de Scrum en la organizacin Planificar implementaciones de Scrum dentro de la organizacin Ayudar a los empleados y usuarios a comprender e implantar Scrum y el desarrollo emprico de productos Provocar cambios que aumenten la productividad del Scrum Team Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicacin de Scrum en la organizacin
Scrum Guide, julio 2010
108

Development Team

Roles de Scrum Development Team

El Development Team tiene las siguientes caratersticas:
Roles Scrum

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)

Scrum Guide, julio 2010

109

Desde roles Tradicionales hacia roles giles

Roles Tradicionales Roles Scrum

Cliente

Jefe de proyecto

Product Owner

Analista

Scrum Master

Programador Development Team Tester (Pruebas de Aceptacin)

110

Entonces . qu es un Cross-Functional Team?

Programacin Definicin Testeo

Otras Actividades

NO implica que todos los miembros:

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

Algunas Alternativas Actividades-Roles para abordar un mismo tem

Dependiendo del tamao del equipo de desarrollo:
Slo 1 miembro para un tem
D P
Desarrollador Analista/Programador

2 miembros para un tem

D P T
Tester

2 miembros para un tem

D P
Programador

3 miembros para un tem

D P
Analista/Tester Programador Analista

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

Manager Lder Facilitador?

115

Comentarios finales respecto de roles

Los roles son slo una facilidad para asociar ciertas actividades. Lo importante no son los roles en s mismos sino las actividades que se deben realizar y quin se ocupar de ellas en cada tem. Scrum promueve romper con la especializacin extrema, es decir, evitar que cada miembro realice slo 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 iteracin. No existe una combinacin 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 motivacin, eficacia y eficiencia?
116

Gemba Lugar de trabajo

117

Mtodos giles

Herramientas para Gestin gil

Herramientas usadas en proyectos giles

http://www.versionone.com/pdf/2010_State_of_Agile_Development_Survey_Results.pdf
119

Herramientas para la gestin gil de proyectos

Agilo JIRA OnTime Pivotal Tracker Rally ScrumDesk Scrumworks TargetProcess Team Concert TinyPM VersionOne www.agile42.com/cms/pages/agilo/ www.atlassian.com/software/jira/ www.axosoft.com/ontime www.pivotaltracker.com/ www.rallydev.com/ www.scrumdesk.com/ danube.com/scrumworks/pro/ www.targetprocess.com/ www-01.ibm.com/software/rational/products/rtc/ www.tinypm.com/home www.versionone.com/
120

Proceso Iterativo e Incremental con Scrum

Sprint Planning Meeting Sprint Review Meeting

Lista ordenada de prximas WUs (en constante cambio). Requisitos definidos en gran parte antes de que a WU se incluya en una iteracin

121

Kanban + Scrum usando WFs

Cada tem sigue su WF Los WF deberan ser configurables en cuanto a actividades, roles y encadenamiento de actividades. Un producto puede tener asociados varios WFs disponibles para utilizar con sus WUs

122

123

Ejemplo workflow simple estilo tradicional

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.

Estado de las WUs en cada actividad

Diversas formas de acceder al detalle de la WU en el WUM (Work Unit Manager)

126

TUNE-UP Kanban y Gestor de WUs (tems)

Filtro agente Filtro producto y versin

TUNE-UP Kanban

Definicin del cambio mediante pruebas de aceptacin

TUNE-UP Work Unit Manager

Actividades en las que puede estar una WU (es configurable) Tracking de la WU

Agentes responsables

127

www.tuneupprocess.com

128

Mtodos giles

Planificacin y el Product Backlog

Planificacin Iterativa e Incremental usando Diagrama Gantt

Extrapolar esto a decenas de tems en cada versin!!

Extrapolar esto a tems con WFs diferentes y ms complejos!!

130

Producto - tems de trabajo

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

Producto en desarrollo o mantenimiento

131

Esfuerzo estimado versus Capacidad

Product Backlog

Esfuerzo estimado

Capacidad del equipo

Sprint

132

Planificacin gil Sprints y Releases

Sprint Planning Meeting Sprint Review Meeting

SprintX

Sprintx+1

Sprintx+2

Product Backlog

Release

133

Gestin de Fallos

134

La clave: el Product Backlog

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].

135

Alternativas para estimacin

tems (p.e. Historias de Usuario)
1. No estimarlas

(adaptado de una presentacin de Henrik Kniberg)

tem Units (Tareas)

1. No dividir HU en tareas 2. Estimarlas usando tallas de camiseta

2. No estimarlas, slo contarlas

3. Estimar las HU usando Puntos

1p

2p 30h

5p 45h

3. Estimar las tareas en horas o das (ideales)

4h

4. Estimar las HU en horas o das (ideales)

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

Ms informacin en: http://bit.ly/tNeyn7

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

Esfuerzo restante Esfuerzo abordable

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

Visualizacin del estado del Sprint

144

Seguimiento gil - Grficas Burndown

La grfica Burndown ilustra el Esfuerzo Restante, para el seguimiento ste debe contrastarse con el Esfuerzo Abordable en el perodo restante del Sprint.

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

Soporte para grficas Burndown en herramientas comerciales

147

Interpretacin de las Grficas Burndown

Eventos que invalidan la lectura del Esfuerzo Restante
Actividad con estimacin sobrepasada Actividad sin estimacin

Eventos que provocan una variacin del Esfuerzo Restante

Ajuste en Estimacin - Incremento/Decremento Introduccin de estimacin faltante Trabajo aadido a iteracin (WU nueva o ya existente) Trabajo desestimado, cambiado de iteracin o eliminado Trabajo terminado Trabajo asignado/desasignado a/de un agente Correccin del Esfuerzo Invertido

148

149

Gestin gil de Requisitos

TDRE: Test-Driven Requirements Engineering

Requisitos

Pruebas de Aceptacin
Pruebas de Sistema Pruebas de Integracin Pruebas Unitarias

Anlisis

Diseo de Arquitectura Diseo de Mdulos

Especificacin y Diseo de Pruebas

Programaci n

Aplicacin de Pruebas
151

Desarrollo Test-Driven (TDD)

Cambio en comportamiento

Versini Unidades de Trabajo (Wus)

Versini+1 Nuevo requisito Expresados en trminos Mejora de Pruebas de Aceptacin Correccin de defecto
152

Especificacin de requisitos tpica

Diagramas de Secuencia

Pero

Descripcin narrativa

Casos de Uso

Plantillas de Casos de Uso

Bocetos de IU
153

Propuesta de TUNE-UP: TDRE (Test-Driven Requirements Engineering)

Descripcin narrativa (muy breve) + atributos Escenarios PAs Diagramas de Secuencia

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

Ejemplo de especificacin de requisitos

Enviar artculo Usuario: Autor Prioridad: Alta Riesgo: Medio Esfuerzo: Medio Tipo: Nuevo Requisito 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.

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

ATEST 1.6: Envo exitoso con email de confirmacin

155

Definicin de Pruebas de Aceptacin (PAs)

Una PA tiene como propsito demostrar al cliente el cumplimiento de un requisito del software
Precisando ms, una PA: Describe un escenario, compuesto por una situacin del sistema (condicin de ejecucin) 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 ms PAs asociadas Las PAs cubren desde escenarios tpicos/frecuentes hasta los ms excepcionales

156

Identificacin de Pruebas de Aceptacin

Pruebas de Aceptacin (= Escenarios) Reintegro normal Intento de reintegro con saldo insuficiente Falta de ciertos tipos de billetes Cancelacin de operacin Aviso de no entrega de recibo Fuera de servicio por falta de billetes Excedido tiempo comunicacin con banco Excedido tiempo inactividad usuario Cajero en mantenimiento

Ejemplo: Requisito Reintegro

157

Definicin de Pruebas de Aceptacin

Estructura de una PA
Nombre Condicin Pasos
-----

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

Mantenimiento del software basado en PAs

Ejemplo: WU Adaptacin a nueva normativa. Es una mejora que afectar entre otros requisitos ya implementados al requisito Reintegro
Impacto en requisito Reintegro (en sus Pruebas de Aceptacin)
Reintegro normal Configuracin monetaria del pas Intento de reintegro con saldo insuficiente Saldo insuficiente con cliente premium Faltan de ciertos tipos de billetes Cancelacin de operacin Aviso de no entrega de recibo Confirmacin si cantidad de reintegro es alta Fuera de servicio por falta de billetes Excedido tiempo comunicacin con banco Excedido tiempo inactividad usuario Cajero en mantenimiento

159

Gestin del producto SW

Estructura de requisitos del producto
Reintegro

Requisitos afectados por la WU

WU adaptacin a nueva normativa

161

Proceso de Desarrollo dirigido por PAs

Escribe cdigo para satisfacer las PAs

WUs
Definen WUs en trminos de PAs

Cambios en la estructura de requisitos y/o en PAs

Disea instanciaciones y aplica las PAs

162

Comentarios finales respecto de TDRE

TDRE es rentable, la especificacin de requisitos como PAs ofrece las siguiente ventajas:

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

Mejora Continua del Proceso

Mejora continua Act Check Plan Do

Sprint

Retrospectivas
165

Adaptar la metodologa al producto y refinarla

Scrum
Otras metodologas giles

XP

Kanban

RUP Ad-hoc
Act Plan

Check

Do
166

El Know How est contenido en los WFs

167

Decisiones respecto de los WFs

Cada WU puede necesitar un tratamiento especfico dependiendo de por ejemplo:
Su tipo: Nuevo requisito, mejora en requisitos existente, correccin de fallo, etc. Actividades especficas, por ejemplo: traduccin, pruebas de rendimiento, validaciones adicionales, automatizacin de pruebas, etc. Cliente solicitante del cambio El producto El equipo de desarrollo y su estrategia de organizacin

168

Decisiones respecto de los WFs

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 Decisin recomendada: Comenzar con muy pocos WFs y que sean lo ms sencillo posible Centrar la mejora continua del proceso en la mejora de los WFs (aadiendo, modificando o eliminando actividades y sus relaciones, o incluso aadiendo o eliminando WFs)

169

Escalando el agilismo
Un mismo proyecto con varios equipos Scrum de Scrums

Equipos pequeos < 10 miembros

170

Conclusiones

Expectivas tras el Agilismo

Alcance

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

Agilismo ms all del mbito del software

Desarrollo gil de Software
Manifiesto gil

Gestin gil de Proyectos

Metodologas, Tcnicas y Herramientas giles

SWBOK CMMI UML

Generalizacin a otros mbitos de proyecto

?
Tcnicas y Herramientas Tradicionales PMBOK PMO

RUP

Desarrollo Tradicional de Software

Gestin Tradicional de Proyectos

173

Agilismo a diferentes niveles

(Portafolio management Office, Program Management Office, o Project Management Office)

PMOs

Aplicacin de prcticas giles

(trabajando en un producto/proyecto)

Equipo de trabajo

174

To be or not to be gil?

There is an elephant in the room

175

To be or not to be gil?
Agile's Teenage Crisis? Philippe Kruchten . Enumeracin de los elefantes.
infoq.com/articles/agile-teenage-crisis

ScrumButs = prctica no aplicada / excusa / alternativa.

scrum.org/scrumbut

Necesitamos una evaluacin de procesos giles ?(nivel de madurez?) espero que no .

Post-Agilismo

176

Sinergia de Prcticas (en Extreme Programming)

Mientras ms prcticas se apliquen y en mayor profundidad mejor es el resultado

Extreme Programming: Kent Beck

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

El rol de las certificaciones en el contexto gil

179

Su nombre aqu

180

Una historia que se repite?

En 1997 Bertran Meyer escribi una stira acerca de UML en una edicin especial de la revista American Programmer. El artculo 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 haba obtenido por su trabajo donde haca una evaluacin de UML. Despus de recorrer en forma sarcstica todas las posibles contribuciones de UML respecto de lo ya existente (descartando cada una de ellas), finaliza la carta con esta reflexin: 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.

181

State of Agile Development (Survey 2011)

3 de 3

Otras tambin 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

182

Revolucin o evolucin hacia el agilismo?

Mayoritariamente se est promoviendo la revolucin, 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 (metodologa, equipo en s mismo, productos, clientes, entorno de trabajo, etc.). Es prcticamente imposible llegar a ser 100% gil. Primero porque no existe una definicin rigurosa de ello (ni la necesitamos ) y segundo porque probablemente el contexto del equipo se lo impedir Las prcticas 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

183

Evolucin hacia el agilismo

Caractersticas NO consideradas giles

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

Caractersticas consideradas giles

Determina tu punto de partida

Caractersticas NO giles Caractersticas giles

Establece un punto de partida realista para iniciar tu evolucin hacia el agilismo

Requisito mnimo: tu punto de partida debe considerar un proceso iterativo e incremental con entregas frecuentes.

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

Configuracin metodolgica para un producto

Scrum
Otras metodologas giles

XP

Kanban

RUP Ad-hoc
Act Plan

Check

Do
188

Qu es TUNE-UP?

Adquirir conocimientos, definir metodologa, seleccionar herramienta, e integrar todo

Formacin y consultora, metodologa y herramienta configurables

189

Un Plan de Implantacin de Prcticas giles

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.

Resultado: El equipo alcanza el objetivo metodolgico establecido.

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

Resultado: Evaluacin y recomendaciones para aplicacin de otras prcticas giles

195

Resumen del plan

FASE 0: Formacin Bsica en Agilismo (6 horas) FASE 1: Diagnstico y configuracin (aprox. 3 semanas) FASE 2: Formacin y puesta en marcha (aprox. 4 semanas) FASE 3: Asistencia y seguimiento (aprox. 12 semanas) FASE 4: Evaluacin y prximos pasos (aprox. 2 semanas) Tiempo (cronolgico) de la implantacin: aprox. 20 semanas Incluye:
Aprox. 23 reuniones de aprox. 2 hrs. cada una Formacin bsica en Agilismo , 2 sesiones de 3 hrs. Seminario de formacin por videoconferencia, de 4 sesiones de 3 hrs. Horas de asistencia respecto del uso de la herramienta y dudas metodolgicas
196

Gracias por vuestra atencin!

Patricio Letelier Torres letelier@dsic.upv.es agilismoatwork.blogspot.com www.tuneupprocess.com
Departamento Sistemas Informticos y Computacin (DSIC) Universidad Politcnica de Valencia (UPV) - Espaa