Scrum hipolito

INTRODUCCIÓN A SCRUM

Fernando Pinciroli
Marzo de 2010

Solus S.A. – San Martín 1351 piso 1º of. 4 – Mendoza – +54 261 4294115 – http://www.solus.com.ar

Agradecimientos
Agradezco a todos los autores y metodologistas que siempre están
dispuestos a intercambiar opiniones conmigo sobre metodologías y
hacerme participar de la revisión de sus libros antes de publicarlos, ya
sea personalmente, por correo electrónico, en facebook, ¡o en donde nos
encontremos!

Kenny Rubin Kent Beck Alistair Cockburn Grady Booch

Ron Jeffries James Rumbaugh Martin Fowler Rebecca Wirfs-Brock

Contenido del módulo

1 – Conceptos generales

2 – Roles y actividades

3 – Implementación de Scrum

4 – Conclusiones


Enfoques ágiles #1

• De un tiempo a esta parte apareció un nuevo concepto dentro de la
ingeniería de software, denominado modelado ágil de sistemas,
debido a que hace uso de modelos livianos o ágiles

• Se considera que un modelo es ágil o liviano cuando se emplea para
su construcción una herramienta o técnica sencilla, que apunta a
desarrollar un modelo aceptablemente bueno y suficiente en lugar
de un modelo perfecto y complejo

• Un modelo es suficientemente bueno cuando cumple con los
objetivos de comunicación, es entendible, no es perfecto, posee un
grado de detalle adecuado, suma valor al proyecto y es
suficientemente simple de construir


Enfoques ágiles #2

• Los principales enfoques ágiles son XP (eXtreme Programming),
SCRUM, Crystal Clear y DSDM (Dynamic Systems Development
Method), entre otros

• Herramientas de modelado ágil: tarjetas CRC, lenguaje natural,
castellano estructurado, etc.

• Existen procesos marco tradicionalmente formales que contemplan
la aplicación de técnicas de modelado ágil, como por ejemplo RUP
y actualmente CMMi


Programación extrema #1

• Fue creado por Kent Beck, a su vez creador de las tarjetas CRC y
quizás el programador Smalltalk más respetado del mundo

• Según el autor fue aplicado exitosamente en Chrysler en 1996, dentro
del proyecto C3, aunque Chrysler no opina lo mismo

• Junto a Beck podemos encontrar metodologistas muy prestigiosos
que, además de haber participado en C3, llevan firmemente hacia
adelante las ideas de XP, como es el caso de Ron Jeffries y Martin
Fowler



• “Si al final del día no hay un programa funcionando, ese día no se
hizo absolutamente nada”

• Se basa en los principios de comunicación, simplicidad, pruebas y
agresividad o “coraje”

• Apunta a reducir los costos de desarrollo y a lograr una mayor
satisfacción del usuario

• Se emplea en proyectos restringidos de tiempo, con pocos recursos
humanos y con un cambio constante en los requerimientos



• Los equipos de desarrollo normalmente son de dos a doce personas,
aunque se llegaron a realizar proyectos con treinta integrantes en el
equipo

• No deben ser programadores altamente calificados, sino más bien
de un perfil normal

• Debe existir una presencia física real del usuario, aspecto que de no
poder concretarse, directamente impide la aplicación de XP



La planificación en XP
• Escribir las “historias de los usuarios”
• Planificar las versiones
• Realizar frecuentes versiones pequeñas
• Medir la velocidad del proyecto
• Dividir el proyecto en iteraciones
• Comenzar cada iteración con su planificación
• Cambiar las duplas de programadores
• Realizar una reunión cada mañana
• Corregir las reglas de XP cuando sea necesario



El diseño en XP
• Mantener simplicidad

• Elegir una metáfora del sistema

• Usar tarjetas CRC para el diseño

• Crear prototipos

• No agregar funcionalidad adicional

• Refactorizar en donde sea posible



La codificación en XP

• El usuario debe estar siempre disponible
• Emplear estándares
• Escribir las unidades de prueba primero
• Programar de a pares
• Integrar el código de a un par por vez
• Integrar el código permanentemente
• Hacer a todos propietarios de todo el código
• Optimizar a lo último
• No trabajar más horas de lo normal



La prueba en XP

• Escribir unidades de prueba para todo el código

• Confrontar el código contra las unidades de prueba
antes de incorporarlo como nueva versión

• Crear nuevas pruebas al detectar errores

• Elaborar las “pruebas de aceptación” para probar el
resultado de cada versión


Manifiesto ágil
• Convocados por Kent Beck, se reúne un grupo de profesionales que redactan
y firman el manifiesto ágil: Kent Beck, Mike Beedle, Arie van Bennekum,
Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim
Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert Martin,
Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas

• El manifiesto consiste en un conjunto de valores básicos de los que surge un
conjunto de principios

• Estos valores son:

• Valorar más a los individuos y su interacción que a los procesos y las
herramientas
• Valorar más el software que funciona que la documentación exhaustiva
• Valorar más la colaboración con el cliente que la negociación contractual
• Valorar más la respuesta al cambio que el seguimiento de un plan


Principios del manifiesto ágil
1. Nuestra prioridad más alta es la de satisfacer al cliente a través de la entrega temprana y
continua de software de valor
2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos
ágiles se subordinan al cambio como ventaja competitiva para el cliente
3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par
de meses, con preferencia de los periodos más cortos
4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a lo largo
del proyecto
5. Llevar a cabo proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo
que necesitan y procurándoles confianza para que realicen la tarea
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo
de desarrollo es mediante la conversación cara a cara
7. El software que funciona es la principal medida del avance del proyecto
8. Los procesos ágiles promueven el desarrollo sostenido. Los interesados, desarrolladores y usuarios
deben mantener un ritmo constante de forma indefinida
9. La atención continua a la excelencia técnica y al buen diseño promueve la agilidad
10. La simplicidad –el arte de maximizar la cantidad de trabajo que no se hace- es esencial
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos auto-organizados
12. El equipo reflexiona sobre la forma de ser más efectivo en intervalos regulares y ajusta su
conducta en consecuencia


Acerca de Scrum #1
• Se trata de un enfoque, dentro de las denominadas Metodologías
Ágiles, para administrar el proceso de desarrollo de software desde
una perspectiva empírica basada en la teoría del control de
procesos
• Su finalidad es introducir los conceptos de
flexibilidad, adaptabilidad y productividad en el desarrollo de
software
• Cubre a otras metodologías, estándares y prácticas de
ingeniería, en particular a Programación Extrema (XP)
• Es un proceso donde el costo, el tiempo, la funcionalidad y la
calidad son administrados empíricamente
• Entre otras cosas, intenta resolver el problema de que los clientes
realmente se dan cuenta de lo que quieren una vez que tienen una
primera versión del producto

Acerca de Scrum #2
• Parte del concepto de que los procesos de desarrollo de software
no son definidos, es decir, no pueden ser ni repetibles ni
predecibles
• En lugar de avanzar en un proceso secuencial, se trata de un
proceso caótico de adaptación del equipo al caos para lograr un
Objetivo auto-organizándose y tomando decisiones con total
libertad, logrando una cohesión interna y una productividad cada
vez mayor
• Ocupa menos tiempo en planificación, definición de tareas y
producción de reportes y más tiempo en la comprensión del
problema y la provisión de soluciones empíricas
• A sus autores les gusta llamarlo el arte de lo posible


Historia de Scrum

• El nombre describe un proceso de desarrollo hiperproductivo de
productos utilizado inicialmente en Japón en 1987 por Takeuchi y
Nonaka

• Jeff Sutherland empleó Scrum por primera vez para el desarrollo
de software en Easel Corporation en 1994

• Luego Ken Schwaber tuvo la oportunidad de emplearlo en
Individual Inc. en 1996, en donde se probó y se refinó el método


Beneficios de Scrum

• Permite coordinar los recursos humanos de modo de que trabajen
juntos en forma efectiva y puedan lograr desarrollos complejos

• Permite lograr incrementos exponenciales en la productividad

• Con Scrum se espera estar entregando software funcionando
correctamente ya en el primer mes de desarrollo

• Posibilita el desarrollo de software en entornos complejos y
cambiantes


Bases conceptuales
• Scrum se basa en un proceso empírico en lugar de en un modelo de
control del proceso definido
• Generalmente se dice que aplica en entornos cambiantes,
complicados, conflictivos, frustrantes
• Ayuda a quitar las “interferencias” en las acciones cotidianas
• El proceso no sólo no está definido sino que, incluso, es inesperado
• La interacción humana de las reuniones diarias obliga a ser sincero,
a hablar cara a cara y a comprometer a ambas partes en cumplir sus
compromisos y en quitar los obstáculos


Resultados esperados
• Las gerencias se vuelven más expeditivas, menos burocráticas y
menos tendientes al uso de papel
• Los Equipos se tornan más confiados, con más poder, más eficientes
y más enfocados en su trabajo
• Los gerentes comienzan a transformar sus actividades de control en
acciones para ayudar al Equipo, quitar impedimentos, aportar lo
que ayude a brindar más y mejores resultados


Product Owner
• El Dueño del Producto es oficialmente el responsable del proyecto
• Es una persona, no un comité; aunque pueden existir comités para
asesorar al dueño del producto
• Es un miembro de la organización y representa los intereses de los
stakeholders: clientes, usuarios y gerencia
• Es la persona que se encarga de administrar los requisitos que se
van a entregar, de establecer las prioridades y el orden en que se
deben implementar y debe decidir el contenido de cada uno de los
releases
• Es el responsable de convertir los “temas” en requisitos dentro de
la lista oficial de requisitos del proyecto que se denomina Backlog
del Producto


Product Backlog #1

• Se trata de una lista evolutiva y priorizada que contiene la
totalidad de los requisitos funcionales y no funcionales del
proyecto, características y aspectos de tecnología
• Es administrada por una única persona, el Dueño del Producto
(Product owner)
• El Dueño del Producto establece periódicamente las prioridades y
es el único que puede hacerlo
• No se niega la entrada de ningún requisito; a lo sumo no se
implementará nunca por tener siempre una prioridad baja
• La agenda de desarrollo del proyecto se hace a partir de esta lista
• La lista no se cierra nunca y se mantiene visible en forma
permanente


Product Backlog #2
• Permite que el Equipo de desarrollo no sea molestado nunca con
solicitudes, las que deben pasar necesariamente a través de esta
lista
• Cada requisito del Backlog debe tener su propia estimación de
tiempo y esfuerzo
• Sólo pueden entrar para ser atendidos en cualquier momento los
requisitos de soporte y mantenimiento del código preexistente
• Cualquier cosa que signifique trabajo en el proyecto debe estar
incluido en el Backlog
• Las fuentes del Backlog pueden ser tan formales o informales como
lo sea la organización para la que se desarrolla el software
• Los requisitos del Backlog de más alta prioridad están más
detallados que los de más baja prioridad


Product Backlog #3
• Además de los requisitos, el Backlog incluye “temas” (issues), que
hasta que no sean convertidos en trabajo
• Si un ítem del Backlog no está lo suficientemente claro, se lo debe
transformar en un tema o se le debe reducir su prioridad
• El Backlog se puede dividir en partes, llamadas Release Backlog,
correspondientes a los releases planificados
• Ejemplos de ítems del Backlog, mezclando funcionalidad con
tecnología:
• se pierden transacciones en determinado proceso
• el framework debe mejorarse para soporte de múltiples bases
de datos
• se detectó que falta presentar determinada información en
pantalla en determinado proceso


Scrum Master
• Es el principal responsable del éxito de Scrum
• Se ocupa de velar por el estricto cumplimiento del proceso, de
proteger al Equipo de los pedidos fuera del Backlog, de hacer que
los clientes, usuarios y stakeholders en general se atengan a las
reglas del proceso, etc.
• Se encarga de controlar que el Equipo no desarrolle nada fuera de lo
acordado dentro del Sprint en curso
• Debe conseguir los recursos que precisa el Equipo y quitar los
impedimentos
• Representa a la otra parte, a la gerencia o al Equipo, frente a cada
uno de éstos
• Selecciona al Dueño del Producto junto con la gerencia
• Sin lugar a dudas este rol debe ser ocupado por quien tenga el perfil
adecuado; no todos pueden llevarlo a cabo

Sprint #1
• Se denomina así a cada una de las iteraciones del proceso de
desarrollo de software, que es un proceso iterativo e incremental
• Posee una duración fija que se establece al inicio del proyecto (por
ejemplo, un mes)
• La duración debe permitir la inclusión de requisitos de alta
prioridad que pudieran surgir mientras se lleva a cabo un Sprint
• Cada Sprint se inicia con una Reunión de Planificación, que
establecerá el trabajo a realizarse en el tiempo que dura el Sprint
• Al comienzo de un Sprint y junto al Scrum Master el Equipo se
compromete a transformar en producto un conjunto de ítems del
Backlog
• Los ítems del Backlog del producto que se incluyen en el Sprint
conforman el Backlog del Sprint
• Cada Sprint debe tener un Objetivo claro (Sprint Goal)

Sprint #2
• Al término de un Sprint se hace una Reunión de Revisión para
evaluar lo realizado y el cumplimiento del Objetivo del Sprint
• Si durante el Sprint se detecta que no se puede cumplir con el
Objetivo, el Srum Master se debe reunir de inmediato con Dueño
del Producto y el Equipo para ver qué ítem del Backlog del Sprint
se puede quitar o disminuir su alcance o profundidad
• Cuando el Equipo descubre que no podrá cumplir con sus
compromisos en el Sprint, debe solicitar una Terminación Anormal
del Sprint y se debe convocar a una reunión de planificación de un
nuevo Sprint
• Si al término del Sprint se detectó que hubo una decisión
equivocada, se debe rehacer el trabajo
• Como un Sprint es corto, a lo sumo se pierden sólo 30 días de
trabajo


Sprint #3
• En todo proyecto existen cuatro restricciones: tiempo, costo,
calidad y funcionalidad a entregar; un Sprint prácticamente fija las
tres primeras
• El tiempo, son 30 días; el costo, el del salario del equipo, el
equipamiento y los consultores y herramientas que se pudieran
precisar; la calidad se debe establecer antes de iniciar el Sprint; la
funcionalidad se puede manejar siempre y cuando se cumple con el
Objetivo del Sprint
• Al término del Sprint se debe actualizar el conjunto de pruebas,
ejecutarlas a todas y ejecutar las pruebas de humo más las de
regresión para el resto del código


Incremento de producto
• Es el producto resultante de cada Sprint y el Objetivo fundamental
a lograr
• Se debe realizar necesariamente la entrega de un Incremento de
Producto al final de cada Sprint
• La arquitectura y el diseño del producto emergen luego de varios
Sprints en lugar de plantearse en el primero


Reunión de planificación del Sprint #1
• En la Reunión de Planificación del Sprint deben participar todos,
el equipo y los interesados
• En cada reunión de planificación se deben tener en consideración el
Backlog, las capacidades del Equipo, las condiciones del negocio,
la estabilidad tecnológica, los Incrementos de Producto
• En estas reuniones se debe revisar, reconsiderar lo que se está
haciendo y reorganizar el Equipo y el proceso
• Esta reunión, en realidad, consta de dos reuniones:
• Primera reunión: se reúnen el Scrum Master, el Equipo
completo, el Dueño del Producto, los clientes, los usuarios y la
gerencia y determinan qué funcionalidad incluirán en el Sprint
• Segunda reunión: se reúnen sólo el Scrum Master y el Equipo
para ver cómo transformar esa funcionalidad en un Incremento
de Producto


• Son insumos de la reunión el Backlog del Producto, el último
Incremento de Producto, el detalle de las capacidades y
rendimiento del Equipo, las condiciones del negocio y la estabilidad
de la tecnología
• Se puede invitar a otras personas para que aporten opiniones o
consejo
• Al inicio, el Scrum Master presenta los ítems prioritarios del
Backlog y se discuten posibles cambios
• Los miembros del Equipo, trabajando con todos los presentes,
establecen lo que pueden hacer durante los próximos 30 días
• Se debe describir el Objetivo del Sprint que engloba los ítems del
Backlog a implementar y el Incremento de Producto a entregar, de
modo de que sea un Objetivo claro en la mente de todos a lo largo
del Sprint


• El Equipo delinea una lista de las tareas que llevará a cabo para
cumplir con el Objetivo y que se llama Sprint Backlog
• Cada tarea debe poder cumplirse entre 4 y 16 horas
• A medida que se trabaja en las tareas o se completan se deben
actualizar las estimaciones de las restantes y sólo puede hacerlo el
Equipo
• El Equipo debe transformar el caos y la complejidad en un
Incremento de Producto
• Ejemplos de ítems del Sprint Backlog son:
• escribir un objeto de negocio en para administrar las
transacciones
• medir el rendimiento de las transacciones para asegurar los
requisitos de escalabilidad


Daily scrum #1
• Son reuniones diarias en las que el Equipo reporta a los clientes del
producto los avances realizados el día anterior y la actividad que está
llevando a cabo
• Estas reuniones diarias no deben ser de más de 15’ aunque sea difícil
decirle a un gerente que no interrumpa
• Los miembros del Equipo informan uno tras otro, breve y
concisamente, sólo tres cosas:
• qué se hizo desde la última reunión: no importa nada que no
esté relacionado con su trabajo
• qué se planificó hacer en el tiempo hasta la próxima reunión:
que debe coincidir con el trabajo planificado por el Equipo; si hay
diferencias las deben discutir tras esta reunión
• qué cosas impiden trabajar adecuadamente: qué se interpone,
qué reduce la velocidad, qué hace que el equipo no trabaje como
un todo y qué ayudaría a lo contrario

Daily scrum #2
• Las personas ajenas al Equipo no pueden preguntar nada;
simplemente se les informa
• Tras informar a los clientes, el Equipo potencia su productividad
cuando cada programador conoce lo que hará el otro y puede
sugerirle mejores alternativas
• El Scrum Master debe confrontar lo que cada integrante del Equipo
informa con el Objetivo del Sprint y con el compromiso del Daily
Scrum anterior
• Los Daily Srcums deben eliminar otras reuniones, quitar
impedimentos al desarrollo, ayudar a la rápida toma de decisiones y
mejorar la visibilidad del proyecto para todos
• En estas reuniones se puede detectar rápidamente si alguien se
desmotivó, tiene problemas externos (familiares, etc.), las buenas y
malas actitudes, etc.


Daily scrum #3
• La habitación para estas reuniones se llama Sala de Scrum y debe
tener una puerta, una mesa, sillas para el Equipo, pizarra y un
teléfono con altavoz
• Estas reuniones no deben ser ni un espectáculo ni un centro de
entrenamiento para otros Equipos
• El Scrum Master debe asegurarse de que la sala está en orden antes
de comenzar la reunión, incluso ordenando las sillas
• Se debe establecer un límite físico para que no queden dudas de que
quienes no son miembros del Equipo son sólo observadores y no
participantes
• Si queda gente de pie no hay problemas; esto ayuda al concepto de
brevedad
• El inicio debe ser puntual, sin importar quién está ausente, y se
deben establecer multas para los miembros del Equipo impuntuales


Daily scrum #4
• Algunos impedimentos típicos: equipos o red funcionando mal,
solicitudes al Equipo de ir a reuniones o de hacer algo, indecisiones
acerca de cómo proceder con algo, de cómo hacer un diseño o de
cuestiones tecnológicas, etc.
• Es un mal signo que se vuelvan a reportar los mismos impedimentos
al día siguiente
• Si el Scrum Master detecta que no hay apoyo suficiente de parte de
la organización puede suspender el Sprint, aunque debería hacer
esto sólo tras haber agotado otras instancias
• Si se detectan indecisiones o decisiones riesgosas, el Scrum Master
debe reunirse con el Equipo para conversar tras la reunión
• Si el Scrum Master no puede resolver un impedimento, se lo debe
comunicar al Equipo dentro de la hora siguiente a la reunión


Daily scrum #5
• Los miembros del Equipo deben estar obligatoriamente con
presencia activa, es decir, al menos por teléfono, pero no se pueden
reportar vía fax o correo electrónico
• En estas reuniones se debe detectar qué prácticas de modelado se
realizan y luego trabajar sobre si es necesario el modelado que se
haga
• Cuando no hay inconvenientes puede ser una mala señal, ya que
puede ser que no los haya porque no se avanza
• Un miembro del Equipo puede solicitar una reunión de seguimiento
de la discusión de un tema tras el Daily Scrum
• Estas reuniones de seguimiento no están restringidas en tiempo


Reunión de revisión del Sprint #1
• Antes del Sprint, el Equipo hizo estimaciones acerca de adónde
estará al final del Sprint
• En el día final, número 30, del Sprint se reúnen gerentes, usuarios,
clientes, el dueño del producto, el Scrum Master y el equipo para
evaluar el Incremento de Producto que se obtuvo
• Es posible que participen otros ingenieros y desarrolladores para
ver cómo se desempeñó el Equipo
• El Scrum Master es quien coordina y dirige la reunión, para lo que
previamente se reunió con el Equipo para organizar qué se
presentará y quién lo hará
• El Scrum Master se ocupa de las invitaciones y de los recordatorios
a la reunión


• El Scrum Master inicia la reunión con un resumen conciso del
Sprint
• El Equipo puede presentar primero un diagrama simple de
arquitectura
• Luego el Equipo presenta las funcionalidades que se fueron
agregando, para lo que quizás haya que pasar la reunión de una
computadora, e incluso de una oficina, a otra
• Se revisan y se discuten las diferencias que se encuentran entre el
Objetivo del Sprint y el Backlog del Producto y los resultados que
se obtuvieron
• A medida que se realiza la presentación, se puede determinar qué
funcionalidad se debe agregar en el próximo Sprint


• También se van explicando las fortalezas y debilidades de las
funcionalidades que se presentan junto con las cuestiones
favorables y desfavorables que vivieron a lo largo del Sprint
• A fin de agilizar la reunión y hacerla concreta, se prohíben las
presentaciones estilo PowerPoint
• Si se necesitan más de dos horas para preparar la reunión, es que se
está necesitando “adornar” lo que se va a presentar
• Se espera que existan muchas preguntas, opiniones, sugerencias y
discusiones
• Con todo lo dicho, se establece en qué lugar están parados en el
proyecto
• En este punto se comienzan a realizar los ajustes que sean
necesarios para enderezar el rumbo del proyecto


Equipo de Scrum #1
• Es un Equipo pequeño, compuesto por aquellos que desarrollan el
producto; se dice que debería ser de siete más menos dos personas
• Los Equipos de tres personas no son convenientes porque no se da la
interacción suficiente y se reduce la productividad
• Los Equipos de más de ocho personas pueden no trabajar bien y
complicar al Scrum Master en las reuniones de Daily Scrum
• Realizan las Reuniones de Planificación de cada Sprint e informan
en los Daily Scrums
• Pueden haber varios Equipos trabajando en paralelo sobre el mismo
Backlog, pero todos deben ser autónomos y organizarse por sí mismos
• Las únicas restricciones deben ser los estándares, guías y
convenciones para el desarrollo
• El Equipo debe estar protegido y desconectado del caos externo


Equipo de Scrum #2
• En Scrum se busca proveer al Equipo de trabajo un ambiente en el
cual cada uno pueda dar lo mejor de sí
• Cuando hay inconvenientes dentro del Equipo hay que dejarlos que
resuelvan sus diferencias entre sí; ayudarlos significa quitarles parte
de su responsabilidad de cumplir con sus compromisos
• Se deben minimizar las interacciones entre Equipos y maximizar la
cohesión interna de cada Equipo
• En los proyectos grandes donde se hace Scrum de Scrums, los
Scrum Masters de cada Scrum tienen sus propias reuniones de Daily
Scrum además de las de sus correspondientes equipos
• Los Equipos deben contar con todos los perfiles entre sus miembros
que les permitan alcanzar los Objetivos
• Es deseable que haya siempre un programador con mucha
experiencia en cada Equipo


Equipo de Scrum #3
• Algunos Equipos incluyen recursos para pruebas o para elaborar la
documentación del usuario, mientras que otros hacen que los
programadores revisen su propio código y escriban la documentación
• Algunas veces se incluye un documentador
• La mayor parte de los miembros deben estar asignados al Equipo a
tiempo completo, mientras que pueden existir algunos miembros
part time
• No existen títulos ni cargos en los Equipos, ni se aceptan personas
que no quieran codificar porque, por ejemplo, digan que son
analistas de sistemas
• La composición de los Equipos puede cambiar al final de un Sprint,
aunque con los cambios disminuye la productividad
• El Equipo tiene la libertad de tomar decisiones y puede solicitar que
le quiten impedimentos para alcanzar los Objetivos


Equipo de Scrum #4
• Puede solicitar ayuda o consejo como así también rechazarlo cuando
se le ofrece
• El Equipo tiene autoridad completa sobre sí mismo y muchas veces
cuesta que sus miembros lo entiendan; cuando sucede esto, la
productividad crece
• En cada Equipo hay libertad absoluta para utilizar métodos,
herramientas, convenciones, estándares, tecnologías, etc., sólo que
se deben establecer antes del inicio del Sprint
• Se debe brindar al equipo las mejores herramientas posibles
• El silencio siempre es un mal signo; cuando hay conversaciones es
porque hay colaboraciones
• Cada Equipo establece sus propios horarios, aunque se pueden
poner ciertas restricciones


Equipo de Scrum #5
• Pueden trabajar tantas o tan pocas horas como quieran, pueden
asignar todo el tiempo que quieran a una tarea, pueden gastar días
en reuniones con consultores y proveedores y en navegar en la web
• Puede y debe hacer todo por cumplir sus compromisos incluyendo
entrevistar a otros, traer consultores, leer libros, buscar en
Internet, o lo que sea necesario, siempre dentro del presupuesto
• Ante indecisiones del Equipo, el Scrum Master debe decidir, pero
esta intervención no debería ser frecuente
• No todas las personas pueden llevar adelante Scrum, pero quienes lo
hacen son normalmente las personas que conforman el núcleo
principal de una organización, y Scrum ayuda a identificarlos
• Cada programador es responsable para siempre de la corrección de
las porciones de código que haya escrito


Equipo de Scrum #6
• Como cada programador es responsable a perpetuidad del código
que escribió, será cada uno de ellos el que establezca cuál es la
mejor documentación que le ayude a cumplir con tal responsabilidad
• No obstante lo anterior, al término de cada Sprint se debe entregar
algo que ilustre el diseño del producto entregado y el código escrito
• Cuando el Equipo está geográficamente distribuido es fundamental
un software que ayude a gestionar los recursos
• Cuando hay Equipos distribuidos se puede avanzar dividiendo el
trabajo adecuadamente y realizando una buena coordinación


Terminación anormal de un Sprint
• A raíz de la corta duración de un Sprint, es raro que deba finalizarse
anticipadamente
• El Scrum Master es quien finaliza anticipadamente un Sprint y
puede hacerlo por las siguientes razones:
• el Objetivo del Sprint quedó obsoleto
• el Equipo se dio cuenta de que no logrará el Objetivo
• la organización no brinda el apoyo suficiente al Equipo
• Una terminación anticipada consume mucho tiempo y recursos, por
lo que se debe tratar de evitar
• Por lo general, nadie quiere quedar como el responsable de una
terminación anormal de un Sprint


Estimaciones #1
• El Dueño del Producto trabaja con el equipo para determinar
cuánto esfuerzo demandará desarrollar los requisitos del Backlog
• Los tiempos que se estiman deben incluir todo lo necesario para
llevar a cabo la arquitectura, el diseño, la construcción, la prueba y
la elaboración de la documentación del usuario
• Las estimaciones evolucionan a medida que se conoce más acerca
del ítem del Backlog a construir
• Las estimaciones no son vinculantes en el Equipo y no significan que
no hay más tiempo para desarrollar que el que se estableció
• A medida que se gana experiencia se supone que las estimaciones
serán mejores
• Las estimaciones se pueden revisar y reajustar y son más acertadas
después del tercero o cuarto Sprint


Estimaciones #2
• Se debe comprender que al comienzo no habrá una estimación fija
de costo, fecha, calidad y funcionalidad; estos factores se deben
negociar a lo largo del proyecto
• La información de la brecha entre el producto real y el estimado
debe ser visible al cliente; en Scrum la relación con el cliente debe
ser siempre honesta
• El problema de la estimación pasa principalmente por tres ejes: los
requisitos, la tecnología y las personas
• Las correcciones a los problemas en la estimación son tres:
reducción de la funcionalidad, agregado de recursos y postergación
de la fecha de entrega


Administración empírica #1
900

800
Trabajo remanente (hs.)

700

600

500

400

300

200

100

0
1 2 3 4 5 6 7 8 9

Tiempo (meses)


1000

800

600

400

200

0
1 2 3 4 5 6 7 8 9 10 11

-200
Tiempo (meses)


900

800

700

600

500

400

300

200

100

0
1 2 3 4 5 6 7 8 9 10 11
-100

-200

Tiempo (meses)

Forma de un Sprint ideal
1800

1600

1400

1200

1000

800

600

400

200

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Tiempo (días)

Forma de un Sprint real
2500

2000

1500

1000

500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Tiempo (días)


Forma de un Sprint sin actualizar
2500

2000

1500

1000

500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Tiempo (días)


Forma de un Sprint subestimado
3000

2500

2000

1500

1000

500

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Tiempo (días)


Forma de un Sprint sobreestimado
1800

1600

1400

1200

1000

800

600

400

200

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Tiempo (días)

Entrega con control perfecto
6000

5000

4000

3000

2000

1000

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Tiempo (meses)


Entrega con funcionalidad reducida
6000

5000

4000

3000

2000

1000

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Tiempo (meses)


Entrega con un segundo equipo
6000

5000

4000

3000

2000

1000

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Tiempo (meses)


Entrega con tiempo agregado
6000

5000

4000

3000

2000

1000

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Tiempo (meses)


Para implementar Scrum #1
• Scrum encapsula todas las prácticas de ingeniería de software que
se usan en la organización
• Para la gestión del proyecto se pueden eliminar las cartas Gantt, los
reportes de horas, las largas reuniones para controlar el proyecto,
etc.
• Se recomienda comenzar con un proyecto nuevo
• El proyecto se inicia trabajando en conjunto durante varios días para
obtener un Backlog de producto inicial
• El Objetivo del primer Sprint puede llegar a ser: “presentar una
porción clave de funcionalidad en la tecnología seleccionada”
• Entre las tareas se deben incluir aquellas que permitan establecer el
ambiente de desarrollo, las prácticas de administración del código,
la tecnología para el sistema, etc.


Para implementar Scrum #2
• Durante el Sprint se deben aplicar todas las reglas tal como son, sin
excepción, respetándolas a rajatabla
• Una vez que haya transcurrido un tiempo prudencial utilizando
Scrum, recién entonces se podrán hacer ajustes al método para
adaptarlo a la propia organización
• Mientras el Equipo trabaja, el Scrum Master y el Dueño del
Producto continúan agregando ítems al Backlog de producto; ambos
son quienes establecen la visión del proyecto
• Al implementar Scrum en proyectos ya en marcha, el foco debe
estar en detectar los impedimentos y lograr que se empiecen a
entregar productos


Valores de Scrum

• Compromiso
• Estar en foco
• Apertura
• Respeto
• Sinceridad
• Coraje
• Confianza en sí mismo
• Iniciativa
• Auto organización
• Actitud proactiva


Palabras clave
• Metodologías ágiles • Estimaciones
• Cliente • Objetivo del Sprint
• Usuario • Incremento de producto
• Gerencia • Backlog del Sprint
• Dueño del Producto • Daily Scrum
• Scrum Master • Reunión de revisión del
• Backlog del Producto Sprint
• Backlog del Release • Terminación anormal del
Sprint
• Equipo de Scrum
• Sprint
• Reunión de Planificación del
Sprint


Referencias #1
• BECK, Kent, carta personal a Fernando Pinciroli (8/VII/2002).
• BECK, Kent, carta personal a Fernando Pinciroli (15/VII/2002).
• BOOCH, Grady, carta personal a Fernando Pinciroli (11/VII/2002).
• C3 TEAM. "Case Study: Chrysler Goes to 'Extremes'". En: Distributed Computing. Oct.
de 1998.
• DAVIES, Rachel. "The Power of Stories". Cap. 11. Londres, Connextra, s/f.
• FOWLER, Martin, carta personal a Fernando Pinciroli (8/VII/2002).
• JEFFRIES, Ron, carta personal a Fernando Pinciroli (8/VII/2002).
• JEFFRIES, Ron, carta personal a Fernando Pinciroli (16/VII/2002).
• SCHWABER, Ken y Mike Beedle. Agile Software Development with Scrum. Prentice-
Hall, 2002.
• WIRFS-BROCK, Rebecca, carta personal a Fernando Pinciroli (8/VII/2002).
• WIRFS-BROCK, Rebecca, carta personal a Fernando Pinciroli (15/VII/2002).


Referencias #2
En Internet:
• Agile Modeling: http://www.agilemodeling.com/
• Cristal Clear: http://alistair.cockburn.us/
• Dynamic Systems Development Method: http://www.dsdm.org
• Martin Fowler: http://www.martinfowler.com/
• SCRUM: http://www.controlchaos.com/
• XP: http://www.extremeprogramming.org/


Scrum hipolito

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (15)

Similar a Scrum hipolito

Similar a Scrum hipolito (20)

Scrum hipolito