1 - Introduccion A Scrum

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
4 – Conclusiones
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
•
•
Trabajo remanente (hs.)
Administración empírica #1
Tiempo (meses)
Tiempo (meses)
Tiempo (meses)
Forma de un Sprint ideal
Tiempo (días)
Forma de un Sprint real
Tiempo (días)
Forma de un Sprint sin actualizar
Tiempo (días)
Forma de un Sprint subestimado
Tiempo (días)
Forma de un Sprint sobreestimado
Tiempo (días)
Entrega con control perfecto
Tiempo (meses)
Entrega con funcionalidad reducida
Tiempo (meses)
Entrega con un segundo equipo
Tiempo (meses)
Entrega con tiempo agregado
Tiempo (meses)
4 – Conclusiones
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
4 – Conclusiones
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 Sprint
•Backlog del Producto •Terminación anormal del
•Backlog del Release 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/
•

1 - Introduccion A Scrum

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1 - Introduccion A Scrum

Cargado por

Copyright:

Formatos disponibles

INTRODUCCIÓN A SCRUM

Kenny Rubin Kent Beck Alistair Cockburn Grady Booch

Ron Jeffries James Rumbaugh Martin Fowler Rebecca Wirfs-Brock

•De un tiempo a esta parte apareció un nuevo concepto dentro de la

•Se considera que un modelo es ágil o liviano cuando se emplea para

•Un modelo es suficientemente bueno cuando cumple con los

•Los principales enfoques ágiles son XP (eXtreme Programming),

•Los equipos de desarrollo normalmente son de dos a doce personas,

•El usuario debe estar siempre disponible

•Escribir unidades de prueba para todo el código

•Crear nuevas pruebas al detectar errores

•Estos valores son:

•El nombre describe un proceso de desarrollo hiperproductivo de

•Permite coordinar los recursos humanos de modo de que trabajen

También podría gustarte