Agilidad Archives - Software Evolutivo

Colaboración en equipos tecnológicos: Integrando el Corazón de la Agilidad

Gissella Trujillo — Thu, 17 Oct 2024 23:45:13 +0000

Vivimos en una era donde la tecnología evoluciona a un ritmo vertiginoso. La incertidumbre, la volatilidad, la complejidad y la ambigüedad (VUCA) son la nueva normalidad.

En este contexto, los equipos de tecnología ya no pueden trabajar de forma aislada. La clave para destacar y ser competitivos radica en la colaboración.

La colaboración en equipos de tecnología es fundamental para mantenerse competitivo en el mercado actual. Las estadísticas muestran que el 97% de los ejecutivos considera que la falta de alineación dentro de un equipo impacta negativamente en los resultados de proyectos o tareas (Jobstik). Además, el 56% de los ejecutivos encuestados indican que las medidas relacionadas con la colaboración son el factor más importante que afecta la rentabilidad de sus organizaciones (KhrisDigital).

Estos datos resaltan la importancia de fomentar un ambiente colaborativo, ya que no solo mejora el rendimiento y la satisfacción de los empleados, sino que también contribuye a los resultados financieros y a la innovación de la empresa.

La Suma es Mayor que la Suma de las Partes

Cada miembro de un equipo aporta un conjunto único de habilidades, conocimientos y perspectivas. Cuando estos se unen y se complementan, el resultado es mucho mayor que la simple suma de sus partes individuales.

La colaboración multiplica las capacidades del equipo

La interacción entre los miembros del equipo no solo suma habilidades, sino que también genera una sinergia donde nuevas ideas pueden emerger. Es como si las ideas rebotaran y se combinaran, dando lugar a conceptos innovadores que no surgirían de manera aislada. Esto se traduce en que, en un entorno colaborativo, 1+1 puede ser igual a 5, ya que la colaboración potencia exponencialmente las capacidades del equipo. Esto sucede gracias a:

La colaboración en equipos no solo maximiza el potencial individual de cada miembro, sino que crea un entorno donde las ideas pueden florecer y convertirse en algo extraordinario. Es un claro ejemplo de cómo la colaboración puede superar la simple suma de sus partes, produciendo resultados excepcionales.

Agilidad: Un Corazón Colaborativo

En el corazón de la agilidad se encuentra la colaboración. Los equipos ágiles se basan en la comunicación abierta, la transparencia y la retroalimentación constante. Esto fomenta un ambiente de confianza donde todos los miembros se sienten valorados y empoderados para contribuir.

El corazón de la Agilidad, se centra en cuatro principios fundamentales: Colabora, Entrega, Reflexiona y Mejora. Estos principios, representados de forma visual en un diamante, encapsulan la esencia de la agilidad de manera simple y directa.

La belleza de estos cuatro principios radica en su simplicidad. No requieren una gran cantidad de formación o explicación para ser entendidos y adoptados. Al enfocarse en estos conceptos básicos, los equipos pueden cultivar una mentalidad ágil y un enfoque orientado a resultados, fomentando un entorno de trabajo dinámico y efectivo. El diamante que los representa es un recordatorio visual de que cada elemento es igualmente importante y está interconectado, formando un sistema cohesivo que impulsa el éxito de equipos ágiles.

Para este caso, nos centramos en cómo fomentar la Colaboración:

Trabajar en un equipo ágil, significa colaborar en sintonía. Y para hacerlo bien, hacerlo bien, es importante centrarse en tres aspectos clave: confianza, motivación y el acto de colaborar en sí mismo.

✨Confianza: La confianza es un tópico enorme. Una búsqueda rápida en Amazon entrega más de 91.000 títulos de libros de confianza. Cuando confías en tus compañeros, te sientes cómodo compartiendo ideas y opiniones, sin miedo a ser juzgado o ignorado, ahí estamos hablando de seguridad psicológica. Esto se construye con el tiempo y es vital para un equipo innovador.

“El clima de equipo positivo es el impulsor más importante de la seguridad psicológica y es más probable que ocurra cuando los líderes demuestran comportamientos de apoyo y consulta, y luego comienzan a desafiar a sus equipos” – McKinsey and Company

✨Motivación: La motivación es lo que impulsa a las personas a trabajar con entusiasmo. Puede ser de dos tipos: Motivación intrínseca: Es la que viene de adentro, como la satisfacción de hacer un buen trabajo o aprender algo nuevo. Motivación extrínseca: Son recompensas externas, como dinero, reconocimiento o promociones.

La motivación intrínseca es más poderosa; sin embargo, es diferente para cada persona, y podemos fomentar un ambiente motivador si entendemos las motivaciones de los miembros del equipo. Una manera sencilla de conocer los motivadores personales del equipo es mediante la dinámica de Moving Motivators o Champ Frogs. Estas herramientas te pueden ayudar a diagnosticar y mejorar los aspectos que motivan al equipo dentro del ambiente de trabajo.

✨El acto de colaborar: No es solo trabajar juntos, sino también comunicarse abiertamente, escuchar a los demás y ser flexible. La colaboración efectiva significa que todos los miembros del equipo se sienten valorados y que sus contribuciones son importantes.

Una herramienta que puede ayudar a diagnosticar y mejorar la colaboración es Dinámicas de Roles de Belbin: Esta herramienta permite identificar los roles que cada miembro tiende a asumir en el equipo, ya sea como líder, implementador, creador de ideas, etc. Al conocer estos roles, puedes ajustar el trabajo para que cada persona esté en una posición donde su colaboración sea más efectiva.

Preguntas para mejorar la colaboración

Para mejorar la colaboración en un equipo, es útil hacer preguntas con intención, es decir, preguntas que no solo busquen obtener información, sino que también fomenten la reflexión y el diálogo.

Sobre la confianza

¿Qué acciones pueden tomar los miembros del equipo para construir y mantener la confianza?
¿En qué momentos te has sentido más confiado trabajando con el equipo? ¿Qué contribuyó a esa confianza?
¿Hay alguna situación reciente en la que hayas sentido falta de confianza? ¿Cómo podríamos haber manejado mejor esa situación?

Sobre la motivación

¿Qué te motiva a dar lo mejor de ti en el equipo?
¿Qué factores disminuyen tu motivación? ¿Cómo podemos abordarlos como equipo?
¿Cómo podemos asegurarnos de que cada miembro del equipo se sienta valorado y reconocido por sus contribuciones?

Sobre el acto de colaborar

¿Qué herramientas o métodos han sido más efectivos para colaborar en proyectos recientes?
¿Qué desafíos has enfrentado al colaborar con otros y cómo los superaste?
¿Hay formas en que podríamos dividir mejor las tareas y responsabilidades para aumentar la eficiencia?

Las preguntas están diseñadas para promover una conversación abierta y reflexiva. Al centrarse en estos temas, los equipos pueden trabajar para crear un entorno de trabajo más colaborativo y efectivo.

Liderazgo en todos los niveles: ¿Quién Debería Impulsar la Colaboración en el Equipo?

Hacer preguntas intencionadas para mejorar la colaboración no solo ayuda a identificar áreas de mejora, sino que también fortalece las relaciones dentro del equipo. Pero, ¿Quién debería ser el encargado de hacer estas preguntas?

1. Líderes de Equipo y Gerentes

Los líderes de equipo y gerentes son responsables de establecer un ambiente de trabajo positivo y productivo. Como figuras de autoridad, tienen la responsabilidad de guiar las discusiones y asegurar que todos los miembros del equipo se sientan escuchados y valorados. Al hacer preguntas intencionadas, pueden:

Identificar obstáculos en la colaboración.
Fomentar la confianza y la transparencia.
Motivar a los miembros del equipo a expresar sus ideas y preocupaciones.

2. Facilitadores de Reuniones y Coaches Ágiles

Los facilitadores de reuniones, como Scrum Masters o coaches ágiles, juegan un papel crucial en la dinamización de equipos ágiles. Su función es observar las dinámicas del equipo y proporcionar retroalimentación constructiva. Al hacer preguntas, estos facilitadores pueden ayudar a:

Reflexionar sobre el trabajo realizado y encontrar áreas de mejora.
Promover la autoevaluación y el aprendizaje continuo.
Guiar al equipo hacia soluciones prácticas y efectivas.

3. Miembros del Equipo

Cada miembro del equipo tiene la capacidad de influir positivamente en la colaboración. Al ser proactivos y formular preguntas, pueden:

Contribuir a una cultura de apertura y honestidad.
Fomentar un diálogo constructivo y respetuoso.
Asegurar que las diferentes perspectivas sean consideradas y respetadas.

4. Consultores Externos

En ocasiones, las organizaciones pueden recurrir a consultores externos para obtener una perspectiva imparcial. Estos profesionales pueden facilitar discusiones y realizar preguntas que quizá no sean obvias para los miembros internos del equipo. Al hacerlo, pueden:

Identificar problemas subyacentes que podrían estar afectando la colaboración.
Proporcionar soluciones basadas en experiencias de otras organizaciones.
Ayudar a implementar cambios estructurales o culturales necesarios.

La responsabilidad de hacer preguntas intencionadas para mejorar la colaboración no recae en una sola persona. Es un esfuerzo colectivo que debe ser fomentado por todos los niveles de la organización. Al fomentar una cultura de preguntas abiertas y reflexivas, se pueden identificar problemas y oportunidades de mejora, lo que lleva a un equipo más cohesionado y eficiente.

Recuerda:

La clave está en la disposición para escuchar y actuar sobre las respuestas recibidas.

¿Cómo fomentamos la colaboración en Software Evolutivo?

En Software Evolutivo, creemos que la agilidad es clave para ofrecer resultados exponenciales a nuestros clientes.

Más allá de las técnicas y herramientas, lo que realmente marca la diferencia es cómo colaboramos y trabajamos en equipo. La agilidad es un enfoque que nos permite adaptarnos rápidamente, y fomentar una cohesión efectiva entre nuestros equipos de desarrollo y comercial.

Colaboración Continua y Transparente: Organizamos reuniones diarias y revisiones de sprint para alinear objetivos y facilitar el intercambio de información. Esto asegura que todos los miembros del equipo estén informados y puedan contribuir con sus perspectivas únicas.
Equipos Multifuncionales y Autonomía: Nuestros equipos están formados por profesionales de diversas disciplinas que trabajan juntos para resolver problemas y mejorar productos. La autonomía les permite tomar decisiones rápidas y efectivas, adaptándose a las necesidades del cliente.
Cohesión a Través de la Retroalimentación y la Reflexión: Realizamos retrospectivas al final de cada sprint para discutir aciertos y áreas de mejora. Este proceso fomenta un ambiente de apertura y confianza, crucial para el desempeño efectivo del equipo.
Integración de Perspectivas para Soluciones Óptimas: La colaboración entre los equipos de desarrollo y comercial nos permite crear soluciones ajustadas a las necesidades del mercado, maximizando el valor entregado a nuestros clientes.
Fortalecimiento de la Relación con el Cliente: Involucramos a nuestros clientes en cada fase del proyecto, asegurando que sus necesidades sean comprendidas y atendidas. Esto resulta en productos que realmente solucionan sus problemas y añaden valor significativo.

En Software Evolutivo, la agilidad es mucho más que un enfoque; es un reflejo de cómo trabajamos juntos para alcanzar el éxito. Nuestra cohesión interna y nuestra capacidad para colaborar de manera efectiva nos permiten entregar soluciones de software que cumplen con estándares, superan expectativas y generan un impacto positivo en nuestros clientes.

Conclusiones

La Colaboración como Pilar de la Innovación
En la era del conocimiento, la colaboración es fundamental para el éxito. La diversidad de habilidades y perspectivas en un equipo crea un entorno donde la suma de las partes es mucho mayor que sus componentes individuales. Este fenómeno, donde 1+1=5, demuestra cómo la sinergia puede llevar a soluciones innovadoras y eficientes que no serían posibles en el trabajo aislado.O como dice el proverbio africano: “Si quieres ir rápido ve solo, si quieres llegar lejos ve acompañado”

El Corazón de la Agilidad: Simplicidad y Efectividad
Los principios del corazón de la Agilidad—Colabora, Entrega, Reflexiona y Mejora—son simples pero poderosos. Estos principios no solo facilitan la colaboración efectiva, sino que también promueven un enfoque ágil y adaptable en un entorno de trabajo dinámico. La simplicidad de estos conceptos permite su fácil adopción y aplicación, potenciando la productividad y la satisfacción del equipo.

Importancia de la Comunicación Abierta y la Retroalimentación
Para fomentar una colaboración efectiva, es crucial mantener una comunicación abierta y honesta. Las preguntas intencionadas, ya sean formuladas por líderes, facilitadores o los propios miembros del equipo, ayudan a identificar áreas de mejora y a fortalecer las relaciones internas. Este enfoque promueve un ambiente de confianza y respeto, esencial para un trabajo colaborativo exitoso.

¿Buscas mayor agilidad y eficiencia?

Automatiza y moderniza tus sistemas con nuestras soluciones en automatización y modernización de aplicaciones.

¡Da el siguiente paso hacia la transformación digital!

Modernización de Aplicaciones

The post Colaboración en equipos tecnológicos: Integrando el Corazón de la Agilidad appeared first on Software Evolutivo.

Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile?

Gissella Trujillo — Fri, 14 Jun 2024 23:50:43 +0000

¡Software Evolutivo es una empresa ágil! ¿O tal vez no? Durante el Team Building trimestral de Software Evolutivo, nos sumergimos en una experiencia única que combinó la diversión de LEGO con los principios ágiles de Scrum.

Cuando te introduces en el mundo de la agilidad, es habitual encontrar muchas fotografías o referencias de equipos que parecen divertirse “jugando” con Legos de colores. Siendo formadores, coaches o líderes de proyecto, enseguida nos planteamos si este “juego” también podría ser útil para nosotros.

En este blog, explicaremos cómo Lego Scrum nos permitió descubrir aspectos que podrían haber pasado desapercibidos durante la rutina del día a día y fortalecer la colaboración entre nuestros equipos Comercial y de Desarrollo. A través de las metodologías ágiles, buscamos transmitir y asentar mejor los conocimientos en nuestros equipos. Acompáñanos para conocer más sobre esta experiencia.

Índice:

1. El Desarrollo del Lego Scrum: Personas y proyectos

2. Planeación y Estimación

3. Sprint y Construcción

4. Revisión y Retrospectiva

5. Lecciones Aprendidas

6. Conclusiones

1. El Desarrollo del Lego Scrum: Personas y proyectos

Durante el evento, dividimos a nuestro equipo en grupos multidisciplinarios, es decir, mezclamos a personal del área comercial con el equipo de Desarrollo, e incluso incluimos a nuestro jefe Jorge. Una vez que todos estábamos bien integrados y mezclados, cada equipo recibió uno de estos desafíos:

💬 Cada proyecto Lego tenía sus propias historias de usuario y desafíos únicos, lo que les ofreció oportunidades para enfrentar situaciones distintas y demostrar toda su creatividad y habilidades.

Reglas de Lego Scrum (las mismas que Scrum, pero ajustadas):

– Los equipos deben usar solo los materiales proporcionados.
– Cada historia de usuario debe completarse antes de pasar a la siguiente.
– Se alienta la comunicación y colaboración dentro de los equipos.
– Cada Sprint debe resultar en un producto o mejora tangible que se pueda revisar.
– ¿Y el Product Owner? Compartimos uno para los dos grupos.
– ¿Y el Scrum Master? Cada equipo se encargó de nombrar uno.

2. Planeación y Estimación

Comenzamos con una sesión de planificación, donde cada equipo seleccionó el proyecto a construir y estimó el tiempo necesario para completarlo.

– El equipo “Transporte Espacial Lego” 🚀 utilizó la técnica de Planning Poker, para llegar a un consenso sobre la complejidad de cada historia de usuario. ¡Muy bien, estaban liderando con esa organización!

– Lamentablemente nuestro equipo “Ciudad Lego” 🏙️ no empezó con estimación (a algunos agilistas no les gusta estimar) y durante el primer sprint no lograron entregar todo el valor.

Desde la perspectiva de los participantes, se consideró la falta de realizar una incepción para poder entender mejor el producto como una limitación significativa en el proceso de desarrollo.

💬 ¡Recuerda! Siempre realiza una reunión de incepción y planificación, y estima tus historias para asegurar que todos los miembros del equipo tengan una comprensión clara de las tareas, prioricen adecuadamente y establezcan expectativas realistas sobre lo que se puede lograr en cada sprint. Esto también ayuda a identificar posibles obstáculos con anticipación y facilita la comunicación y la colaboración eficaz dentro del equipo.

3. Sprint y Construcción

Con el plan en su lugar, cada equipo se embarcó en su primer Sprint de construcción. Durante este tiempo, los grupos aplicaron los principios de Scrum, realizando reuniones “diarias” de stand-up para compartir el progreso, identificar obstáculos y ajustar el plan según fuera necesario.

¿Y el Product Owner? Bueno, indicamos que la comunicación con el PO se realizaría On Demand.

– El grupo “Transporte Espacial Lego” 🚀 utilizó muy bien sus tiempos y preguntaron todos los posibles obstáculos con anticipación, ¡Muy bien, seguían liderando con esa gestión de riesgos!
– Lamentablemente nuestro equipo “Ciudad Lego” 🏙️ no empezó con estimación y casi pero casi no lograron entregar todo el valor comprometido para el final del Sprint.

Imagen: Equipos en Sprint de Construcción

Imagen: Product Owner Disponible On Demand

Imagen: Equipo "Transporte Espacial Lego" en Acción

Imagen: Equipo "Ciudad Lego" en el Sprint Final

4. Revisión y Retrospectiva

Al final de 3 sprints, y con algunos sobresaltos mientras se apagaban los incendios, cada equipo presentó su proyecto terminado. Con cada revisión se pudo mejorar el producto y con cada retroalimentación mejoraron el proceso. Ambos equipos aprendieron de sus errores iniciales y al final de todo…

– “Transporte Espacial Lego” 🚀 y el equipo “Ciudad Lego” 🏙️ ¡culminaron exitosamente sus proyectos! 🏁

💬 Entonces, ¿Software Evolutivo es ágil? No lo sabremos sin antes tener una sesión de retroalimentación donde discutimos los resultados y compartimos feedback constructivo.

Aunque en los equipos más jerárquicos y tradicionales, el proceso de feedback puede verse con temor por el miedo a un ataque personal o una mala interpretación de las observaciones, en Software Evolutivo practicamos una comunicación asertiva para identificar: áreas de mejora, reconocer los logros del equipo y fomentar un ambiente de aprendizaje continuo.

5. Lecciones aprendidas

Aunque trabajamos juntos día a día, cuando se encendió el cronómetro, nos encontramos resolviendo problemas urgentes, y tal vez olvidamos algunas cosas importantes, la experiencia del Lego Scrum fue reveladora en varios aspectos:

– La colaboración entre los equipos comerciales y de desarrollo se fortaleció significativamente mientras trabajaban juntos para completar las historias de usuario. Cuanta más cohesión tengamos en el equipo, más resultados exponenciales obtenemos.
– Estima tus historias para tener una visión clara del esfuerzo necesario para completarlas.
– La negociación con el Product Owner es clave para entregar valor al cliente, ya que ayuda a establecer expectativas realistas y a alinear las prioridades con las necesidades del cliente.
– Si no estamos seguros de alcanzar a entregar todo lo que nos pide el cliente, podemos aplicar la regla de Pareto y entregar primero lo que es más importante, maximizando así el valor entregado en el tiempo disponible.
– Además, recuerda que en equipos pequeños el Scrum Master también puede formar parte del Scrum Development Team, lo que facilita una colaboración más estrecha y una mayor comprensión de los desafíos y oportunidades del proyecto.

💬 Recuerda: Al realizar una retrospectiva del evento Lego Scrum en general, lo que estamos buscando es la mejora de la ejecución del evento como tal y como eso nos ayuda a replicar y mejorar las actividades para obtener mejores resultados en el futuro. También en este caso, el facilitador y el Product Owner recibieron feedback por parte de los desarrolladores y el equipo comercial.

6. Conclusión

El Lego Scrum fue mucho más que una actividad de Team Building; fue una experiencia transformadora que fortaleció nuestra colaboración y mejoró nuestra capacidad para entregar valor al cliente. Si estás buscando una forma innovadora de fortalecer la colaboración en tu organización y maximizar la entrega de valor al cliente mediante enfoques ágiles, ¡considera el Lego Scrum como una opción! En nuestro próximo Blog se realizará la guía paso a paso para replicar Lego Scrum con tu equipo.

¿QUIERES SER ÁGIL?

¡Descubre cómo los frameworks agile maximizan la entrega de valor al cliente!

Contáctanos para obtener más información sobre cómo podemos ayudarte a implementar estas prácticas en tu organización.

Conoce más

💬 Nos encantaría conocer tu opinión sobre cómo las metodologías ágiles han impactado en tu equipo y en la entrega de valor al cliente. ¡Déjanos tus comentarios y comparte tus experiencias!

The post Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile? appeared first on Software Evolutivo.

Scrum: El rol del Product Owner

Mateo Martínez — Thu, 15 Dec 2022 21:55:04 +0000

El marco de trabajo “Scrum” dentro del desarrollo de software, sugiere un conjunto de buenas prácticas aplicadas al desarrollo de productos de software, estas permiten mejorar el trabajo en equipo y busca obtener los mejores resultados. Para lograr su objetivo, Scrum sugiere que cada equipo cuente con 3 roles principales: el Product Owner, el Scrum Master y el Equipo de Desarrollo.

Es muy común confundir las tareas y objetivos que cada rol cumple sobre todo con el Product Owner, quien ocupa un lugar menos técnico en el equipo, por lo tanto, el objetivo de este blog será dejar en claro cuáles son las responsabilidades, retos y características que un Product Owner tiene.

Figura 1. El Product Owner y sus responsabilidades.

El objetivo principal del Product Owner (PO) es optimizar el valor del producto final entregado por todo el equipo de desarrollo hacia el cliente.

Para poder cumplir con este objetivo el PO es responsable de:

– Desarrollar y comunicar de manera clara a todo el equipo sobre los objetivos del producto, para saber hacia dónde se encamina el trabajo a realizarse.
– Comunicar explícitamente sobre los elementos de trabajo, es decir, entrar en detalles sobre las especificaciones de lo que se va a desarrollar a través de cada entregable (conocido también como sprint).
– Mantener una comunicación con el Scrum Master y el Equipo de Desarrollo siempre transparente y comprensiva, además, se sugiere que sea hablada y no escrita para facilitar el feedback (retroalimentación) y la resolución de dudas.

Retos a los que el Product Owner se enfrenta

En cuanto a la cultura ágil se refiere, el PO deberá mantener la orientación a las entregas, las prácticas que se adaptan al equipo en base a la experiencias y evidencias del equipo.

En cuanto a la cultura empresarial, el PO se enfrenta a desafíos relacionados a los resultados del producto, principios y prácticas, y a la retroalimentación en cada entrega del producto.

Enfrentarse a estos retos no es algo sencillo, para que un miembro del equipo califique para desempeñarse como Product Owner deberá:

– Tener conocimiento del negocio.
– Tener conocimiento del producto para identificar los puntos fuertes y débiles de este para mejorarlos y tener un dominio sobre todas las aristas.
– Tener conocimiento del contexto en el que se encuentra el usuario final.
– Desarrollar un correcto análisis del negocio, es decir, entender los problemas y estar en la capacidad de ofrecer soluciones en base al cliente, el equipo y la organización.

Además, las habilidades blandas que se identifican en un PO son:

– Influencia positiva en el equipo.
– Comunicación y buen diálogo durante las reuniones. Permite siempre llegar a soluciones y conclusiones productivas.
– Negociación constante tanto con el cliente como con el equipo.
– Abstracción y categorización de toda la cantidad de información que recibe para poder comunicar y llegar con el mensaje al resto del equipo.

El trabajo del Product Owner

Hemos revisado las características de un Product Owner de una manera un tanto general, ahora en la práctica, en el día a día quien ocupe este rol deberá realizar actividades como las siguientes:

– Determinar los objetivos de un producto.
– Definir y crear el backlog mediante las características del producto.
– Gestionar y priorizar el backlog creado.
– Crear las historias de usuario. (Para más info “Mejores Historias de Usuario para Scrum”)
– Para garantizar el desarrollo adecuado del producto debe estar presente en:
– Reuniones de refinamiento de los pendientes (semanales).
– Reuniones para revisar los sprints.

Interacción con el resto del equipo

Figura 2. Interacción del Product Owner.

Al ser el Product Owner la voz del cliente y el negociador principal entre él y el equipo de desarrollo, el PO interactúa constantemente con el resto del equipo en situaciones como:

– Para el desarrollo del backlog, se tiene en cuenta la opinión y perspectiva de todo el equipo.
– En la planeación del sprint, se realiza la estimación en base a un consenso entre todos quienes colaboran en el proyecto.
– Cuando surgen impedimentos o bloqueos para el avance del proyecto, el PO tiene la responsabilidad de interactuar con el equipo para informar y establecer qué tan prioritaria es la entrega del elemento que está teniendo el bloqueo en cuestión o cuánto valor puede entregar al cliente este elemento.
– En la revisión del sprint, el PO tiene que reunir al equipo y a los involucrados relevantes para que se realice una inspección de lo que se está entregando.
– El PO participa en la retrospectiva del sprint y durante ese período debe tratar de participar en todas las dailys.

Importante

Establezcamos un par de roles con los que más a menudo solemos confundir al Product Owner:

– El Business Analyst identifica y define soluciones para maximizar el valor que se entrega en un proyecto, se lo confunde con el PO pero en la práctica el PO suele tener un Business Analyst para ayudarlo en la toma de decisiones, sin embargo la diferencia radica en que solo el PO puede priorizar en base a la información de la que dispone.
– El Product Manager es quien crea las estrategias del producto pero a un nivel más global, en este caso es el Product Manager quien puede tener a varios Product Owner trabajando en diferentes partes de un proyecto.

Conclusiones

Al Product Owner se lo puede definir de manera sencilla como ”la voz del usuario final en el equipo de desarrollo”, cumple con un rol estándar dentro del marco de Scrum y su trabajo se enfoca principalmente en realizar la entrega de un producto de calidad que permita satisfacer tanto a cliente como a usuario final después de haber seguido un largo pero claro y organizado camino junto al resto de su equipo de trabajo.

Complementos

Te invito a revisar mucha más información que puede ayudarte a desarrollar tus conocimientos en agilidad.

– Mejores Historias de Usuario para Scrum
https://softwareevolutivo.com.ec/mejores-historias-de-usuario-para-scrum/

– ¿La Agilidad puede ayudar a mi organización?
https://softwareevolutivo.com.ec/la-agilidad-puede-ayudar-a-mi-organizacion/

Fuentes

El presente blog, fue desarrollado en base a los conocimientos adquiridos en:

– “Curso de Fundamentos de Product Owner” de Platzi:
https://platzi.com/cursos/product-owner/

– Scrum Guide:

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-American.pdf

The post Scrum: El rol del Product Owner appeared first on Software Evolutivo.

¿La Agilidad puede ayudar a mi organización?

Gissella Trujillo — Thu, 04 Aug 2022 19:29:07 +0000

El desafío de cambiar la cultura y la forma de pensar a nivel de individuos y equipos es bien conocido para quienes ya conocen de Agilidad y para las empresas que están en este camino.

Muchas veces los esfuerzos y decisiones para lograr un cambio se ven poco claras o insatisfactorias, como en una conversación acerca del clima; todos parecemos tener algo que decir al respecto pero nadie puede cambiarlo.

A continuación se presenta un ejercicio que nos ayudará a enfocarnos en las cosas que sí podemos mejorar. Este ejercicio es parte de una clase del PROFESSIONAL AGILE LEADERSHIP ESSENTIALS™ TRAINING, creado por Kurt Bittner del equipo de Scrum.org. Para ayudar a los líderes del cambio a comprender mejor dónde encaja la agilidad y dónde puede ayudar a tu organización.

Antes de empezar, recordamos que la agilidad no tiene un único enfoque en su adopción ya que depende del contexto empresarial. Por lo tanto cada esfuerzo realizado por la organización en este sentido es susceptible de ajustes de acuerdo a su realidad.

Modelo de la afinidad Ágil

Por agilidad, hablamos del enfoque empírico para entregar valor al negocio de manera incremental, medir el efecto de esa entrega, inspeccionar los resultados y adaptarse basado en el aprendizaje de esta inspección.

Este modelo de Afinidad Ágil considera 5 dimensiones ( Figura 1 ) que influyen en la atracción o resistencia al empirismo dentro de la organización.

Figura 1. Modelo de la afinidad Ágil

Estas 5 dimensiones expresan diferentes fuerzas internas y externas que afectan a las creencias y valores de una organización.

Dimensiones externas (Amenaza Competitiva y Potencial de Crecimiento del Mercado): Comúnmente atraen a las organizaciones hacia la agilidad.
Dimensiones internas (Voluntad de Experimentar, Incertidumbre de la Solución y Descentralización de Decisiones): Casi siempre retrasan a la organización para volverse más Ágil.

¿Por qué estas dimensiones?

Estas dimensiones capturan la esencia de los desafíos a los que se enfrentan las organizaciones y proporcionan una forma útil de conocer mejor las actividades y tener debates sobre lo que las personas podrían hacer para cambiar las creencias que frenan su Agilidad.

Cada una de estas dimensiones se describen a continuación:

Amenaza competitiva

Expresa el grado en que el producto o servicio está desafiado por la competencia.

Indicadores
Bajo	Elevado
Tenemos alta cuota de mercado	Tenemos baja cuota de mercado
Existe poca competencia	Tenemos mucha competencia
El cliente tiene alta dependencia a nuestro producto / servicio	Poca dependencia del cliente hacia nuestro producto / servicio

Voluntad de experimentar

Expresa el grado en que la organización se siente cómoda con la incertidumbre.

Indicadores
Bajo	Elevado
Incrementamos detalles del plan cuando aumenta la incertidumbre.	Formulamos hipótesis y se ejecutamos experimentos para probar suposiciones cuando aumenta la incertidumbre.
Agregamos hitos y revisiones cuando aumenta la incertidumbre.	Planificamos en pequeños incrementos, medimos, inspeccionamos y adaptamos los planes.
Consideramos como un resultado negativo cualquier desviación en el plan.	Las desviaciones de los planes se consideran como información nueva.

Incertidumbre de la solución

Es el grado en que la organización está segura de saber lo que el mercado y los clientes necesitan de nuestro producto o servicio.

Indicadores
Bajo	Elevado
Las solicitudes de cambio en nuestro producto / servicio se consideran resultados negativos	Realizamos focus group o otro tipo de investigación de forma frecuente para evaluar diferentes alternativas y necesidades del cliente
Tenemos pocos datos disponibles sobre el uso real del usuario sobre nuestro producto / servicio.	Preparamos nuestras aplicaciones para obtener información de uso real del usuario con nuestro producto / servicio
Planificamos los lanzamientos y actualizaciones siguiendo en gran medida roadmaps del producto / servicio.	Ejecutamos pruebas A / B para probar y validar alternativas o nuevas características a nuestros productos / servicios.
Basamos los releases de nuevas características en roadmaps detallados que han sido planificados con mucha anticipación.	No tenemos roadmaps de productos a largo plazo, los roadmaps del producto cambian con el tiempo.

Descentralización de decisiones

Expresa el grado en que la autoridad para la toma de decisiones está dispersa en la organización, en el que ciertas decisiones específicas pueden ser tomadas por individuos o equipos sin tener que buscar la aprobación de mandos superiores.

Indicadores
Bajo	Elevado
Todas las decisiones de gasto deben pasar por un gerente con la autoridad presupuestaria adecuada.	Permitimos que los equipos sean responsables de un presupuesto que pueden usar para ayudarlos a cumplir sus objetivos.
Todas las decisiones de contratación y despido las toman los mandos superiores.	Permitimos que los equipos se involucren, participen o tomen decisiones de contratación / despido.
Todas las decisiones de productos las toman los mandos superiores.	Permitimos tomar decisiones sobre el producto a los equipos (incluido Product Owner)

Potencial de crecimiento

Expresa el grado en que el producto tiene potencial de crecimiento en el mercado, es decir el grado en el que puede aumentar significativamente los ingresos.

Indicadores
Bajo	Elevado
El producto está en un mercado que se está contrayendo.	El producto está en un mercado en rápida expansión.
La cuota de mercado del producto se está reduciendo	Los competidores dominantes en el mercado se debilitan y pierden cuota de mercado.
El producto proporciona un ingreso o ganancia constante, ha alcanzado una gran participación de mercado.	Es posible aumentar los ingresos del producto aumentando el número absoluto de clientes o aumentando la participación de mercado.

Aplicando el modelo en tu equipo de trabajo

Objetivos:

Sacar a la superficie supuestos tácitos pero muy importantes.
Lograr que el equipo piense en el entorno en el que se va a introducir un enfoque ágil o empírico.

Antes de empezar, recuerda:

¿Cómo empezar?:

Organizar idealmente en equipos de menos de 5 personas para cada producto.
Cada equipo marca las dimensiones para el producto / equipo en el que trabaja.
Si hay personas de diferentes productos en el mismo equipo, pídeles que marquen las dimensiones de cada producto.
Dibujar las líneas entre puntuaciones. Tendrá un resultado similar a este (Figura 2) , donde cada color representa un producto diferente.

Figura 2. Resultado Modelo de Afinidad Ágil

Cada equipo revisa sus puntuaciones y explica sus porqué mientras los demás equipos solo pueden escuchar y hacer preguntas aclaratorias
Después de la presentación se ayuda a los grupos a sacar algunas conclusiones.

Interpretación de los resultados

Recuerde: No existen respuestas correctas y el valor del ejercicio es estimular la conversación sobre los desafíos que cada organización enfrenta al adoptar un enfoque Ágil.

Algunos puntos de discusión comunes

Baja amenaza de la competencia/ Potencial de crecimiento del mercado

En este caso es importante distinguir si este producto realmente se beneficia del empirismo. Sin mucha amenaza y pocas oportunidades, la organización puede enfocar esfuerzos en productos con mayor necesidad.

Ágil no es la forma de ejecutar todo y necesitamos ser reflexivos sobre ello. Debido a que la organización sólo puede respaldar cierta cantidad de cambios y forzar un cambio sin gran beneficio puede privar a otro equipo de la ayuda necesaria.

Alta amenaza de la competencia/ Potencial de crecimiento del mercado

El producto tiene oportunidades con las que el empirismo puede ayudar. Si además tenemos una calificación baja en dimensiones internas, éstas representan barreras internas que pueden impedir que funcione el empirismo.

Baja incertidumbre de la solución

Puede parecer algo bueno pero no lo es, podemos estar pensando que sabemos lo que quiere el cliente pero sin una medición sobre la experiencia del cliente ¿Cómo podemos estar seguros? El primer paso es medir la experiencia para saber que creencias son ciertas, caso contrario podríamos estar perdiendo oportunidades de brindar un mejor servicio a los clientes.

Baja disposición a experimentar

Surge de la aversión a cometer errores y de la creencia de que planificar al detalle aumenta la probabilidad de un plan totalmente seguro. Sin embargo, a menudo las suposiciones en las que se basa el plan, resultan no ser realistas.

Hacer pequeños experimentos es menos costoso y dañino que elaborar grandes planes detallados que a menudo salen mal.

e. Baja descentralización de decisión

Refleja falta de confianza entre gerentes y el equipo. Siempre que haya disposición de las partes hay muchos caminos para aumentar la confianza empezando por otorgar gradualmente a los equipos autonomía en la toma de decisiones pequeñas y seguir avanzando a cosas más grandes.

La actividad final del ejercicio, después de crear estas conversaciones valiosas, es preguntarse si como equipo están de acuerdo con su enfoque de trabajo actual, y si no lo están, ¿qué cambiarían?, para que puedan generarse acciones al respecto.

Para recordar

Las organizaciones son diferentes entre sí y dentro de ellas mismas encontramos equipos con objetivos diferentes. Por esta razón al adoptar prácticas ágiles o escalarlas, no existe un único enfoque.

Te invitamos a leer más sobre agilidad empresarial y agilidad desde el punto de vista del negocio en nuestro blog.

Fuentes:

https://www.scrum.org/pathway/product-owner-learning-path

https://www.scrum.org/resources/blog/whats-driving-your-need-agility

https://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/

https://www.scrum.org/resources/blog/business-agility

The post ¿La Agilidad puede ayudar a mi organización? appeared first on Software Evolutivo.

Mob Programming, colaboración en equipo

Johannes Caranqui — Thu, 16 Jun 2022 22:36:52 +0000

¿Qué es mob programming?

Popularizado por Woody Zuill, es una estrategia de programación para desarrolladores en grupo en la que trabajan en una única tarea al mismo tiempo, podríamos tomar como referencia a pair programming pero a una escala mayor.

Originalmente fue pensado para sesiones presenciales, pero poco a poco se ha adaptado para sesiones remotas, la idea principal es que un desarrollador sea piloto y sea el encargado de “pilotar” mientras que el resto actuará de “navegadores” brindando mejores prácticas para afrontar la tarea, refactorización de código y reducción de “smells” o malas prácticas de programación.

Para sesiones presenciales, se utilizará un solo ordenador, proyector y todos los desarrolladores en una misma sala, mientras que en sesiones remotas se utiliza varios ordenadores (uno por desarrollador remoto, lo cual puede sonar una desventaja ya que cada máquina debe tener un ambiente listo para desarrollar) y se proyecta su código en cualquier herramienta de videoconferencia como Google Meet, Jitsi, etc, así como manejar un repositorio de versionamiento como Github, Gitlab, entre otros.

Más información en el sitio web oficial.

Principios:

Herramienta para Mob remoto:

Para sesiones remotas se popularizó la herramienta Mob, la cual mejora la agilidad para el versionamiento de código.

Desarrollado por Remote Mob Programming, es una herramienta desarrollada en GO, mantiene las ramas limpias y solo crea “commits” temporales de proceso entre desarrolladores.

El tiempo de versionamiento se reduce considerablemente, lo que permite a los desarrolladores mantener su concentración en el código y no en el versionamiento.

Remote Mob Programming ofrece plugins para los principales IDEs de desarrollo como Visual Studio Code e IntelliJ.

Conclusiones:

Mob se da muy bien para trabajar con historias de usuario grandes y de alto valor de negocio.
Mob facilita el proceso de aprendizaje de los miembros del equipo de negocio y tecnológico.
Cuando las personas se respetan, colaboran y están dispuestas a aprender, Mob funciona muy bien.

The post Mob Programming, colaboración en equipo appeared first on Software Evolutivo.

Kata Juego de la Vida

Fernando Paz — Wed, 18 May 2022 19:35:27 +0000

Una de las katas más populares al hacer Coding Dojo es la Kata Juego de la Vida, y de hecho la más usada en Code Retreat.

Descripción del problema

Este Kata se trata de calcular la próxima generación del juego de la vida de Conway, dada cualquier posición inicial. Consulta Juego de la vida de Conway para conocer los antecedentes.

Comienza con una cuadrícula bidimensional de celdas, donde cada celda está viva o muerta. En esta versión del problema, la cuadrícula es finita y no puede existir vida fuera de los bordes.

Al calcular la próxima generación de la red, sigue estas reglas:

Cualquier celda viva con menos de dos vecinas vivas muere, como si la causa fuera la subpoblación.
Cualquier celda viva con más de tres vecinos vivos muere, como por superpoblación.
Cualquier celda viva con dos o tres vecinos vivos seguirá viva.
Cualquier celda muerta con exactamente tres vecinos vivos se convierte en una celda viva.

Pistas

La posición inicial de entrada podría ser un archivo de texto que se vea así:

Generación 1 inicial:

4 (filas) 8 (columnas)

0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0
0 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0

Generación 2 próxima resultante por regla No. 4:

4 (filas) 8 (columnas)

0 0 0 0 0 0 0 0
0 0 0 1 1 0 0 0
0 0 0 1 1 0 0 0
0 0 0 0 0 0 0 0

Visualiza tus casos de prueba

Hemos preparado la siguiente herramienta para que puedas dibujar (en caso remoto colaborativo) tus casos de prueba, revísalo en Juego de la vida visual.

Casos de prueba sugeridos

Asegúrate de tener suficiente cobertura de casos en los extremos, en donde hay nacimientos y muertes en el extremo de la cuadrícula.

!Que te diviertas! En tu Kata Juego de la vida

DISCLAIMER: La mayoría de este texto es traducido del valioso aporte en GameOfLife, pero no está disponible en español. Pero hemos añadido varias cosas a la descripción y alguna herramienta, para hacerlo en nuestro entendimiento más comprensivo.

The post Kata Juego de la Vida appeared first on Software Evolutivo.

Agilidad empresarial: Abrazar el cambio o morir en el intento

Gissella Trujillo — Wed, 27 Apr 2022 15:47:27 +0000

Agilidad empresarial

La competencia actual por cambiar en una economía basada en servicios es más fuerte que en la economía de producción que predominó el siglo pasado, por lo que es vital que una organización tenga la capacidad de adaptarse a nuevas condiciones y cambiar su dirección, a esto se lo conoce como Agilidad Empresarial.

El nuevo modelo económico cambiante ha transformado el mercado y se pronostica que la tendencia se mantendrá.

Algunos ejemplos de estos cambios los vemos en:

Expertos pronostican que esto no se limitará a industrias hoteleras, de transporte y entretenimiento, las cuales han hecho que empresas como Airbnb, Uber y Didi tengan tanto éxito en el mercado. Se puede extender a sectores a gran escala como confección, salud, energía, etc.

De igual manera, es probable que aparezcan más modelos de servicio en varias industrias. Como podemos ver en la figura 1, en el año 2020 la tendencia de inversión de las industrias apunta a diferentes formas de innovación.

¿Estamos preparados para estos cambios drásticos en los hábitos de consumo?

En realidad, el panorama no se ve bien para organizaciones con estructuras funcionales, burocráticas, jerárquicas y clásicas.

Una estructura piramidal (Fig. 2) perjudica tanto la velocidad y creatividad debido a la cantidad de niveles y procedimientos. Algunas de las razones:

A diferencia de una organización Ágil, la estructura tradicional hace que la creación de valor se vuelva dependiente, desencadenando una tensión constante entre niveles superiores e inferiores.

Diferencias entre Organizaciones Tradicionales y Ágiles

Una organización Ágil

Significa evolucionar constantemente hacia una estructura de red flexible que cumpla las expectativas del cliente.

Minimizar jerarquía y burocracia.
Creando equipos de trabajo con múltiples competencias ( ventas, marketing, desarrollo de software, etc.) enfocados en un mismo objetivo.
Crear una organización viva y flexible, capaz de responder rápidamente a los cambios del mercado y a las expectativas del cliente.

¿Vale la pena evolucionar hacia una organización Ágil?

Alcanzar la agilidad empresarial no es fácil, lo más importante es empezar a cambiar la cultura y la forma de trabajar.La solución no está en una receta lista, en un framework o metodología que se pueda implementar, sino que deben ser cambios orgánicos, adaptados a la realidad de cada empresa, lo cuál conlleva tiempo y un cambio de mentalidad a nivel organizacional, de equipos y personal. Este cambio tomará tiempo, sin embargo la recompensa se ve reflejada en un futuro inmediato.

El mundo digital favorecerá a las organizaciones que adopten el cambio rápido, brindándoles una ventaja competitiva. Por lo tanto, podemos decir que esta era estará determinada por empresas Ágiles, con un equipo y un negocio listo para responder a nuevos esquemas y mantener una ventaja competitiva en un mercado cada vez más complejo.

Lecturas recomendadas

https://publications.iadb.org/en/industria-40-fabricando-el-futuro
https://www2.deloitte.com/us/en/insights/focus/industry-4-0/industry-4-0-business-models.html
https://www.scrum.org/resources/blog/business-agility
https://www2.deloitte.com/us/en/insights/deloitte-review/issue-22/industry-4-0-technology-manufacturing-revolution.html

The post Agilidad empresarial: Abrazar el cambio o morir en el intento appeared first on Software Evolutivo.

Mejores Historias de Usuario para Scrum

Fernando Paz — Tue, 25 May 2021 03:59:11 +0000

Mejores Historias de Usuario para Scrum

Las Historias de Usuario son una herramienta muy usada en el mundo de la Agilidad, vienen de Extreme Programming y han sido adoptadas en marcos de trabajo ágiles como Scrum. Pero… ¿Cómo escribimos mejores Historias de Usuario para Scrum?.

Hay que decir primero que las Historias de Usuario no son solo para la Agilidad, sino más bien son algo que describe lo que hace un usuario en el sistema para completar una determinada tarea.

Nacieron precisamente de una carencia de los requerimientos, los requerimientos funcionales anteriormente tenían un enfoque desde el sistema. Por ejemplo:

El sistema debe permitir …

Las Historias de Usuario por otro lado sacan del contexto al sistema y expresan que necesita el usuario. Por ejemplo:

Ana como ejecutiva de cuentas requiere … para …

La gran diferencia es que el usuario nos transmite así su necesidad… desde su óptica, con libertad de expresarse, sin lenguajes restrictivos, para luego ser traducido a una perspectiva del sistema por un analista de negocios.

Para escribir mejores Historias de Usuario para Scrum, debemos regresar a ver los principios de la agilidad.

Manifiesto por el Desarrollo Ágil de Software y su conexión con las Historias de Usuario

El Manifiesto ágil nos dice: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: …”.

Individuos e interacciones sobre procesos y herramientas

Las Historias de Usuario crean un entendimiento compartido de una conversación, para los miembros del equipo, los stakeholders y los usuarios finales.

Software funcionando sobre documentación extensiva

Un solo documento de acuerdos reemplaza a mil redacción de actas.

Colaboración con el cliente sobre negociación contractual

Queremos deleitar al cliente… y una negociación contractual no es la mejor manera. La colaboración continua y fluida es clave en los productos y esto representa un Historia de Usuario.

Respuesta ante el cambio sobre seguir un plan

Es necesario tener un plan pero debe ser flexible, general y permitir reaccionar al cambio. El feedback del cliente es el único que nos marca el éxito de un Producto, más allá de cumplir funcionalidades, tiempos y presupuestos.

¿Cómo se relacionan las Historias de Usuario con los principios de la Agilidad?

La más alta prioridad es satisfacer al cliente mediante la temprana y continua entrega de software de valor, mismo valor que se expresa en la historia de usuario.
Los cambios son bienvenidos incluso si es tarde en desarrollo, y si dividimos bien las historias de usuario reducimos los impactos en desarrollo.
Entregar software frecuentemente, desde un par de semanas hasta máximo un par de meses, para esto hay que trabajar en historias pequeñas completas que realmente agreguen por si solas.
Las personas de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto, y las Historias de Usuario son por naturaleza escritas en colaboración continua y fluida.
Construir proyectos alrededor de gente motivada, darles el ambiente y soporte que necesitan, y confiar que van a realizar el trabajo, y aquí la colaboración y apropiación de la solución motiva a las personas alrededor de las conversaciones de la Historia de Usuario.
La forma más eficiente y efectiva de transmitir información hacia y dentro del equipo es una conversación cara a cara, parte de la dinámica de las Historias de Usuario.
El software funcionando es la principal medida de progreso, mismo progreso que se madura, prioriza, simplifica y entrega a través de mejores Historias de Usuario.
Un proceso ágil promueve un desarrollo sustentable, las Historias de usuario nos permite mantener un ritmo predecible de entrega de valor constante.
Poner continua atención a la excelencia técnica y un buen diseño mejora la agilidad.
Simplicidad, el arte de maximizar la cantidad de trabajo no hecho es esencial, hay que enfocarse en los resultados (valor expresado en la Historia de Usuario) y no en las salidas.
La mejor arquitectura, requerimientos y diseño emergen de equipos auto-organizados.
En intervalos regulares, el equipo reflexiona en como ser mas efectivo, luego hace ajustes en su comportamiento acorde a las conclusiones.

Escribiendo mejores Historias de Usuario para Scrum

Como se dijo anteriormente las Historias de usuario no son solo para Scrum pero es cierto que dado las dinámicas y artefactos de Scrum se pone énfasis en ciertos detalles que hacen que las mismas sean más adecuadas para implementar en los ciclos iterativos e incrementales de la propuesta Scrum.

En las siguientes secciones vamos a revisar en detalle las Historias de Usuario sus componentes, características y mejores pŕacticas.

Contenido:

Introducción a las Historias de Usuario

¿Qué son las Historias de Usuario y por qué estas son usadas?

Es una pequeña unidad para trabajar, que dice desde la perspectiva del usuario cual es la funcionalidad deseada.

Mueve el foco de escribir requerimientos a conversar sobre los requerimientos, es decir el principal objetivo es habilitar la conversación y fomentar la colaboración.

Las Historias de Usuario ponen a los usuarios finales en el centro de la conversación.

Historias de Usuario además, nos provee un contexto no técnico para el equipo de desarrollo. El equipo después de participar en una Historia de Usuario sabe porque ellos están construyendo lo que están construyendo y que valor la solución provee.

Una Historia de Usuario escrita efectivamente incrementa la colaboración, la creatividad y el producto en general.

Al escribir la Historia de Usuario debes preguntarte tres cosas básicas:

¿Quién es tu cliente?
¿Qué lo satisface? y,
¿Qué necesita?

La Historia de Usuario ayuda a entregar el más alto valor enfocándose en pequeñas y urgentes necesidades del cliente.

Cuando la necesidad del cliente es descompuesta en pequeñas funcionalidades es posible entregar valor en días o incluso en horas.

Partiendo de un enfoque de entregar el más alto valor en cada Historia de Usuario, conseguimos que:

el equipo esté empoderado
el equipo esté conectado
el equipo pueda colaborar con el usuario final.

Al enfocarse y brindar el mayor valor con cada historia de usuario, los equipos están empoderados, están conectados y pueden colaborar con el usuario final. Y cuando se conectan directamente con el usuario final, los desarrolladores tienen una oportunidad de entender realmente desde la perspectiva del usuario, sus desafíos, sus puntos de dolor, y reciben esa retroalimentación temprana con cada entrega, para que puedan asegurarse que están construyendo un producto adecuado.

Formato de una Historia de Usuario:

[who] as as

[what] I would like

[why> So that or

Siempre se expresa una Historia de Usuario desde la perspectiva del cliente “As a/an…”.

¿Quién escribe las Historia de Usuario y cuando estas son escritas?

Todos los integrantes del equipo pueden escribir Historias de Usuario sin embargo la mayoría del tiempo lo hace el Product Owner o el Analista de Negocio (Business Analyst), esto es más porque ellos están más tiempo cerca del cliente/usuario pero en realidad todo el mundo puede hacerlo.

Una de las mejores prácticas es que el equipo debe ser experto acerca del cliente y del producto por tanto estén en la capacidad de escribir Historias de Usuario. No deben necesariamente hacerlo pero deberían tener esa capacidad y además la capacidad de conversar qué es lo siguiente que viene del Product Backlog.

Por ejemplo el Product Owner y analista de Negocio escriben la primera versión del Historia de Usuario, pero luego el equipo ayuda a madurarla, mejorándola y añadiendo detalles y cosas.

¿Cuando son escritas? Pues en todo momento que llegan o surgen de conversaciones, a lo mejor en primera instancia es un borrador que se debe ir iterando con el equipo y priorizando pero lo importante es tomar nota de aquello que el usuario nos cuenta.

Hay que tomar en cuenta que una idea por si no es una Historia de Usuario, por lo que hay que tomar un tiempo para conversar y transformarla a una Historia de Usuario. Por esta razón es muy común que se manejen documentos alternativos al Product Backlog (donde ya están las Historias de Usuario) para ir desarrollando esas ideas.

Uno de esos momentos es los Demo de productos en donde hay feedback de lo que se hizo y se expresan además cosas que se esperan tener del producto. Estas conversaciones pueden llevarnos a nuevas Historias de Usuario y/o ajustes a Historias de Usuario existentes.

Otro instrumento que se suele tener en los equipos son los Talleres de Historias de Usuario (Story Workshops), que son sesiones cada cierto periodo de tiempo (2 o 3 meses) para escribir Historias de Usuario para los siguientes tres meses (al menos su versión inicial).

Hay otras sesiones importantes como el Backlog Refinement o (Grooming) en donde se crean nuevas Historias de Usuario, se descartan otras, y se estiman o se ajusta la estimación de Historias de Usuario faltantes. Incluso en estas sesiones se Divide (Splitting)” las Historias de Usuario.

3 C's para escribir historias de usuario

Las 3 C’s son las recomendaciones al escribir Historias de Usuario: Tarjeta (Card), Conversación (Conversation) y Confirmación (Confirmation).

La Historia debe ser lo suficientemente pequeña para que entre en una tarjeta y que invite a una conversación.

Hay que recordar que en un enfoque ágil de desarrollo no tienes que tenerlo todo perfectamente definido por adelantado antes de llevarlo al equipo. El equipo y el negocio realmente pueden trabajar juntos para descubrir la necesidad mientras trabajan juntos, y esto puede acordarse a través de la conversación y colaboración alrededor de las Historias de Usuario.

La tarjeta conduce a una conversación entre el Product Owner y los equipos, y esto debe suceder en persona tanto como se posible, y finalmente debe incluir una especie de confirmación.

Ese momento es cuando el equipo sabe realmente qué se debe hacer y en este momento es cuando entran los criterios de aceptación.

Diferencias entre Requerimientos y Historias de Usuario

Muchas veces las solemos intercambiar pero no son lo mismo de ninguna manera.

Existen 4 diferencias básicas:

Perspectiva:
1. El requerimiento tiene perspectiva desde el sistema o desde la solución (el sistema debe…).
2. La Historia de Usuario lo mira desde el problema descrito desde el punto de vista del cliente (como supervisor… quiero… para..).
Cuando estas son usadas:
1. Los Requerimientos tradicionales se utilizan en proyectos no ágiles, por ejemplo en metodologías en espiral o cascada.
2. Las Historias de Usuario se usan en proyectos ágiles mayormente.
Cómo son obtenidas/definidas:
1. Para los requerimientos tradicionales los Analistas de Negocio usan técnicas como entrevistas, encuestas u otras que extraigan respuestas en reacción a las acciones o preguntas, para luego documentarlas en los instrumentos que usen en la organización (ejemplo un BRD – Business Requirement document). Suele ser una actividad única, el Analista de Negocio obtiene las respuestas las documenta y cambia a la siguiente cosa
2. En Agil la Historia de Usuario es una discusión y un esfuerzo colaborativo. La manera en que son escritas ayudan a empujar una conversación, terminando en cosas como porque la necesitan realmente?, cuales son los detalles?, que sabemos y que no sabemos? cuales son los matices que la componen?. Esto es un trabajo de salida constante de información y de conversaciones constantes que aseguran que se consideren todas esas pequeñas piezas desde la perspectiva del usuario.
Quien es el dueño:
1. Los requerimientos tradicionales normalmente pertenecen a quien lo escribió, dado que lo hizo en su lenguaje y en su entendimiento y más allá de eso lo hizo desde la perspectiva de sistema o solución, lo que los hace confusos si no entiendes el contexto desde donde fue escrito. Generalmente el analista de Negocio es el dueño de esos requerimientos con su estructura y normalmente esto implica que se “deba” explicar el documento a otros lectores y de como hacer cambios en el mismo, sintaxis, etc.
2. En enfoque Ágil, el dueño es el Grupo ya que se escribió en grupo con muchas conversaciones y desde la perspectiva del usuario con lenguaje natural y propio del problema. Todos sienten su piel en el juego y que han ayudado a desarrollar esa Historia de Usuario.

Diferencias entre Casos de Uso y Historias de Usuario

Ambas describen una misma meta pero tiene diferentes propósitos: los Historias de Usuario son acerca de necesidades, mientras que los Casos de Uso ayudan a explicar el comportamiento que el sistema debe tener para ser exitoso.

Las Historias de Usuario son realmente pequeñas y concisas, su alcance es muy delgado y específico, en cambio las Casos de Uso describen las interacciones de todo el sistema y a veces con otros sistemas.

Roles de Usuario

Cuando escribes Historias de Usuario tu vas a querer conocer a los usuarios de esas Historias de Usuario, saber qué rol cumplen, como operan, etc.

Al tener esta información sueles tener muchos roles y no tiene sentido y se vuelve inmanejable describir a cada uno en una historia de usuario.

Se recomienda crear grupos de usuarios/roles sobre los cuales discutir las características a implementar.

Según Scrum Alliance los Roles de Usuario son usuarios que comparten:

necesidades comunes
intereses
expectativas
comportamientos

Son entonces una manera de pensar en ciertos usuarios y conversar sobre ellos porque comparten cosas.

Aquí la recomendación siempre será hacer una lluvia de ideas de todos los roles y refinar esta lista y agruparla según los criterios de Roles de Usuarios de Scrum Alliance por ejemplo. Esto podría ser parte de la Incepción Ágil.

Personas

Una vez que tengas los roles puedes crear los “Personas”, de forma que pueda visualizar mejor esa clase de persona:

Persona, es una representación ficticia del usuario, es como la figura Persona que se usa por ejemplo en procesos Customer Journey Map.

Más de las Historias de Usuario

Ojo que las Historias de Usuario son como un punto de partida en donde puedes tener dentro cosas como documentos de respaldo, wireframes, maquetas de UI, diagramas de flujo, y una serie de estas representaciones visuales de requisitos.
- Es importante esto porque a menudo significan un entendimiento común para todos los stakeholders así que no subestimes esta parte.
No asumas que una Historia de Usuario tiene una funcionalidad implícita, esto por ejemplo en el caso de una Historia de Usuario que habla de crear registros, a menudo se suele omitir la actualización de esa información, pero esto puede causar problemas ya que la actualización puede implicar por ejemplo connotaciones de recálculo de otros valores, o reprogramación de otras actividades.
- Es importante ser explícito en las funcionalidades para describir que una Historia de Usuario incluye el CRUD completo o que hay otras Historias de Usuario que especifican tal feature.
Otro detalle importante es el “Porqué?”, ya que nos da el contexto del valor que representa la Historia de Usuario para el cliente y el negocio, y, nos ayuda a priorizarla en el Backlog.
- A menudo las Historias de Usuario quedan mal documentadas y no proveen los suficientes detalles, no para estimarlas, pero si para entenderlas tanto que el “que busca”, así como el “porqué es importante” ya que es probable que después de un tiempo al regresar a retomar una conversación no podamos identificar realmente lo que quisimos expresar.
Hay veces que una Historia de Usuario involucra una funcionalidad compartida entre dos o más roles. Por ejemplo dar de alta a un usuario, esta funcionalidad involucra crear un usuario en el sistema, que lo puede hacer el mismo usuario que desea darse de alta o un administrador de usuarios; sin embargo aunque las pantallas e input son similares no tienen los mismos detalles y accesos por lo que está bien y es correcto tener dos o más Historias de Usuario que representen cada caso con sus particularidades aunque cierta funcionalidad podría ser implementada por la otra Historia de Usuario.

Criterios de Aceptación

Entendiendo los Criterio de Aceptación

La Historia de Usuario no provee suficientes detalles por sí sola para que alguien pueda tomarla y crear algún tipo de solución.

Es por eso que tenemos los criterios de aceptación, que son una serie de condiciones que un producto debe cumplir para ser aceptado por un usuario, un cliente o otro sistema.

Provee estándares y requerimientos que el resultado final debe cumplir para ser exitoso.

Hay cuatro beneficios principales de los criterios de aceptación:

Crea un entendimiento común: provee detalles necesarios en una solución como criterio compartido por los stakeholders.
Define el alcance: le dice a los creadores de la solución dónde empezar y dónde terminar, y que es lo importante.
Valida que una Historia de Usuario está completada: provee un checklist o condiciones que al ser alcanzadas nos indican que finalizó de una forma certera.
Muestra que probar y si pasa la prueba la solución entregada.

Normalmente obtenemos esos detalles faltantes para figurar una solución a través de preguntas poderosas como por ejemplo:

Cuál es la información más relevante a mostrar?
Cómo se va a obtener esa información?
A qué se refiere tal o cual término mencionado?
Quién puede obtener esa información?,
etc.

Su definición pasa por un proceso evolutivo en donde las preguntas fluyen conforme varias conversaciones suceden.

Escribiendo un Criterio de Aceptación

Hay varias formas de escribir los criterios de aceptación entre los cuales mencionamos las siguientes:

Checklist Format, listando esos detalles que hacer la solución exitosa.
Given-(And)-When-Then-(And) que es otro enfoque especialmente usado en pruebas BDD (Behavior Driven Development).

¿Quién escribe los Criterios de Aceptación y cuando son escritos?

El Product Owner generalmente escribe la Historia de Usuario inicial y luego suele recaer la responsabilidad de escribir los criterios de aceptación en el Analista de Negocios, en donde él aplica todo su expertise de análisis de negocios y elicitación (traspaso de información de forma fluida de un ser humano a otro por medio del lenguaje) para el fin.

Aquí el Analista de Negocios suele usar muchas cosas como entrevistas, sesiones de brainstorming, talleres, etc. de forma que pueda documentar con precisión los criterios de aceptación.

Normalmente al crear una Historia de Usuario no se escriben los criterios de aceptación, y la misma se va a iterando en conversaciones en el tiempo. La idea es que la Historia de Usuario esté en un punto sólido de forma que el Analista de Negocios pueda en ese momento trabajar en los criterios de aceptación.

Ninguna Historia de Usuario debería entrar en el Sprint Backlog si la misma no tiene criterios de aceptación.

Mejores prácticas para los Criterios de Aceptación

Escríbelos en texto simple, evita tecnicismos y modismos de forma que sea legible por todos los integrantes del equipo.
Explica la intención no la solución que se necesita.
Mantenlos medibles evita puntos grises, es decir, debe haber criterios blanco o negro porque el gris es sujeto a quien lo usa y como lo usa.
Listas extensas de criterios de aceptación son aceptables, luego preocúpate de dividir la Historia de Usuario; esto, al mismo tiempo significa para los stakeholders interiorizar cuan complejo puede ser la solución y entender que se requiere dividir dicha Historia de Usuario para poder cumplirla en un Sprint.

Escribir mejores Historias de Usuario con INVEST

¿Qué es INVEST?

Una buena práctica al escribir Historias de Usuario es chequearlas con el criterio INVEST.

INVEST significa:

Independiente: la idea es ver si hay dependencias con otras Historias de Usuario ya que puede resultar en problemas de planificación. Incluso afecta a la prioridad ya que una dependencia puede tener baja prioridad pero bloquea una de alta prioridad.
Negociable: la idea es que no es un contrato sino una invitación a una conversación en donde se acuerdan los detalles, los tiempos y los criterios de aceptación entre todo el equipo.
Valiosa: el valor de esa historia debe estar realmente claro para todo el equipo, no solo desde la perspectiva del cliente sino en términos de negocio, y como todas estas Historias de Usuario trazan el camino a los metas del negocio.
Estimable: debe tener los detalles suficientes para que el equipo las pueda estimar, no todos los detalles pero si lo relevante a la Historia.
Pequeña (Small): si la Historia no puede ser completada en un Sprint es muy grande y debería ser dividida, de igual forma si no es necesario hacer una Historia más pequeña pues evite hacerlo ya que al dividirla puede quedar la sensación de trabajo incompleto en un todo.
- Por ejemplo separar un CRUD no tiene mucho sentido a menos que haya algo específico que cause una acción en particular.
Comprobable (Testable): de modo que podamos decir que la implementación está finalizada correctamente.

Más del criterio INVEST

Una de las cosas más importante de una Historia de Usuario es mantenerla negociable, es decir que se permita cambios en la misma. Recuerda que no es un BRD, esto especialmente si hablamos de un ambiente ágil, no tiene sentido hacer algo que nadie quiere por cumplir un BDR.
Otra cosa muy importante es siempre cuestionar si aporta valor, ya que muchas historias parecen aportar valor pero no es relevante frente a las prioridades funcionales y los objetivos de negocio por lo que no debería ser implementada.
Mantenerlas pequeñas por otro lado es crucial porque pueden liberarse al uso rápidamente y retornar la inversión al negocio.
Recuerda que INVEST es una guía y no son reglas estrictas así que hay que tomarlas en cuenta para construir nuestro Backlog pero no tratar de forzar todas las ideas.

Non-Historias de Usuario

Entendiendo los Spikes

Hay aspectos en la solución que no se relacionan al negocio en sí, como por ejemplo la arquitectura, que de acuerdo a los principios de Scrum debe evolucionar según sigue el desarrollo o la implementación del producto. Esto significa que no toda la infraestructura como toda la arquitectura debe estar prediseñada antes de arrancar el Producto.

Spike es una investigación de un conocimiento o incluso la producción de un nuevo conocimiento que da una respuesta para la solución de algo en el Backlog.

Los Spikes son usados para responder a estos retos técnicos e incluso a problemas de diseño.

El resultado de un Spike puede derivar en una nueva Historia de Usuario o una actualización a una existente.

Una de las razones por las que los Spikes pueden ser usados es la investigación, cuando una Historia de Usuario es muy grande para ser estimada, así se analiza el comportamiento esperado, se divide la Historia en otras más pequeñas y se reduce significativamente el riesgo y la incertidumbre en una story.

Recuerda que no por estar en un enfoque ágil vas a dejar de necesitar analizar ciertos aspectos técnicos, de diseño o incertidumbres.

Debes ser documentados como cualquier Historia de Usuario (pero no son Historias de Usuario realmente), deben tener criterios de aceptación para saber qué preguntas tiene que responder o qué preocupaciones tiene que aclarar, y así mismo ir al Backlog ser priorizado y eventualmente incluido en un Sprint Backlog.

La diferencia principal es que en lugar de generar valor para el negocio debe responder preguntas al equipo, preguntas como:

Es esto factible?
Podemos hacer eso con nuestra actual tecnología?
Es esta la mejor opción o hay otras que deberíamos considerar para entregar la misma característica/valor?
Cuáles son los riesgos de tomar cierto camino?

Entendiendo las Historias de Usuario Técnicas y de Infraestructura.

Hay necesidades en la implementación de un producto que no tiene que ver con sus usuarios o el negocio, sino que son necesidades para poder crear el mismo Producto, esto incluye por ejemplo:

Implementación de herramientas de testing.
Implementación de automatizaciones de despliegues.
Implementación de servidores.
Implementación de esquemas de seguridad externos, etc.

Estas Historias de Usuario de Infraestructura o Técnicas tiene el mismo tratamiento que las de negocio e igualmente con criterios de aceptación, adicionadas al Backlog, priorizadas y eventualmente incluidas en un Sprint.

La parte “como … “ (as a …) en la Historia de Usuario es confusa en esta clase de Historias pero a menudo el usuario que requiere dicha feature es el programador, el arquitecto, o incluso el equipo de desarrollo.

Estimando Historias de Usuario

Conceptos Generales de Estimación

En la metodologías tradicionales como cascada las estimaciones son absolutas y van en métricas como horas o días.

En proyectos ágiles son muy importantes las estimaciones pero tienen una diferencia… en los proyectos ágiles las estimaciones no son absolutas sino relativas. Estas estimaciones son producto de comparar tareas unas con otras y así poderlas agrupar según el grupo la complejidad en la que cada una se ubique.

Una métrica bastante conocida es la T-shirt technique (tallas de camiseta) con medidas como pequeña, mediana o grande. Esto nos permite ubicar en un determinado conjunto a tareas que son parecidas unas con otras.

Otra técnica es la serie de Fibonacci que permite una una estimación relativa con un número que determina la complejidad.

Entendiendo la técnica de estimación Fibonacci

Aquí los valores de la serie de Fibonacci representan el tamaño de la Historia de Usuario

Cada Historia de Usuario es comparada con otras y se les asigna un número de la serie de Fibonacci que representa el tamaño más adecuadamente. Este número asignado es conocido como “Puntos de Historia” (Story Points).

Cuando nos encontramos con Historias de Usuario con asignación mayor a 8 como tamaño deberíamos dividirla antes de pasarla a un Sprint Backlog.

En una iteración (Sprint) se implementa un número determinado de “Puntos de Historia” por parte del equipo y el promedio de este número en varias iteraciones viene a ser la velocidad del equipo.

Obviamente al principio, es decir en las primeras iteraciones, la velocidad del equipo no la vamos a tener porque va a depender del desempeño del mismo en el tiempo.

Las Historias de Usuario Épicas

Suele haber casos en que una Historia de Usuario es tan grande o compleja que no se puede estimar tan solo como una definición de “Grande” o con un número Fibonacci como 13, 21, 55 o superior, en este caso es mejor no estimarla y nombrarla como épica (Epic)

Epica marca a un Historia de Usuario, como una conversación pendiente acerca de un análisis más profundo de su complejidad, fases y partes para llegar a una definición derivada de 3, 4 o muchas más Historias de Usuario que permitan su implementación.

Dividiendo las Historias de Usuario

Introducción al concepto de División (Splitting)

A menudo los equipos deben trabajar con Historias de Usuario grandes y muy grandes que no se pueden terminar en una iteración, aquí es cuando es necesario dividir esa gran Historia de Usuario en varias más pequeñas de forma que sea posible implementarlas en una iteración y que por supuesto traten de estar lo más cercano a los principio INVEST.

¿Por qué dividir la Historias de Usuario?

Una de las ventajas principales de dividir una Historia de Usuario es que las Historias de Usuario resultantes explican de mejor manera el todo y a menudo se las puede priorizar y evaluar en cuanto a qué valor aporta, así es probable que muchas de estas pierdan prioridad en el todo o no se las deba implementar realmente.

Al final esta actividad deriva en optimizar y enfocar el esfuerzo en el 20% del trabajo que tiene una alta aportación de valor, y, asignar una priorización más baja a esas stories que no aportan tanto.

La otra gran razón, como ya lo mencionamos, es que una Historia grande no se puede implementar en una iteración (1 o 2 semanas), y dividirla permite implementar parte de ella con un valor determinado en una iteración.

La idea es: algunas historias de Usuario implementadas es mejor que ninguna Historia de Usuario implementada.

La última razón más importante es que una estimación de una Historia de Usuario grande a menudo es errónea ya que no se entiende la complejidad o tamaño de la misma. Dividirla ayuda al equipo a clarificar algunos detalles que son importantes para tener una estimación real del esfuerzo, y así no dar falsas promesas.

Tener divididas las Historias de Usuario también ayuda a que estas sean testeables, y se evidencia con el cómo testear las mismas por ejemplo en ambientes e2e, ambientes mock y/o prueba unitarias solamente.

Dividiendo con simplicidad

Hazlo simple al principio y luego empieza con variaciones.

La idea es que uses primero opciones simples respecto a una solución, y luego las complejas.

Las opciones más complejas puedes escribirlas en las siguientes iteraciones pero al principio mantenlo simple.

Por ejemplo:

Historia de Usuario A: como comprador quiero poder hacer transferencias bancarias entonces puedo cancelar mi pedido.

Dividiéndola:

Historia de Usuario A-1: como comprador quiero poder hacer transferencias bancarias manuales entonces puedo cancelar mi pedido.
Historia de Usuario A-2: como comprador quiero poder hacer transferencias bancarias a través de un link de pagos de mi banco entonces puedo cancelar mi pedido.
Historia de Usuario A-3: como comprador quiero poder hacer transferencias bancarias conectando automáticamente a mi banco entonces puedo cancelar mi pedido.

Dividiendo con un Workflow

Las Historias de Usuario grandes a menudo están compuesta de pasos para ser implementadas.

Por ejemplo una Historia de Usuario como “Comprar en la Tienda en línea” involucra cosas como:

Buscar productos,
Comparar productos,
Seleccionar forma de pago,
Crear una cuenta,
Especificar dirección de entrega, etc.

Cada uno de estos pasos son en sí una Historia de Usuario por lo que una forma de muy evidente de dividir Historias de Usuario es discutir en el proceso que envuelve su cumplimiento.

Dividiendo con CRUD (Crear, Leer, Actualizar y Borrar)

Se puede dividir una Historia de Usuario pensando en las operaciones normales del registro de información: crear, leer, actualizar y borrar.

Tiene sentido si alguna de estas operaciones tiene una complejidad particular y/o son usadas por diferentes roles.

En la mayoría de casos un CRUD es una sola Historia de Usuario aunque operaciones relacionadas como búsquedas, reportes o clasificaciones pueden resultar en otras Historias de Usuario.

Dividiendo por el Método de Ingreso

Hay Historias de Usuario que involucran una entrada de información y esta entrada se puede hacer por varios canales.

Un ejemplo es la función de “añadir fotos en Word”, se puede hacer subiendo las fotos del sistema de archivos, se puede hacer referenciando a un URL, se puede hacer usando un servicio como Pexels, etc. Cada una de estos métodos de ingreso representa una Historia de Usuario en particular y forman parte de una Historia de Usuario más grande que es “añadir fotos en Word”.

Dividiendo con Spikes

Considera una Historia de Usuario en donde necesitas hacer una investigación previa de las alternativas de implementar una solución, es decir un Spike.

Por ejemplo: quieres “pagar con la integración a un Gateway de pagos”, pero no sabes cómo se integra y que necesitas.

En este caso parte de la Historia de Usuario, es esta investigación y debe ir como una Historia de Usuario, la idea es que esa Historia esté planteada con criterios de aceptación de manera que clarifiquen esas dudas que necesitan respuesta antes de la implementación de la funcionalidad.

Ojo debe hacerse un en la investigación porque de lo contrario es muy fácil entusiasmarse en más y más investigación de alternativas y dilatar los objetivos de la Historia de Usuario.

Más acerca de Dividir las Historias de Usuario

No trates de agrandar una iteración para lograr implementar una Historia de Usuario.
No dividas las Historias de Usuario en fases: diseño, desarrollo y testing.
No partas con la mentalidad fija que una Historia de Usuario no se puede dividir, a menudo tener la mente abierta y pensar y hacer preguntas, te llevan a técnicas con las cuales llegas a dividir esa Historia de Usuario.

Retos Comunes al gestionar las Historias de Usuario

Proporcionando el Quién y el Porqué?

No olvides que especificar con precisión quién necesita la funcionalidad en una Historia de Usuario es útil para el enfoque de la solución, el equipo así sabrá quien es esa persona y cuál es su comportamiento normal.

Poner algo como “Como Usuario…” es decir genérico no ayuda al entendimiento de la necesidad.

El “Porqué” en la Historia de Usuario es extremadamente fundamental, y a veces olvidamos describirlo o detallarlo con precisión.

El “Porqué” da el contexto de la necesidad y suele llevar a preguntas adicionales que clarifican la solución.

Manejando defectos y bugs

Es normal que aparezcan de cuando en cuando defectos o mal funcionamientos en el Software, pues se considera que estos al final son parte de la solución o de la creación de la solución.

Muchos equipos tratan de resolver mágicamente estos problemas encontrando tiempo al parecer de la nada, pero hay que recordar que el equipo tiene ya una carga de trabajo asociada a las Historias de Usuario que se hayan comprometido entregar en la iteración que transcurren en ese momento.

Este enfoque es frecuentemente erróneo ya que no terminan de completar las Historias objetivo del Sprint, afectando a su velocidad y expectativas del cliente. La mejor forma es documentar estas incidencias como cualquier otra Historia de Usuario de forma que nos lleve a una conversación, a su estimación y a una definición de criterios de aceptación que expliquen cuando esta incidencia ha sido superada, y, que de igual forma se priorice en el Backlog.

Hay que recordar que hay varios tipos de incidencias, unas que a lo mejor son inhabilitantes o otras que son de forma que no tienen porque ser resueltas de manera urgente.

Lidiando con las dependencias

La mejor forma de lidiar con las dependencias es no tenerlas, y esto en un primer momento es usar prácticas o guías como INVEST que ya la conversamos anteriormente. Aquí el principio de INDEPENDENCIA es un control sobre la definición de una Historia de Usuario que marca que la misma está lista para incluirla en una iteración (Sprint Backlog).

El típico ejemplo es una story que añade funcionalidad o complementa a otra story; aquí evidentemente la story a ser modificada debe existir antes y haber sido implementada en una anterior iteración, pues si las planificamos ambas en una misma iteración vamos a tener un inevitable tiempo muerto para el equipo y por consiguiente un desperdicio de su velocidad.

Combinando Historias de Usuario

Al encontrarnos con Historias de Usuario que son dependientes podemos intentar re-enfocar las mismas de forma que esa o esas dependencias se eliminen. La práctica aquí es combinar las Historias y crear una sola gran Historia de Usuario y a partir de ella pensar en otras formas de dividirla, como por ejemplo encontrar hacerla en fases y no por segmentos de funcionalidad.

Intercambiando algunos de esos requisitos

La idea es que si tenemos dependencias entre Historias de Usuario, podemos identificar esos detalles que componen la dependencia y moverlos de una story a otra de forma que lleguen a un punto que sean independientes.

No hacer nada

Hay veces que estas dependencias no se pueden disolver, incluso aplicando los anteriores métodos.

En estos casos monitorear estas Historias de Usuario es clave para asegurar que su implementación no esté causando problemas al negocio mientras se implementan las Historias dependientes.

Cambiando las Historias de Usuario en medio de un Sprint

Hay que diferenciar el Product Backlog con el Sprint Backlog, ambas contienen Historias de Usuario pero el Sprint Backlog tiene solo aquellas Historia de Usuario priorizadas, estimadas, verificadas (con INVEST por ejemplo) y acordadas con los Stakeholders, antes de iniciar una iteración.

Una iteración (Sprint), normalmente de 2 semanas, tiene como base de trabajo estas Historias de Usuario que han pasado por un proceso y que son el compromiso del equipo. No tiene que y no debe incluirse otras stories una vez comenzada la iteración pues esto genera varios problemas al equipo como por ejemplo: afecta a su velocidad ya que existe más trabajo, afecta a la solución pues no se ha conversado los detalles previamente y afecta la planificación comprometida a los stakeholders.

Si hay una necesidad urgente de una Historia de Usuario esta debe pasar por su proceso de maduración y ser priorizada en el Product Backlog para luego ser incluida, tras el descubrimiento de detalles e implicaciones, en el Sprint Backlog.

El Sprint es un compromiso de trabajo del equipo con los stakeholders.

Retos usando estimación Ágil

Mentalidad relativa a horas

Hay que apoyar a los miembros del equipo que piensa aún en términos de horas (pues sabemos que están acostumbrados a esa referencia), y hacerlos estimar comparando esfuerzo de una story a otra.

Recuerden que la estimación se hace al tener los detalles suficientes sobre la Historia de Usuario, es decir deben haberse ejecutado esas conversaciones que la definen antes, así como tener esos criterios de aceptación.

Comparación de estimaciones entre proyectos o equipos

La estimación en agilidad es relativa a la comparación de stories, al contexto del proyecto y a la base que se haya tomado como métrica.

Por tanto, una estimación en “Puntos de historia” de una misma Historia de Usuario es diferente entre equipos pues su base o perspectiva es acordada en sus conversaciones. 21 Puntos de Historia como velocidad del equipo A puede significar más entrega de valor (funcionalidades) del Producto que 50 Puntos de Historia de velocidad del equipo B en el mismo Producto.

Incluso la velocidad de un mismo equipo puede ser diferente entre implementación de productos ya que son otros los puntos de vista y conversaciones que se acordaron en ese Producto en el equipo.

No es sano y no agrega valor comparar velocidades en ningún caso pero las estimaciones son relativas en proyectos ágiles.

Pensamientos Finales

Las Historias de Usuario son una herramienta muy utilizada en el mundo de la Agilidad, que viene en sus inicios desde el marco de trabajo “Extreme Programming (XP)“, y que ha sido adoptada por varios otros marcos como Scrum.

La idea principal es recordar que la misma provoca varias conversaciones acerca de la necesidad del cliente y se robustece en el tiempo con otra información como diagramás, flujos, documentos, etc. que maduran la necesidad y sirven como datos para una solución efectiva.

Al final esta Historia de Usuario derivará en otras más pequeñas, hasta que tengamos una Historia de Usuario de un tamaño que puede implementarse en un Sprint.

La habilidad de escribir mejores Historías de Usuario para Scrum u otro framework es un conjunto de pasos y técnicas que se interiorizan en el tiempo por el equipo y que al final les permite crear funcionalidades de valor y con entendimiento común.

Esperamos que esta guía robusta de Historías de Usuario les ayude a mejorar esta habilidad y poder entregar cada vez mejor valor a su cliente.

The post Mejores Historias de Usuario para Scrum appeared first on Software Evolutivo.

Live – Share, colaboración del equipo en tiempo real

Johannes Caranqui — Thu, 06 Aug 2020 16:41:35 +0000

Live Share es un plugin o extensión de Visual Studio Code que permite a su equipo colaborar rápidamente en la misma base de código sin la necesidad de sincronizar el código o configurar las mismas herramientas de desarrollo, configuraciones o entorno.

Cuando comparte una sesión de colaboración, su compañero de equipo ve el contexto del espacio de trabajo en su editor. Esto significa que su compañero de equipo puede leer el código que compartió sin tener que clonar un repositorio o instalar cualquier dependencia en la que se base su código.

Pueden usar funciones de lenguaje enriquecido para navegar dentro del código; no solo abre otros archivos como texto, sino que usa la navegación basada en análisis semántico como Ir a definición o Peek.

Es necesario previamente contar con el editor de texto Visual Studio Code:

https://code.visualstudio.com/download

Paso 1:

Descargar la extensión

El primer paso es instalarlo como una extensión, en la pestaña extensiones, buscar “Live Share”, clic en instalar y volver a cargar Visual Studio Code cuando finalice la instalación.

Paso 2:

Compartir y unirse a una sesión

Una vez que haya iniciado sesión, estará listo para crear una sesión para compartir con otros. Asegúrese de compartir solo sesiones en vivo con personas de su confianza. Como verá, otorgará a los usuarios cierto acceso que puede ser perjudicial si se usa incorrectamente.

Comience haciendo clic en su nombre de usuario en la barra de estado inferior y elija Iniciar sesión de colaboración entre las opciones disponibles. Alternativamente, puede abrir la Paleta de comandos y escribir “Start Collaboration Session”

Se le notificará que su enlace de invitación se ha copiado en el portapapeles.

Comparta este enlace con alguien para invitarlo a su sesión.

Desde el punto de vista del invitado, para aceptar una invitación, haga clic en su nombre de usuario en la barra de estado inferior y elija unirse a la sesión de colaboración.

Alternativamente, como arriba, puede abrir la Paleta de comandos y escribir “Join Collaborative Session”.

Cuando se le solicite, ingrese el enlace de sesión de colaboración que le envió el anfitrión .

El anfitrión será notificado cuando alguien se una a la sesión.

Por defecto, unirse a una sesión automáticamente hará que el invitado siga al anfitrión mientras navega por el código. Esto sucederá hasta que el invitado haga un movimiento por sí mismo.

A partir de ahí, ambos lados son libres de navegar y editar como mejor les parezca. Además, ambos lados verán un marcador que muestra dónde está el otro editor como se muestra aquí.

También puede seleccionar un fragmento de código para que se resalte en la computadora del otro usuario. Puede usar esto para llamar su atención a una sección de código, por ejemplo.

Paso 3:

Compartir un servidor

Puede ser un desafío compartir con otros cuando se trabaja en una aplicación localmente. Puede verificar el código en GitHub y hacer que la otra persona clone, pero aún así tienen que instalar dependencias e iniciar el servidor ellos mismos. Con Live Share se puede iniciar el servidor localmente y la otra persona puede obtener acceso a la misma aplicación en ejecución.

Como anfitrión , inicie su servidor normalmente. Luego, haga clic en el nombre de usuario en la barra de estado inferior y elija Compartir servidor . Alternativamente, abra la Paleta de comandos y escriba “Share Server”.

Como invitado , puede navegar hasta localhost el puerto adecuado para ver el servidor.

Paso 5:

Compartir una terminal

Puede haber un escenario en el que le gustaría enseñarle a alguien comandos en la terminal, como cómo navegar por el sistema de archivos, trabajar con npm, iniciar su servidor de desarrollo, etc. Al igual que con las características anteriores, esto puede ser complicado de hacer de forma remota. Live Share también incluye una función para compartir terminales para resolver este problema.

Compartir un terminal es similar a compartir su servidor. Similar a las otras funciones, seleccione la opción “Shared Terminal”. Después de eso, elija entre read only o read/write para colaboradores.

Una vez que se haya compartido el terminal, los colaboradores podrán ver (y editar, si corresponde) la terminal.

The post Live – Share, colaboración del equipo en tiempo real appeared first on Software Evolutivo.

Coding Dojo, el arte de la invención en equipo

Johannes Caranqui — Thu, 06 Aug 2020 15:59:07 +0000

¿Qué es un Coding Dojo?

Un Coding Dojo es una sesión de programación basada en un desafío simple de codificación. Los programadores de diferentes niveles de habilidad están invitados a participar como iguales en la práctica deliberada.

¿Por qué hacer un Coding Dojo?

Se ha descubierto que expertos en diferentes áreas, cuyas habilidades exceden las del promedio tienen algo en común: Practican en promedio la misma cantidad todos los días, incluidos los fines de semana, durante un período de al menos 10 años.

Es decir: Existe un vínculo intrínseco entre la práctica deliberada y los altos niveles de habilidad.

Entonces ¿Cómo desarrollamos nuestras habilidades de programación? ¡En efecto! Con práctica deliberada. Adquirir habilidades de codificación debe ser un proceso continuo.

¿Puedo practicar solo?

¡Claro que sí! Dave Thomas, escritor del libro The Pragmatic Programmer aprovechó esta idea y sugirió que los programadores deberían practicar pequeños problemas fuera de su trabajo regularmente, repitiendo el mismo problema para aprender de los errores anteriores. Para alentar a las personas a practicar, publicó una serie de Code Katas que puedes encontrar en su sitio web. La palabra Kata proviene de las artes marciales y es una práctica de repetir un pequeño movimiento repetidamente para perfeccionarlo.

¿Por qué participar en un Coding Dojo?

Una de las limitaciones con el Code Kata es que cuando completas una tarea por tu cuenta, no recibes ningún comentario. Un importante estímulo positivo que se encuentra en la investigación sobre la práctica deliberada muestra que tener un maestro en el oficio disponible para usted mientras aprende es crucial.

Un Coding Dojo brinda esta oportunidad de aprender, enseñar y mejorar con otros desarrolladores de software en un ambiente:

No competitivo, sino colaborativo y divertido
Donde todos los niveles de habilidad son bienvenidos
Seguro para probar nuevas ideas

Tipos de reuniones

Existe varios tipos de reuniones, incluso, se sigue implementando mediante la combinación de las ya conocidas, entre las principales tenemos:

Kata preparada

Un presentador muestra cómo resolver el desafío desde cero, utilizando TDD y Baby steps (lo más pequeño y simple posible).
Cada paso debe tener sentido para todos los participantes.
Las personas podrían interrumpir solo si no entienden lo que está sucediendo.

Randori Kata

El desafío se resuelve con el par de codificación (controlador y copiloto).
Todos los presentes están invitados a intervenir.
Cada par tiene un intervalo de tiempo pequeño (5 o 7 minutos según sea la necesidad) para avanzar usando TDD y Baby Steps (lo más pequeño y simple posible).
Al final del tiempo, el conductor vuelve a la audiencia, el copiloto se convierte en conductor y uno de los asistentes se convierte en copiloto.

En el Dojo, lo más importante es divertirse y aprender, cada quien es libre para crear y mejorar parte del código, todos ganan, nadie pierde. Recuerda, en el equipo hay personas que dominan mejor un tema, mediante estas prácticas todos aprenden por igual.

The post Coding Dojo, el arte de la invención en equipo appeared first on Software Evolutivo.

Agilidad Archives - Software Evolutivo

Colaboración en equipos tecnológicos: Integrando el Corazón de la Agilidad

La Suma es Mayor que la Suma de las Partes

La colaboración multiplica las capacidades del equipo

Diversidad de pensamiento

Ampliación de visión

Mayor Eficiencia

Agilidad: Un Corazón Colaborativo

Preguntas para mejorar la colaboración

Liderazgo en todos los niveles: ¿Quién Debería Impulsar la Colaboración en el Equipo?

1. Líderes de Equipo y Gerentes

2. Facilitadores de Reuniones y Coaches Ágiles

3. Miembros del Equipo

4. Consultores Externos

¿Cómo fomentamos la colaboración en Software Evolutivo?

Conclusiones

¿Buscas mayor agilidad y eficiencia?

Automatiza y moderniza tus sistemas con nuestras soluciones en automatización y modernización de aplicaciones.

Lego Scrum en Software Evolutivo: ¿Realmente la rutina mata el amor por Agile?

1. El Desarrollo del Lego Scrum: Personas y proyectos

2. Planeación y Estimación

3. Sprint y Construcción

4. Revisión y Retrospectiva

5. Lecciones aprendidas

6. Conclusión

¿QUIERES SER ÁGIL?

¡Descubre cómo los frameworks agile maximizan la entrega de valor al cliente!

Scrum: El rol del Product Owner

¿La Agilidad puede ayudar a mi organización?

Amenaza competitiva

Voluntad de experimentar

Incertidumbre de la solución

Descentralización de decisiones

Potencial de crecimiento

Mob Programming, colaboración en equipo

Kata Juego de la Vida

Descripción del problema

Pistas

Visualiza tus casos de prueba

Casos de prueba sugeridos

Agilidad empresarial: Abrazar el cambio o morir en el intento

Agilidad empresarial

¿Estamos preparados para estos cambios drásticos en los hábitos de consumo?

Diferencias entre Organizaciones Tradicionales y Ágiles

Una organización Ágil

¿Vale la pena evolucionar hacia una organización Ágil?

Lecturas recomendadas

Mejores Historias de Usuario para Scrum

Mejores Historias de Usuario para Scrum

Manifiesto por el Desarrollo Ágil de Software y su conexión con las Historias de Usuario

¿Cómo se relacionan las Historias de Usuario con los principios de la Agilidad?

Escribiendo mejores Historias de Usuario para Scrum

Introducción a las Historias de Usuario

¿Qué son las Historias de Usuario y por qué estas son usadas?

¿Quién escribe las Historia de Usuario y cuando estas son escritas?

3 C's para escribir historias de usuario

Diferencias entre Requerimientos y Historias de Usuario

Diferencias entre Casos de Uso y Historias de Usuario

Roles de Usuario

Personas

Más de las Historias de Usuario

Criterios de Aceptación

Entendiendo los Criterio de Aceptación

Escribiendo un Criterio de Aceptación

¿Quién escribe los Criterios de Aceptación y cuando son escritos?

Mejores prácticas para los Criterios de Aceptación

Escribir mejores Historias de Usuario con INVEST

¿Qué es INVEST?

Más del criterio INVEST

Non-Historias de Usuario

Entendiendo los Spikes

Entendiendo las Historias de Usuario Técnicas y de Infraestructura.

Estimando Historias de Usuario

Conceptos Generales de Estimación

Entendiendo la técnica de estimación Fibonacci

Las Historias de Usuario Épicas

Dividiendo las Historias de Usuario

Introducción al concepto de División (Splitting)

¿Por qué dividir la Historias de Usuario?

Dividiendo con simplicidad