Curso de Scrum

Metodología ágil

Es la habilidad de crear productos y responder al cambio, ya sea por el cliente o por los cambios del mercado. Son muchos marcos de trabajos y metodologías. Actualmente estamos viendo el marco Scrum.

Está centrado en las personas. No solo en el cliente sino en cada uno de los desarrolladores.

Es una forma de mejorar el desarrollo de software y tomar experiencias para mejorar los productos.

La diferencia entre el desarrollo tradicional y el desarrollo ágil es el tamaño del equipo, teniendo fracciones de equipos con objetivos claros e iteraciones. Otra diferencia son los requerimientos trabajando en base a eso, fraccionando la lista de requerimientos. La generación de valor es otra gran diferencia, en lugar de trabajar todas las tareas, es mejor hacerlo de forma fraccionada e ir mostrando los cambios para que el cliente vea. De esta forma el cliente puede hacer correcciones y no será complicado para los desarrolladores.

Principios

Se valora a individuos e interacciones, esto será más valorado que cualquier proceso o herramientas. El cliente debe ver el software funcionando, que valora más que cualquier manual o documentación. Es muy importante tener colaboración con el cliente, no estar en contra de el en cualquier punto. La respuesta ante al cambio sobre seguir un plan nos ayuda a reaccionar a los cambios en el proyecto para poder implementar.

  1. Satisfacción al cliente: entregar cambios constantemente al cliente para que vea e ir agregando valor.

  2. Cambios: son aceptas en cualquier momento del desarrollo, tenemos que adaptarnos al entorno.

  3. Software funcional: si entregamos software funcional a tiempo, el cliente estará satisfecho.

  4. Colaboración: con el cliente y con el equipo.

  5. Individuos motivados: dejar que el equipo tome sus decisiones para que estén cómodo en el desarrollo.

  6. Comunicación cara a cara: favorece hablar con el cliente cara a cara, y leer su lenguaje corporal, no por mensajes.

  7. Progreso: el software funcional es la principal medida de progreso. Escribir mucho código no es avance, ver algo funcionando sí.

  8. Desarrollo sostenible: el equipo debe entregar la misma cantidad de producto durante las iteraciones

  9. Mejora continua: el equipo tendrá tiempo de aprender que hizo bien o mal, e ir mejorando por cada iteración del proyecto.

  10. Simplicidad: maximizar el trabajo no realizado es esencial, únicamente vamos a trabajar en las cosas que están bien definidas.

  11. Autoorganización: el equipo debe decidir por sí mismo.

  12. Autoevaluación: el equipo debe poder autoevaluarse para perfeccionar su comportamiento.

Introducción a Scrum

Es un momento donde todo el equipo colabora por un objetivo. Es un marco de trabajo para abordar problemas complejos o sencillos. Se enfoca de entregar productos con el máximo valor posible y creativamente.

Es un equipo pequeño de personas, son individualmente flexibles y adaptativos. Tienen que ser pequeños para que sean altamente flexible.

Teoría

Se basa en el control de procesos basados en empirismo. El conocimiento procede de experiencias y de tomar decisiones en base a lo que conocemos.

  1. Transparencia: debe haber comunicación con el cliente y el equipo. Cualquier persona involucrada debe saber el estado actual del proyecto. No debemos temer a decir que estamos trabados en algo.

  2. Inspección: cualquier persona podrá ver los requerimientos y ver si están bien definidos o no.

  3. Adaptación: capacidad del equipo de reconocer los cambios y poder implementar lo antes posible.

Valores de scrum

  1. Compromiso: el equipo de comprometerá 100%.

  2. Coraje: cualquier miembro del equipo tendrá el coraje de hacer cualquier tarea, sepa o no hacer la tarea. Aprenderá para cumplirla en la iteración.

  3. Enfoque: cada uno debe estar enfocado en cumplir los objetivos.

  4. Apertura: estar abiertos a escuchar a cualquier persona relacionada con el proyecto.

  5. Respeto: todos somos partes del mismo equipo, por lo tanto, debemos respetarnos. No podemos intentar cambiar la solución de alguien si funciona, esto es una falta de respeto.

Componentes

Equipo Scrum

Es auto organizado y multifuncional. Puede organizarme para cumplir las tareas y poder solucionar cualquier problema.

  • Product Owner: responsable de maximizar el valor del product.

  • Scrum Master: responsable de promover y apoyar scrum.

  • Equipo de desarrollo: profesionales que se dedican a completar el producto.

Eventos

Existen eventos definidos para regularidad y minimizar la necesidad de reuniones no definidas. El equipo va mejorando con el proceso y mejorando la calidad del producto deseado.

  • Sprint: son las iteraciones con un determinado tiempo donde el equipo entrega partes del producto y se crea un incremento de calidad.

  • Sprint planning: definir que se hará en el sprint.

  • Scrum diario o daily stand-up: el equipo se reúne y hablan sobre cómo va el proceso.

  • Sprint review: se muestra lo que trabajamos durante el sprint.

  • Sprint retrospective: el equipo analiza que hizo bien y en que debe mejorar.

Artefactos de Scrum

Representa en el trabajo y el valor del mismo. Todos tienen acceso a estos para su revisión.

  • Product backlog: una lista detallada de lo que se conoce que es necesario para el proyecto.

  • Sprint backlog: un pequeño conjunto de elementos del producto backlog que se va a trabajar en ese sprint.

Equipo de Scrum

Vamos a tener un equipo con varios roles.

  • Product owner: el encargado de establecer relación con el cliente para conocer el producto.

  • Scrum master: encargado de que las reglas se cumplan.

  • Equipo de desarrollo: el equipo que crea la aplicación o el proyecto.

Este equipo está diseñado para que sea flexible y avancen al mismo tiempo.

El producto puede ser entregada por parte, esto es una entrega incremental. Debe ir mejorando cada vez, pero debe entregarse ese valor de producto al cliente. La idea de esto es maximizar las oportunidades de tener un feedback del cliente.

Las dependencias externas deben evitarse a toda costa. El equipo debe contener todas las personas necesarias para terminar el trabajo.

Pueden organizarse en base a las funcionalidades de los componentes.

Product Owner

Es el responsable de maximizar el valor del producto. Es el responsable de gestionar la lista del producto. Si el cliente no está, el debe transmitir exactamente qué es lo que el cliente desea.

Responsabilidades:

  • Expresar claramente qué es lo que el cliente quiere. Es responsabilidad de el bajar la cantidad de dudas.

  • Es responsable de la prioridad de los items de la lista del producto.

  • Optimiza el valor del trabajo del equipo del desarrollo.

  • Se asegura de que la lista del producto sea transparence y clara. Debe dar información en tiempo real al cliente.

  • Debe asegurarse de que el equipo sepa la lista de requerimientos.

El decide en qué se va a trabajar. Su decisión se debe respetar ya que es la única persona autorizada para modificar la lista del producto.

Nadie puede forzar al equipo a trabajar en tareas que no estén priorizadas en la lista del producto.

Scrum Master

Es el encargado de ayudar a que el equipo mejora, es el primero en promover el marco scrum. Ayuda a todos a entender en qué momento es el indicado para interactuar con el equipo y en qué momento no.

Va a estar al servicio de la gente, esté fuera o dentro del equipo.

Ayuda al product owner de la siguiente forma:

  • Se asegura que todos los miembros del equipo entiendan en qué se va a trabajar.

  • Entienda y practique la agilidad.

  • Facilita los eventos de Scrum según se requiera o necesite.

Ayuda al equipo de desarrollo de la siguiente forma:

  • Guía al equipo a ser auto organizado y multi funcional.

  • Ayuda al equipo a crear un producto de alto valor.

  • Elimina los impedimentos para el progreso del Equipo de Desarrollo.

Ayuda a toda la organización de la siguiente forma:

  • Guía a la organización a usar Scrum o a entender que el equipo de desarrollo usa Scrum

  • Trabaja con otros Scrum master para incrementar la efectividad de la aplicación del marco en toda la organización.

Equipo de desarrollo.

Consiste en profesionales que realizan trabajos para incrementar el valor del producto que se desea terminar. El producto terminado es la actividad que se realizó en el sprint, el cliente podrá tener una idea de su producto final.

La organización debe darle la confianza y empoderamiento a que el equipo tome sus decisiones.

Características:

  • Auto organizados: deciden quién va a hacer cada cosa.

  • Multi funcional: no solo tenemos a programadores, Podemos tener diseñadores y QA, entre otros.

  • No tienen títulos: que alguien tenga más experiencia no lo hace jefe del equipo de desarrollo. Todos van a ser responsables de la misma forma.

  • No hay sub equipos: todos son un solo equipo y trabajan al mismo ritmo.

  • No se puede modificar el equipo hasta que haya terminado el sprint.

Debe ser lo suficientemente pequeño para que sea ágil pero lo suficientemente grande como para poder entregar el producto. Pueden ser entre 3 a 9 personas. No incluyen al scrum master ni al product owner, a menos que puedan cumplir con tareas del equipo.

Las épicas y el Backlog del producto

Es una lista ordenada de todos los requisitos del proyecto. Todo lo que el cliente quiere que se le haga al producto debe estar en esa lista.

La lista del producto nunca va a estar completa. Esto no quiere decir que el cliente no sepa lo que quiere, pero puede ir agregándose nuevo requerimientos. Los elementos de la lista más prioritarios deben tener una descripción completa.

A lo largo del desarrollo la lista puede cambiar, es un artefacto vivo. En ella están todos los elemento necesarios para completar el producto.

historias de usuario

Los elementos se llaman historias de usuario. Son suficientemente modulares y pequeños que describen el uso del producto.

Épicas

Las épicas están conformada por varias historias o módulos del producto. Puede tomarse varios sprint en completarse.

Pueden ser módulos como: Módulo de autenticación, módulo de creación de elementos, entre otros. Y en ellos estará un conjunto de historias.

¿Qué nos cuentan las historias de usuario?

Son los elementos más específicos del producto, es lo que el usuario nos está contando, lo que quiere de nuestro producto. No necesariamente tiene que ser una persona, puede ser una parte del sistema.

Componentes

  1. Título

  2. Descripción

  3. Puntos

  4. Criterio de aceptación

Descripción:

Como (rol) quiero (acción) para (beneficio).

Ejemplo: Como estudiante quiero poder completar evaluaciones en la plataforma para poder ser evaluado y tener calificación.

Para que una historia esté completa debe tener las funcionalidades, que son los criterios de aceptación. El código debe estar subido a github, etc. Debe tener las pruebas necesarias y también documentación. Pueden ser más o menos.

Hay que invertir tiempo, podemos aplicar las tres C.

  • Cards: donde escribimos las historias

  • Conversación: hablar con el cliente

  • Confirmación: asegurarse de que todos lleguen a un acuerdo

Debe ser independiente.

Debe ser negociable, se puede cambiar.

Debe ser valiosa para el cliente.

Debe ser estimable.

Debe ser pequeña.

Debe ser testeable, a través de los criterios de aceptación o a travez de listo.

Estimar las historias

Los puntos de una historia son números que representan varias cosas:

  • Complejidad de la historia

  • Cantidad de trabajo requerido

  • Conocimientos necesarios

  • Incertidumbre

Los puntos no son horas, líneas o cantidad de commits por hacer, no es una unidad de medición específica.

Puede ser representado por cualquier tipo de escala, por ejemplo, fibonacci modificado: 1, 2, 3, 5, 8, 13, 20, 40, 100, infinite, ?.

Es así para evitar ser exactos en el número, ya que podremos redondear la complejidad al número más cercano.

Esto nos da un total de puntos por las historias, y podremos calcular por los puntos que el equipo puede completar.

La velocidad es el total de puntos que el equipo puede completar en un sprint, y la capacidad es la cantidad de historias de usuario que el equipo puede completar en base a su experiencia.

Lista de pendientes

Deben ser flexibles, se pueden quitar historias que no sean tan importantes para meter otras que sean de alta prioridad, el equipo debe aceptar esto.

El equipo de desarrollo decide las prioridades del sprint.

Para definir las prioridades se debe pensar en la urgencia y en la importancia de ese feature para el cliente.

El riesgo o la oportunidad también puede definir la importancia. Si no se hace una y puede atrasar otras historias, entonces debe ser prioridad. Si esa historia se hace y permite avanzar en otras historias, entonces debe ser prioridad también.

También se debe medir el esfuerzo para completar esa historia para definir su importancia.

Midiendo el avance

Puede ser día a día, y es para ver si el equipo puede cumplir con el sprint.

Estas mediciones se pueden hacer en excel en base a los puntos de las historias.

Ritmo del Sprint

Es un periodo de tiempo fijo. Lo más utilizado son dos semanas.

El flujo es el siguiente: planeación, scrum diario, trabajo de desarrollo, revisión del sprint, la retrospectiva para mejorar.

Todos los sprint deben tener un objetivo claro. Cualquier cambio debe ser negociado entre el product owner y el equipo de desarrollo.

El sprint puede ser cancelado, y puede ser cancelado por el product owner.

Es muy poco común que esto pase.

Planeación

Se define qué elemento del producto se va a realizar. Debe estar presente todo el equipo de scrum.

No debe durar más de 8 horas para sprint de cuatro semanas. Normalmente dura 2 horas para dos semanas.

El scrum master se encarga de organizar esta ceremonia, debe ser un salón suficientemente amplio para que el equipo pueda trabajar cómodo.

Nadie puede distraerse en este momento, ya que es muy importante.

¿Qué puede entregrarse al final del sprint? Se toman los elementos más prioritarios de la lista del producto y se mueve al backlog del sprint. En base a esa lista se decine los objetivos del sprint, puede tener uno o dos objetivos, pero es recomendable que sea uno solo.

Se necesita saber la capacidad del equipo y la velocidad que tuvieron en el sprint aterior.

¿Cómo se logrará? Se mueven los elementos de la lista del producto al backlog, y aquí se hace la planeación y el esfuerzo que debe dedicarse a cumplir.

El product owner debe encargarse de resolver cualquier duda. Puede haber invitados en esto.

Resumen: tomar los elementos, estimar el tiempo, calcular el total de puntos con la capacidad del equipo y trazar objetivos claros.

Daily standup

Es una reunión diaria del equipo de desarrollo. Debe ser en pié y se habla sobre lo que se va a hacer en las próximas 24 horas. Otras personas pueden estar presente pero no puede hablar en la reunión.

Esto optimiza la colaboración etre el equipo y puede comentar en las reuniones próximas en detalles más profundos.

Hay que hacerse tres preguntas: ¿Qué hice ayer para cumplir con el objetivo? ¿Qué hice hoy? ¿Tengo algún impedimento?

Si existe un impedimento, el scrum master se encarga en resolver este impedimento que generalmente tiene que ver con personas externas. Se pueden organizar reuniones entre miembros del equipo para resolver detalles.

Refinar historias

Para poder ver en qué se va a trabajar el próximo sprint, debe refinarse las historias. Deben tener toda la claridad necesaria para poder ser trabajas desde el primer día del sprint.

Se recomienda que sea a mitad del sprint el día qeu se van a refinar las historias. Puedes participar todos, pero no es necesario que participe todo el equipo del desarrollo.

El objetivo de esta sesión puede ser completar la descripción, crear el criterio de aceptación, crear marcos de pruebas y también si hay un tipo de dependencia.

Demos y retrospectiva

El sprint review sucede en el último día y se muestra al cliente todo lo que hemos hecho. Puede ser varias reuniones a lo largo del sprint para mostrar funcionalidades pero no es necesario, puede ser todo al final del sprint.

En esta ceremonia se interactúa con el cliente. Es un timo de retroalimentación. En esta reunión de habla de las historias que no se lograron terminar, y se debe ser totalmente transparente con el cliente. Es una reunión un tanto informal, abierta al diálogo y al feedback, no es una reunión de seguimiento. Esto podría afectar en el ánimo del equipo.

No debe durar más de 4 horas para un sprint de un mes pero esto dependerá de la cantidad de cosas que se tienen que presentar. Al final de la revisión, se tendrá una lista del producto actualizada.

Debemos mostrar el software directamente en lugar de una presentación.

Luego viene la retrospectiva, debe suceder en un ambiente cómodo donde el equipo pueda hablar y decir lo que siente y piensa de todo el trabajo. Es una oportunidad de mejora, esto es solo para el equipo de scrum. No se permite personas ajenas al equipo. Esta retrospectiva debe ser positiva, no se puede culpar ni regañar, es para hacer sentir bien a todos los miembros.

No debe durar más de 3 horas para un sprint de un mes, para un sprint de una semana puede durar entre 15 min a una hora, el scrum master se encargará de esto. Participarán todos y deben estar presentes.

Se hablará sobre herramientas, relaciones, personas y proceso.

Se debe responser las siguientes preguntas: ¿qué hicimos bien? ¿Qué no hicimos tan bien? ¿Qué podemos mejorar?

En base a estas respuestas se sacan cuales son las más importantes y se aplica un plan de acción para solucionar los problemas y mejorar el rendimiento.

Escabilidad de equipos

La forma en que se organiza scrum nos permitirá hacer funcionar un equipo con muchas personas.

Se puede dividir en equipos de scrum, y pertenecerán a scrum de scrums, que es un equipo virtual que nos ayudará a coordinar los elementos de trabajo entre todos los equipos.

Los scrum of scrums se coordinan a travez de esta reunión, solo participan algunas personas de cada equipo, y la idea es que todos los involucrados en el proyecto participen. Debe haber al menos un encargado de cada equipo, que puede ser cualquier, desde un programador hasta el product owner.

Comunidades de práctica

Son grupos de personas que comparten una pasión por algo que hacen, e intentan hacerlo lo mejor posible a medida que van interactuando.

Si conoces a alguien que haga lo mismo que tú haces, entre los dos pueden ayudarse para mejorar en lo mismo.

Tiene varios elementos:

  • Lo que nos gusta

  • La práctica: cómo lo compartimos y practicamos

  • A quién más le interesa: pueden haber más programadores o personas que quieran aprender del tema

La comunidad se puede dividir en roles: programadores, diseñadores, producto owner, entre otros.

También se puede hacer basado en tópicos: programación, ui ux, diseño.

Cada equipo tiene programadores, diseñadores, entre otros. Y entre ellos pueden compartir sus mejores prácticas para poder seguir mejorano.

Última actualización