¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible
Cascada Ágil

  • Orientadas al proceso

    • Un gran proyecto

    • Proceso secuencial

    • Estructurado

  • Orientadas a las personas

    • Muchos pequeños proyectos

    • Proceso iterativo e incremental. Fases en paralelo

    • Flexible. Adaptable. Mejora continua

  • Desarrollo Predictivo

    • Plazos y costes son conocidos al principio

    • Grandes y pocas entregas de software

  • Desarrollo Adaptativo

    • Ámbito y costes varían según evoluciona el proyecto

    • Entregas pequeñas y frecuentes de software, que siempre aportan valor

  • Orientadas a la documentación. Proyecto bien documentado con modelos gráficos (UML)

    • Buena definición de requisitos al principio

    • El usuario participa fundamentalmente en la fase inicial de toma de requisitos

  • Orientado al código. La documentación no es prioritaria

    • Los requisitos se van desgranando cuando se van a abordar

    • El usuario está involucrado constantemente en el proyecto. Comunicación fluida

  • Adecuado para situaciones dónde los cambios no son frecuentes

  • Adecuado cuando el usuario no conoce al detalle todas las necesidades al principio, y, además, serán cambiantes

¿Qué?

Scrum es un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptables para problemas complejos
— Ken Schwaber & Jeff Sutherland
La Guía Scrum

  • En pocas palabras, Scrum requiere un Scrum Master para fomentar un entorno donde:

    • 1. Un propietario del producto (Product Owner) ordena el trabajo de un problema complejo en un Product Backlog.

    • 2. El equipo de Scrum convierte una selección del trabajo en un Incremento de valor durante un Sprint.

    • 3. El equipo de Scrum y sus partes interesadas (stakeholders) inspeccionan los resultados y realizan los ajustes necesarios para el próximo Sprint.

    • 4. Repetir

  • Scrum es simple.

    • Pruébalo tal cual y determine si su filosofía, teoría y estructura ayudan a alcanzar metas y crear valor. El marco de Scrum es deliberadamente incompleto, solo define las partes necesarias para implementar la teoría de Scrum.

      • Scrum se basa en la inteligencia colectiva de las personas que lo utilizan. En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum guían sus relaciones e interacciones.

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible

¿Cómo?

Roles

El Dueño de Producto El Equipo El Scrum Master

  • Responsable de las pérdidas y ganancias del producto, asumiendo que es un producto comercial, por tanto, maximiza el retorno de inversión (ROI, return of investment)

    • identificando las funcionalidades del producto,

    • poniéndolas en una lista priorizada de funcionalidades, decidiendo cuales deberían ir al principio de la lista para el siguiente Sprint, y

    • re-priorizando y refinando continuamente la lista.

  • Coincide con el cliente en aplicaciones internas.

    • En otras, el cliente podría ser millones de personas con diferentes necesidades, en cuyo caso, es parecido al rol de jefe de producto/marketing

  • Es diferente al tradicional jefe de proyecto porque interactúa activa y frecuentemente con el equipo, revisando el resultado en cada iteración, en vez de delegar las decisiones de desarrollo

  • Construye el producto que va a usar el cliente

  • “Multi-funcional”, tiene todas las competencias y habilidades necesarias para entregar un producto potencialmente distribuible en cada Sprint

  • “Auto-organizado” (auto-gestionado), con un alto grado de autonomía y responsabilidad. En Scrum, los equipos se auto-organizan en vez de ser dirigidos por un jefe. El equipo decide a que se compromete, y cómo hacer lo mejor para cumplir con lo comprometido

  • Ayuda al grupo del producto a aprender y aplicar Scrum para conseguir valor de negocio. Hace lo que sea necesario para ayudar a que el equipo tenga éxito.

    • No es el jefe del equipo o jefe de proyecto; sirve al equipo, le protege de interferencias del exterior, y enseña y guía al Dueño del Producto y al equipo en el uso fructífero de Scrum.

    • Asegura de que todo el mundo entienda y siga las prácticas y ayuda a llevar a la organización, a través de los cambios necesarios y frecuentemente difíciles, a conseguir el éxito con el desarrollo ágil.

    • No puede ser también el Dueño del Producto porque a veces el Scrum Master necesitará pararle los pies, ni jefe de proyecto porque no le dice a la gente las tareas que tienen asignadas

  • Se conoce al equipo como los “Cerdos” y a todos los demás como “Gallinas”

  • un cerdo y una gallina que están hablando sobre abrir un restaurante llamado “Huevos con jamón”, y el cerdo no lo ve claro porque “él estaría comprometido, pero la gallina solo estaría implicada”

Artefactos

Pila de Producto (Product Backlog) Pila del Sprint (Sprint Backlog)

  • Es el corazón de Scrum, es donde empieza todo.

  • Es, básicamente, una lista priorizada de requisitos o funcionalidades, o lo que sea:

    • Cosas que el cliente quiere, descritas usando la terminología del cliente.

    • Llamamos a esto historias de usuario, o a veces simplemente [blue]elementos de la Pila del Producto.

  • El Dueño de Producto debería concentrarse en los objetivos de negocio.

    • Otras personas aparte del Dueño de Producto (implicados stakeholders) pueden añadir sus historias a la Pila de Producto.

      • Pero no pueden asignarles niveles de importancia, ese es un cometido exclusivo del Dueño de Producto.

      • Tampoco pueden establecer estimaciones, ese es un cometido exclusivo del equipo. El equipo está normalmente mejor capacitado para averiguar como resolver algo.

  • Representa las historias a las que el equipo se compromete durante este Sprint.

    • El equipo decide cuántas historias incluirá en el Sprint.

    • No el Dueño de Producto ni nadie más

Actividades

  • do {

    • Planificación del Sprint (\~1 día)

    • Desarrollo del Sprint (\~13 días)

      • for(int i=0; i<13; i++) {

        • Daily Meeting (\~15 minutos)

        • Test-driven Development (\~7:45 horas)

      • }

    • Demostración del Sprint (\~½ día)

    • Retrospectiva del Sprint (\~½día)

  • } (ProductBacklog != vacio)

actividades

Duración del Sprint

  • Los Sprints cortos están bien. Permiten a la compañía ser “ágil”, es decir,

    • cambiar de dirección frecuentemente ⇒

    • ciclo de feedback corto ⇒

    • más entregas y más frecuentes ⇒

    • más feedback del cliente ⇒

    • menos tiempo desarrollando en dirección incorrecta ⇒

    • aprender y mejorar más rápido, etc.

  • Generalmente, los Dueños de Producto prefieren los Sprints cortos y a los desarrolladores les gustan los Sprints largos.

    • Así que la duración del Sprint es un valor de compromiso. Hemos experimentados con varias duraciones y encontramos nuestra duración favorita es 3 semanas.

  • Los Sprints largos tampoco están mal.

    • El equipo tiene más tiempo para conseguir impulso,

    • tienen más espacio para recuperarse de los problemas que surjan y aun así cumplir la meta del Sprint,

    • tiene menos carga de gestión en términos de reuniones de planificación de Sprints, Demos, etc.

Planificación del Sprint

  • La planificación de Sprint es una reunión crítica, probablemente la más importante de Scrum.

    • Una planificación de Sprint mal ejecutada puede arruinar por completo todo el Sprint.

Participantes de la Planificación

¿quién?

Propósito de la Planificación

¿para qué?

Agenda de la Planificación

¿cuándo?

Meta de la Planificación

¿por qué?

Tarjetas de Historias de Usuario

¿cómo?

Tareas de la Pila del Sprint

Negociación de la Planificación

Comunicación de la Planificación

¿dónde?

Participantes de la Planificación

  • La razón por la que el equipo y el Dueño de Producto deben asistir a la planificación de Sprint es que cada historia contiene tres variables que son muy dependientes unas de otras:

    • El alcance y la importancia los fija el Dueño de Producto.

      • “The developers have different priorities for many of the stories. They may suggest that the priority of a story be changed based on its technical risk or because it is complementary to another story. The customer team listens to their opinions but then prioritizes stories in the manner that maximizes the value delivered to the organization.”

    • La estimación la proporciona el equipo.

  • Durante una planificación de Sprint, estas variables sufren un ajuste fino y continuo a través del diálogo cara a cara entre el equipo y el Dueño de Producto:

    • Normalmente, el Dueño de Producto comienza la reunión resumiendo cuál es su meta para el Sprint y las historias más importantes.

  • A continuación, el equipo las repasa y les asigna una estimación, comenzando con la más importante. Conforme van haciéndolo, aparecerán dudas importantes respecto al alcance:

    • En algunos casos, las respuestas sorprenderán al equipo y les obligarán a cambiar sus estimaciones.

      • “esta historia sobre ‘borrar usuario’, ¿incluye repasar todas las transacciones pendientes del usuario y cancelarlas?”.

    • En algunos casos, la estimación para una historia no será la que el Dueño de Producto esperaba.

      • Esto puede forzarle a cambiar la importancia de la historia o su alcance, lo que obligará al equipo a re-estimarla, etc., etc.

Propósito de la Planificación

  • El propósito de la planificación de Sprint es proporcionar al equipo suficiente información como para que puedan trabajar en paz y sin interrupciones durante unas pocas semanas, y para ofrecer al Dueño de Producto suficiente confianza como para permitírselo. Una planificación de Sprint produce, concretamente:

  • 1. Una meta del Sprint

  • 2. Una lista de miembros (y su nivel de dedicación, si no es del 100%)

  • 3. Una Pila de Sprint (lista de historias incluidas en el Sprint)

  • 4. Un lugar y momento definidos para el ScrumDiario.

  • 5. Una fecha concreta para la Demo del Sprint.

Agenda de la Planificación

13:00 –13:30.

  • El Dueño de Producto comenta la meta del Sprint y resume la Pila de Producto.

  • Se establece un lugar, fecha y hora para la Demo.

13:30 –15:00.

  • El equipo da estimaciones de tiempo, y divide los elementos tanto como sea necesario.

  • El Dueño de Producto actualiza los ratios de importancia.

  • Se clarifican los elementos. Para todos los elementos de alta importancia se establece el “Como probarlo”.

15:00 –17:00.

  • El equipo selecciona las historias que se incluirán en el Sprint.

    • Se realizan cálculos de velocidad para chequear si es factible.

  • El Scrum Master puede ampliar o acortar los periodos según sea necesario conforme progresa la reunión pero a priori es cerrada (time-boxed)

Meta de la Planificación

  • La meta de Sprint debería responder a la pregunta fundamental: ¿Por qué hacemos este Sprint?

    • De hecho, una forma de obtener la meta del Dueño de Producto es precisamente hacerle esa misma pregunta.

  • Lo importante es que esté descrito en términos de negocio. Eso significa en términos en los que la gente de fuera del equipo lo pueda entender.

  • La meta debería ser algo que no se haya logrado aun.

  • La meta del Sprint puede parece bastante tonta y artificial durante la planificación de Sprint, pero muchas veces resulta útil a mediados de Sprint, cuando la gente comienza a sentirse confusa acerca de lo que deberían estar haciendo.

Tarjetas de Historias de Usuario

height32

height32

  • Crear tarjetas y ponerlas en la pared (o en una mesa grande). Una solución que funciona mucho mejor. En cualquier caso, una vez que las tarjetas están en la pared puedes ignorar el ratio de importancia y en lugar de ello usar el orden físico para indicar la importancia relativa. Si el dueño de producto cambia dos historias de sitio no pierdas el tiempo actualizando los ratios de importancia en la tarjeta.

  • Este es un interfaz muy superior, comparado con un ordenador y un proyector, debido a que:

    • La gente se pone de pie y camina alrededor y se mantienen despiertos y alerta más tiempo

    • Todo el mundo se siente personalmente más involucrado (y no solamente el tipo del teclado)

    • Se pueden editar múltiples historias simultáneamente

    • Repriorizar es trivial –simplemente se trata de mover las tarjetas

  • El Dueño de Producto imprime los elementos de Jira [gestor de tareas] más importantes, los trae a la reunión de planificación de Sprint y los coloca en la pared junto al resto de historias (especificando así implícitamente la prioridad de estos elementos comparados con las otras historias).

  • Es importante que el dueño de producto y el equipo estén de acuerdo en una definición clara de “terminado”. ¿Está terminada una historia cuando todo el código ha sido chequeado? ¿O cuando se ha instalado en un entorno de pre-producción y ha sido verificada por un equipo de pruebas de integración? A veces debemos conformarnos con “instalado en preproducción y lista para las pruebas de aceptación”.

  • Tras la reunión de planificación de Sprint, el Scrum Master actualiza manualmente la Pila de Producto en Excel respecto a cualquier cambio que se haya realizado sobre las tarjetas de historia físicas.

    • Sí, es una pequeña molestia administrativa, pero lo encontramos perfectamente asumible considerando cuánto más eficiente es la reunión de planificación de Sprint utilizando tarjetas físicas.

  • Errores heredados del Sprint anterior:

    • La corrección de errores se considera algo fuera del Sprint. Entonces simplemente se asume que el equipo pasará parte de su tiempo arreglando los errores.

    • El equipo mantiene un factor de dedicación suficientemente bajo (por ejemplo, el 50%) para asegurar que tienen tiempo suficiente para arreglar errores.

Tareas de la Pila del Sprint

  • Las estimaciones de tiempo son normalmente más fáciles de hacer (y más exactas) si una historia se subdivide en tareas. Puedes hacer que el equipo se divida en parejas y que cada una subdivida una historia en paralelo. Físicamente, hacemos esto añadiendo pequeñas notas post-it bajo cada historia, de forma que cada post-it representa una tarea dentro de dicha historia.

height32

  • ¿Cuál es la diferencia entre historias y tareas? Una pregunta muy válida. La diferencia es muy simple. Las historias son entregables de los que el Dueño de Producto se preocupa. Las tareas son no-entregables, o aspectos de los que el Dueño de Producto no se preocupa.

    • Los equipos que están empezando con Scrum son reticentes a perder tiempo dividiendo un montón de historias en tareas desde el principio. Algunos piensan que es una aproximación tipo “cascada”.

  • Para historias que se entienden bien, es tan fácil hacer esto desde el principio como hacerlo más tarde

  • Este tipo de división frecuentemente revela trabajo adicional que hace que las estimaciones suban, con lo que se consigue un plan de Sprint más realista.

  • Este tipo de división desde el principio hace que los Scrum diarios sean notablemente más eficientes.

  • Incluso si la división es inexacta y cambia una vez que empezamos, todas las ventajas anteriormente mencionadas siguen siendo válidas.

  • En la práctica significa que la primera tarea para casi todas las historias es “escribir una prueba” y la última es “refactorizar” (es decir, mejorar la legibilidad del código y eliminar la duplicación).

  • No actualizamos la Pila de Producto en Excel respecto a nuestra división en tareas por dos razones:

    • La división en tareas suele ser bastante volátil, es decir, se cambia y se refina con frecuencia durante el Sprint, así que es bastante molesto mantener la Pila de Producto en el Excel.

    • De todas formas, el Dueño de Producto no necesita estar involucrado a ese nivel de detalle.

  • La estimación es una labor de equipo: todos los miembros del equipo deben involucrarse en estimar cada historia. ¿Por qué?

    • A la hora de planificar, normalmente no sabemos exactamente quién implementará qué partes de cada historia.

    • Las historias normalmente involucran a bastantes personas y de diferentes áreas de experiencia (diseño de interfaz de usuario, programación, pruebas, etc.).

    • Cuando pedimos a todo el mundo que de estimaciones muchas veces encontramos discrepancias en las que dos miembros del equipo tienen estimaciones tremendamente distintas sobre la misma historia. Es mejor descubrir tales cosas al principio.

    • Para poder proporcionar una estimación, un miembro del equipo necesita comprender de alguna forma de qué trata la historia. Pidiendo a todo el mundo que estime la historia nos aseguramos de que cada miembro del equipo comprende de qué trata cada elemento. Esto incrementa las posibilidades de que unos miembros del equipo ayuden a otros durante el Sprint. También mejora las posibilidades de que aparezcan pronto las preguntas importantes sobre cada historia.

    • Si pides al equipo que proporcione una estimación, normalmente la persona que entiende mejor la historia será el primero en soltar una. Desafortunadamente, esto afectará severamente a las estimaciones de los demás

Planning poker

  • Cada miembro del equipo cuenta con una baraja de 11 cartas: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 y 100. Cada vez que hay que estimar una historia, cada miembro del equipo selecciona una carta que representa su estimación de tiempo (en puntos de historia) y la coloca boca abajo en la mesa.

    • Date cuenta de que la secuencia de números no es lineal. ¿Por qué? Esto es para evitar una falsa sensación de exactitud para las estimaciones de tiempo más grandes. Si una historia se estima aproximadamente en 20 puntos, no es relevante discutir si deberían ser, 18 o 21. Todo lo que sabemos es que es una historia grande y es difícil de estimar. Así que 20 es nuestra idea aproximada.

  • Cuando todos los miembros del equipo han preparado sus cartas, se les da la vuelta al mismo tiempo. Así obligamos a cada miembro del equipo a pensar por si mismo en lugar de seguir la estimación de otro.

    • Si hay mucha discrepancia entre dos estimaciones, el equipo discute las diferencias y trata de construir una imagen común del trabajo necesario para la historia. Pueden hacer algún tipo de división en tareas.

    • Después, el equipo estima de nuevo. Este bucle se repite hasta que la estimación de tiempo converge, es decir, que todas las estimaciones sean aproximadamente las mismas para esa historia.

  • Es importante que los miembros del equipo recuerden que deben estimar el total de tiempo necesario para la historia. No solamente “su” parte del trabajo.

  • Normalmente buscamos historias con estimaciones de 2 a 8 días/hombre. Nuestra velocidad es usualmente 40-60 para un equipo típico, así que eso nos da para unas 10 historias por Sprint. A veces sólo 5, y a veces hasta 15. Es un número de tarjetas gestionable con el que trabajar.

    • Las historias no deberían ser demasiado pequeñas ni demasiado grandes (en términos de estimación).

    • Si tienes un montón de historias de 0.5 puntos probablemente vas a ser una víctima de la micro-gestión.

    • Por otra parte, una historia de 40 puntos corre un importante riesgo de acabar parcialmente completa, lo que no aporta valor a tu empresa y simplemente incremente la administración. Lo que es más, si tu velocidad estimada es 70 y tus dos historias más prioritarias pesan 40 puntos cada una, la planificación se vuelve difícil. Tienes que elegir entre comprometerte a más de lo que deberías (escoger las dos historias) o a menos (elegir sólo una).

Negociación de la Planificación

  • El equipo decide cuántas historias incluirá en el Sprint. No el Dueño de Producto ni nadie más.

    • La Pila de Sprint de la derecha es una instantánea de las historias la Pila de Producto. Representa las historias a las que el equipo se compromete durante este Sprint.

    • Cada rectángulo representa una historia, ordenadas por importancia.

      • La historia más importante está al principio de la lista.

      • El tamaño de cada rectángulo representa el tamaño de la historia (es decir, el tiempo estimado en puntos de historia).

      • La altura del corchete azul representa la velocidad estimada del equipo, es decir, cuántos puntos de historia cree el equipo que puede completar durante el próximo Sprint.

height32
Métodos de Cálculo de la Velocidad estimada del Equipo

  • Estimando a ojo de buen cubero

  • Estimando usando cálculos de velocidad
Fundamentos:

  • Una manera muy fácil de estimar la velocidad es revisar la historia del equipo. ¿Cuál fue su velocidad durante los últimos Sprints? Y entonces asumir que la velocidad será más o menos la misma en el próximo Sprint.

  • Esta técnica se conoce como el tiempo que hizo ayer.

    • Solo es factible para equipos que ya han hecho algunos Sprints (de forma que haya estadísticas disponibles) y que harán el próximo Sprint más o menos de la misma manera, con el mismo tamaño de equipo, las mismas condiciones de trabajo, etc. Este, claro está, no siempre es el caso.

  • El siguiente gráfico muestra un ejemplo de velocidad estimada al principio de un Sprint y la velocidad real al final de dicho Sprint. Cada rectángulo es una historia, y el número interior es la estimación inicial de dicha historia.

height32

  • ¿Es esta nuestra velocidad estimada? No, porque nuestra unidad de estimación son puntos de historia lo que, en nuestro caso, corresponde más o menos a “días-hombre ideales”. Un día-hombre ideal es un día perfectamente efectivo, sin distracciones, lo cuál es raro. Lo que es más, debemos tener en cuenta cosas como trabajo no planificado que se añade al Sprint (enfermos, …​)

 
                       Velocidad Real Anterior
Factor de dedicación =------------------------
                        Dias Hombre Anterior

  • Digamos que en el último Sprint se completaron 18 puntos de historia utilizando un equipo de 3 personas formado por X, Y y Z trabajando las tres semanas hasta un total de 45 días-hombre

 
                       18 puntos de historia
Factor de dedicacion = ---------------------- =40%
                          45 dias - Hombre

  • Digamos que estamos planificando un Sprint de 3 semanas (15 días laborables) con un equipo de 4 personas. X estará de vacaciones 2 días. Y sólo estará disponible al 50% y estará un día de vacaciones. Poniéndolo todo junto …​ 50 días-hombre

  • Velocidad estimada = Factor de dedicación * Días-hombre próximo

  • Velocidad estimada = 40% * 50 días-hombre = 20 puntos de historia

  • Velocidad estimada del equipo: es una medida de “cantidad de trabajo realizado”, donde cada elemento se evalúa en función de su estimación inicial.

    • Se trata de un número bastante aproximado. Pero aun así es bastante útil, especialmente si lo comparamos con “nada en absoluto”. Proporciona algunos verdades crudas: “sean cuales sean las razones, aquí está la diferencia aproximada entre cuánto pensábamos que podríamos hacer y cuánto hicimos en realidad”.

    • El factor de dedicación “por defecto” que usamos para equipos nuevos es habitualmente el 70%.

      • Si una nueva persona se une a este Sprint deberías reducir su factor de dedicación para tener en cuenta su formación

  • Siempre que sea posible, ten en cuenta varios Sprints y saca medias para conseguir estimaciones más acertadas.

    • Si el último Sprint fue especialmente malo porque la mayoría del equipo estuvo enfermo una semana, entonces podría ser adecuado asumir que no volverás a tener tan mala suerte y podrías estimar un factor de dedicación mayor el próximo Sprint.

    • Si el equipo ha instalado recientemente un sistema super-rápido de compilación continua probablemente también podrás incrementar el factor de dedicación gracias a ello.

  • Nota que la velocidad real esta basada en las estimaciones iniciales de cada historia. Cualquier actualización a la estimación de la historia realizada durante el Sprint es ignorada.

  • ¿Qué ocurre si el equipo es completamente Nuevo y no tienes ninguna estadística? Mira al factor de dedicación de otros equipos en circunstancias similares.

    • ¿Qué pasa si no tienes otros equipos en los que fijarte? Adivina un factor de dedicación. Las buenas noticias son que sólo deberás adivinar para el primer Sprint. Después, tendrás estadísticas que podrás ir midiendo continuamente para aproximar mejor el factor de dedicación y la velocidad estimada.

  • ¿Qué pasa con las historias que casi se consiguieron durante el Sprint? ¿Por qué no conseguimos algunos puntos por ellas en la velocidad real? Esto es así para reforzar el hecho de que Scrum gira en torno al concepto de conseguir que las cosas se hagan completamente, hasta un estado de “potencialmente entregable”. El valor de las cosas medio hechas es cero

  • Una de las principales actividades durante la planificación de Sprint es decidir qué historias se incluyen en el Sprint. Más específicamente, qué historias de la Pila de Producto copiar en la Pila de Sprint.

  • Supongamos que tenemos la siguiente situación durante una reunión de planificación de Sprint.

    • Al Dueño de Producto no le gusta que la historia D no se vaya a incluir en el Sprint. ¿Cuáles son sus opciones durante la reunión de planificación de Sprint?

height32

  • Una es re-priorizar. Si le da al elemento D la mayor importancia, el equipo se verá obligado a añadirlo al Sprint en primer lugar (descartando en ese caso la historia C).

height32

  • La segunda opción es cambiar el alcance –reducir el alcance de la historia A hasta que el equipo crea que la historia D podría caber en el Sprint.

height32

  • La tercera sería dividir una historia. El Dueño de Producto podría decidir que hay algunos aspectos de la historia A que no son tan importantes, así que dividiría la historia A en dos historia A1 y A2 con diferentes niveles de importancia.

height32

Comunicación de la Planificación

Planificación3

  • Página de información de Sprint. Tan pronto como sea posible tras la reunión de planificación de Sprint, el Scrum Master crea esta página, la pone en el Wiki, manda un spam e imprime la página de información de Sprint y la pega en la pared de la sala de desarrollo

  • Cuando el Sprint se acerca a su final, el Scrum Master recuerda a todo el mundo que se acerca la demo

height32

Realización del Sprint

  • Busca una pared que no esté usada por lo menos de 2x2 metros, o 3x2 para un equipo grande y entonces haz esto:

  • Después del primer Scrum, el tablón puede aparecer así. Como puedes ver, tres tareas están “en proceso”, es decir, el equipo estará trabajando en estos elementos hoy.

    • A veces, para equipos más grandes, una tarea queda atascada “en progreso” porque nadie recuerda quién estaba trabajando en ella. Si esto ocurre a menudo en un equipo, usualmente introducimos políticas como etiquetar cada tarea enprogresocon el nombre de la persona que la ha emprendido. :

  • Unos días más tarde el tablón puede aparecer de la siguiente manera. Tenemos tres elementos no planificados, como puede verse abajo a la derecha. Esto es útil para recordar cuando hagamos retrospectiva del Sprint.

  • Como puede observarse, se ha completado la historia “Depósito” (es decir, ha sido chequeada en el repositorio de código fuente, testeada, refactorizada, etcétera). La herramienta de migración (segunda historia) está parcialmente completada. La tercera historia (“backofficelogin”) ha comenzado, y la cuarta (“backofficeuseradmin.”) no ha empezado aun.

RelazacionDelSprint

RelazacionDelSprint2

RelazacionDelSprint3

Burndown

  • En el primer día del Sprint, 1 de Agosto, el equipo estimó que habían aproximadamente 70 puntos de historia en los que trabajar. Esta era, consecuentemente, la velocidad estimada para todo el Sprint.

height32

  • El 16 de Agosto el equipo estima que quedan aproximadamente 15 puntos de historia por hacer. La línea de puntos nos muestra que estamos incluso algo avanzados respecto a la planificación, es decir, que a este paso completaríamos todo al final del Sprint.

height32

height32

height32

Sala de Equipo

  • No hay mejor manera para obtener una visión general del sistema que estar de pie en la esquina de diseño y observar ambas paredes, entonces echar un vistazo en el ordenador y probar la última compilación del sistema

    • La “pared de diseño” es sólo una pizarra grande que contiene los garabateos más importantes sobre el diseño y la documentación impresa más importante

height32

  • No hay mejor manera cuando se trata de asientos y disposición de mesas, hay una cosa en la que nunca puede hacerse demasiado énfasis: ¡Sienta al equipo junto!

    • Audibilidad: cualquier miembro del equipo puede hablar con cualquier otro sin tener que levantarse de su sitio.

    • Visibilidad: todo el mundo puede ver a los demás. Todo el mundo puede ver el tablón de tareas. No necesariamente tan de cerca como para poder leerlo, pero si por lo menos verlo.

    • Aislamiento: si todo el equipo necesitase levantarse y agruparse para una animada y espontánea discusión sobre el diseño, nadie fuera del equipo está tan cerca como para ser molestado. Y viceversa.

  • [blue]El Dueño de Producto:

    • debería estar suficientemente cerca como para que el equipo pueda caminar hasta donde está y preguntarle algo, y para que él pueda acercarse al tablón de tareas.

    • Pero no debería sentársele junto al equipo. ¿Por qué? Porque lo más probable es que no sea capaz de controlarse e interrumpa constantemente entrometiéndose en cualquier detalle, y el equipo no podrá “fluir” adecuadamente (es decir, alcanzar un estado centrado, autogestionadoe hiperproductivo)

Scrum diario

  • Empiezan exactamente a su hora, cada día en el mismo sitio. Las reuniones de pie, ya que eso reduce el riesgo de sobrepasar los 15 minutos.

  • Se actualiza el tablón de tareas durante los Scrum diarios.

    • Conforme cada persona describe lo que hizo el día anterior y lo que hará hoy, mueve los post-it en el tablón. Si no tiene nada que hacer, están disponible para dar ayuda en programación por parejas.

    • Conforme describe elementos no planificados, pone un pos-it nuevo para cada uno de ellos.

    • Conforme actualiza sus estimaciones, escribe una nueva estimación en el post-it correspondiente y tacha la anterior estimación.

  • El Scrum Master

    • hace todo esto mientras los demás hablan (mueve post-it, re-estima, elementos no planificados).

    • Inmediatamente tras el Scrum diario, suma todas las estimaciones de tiempo (ignorando los de la columna “terminado”) y dibuja un nuevo punto en el burn-down de Sprint

Demo del Sprint

Objetivos

Contenidos

  • El equipo obtiene reconocimiento por sus logros. Se sienten bien.

  • Otras personas se enteran de lo que está haciendo el equipo.

  • La demo consigue feedback vital de los interesados.

  • Hacer una demo fuerza al equipo a acabar realmente las cosas y entregarlas (incluso aunque sea sólo en entorno de pruebas).

    • Sin las demos, seguimos consiguiendo enormes montones de cosas terminadas al 99%.

    • Con las demos puede que consigamos menos cosas terminadas, pero estas están realmente terminadas, lo que (en nuestro caso) es mucho mejor que tener una enorme pila de cosas que están más o menos listas y que se pulirán en el próximo Sprint.

  • Si un equipo se ve obligado a hacer una demo de Sprint, incluso aunque no tengan mucho que realmente esté funcionando, la demo será embarazosa. El equipo tartamudeará y tropezará mientras hace la demo y el aplauso de después será frío. La gente sentirá un poco de pena por el equipo, algunos se enfadarán con ellos por hacerles perder el tiempo con una demo pésima. Esto duele, pero el efecto es similar al de una amarga medicina.

  • En el próximo Sprint, el equipo intentará por todos los medios tener cosas terminadas. Sentirán algo como “bueno, puede que sólo podamos demostrar dos historias el próximo Sprint en vez de cinco, pero maldita sea, ¡esta vez *VA A FUNCIONAR!”*. El equipo sabe que tendrán que hacer una demo pase lo que pase, lo que incrementa significativamente las posibilidades de que haya algo útil que demostrar. He visto como esto ocurría varias veces.

  • Asegúrate de presentar claramente el objetivo del Sprint. Si hay personas en la demo que no saben nada sobre tu producto, tomate un par de minutos para describirlo.

  • No pierdas mucho tiempo preparando la demo. Mantén el paso rápido, es decir, concentra tu preparación en hacer que la demo sea rápida en lugar de bonita.

  • Mantén la demo a nivel de negocio, deja los detalles técnicos aparte. Concéntrate en “qué hemos hecho” en lugar de “cómo lo hemos hecho”.

  • En la medida de lo posible, deja que la audiencia pruebe el producto por si misma.

  • No muestres un montón de pequeños errores solucionados y funcionalidades triviales. Menciónalos, pero no los muestres, ya que normalmente se tarda mucho y desvía la atención de las historias.

Retrospectiva del Sprint

  • Las retrospectivas son extremadamente útiles. De hecho, se diría que es el segundo evento más importante de Scrum ya que ¡es la mejor oportunidad para mejorar!

    • la idea viene “del equipo”, es decir, surge durante la retrospectiva y a todo el mundo se le permite contribuir y discutir las ideas

    • Sin las retrospectivas encontrarás que el equipo sigue cometiendo los mismos errores una y otra vez.

  • Reservamos 1-3 horas, dependiendo de cuánta discusión esperemos con el Dueño de Producto, el equipo y el Scrum Master.

  • Normalmente no hacemos retrospectivas en la sala del equipo, ya que la atención de la gente suele diluirse.

  • El Scrum Master muestra la Pila de Sprint y, con ayuda del equipo, resume el Sprint. Eventos importantes, decisiones, etc.

  • Cada persona tiene una oportunidad de decir, sin ser interrumpida, qué piensan que ha ido bien, que podría haber ido mejor y que piensan que debería hacerse de forma diferente en el próximo Sprint.

    • Deberíamos haber pasado más tiempo dividiendo historias en subhistoriasy tareas

    • Demasiadas distracciones

    • Nos sobre-comprometimos y sólo hicimos la mitad

    • Nuestro entorno de oficina es demasiado ruidoso y desordenado

  • Observamos la velocidad estimada frente a la real. Si hay una gran diferencia, intentamos analizar por qué.

  • El Scrum Master trata de resumir las sugerencias concretas sobre qué puede hacerse mejor el próximo Sprint.

Contenido

  • Después de que el equipo genere todas estas ideas en post-its, utilizan “votación por puntos” para determinar en qué mejoras centrarse el próximo Sprint. Cada miembro del equipo tiene tres imanes y se les invita a votar sobre cualquier mejora en la que les gustaría trabajar en el próximo Sprint. Cada miembro del equipo distribuye los imanes como quiera, incluso colocando los tres en el mismo elemento.

  • Basándonos en esto, seleccionamos 5 mejoras de procesos en los que concentrarse y los evaluamos en la siguiente retrospectiva. Es importante no ser demasiado ambicioso. Concéntrate en unas pocas mejoras en cada Sprint.

Sintesis

Bibliografía

Obra, Autor y Editor Portada Obra, Autor y Editor Portada

  • Refactoring (Pearson Addison-Wesley Signature Series)

    • Fowler Martin

    • Financial Times Prentice Hall; Edición: 01 (28 de noviembre de 2018)

height32

  • Test Driven Development. By Example (The Addison-Wesley Signature Series

    • Beck Kent

    • Addison Wesley; Edición: 01 (8 de noviembre de 2002)

height32

  • Extreme Programming Explained: Embrace Change: Embracing Change

    • Kent Beck, Cynthia Andres

    • Addison-Wesley Educational Publishers Inc; Edición: 2nd edition (16 de noviembre de 2004)

height32

  • Planning Extreme Programming (The Xp Series)

    • Beck Kent, Fowler Martin

    • Addison Wesley; Edición: 01 (16 de octubre de 2000)

height32

  • Scrum and XP from the Trenches (Enterprise Software Development)

    • Henrik Kniberg

    • Lulu.com; Edición: 1 (4 de octubre de 2007)

height32

  • Scrum: El revolucionario método para trabajar el doble en la mitad de tiempo

    • Jeff Sutherland,

    • Editorial Ariel (20 de enero de 2015)

height32

  • Refactoring Databases: Evolutionary Database Design

    • Scott J Ambler, Pramod J. Sadalage

    • Addison-Wesley Professional; Edición: 1 (13 de marzo de 2006)

height32

  • User Stories Applied: For Agile Software Development

    • Cohn, M.

    • Addison Wesley, 2004

UserStoriesAppliedForAgileSoftwareDevelopment

  • Scrum y XP desde las trincheras

    • Henrik Kniberg. Prólogos de Jeff Sutherland y Mike Cohn

    • proyectalis.com

ScrumXPTrenches

  • Diseño Ágil con TDD

    • Carlos Blé Jurado

    • Lulu.com

DisenoAgilconTDD

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM