Scrum hipolito

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

INTRODUCCIÓN A SCRUM

Fernando PinciroliMarzo de 2010

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



• 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 #1



• 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

Enfoques ágiles #2



• 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

Programación extrema #1



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




• 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

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 proyecto8. Los procesos ágiles promueven el desarrollo sostenido. Los interesados,

desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida9. La atención continua a la excelencia técnica y al buen diseño promueve la agilidad10. La simplicidad –el arte de maximizar la cantidad de trabajo que no se hace- es esencial11. Las mejores arquitecturas, requisitos y diseños surgen de equipos auto-organizados12. El equipo reflexiona sobre la forma de ser más efectivo en intervalos regulares y ajusta

su conducta en consecuencia

Principios del manifiesto ágil



• 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 #1



• 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

Acerca de Scrum #2



• 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

Historia 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

Beneficios de Scrum



• 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

Bases conceptuales



• 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

Resultados esperados







4 – Conclusiones



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



• 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 #1



• 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 #2



• 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

Product Backlog #3



• 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

Scrum Master



• 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 #1



• 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 #2



• 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

Sprint #3



• 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

Incremento de producto



• 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

Reunión de planificación del Sprint #1



• 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




• 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 #1



• 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 #2



• 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 #3



• 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 #4



• 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

Daily scrum #5



• 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

Reunión de revisión del Sprint #1



• 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




• 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 #1



• 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 #2



• 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 #3



• 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 #4



• 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 #5



• 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

Equipo de Scrum #6



• 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

Terminación anormal de un Sprint



• 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 #1



• 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

Estimaciones #2



Administración empírica #1

Trab

ajo

rem

an

en

te (

hs.)

Tiempo (meses)1 2 3 4 5 6 7 8 9

0

100

200

300

400

500

600

700

800

900



Trab

ajo

rem

an

en

te (

hs.)

Tiempo (meses)

1 2 3 4 5 6 7 8 9 10 11

-200

0

200

400

600

800

1000




Trab

ajo

rem

an

en

te (

hs.)

Tiempo (meses)

1 2 3 4 5 6 7 8 9 10

-200

0

200

400

600

800

1000




Trab

ajo

rem

an

en

te (

hs.)

Tiempo (días)

Forma de un Sprint ideal

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 310

200

400

600

800

1000

1200

1400

1600

1800



Trab

ajo

rem

an

en

te (

hs.)

Tiempo (días)

Forma de un Sprint real

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 310

500

1000

1500

2000

2500



Trab

ajo

rem

an

en

te (

hs.)

Tiempo (días)

Forma de un Sprint sin actualizar

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 310

500

1000

1500

2000

2500



Trab

ajo

rem

an

en

te (

hs.)

Tiempo (días)

Forma de un Sprint subestimado

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 310

500

1000

1500

2000

2500

3000



Trab

ajo

rem

an

en

te (

hs.)

Tiempo (días)

Forma de un Sprint sobreestimado

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 310

200

400

600

800

1000

1200

1400

1600

1800



Entrega con control perfectoTr

ab

ajo

rem

an

en

te (

hs.)

Tiempo (meses)

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

1000

2000

3000

4000

5000

6000



Entrega con funcionalidad reducida

Trab

ajo

rem

an

en

te (

hs.)

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

0

1000

2000

3000

4000

5000

6000



Entrega con un segundo equipoTr

ab

ajo

rem

an

en

te (

hs.)

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

0

1000

2000

3000

4000

5000

6000



Entrega con tiempo agregadoTr

ab

ajo

rem

an

en

te (

hs.)

Tiempo (meses)

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

1000

2000

3000

4000

5000

6000







4 – Conclusiones



• 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 #1



• 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

Para implementar Scrum #2







4 – Conclusiones



• Compromiso

• Estar en foco

• Apertura

• Respeto

• Sinceridad

• Coraje

• Confianza en sí mismo

• Iniciativa

• Auto organización

• Actitud proactiva

Valores de Scrum



Palabras clave

• Metodologías ágiles

• Cliente

• Usuario

• Gerencia

• Dueño del Producto

• Scrum Master

• Backlog del Producto

• Backlog del Release

• Equipo de Scrum

• Sprint

• Reunión de Planificación del Sprint

• Estimaciones

• Objetivo del Sprint

• Incremento de producto

• Backlog del Sprint

• Daily Scrum

• Reunión de revisión del Sprint

• Terminación anormal 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

Documents

Transcript of Scrum hipolito