Tomado de:
Mostrando las entradas con la etiqueta inception. Mostrar todas las entradas
Mostrando las entradas con la etiqueta inception. Mostrar todas las entradas
martes, abril 26, 2022
miércoles, abril 06, 2022
¿Cuándo podríamos estimar una historia de usuario con mejor certeza? La matriz de Stacey, una técnica a usar en el Refinamiento
Hola a todos
La matriz desarrollada por Ralph Stacey, conocida como la Matriz de Stacey, permite entender cuando de acuerdo con los ejes de Requerimientos y Tecnología, podemos tener una aproximación de gestión simple, complicada, compleja;
 |
| Matriz de Stacey. Tomado de (1) |
y dados estos escenarios, se ha usado en los últimos años, para justificar en que escenarios trabajar con métodos tradicionales y cuando con enfoques ágiles (existen cientos de artículos al respecto).
 |
| Matriz de Stacey. Tomado de (2) |
Usando este mismo enfoque, podríamos identificar en un taller de Inception o de Refinamiento, cuando una historia de usuario o una épica incluye mucha o poca incertidumbre para ser estimada y, por ende, desarrollada, tanto desde el punto de vista de requerimientos, como de tecnología, proporcionándonos estimaciones indirectas sobre tiempos y esfuerzos requeridos (toda estimación incluye una probabilidad y una incertidumbre asociada).
Los equipos ágiles deben preferir historias en esta zona de confianza, y estos elementos podría hacer parte de una Definición de Ready o Preparado adecuada, para que las historias puedan ser incluidas en el planning. Los siguientes criterios que garantizan esta zona de estimación con certeza:
- Las historias cumplen cumplen INVEST y las 3C
- Existe un entendimiento consistente de parte del product owner y del equipo acerca de la historia de usuario.
- Las historias cuentan con claros criterios de aceptación
- Se han resuelto las dependencias técnicas y funcionales
- Las ambigüedades se han resuelto
- El tiempo para construir-probar-desplegar la historia de usuario se encuentra en horizontes de tiempo menor o igual a 4 días-persona (esto es una heurística que he observado en los equipos ágiles, en este número de dias las estimaciones son más certeras y confiables. Habrá que hacer un estudio riguroso para confirmar mi experiencia e hipótesis).
Para cerrar, los invito a que usen esta matriz para realizar refinamiento de historias de usuario con sus equipos, asegúrense que existe certidumbre en la tecnologia y acuerdo en los requerimientos, de esta forma fluirán mejor sus sesiones de planning y no se enfrascarán en discusiones innecesarias.
Saludos ágiles,
Jorge Abad
Referencias
- Entendiendo la complejidad: La matriz de Stacey - https://academy.jeronimopalacios.com/courses/145560/lectures/5315213
- https://www.researchgate.net/figure/Stacey-Matrix-Stacey-1996-adapted-to-software-development_fig3_336899045
- Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario
jueves, febrero 25, 2021
Tres Ejemplos de Productos concebidos de Forma Ágil - Agile Inception
Hola a todos
A mi criterio, una de las mejores formas de aprender ciertas técnicas, a parte de experimentarlas, es viendo ejemplos, es por esto que a continuación les comparto tres casos de Agile Inception de productos digitales, el resultado final es un plan de releases del cual se pueden luego detallar las historias de usuario.
Estos ejemplos fueron desarrollados por los Estudiantes de la Cohorte 2020-Sem02 de la ESPECIALIZACIÓN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DE SOFTWARE de la Unab, a quienes tuve la oportunidad de enseñarles la Materia de Metodologías y Marcos Ágiles.
Se desarrollo un caso al cual se le identificó:
- El Problema: qué es lo que intenta ser resuelto con el sistema
- La Visión: Elevator pitch
- El Vecindario: áreas y sistemas con los cuales se relacionará el sistema
- Product Vision Board: usuarios, necesidades, productos y metricas
- User Story Map con identificación del Producto Mínimo Viable - MVP: Épicas priorizadas con estimación de esfuerzo y asignación de valor
- Estimación de Tiempo y Costo
- The Go Product Roadmap: Este artefacto también puede ser conocido como el plan de releases.
- Historias de Usuario con Criterios de Aceptación: se seleccionaron algunas épicas de forma aleatoria y se les escribieron las historias de usuario, simulando un refinamiento.
Espero estos ejemplos les sean de utilidad,
Saludos ágiles
Jorge Abad.
jueves, julio 02, 2020
Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor
Hola a todos
Debido a recurrentes conversaciones y aclaraciones sobre:
- Épicas
- Historias de Usuario
- MVP (Minimun Viable Product o Producto Mínimo Viable)
- Agregar Valor
- Agregar Valor Incrementalmente
- y Scrum
Voy a desarrollar un ejemplo hasta llegar a la planeación de los primeros
tres sprints de un producto de solicitud de crédito, esto con el fin de
ilustrar varios conceptos.
Comencemos.
Paso 1. Durante el Inception (9) se creó el siguiente User Story Map
Paso 2. Durante el Inception (9) se realiza la estimación de cada release
Se realiza una estimación de alto nivel y se identifica
que aproximadamente (7)
cada release tomará:
| Release 1 - MVP | 7 sprints |
| Release 2 | 6 sprints |
| Release 3 | 6 sprints |
Paso 3. Inception - Durante el Inception se identifican las historias de usuario de los siguientes tres sprints (11)
El equipo técnico luego de tener conversaciones con el PO y los Stakeholders
estima que las dos primeras historias épicas son suficiente para los primeros
tres sprints, quedando identificadas de la siguiente manera:
| Release | Épica | Historia de Usuario |
| Release 1 - MVP | Formato de solicitud básico |
|
| Validar referencia personales |
|
|
| Validación centrales de riesgo 1 y 2 | Pendientes por definir (10) | |
| Calificación | Pendientes por definir (10) | |
| Creación del crédito | Pendientes por definir (10) | |
| Desembolso a cuenta propia | Pendientes por definir (10) |
| Release | Sprint | Historia de Usuario |
| Release 1 - MVP | Sprint 1 |
|
| Sprint 2 |
|
|
| Sprint 3 |
|
|
| Sprint 4 | Pendientes por definir (10) | |
| Sprint 5 | Pendientes por definir (10) | |
| Sprint 6 | Pendientes por definir (10) | |
| Sprint 7 | Pendientes por definir (10) |
Ya que llegaste hasta acá, déjame compartirte cuál es mi punto
Realmente no es un punto, son varios, veamos:
- Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
- El sprint backlog identificado se mantuvo entre 5 historias aproximadamente, la experiencia de varios autores sugiere que un buen Sprint Backlog debería tener entre 6 - 10 historias de usuario de similar tamaño (en la medida de lo posible), menos no es recomendable.
- El formulario o Épica de Solicitud de Crédito, NO ES UNA HISTORIA DE USUARIO, es una épica y el principal criterio es que un equipo se demorará más de un sprint en terminarlo (rompiendo los criterios de INVEST y CCC), por lo tanto, para ver progreso de VALOR INCREMENTAL, lo partimos en historias de usuario que nos permiten ver progreso en la construcción del formulario.
- Obvio, cuando se termine el sprint 1 tal vez tengamos las historias: HU1 - Datos personales, HU2 - Datos familiares, HU3 - Datos laborales, HU4 - Referencias laborales, HU5 - Ingresos; pero no tendremos nada que liberar a producción, lo que si es cierto, es que habrá sofware funcionando potencialmente liberable (o en producción apagado) esperando el resto del MVP para ser liberado cuando el PO dé la orden.
- El formulario o Épica de Solicitud de Crédito se terminará de construir aproxidamente en la mitad del sprint 3, como PO, ¿no prefieres ir observando progreso cada sprint? o ¿deseas luego de mes y medio (suponiendo que cada sprint fuera de 2 semanas) de estar comiendote las uñas, pensando que el equipo no te muestra avance? la verdad, creo que es mejor ver valor incremental; los PO con los que he trabajado luego de conocer el mundo del VALOR INCREMENTAL, de las pequeñas entregas, no desean volverse al anterior. Te invito a leer estos dos post respecto a la necesidad de tener historias de usuario pequeñas para poder observar progreso:
- Es en serio, las historias usuario tienen que ser pequeñas (clic aquí)
- Consejo: Que tus Historias de Usuario no sean como Bruce Willis "Duras de Matar" (clic aquí)
- Cuando se termine el formulario o Épica de Solicitud de Crédito, se le agregará VALOR al producto, pero este valor no se hará tangible hasta después que se ponga en producción. Recuerda: "el Software solo adquiere valor cuando es usado".
- Se dice aproximadamente, pues realmente no se sabe a ciencia cierta cuanto tiempo va a demorar en construirse cada release, lo que si sabemos es que vamos a estar priorizando por valor y tan pronto tengamos algo que genere impacto lo liberaremos.
- Realmente se Agregará o Generará VALOR cuando salga a producción el MVP, antes solo se genera satisfacción al PO y a los stakeholders, pues estos ven progreso. Recuerda: "el Software solo adquiere valor cuando es usado".
- El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )
- Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelante. Se realiza en la vista del Discovery del Product Owner (ver http://www.lecciones-aprendidas.info/2020/03/product-owners-views-explicacion.html), además como estamos en un mundo tan volátil, es probable que tengan cambios en el futuro y sean fácilmente obsoletas. Recuerda, en ágil nos enfocamos mucho en no hacer activdades de desperdicio, o como dice el principio 10 del Manifiesto Ágil (clic aquí): "La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial."
- Es altamente recomendado que como resultado de un Inception, se tengan las historias de usuario de los primeros tres sprints refinadas o preparadas para ser desarrolladas. Estas historias podrán tener formato o modo de representación que desees (ver http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html )
- En caso que para el PO y los stakeholders sea de valor liberar la Épica-Solicitud de Crédito (tal vez, porque les ahorra muchos procesos manuales), aunque esta no sea el MVP, pueden hacerlo, (¿quién se los impide?), y para acabar de ajustar no es necesario esperar al review del tercer sprint para ponerla activa en producción, perfectamente pueden liberarla en la mitad, no es necesario que esperen (no te lo imaginabas, ¿cierto 🤯? ). La referencia a esta práctica de liberación continua en la guía de Scrum (ver acá), es la siguiente: "(Scrum se ha usado para) Liberar productos y mejoras tantas veces como sea posible durante el día".
Espero te sirva este post para el desarrollo tu producto y puedas
aprovechar los beneficios del desarrollo incremental.
Saludos ágiles
Jorge Abad
martes, agosto 01, 2017
Ejemplos de Artefactos Ágiles - Inception e Historias de Usuario
Hola a todos
(les comparto un post relativamente recurrente)
Siempre he reconocido en los ejemplos el poder de ayudarnos a comprender mejor los conceptos.
Nuevamente les comparto el resultado del trabajo de la cátedra TÓPICOS TÉCNICOS II, que impartí en la ESPECIALIZACIÓN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DEL SOFTWARE, de la Universidad Autónoma de Bucaramanga (Colombia).
En esta materia vimos tanto el Agile Inception, el desarrollo y ejecución de un proyecto empleando Scrum, como la atención de un área de gestión de incidentes empleando Kanban
Los entregables desarrollados son:
En estos links encontrarán los cuatro proyectos con los entregables citados:
Espero los disfruten y les ayude en sus proyectos.
Saludos ágiles
Jorge Abad
(les comparto un post relativamente recurrente)
Siempre he reconocido en los ejemplos el poder de ayudarnos a comprender mejor los conceptos.
Nuevamente les comparto el resultado del trabajo de la cátedra TÓPICOS TÉCNICOS II, que impartí en la ESPECIALIZACIÓN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DEL SOFTWARE, de la Universidad Autónoma de Bucaramanga (Colombia).
En esta materia vimos tanto el Agile Inception, el desarrollo y ejecución de un proyecto empleando Scrum, como la atención de un área de gestión de incidentes empleando Kanban
Los entregables desarrollados son:
- Agile Inception
- Problema
- Elevator Pitch
- Vecindario
- Incluido, No Incluido y Pendiente por Resolver
- Product Vision Board
- User Story Map - Sin priorizar
- RoadMap (artefacto nuevo que estoy desarrollando y me esta ayudando mucho a identificar el MVP y el crecimiento orgánico del producto)
- User Story Map - Priorizado
- RoadMap Actualizado
- Historias Epicas
- Historias de Usuario
- Estimación de Pivote
- Calculo Costo y Tiempo
- Restricciones
- Arquitectura Fisica
- Arquitectura de componentes
- Diagrama de Contexto
- ¿ Que no nos deja dormir ?
- Simulación de Scrum
- Simulación de tres sprints de scrum, durante una sesión de 4 horas, generando los siguientes entregables:
- Historias de usuario
- Bocetos asociados a las historias de usuario
- Gráfica de Velocidad
- Gráfica de Release Burn Up
- Mejoras identificas cada sprint
En estos links encontrarán los cuatro proyectos con los entregables citados:
- Se lo tengo -Se Lo Tengo! es una startup establecida como canal de adquisición de productos y servicios que permite a cualquier persona vender y comprar de manera fácil mediante un sistema de fidelización por puntos sin restricciones de localización. (dar clic aquí)
- SaluCloud -Es un proyecto para gestionar diferentes áreas de las IPS que necesitan las instituciones prestadoras de servicios de salud.- (dar clic aquí)
- EduCool - Sistema para administrar los procesos de instituciones eductativas - (dar clic aquí)
Espero los disfruten y les ayude en sus proyectos.
Saludos ágiles
Jorge Abad
domingo, diciembre 18, 2016
Tan cerca, Tan lejos. Una Comparación entre el Agile Inception y el Acta de Constitución del Proyecto (Project Charter) del PMBok
Hola a todos
Desde hace un tiempo me debía a mí mismo y a ustedes la escritura de este post, pues en numerosas ocasiones durante los entrenamientos de Scrum o Gerencia de Ágil de Proyectos he hecho esta comparación, y es bueno dejarla plasmada para ayudar mejor a la ilustración de lo que quiero decir.
Los Dos Mundos, el Predictivo y el Ágil
Dentro de los 47 procesos de la gerencia de proyectos del PMBoK (versión 5) existe el primer proceso llamado “4.1 Desarrollar el Acta de Constitución del Proyecto” (este proceso pertenece a los procesos de inicio) que cuenta básicamente con los siguientes aspectos
· Objetivo
o “Es el proceso de desarrollar un documento que autoriza formalmente la existencia de un proyecto y confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto”(1)
· Entradas
o Enunciado del trabajo del proyecto
o Caso de Negocio
o Acuerdos
o Factores ambientales de la empresa
o Activos de los procesos de la organización
· Herramientas y Técnicas
o Juicio de Expertos
o Técnicas de Facilitación(2)
· Salidas
o Acta de constitución del proyecto
Y sugiere documentar los siguientes aspectos (1):
· El propósito o la justificación del proyecto,
· Los objetivos medibles del proyecto y los criterios de éxito asociados,
· Los requisitos de alto nivel,
· Los supuestos y las restricciones,
· La descripción de alto nivel del proyecto y sus límites,
· Los riesgos de alto nivel,
· El resumen del cronograma de hitos,
· El resumen del presupuesto,
· La lista de interesados,
· Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto),
· El director del proyecto asignado, su responsabilidad y su nivel de autoridad
· El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.
Para mayor ilustración sugiero leer este articulo del PMI Colombia (Acta de Constitución del Proyecto) y este excelente ejemplo (Ejemplo Acta de inicio del Proyecto)
Ahora, si realizamos los talleres de Agile Inception (Inicio Ágil – en español) como los sugieren:
· The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers) de Jonathan Rasmussone (clic aquí)
· Inceptions. Starting a Software Project de Enrique Comba Riepenhausen (clic aquí)
Encontramos que sugieren en un taller de 2 a 3 días obtener lo siguiente
· Quién está en el Salón o Taller
· Las reglas de Juego del taller
· Por qué estamos aquí (en este taller)
· Crear el Elevator Pitch
· Diseñar la caja de producto
· Crear el Product Backlog Board(3)(4)
· Crear la lista de No
· Encontrar tu comunidad
· Que te mantiene despierto en la noche
· Muestra la solución
· Darle una personalidad a la solución
· Mostrar el flujo
· Story Mapping (Plan de Releases)
· Qué vamos a obtener (Restricciones, Prioridades, Beneficios)
· Cuánto va a costar y cuánto nos va a tomar
Y si comparamos ambos
Realizando la comparación de ambos, se tienen muchas coincidencias:
Agile Inception
|
Acta de Constitución del Proyecto (PMBoK)
|
· Quién está en el Salón o Taller
· Las reglas de Juego del taller
|
· Aplica parcialmente, no siempre es un taller.
|
· Por qué estamos aquí (en este taller)
· Crear el Elevator Pitch
|
· El propósito o la justificación del proyecto,
|
· Diseñar la caja de producto
· Product Backlog Board
|
· Los objetivos medibles del proyecto y los criterios de éxito asociados,
· Los requisitos de alto nivel,
· Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto,
|
· Crear la lista de No
|
· Los supuestos y las restricciones,
· La descripción de alto nivel del proyecto y sus límites,
|
· Encontrar tu comunidad
|
· La lista de interesados,
|
· Que te mantiene despierto en la noche
|
· Los riesgos de alto nivel
|
· Muestra la solución
· Darle una personalidad a la solución
· Mostrar el flujo
|
· La descripción de alto nivel del proyecto y sus límites,
|
· Story Mapping (Plan de Releases)
|
· El resumen del cronograma de hitos,
|
· Que vamos a obtener (Restricciones, Prioridades)
|
· Los supuestos y las restricciones,
|
· Cuánto va a costar y cuánto nos va a tomar (estos valores son aproximados, nunca cerrados)
|
· El resumen del presupuesto,
|
· No aplica
|
· El director del proyecto asignado, su responsabilidad y su nivel de autoridad
|
· No aplica
|
· El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.
|
¿Entonces en dónde radica la diferencia?
En esencia, se observa que es lo mismo para ambos tipos de iniciativas (predictiva o ágil), aún más el PMBoK sugiere que sean talleres facilitados y no dudo que algunos gerentes de proyecto lo hagan así, pero lo que si es cierto es que en Agile es necesario (por no decir obligatorio) que sea un taller y que se maximice la comunicación cara a cara como lo sugiere el manifiesto ágil y sus principios (5) para garantizar el éxito de lo que se va a realizar.
Adicional en proyectos tradicionales (en los cuales la planeación predictiva es ideal):
- Construcción de edificios
- Construcción de puentes
- Construcción de carreteras
- Ampliaciones de fábricas
- Construcción de barcos
Se hace hasta lo imposible por cerrar el alcance y no dejar lugar a la incertidumbre, pues el costo de los cambios es altísimo (¿o no creen que un dos nuevos carriles en la carretera o 2 pisos más en el edificio, fuera de afectarán gravemente los planes, cambiará el diseño de temas importantes?), cosa muy distinta en desarrollo ágil donde el software es más maleable y donde somos tenemos una arquitectura base sobre la que podemos evolucionar.
Para cerrar esta pequeña comparación, les comparto esta tabla en donde presento las principales diferencias de ambos enfoques:
Agile Inception
|
Acta de Constitución del Proyecto (PMBoK)
| |
Propósito principal
|
No es el objetivo del Inception, esto debe ser resuelto antes.
|
Autoriza formalmente la existencia de un proyecto
|
No tiene como objetivo entregar Autoridad.
|
confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto
| |
Es un taller que permite a los interesados y al posible Product Owner(PO):
· Entender la idea que se tiene a un nivel más profundo
· Identificar las posibles dificultades del proyecto
· Decidir si se continuará o no con el mismo
· Proporciona al PO y a sus Interesados información suficiente para guiar al equipo de desarrollo en la construcción del producto
|
No corresponde a su objetivo primordial
| |
Respecto al alcance
|
Se busca tener una primera versión u hoja de ruta sobre las cuales realizaremos la construcción del producto mínimo viable (MVP - http://www.lecciones-aprendidas.info/search/label/mvp ) y seguiremos creciendo incrementalmente hasta que construyamos el producto que requiere el negocio.
|
Se centra en esbozar el alcance va a detallar y gestionar en las siguientes grupos procesos de la gerencia de proyectos:
· Planeación
· Ejecución
· seguimiento y control
· y cierre
|
Transparencia
|
Esta información queda disponible al lado del equipo del proyecto para que sirva como radiador de información y le sirva para tomar decisiones
|
Muchas veces no es un taller, se comparte con el equipo y los interesados del proyecto, pero no se garantiza que todos la conozcan aunque se sugiere que todos la dominen.
|
Hasta acá esta corta comparación, los invito a profundizar en estos links
- Webinar- Agile Inceptions - http://www.lecciones-aprendidas.info/2016/08/inceptions-con-lucho-salazar.html
- Story Mapping - http://www.lecciones-aprendidas.info/2016/06/user-story-map-mapas-de-historias-de.html
- EDT Ágil - http://www.lecciones-aprendidas.info/2016/07/hola-todos-cuando-desde-la-gerencia-de.html
- Sprint Cero o Agile Inception
- Colección de entregables generados en un Inception
Bienvenidos sus comentarios y feedback.
Saludos Ágiles,
Jorge Abad
Notas, aclaraciones, referencias
1. Guía de los Fundamentos para la Dirección de Proyectos. Guía del PMBoK Quinta Edición.
2. Se enumeran entre varias posibles actividades: la tormenta de ideas, resolución de conflictos, gestión de reuniones para realizar la obtención de este entregable.
3. Aunque no Corresponde a una propuesta de Agile Samurai o Inceptions, es ampliamente usado y recomendable para este proceso
4. Ejemplos del Product Backlog Board - http://www.lecciones-aprendidas.info/search/label/product%20backlog%20board
5. http://agilemanifesto.org/iso/es/principles.html - “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.”, “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.”
Suscribirse a:
Entradas (Atom)