Modelamiento de Proceso de Software

Departamento de Informática, UTFSM 2013/2014

Universidad Técnica Federico Santa María Departamento de Informática

Departamento de Informática 2013/2014

PROGRAMA: “Magíster en

Tecnologías de la Información”

(modo ejecutivo)

Curso “Modelamiento de Procesos de Software”

Hernán Astudillo

Marcello Visconti


Instructores

Marcello Visconti

Ingeniero Civil Informático & PhD Computer Science

Profesor UTFSM, Valparaíso

Hernán Astudillo

Ingeniero Civil Informático & PhD Computer Science

Profesor UTFSM, Valparaíso & Santiago

Horario & materiales

16 horas lectivas

Lecturas: artículos


Evaluación

Dos controles de lectura (25% c/u)‏

Control 1: tomado sesión 24 de mayo

Control 2: tomado sesión 15 de junio

Una tarea en grupo (50%)‏

Tarea: se entrega 3 semanas después de la última sesión


¿INGENIERÍA? DE SOFTWARE


Percepciones del

Desarrollo de SW

Problemas

Retraso respecto al potencial de hardware

Insatisfacción de la demanda

Bajo cumplimiento de compromisos – costos, plazos

Baja calidad y satisfacción de clientes/usuarios

Mantención de sistemas legados

Ineficiencia

Altos costos

Baja confiabilidad

Escasa ingeniería


Algunos Mitos

estándares y procedimientos bastan

tecnología de punta basta

más gente para ponerse al día

programación inmediata

fácil acomodo de los cambios

programación: fin del trabajo

calidad: sólo del ejecutable

código es el único producto


Ingeniería de Software

Objetivos

Maximizar calidad

Maximizar productividad

Minimizar riesgos

La Ingeniería de Software es la disciplina que se ocupa de la construcción sistemática, eficaz y eficiente de software eficaz y eficiente.

Sistemática – principios, métodos y técnicas

Eficaz – ...para lograr los objetivos

Eficiente – ...usando los recursos adecuadamente



“Establecimiento y uso de principios con caracteres de ingeniería apropiados para obtener, eficientemente, software confiable, que opere eficaz y eficientemente en máquinas reales”

En una Conferencia de la OTAN en Alemania (1968), para abordar la entonces llamada “crisis del software”.

La Ingeniería de Software tiene sentido para quien quiere vivir de hacer software

Sin mucho sentido para artesanos o hobbistas



Implicancias

constructores básicos más poderosos

mejores técnicas de control de calidad

mejores herramientas y métodos

Empacados en procesos de software adecuados al tipo de problema que se resuelve, y que permiten gestionar de mejor manera los principales riesgos relevantes para todos los stakeholders

“Stakeholders”: involucrados o afectados


ISW COMO

GESTIÓN DE RIESGO


Dificultades en

Producir Software

Brooks (“No silver bullet”, 1986) arguyó que hacer software siempre será muy complejo

Problemas accidentales

Solubles con avances de investigación

Problemas esenciales

Complejidad

Conformidad

Necesidad de cambios

Invisibilidad


Proyectos atrasados y

cancelados

Estudio de 8000 proyectos en EEUU [Standish 2000]

En plazo y costo: 9%-16%

Retrasados/excedidos: 53%-60%

Cancelados (abortados): 31%

o Requisitos incompletos: 13%

o Falta de participación del usuario: 12%

o Falta de recursos: 11%

o Expectativas descontroladas: 10%

o Falta de apoyo gerencial: 9%

o Requisitos inestables: 9%

o Falta de planificación: 8%

o Obsolescencia pre-parto: 7%


Costo de problemas

Cuantificación de Impacto

Costo de reparar errores en los requisitos…

oDetectado durante análisis: $X

oDetectado durante diseño: $5X

oDetectado durante construcción: $10X

oDetectado durante prueba: $20X

oDetectado después de entregado: $100X-$200X


Proyectos ineficientes

e inefectivos

Riesgos de construcción de software

(R1) riesgo de hacer algo inútil (inefectividad)‏

(R2) riesgo de sub-/sobre-estimar recursos (ineficiencia)‏

Clasifiquemos las causas de cancelación

Requisitos incompletos: 13% (R1)‏

Falta de participación del usuario: 12% (R1)‏

Falta de recursos: 11% (R2)‏

Expectativas descontroladas: 10%

Falta de apoyo gerencial: 9%

Requisitos inestables: 9%

Falta de planificación: 8% (R2)‏

Obsolescencia pre-parto: 7% (R1)‏


Ing. de SW como

Gestión de Riesgo

Propósito: Reducir el riesgo de construcción

Inefectividad: riesgo de hacer algo inútil

Ineficiencia: riesgo de sub-/sobre-estimar recursos

Para efectividad:

Ingeniería de Requisitos: caracterización del problema correcto

Para eficiencia:

Diseño de Software: resolución del problema correctamente (p.ej. reusando trabajo previo)‏

Calidad de Productos: para minimizar retrabajo

Enfoque sistemático: empacado en procesos


Procesos de Software

Proceso: serie de pasos que involucran actividades, restricciones y recursos, y que producen una salida.

Impone consistencia y estructura al conjunto de actividades.

No es un procedimiento, sino un conjunto organizado de ellos.

Un proceso permite/sugiere técnicas y herramientas.

La estructura del proceso guía la acción, permitiendo examinar, entender, controlar y mejorar actividades.

Permite capturar y transmitir experiencia de un proyecto a proyectos futuros.


PROCESOS DE

(DESARROLLO DE)

SOFTWARE


Un poco de Historia

El proceso como “caja negra”.

Requerimientos(informales)

Producto

PROCESO


Un poco de Historia

El proceso en una visión “transparente”.

Requerimientos(informales)

Producto

PROCESO

Retroalimentación


Modelos de Proceso

de Software

En la Ingeniería de Software se describen muchos Modelos de Proceso.

Unos son prescriptivos: establecen la forma en que debería progresar el proceso de software.

Otros son descriptivos: dicen la forma en que el proceso de software progresa en la realidad.


Modelos de Proceso

de Software

Razones para modelar un proceso:

Conforma un entendimiento común de las actividades, recursos y restricciones involucrados.

Ayuda a encontrar inconsistencias, redundancias y omisiones del proceso y sus partes.

Refleja las metas del desarrollo. El equipo puede evaluar la forma de alcanzar las metas.

El proceso puede ser modificado a la medida de la situación en que será usado.


Algunos Modelos de

Proceso de Software

Modelo en Cascada.

Modelo en V.

Modelo de Prototipación.

Modelo de Desarrollo en Fases.

Modelo en Espiral.

RUP.

Métodos Ágiles.


Modelo Cascada [1]

Es el primero formalizado (Roy 1971)‏

Debe completarse un estado antes de comenzar el siguiente.

Es útil para que el desarrollador visualice lo que va a hacer.

Su principal problema es que no refleja la realidad.

ANÁLISIS DEREQUERIMIENTOS

DISEÑO DELSISTEMA

DISEÑO DEPROGRAMAS

CODIFICACIÓN

TESTING UNITARIOE INTEGRADO

TESTING DELSISTEMA

TESTING DEACEPTACIÓN

OPERACIÓN YMANTENCIÓN


Modelo Cascada [2]

En la práctica:

A NÁ LISIS DEREQ UERIMIENTO S

DISEÑO DELSISTEMA

DISEÑO DE

PRO GRA MA S

C O DIF IC A C IÓ N

TESTING UNITA RIOE INTEGRA DO

TESTING DELSISTEMA

TESTING DE

A C EPTA C IÓ N

O PERA C IÓ N YMA NTENC IÓ N


Modelo V [1]

Variación del modelo en cascada (Alemania 1992).

El “ángulo” es la codificación.

Los sucesivos testing proceden como contraparte de las actividades de desarrollo.

Se forman “ciclos” desarrollo-verificación-desarrollo...

Verificación: determinar si el sistema construido se hace lo especificado

Validación: determinar si el sistema hace lo deseado


Modelo V [2]

A NÁ LISIS DEREQ UERIMIENTO S

DISEÑO DEL

SISTEMA

DISEÑO DEPRO GRA MA S

C O DIF IC A C IÓ N

TESTING UNITA RIOE INTEGRA DO

TESTING DEL

SISTEMA

TESTING DEA C EPTA C IÓ N

O PERA C IÓ N YMA NTENC IÓ N


Modelo de Prototipado

[1]

Permite la construcción rápida del sistema (o parte de éste).

Usuario y desarrollador tienen una visión común.

Se reduce el riesgo y la incerteza del desarrollo.


Modelo de Prototipado

[2]

REQ UERIMIENTO SDEL PRO TO TIPO

DISEÑO DELPRO TO TIPO

SISTEMAPRO TO TIPO

TESTING

REV ISIÓ N REV ISIÓ N REV ISIÓ N

REQUERIMIENTOS

DEL SISTEMA

SISTEMA

ENTREGADO


Modelo de Desarrollo

en Fases [1]

Una forma de reducir atrasos es desarrollar en fases.

El sistema se diseña de manera que pueda ser entregado por partes.

El usuario obtiene funcionalidad parcial mientras se desarrolla el resto.

Hay dos sistemas funcionando en paralelo:

Producción: usado por el Cliente.

Desarrollo: la siguiente versión (release) que reemplazará a la actual de Producción.

OJO: ¿propagación de correcciones a versiones estables?



en Fases [2]

DESARRO-

LLADORES

C O NSTRUIRV ERSIÓ N 1

USA R V ERSIÓ N1


USA R V ERSIÓ N2


USA R V ERSIÓ N3

USUARIOS

Sistemas en Desarrollo

Sistemas en Producción/Operación



en Fases [3]

Hay dos maneras básicas de organizar el desarrollo de los releases:

Incremental. El sistema se especifica y luego es particionado en subsistemas, por funcionalidad. Se comienza con un subsistema pequeño y se va agregando funcionalidad en cada nuevo release.

o Ej.: v1: ABM usuarios; v2: ABM usuarios + productos

Iterativo. Se entrega el sistema completo el comienzo y se van haciendo cambios y mejoras en la funcionalidad, en cada nuevo release.

o Ej.: v1: examinar usuarios/prods.; v2: ABM usuarios/prods.



en Fases [4]

Desarrollo Incremental

Desarrollo Iterativo



en Fases [5]

En la realidad, las organizaciones usan generalmente una combinación de desarrollo iterativo e incremental.

Esta forma es beneficiosa porque:

El entrenamiento de los usuarios puede comenzar tempranamente, aunque falte funcionalidad.

Releases frecuentes permiten encontrar y resolver problemas, a partir de las versiones operativas.

El equipo de desarrollo puede enfocarse en diferentes áreas de expertise en cada release.

Caso general: requiere arquitectos + product managers


Modelo en Espiral [1]

Se combina las actividades de desarrollo con Análisis de Riesgo.

El modelo es de tipo iterativo:

Planificación Análisis de Riesgo Ingeniería Evaluación Planificación ...

En cada iteración, se evalúan las diferentes alternativas y se elige una.

Los gestores del proyecto intentan eliminar o minimizar el riesgo.


Modelo en Espiral [2]

Recolección de Requerimientos y Planificación del Proyecto (iniciales)‏

Planificación basada en los comentarios del cliente

Evaluación del cliente

Análisis de Riesgo basado en los

requerimientos iniciales

Análisis de Riesgo basado en la

reacción del cliente

Hacia el Sistema Final

Prototipo inicial del Sw

Prototipo del siguiente nivel

Sistema de Ingeniería

INGENIERÍA EVALUACIÓN DEL CLIENTE

PLANIFICACIÓN ANÁLISIS DE RIESGO

Decisión de Seguir/No Seguir

Boehm (1986)‏


RUP – Rational Unified

Process [1]

RUP es un framework de procesos para describir procesos de desarrollo específicos

P.ej.: Agile UP (Ambler)‏, Basic UP (IBM/Eclipse), Enterprise UP…

Un proyecto tiene 4 fases, con criterios de término:

1. Concepción – planificación; criterio: decisión de factibilidad

2. Elaboración – determinar lo que hay que hacer; criterio: típicamente 80% de Casos de Uso (pero en AgileUP 20%)‏

3. Construcción – elaborar el software (iterativo incremental)‏

4. Transición – despliegue; termina con solución operando

Cada fase consiste en iteraciones

Cada iteración resulta en un entregable

RRHH agrupados por disciplinas (p.ej. Análisis)‏


RUP – Rational Unified Process [2]


PROCESOS ÁGILES DE

DESARROLLO DE SOFTWARE


Métodos Ágiles [1]

Interés creciente en los métodos ágiles (inicialmente llamados ligeros, lightweight) en los últimos años enfrentamiento de requerimientos cambiantes

tiempos de desarrollo escasos

clientes y usuarios cada vez más exigentes

Caracterizados alternativamente como antídoto a la burocracia (métodos planificados, pesados,

heavyweight)‏

hacking


Métodos Ágiles [2]

Algunas características de los métodos ágiles Documentación mínima

Ciclos iterativos breves

Reacción rápida ante los cambios

Estrecha relación con el cliente

Diseño simple

Satisfacción de necesidades inmediatas

Foco en las personas

Organización libre

Procesos adaptables, no predictivos


Principios Ágiles [1]

The highest priority is to satisfy the customer through early and continuous delivery of valuable software

Welcome changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage

Deliver working software frequently, from a couple of weeks to a cuple of months, with a preference to the shorter timescale

Business people and developers must work together daily throughout the project

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done


Principios Ágiles [2]

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Working software is the primary measure of progress Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace indefinitely

Continuous attention to technical excellence and good design enhances agility

Simplicity – the art of maximizing the amount of work not done – is essential

The best architectures, requirements, and designs emerge from self-organizing teams

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly


Principales Métodos Ágiles

Extreme Programming, XP

Scrum

Crystal Family

Feature-Driven Design

Adaptive Software Development

DSDM

Otros Open Source

RUP


Agilidad vs. Proceso

Últimamente, distintos trabajos han investigado la relación entre modelos de proceso y métodos ágiles, observando lo siguiente CMM/CMMI y XP pueden complementarse (foco en aspectos de

gestión vs. técnicos)‏

Métodos ágiles calzan con la esencia del mejoramiento de procesos bajo una interpretación menos literal (que CMMI, por ejemplo)‏

Métodos ágiles apuntan a gestión de proyectos, no a gestión de procesos


Dudas y Desafíos Ágiles

¿Son los métodos ágiles (XP por ejemplo) para todos?

¿Qué otros artefactos considerar además de código?

¿Cuánta agilidad? ¿Cuánto proceso?

Desafío: encontrar un punto de equilibrio, un balance adecuado

Desarrollos potenciales Modelos ágiles balanceados para migración a la práctica industrial

Mecanismos y herramientas ágiles para selección, adaptación, implantación y adopción de métodos ágiles


Extreme Programming

(XP) [1]

Valores Comunicación

Retroalimentación

Simplicidad

Coraje

Principios Retroalimentación Rápida

Cambio Incremental

Trabajo de Calidad

Simplicidad


Extreme Programming

(XP) [2]

El proceso de desarrollo extremo Fase inicial de captura de requerimientos es eliminada.

El ciclo de desarrollo de XP se divide en liberaciones, cada una de las cuales es medida en historias de usuario.

o Historia de usuario: unidad funcional en un proyecto XP, debe ser entendible tanto para el cliente como para los desarrolladores, verificable y pequeña.


Extreme Programming

(XP) [3]

El proceso de desarrollo extremo Fase de Exploración

Fase de Planificación

Fase de Iteraciones y Entregas

Fase de Producción

Fase de Mantenimiento

Fase de Muerte


Extreme Programming

(XP) [4]


Extreme Programming

(XP) [5]

Prácticas de la Programación Extrema Sobre los valores de la XP, la metodología construye una

docena de prácticas que los proyectos deben seguir.

Muchas de ellas son técnicas antiguas, tratadas y probadas, unidas en un todo sinérgico donde cada una refuerza a las demás.


Extreme Programming

(XP) [6]

Prácticas On-site costumer

Whole team

Planning game

Small releases/continuous integration

Sustainable pace/40-hour week

Test-driven development

Simple design

Pair programming

Collective code ownership

Coding standards

Metaphor

Refactoring


PROPUESTA DE

HERRAMIENTAS PARA

IMPLANTACIÓN DE XP


Identificación

Prácticas Ágiles [1]

Inicio Práctica 1: Establecer una declaración de políticas a adoptar

en XP, que permitan al equipo tener la información necesaria para comenzar con el proceso de XP.

Planificación Práctica 2: El juego de la planificación (Planning Game)

Práctica 3: Pequeñas Liberaciones (Small Releases)‏


Identificación


Diseño Práctica 4: Metáfora (Metaphor)‏

Práctica 5: Diseño Simple (Simple Design)‏

Pruebas Práctica 6: Pruebas Automatizadas (Testing)‏


Identificación


Desarrollo Práctica 7: Programación por Pares (Pair

Programming)‏

“My mind to your mind. My thoughts to your thoughts.”

Práctica 8: Refactoring

Práctica 9: Propiedad Colectiva del Código (Collective Code Ownership)‏

Práctica 10: Estándares de Codificación (Coding Standards)‏


Identificación


Desarrollo Práctica 11: Integración Continua (Continuous Integration)‏

Práctica 12: Cuarenta Horas Semanales (Sustainable Pace)‏

Práctica 13: Cliente Siempre Disponible (On-Site Customer)‏


Herramientas

Propuestas [1]

Cada práctica tiene asociada una o más herramientas para facilitar su implantación

Métodos para fijar la velocidad del proyecto. (Guía/Template)‏

Procedimiento de priorización de historias de usuario. (Guía/Template)‏

Estimación de historias de usuario. (Guía/Template)‏

Implementación de las historias de usuario. (Guía/Template)‏

Políticas de planificación. (Guía)‏ Planning Game

Proceso de desarrollo extremo. (Guía)‏

Introducción a la XP. (Guía)‏ Inicio

Herramienta Propuesta Práctica


Checklist de percepción (Checklist)‏

Seguimiento del plan de liberación. (Template)‏

Plan de liberación (Guía/Template)‏

Implementación de tareas de programación (Guía/Template)‏

Actividades de Planificación para las Liberaciones (Guía/Template)‏

Small Releases

Seguimiento plan de entregas (Template)‏

Plan de entregas (Guía/Template)‏


Herramientas

Propuestas [2]


Identificación de la Metáfora (Guía/Template)‏

Metaphor

Checklist de aceptación de las pruebas. (Checklist)‏

Desarrollo e implementación de las pruebas unitarias (Guía/Template)‏

Desarrollo e implementación de las pruebas de aceptación (Guía/Template)‏

Políticas sobre el testing en la programación extrema (Guía)‏ Testing

Actividades de implementación de tarjetas CRC (Guía/Template)‏

Guía para un diseño simple (Guía)‏ Simple Design


Herramientas

Propuestas [3]


Guía para llevar a cabo la integración continua (Guía)‏ Continuous Integration

Guía para implementar estándares de codificación (Guía)‏

Coding Standards

Definición de los estándares de codificación (Guía/Template)‏

Guía respecto a la propiedad colectiva del código (Guía)‏

Collective Code Ownership

Guía para la implantación del refactoring (Guía)‏ Refactoring

Establecimiento de la tarea de programación a desarrollar (Guía/Template)‏

Guía respecto a la programación por pares (Guía)‏ Pair Programming (Programación en

Pares)‏


Herramientas

Propuestas [4]


Checklist de aceptación de la entrega del sistema (Checklist)‏

On-Site Customer (Cliente on-site)‏

Actividades que debe desarrollar el cliente (Guía)‏

Guía para implementar el paso sustentable (Guía)‏ Sustainable Pace (Paso Sostenible)‏


Herramientas

Propuestas [5]

http://www.inf.utfsm.cl/~visconti/xp/




SCRUM


¿Qué es Scrum?

Un framework simple que puede ser implementado en unos pocos días

Un enfoque para manejar problemas complejos Un ambiente para soportar auto-organización,

creatividad y emergencia Un esfuerzo colaborativo que involucra

desarrolladores y clientes en un dialogo constante

Conceptos claves Proceso Empírico

o Planificación detallada por anticipado y procesos definidos son reemplazados por ciclos “just-in-time” de revisión y adaptación

Auto-organización o El equipo se autogestiona y organiza alrededor de metas,

tomando en cuenta restricciones claramente establecidas


El Framework Scrum

Planning Meeting

Estimation

Meeting

Sprint

Review

Retrospective

&

Impediment

Backlog


Roles de Scrum

Product Owner (Dueño del Producto) Gestiona la Visión y los Requerimientos Es el responsable de construir y difundir la visión del producto,

mejorar el ROI, conciliar las expectativas del cliente y de los stakeholders, trazar el rumbo a seguir y planificar las entregas, coordinar y priorizar el Product Backlog, proveer requerimientos claros y testeables al Team, colaborar con el cliente y con el Team para asegurar que se cumplan las metas y para aceptar el software al final de cada iteración

Puede ser un analista que escribe los requerimientos

Scrum Master (Facilitador) Gestiona el Proceso Líder Servidor del Equipo Es responsable de guiar al Team, crear un ambiente de confianza,

facilitar las reuniones del Team, hacer las preguntas difíciles, remover impedimentos, hacer visibles los problemas, mantener al proceso avanzando, sociabilizar Scrum y Agile con el resto de la organización, educar a Clientes y otros Stakeholdres


Roles de Scrum

The Team (El Equipo)

Se gestiona así mismo

Se maneja desde una perspectiva táctica. Es responsable por estimar el tamaño de los ítems del Product Backlog, tomar decisiones de diseño e implementación, y comprometerse a entregar incrementos de software.

Sigue su propio progreso (con ayuda del Scrum Master). Es autónomo y auto-organizado, pero debe responder ante el Product Owner para entregar lo prometido


Reuniones de Scrum

Estimation Meeting (Reunión de estimación) El Team se reúne con el Product Owner para discutir sobre los ítems del

Backlog y asignarle un tamaño a cada uno. Esto ocurre por primera vez antes de que comience el desarrollo y luego iterativamente al inicio de cada Sprint.

Planning Meeting (Reunión de planificación) Ocurre al comienzo de cada Sprint. El Team y el Product Owner negocian

el Sprint. La planificación puede ser basada en compromisos o en velocidad

Daily Scrum (Scrum Diario) Todos los días. Máximo 15 minutos. El equipo se reúne para reportar a los

demás miembros el progreso, intenciones e impedimentos y actualizar el task board

Review (Revisión) Inspeccionar y adaptar el producto. El Team se reúne con el Product

Owner al final de cada Sprint para hacer una demostración del software que se ha desarrollado en el Sprint

Retrospective (Retrospectiva) Inspeccionar y adaptar el proceso. El Team se reúne con el Scrum Master

para discutir qué cosas anduvieron bien y cuáles pueden ser mejoradas


Artefactos de Scrum

Product Backlog (Trabajo por hacer del producto) Lista priorizada de todos los requerimientos conocidos acerca del producto Cada requerimiento se denomina Product Backlog Item (PBI) Representa el Qué del proyecto Siempre fluyendo; sufre de re-priorizaciones según las necesidades del

cliente

Committed Backlog (aka Sprint Backlog) El subconjunto del Product Backlog que el Team se ha comprometido a

desarrollar para el siguiente Sprint Es fijo Los PBIs comprometidos son descompuestos en tareas: el Cómo

Impediment List (Lista de impedimentos) Lista priorizada de todos los impedimentos al proceso de desarrollo Dividida en secciones Organizacional y Team.

Product Increment (Incrementos del producto) El software terminado y entregado al final de cada Sprint Aceptado o rechazado por el Product Owner y los stakeholders


Scrum, Rugby y los Japoneses

El término “Scrum” viene de un estudio de 1986 de los japoneses Takeuchi y Nonaka. En dicho estudio se documentaban una serie de proyectos muy exitosos los cuales tenían en común el uso de equipos pequeños y multidisciplinarios. El estudio comparaba a esos equipos hiper-productivos con la formación Scrum de Rugby.

Jeff Sutherland creó el proceso Scrum para desarrollo de software en 1993 usando este estudio como base y adoptó la analogía con los equipos de Rugby.

Posteriormente, Ken Schwaber formalizó el proceso y lo abrió a toda la industria del software en 1995.

Ref.:‏“¿Qué‏es‏Scrum?‏”‏http://www.baufest.com/spanish/scrum/scrumconference2006/7.htm




Planificación y Seguimiento en

Scrum

Estimaciones

Product Backlog

Task Board

Burndown Charts

Velocity Graph


Estimaciones

Primero Crear el Product Backlog Cuando un proyecto se inicia no es necesario que sea exhaustivo Típicamente al principio se escribe todo lo obvio, lo que suele ser

más que suficiente para un primer Sprint Los PBI’s pueden ser:

o User Stories, Casos de Uso, Requerimientos (funcionales, técnicos, etc.), y/o complementos entre estos

Técnicas para reunir PBI’s Cuestionarios, observación, entrevistas, etc.

Si usas User Stories, entonces, estimar con Story Points Basado en una combinación de complejidad y tamaño La escala la decide el Team (ej. 1 a 10), es una estimación

relativa Se hace mediante votaciones iterativas de los miembros del Team

hasta converger


Ejemplos de Estimaciones del Product

Backlog


Planificación del Sprint Basada en

compromisos

El Product Backlog es constantemente re-priorizado por el Product Owner según las necesidades del cliente

Dichas transformaciones son explicadas por el PO al Team durante la Planning Meeting del Sprint

Durante la Planning Meeting el Team selecciona los PBI’s que puede terminar durante el Sprint que viene (se compromete)

Cada PBI se descompone en múltiples tareas para el Sprint, la estimación de dichas tareas y su asignación es hecha por el Team

Task Board Muestra todo el trabajo que se está haciendo durante un Sprint. Se actualiza diariamente en el Daily Scrum Las tareas se ubican en la columna To Do Típicamente se incluyen columnas In Progress (trabajo que se

está realizando) y Done (trabajo ya terminado)


Ejemplos de Task Board para Sprints


Burndown charts para un Sprint

Task Burndown

0

10

20

30

40

50

60

1 2 3 4 5 6 7 8 9 10

Days

Nº

Tasks

real

ideal

Story Burndown

0

1

2

3

4

5

6

7

8

1 2 3 4 5 6 7

Days

Nº

Sto

ries


Graficas para el proyecto

• Burndown del Proyecto

Velocity

0

10

20

30

40

50

60

70

80

1 2 3 4 5 6 7 8

Sprint

Sto

ry p

oin

ts

Real

Ideal

Velocity Graph

• Altura representa el trabajo pendiente al inicio de cada Sprint

• Su información puede usarse como alternativa a la planificación basada en compromisos para equipos experimentados




El Proceso Scrum

Iniciar el Proyecto

Crear el Product Backlog

Sprint 1

Retrospectiva

Revisión

Sprint 2

…

Sprint n


Iniciar el Proyecto

Presentar la Visión del Cliente

Requerimientos de alto nivel

El equipo discute (y habla con el Cliente)

Discusión de usabilidad

o¿Para quién es este producto?

o¿Qué necesidad va a satisfacer?

Crear un Documento de Visión

Crear un primer borrador del Product Backlog


Preparación del Product Backlog

Típicamente recomendado

Crear User Stories (PO, Cliente)

Priorización “gruesa” (PO)

Refinar 30% superior (PO, Team)

Estimar ítems de Backlog (Team)

Normalizar y re-priorizar (PO, Team)


Sprint 1

Planning Meeting En este momento todavía hay mucha incertidumbre. Hay que

mantener esta reunión corta y simplemente comprometerse con algo (tomar un conjunto de PBI’s [votar]). El aprendizaje va a ocurrir a través de la creación de ese algo, no por hablar acerca de eso

Tomar los PBI’s comprometidos y descomponerlos en tareas Idealmente mantener el tamaño de las tareas en 1 día Asignar tareas

Desarrollo Daily Scrum 1

o Scrum Master hace tres preguntas:

– ¿En qué trabajaste? – ¿En qué trabajarás ahora? – ¿Hubo algún impedimento?

o Actualizar Task board y gráficos … Daily Scrum n (Además preparar el Review)


Review del Sprint 1

¿Hay incremento demostrable del producto?

¿Lo acepta el Product Owner?

¿Se ha cumplido los criterios de aceptación?


Retrospective del Sprint 1

Reflexionar sobre el Task board Tracking de horas vs. Tracking de tareas PBIs imcompletos

o Devolver al Backlog Task burndown Story Burndown Velocity Burndown

Feedback ¿Estaban claros los requerimientos? ¿Hay impedimentos, problemas? ¿Qué estuvo bien y qué estuvo mal? ¿Qué funcionó? ¿Qué necesita ser mejorado?

Impediment List Impedimentos a nivel del equipo Impedimentos a nivel de la organización


Continúa iterando …

Sprint 2 Planificación

o Re-estimación

o Discutir planificación basada en velocidad o compromiso

Desarrollo

oDaily Scrum 1

o …

oDaily Scrum n

Review del Sprint 2

Retrospective del Sprint 2

…

Sprint n



GESTIÓN DE COMPROMISOS

EN MÉTODOS ÁGILES


Problema a resolver

Los métodos ágiles están orientados a lograr calidad de software, pero no aseguran por sí solos el cumplimiento de las expectativas de incorporación de valor de negocio para el cliente (funcionalidad, time-to-market, budget, calidad)‏

Métodos ágiles y expectativas de negocio del cliente

¿Cómo pueden ser alineados?

¿Con qué método el cliente puede gestionar el riesgo de incumplimiento de sus expectativas de negocio?


Gestión de

Compromisos

La gestión de compromisos es el proceso de

especificación, formalización y seguimiento de

compromisos durante el proyecto, para alinear el resultado

final del proyecto al objetivo y estrategia de negocio.

Los compromisos son objetivos, formas de cooperación,

responsabilidades y decisiones que los participantes

acuerdan sobre un proyecto.


Gestión de Compromisos

en Métodos Ágiles

Hipótesis

Para proyectos en que se utilizan métodos

ágiles, la incorporación de la gestión de

compromisos como práctica formal, permitirá

mejorar la gestión de riesgos en el cumplimiento

de las expectativas de valor de negocio que el

cliente ha definido para el software.


¿Porqué el proyecto está siendo desarrollado?

Motivación de negocio.

¿Qué es entregado y cumplido, cuándo se entrega y

cuánto cuesta?

Objetivos de proyecto.

¿Cómo será desarrollado el proyecto?

Especificación del proceso.

¿Cuáles son los riesgos y qué hacer para mitigarlos?

Gestión de Riesgos.


Gestión de Compromisos en

Métodos Ágiles

Risk responsibility assignment

Accepted Risks

Scope of risk management

Risk Analysis and identification

Shared assumptions for the project Project Risk Management

Change control procedures

Conflict resolution procedures

Agile process definition (standard or framework)‏

Project management Agile Process Specification

Quality

Cost and budget

Schedule and times

Deliverables and Iterations (value added)‏ Project Goal

Time-to-market

Business goals

Strategic directions and intentions Business motivation

Specifics Goals Process Areas


Referencias

Software Engineering: Theory and Practice (2nd Ed.)‏ Shari Pfleeger, Prentice Hall (2001), Cap. 1&2

“The Software-Research Crisis” Robert L. Glass, IEEE Software, Noviembre 1994

“Using Risk to Balance Agile and Plan-Driven Methods” Barry Boehm, Richard Turner, IEEE Computer,

Junio 2003 RUP

www.ibm.com/rational Agile Alliance

www.agilealliance.com

Documents

Modelamiento de Proceso de Software