Métodos ágiles

Mtodos giles-Scrum y XPObject-Oriented Technology Training Dr. Ricardo R. Quintero Meza

^ El Desarrollo Iterativo y M Evolutivo: Serum y XP

Tema 1: Iterativo y Evolutivo (Dr. Ricardo Quintero)

(7

l

Repositorio en lnea de Material AdicionalMtodos giles-Scrum y XP

Mtodos giles-Scrum y XP

o http:/ / tinvurl.com/ cursoaqil

Dr. Ricardo Quintero1

^ Temas

V | bi Motivacin : : : j

o Desarrollo Iterativo

o Planeacin iterativa dirigida por los

riesgos y por el cliente

o El principio de "Time boxing"

o Desarrollo evolutivo y adaptativo

o Entrega incremental

o Entrega evolutiva

o Los errores ms comunes3

Al construir un telfono celular es posible definir, sin ambigedades, sus especificaciones y pasos de construccin.Despus de alguna experiencia en la construccin de telfonos es posible hacer estimaciones confiables deMtodos giles-Scrum y XP


costo y tiempo de futuros telfonos a construir.Dr. Ricardo Quintero2

Dr. Ricardo Quintero#

Suponga una persona que desea construir una casa "a la medidaSe quieren utilizar materiales y mtodos ecolgicos, pero no se est seguro al 100% de lo quese desea.Cambia o clarifica sus decisiones conforme pasa el tiempo al ver la casa y sus costos.Mtodos giles-Scrum y XP


Desarrollar Software es Desarrollar nuevos productos

Manufactura en masa o Manufactura predecible:Desarrollo de nuevos productos o proyectos con alto nivel de inventiva:Predictibilidad de proyectosNiveles bajos de cambio o novedad con altos niveles de creacin idntica o casi idnticaAlto grado de novedad, creatividad y cambio sin experiencia previa de casos idnticos a partir de los cuales estimar o derivar planes confiables


Proyectos predecibles y no predeciblesP. PredeciblesP. No predecibles

Al principio es posible definir sus especificaciones y despus construirRaramente es posible crear una especificacin detallada y no cambiante

Al inicio, se puede estimar de forma confiable el esfuerzo y el costoAl principio no es posible. Conforme van surgiendo datos empricos, incrementalmente va siendo posible planear y estimar

Es posible identificar, definir, calendarizar y establecer detalladamente el orden de todas las actividadesAl principio, no es posible. Se requieren pasos adaptativos conducidos por ciclos construir- retroalimentar

La adaptacin al cambio no predecible no es la norma y la razn de cambio es relativamente bajaLa adaptacin creativa para los cambios no previstos es la norma. La razn de cambio es alta.

En que categora cae el software?Desarrollar software no es un problema de manufactura en masa o predecible.Mtodos giles-Scrum y XP4



El desarrollo de software cae en la categora de desarrollo de un producto nuevo.Dr. Ricardo Quintero6



Muchos proyectos utilizan tecnologas nuevas (y no sencillas) que incrementan el grado de novedad y no predictibilldad.Estas tecnologas llevan a un inexperto a situaciones semejantes a las de la construccin de un nuevo producto, an cuando tenga experiencia preciaPor lo tantoo Debido a que el paradigma de manufactura predecible es elincorrecto para desarrollar software entonces ...Las prcticas y valores que tienen sus races en el mismo no resultan tiles.Considere el enfoque de cascadao Especificacin predictiva de las especificaciones, o Estimaciones y planes especulativos aplicables a la manufactura predecible, incorrectamente se han aplicado a los proyectos de software, un dominio que requiere trabajo inventivo, de alta razn de cambio y novedad.Ejercicio: Por qu estimaciones predictivas fallan?o Usando el artculo de Parnas y Clemens (1986) realice el ejercicio Porgu las estimaciones predictivas fallan?Por qu las estimaciones predictivas fallan? o Parnas y Clemens (1986) nos dan razones: Los clientes o usuarios suelen no estar seguros (de forma precisa) lo que quieren. Les resulta difcil establecer todo lo que quieren y desean. Muchos de los detalles de lo que realmente quieren solamente se revela al momento del desarrollo.Por qu estas estimaciones predictivas de estimacin fallan?o (cont..)Parnas y Clemens (1986) nos dan razones: Para las personas los detalles son abrumadoramente complejos. Conforme van viendo el producto desarrollado, van cambiando su mente (lo que desean). Factores externos (como el producto de un competidor o servicio) dirigen los cambios o extensiones en las solicitudes.La motivacin de los mtodos gileso La motivacin principal para los mtodos giles e iterativossubyace en la apreciacin de que:La actividad de construir software es compleja, con alto nivel de cambio y con naturaleza no predeciblePero tambin son motivados por el deseo de competir y ganarMtodos giles-Scrum y XP


Mtodos giles-Scrum y XP9

o Los mtodos giles e iterativos impulsan flexibilidad y maniobrabilidad: ventajas competitivas.Dr. Ricardo Quintero7


^ Pero tambin son motivados por el

^ deseo de competir y ganar

o Goldman y Preiss en su

libro Agile competitors and VirtuafOrganizations: Strategies for Enriching the r Customer nos ensean:AGILECOHPfTITORS

"Agilidad es acerca de xito y triunfo: xitoen salir triunfante en las arenas competitivas; triunfo en predicciones y clientes, en el centro de las tormentas competitivas que muchas empresas actuales enfrentan"VIRTUALORGANIZATIONSsmmXittwKNHOUNG CUSTOMER Steven L. Goldman Roger N. Nagel a Kenneth Preiss , us i*ff jQy17

^ Recursos Web

o www.aqilealliance.com

o www.cetus-links.orq

o www.bradapp.net

o alistair.cockburn.us

o www.martinfowler.com

18


Temaso MotivacinDesarrollo IterativoPlaneacin iterativa dirigida por losriesgos y por el clienteEl principio de "Time boxing"Desarrollo evolutivo y adaptativoEntrega incrementalEntrega evolutivaLos errores ms comunesDesarrollo iterativoLos mtodos giles son un subconjunto de los mtodos iterativos y evolutivos. Es un enfoque para construir software (o cualquier cosa) en el cual el ciclo de vida se compone por varias iteraciones en secuencia.Mtodos giles-Scrum y XP10



Cada iteracin es un mini-proyecto auto-contenido compuesto por actividades como anlisis de requisitos, diseo, programacin y pruebas.Dr. Ricardo Quintero10


Desarrollo iterativoEl objetivo final de una iteracin es obtener un re/ease de iteracin: un sistema parcial estable, integrado y probado.Es decir: Todo el software a travs de todos los equipos de desarrollo se integra en un release en cada iteracin.Los release pueden ser internos (para el equipo de desarrollo) o externos (para el cliente).Desarrollo iterativo e incremental (I ID)

La retroalimentacin (feedback) de la iteracin N dirige el refinamiento y adaptacin de los requisitos y el diseo en la iteracin N + lUna iteracin de 3 semanasEl Sistema crece incrementalmenteRELEASE AL CLIENTE

Longitud de las iteracioneso Muchos proyectos tienen al menos tres iteraciones antes de un release pblico final, o En los mtodos modernos:La longitud recomendada de una iteracin oscila entre 1 y 6 semanas.Disciplinas a travs de las iteracionesA cur-week Nation Disciplina de sustentabilidad: el roce humano. [oEl equipo como un Sistema Complejo Adaptativo.Disciplina de sustentabilidad: el toque humanoo No hay pocas historias de intentos en adoptar mtodos que requieren disciplina y esfuerzo, slo para terminar en poco tiempo con poco apego a los mismos, o Los factores sociales y psicolgicos necesarios para la adopcin sustentable se estn perdiendo.Disciplina de sustentabilidad: el toque humanoo Los creadores de algunos mtodos giles (XP, Crystal) reconocen que factores humanos como el disfrute, la simplicidad, el estmulo a corto plazo, etc; son ingredientes para crear un suelo frtil para la auto-disciplina sostenible en las prcticas.Disciplina de sustentabilidad: el toque humanoo Por ejemplo, el desarrollo dirigido por pruebas revela sus ventajas rpidamente a aquellos que lo usan, o Los desabolladores disfrutan la "pequea victoria" de pasar una prueba y la clarificacin en el diseo que viene a partir de escribir las pruebas antes de que el cdigo sea probado (prctica comn en XP).Agendao Desarrollo gil o Clasificacin de los mtodos o Los principios y el manifiesto gil o Gestin de proyectos gileso Abrazando la comunicacin y la retroalimentacin o Prcticas y herramientas de proyectos simples o Procesos empricos VS Procesos definidos y prescriptivos o Disciplina de sustentabilidad: el roce humano.(> El equipo como un Sistema Complejo daptativ;o; |El equipo como un Sistema Complejo Adaptativoo Algunos mtodos giles (ej. Serum) hablan de un equipo de desarrollo saludable como un Sistema Complejo Adaptativo (SCA). o Lo comparan con una "parvada de pjaros". Cada pjaro tiene reglas de comportamiento local relativamente simples, pero a nivel macro exhiben un comportamiento emergente, o Esto es distinto a una coordinacin dirigida por un lder.

El equipo como un Sistema Complejo Adaptativoo Los mtodos giles promueven el valor de que para proyectos creativos-inventivos una cultura inspirada en SCA es ms valiosa que el control y planeacin de los administradores. Ej.- En Serum los equipos son auto- organizados; la organizacin a nivel de equipo y adaptacin se realiza en la Serum meeting.Mucha promocin gil?o Visto como un todo los principios y prcticas giles (por ejemplo de XP o Serum) tienen un "sabor fresco" nuevo, o Se engloban en: Abrazar los cambios de requisitos. La comunicacin. La auto-organizacin de equipos. La planeacin adaptativa. Etc.Mtodos giles-Scrum y XP51



Y poseen algunas prcticas novedosas como el desarrollo dirigido por pruebas y la integracin continua.Dr. Ricardo Quintero22



Mtodos giles especficoso De acuerdo a una encuesta de Shine, XP y Serum son los mtodos giles ms ampliamente utilizados, o Serum: su nfasis distintivo entre los mtodos es su fuerte promocin a los equipos auto-organizados, a la medicin diaria de los equipos y el evitar seguir pasos predefinidos.Mtodos giles especficoso XP: es el mtodo gil ms conocido; enfatiza la colaboracin, rpida y temprana creacin del software; y buenas prcticas experimentadas de desarrollo. Se fundamenta en 4 valores:Comunicacin. Simplicidad.Retroalimentacin Coraje o valor.Mtodos giles especficoso Familia Crystal: fue desarrollada por Alistair Cockburn. o Al mismo tiempo que reconoce la necesidad del ciclo de vida iterativo, en este grupo de mtodos Cockburn favorece los aspectos del "peopleware" sobre los procesos: comunicacin, educacin, etc. o Su definicin del desarrollo de software: "un juego cooperativo de invencin y comunicacin.Mtodos giles especficoso Familia Crystal: diferentes versiones de Crystal (Clear, Yellow,...) contienen incrementalmente "peso del mtodo como una funcin del tamao del staff, criticalidad y prioridad del proyecto, o Se selecciona el tamao y la criticalidad y se mapea a una versin particular Crystal con un "peso del mtodo" recomendado, o Utilizaremos este modelo para clasificar Scrum y XP.

Familia CrystalLife (L)16L20L40X100

Essential money (E)E6E20E40E100

Diserri onaiy money (D)D 6D20,D40D100

Comfort (C)C6C20C40C100

Cockburn ScaleCriticalityThe Cockburn Scale1-6 -20 -40 -100 Number of people

Modelado gilproject types may need quite different method weights

Es un conjunto de principios y prcticas para el anlisis de requisitos y modelado que complementa a muchos mtodos 11D.El Modelado gil promueve la creacin colaborativa "low-tech, high-touch con modelos que ayuden ms al entendimiento y la comunicacin.Mtodos giles-Scrum y XP54



Sus prcticas promueven velocidad, simplicidad y creatividadDr. Ricardo Quintero25



Prcticas del Modelado gilMtodos giles-Scrum y XP58



Refinamiento iterativoSimplicidad


1

Dr. Ricardo Quintero

Crea varios modelos en paraloEj. un diagrama de clases y uno de secuencia relacionadosItera a otros artefactosEj. 5% de un diagrama de clases, despus 5% de un diagrama de secuenciaUsa la herramienta ms simpleEj. pi2arrn blanco & cmara; videoDespliega los modelos de forma simpleEj. en la pared; no en una pgina Web

Trabajo en equipoDocumentacin

Descarta modelos temporalesEj. toma una foto; borra el pizarrnActualiza solo si vale la penaEj. desarrollar el cdigo es ms importante que mantener el diagramaModela con otrosEj. diagramacin en parejasDespliega los modelos pblicamenteEj. Datos de gestin del proyecto en las paredes

55

Otros mtodos y prcticas

Adaptative Software Development (DSA):V0050tv

J im Highsmith.Dynamic Solutions Delivery Model (DSDM). Feature-driven Development (FDD);voo*J?or,

J eff De Luca y Peter Coad.Lean Development:Mary and Tom PoppedieckPragmatic programming: Andy Hunt and Dave Thomas.www. praqmaticproqram mer.com

56El Desarrollo Iterativo y Evolutivo: Scrum y XP

Tema 3: Serum (Dr. Ricardo Quintero)

Temaso[Clasificacin de Serumo Workproducts, roles y prcticas o Errores comunes, adopcin y mezcla de procesos, fortalezas y debilidadesDr. Ricardo Quintero

Serum: prcticas claveo Serum es un trmino con el que se identifica una jugada de Rugby en la cual un par de equipos se disputan la posesin del baln una vez que se ha reanudado un juego por alguna interrupcinSerum y Rugby

o Equipos auto-dirigidos y auto- organizados.o Una vez seleccionado, no se agrega trabajo adicional a una iteracin, o Reunin diaria "de pie" con preguntas especiales, o Iteraciones de 30 das (generalmente), o Demo a los stakeholders al final de cada iteracin,oEn cada iteracin, planeacin adaptativa dirigida por los clientes.Mtodos giles-Scrum y XP

Serum en la escala de ciclos y ceremonia64

3Dr. Ricardo Quintero


Oo

EstrictamenteF lexi ble en el grado de "5ecuenc 131) ceremonialidad pero se recomienda "as little ceremony as possi ble".Pocos documentos Pocos pasos CeremoniaPreciso en la longitud de las iteraciones (30 das), no en el nmero de iteraciones.Muchos documentos Muchos Pasos formalesScrum I- f; . i r~til? :

Muchas iteraciones pequeas (5 das)Serum en la escala de Cockburnf/1 L6SerumCrystalLeanLife (L)L20L40L80L200r~E6dsdm.E40xp'N^E20AUP\E200\E80Essential Money(E)

Discretionary Money (D)VD20D40D80D200C40C6C20^C80FDD .C200Comfort (C)

1-6 -20 -40 -100 -200 Number of PeopleTamao de equipos1 equipo de Serum debe ser de 7 o menos participantes.Mltiples equipos pueden formar un proyecto. Pueden tenerse "Serum de Serums" donde varios equipos pequeos trabajan juntos y tienen una reunin diaria con representantes de cada equipo. Serum es complementario a otras prcticas de tal forma que puede aplicarse a otros dominios de software (desde misin crtica hasta ms casuales).Promueve valores y prcticas de gestin de proyectos (ms que de requisitos, implementacin, anlisis, diseo, etc.). Por eso puede combinarse con otros mtodos.Mayor nfasis en procesos empricos que en predefinidosAgile Software Development with Scrum

Ken Schwaber, uno de losfundadores de Serum cuenta la siguiente historia: "Deseaba entender porque los procesos de mis clientes (cascada y definidos- detall admente) no trabajaban para mi compaa de software, as que en 1995 traje varias metodologas a los expertos de teora de procesos en el DuPont Experimental Station. Estos expertos, dirigidos por Babatunde Ogannaike, son los expertos teoristas ms respetados en procesos de control industrial...

Mayor nfasis en procesos empricos que en predefinidoso "..Inspeccionaron los procesos de desarrollo de sistemas que les lleve. Raramente haba visto un grupo que se riera tanto. Estuvieron sorprendidos y asustados de que mi industria (de software) estuviera tratando de hacer su trabajo usando un modelo de control de procesos completamente inapropiado. Decan que el desarrollo de sistemas tena mucha complejidad e impredecibilidad por lo que tena que ser manejado por un modelo de control de procesos que referan como "emprico". Decan que eso no era totalmente nuevo y que todos los procesos complejos que no estuvieran completamente entendidos (o que tenan entradas cambiantes) requera el modelo emprico (y no un modelo definido de procesos) ..."Mayor nfasis en procesos empricos que en predefinidosMtodos giles-Scrum y XP65


Mtodos giles-Scrum y XP#

o ...[Ogannaike] me dijo que mi negocio era un negocio intelectualmente intenso que requera de mucho intelecto y creatividad para ser un buen candidato para un enfoque predefinido...Estaba particularmente sorprendido de que las tareas estuvieran enlazadas con dependencias (tipo PERT), como un proceso industrial bien definido.."Dr. Ricardo Quintero4



Mtodos giles-Scrum y XPMayor nfasis en procesos empricos que en predefinidos67

oLas palabras de Ogannaike recuerdan los procesos industriales de Deming y Shewhart que poseen nfasis en ciclos Plan-Do-Study-Act para ambientes complejos y cambiantes. (El ciclo de Shewart o la rueda de Deming).6

7

7

CwignPlan'How'ArfllysSpedfy'WnafShewart"cycleEmbateCh*See"ExecuteCcnstrilDoll

Ciclo de vida de Serum: 4 fases para una entrega (release)Planeacin(Pre-juego)Montaje (Pre-juego)Desarrollo(Juego)Entrega(pos-juego)

Propsito:Establecer la visin, expectactivas y aseguramiento financieroPropsito:Identificar la mayora de los requisitos y priorizarlos para la primer iteracin.Propsito:Implementar un sistema listo para entregarse en una serie de iteraciones (Sprints) de 30 dasPropsito:-Instalacinoperacional.

Actividades:-Definir la visin, presupuesto, Product Backlog inicial y estimacin de sus Items.-Diseo exploratorio y prototipos.-Diseo de la Arquitectura de alto nivelActividades:-Planeacin.-Diseo exploratorio y prototipos.Actividades:-Junta de planeacin para el Sprint definiendo el Sprint Backlog y estimaciones.-Juntas diarias Serum.-Revisin del SprintActividades:-Documentacin. -Entrenamiento. -Mercadeo & Ventas.

12

Dr. Ricardo QuinteroMtodos giles-Scrum y XPCiclo de vida de Serum68

Especlflc.Re>quenim.Prueba de AceptacinCreadn del ConceptoPrueba de UnidadPrueba d IntegracinPrueba del SistemaDiseoCodigoPre-Juego-A-Pos-Juegoy-.JuegoPlaneamienioProductofinal,DocumentosIntegracin.Prueba deSistema

iRelease , Intermedio/Qiflo iJ AltP Nivel / Arquitectura

13

Ciclo de vida de Serum

Swire: Alluri rn f\\Vi lottarv ff. it-i r J,: I.U.. Scelta.Daily Serum MeetingDemonstrable new functionalityBacklog tasks expandedSprint BacMog ^ by teamProduct BacMog As pnontized by Product Owner


TemasoClasificacin de SerumWorkproducts, roles y prcticasMtodos giles-Scrum y XP#


oErrores comunes, adopcin y mezcla de procesos, fortalezas y debilidades



15

Workproducts (entregables no-software) de las diversas disciplinasRequisitosDiseo

I ncluye todos los tems del producto.El Release backlog es un subconjunto del Product Backlog (PB).Incluye: caractersticas. UC. extensiones, defectos, tecnologas, etcPruebas & VerificacinI mplementacin

Gestin del proyectoSpnnBacklogBacklogGraphEstimacin del trabajo restante VS los das restantes.Tareas para la Iteracin. Granularidad de 4 a 16 hrs.Configuracin & Ambiente de Gestin de Cambios

16Workproducts (o entregables)o Adems de los que se mencionan, Serum permite cualquier Workproduct quedevaloral proyecto. Los principales son: El Product Backlog. El Sprint Backlog. El grfico del Sprint BacklogWorkproducts-Product Backlog (Requisitos)o Product Backlog: Incluye una lista de todos los items" concebibles del sistema, priorizados por el Product Owner (el cliente).o Es una lista maestra de toda la funcionalidad deseada en el producto, o Incluye estimaciones de esfuerzo (enMtodos giles-Scrum y XP70



unidades de tiempo-hombre) de cada item". En principio definidas burdamente pero refinadas despus una vez que los miembros del equipo se comprometen29Dr. Ricardo Quintero



Workproducts-Ejemplo de Product BacklogAB CDE I F

1Product Backlog

2

3RequirementHum CategoryStatusPri Estimate I

4log credit payments to AR17 featureunderway5 2

5process sale-simple cash scenario232 use caseunderway5 60

6slow credit payment approval12 issuenot started4 10

7sales commission calculation43 defectcomplete4 2

8lay-away plan payments321 enhancenot started3 20

9PDA sale capture53 technologynot started1 100

10process sale-credit pmt scenario235 use caseunderway5 30

Workproducts-Product BacklogI him c (xiuiuWn I iti I Bv

IfinWi iihi|15141

G*l !< *4 ^llJ Awl m itMAfc.M*8Ml

ft.ll li-.mmi

Cri'EJ(IK*iinjISTG

F nun *i h(c-'T at cad xa160T&

K-jl.CHi*3 (/-p Ai^miMC

EiiIm *cw ip >n n me pet In ir lowor 1/2 ti aiNy^s titCum*to! Ufi lMOir^0IG

iilTLA

12C) xgitd rwtoci1rt*.

ItHmroalil c/(WlnjUriA

l'cpullllMI iMMIIn

11Mi'll'*33TiM

15Ojerf Tic0!4M

ii.'43IlM

17Ju VMU MU|tf.*3IV,d neglecting EQthe top-pnonty items!Owe I SWT CC



m



Workproducts-grfico Sprint Backlogo Grfico Sprint Backlog: es un resumen visual de la estimacin de tiempo restante de las tareas del Sprint Backlog.o Es considerado el dato ms crtico del proyecto.o Recomendacin:Colocar en la pared y actualizar diariamente una versin de este Workproduct para la junta diaria de Serum.A Workproducts-grfico Sprint Backlog

rSprint^

r

|

Oay o Mor*/

34


Workproducts-grfico Sprint Backlog79

18

18

ProgressNotse que el equipo hace un ajuste en las tareas del Sprint actual cuando restaban 619 horas y se han percatado que es mucho trabajo y el Sprint corre el riesgo de no cumplirse (remueven tareas)

1J2_\\y25^1*rW4:0

35

RolesCustomerUna persona responsable de crear y priorizar el PB.A partir del PB selecciona los objetivos del siguiente Sprint. Junto con los stakeholders. revisa el sistema al finalizar el Sprint.DevelopmentTrabaja en el Sprint Backlog (iteracin).Cada miembro es, solamente, un "miembro del equipo (team member).Cu*toroerJJSerum T&tmJProduct OwntrOtherManagement50% desabollador, no slo administrador.Conoce y refuerza la visin y objetivos del proyecto e iteracin.Asegura que los valores y prcticas se sigan.Media entre la administracin y el Serum team.Monitorea el avance y elimina obstculos.Conduce la reunin diaria de Serum. Conduce la revisin del Sprint (demo).Chic KonsTodos los dems pueden observar, pero no interferir o hablar durante una iteracinjSerum Uatfer


Prcticas-una puede soportar mltiples disciplinasMtodos giles-Scrum y XP80



Requisitos19Dr. Ricardo Quintero



Pruebas & VerificacinrI mplementacin

/ Spnm j

Gestin del proyectoCticfcons I /f're Gain I and Pqs IConfiguracin & Ambiente de Gestin de Cambios

Dedonsi GtocfcGono|H ( valores)-U-

In I Hour | -tOn | | Tm17 I

Core practices-Requisitoso Pre-juego Planeacin y montaje: Todos los stakeholder pueden contribuir para crear una lista de caractersticas, UC, extensiones, defectos, etc y registrar en el Product Backlog. Se designa un Product Owner y las solicitudes se hacen a travs del mismo. En esta sesin se genera el trabajo para, al menos, la primer iteracin. Se identifica el Release Backlog, un subconjunto del Product Backlog que definir al siguiente producto operacional.Core practices-Requsitoso Planeacin de Sprint:Antes del inicio de cada Sprint se manejan dos juntas:1) Los stakeholders refinan y re-priorizan el Product Backlog y el Release Backlog para seleccionarlos objetivos de la siguiente iteracin, dirigidos por valor del negocio o riesgo.2) El Serum Team y el Product Owner serenen para definir como lograr las tareas y crear el Sprint Backlog (en unas 4 a 16 hrs). Si el esfuerzo estimado excede los recursos, ocurre otro ciclo de planeacin.Core practices-Requsitoso Planeacin de Sprint:Conforme la iteracin procede, el Sprint Backlog se actualiza, es comn que sea diario durante la parte inicial de la iteracin, conforme nuevas tareas se descubren.Al paso del tiempo (y con experiencia), el equipo mejora en la elaboracin del Sprint Backlog.mPlaneacin del Sprint-Aspectos prcticoso Es, quiz, el evento ms importante de Serum. Una mala planeacin puede llevar al fracaso todo el Sprint. o Resultados de la planeacin:El objetivo del Sprint.Una lista de los miembros del equipo y sus niveles de compromiso.El Sprint backlog.Una fecha definida para el Sprint demo.Una hora y lugar definidos para la junta diaria de Serum.mPlaneacin del Sprint-Aspectos prcticoso El Product Owner la debe atender. De no hacerlo, el mtodo se ver seriamente comprometido en su xito, o El tiempo del reunin debe respetar el principio de time-boxing (al principio puede ser difcil e incluso no lograrse una reunin satisfactoria, pero an as persiste, la prxima reunin se vern presionados a dar resultados en el tiempo estipulado).mPlaneacin del Sprint-Aspectos prcticoso Agenda ejemplo (8:00 a 12:00 hrs) 8:00 a 8:30 - El Product Owner define el objetivo y sumariza el Product Backlog. Se define lugar del Demo, hora y fecha. 8:30 a 10:00 - Estimaciones de tiempo de las HU, posibles divisiones de las mismas. El Product Owner puede repriorizar las HU. Se clarifican las HU. Se llenan todos los "Demos" de cada HU en el PB. 10:00 a 11:00 - El equipo selecciona las HU a incluir en el Sprint. Se calcula la velocidad del equipo. 11:00 a 12:00 - Se determina la hora y lugar de la junta diaria de Serum. Se dividen las HU en Tareas.Core practices-Requisitoso Revisin de Sprint:Al finalizar cada iteracin, hay una reunin de revisin (max. 4 hrs) convocada por el Scrum master. Participan el equipo, el Product Owner y otros stakeholders.Se muestra un demo del producto para informar a los stakeholders de la funcin del producto, diseo, fortalezas, debilidades, esfuerzo del equipo y futuros puntos de problema.HCore practices-Requsitoso Revisin de Sprint:Se motiva al feedback" y a la lluvia de ideas sobre las direcciones futuras, pero no se establecen compromisos. En la siguiente reunin de Sprint planning, los stakeholders y el equipo harn los compromisos.Prohibido presentaciones en Power Point. El nfasis en la presentacin es en mostrar el producto.mRevisin de Sprint-Aspectos prcticoso Asegrate de presentar claramente el objetivodel Sprint. Si en la reunin hay gente que no sabe nada del producto, da alguna explicacin, o Enfcate en presentar el producto, no presentaciones en PowerPoint, o Procura que tu demo sea sobre escenarios fciles y giles de presentar (ms que cuestiones estticas), o Manten la demo a nivel de funcionalidad (el Qu?)y no tecnicismos (el Cmo?), o Si es posible, trata que el auditorio pruebe el producto.o No muestres arreglos o caractersticas pequeas. Enfcate en lo importante.Mtodos giles-Scrum y XP83






Core practices-Project Managemento No agregar a una iteracin:Durante una iteracin, la administracin no agrega trabajo al equipo o individuos. Se busca un "enfoque ininterrumpido".En el raro caso de que algo tenga que agregarse algo deber removerse.Pero, antes de cada nueva iteracin el Product Owner y la administracin tienen el derecho y la responsabilidad de re-priorizar el Product Backlog e indicar que hacer en la siguiente iteracin, de tal forma que la requisicin de trabajo no exceda los recursos.ICore practices-Project Managemento Cerdos y gallinas:Durante la Serum meeting, slo el Serum Team puede hablar (the Pigs). Los dems pueden atender a la reunin, pero se mantienen en silencio (the chickens), an el jefe.Slo se les permite "feedback" para puntos de explicacin relevante del negocio para el trabajo del equipo."Huevos con jamn-Quin est involucrado y quien comprometido? El cerdo o la gallina?"Core practices-Project Managemento Serum Master firewall:El Serum Master debe asegurarse de que el equipo no sea interrumpido por solicitudes de trabajo de terceros y de ocurrir, removerlas y manejarlas con "inteligencia".El Serum Master debe asegurarse de que el mtodo de Serum se aplique, removiendo obstculos, proveyendo recursos y tomando decisiones.Debe tomar la iniciativa cuando ve que las reuniones no estn completando su trabajo o si el equipo no est participando (hablando, por ej.)ICore practices-Project ManagementSerum diario:Cada da de trabajo en el mismo lugar y hora, se tiene una reunin con los miembros del equipo (en crculo), en el que se realizan las preguntas especiales Serum para cada miembro: i) Qu hiciste desde el ltimo Serum?2i Qu hars desde ahora y hasta el siguiente Serum?3i Qu obstculos tienes para alcanzar los objetivos?i) Alguna tarea a agregar al Sprint Baeklog? s) Haz aprendido o decidido algo nuevo, de relevancia para alguno de los miembros del equipo?1Core practices-Project Managemento Serum diario:La reunin es mejor manejarla en crculo para motivar a la brevedad.En promedio 15 a 20 minutos para 7 a 10 personas. Reuniones ms largas pueden tenerse al inicio de la iteracin.Miembros que no son del equipo (chickens) estn fuera del crculo.Se maneja junto a un pizarrn en el cual las tareas y obstculos se van escribiendo.El Serum Master borra los obstculos slo cuando han sido removidos1Core practices-Project ManagementSerum diario:Puede existir alguna forma de comunicacin externa para miembros no presentes.El Serum Master asegura que las reglas se sigan y prepara el lugar para una reunin eficiente. Debe empezar a la hora.Ninguna otra discusin se permite que las 5 preguntas. El Serum Master tiene la autoridad de reenfocar la discusin.Si otros aspectos necesitan discusin, se pueden tener reuniones secundarias inmediatamente despus del Serum meeting con subconjuntos del Serum team.



1



Serum diario-Aspectos prcticoso En el Sprint Backlog "de hombre pobre" cada miembro del equipo puede actualizar el tiempo restante de cada tarea, es muy importante que todos actualicen sus tareas. Si esta tarea se deja slo al Serum Master, ser mucho trabajo:WriteWriteWrite

failingfailingfailing

2d testtest3d24 test , 34

1Serum diario-Aspectos prcticosQu hacer con los impuntuales? Puede pagar una "multa" y usar luego el dinero para algn evento social Qu hacer con los que no saben que hacer el da actual"? Se les escucha (sin discutir) y luego se lleva a todo el equipo al Sprint Backlog para que adecen o agreguen nuevas tareas. Con el SB actualizado se les pide a los "susodichos" que seleccionen lo que harn el da de hoy. En ocasiones, si esto no funciona, el Serum Master tendr que realizar coaching ms personal (incluso decidir si vale la pena seguir con ese miembro o no en el equipo).1Core practices-Project Managemento Decisiones en 1 hora:Los bloqueos reportados en el Serum Meeting y que requieren decisin del Serum Master deben decidirse, idealmente, inmediatamente o dentro de 1 hora.Se promueve el valor de "Es mejor tomar malas decisiones a no decidir. Las malas decisiones se pueden revertir"ICore practices-Project Managemento Remocin de bloqueos en 1 da:Los bloqueos reportados en el Serum Meeting deben removerse idealmente antes de la siguiente reunin.Mtodos giles-Scrum y XP88






Core practices-Project Managemento Equipos de 7:Serum se puede escalar a proyectos grandes, pero recomienda tener un mximo de 7 miembros.Mtodos giles-Scrum y XP90



Proyectos ms grandes se manejan como multi-equipo.29Dr. Ricardo Quintero



57

Core practices-Project Managemento Serum of Serums:Se pueden manejar para multi-equipos reuniones de Serum de Serums.VA,YA

Core practices-Project Managemento Sprint:El trabajo generalmente se organiza en iteraciones de 30 das de calendario; cada una llamada un Sprint.Core practices-Project Managemento Equipos auto-dirigidos y auto- organizados:Se empodera al equipo con autorizacin y recursos de tal forma que caminen a su ritmo y resuelvan sus problemas.El Serum Master y la administracin proveen recursos y remueven obstculos.Es el reto ms fuerte para la adopcin de Serum.mCore practices-configuracin & Ambiente de Gestin de Cambioso Cuarto comn del proyecto:Idealmente el equipo trabajo junto en un espacio comn para el proyecto, en lugar de oficinas separadas o cubculos.Para otras actividades se pueden considerar los espacios separados y privados.Se han reportado casos de xito con equipos geogrficamente dispersos que participan mediante comunicacin virtual.iCore practices-configuracin & Ambiente de Gestin de Cambioso Construccin diaria:Al menos una integracin diaria y una prueba de regresin a todo lo largo del cdigo verificado.Ms adelante veremos la prctica de Integracin Continua de XP que es an mejor.1Valores que promueve SerumCompromiso: Dado que el Serum Team se compromete a metas definidas por iteracin y se le da la autonoma y autoridad para decidir como alcanzarla. Dado que la Administracin y el Serum Manager se comprometen a no introducir nuevo trabajo, eliminar obstculos y proveer recursos. El Product Owner se compromete a definir y priorizar el Product Backlog, guiar los objetivos por iteracin y revisar y ofrecer "feedback" iteracin a iteracin.Valores que promueve Serumo Enfoque: Dado que el Serum Team se enfoca en los objetivos establecidos de la iteracin, sin distracciones.El Serum Master y la administracin se enfocan en proveer recursos, remover obstculos y evitar interrupciones al equipo con solicitudes adicionales.Valores que promueve Serumo Apertura:El Product Backlog est disponible para visualizar el trabajo y las prioridades. Las Daily Serums hacen visible el estado general de los individuos y sus compromisos. La velocidad del trabajo y su tendencia es visible con el Backlog graph.Valores que promueve SerumRespeto: Ms responsabilidad de equipo que "chivos expiatorios". Los miembros del equipo se respetan por sus debilidades y fortalezas y no por sus fallas en las iteraciones. El equipo completo (ms que el administrador), mediante auto-organizacin y direccin, adopta la actitud de resolver problemas "individuales" mediante la exploracin grupal de soluciones dndole los recursos y la autoridad para reaccionar a los retos (tal como traer un experto consultor para compensar sus carencias de expertise).Valores que promueve Serumo Coraje:a La administracin tiene el coraje de planear y guiar adaptativamente y confiar en el equipo evitando decirles que tienen que hacer. El equipo tiene el coraje de tomar la responsabilidad de la auto-direccin y la auto-gestin.Temaso Clasificacin de Serum o Workproducts, roles y prcticas(Errores comunes, adopcin y

mezcla de procesos, debilidadesfortalezas y







Errores comunes y malos entendidoso No ser equipo auto-dirigido; los administradores o el Serum Manager dirige u organiza el equipo, o No actualizar diariamente el Sprint Backlog. o Agregar nuevo trabajo individual o a la iteracin, o El Product Owner no se involucra o no decide, o No hay Sprint Review. o Muchos masters.o La documentacin es mala: no se habl de documentacin, pero el principio ya se ha comentado -aquella que agregue valor al proceso-.Errores comunes y malos entendidoso El diseo o la documentacin es mala: lo mismo que la documentacin, o Serum meetings muy largas o no enfocadas, o La iteracin no termina en un producto parcial integrado y probado, o Cada iteracin termina en un release de producto.o Planeacin predictiva. Planeacin tipo PERT.Mezcla de procesos: Scrum+UPo Las prcticas de Serum son guales o especializaciones de las prcticas de UP o son adiciones consistentes.o Aunque Serum no promueve orden en las actividades, se puede aprovechar el orden de UP para los Sprints.o Cuando estudiemos XP veremos su mezcla con SerumEstrategias de adopcinMtodos giles-Scrum y XP#



o En contraste a la recomendacin precautoria de UP (un proyecto piloto), los creadores de Serum motivan a las organizaciones para adoptarlo en su proyecto ms difcil y crtico, o Esta recomendacin atrevida la sustentan en la visin que tienen los creadores de que es una medicina fuerte con una alta razn de xito.35Dr. Ricardo Quintero

Dr. Ricardo Quintero


Estrategias de adopcino Despus de que inicia el primer proyecto, pero no antes de la segunda iteracin (es decir, cuando todas las prcticas se han probado) administracin ajena al proyecto y clientes potenciales se les puede invitar para observar los Serum meetings, Sprint Planning y Sprint Reviews.o Los proyectos de segunda generacin de Serum pueden iniciar antes de complementar los primeros, aunque se debe dar tiempo de madurar al primero (algunas 3 iteraciones). Los miembros del equipo del segundo equipo se pueden beneficiar al atender alguna de las reuniones del primer equipo.^ Lecturas recomendadas

o La biblia de Serum es: Agile Software Development with Serum

Agile Software Development with Scrumredyellow

bluered

yellow

blueKen Schwaber M Ike Beedie

74

Ejercicioo Realizaremos un ejercicio de Serum, o Se formaran 3 equipos (no ms de 7 integrantes),oEste es el Product Backloq.



oEste es el ejercicio.



EJERCICIO - Porqu estas estimaciones predictivas fallan?LECTURA: A rational design process: How and Why to fake it1) Lea la parte I.- THE SEARCH FOR THE PHILOSOPHER 'S STONE: WHY DO WE WANT A RATIONAL DESIGN PROCESS? Conteste las siguientes preguntas:a. Qu se entiende por una persona racional?b. Porqu el proceso de desarrollo de software es considerado irracional?c. Cul es

el propsito de los mtodos de desarrollo de software?2) Lea la parte II.- WHY WILL A SOFTWARE DESIGN PROCESS ALWAYS BE AN IDEALISATION? Identifique las 7 razones por las cuales el desarrollo de software es considerado irracional. Escrbalas en una sola lnea:a. b c. d. e. f. g 100

102

101

3) TAREA: En casa lea el resto del artculo. Escriba sus comentarios sobre el disfraz que es necesario colocar a nuestro proceso de desarrollo de software.2

1

A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE ITDavid L. Parnas Computer Science Department University of Victoria Victoria BC V8W 2Y2 Canada andComputer Scicnce and Systems Branch Naval Research Laboratory Washington DC 20375 USAandPaul C. Clements Computer Science and Systems Branch Naval Research Laboratory Washington DC 20375 USAI. THE SEARCH FOR THE PHILOSOPHER S STONE: WHY DO WE WANT A RATIONAL DESIGN PROCESS?A perfectly rational person is one who always has a good reason for what he does. Each step taken can be shown to be the best way to get to a well defined goal. Most of us like to think of ourselves as rational professionals. However, to many observers, the usual process of designing software appears quite irrational. Programmers start without a clear statement of desired behavior and implementation constraints. They make a long sequence of design decisions with no clear statement of why they do things the way they do. Their rationale is rarely explained. Many of us are not satisfied with such a design process. That is why there is research in software design, programming methods, structured programming and related topics. Ideally, we would like to derive our programs from a statement of requirements in the same sense that theorems are derived from axioms in a published proof. All of the methodologies that can be considered "top down" are the result of our desire to have a rational, systematic way of designing software. This paper brings a message with both bad news and good news. The bad news is that, in our opinion, we will never find the philosopher's stone. We will never find a process that allows us to design software in a perfectly rational way. The good news is that we can fake it. We can present our system to others as if we had been rational designers and it pays to pretend do so during development and maintenance.II. WHY WILL A SOFTWARE DESIGN "PROCESS" ALWAYS BE AN IDEALISATION?We will never see a software project that proceeds in the "rational way. Some of the reasons are listed below:(1) In most cases the people who commission the building of a software system do not know exactly what they want and are unable to tell us all that they know.(2) Even if we knew the requirements, there are many other facts that we need to know to design the software. Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack. Because we try to minimize lost work, the resulting design may be one that would not result from a rational design process.(3) Even if we knew all of the relevant facts before we started, experience shows that human beings are unable to comprehend fully the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. However, until we have separated the concerns, we are bound to make errors.(4) Even if we could master all of the detail needed, all but the most trivial projects are subject to change for external reasons. Some of those changes may invalidate previous design decisions. The resulting design is not one that would have been produced by a rational design process.(5) Human errors can only be avoided if one can avoid the use of humans. Even after the concerns are separated, errors will be made.(6) We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to try out or use a favourite idea. Such ideas may not be derived from our requirements by a rational process.(7) Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situations, we may be encouraged to share our software with another ongoing project. The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its requirements alone, but it is good enough and will save effort.For all of these reasons, the picture of the software designer deriving his design in a rational, error-free, way from a statement of requirements is quite unrealistic. No system has ever been developed in that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen.EJERCICIO - TimeboxingLECTURA: Timeboxing for top team performance1) Lea la INTRODUCCIN. Conteste las siguientes preguntas:a. Segn el autor Cul es la definicin de un proyecto exitoso?b. Complete:Timebox: Define y establece unypara que lo queadecuado.es lo ms

despus se ajusta el103

104

#

se desea entregar se entregue en Esto asume que

importante y frecuentemente lo es. Hay otros aspectos a considerar tambin:

.. Msy

adelante los revisaremos.2) Lea la parte THE IRON TRIANGLE.En un proyecto, los recursos suelen ser fijos. Lo que se puede manejar es lo siguiente (defina):a. Schedule:b. Scope:c. Quality:3) Se les llama el Tringulo de hierro por su relacin inmutable. El autor menciona dos ejemplos de esta relacin. De acuerdo a su experiencia, proporcione un ejemplo ms:EJEMPLO:4) Lea: THE LAST FEATURES y conteste: Cul es la mejor estrategia de TimeBoxing?5) Revise la Figura 2 The 90/90 Rule. De que forma timeboxing contribuye a que el 10% de un sistema no nos tome el 90% del tiempodisponible?6) Lea: THE RIGHT FEATURES. Conteste Como seleccionar las caractersticas que primero se deben entregar en unsistema?

7) Lea: INCREMENTAL RELEASES. Mencione los pasos que sigue la estrategia de Jim McCarthy de Microsoft para entregas incrmentales: (gotta have=consigue tener; should have= debera tener; nice to have=sera bueno tener)a. b c. d .e. f. 8) Lea: STOP APOLOG1ZING Cul fue la enseanza que Bill Gunther le ense alautor cuando era un joven ingeniero de Sistemas deIBM?Cul es tu opinin al respecto?105Timeboxing For Top Team PerformancebyRick ZahniserWhats your definition of a successful software project? How about this:A successful software project delivers a quality product on time, within budget.Time is always a factor in software development, and developers are always complaining about it.They didnt give us enough time.They didnt let us estimate; they just told us when it was due.We had to skip most of the system testing in order to deliver on time.Timeboxing grabs that problem by the horns and wrestles it to the ground. (Forgive me Im from Colorado!) We set an end time - that is, a timebox - and then adjust our scope so that we deliver what we can within the time allotted. This presumes that the schedule is the most important aspect of the project, and frequently it is. Now there are other aspects, including resources, development skill, scope and quality. Lets look at these aspects realistically, with an eye to managing them so that we look good!The Iron TriangleOn a given project, resources are usually fixed; and unless you believe in the Mongolian Horde Approach (hire a hundred people and hope some of them are good) the best team is a small one. Once youve put that team together, youve established their capability, at least in the short run. Now you have three aspects to manage, as shown in Figure 1.Schedule: The time when the software product is due.Scope: The functions and features delivered in the software product.Quality: The absence of defects in the product.I call these three The Iron Triangle because they have an immutable relationship. For example:1. If we increase the scope, the schedule must grow, or the quality must decline.2. If we shorten the schedule, we must decrease the scope or deliver with more defects.The best timeboxing strategy holds quality constant and reduces scope to meet a schedule. Reducing scope flies in the face of what I call The Worlds Greatest Program syndrome -- the tendency on the part of developers to put every great feature into the first release, even if it causes us to be late. (Roland Racko calls this creeping or galloping elegance.) The customer always wants those features; they just dont understand how much it will cost them. Id like to acquaint you with the facts, so you can feel good about leaving some features out when youre approaching the end of your timebox.The last featuresThose latest and greatest features cost more than you expect, and heres why. Remember the 90:90 rule:The first 90% of a system takes 90% of the time:The last 10% takes the other 90% of the time!That sounds like a joke, but Figure 2 shows why its true. As we approach 100% complete, our progress slows down drastically. This is because were making tough decisions in the face of uncertainty. Moreover, theyre not very good decisions. We will probably have to make many of them over again, when we have more information. This last 10% also accounts for much of the arguing and fighting that goes on in a project. Timeboxing forces us to forgo these last features, but it also lets us avoid most of the conflict that goes with them.Paretos Law - the old 80:20 rule - gives us another justification for procrastinating on those last features. In the systems world, it predicts that:20% of the system will give us 80% of the payback.Now, in reality, this 20% only applies to a particular set of users. If we have a diverse set of users, we will have to106give each group a different 20%, but its reasonable to expect that we can please the vast majority of our users with 80-90% of the features. Sooner or later, were going to deliver those last features, but not right now!The right featuresMaking Paretos Law work for you may sound like magic, but there actually is a systematic way of finding out what features you should deliver first. Ask your customers to rank the features they want. You can do this most easily in a group meeting of customers and developers.Write each feature on a Post-it, put these on a whiteboard, and have the group rank them (1 is high, 10 is low.). Then ask your developers to estimate how difficult each feature will be to implement (1 is easy, 10 is hard) and multiply these two to give you a priority weight for each feature. On the whiteboard, build a matrix like the one Ive shown in Figure 3. It will show you, the team and the customers which features you should implement first and which you might postpone. (Quality practitioners will recognize this process as a part of QFD or Quality Function Deployment.)Incremental ReleasesThis whole process of managing features is the best way to stage incremental releases of a software product. Jim McCarthy, Program Manager for Microsoft C++ products, asserts that you can build customer confidence through a series of timely releases, which delivers a steady stream of new features. To do this, he says you have to get into a stable state, and be ready to ship at any time.Heres a strategy for delivering that first release:1. Define your features.2. Prioritize them.3. Define three subsets: Gotta have Should have Nice to have3. Build the gotta have subset as a prototype. Define a timebox, start prototyping, and deliver what you have when you run out of time. (Since its a prototype, you wont have trouble explaining why it looks incomplete.)4. Use this early experience with the prototype to define timeboxes for your first incremental release.5. Stay within your timeboxes, delivering the features you have ready, on time.Maintaining QualityIf youre in a stable state, you have a much better chance of controlling quality. A couple of basic metrics will demonstrate stability and dramatically improve your ability to deliver a quality product as you reach the end of a timebox. You need Defects Discovered, and Defects Corrected for each time period (days or weeks.) Figure 4 is a graph of these two measures; you can also derive (and graph) other important measures such as Defects Remaining and Mean Time to Repair.Who does this defect tracking and graphing? According to McCarthy, Microsoft has a ratio of one Quality Assurance (QA) person for every two developers on the team. This graph is a great way for QA to highlight the coordination between these two factions on your team.You can timebox anythingSo far, weve been talking about timeboxing for product delivery. As I began studying the literature on timeboxing (see sidebar) I realized that I had been doing a form of timeboxing for over a decade. Training companies frequently have a set format for their courses; for example, all of their courses may be four days long. To build a course, you start with an overall four-day timebox, and break that down into smaller timeboxes to fit within breaks and lunches. That realization led me to try timeboxing in our methodology experiments at CASELab. We put every activity into a one-to two-hour timebox and gave the participants an opportunity to expand the box a little but not more than 20%.

Timeboxing for Top Team PerformancePgina 1 de 5


We found that you can timebox any development activity, from requirements definition, to system design, tohttp://www.belizenorth.com/articlesATIMEBOX.htm22/06/2005

http://www.belizenorth.com/articlesATIMEBOX.htm22/06/2005

107paper prototyping your screens. You define a time interval, and work within it. When you run out of time, you stop, and move on. Of course, you have to be reasonable; you can't do ten days of coding in a two-day timebox; but you actually might able to build a prototype in three days. You won't know until you try.Stop apologizing!Early in my career, as a young IBM Systems Engineer, I was working on a SPOOLing package with Bill Gunther, an old software hand from Northrop Corporation. I suggested that, for some good reasons, we might be able to slip the package we were working on a couple of weeks from its scheduled delivery date."NO!! he said, vehemently. People won't remember why we were late; they will only remember that we were late.Thats still true; it's all too easy to get a reputation for always being late. If schedule is important in your software shop, you CAN be on time, if youll simply manage the iron triangle properly. And timeboxing is a good way to do that.## Go to top Go to sidebarFIGURESScheduleSchedule



http://www.belizenorth.com/articles/TIMEBOX.htm22/06/2005

http://www.belizenorth.com/articles/TIMEBOX.htm22/06/2005

FeatureCustomerRankDeliveryCostPriority

Capture existing file3412

Create new records111

Allocate new space interactively5945

Validate keys interactively224

Validate all fields interactively6636

Recreate file from backup3412

Update file from journal8756

Modify existing records133

Find record by primary key122

Find record by secondary key2612

... etc...

Figure 3. Feature Priority Matrix109

S9ID 11 12 13 H IS 16 17 1S 19Figure 4. Defects found vs. Defects fixed.

SidebarWant to Learn More About Timeboxing?The term timebox was first used by Scott Shultz of DuPont, as a key component of Rapid Iterative Production Prototyping (RIPP), a predecessor of RAD, which Shultz developed in the early 80s. James Kerr and Richard Hunter interview him in Inside RAD: How to build fully functional computer systems in 90 days or less. (McGraw- Hill, 1994, pp. 14-16.)In Rapid Application Development, James Martin calls timeboxing a variant of RAD and devotes an entire chapter to it.(Prentice-Hall, 1991, Chapter 11.)Without using the word timeboxing, Tom Gilb provides a cogent discussion of Deadline pressure: how to beat it in Principles of Software Engineering Management (Addison-Wesley, 1988, Chapter 17.)For more on QFD, see The Customer-Driven Company: Managerial Perspectives on QFD by William Eureka and Nancy Ryan (American Supplier Institute, 1988.)For an interesting discussion of creeping or galloping elegance, and incremental delivery, see Roland Rackos Object Lessons: Joseph and the CD-ROM of Many Colors (Software Development, September 1994.)Jim McCarthy is a frequent speaker at Software Development and other national conferences. His talk 21 Rules of Thumb for Delivering Quality Software on Time is a classic, available on tape from Conference Copy, Inc. 717-775-0580. (Session 04, Conf. #698D)Finally, Pascal Zacharys Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft (Free Press, 1994) is must reading for any one who needs to understand the realities of the Iron Triangle. (Its also a GREAT read!)About the Author. [Updated:] When this was written, Rick Zahniser was the founder & chairman of CASELab, a startup which specialized in coaching software teams to world-class performance. In 1999, he decided to watch the Turn of the Century from Belize, Central America. You can meet him and chat with him on his website http://belizenorth.com.Copyright, CASElab, 1995. All rights reserved.Timeboxing for Top Team PerformancePgina 1 de 5


Go to tophttp://www.belizenorth.com/articlesATIMEBOX.htm22/06/2005

http://www.belizenorth.com/articlesATIMEBOX.htm22/06/2005

1Agile ProcessesThe weather-cock on the church spire, though made of iron, would soon be broken by the storm-wind if it did not understand the noble art of turning to every wind.-- Heinrich HeineMany of us have lived through the nightmare of a project with no process to guide it. The lack of a process leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping schedules, growing budgets, and poor quality. Developers are disheartened by working ever longer hours to produce ever poorer software.Once we have experienced such a fiasco, we become afraid of repeating the experience. A common response to fear is to create a process that we believe eliminates what we are afraid of. We are afraid that The project will produce the wrong product. The project will produce a product of inferior quality. The project will be late. We'll have to work 80 hour weeks. Well have to break commitments. We wont be having fun.#

111

Our fears motivate us to create a process that constrains our activities and demands certain outputs and artifacts. We draw these constraints and outputs from past experience, choosing things that appeared to work well in previous projects. Our hope is that they will work again, and take away our fears.7

7

But projects are not so simple that a few constraints and artifacts can reliably prevent error. As errors continue to be made, vve diagnose those errors and put in place even more constraints and outputs in order to prevent those errors in the future. After many projects we may find ourselves overloaded with a huge cumbersome process that greatly impedes our ability to get projects done.A big cumbersome process can create the very problems that it is designed to prevent. It can slow the team to the extent that schedules slip and budgets bloat. It can reduce responsiveness of the team to the point that they are always creating the wrong product. Unfortunately this leads many teams to believe that they dont have enough process. So, in a kind of runaway process inflation, they make their process ever larger.Runaway process inflation is a good description of the state of affairs of the software industry circa 2000 A.D. Though there were still many teams operating without a process. The adoption of very large heavyweight processes was rapidly growing; especially in large corporations.The Agile AllianceIn early 2001, motivated by the observation that software teams in many corporations were stuck in a quagmire of ever increasing process, a group of industry experts met to outline the values and principles that would allow software teams to develop quickly and respond to change. They called themselves the Agile Alliance. Over two days they worked to create a statement of values. The result was the manifesto of the Agile Alliance. Over the next three months they continued to work together to create the principles of agility.The Manifesto: a statement of agile valuesManifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:- Individuals and interactions over processes and tools - - Working software over comprehensive documentation - - Customer collaboration over contract negotiation ~- Responding to change over following a plan -Chapter:8112

9Chapter :114

Chapter:12113

That is, while there is value in the items on the right, we value the items on the left more.

Alistair Cockburn

Kent Beck Ward Cunningham Andrew Hunt Robert C. MartinMike BeedleArie van BennekumMartin FowlerJames GrenningRon JeffriesJon KernSteve MellorKen SchwaberJim Highsmith Brian Marick Jeff Sutherland

Dave ThomasIndividuals and interactions over processes and tools. People are the most important ingredient of success. A good process will not save the project from failure if the team doesnt have strong players; but a bad process can make even the strongest of players ineffective. Even a group of strong players can fail badly if they dont work as a team.A strong player is not necessarily an ace programmer. A strong player may be an average programmer, but someone who works well with others. Working well with others, communicating and interacting, is more important that raw programming talent. A team of average programmers who communicate well are more likely to succeed than a group of superstars who fail to interact as a team.The right tools can be very important to success. Compilers, IDEs, source code control systems, etc., are all vital to the proper functioning of a team of developers. However, tools can be overemphasized. An overabundance of big unwieldy tools is just as bad as a lack of tools.My advice is to start small. Dont assume youve outgrown a tool until you tried it and found you cant use it. Instead of buying the top of the line, mega-expensive, source code control system, find a free one and use it until you can demonstrate that youve outgrown it. Before you buy team licenses for the best of all CASE tools, use white boards and graph paper until you can unambiguously show that you need more. Before you commit to the top-shelf behemoth database system, try flat files. Dont assume that bigger and better tools will automatically help you do better. Often they hinder more than they help.Remember, building the team is more important that building the environment. Many teams and managers make the mistake of building the environment first and expecting the team to gel automatically. Instead, work to create the team, and then let the team configure the environment on the basis of need.Working software over comprehensive documentation. Software without documentation is a disaster. Code is not the ideal medium for communicating the rationale and structure of a system. Rather, the team needs to produce human readable documents that describe the system, and the rationale for their design decisions.However, too much documentation is worse than too little. Huge software documents take a great deal of time to produce, and even more time to keep in sync with the code. If they are not kept in sync, then they turn into huge lies, and become a significant source of misdirection.I have no problem with a short rationale and structure document that the team produces and keeps in sync from month to month. But I want that document to be short andsalient. It should discuss the overall design rationale, and only the highest level structures in the system.If all we have is a short rationale and structure document, how do we train new team members about the system? We work closely with them. We transfer our knowledge to them by sitting next to them and helping them. We make them part of the team through close training and interaction.The two documents that are the best at transferring information to new team members, are the code and the team. The code does not lie about what it does. It may be hard to extract rationale and intent from the code; but the code is the only unambiguous source of information. The team holds the ever-changing roadmap of the system in their heads. There is no way to put that roadmap down on paper and transfer it to others that is faster and more efficient than interaction with the team.Many teams have gotten hung up in pursuit of documentation instead of software. This is often a fatal flaw. There is a simple rule that prevents it:Produce no document unless its need is immediate and significant.Customer collaboration over contract negotiation. Software cannot be ordered like a commodity. You cannot write a description of the software you want and then have someone develop it on a fixed schedule for a fixed price. Time and time again, attempts to treat software projects in this manner have failed. Sometimes the failures are spectacular.It is tempting for the managers of a company to tell their development staff what their needs are, and then expect that staff to go away for awhile and return with a system that satisfies their needs. But this mode of operation leads to poor quality and failure.Successful projects involve customer feedback on a regular and frequent basis. Rather than depending upon a contract, or a statement of work, the customer of the software works closely with the development team, providing frequent feedback on their efforts.A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed. In most cases the terms it specifies become meaningless long before the project is complete. The best contracts are those that govern the way the development team and the customer will work together.As an example of a successful contract, in 1994 I negotiated a contract for a large, multi-year, half-million-line, project. We, the development team, were paid a relatively low monthly rate. Large payouts were made to us when we delivered certain large blocks of functionality. Those blocks were not specified in detail by the contract. Rather the contract stated that the payout would be made for a block when the block passed the customer's acceptance test. The details of those acceptance tests were not specified in the contract.During the course of this project we worked very closely with the customer. We released the software to him almost every Friday. By Monday of Tuesday of the following week he would have a list of changes for us to put into the software. We would prioritize those changes together, and then schedule them into subsequent weeks. The customer worked so closely with us that acceptance tests were never an issue. He knew when a block of functionality satisfied his needs because he watched it evolve from week to week.The requirements for this project were in a constant state of flux. Major changes were not uncommon. There were whole blocks of functionality that were removed, and others that were inserted. And yet the contract, and the project, survived and succeeded. The key to this success was the intense collaboration with the customer; and a contract that governed that collaboration rather than trying to specify the details of scope and schedule for a fixed cost.Responding to change over following a plan. It is the ability to respond to change that often determines the success or failure of a software project. When we build plans, we need to make sure that our plans are flexible and ready to adapt to changes in the business and technology.The course of a software project cannot be predicted far into the future. There are too many variables to account for. We simply aren't very good at estimating the cost of a large project. The business environment that the software must serve is likely to change during the course of development. It is difficult to write reliable requirements. Customers are likely to alter the requirements once they see the system start to function.It is tempting for novice managers to create a nice PERT or Ghant chart of the whole project, and tape it to the wall. They may feel that this chart gives them control over the project. They can track the individual tasks and cross them off the chart as they are completed. They can compare the actual dates with the planned dates on the chart and react to any discrepancies.But what really happens is that the structure of the chart degrades. As the team gains knowledge about the system, and as the customer gains knowledge about their needs, certain tasks on the chart will become unnecessary. Other tasks will be discovered and will need to be added. In short, the plan will undergo changes in shape, not just changes in dates.A better planning strategy is to make detailed plans for the next few weeks, very rough plans for the next few months, and extremely crude plans beyond that. We should know the tasks we will be working on for the next few weeks. We should roughly know the requirements we will be working on for the next few months. And we should have a only a vague idea what the system will do after a year.This decreasing resolution of the plan means that we are only investing in a detailed plan for those tasks that are immediate. Once the detailed plan is made, it is hard to change since the team will have a lot of momentum and commitment. But since that plan only governs a few weeks worth of time the rest of the plan remains flexible. The lower resolution parts of the plan can be changed with relative ease.PrinciplesThe above values inspired the following twelve principles. These principles are the characteristics that differentiate an agile process. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.The MIT Sloan Management Review published an analysis of software development practices that help companies build high quality products[footnoteRef:1]. The article found a number of practices that had a significant impact upon the quality of the final system. One was a strong correlation between quality, and the early delivery of a partially functioning system. The article reported that the less functional the initial delivery, the higher the quality in the final delivery. [1: Product-Development Practices Thai Work: How Internet Companies Build Software . MIT Sloan Management Review. Winter 2001. Reprint number 4226]

Another finding of this article was a strong correlation between final quality and frequent deliveries of increasing functionality. The more frequent the deliveries, the higher the final quality.An agile process is one that delivers early and often. We strive to deliver a rudimentary system within the first few weeks of the start of the project. And we strive thereafter to continue to deliver systems of increasing functionality every few weeks.Customers may choose to put these systems into production if they think they are functional enough. Or they may choose simply to review the existing functionality and report on changes they want made. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.This is a statement of attitude. The participants in an agile process are not afraid of change. They view changes to the requirements as good things, because they mean that the team has learned more about what it will take to satisfy the market.An agile team works very hard to keep the structure of their software flexible, so that when requirements change, the impact to the system is minimal. Later in this book we will learn the principles of object oriented design that help us to maintain this kind of flexibility. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.We deliver working software. And we delivery it early and often. We are not content with delivering bundles of documents, or plans. We don't count those as true deliveries. Our eye is on the goal of delivering software that satisfies the customers needs. Business people and developers must work together daily throughout the project.In order for a project to be agile, there must be significant and frequent interaction between the customers, developers, and stakeholders. An agile project is not like a fire-and-forget weapon. An agile project must be continuously guided. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.An agile project is one in which people are considered the most important factor of success. All other factors, process, environment, management, etc., are considered to be second order effects, and are subject to change if they are having an adverse effect upon the people.For example, if the office environment is an obstacle to the team, the office environment changes. If certain process steps are an obstacle to the team, the process steps change. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.In an agile project, people talk to each other. The primary mode of communication is conversation. Documents may be created, but there is no attempt to capture all project information in writing. An agile project team does not demand written specs, written plans, or written designs. They may create them if they perceive an immediate and significant need, but they are not the default. The default is conversation. Working software is the primary measure of progress.Agile projects measure their progress by measuring the amount of software that is working. They don't measure their progress in terms of the phase that they are in, or by the volume of documentation that has been produced, or by the amount of infrastructure code they have created. They are 30% done when 30% of the necessary functionality is working. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.An agile project is not run like a 50 yard dash; it is run like a marathon. The team does not take off at full speed and try to maintain that speed for the duration. Rather they run at a fast, but sustainable, pace.Running too fast leads to burnout, shortcuts, and debacle. Agile teams pace themselves. They dont allow themselves to get too tired. They dont borrow tomorrows energy to get a bit more done today. They work at a rate that allows them to maintain the highest quality standards for the duration of the project. Continuous attention to technical excellence and good design enhances agility.High quality is the key to high speed. The way to go fast is to keep the software as clean and robust as possible. Thus, all agile team-members are committed to producing only the highest quality code they can. They do not make messes and then tell themselves they'll clean it up when they have more time. If they make a mess, they clean it up before they finish for the day. Simplicitythe art of maximizing the amount of work not doneis essential.Agile teams do not try to build the grand system in the sky. Rather they always take the simplest path that is consistent with their goals. They dont anticipate tomorrows problems and try to defend against them today. Rather they do the simplest and highest quality work today, confident that it will be easy to change if and when tomorrows problems arise. The best architectures, requirements, and designs emerge from self-organizing teams.An agile team is a self organizing team. Responsibilities are not handed to individual team members from the outside. Rather, responsibilities are communicated to the team as a whole, and the team determines the best way to fulfill them.Agile team members work together on all aspects of the project. Each is allowed input into the whole. No single team member is responsible for the architecture, or the requirements, or the tests, etc. The team shares those responsibilities and each team member has influence over them. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.An agile team continually adjusts its organization, rules, conventions, relationships, etc. An agile team knows that its environment is continuously changing, and knows that they must change with that environment to remain agile.Conclusion11Chapter : :115

11813Chapter: :

Chapter:12117

The professional goal of every software engineer, and every development team, is to deliver the highest possible value to our employers and customers. And yet, our projects fail, or fail to deliver value, at a dismaying rate. Though well intentioned, the upward spiral of process inflation is culpable for at least some of this failure. The principles and values of agile software development were formed as a way to help teams break the cycle of process inflation, and to focus on simple techniques for reaching their goals.Product Backlog para un Sprint de 59 minutos02/11/2009118

Este backlog posee un nmero de items a considerar para completar un Sprint (iteracin). El equipo puede decidir, junto con el Product Owner (el instructor), cual es el tema u objetivo del Sprint. El Product Owner decidir el orden de prioridad de los items. El equipo deber enfocarse en no ms de 5 items para el demo del Sprint. Se har algo creativo (comercial, folleto, stand, poster).Backlog para turismo espacial-Marte visita la Tierra Crear la portada, marca y/o logo Definir los tpicos mayores para el turismo marciano. Describir el tour "El Arte en Europa". Describir un tour basado en el folklore. Esquematizar una expedicin a las 7 maravillas del mundo antiguo". Definir los mensajes de waming" (gravedad, oxgeno, etc.) Sugerir opciones de vestuario. Explicar las opciones de viaje hacia/desde Marte. Describir un tour "Deportes humanos". Esquematizar la poltica de devoluciones. Sugerir servicios relacionados. Definir los medios de publicacin. Definir una campaa de 12 meses. Establecer la forma de obtener ms informacin. Definir los precios de los tours.#

1