Modelos de Procesos de Gestión y Desarrollo de Software

Modelos de Procesos de Gestión y

Desarrollo de SoftwarePatricio Letelier Torresletelier@dsic.upv.es

agilismoatwork.blogspot.comwww.tuneupprocess.com

Departamento Sistemas Informáticos y Computación (DSIC)Universidad Politécnica de Valencia (UPV) - España

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

Introducción al Proceso de Software

Contexto

Alcance

CostoCalidad

Productividad

Ámbitos de mejora en Ingeniería de Software

Herramientas(IDEs, CASE, …)

Proceso(Metodologías)

Notación(Lenguajes)

Calidad del Producto Software

ISO/IEC 9126

¿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

hazlo!!

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

CMMI: Capability Madurity Model

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

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.

Configuración de la metodología

Kanban

Ad-hoc Plan

DoCheck

Otras metodologías

Ágiles

“Just Enough Process”

… Ni muy poco

… Ni mucho

Modelos de Proceso y Metodologías

Definiendo “nuestro” modelo de proceso

tiempo

Planificación

Requisitos

Arquitectura & Diseño

Codificación (Programación)

Testing

Despliegue (Deployment)

Proceso Secuencial

P R D C T D

tiempo

Mejor es solapar trabajo ¿no? …

Proceso en Cascada (Waterfall)

tiempo

Planificación y seguimiento usando Diagramas Gantt

Realismo (el cambio y el retrabajo existe!) Desarrollo incremental

+ “Divide y vencerás”

Proceso Incremental

tiempo

D1 C1 T1

tiempo

¿No es mejor hacer todo incremental ? …

… Proceso Incremental

R1 D1 C1 T1

tiempo

Pero ¿cómo planificar sin antes saber lo que hay que hacer? …

Proceso Incremental con fase de exploración

R1 D1 C1 T1

tiempo

Validación frecuente → Desarrollo Iterativo …

Proceso Iterativo e Incremental

tiempo

Fin 1eraIteración

Fin 2daIteración

Fin 3raIteración(Entrega)

InicioConstrucción

D TC2 T2

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? …

R1 D1 C1 T1

tiempo

Fin 1eraIteración

Fin 2daIteración

Fin 3raIteración(Entrega)

InicioConstrucción

TR2 D2 C2 T2

R3 D3 C3 T3T

R4 D4 C4 T4

R5 D5 C5 T5

R6 D6 C6 T6

Pero ¿cómo reflejamos el re

-trabajo

que se producirá debido a la

resolución de defectos? …

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

¿Qué es una Metodología?

Una metodología define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo

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

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.

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.

Elementos de una Metodología

ProcesoSW

Notación

HerramientasPersonas

ArtefactosRoles

Actividades

Metodologías Tradicionales Rational Unified Process (RUP)

Fases y actividades

Fases e Hitos (Milestones)

tiempo

Objetivos(Vision)

Arquitectura CapacidadOperacionalInicial

Releasedel Producto

Inception Elaboration Construction Transition

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)

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)

... Elementos en RUP

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

Ejemplo Workflow Detail:Analyse the ProblemWorkflow: Requirements

Actividades

Roles Artefactos

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

… ……

Características Esenciales de RUP

Proceso Dirigido por los Casos de

Proceso Centrado en la

Arquitectura

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

... Proceso dirigido por los Casos de Uso

Caso de Uso Realización de Análisis Realización de Diseño

Caso de Prueba

«trace» «trace»

«trace»«trace»

Pruebas Funcionales

PruebasUnitarias

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

... Proceso dirigido por los Casos de Uso

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

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

… Proceso Iterativo e Incremental

EnfoqueCascada

EnfoqueIterativo eIncremental

... Proceso Iterativo e Incremental

Grado de Finalización de Artefactos

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

“Cambia el chip”

Metodos Ágiles Una ojeada al agilismo

Ser Ágil => actuar según el Manifiesto Ágil (2001)

¿cuál es tu interpretación?

agilemanifesto.org

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

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?

Costo de los Cambios en SW

Costodel

cambio

tiempo

Tradicional

Suposición MAs

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

Tradicional v/s Ágil

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

State of Agile Development (Survey 2010) 1 de 3

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

Los protagonistas

Kanban

Lean Development

Extreme Programming

¿De qué estamos hablando?

Métodos Á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 proyectoDurante el proceso nació una nueva metodología: eXtreme Programming (XP)C3 concluyó exitosamente en 1997

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

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

Boceto de IU para Historia de Usuario

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

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

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

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

Esquema de proyecto XP

Métodos Ágiles Lean Development

Impulso Lean Manufactoring al Agilismo

Desarrollo Ágil de Software

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!

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

Auto- discipl

inaShitsuk

ClasificarSeiri

OrdenSeiton

Limpieza

Estanda-

rización

Seiketsu

Método 5S – Lean Manufacturing

Métodos Ágiles Kanban

Kanban elemental

To Do Doing Done

Toyota Production System

Just-In-TimeLean Manufacturing

Eliminar el “waste”

Pull Systems

Kaizen

Kanban elemental

To Do Doing Done

Kanban elemental

To Do Doing Done

Kanban elemental

To Do Doing Done

Kanban elemental

To Do Doing Done

Kanban elemental

To Do Doing Done

Kanban elemental

To Do Doing Done

Visibilidad del estado del trabajoConseguir un flujo de producción “Pull”Limitar el WIP (Work in Progress)

Ilustrando el concepto WIP

MAGDALENA

PATRICIO

ALEJANDRO

FERNANDO

CATALINA

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)

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)

Métodos Ágiles Scrum

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

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

Scrum “Core” (Scrum Guide, julio 2010)

“Units” (de menos de un día de trabajo)

Product Backlog(lista ordenada)

Sprint Backlog

No más de 4 semanas

A1A3 A4

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!

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

Estimar ítems

Ordenar ítems

Implementar ítems

Testear ítems

Introducir nuevas ítems

Definir ítems

Estimar ítems

Ordenar ítems

Implementar ítems

Testear ítems

Tiempo

Métodos Ágiles Scrum + Kanban

Scrum + Kanban elemental

To Do Doing Done

ProductBacklog

Sprint

No más de 4 semanas

Sprint PlanningMeeting

Actividades esenciales asociadas a un ítem

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

Scrumban = Kanban + Scrum con actividades específicas

To Do Doing

Implementar

To Do Doing

TestearDone

Sprint Backlog

To Do Doing

Definir

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

Scumban manual (de pared)

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.

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.

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

Cross-Functional ySelf-Organizing Team

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?

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)

Muchos más

unos pocos más

…Manager

Una analogía un tanto molesta

Separación entre comprometidos e involucrados

letelier@dsic.upv.es

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

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

Desde roles Tradicionales hacia roles Ágiles

Scrum Master

Product Owner

DevelopmentTeam

Roles Scrum

Jefe deproyecto

Analista

Programador

Cliente

Roles Tradicionales

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

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

Ítem8

En un mismo Sprint cada ítem podría tener una estrategia diferente en cuanto a roles-agentes

Carlos María

Ítem1

Carlos María

Ítem2

Ítem4

MaríaCarlos

PMaría

Carlos

Ítem3

Ítem5

María

Carlos

Javier

Ítem6

JavierMaríaCarlos

María

Javier

PMabel

Ítem7

Ítem9

Todo el “Team”

Carlos

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

¿Manager … Líder …Facilitador?

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?

Gemba – Lugar de trabajo

Métodos Ágiles Herramientas para Gestión Ágil

Herramientas usadas en proyectos ágiles

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

Proceso Iterativo e Incremental con Scrum

tiempo

P Sprint Planning Meeting R7

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

PreparaciónProduct Backlog

TC2 T2

R2D2 R

ImplementaciónSprint

C3 T3R3D3

C4 T4R4D4 T R

ImplementaciónSprint

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

Ejemplo workflow simple “estilo tradicional”

… un workflow más complejo

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)

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

www.tuneupprocess.com

Métodos Ágiles Planificación y el Product Backlog

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!!

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

Esfuerzo estimado versus Capacidad

Sprint

Product Backlog

Esfuerzo

estimado

Capacidad

del equipo

Planificación Ágil – Sprints y Releases

tiempo

SprintX

Sprintx+1 Sprintx+2

P Sprint Planning Meeting

Product Backlog

R Sprint Review Meeting

Release

Gestión de Fallos

tiempoFin

SprintInicioSprint

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

Fallo detectado en versión

previa

“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

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

4. Estimar las HU en horas o días (ideales)

10h 30h 45h

Planning Poker

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?)

Más información en: http://bit.ly/tNeyn7

Métodos Ágiles Seguimiento

Planificación y seguimiento de proyectos

Introducción

Alcance

Costo Tiempo

Seguimiento ¿lo conseguiremos?

¿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

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)

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

Visualización del estado del Sprint

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

Soporte para gráficas Burndown en herramientas comerciales

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

Gestión Ágil de Requisitos

TDRE: Test-Driven Requirements Engineering

Requisitos

Análisis

Diseño deArquitectur

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

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)

Pero …

Plantillas de Casos de Uso Bocetos de IU

Descripción narrativa

Diagramas de Secuencia

Casos de Uso

Especificación de requisitos típica

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)

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

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

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

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

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

Gestión del producto SW

Reintegro

WU «adaptación a

nueva normativa»

Requisitos afectados por la WU

Estructura de requisitos

del producto

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

Cambios en la estructura de requisitos y/o

en PAs

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

Mejora continua

Retrospectivas

DoCheck

Sprint

Adaptar la metodología al producto y refinarla

Kanban

Ad-hoc Plan

Otras metodologías

Ágiles

El Know How está contenido en los WFs

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

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

Escalando el agilismo

Equipos pequeños < 10 miembros

Scrum de ScrumsUn mismo proyecto

con varios equipos

Conclusiones

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

Desarrollo “Tradicional” de Software

Desarrollo Ágil de Software

Agilismo más allá del ámbito del software

Gestión Ágil de Proyectos

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

PMOs (Portafolio management Office,Program Management Office, o

Project Management Office)

Agilismo a diferentes niveles

Equipo de trabajo (trabajando en un producto/proyect

Aplicación deprácticas ágiles

¿To be or not to be Ágil?

“There is an elephant in the room”

…¿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 …

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

“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”

El rol de las certificaciones en el contexto ágil

Su nombre aquí

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?

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

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?

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

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.

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

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

Configuración metodológica para un producto

Kanban

Ad-hoc Plan

Otras metodologías

Ágiles

¿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

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

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

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.

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.

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

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 Torresletelier@dsic.upv.es

agilismoatwork.blogspot.comwww.tuneupprocess.com

Departamento Sistemas Informáticos y Computación (DSIC)Universidad Politécnica de Valencia (UPV) - España

Modelos de Procesos de Gestión y Desarrollo de Software

Documents

Grupo 5-modelos-de-procesos-de-software

PROCESOS PARA LA INGENIERÍA DE SOFTWARE€¦ · Modelos de procesos de desarrollo de software Todos los modelos del proceso del software pueden incluir las actividades estructurales

Modelos de software

Equipo 4 Modelos de procesos de Software

PROCESOS PARA LA INGENIERÍA DE SOFTWARE - uv.mx · software Modelos de proceso evolutivos Prototipo El cliente define un conjunto de objetivos generales. No identifica los requerimientos

PROCESOS PARA LA INGENIERÍA DE SOFTWARE - … · Pressman, R.S., Ingeniería del Software. Un enfoque práctico ... El trabajo desde la comunicación hasta el ... Modelos de procesos

MODELOS DE PROCESOS DE INGENIERIA DE SOFTWARE

Modelos de Procesos: Prescriptivo - Javier8a · ... Características que deben tomarse en cuenta dentro del desarrollo del software El flujo de un ... procesos de desarrollo y

Modelos de software

INTRODUCCIÓN A INGENIERÍA DE SOFTWARE & MODELOS DE PROCESOS Mgr. Indira Camacho Basado en la presentación de Cibertec 1

Modelos Procesos OxO

Modelos de procesos del software

Software modelos educativos . final

Ingenieria de Software - Procesos

Software Eficiencia y seguridad para sus procesos de ...€¦ · Software y Servicios Construcción de troqueles y moldes Construcción de modelos Ingeniería mecánica. Contenido

Modelos Cuantitativos_manual de Software

Presentacion modelos de Software

Procesos de modelos del software

PROCESOS DE CALIDAD SOFTWARE

Ingeniería de Software Unidad II. Modelos de Procesos de software