Introducción a técnicas ágiles y Scrum 

Curso taller

Visión

El asistente al curso aprenderá los principios y dinámica Scrum y la filosofía Agile, así como, en que situaciones aplicarla.

Valores y Principios de Agile

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Agile Manifesto

1. Nuestra máxima prioridad es satisfacer al cliente a través de una temprana y continua entrega de software de gran utilidad.

2. Son bienvenidos los  cambios de requerimientos, incluso tarde en el desarrollo. Los procesos Ágiles aprovechan el cambio para obtener ventajas competitivas para el cliente.

3. Entregar software funcional con una cierta frecuencia, en un par de semanas a un par de meses, con preferencia a la escala de tiempo más corto.

12 Principios Agiles

4. La gente del negocio y desarrolladores deben trabajar juntos todos los días en todo el proyecto.

5. Construir proyectos en torno a individuos motivados. Brindarles el medio ambiente y el apoyo que necesitan, y confiar en ellos para hacer el trabajo.

6. El método más eficiente y eficaz de transmisión de información de un equipo de desarrollo es la conversación cara a cara.

12 Principios Agiles

7. Software funcional es la principal medida de progreso.

8. Procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y los usuarios deben ser capaces de mantener un ritmo constante indefinidamente.

9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.

12 Principios Agiles

10. La simplicidad –el  arte de maximizar la cantidad de trabajo innecesario– es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12. A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaces, luego ajusta su comportamiento en consecuencia.

12 Principios Agiles

Somos una comunidad de líderes de proyectos altamente exitosos en la entrega de resultados. Para alcanzar estos resultados: Aumentamos retorno de la inversión, haciendo del flujo continuo

de valor nuestro enfoque. Entregamos resultados fiables mediante la participación de los

clientes en las interacciones frecuentes y la propiedad compartida. Esperamos la incertidumbre y la gestionamos a través de

iteraciones, anticipación y adaptación. Liberamos la creatividad y la innovación al reconocer que las

personas son la fuente más grande de aporte de valor, y creando un entorno en el que pueden hacer la diferencia.

Impulsamos el rendimiento mediante rendición de cuentas del grupo para resultados y la responsabilidad compartida para la eficacia del equipo.

Mejoramos la eficacia y la confiabilidad a través de estrategias, procesos y prácticas específicas a la situación.

La Declaración de Interdependencia

Libertad para el cambio Equipo energizado Comunicación con el cliente Colaboración Atención a la calidad Incrementalismo Automatización

Factores de Éxito en Agile

Clientes satisfechos Mejora de la retorno de la inversión Reducción de costos Resultados rápidos Confianza para tener éxito en un

mundo complejo Más alegría

Beneficios de Scrum

Visión General de Scrum

Ikujiro Nonaka y Hirotaka Takeuchi (Harvard Business Review en 1986) “The New New Product Development Game,”

Jeff Sutherland(VP de Engineering en Easel, Inc) En 1993 Sutherland y su equipo desarrollaron dicho proceso  combinando conceptos del artículo de Takeuchi  y Nonaka con conceptos de desarrollo orientado a objetos, control de procesos empíricos, desarrollo iterativo e incremental, procesos de software e investigación de productividad y sistemas complejos adaptativos.

Ken Schwaber estaba buscando la manera de mejorar la productividad de los equipos de desarrollo de su empresa (Advanced Development Methods, Inc.), a través de la mejora de sus procesos.

En 1995, Ken Schwaber publicó el primer artículo sobre Scrum en OOPSLA 1995 (Schwaber 1995)

Scrum and the Perfect Storm“.

Origenes Scrum

Scrum es un framework agile para gestión de trabajos complejos  tales como el Desarrollo de software

Scrum Framework

Roles x3

Product owner

ScrumMaster

Development team

Actividades x5

Sprint Sprint planning Product backlog

grooming Daily scrum Sprint

execution Sprint review Sprint

retrospective

Scrum Framework

Artefactos x3

•Product backlog•Sprint backlog•Potentially shippable product increment

Scrum Framework

Equipo Scrum

Equipos Pequeños  < 7 Auto Organizado y autoadministrado Encargado de hacer la estimación de historias de

usuario o ítems del backlog Interdisciplinario(architect, programmer, tester,

database administrator, UI designer) Facultado para convertir ítems del backlog en

tareas en las cuales se van a trabajar. Seguimiento del progreso del proyecto Responsable de mostrar los resultados del Sprint

para el product owner y los stakeholders al final de cada sprint.

El Equipo Scrum

Drucker ExcersiseIntegración de Equipo

What Am I Good At

How do I perform?

What do I value?

What contribution can be expected from me on this project

Habilidades Técnicas

TÉCNICAS UTILES QUE EL PROGRAMADOR AGILE DEBE TENER

¿Qué es la programación por intención? Es una técnica central utilizada en

Programación eXtema (XP), donde se trata de comunicar de manera clara que es lo que se tenía en mente cuando escribíamos el código, dicho de otra manera, la intención con la cual se escribió el código.

TDD y Programación por Intención

Cuando hacemos Test Driven Development, y programamos la prueba antes de tener el código real, hacemos la suposición del método ideal que necesitamos, imaginamos los parámetros deberá tener y que valor deberá regresar, consideramos que nombre tendría más sentido para dicho método y pensamos en qué es lo que debe hacer, antes de pensar en el cómo

Prueba Primero (TDD) y Suposiciones

Dentro del ciclo de TDD una etapa fundamental que nos ayuda a hacer más claro y legible nuestro código es la etapa del refactor, en la cual contamos con las siguientes opciones para lograr dicho fin:

Renombrar métodos o variables para que tengan más sentido en el contexto de la clase

Extraer  y generar métodos a partir de un código en un método extenso.

Extraer y generar clases a partir de código en un método extenso, en caso de considerarse que el comportamiento del código está fuera del contexto de la clase donde está definido.

Refactor

Product backlog

El uso de Scrum, siempre hacemos el trabajo más valioso primero.

El product owner, con el aporte del resto del equipo Scrum y los Stakeholders, es responsable de determinar y gestionar la secuencia de este trabajo y comunicarla en forma de una lista de prioridades (u ordenada),

Aprovechamos la conversación como una herramienta clave

La comunicación verbal tiene la ventaja de ser de alto ancho de banda y proporcionar una respuesta rápida,

Los ítems del product backlog(PBI) son características necesarias para cumplir con la misión del product owner.

A lo largo del proyecto el product backlog puede contener nuevas características, cambios en las características, defectos que debe arreglarse, mejoras técnicas, etc.

Se ponen en la secuencia correcta (usando factores tales como el valor, el costo, el conocimiento, y el riesgo) dando prioridad a los ítems de alto valor en el backlog

El product backlog es un artefacto en constante evolución.

En Scrum, los detalles de un requisito se negocian a través de conversaciones que suceden de forma continua durante el desarrollo y detalles se desglosan justo a tiempo y sólo lo suficiente para que los equipos comiencen a construir la funcionalidad para cumplir ese requisito.

Product Backlog Items (PBI)

Grooming En general, la

actividad de crear y refinación ítems del product backlog, la estimación, y la priorización de estos, se conoce como grooming

Tamaño

Antes de que finalicemos de priorizar, ordenar, u organizar el product backlog, tenemos que conocer el tamaño de cada elemento del product backlog

Tamaño equivale a los costos, y es necesario saber el costo para determinar su prioridad.

Una medida de tamaño relativo expresa el tamaño total de un elemento en una forma tal que el valor absoluto no se considera, pero el tamaño relativo de un elemento en comparación con otros artículos se considera

Ej. característica C es de tamaño 2 y característica E es de tamaño 8. Lo que podemos concluir es que la función E es aproximadamente cuatro veces más grande que la característica C.

Medida Relativa

Scrum no especifica ningún formato estándar para PBI User Stories son un formato conveniente para expresar

el valor de negocio deseado para muchos tipos de PBI, especialmente características.

Las Historias de los usuarios se elaboran de manera tal que sean comprensibles para las personas de negocios y técnicos.

Son estructuralmente simple y proporcionan un gran marcador de posición para una conversación.

Pueden ser escritos en varios niveles de granularidad y son fáciles de refinar progresivamente.

Las 3 Cs: Card, Conversation, Confirmation (Jeffries 2001).

User Stories (Historias de usuario)

Originalmente se escribían las User stories en tarjetas de: 3 x 5 pulgadas Un formato de plantilla

común para la escritura de historias de usuario(Cohn2004):◦ Especificar una clase de

usuarios (el rol de usuario)

◦ Lo que esa clase de usuario quiere lograr (la meta)

◦ ¿Por qué los usuarios quieren lograr el objetivo? (el beneficio)

Card

Los detalles de un requisito se exponen y comunican en una conversación entre el equipo de desarrollo, product owner, y las partes interesadas(stakeholders).

Puede haber una conversación inicial, cuando la historia de usuario se escribe, otra conversación cuando es refinado, aún otra cuando se estima, otra durante la planificación del sprint (cuando el equipo se sumerge en los detalles a nivel de tareas), y por último, las conversaciones en curso, mientras que el historia de usuario está siendo diseñados, construidas y probadas durante el sprint.

Aunque las conversaciones son en gran parte verbal, con frecuencia se complementan con documentos.

Conversación

Una historia de usuario también contiene información de confirmación en forma de condiciones de satisfacción.

Estos son los criterios de aceptación que aclaran el comportamiento deseado.

Son utilizados por el equipo de desarrollo para comprender mejor lo que se va a construir y probar y por el product owner para confirmar que la historia de usuario se ha implementado hasta su satisfacción.

Estas condiciones se pueden escribir al reverso de la tarjeta

Estas condiciones de satisfacción se pueden expresar como pruebas de aceptación de alto nivel.

Confirmación

Independent, Negotiable, Valuable, Estimatable, Small Testable

(Bill Wake 2003) Cuando se combina la información derivada

de aplicar cada uno de estos criterios, se obtiene una imagen clara de lo que algún cambio adicional podríamos hacer a la historia.

INVEST del Product Backlog

Las historias de usuario deben ser independientes o al menos sólo débilmente acoplados entre sí

Historias que muestran un alto grado de interdependencia complican la estimación, priorizando, y planificación.

Al aplicar el criterio de independencia, el objetivo no es eliminar todas las dependencias, sino escribir las historias de una manera que minimice las dependencias

Independent / Independiente

Las buenas historias captan claramente la esencia de la funcionalidad del negocio que se desea y por qué se desea. Sin embargo, dejan espacio para que el Product Owner, los stakeholders, y el equipo negocien los detalles.

Las historias deben ser acerca del ¿qué? y ¿por qué?, no del ¿cómo?

Historias negociables son agradables porque nos dan el margen de maniobra que a veces necesitamos para trabajar dentro de nuestros presupuestos.

Escribir historias negociables deja claro que el diálogo es necesario.

Un ejemplo común de donde se viola la negociabilidad es cuando el product owner le indica al equipo cómo implementar una historia

Negotiable / Negociable

Historias necesitan ser valiosas para un cliente, usuario, o ambos.

Está bien tener historias técnicos, siempre y cuando el product owner debe de entender por qué aporta valor esa historia

En la práctica, sin embargo, la mayoría de las historias técnicas no deben ser incluidas en el product backlog

En cambio, este tipo de historias deben ser tareas asociadas a satisfacer historias valiosas de negocio.

La clave de los criterios de valor es que todas las historias del backlog deben ser valiosa (valen la pena invertir en ellas) desde el punto de vista del product owner (vista de usuario y clientes)

No todas las historias son independientes, y no todas las historias son totalmente negociable, pero todos deben ser valiosas

Valuable /Valioso

Las historias deben ser estimables por el equipo que las va a diseñar, construir y probar.

Las estimaciones proporcionan una indicación del tamaño y, por tanto, el esfuerzo y el costo (PRIORIDAD)

El equipo Scrum, por otra parte, puede determinar a partir del tamaño de la historia si se requiere refinamiento o desagregación adicional.

Si el equipo no es capaz de dimensionar una historia, la historia es o demasiado grande o ambiguas para ser clasificada, o el equipo no tiene los conocimientos suficientes para estimar un tamaño.◦ Si es demasiado grande, el equipo tendrá que trabajar con el

product owner para dividirla en historias más manejables◦ Si el equipo no tiene el conocimiento, será necesario algún tipo de

actividad exploratoria para adquirir la información

Estimatable /Estimable

Las historias deben ser del tamaño adecuado para cuando tenemos la intención de trabajar en ellas.

Historias trabajadas en sprints deben ser pequeñas.

Debe tener en cuenta cuando la historia se trabajará cuando se aplica este criterio.

Small (Sized Appropriately) / Pequeña (Tamaño Apropiado)

Una historia sólo debe considerarse finalizada (hecha) , entre otras cosas, si se puso a prueba con éxito.

Si uno no puede probar una historia debido a la falta de información, la historia no debe ser considerada como buena candidata para ser parte del backlog

Las historias deben ser comprobable en una manera binaria ya sea que se apruebe o no.

Debido a que estas pruebas con frecuencia proporcionan importantes detalles de la historia, pueden ser necesarias antes de que el equipo incluso pueda estimar la historia.

No siempre puede ser necesario o posible probar una historia (Ej. Historias epicas)

Testable / Comprobable

Project Inception

Involucrar a los usuarios como parte del equipo que está determinando qué construir y está constantemente revisando lo que se está construyendo

La recopilación de historias

El objetivo del taller es generar una lluvia de ideas en conjunto alrededor de los valores de negocio que desee y crear marcadores de posición de la historia de usuario para lo que se supone que el producto o servicio debe hacer.◦ No se genera un conjunto completo de historias de usuario

desde un inicio.◦ El taller tiene un enfoque específico. Ej. Analizar los roles de

usuario o definición de personas El taller incluye frecuentemente al Product Owner,

ScrumMaster y el equipo de desarrollo, en colaboración con los stakeholders internos y externos.

Top- Down o Down- Top

Talleres de redacción de historias de usuarios.

Story mapping es una técnica popularizada por Jeff Patton (Patton 2009) Toma una perpectiva centrada en el usuario para generar el conjunto de historias.

La idea básica consiste en descomponer las actividades de usuarios de alto nivel en un flujo de trabajo que se puede descomponer aún más en un conjunto de tareas detalladas

Patton utiliza términos como actividad, tarea, y subtarea para describir la jerarquía dentro de un mapa de historias.◦ Epic -> Theme -> Sprintable story = Activity -> Task -> Subtask

Epic: Representan las actividades más grandes que aportan valor medible al usuario.

Mapeo historia combina los conceptos de diseño centrado en el usuario con descomposición de historias

Muestran un flujo de actividades, desde la perspectiva del usuario y proporcionan un contexto para entender las historias individuales y su relación con las unidades más grandes de valor para el cliente.

Mapeo de Historias

Seleccionar una historia épica Siguiente pensamos en la secuencia o flujo de

trabajo común de las tareas del usuario que conforman la épica(representado por temas-colecciones de historias relacionadas)

Exponemos los temas a lo largo de una línea de tiempo.

Cada tema se descompone entonces en un conjunto de historias implementables que están acomodadas verticalmente en orden de prioridad

Descripción :Story Mapping

Es una colección de diez preguntas difíciles y ejercicios creado originalmente por Robin Gibbons

Lo usamos para cubrir el área de iniciación del proyecto en métodos ágiles

Si podemos conseguir a la gente adecuada en la habitación y preguntarles las preguntas correctas, esto va a hacer maravillas para establecer colectivamente las expectativas acerca de nuestro proyecto.

Al poner el equipo a través de una serie de ejercicios y capturar la salida en un conjunto de diapositivas (generalmente PowerPoint), podemos conseguir colectivamente una idea bastante clara de lo que este proyecto es, lo que no es, y lo que va a tomar para entregar.

Inception Deck

Cualquier persona directamente involucrada en el proyecto◦clientes, stakeholder, los miembros del

equipo, desarrolladores, testers, analistas

Las personas adecuadas:

Descripción del Inception Deck: Por qué estamos aquí. Crear un discurso de

ascensor. Diseñar la caja del

producto. Cree una lista de NOs. Conocer a los vecinos Mostrar la solución. Preguntar lo que nos quita

el sueño. Asignarle un tamaño Ser claro sobre lo que va a

obtener Mostrar lo que va a

necesitar