ALLSOFT - Blog Allsoft #Scrum

Propósito de la Reunión Diaria (daily scrum)

Thu, 04 Jul 2024 11:34:00 -0600

La reunión diaria de Scrum no es solo una reunión para dar el estado de las cosas hacia la gerencia, es algo más que eso, es para ponernos de acuerdo, ver que todos estamos en el mismo canal, interesarnos en lo que los demás están haciendo, ver que rumbo tomamos.

Es importante recordar que debemos trabajar como un equipo. Para que la reunión sea efectiva, debe ser breve, por eso se realiza de pie. No debemos centrarnos en una sola persona para mostrar nuestro trabajo; nuestros comentarios son para todo el equipo. Esto puede ser difícil, ya que la tendencia ha sido siempre "reportar" a alguien y que "alguien" nos diga lo que debemos hacer. Este es un punto crucial que debemos superar para empezar a funcionar como un equipo autoorganizado.

El propósito de la reunión diaria o "daily scrum" en Scrum es asegurar que el equipo esté alineado y trabajando de manera coordinada hacia el objetivo del sprint. Es una reunión breve, de no más de 15 minutos, que se realiza todos los días y en la cual cada miembro del equipo responde a tres preguntas clave:

1. ¿Qué hice ayer para ayudar al equipo a alcanzar el objetivo del sprint?
2. ¿Qué haré hoy para ayudar al equipo a alcanzar el objetivo del sprint?
3. ¿Hay algún impedimento que me impida avanzar?

Los objetivos principales del daily scrum son:

1. Facilitar la comunicación: Permitir que todos los miembros del equipo estén informados sobre el progreso de los demás y fomentar la colaboración.

2. Identificar y resolver obstáculos: Detectar rápidamente cualquier problema o impedimento que pueda estar bloqueando el progreso y buscar soluciones de manera proactiva.

3. Promover la transparencia y la responsabilidad: Mantener a todos responsables de sus compromisos diarios y asegurar que todos estén trabajando hacia el mismo objetivo.

4. Ajustar el plan de trabajo diario: Adaptar y ajustar las tareas diarias según las necesidades actuales del proyecto, garantizando que el equipo esté enfocado y alineado.

La daily scrum no es una reunión de status para los gerentes, sino una oportunidad para que el equipo de desarrollo se sincronice y se autoorganice.

Foto de Jason Goodman en Unsplash

¿Cómo garantizar que el equipo entregue la funcionalidad?

Fri, 24 Mar 2023 12:51:58 -0600

Lo que el usuario espera de su producto, está reflejado o plasmado en las historias de usuario definidas. ¿Cómo aseguramos que hemos entendido y estamos entregando lo que se espera?. Definiendo lo que debemos de tener como resultado esperado al implementar cada una de las historías de usuario a través de los criterios de aceptación de la historia.

Los criterios de aceptación son una lista de condiciones o requisitos que deben cumplirse para que se considere que una historia de usuario se ha completado correctamente. Estos criterios se utilizan para definir el alcance y los límites de una tarea, así como para asegurar que el trabajo realizado cumple con las expectativas y necesidades del cliente o usuario final.

Los criterios de aceptación se pueden incluir en una historia de usuario como parte de la descripción o se pueden separar en un documento aparte. Por lo general, estos criterios se definen durante la fase de planificación del proyecto, antes de que comience el trabajo de las tareas relacionadas con la historia de usuario..

Un par de ejemplos de criterios de aceptación para una historia de usuario podrían ser:

"El usuario debe ser capaz de agregar un artículo al carrito de compras y completar la compra con éxito, recibiendo un correo electrónico de confirmación de la transacción en un plazo máximo de 5 minutos."

"Al terminar el registro de la tarea el usuario deberá recibir un correo con la información de la tarea asignada y la tarea deberá de aparecer en el listado de tareas por completar."

En este ejemplo, se establece claramente lo que se espera que el usuario pueda hacer y se establece un plazo límite para que el sistema realice una acción específica. Estos criterios pueden ser revisados y ajustados a lo largo del proceso de desarrollo y pueden ser utilizados para realizar pruebas de calidad y asegurar que el trabajo realizado cumple con las expectativas del usuario final.

Es importante recalcar que los criterios de aceptación No son actividades adicionales a realizar, sino, cosas que deben de suceder resultado de la implementación de una historia de usuario determinada. Los criterios de aceptación deben ser específicos, medibles y verificables.

Cómo conclusión, los criterios de aceptación nos ayudarán a garantizar que el equipo de desarrollo está entregando lo que el usuario espera como solución.

SCRUM Demo

Mon, 05 Dec 2022 15:48:20 -0600

Dentro del marco de SCRUM al final de cada Sprint se entrega un incremento funcional, el cual puede ser entregado a producción. Para ello entendemos que el incremento ha sido desarrollado, probado, y se encuentra libre de errores. Antes de poder ser entregado, se lleva a cabo una Reunión de Revisión o Demostración del incremento para comprobar que lo planificado y acordado al inicio del Sprint, se ha realizado. Si bien, el dueño de producto no es ajeno a lo que ha estado haciendo el equipo (si ha participado como se debe), se requiere ver todo integrado y funcionando.

En esta reunión informal de revisión debe de participar todo el equipo, para que reciba retroalimentación de primera mano y no a través de terceros. También debe de participar el dueño del producto y personas interesadas en el producto. El dueño de producto puede invitar a las personas que él considere conveniente y que puedan aportar algo al producto o para que conozcan sobre el producto.

Hemos indicados que la reunión es informal en sentido que no hay que preparar nada, salvo tener la pila del Sprint como referencia y el incremento a ser revisado. Si será necesario planear como se irá mostrando el incremento, quien hará la demostración, quien hablará, etc, para no perder tiempo al momento de la revisión.

La reunión no debería de tener una duración de más de 2 horas (recomendación). El enfoque de la reunión deberá ser constructiva en donde las ideas y la retroalimentación fluyan. Hay que recordar que estamos construyendo un producto, no destruyendo. A través de la retroalimentación iremos adaptando el producto hacia su siguiente iteración.

Las mejores reuniones de Demo que hemos presenciado son aquellas en las que también está el público interesado, y se logra un ambiente de colaboración, retroalimentación y generación de ideas. No es una reunión de trámite, es una reunión para celebrar y motivar al equipo por el trabajo que ha estado realizando.

Escalar SCRUM con NEXUS

Sat, 12 Feb 2022 08:34:56 -0600

Es posible, que en ocasiones, en nuestro portafolio esté un proyecto muy grande que no será posible atenderlo con un solo equipo. Para ello tendremos que recurrir a que varios equipos atiendan el proyecto, sin embargo, si estamos trabajando con SCRUM tendremos que sincronizar a todos los equipos. Para lograr sincronizar a todos los equipos tenemos que escalar las prácticas de SCRUM. Actualmente existen varias guías o frameworks para escalar SCRUM, uno de ellos es NEXUS.

Lo que nos ofrece NEXUS es trabajar con las prácticas de SCRUM sin necesidad de agregar más prácticas o productos a las que ya utilizamos. Es un framework que a través de roles, eventos y técnicas busca vincular el trabajo de los equipos en una sola Pila de Producto que genere un incremento integrado.

Como bien sabemos, una de las fortalezas de SCRUM es la adaptación, por lo que la sincronización entre los equipos se vuelve crucial. A través de identificar y resolver las dependencias entre requisitos, dominio del conocimiento y artefactos reduce los riesgos de que los equipos estén por diferentes caminos. Para lograrlo NEXUS incorpora un equipo de integración que asegure la correcta aplicación de las prácticas y herramientas, así como la integración. Un SCRUM Master que garantice el framework de NEXUS. Un Dueño de Producto que vea por la integración y valor del producto.

NEXUS utiliza una única Pila de Producto coordinada por el Dueño de Producto y cada equipo tiene un Backlog del Sprint de NEXUS. Para que los equipos estén enfocados y tengan visibilidad se define una Meta de NEXUS.Durante la ejecución de NEXUS se realizan actividades como Planeación, Diaria de NEXUS, Revisión de Sprint de NEXUS, Retrospectiva de NEXUS, en donde el equipo de integración trabaja para coordinarse definiendo la Meta de NEXUS y compartiéndola con los equipos. La diaria y la revisión del Sprint la realiza el equipo de integración y la baja a cada equipo.

Como mencionamos en un inicio, si ocupamos varios equipos para desarrollar un proyecto NEXUS es una opción para coordinar el esfuerzo. A través de una Pila de Producto única, con la identificación y resolución de dependencias, y el equipo de integración trabajando para lograr un incremento integrado siguiendo un flujo de trabajo y participación para lograrlo.

6 Responsabilidades del Dueño de Producto

Tue, 25 Jan 2022 14:47:12 -0600

Para mejorar las posibilidades de éxito del proyecto cada uno de los participantes debe de tener claro su participación y lo que se espera de él. El rol de Dueño de Producto es fundamental en la agilidad porqué marcará la pauta del desarrollo del producto. Es por ello que debe de tener claro lo que se espera de él y de sus responsabilidades hacia el proyecto y hacia el equipo.

Aquí te dejamos algunas de las responsabilidades de un Dueño de Producto.

1. Definir la visión

El Dueño de Producto es una persona clave en el equipo que tiene el conocimiento del producto para definir los objetivos y la visión para el proyecto. El Dueño debe de comunicar a todas las partes involucradas dichos objetivos y la visión para asegurarse que estén alineados a los objetivos del negocio.

Uno de los propósitos de la visión es mantener al equipo motivado y enfocado ante un proceso de desarrollo que es flexible y a veces incierto.

¿Su equipo tiene definida una visión?, ¿Su equipo conoce la visión?, ¿Durante la ejecución del proyecto validan las necesidades contra la visión del producto?

2. Gestionar la pila de Producto

Una de las responsabilidades más importantes es generar y mantener la pila de producto, que es la fuente de trabajo para el equipo durante los Sprints. La pila de producto debe ser conocida por el equipo e interesados para conocer el rumbo que toma el producto y contiene las necesidades de los clientes del dueño de producto.

Es responsabilidad del dueño de producto mantener esta lista de producto actualizada, priorizada y con el suficiente detalle para organizar el trabajo del desarrollo del producto. La actualización implica, tanto como poner nuevos elementos en la pila, como eliminar aquellos elementos que ya no aplican al producto.

3. Priorizar la pila de Producto

El dueño de producto marca la pauta del desarrollo a través de la organización de los elementos de la pila de producto a través de establecer prioridades en la misma. Los elementos de más prioridad en la pila solo los de más valor para el negocio.

4. Planificar el trabajo

El dueño de producto de acuerdo con sus necesidades y prioridades debe de planificar el trabajo para el Sprint en conjunto con el equipo tomando en cuenta sus capacidades. La planificación implica clarificar el trabajo y negociar con el equipo el trabajo a realizar.

5. Supervisar la evolución del producto

Durante todo el proyecto el dueño de producto debe ser muy participativo para supervisar, y colaborar en el desarrollo del producto atendiendo las necesidades de información del equipo. Recordemos que las historias de usuario son una conversación mas que una especificación, por lo que el aporte del dueño de producto durante el desarrollo es esencial.

6. Evaluar el progreso

En forma periódica debe de evaluar el progreso del equipo en cuanto a los avances del producto y tomar decisiones sobre que partes son aceptadas y cuales no. Retroalimentar al equipo en el trabajo realizado y replantear el producto para las siguientes iteraciones

Evaluación SCRUM - SCRUM Level

Mon, 07 Nov 2016 07:32:40 -0600

En un intento por mejorar la forma de hacer software, o de mitigar los viejos problemas asociados a esta actividad, las organizaciones y proyectos han implementado SCRUM como su forma de trabajo, pero al igual que otras metodologías, modelos o marcos de trabajo no siempre ha resultado como se esperaba.

Las situaciones que se dan igual varían, pero podemos resumir algunas en la falta de conocimiento, micro managment, presiones externas, viejas prácticas, política, entre otras, así como hacer todo bajo SCRUM cuando no necesariamente es lo más conveniente. Incluso estar haciendo un proyecto con SCRUM en una organización que no es ágil.

Así tenemos que entre los que están haciendo SCRUM, y los que dicen que están haciendo SCRUM, existe la necesidad de identificar que tan bien lo estamos haciendo, o como lo estamos haciendo, para poder obtener lo mejor de este marco de trabajo. Para ello podemos realizar una evaluación formal con SCRUM Level y conocer el grado de agilidad de nuestros proyectos, de nuestra organización, y de las personas involucradas en estos proyectos. A través de los resultados podremos tomar acciones para lograr mejores resultados.

SCRUM Level evalúa la agilidad en dos dimensiones:

Flexibilidad: evalúa la parte técnica determinada por las técnicas y prácticas de trabajo
Agilidad: Dimensión organizativa que ve por los rasgos de personalidad de la organización.

De esta forma podemos ver como los equipos de trabajo se organizan y como la organización soporta a estos equipos de trabajo. Con ello podemos identificar situaciones en las que el equipo conoce las prácticas, pero la organización no apoya al equipo como, por ejemplo, que cuente con un dueño de producto disponible y participativo. El balance entre las 2 dimensiones no sería el adecuando por lo que habría que hacer ajustes para obtener mejores resultados.

¿Qué tan ágil eres? - Participación del cliente

Sat, 20 Jun 2015 18:03:42 -0500

Como les decimos a nuestros clientes, la base de la agilidad es la participación del usuario en el equipo, y debe ser una participación activa. Nuestro equipo no debe decidir o pensar por él, ni en el mejor de los casos podemos ponernos en sus zapatos por mas buenas que sean nuestras ideas. Sabemos que tener al cliente es bastante complicado, aún y cuando, el será uno de los principales beneficiados del producto. La realidad es que no somos la única prioridad en su día, tiene una empresa, un departamento o un equipo que sacar adelante, con todos los retos que esto implica. ¿Qué hay si no podemos contar con el usuario?, ¿Cuáles son nuestras opciones? Para obtener los resultados que el cliente espera debemos de contar con alguien lo mas cercano o parecido a él, que tenga el conocimiento del negocio que necesitamos, la experiencia y el poder de decisión. ¿Por qué es importante? Razones hay muchas, entre ellas: La necesidad y los requerimientos están claros, los requerimientos son priorizados de acuerdo a las necesidades del negocio, nos puede resolver dudas en el día a día, no una semana después (comunicación cara a cara), nos mantenemos en el camino de desarrollar el producto correcto, participa en el progreso, en las reuniones y revisiones, es parte del equipo y comparte responsabilidad. Por mas experiencia que tenga nuestro equipo, que tenga las mejores ideas, las mejores intenciones, si no es nuestro producto, no podremos suplir el conocimiento y la necesidad real que tiene el cliente al querer desarrollar su producto. El tiene el conocimiento y la visión de hacia donde quiere llevar su negocio.

Garantizando la Calidad del Producto

Thu, 22 Jan 2015 00:55:52 -0600

Una de las ventajas de utilizar Scrum, es que la calidad del producto resultante mejora, ¿Porqué decimos esto?. Aún y cuando utilicemos Scrum sin el apoyo de herramientas o técnicas sofisticadas, tenemos durante el proceso de desarrollo, diferentes oportunidades de ir inspeccionando y monitoreando la calidad de los productos que vamos generando. A continuación destacamos algunas de ellas.

Planeación – A través de la interacción del equipo analizando los diferentes requerimientos y características de los productos para lograr la mejor solución, así como identificar la necesidad de información.
Reunión diaria – En esta actividad tenemos oportunidad de retroalimentar sobre el producto y de adaptarnos a lo que vamos encontrando en el día a día.
Trabajo realizado – (Work Done) cada miembro del equipo tiene la información y conocimiento para considerar que el trabajo realizado está hecho, es decir, que cumple con cada uno de los requisitos y criterios establecidos.
Retrospectiva – El equipo identifica buenas prácticas y oportunidades para mejorar en el siguiente ciclo.
Demo – Tenemos la retroalimentación de que lo que estamos construyendo es lo que él negocio necesita. Identificamos ajustes y replanteamos necesidades.

Cada una de las actividades anteriores da al equipo, y al dueño del producto, la oportunidad de ver sí están construyendo el producto correcto, de la manera correcta, desde el primer ciclo. Al final de cada iteración o Sprint, adaptarse según se vean los resultados.

Photo by John Schnobrich on Unsplash

Oportunidades en Agil para Inspeccionar

Wed, 21 Jan 2015 19:03:26 -0600

El trabajo en Scrum es colaborativo, informado, por lo que durante el proceso de desarrollo tenemos diferentes oportunidades para inspeccionar o validar el trabajo que estamos haciendo. No solo se trata de que se hagan las pruebas necesarias sino de ver que lo que estamos haciendo es lo que realmente se está pidiendo y como se está pidiendo. Ver completo en Allsoft

Proyecto tradicional vs Proyecto con Scrum

Fri, 02 Jan 2015 18:54:09 -0600

Algunas de las diferencias entre un proyecto tradicional vs uno gestionado con Scrum, es en la información que tenemos en uno y en otro, por ejemplo en un proyecto tradicional tenemos requisitos estables y estimamos tiempo y esfuerzo, en un proyecto Scrum tenemos tiempo y esfuerzo y estimamos requisitos. Otras diferencias las puedes encontrar en en la siguientes gráfica de Scrum Manager. Tradicional vs Scrum