Los ANS y la agilidad

"En muchos casos los ANS (Acuerdos de Niveles de Servicio) parecen estar ahí más para destruir valor que para construirlo

Recomendación:
Vea el ANS como el peor tiempo de su servicio, no como el estándar a cumplir." pic.twitter.com/VR2RXof5wB

— Jorge Hernán Abad L. (@jorge_abad) March 14, 2019

Tweet - Cita sobre Scrum

"Scrum es un buen lugar para empezar pero es un mal lugar para quedarse" @JonKernPA #ScrumDayCo2019 pic.twitter.com/UQ6Hly7NzI

— Jorge Hernán Abad L. (@jorge_abad) March 16, 2019

Agilizando con scrumban el proceso de talent acquisition y Agilidad para Áreas de Negocio

Agilizando con scrumban el proceso de talent acquisition y Agilidad para Áreas de Negocio de Jorge Hernán Abad Londoño

Entrenamiento: Management 3.0 Workshop Details

#LesComparto el próximo entrenamiento que impartiré en Management 3.0

Cuando: Abril 11-12

Ciudad: Medellín

Link del evento https://management30.com/events/details/?id=5386

¡Están cordialmente invitados!

Hablemos de Contratos Ágiles - Reloaded

Hablemos de Contratos Ágile - (reoloaded) de Jorge Hernán Abad Londoño

La transformación digital requiere de la transformación ágil (resumen)

Imagen de la película Minority Report

Hola a todos

Llevo varios días tratando de escribir este artículo, sustentarlo con una buena cantidad de referencias reconocidas y entre más escribo más me convenzo que se parece más a un ensayo que a un pequeño artículo de fácil y corta lectura.

Pero mientras sale el "casi ensayo",  quisiera dejar evidencia de este importante asunto sobre el que quiero poner foco, pues he observado que muchas empresas quieren hacer su Transformación Digital sin a la par trabajar en su Transformación Ágil, muy seguramente la empresa no esta lista para el cambio (que no es opcional por estos días de cambio acelerado, discruptivo o VUCA) pero quiere empezar "para ayer" - como decimos en Colombia- con este cambio, que ya le esta quitando clientes o pronto se los quitará. Lo simpático es que cuando comienzan con este tipo de proyectos:

• de IoT
• en la Nube
• de BigData
• con IA
• robotics
• customer centric
• etc, 

Sus personas, cultura, mindset y procesos, aun no están listos para gestionarlos- es decir, no tienen el mindset ágil- , correspondiendo al mindset de la gestión predictiva, en el cual toda su cultura esta ubicada - y que es de reconocer, les ha dado éxito hasta el momento- generando problemas como:

• creer que es un proyecto tradicional 
• no verlo como un experimento que puede ser exitoso o fallido
• no considerar hipótesis a ser validadas
• no medir el resultado esperado
• no priorizar alcance por valor
• contratar la construcción con los parámetros de cascada
• quieren presupuesto fijo
• el alcance es fijo con requerimientos detallados
• el tiempo para la ejecución es fijo
• utilizar métricas de cascada para proyectos ágiles
• al proyecto ágil se le asignan ANS o SLA de cascada (¿¡en serio!?)
• las personas no tienen tiempo para ejecutar los roles con el involucramiento que se requiere (ej: Product Owner)
• quieren en la primera versión todo el sistema y no comprenden que es un Producto Mínimo Viable (MVP - Minumum Viable Product)
• no se acompañan de gente que tiene experiencia gestionando este tipo de proyectos
• al gerente de proyecto que no tiene experiencia, pero que hizo un "curso de Scrum Master" le entregan la misión de sacar "el proyecto" adelante.
• los procesos de aprobación de "cualquier cosa" requiere demasiadas aprobaciones y comités
• entre muchas otras cosas

Haciendo que la iniciativa "Digital" muera sin haber nacido.

Es aquí donde veo que es necesario el asesoramiento, el acompañamiento y crear las condiciones para el éxito o para el fracaso (pero que este fracaso o fallo sea rápido).

Estimad@ gerente:

"El tiempo sigue avanzando y usted sigue esperando que el proceso organizacional apruebe su proyecto digital, de forma que salga a buscar a su mejor proveedor en cascada, a decirle que haga ágil, pero con las condiciones de cascada, luego entre a negociar el alcance y las estimaciones - proceso interminable y desgastante -, perdiendo ROI y aumentando el costo del retraso de forma significativa, ¿En serio, va a seguir perdiendo mercado y costo de oportunidad, y permitiéndole a su competencia que le tome ventaja de su proceso lento? o ¿va a generar las condiciones de éxito para este piloto, que va a ser la puerta de entrada a esta nueva forma de trabajo? La decisión está en sus manos, nos vemos la próxima reunión"

Hasta áca este corto compartir

Saludos Ágiles

Jorge Abad

Algunas Referencias

1. Is Digital a Priority for Your Industry?. https://www.gartner.com/smarterwithgartner/is-digital-a-priority-for-your-industry/
2. El mundo ya cambió. https://www.youtube.com/watch?v=pPzS6gza9KQ
3. What is VUCA https://www.youtube.com/watch?v=9yg_BLNSYZU
4. Economía Colaborativa - https://es.wikipedia.org/wiki/Consumo_colaborativo
5. Transformación digital, reto de empresas líderes globales - https://www.portafolio.co/negocios/empresas/transformacion-digital-reto-de-empresas-lideres-globales-524943
6. ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?- http://www.lecciones-aprendidas.info/2018/11/por-que-no-contratar-en-cascada-un.html
7. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. http://www.lecciones-aprendidas.info/2017/08/como-elegir-el-proyecto-piloto.html

Invitación ScrumDay en Medellin Colombia - Marzo 15 y 16 de 2019

Invitación al ScrumDay a realizarse en Medellín Colombia el proximo 15 y 16 de marzo. Link del sitio - http://www.scrumday.co/ Link de la agenda - http://www.scrumday.co/#faq

[De Colección] Lo más importante de las historias de usuario no es el formato sino la esencia - Tweet de Colección

As an author of the Agile Manifesto
I want that stupid story format to go away
So that people can get to the essence of user stories.

— Ron Jeffries (@RonJeffries) April 7, 2016

Señor(a) CIO le comparto una noticia: "Su equipo le quiere despedir"

Imagen tomada de: https://unsplash.com/photos/nuvtfH-p1H8

Hola a todos

He tenido la oportunidad de conversar con agilistas(2) de varias latitudes y acentos en Latinoamérica y con frecuencia les pregunto esto:

¿Crees que el equipo de IT de esta organización en la que estas trabajando despediría a su jefe?

La mayoría de las veces la respuesta es un doloroso y rotundo

 "Sí, sin lugar a dudas"

y cuando indago las razones, encuentro expresiones como:

• No se involucra
• Nos dice: "hagan, tienen mi autorización", pero no ha entendido que su involucramiento es fundamental, cree que no estorbar es suficiente.
• No entiende la agilidad y lo que implica de parte de él (ella) y de la organización
• Cree que es solo asistir a capacitaciones
• Nos sigue midiendo en cascada, adicionalmente le gusta cumplir con lo que promete a otras áreas pero no esta centrado en el cliente, ni le importa si lo que hacemos genera o no valor para la organización.
• Quiere que seamos ágiles y colaboremos entre nosotros, pero hace que  nos relacionemos como silos que compiten entre sí.
• Quiere que seamos ágiles pero nos esta exigiendo contratar en cascada
• No entiende que la agilidad no es solo de IT y no nos está ayudando a llegar a otras áreas y vicepresidencias
• No esta predicando con el ejemplo y en su forma de interactuar y tomar decisiones sigue bajo el esquema tradicional de comando y control
• Vive en competencia con los otros CXO para ganarse el favor del CEO
• Sigue enfocado en la microgestión sin delegar en su equipo
• Habla de agilidad con todos, porque sabe que eso le va a servir para sus resultados pero no es un jugador de equipo
• Le encanta la estabilidad y no nos permite fallar y aprender, impidiendo el cambio y la verdadera innovación
• Vive en el presente (o hasta en el pasado) de la organización
• No ha permitido mejorar la calidad técnica de las soluciones

En el contexto estado actual (2019) la mayoría de los CIO (también denominados como vicepresidente, gerente o director), han llegado a sus puestos de la forma tradicional: con un estilo de gestión comando-control, por haber logrado cerrar proyectos muy grandes y complejos, algunas veces por sus habilidades técnicas, otras por sus habilidades de relacionamiento y muchas otras por su rudeza y mano dura -entendida como carácter y firmeza para sobresalir-, pero este estilo de management aun predominante en las organizaciones (pero que esta renovándose debido a los retos actuales hacia un management más humano, colaborador, empoderador, etc ) esta caracterizado por solo escuchar a los de su misma tribu, a los que opinan igual a ellos, y comúnmente no escuchar a nadie, sino a sí mismos, conductas completamente adversas a la agilidad, considerando que esta se basa en una cultura de cultivación y cooperación principalmente, ver las siguientes dos imágenes.

Modelo Cultura de Schneider (1)

Manifiesto Ágil plasmado en el esquema de cultura de Schneider elaborado por Michael Sahota(1)

Bajo este esquema, las expectativas de un equipo de TI que está batallando con la transformación ágil (y digital) de la empresa ve en su CIO su sponsor y miembro de equipo clave, requiriendo que:

• Ella (él) y su equipo lideren con el ejemplo para el resto de la organización
• Sea un aliado y un involucrado, no solo un espectador
• Este validando constantemente los resultados
• Trate a su equipo y proveedores como unos aliados y no como unas víctimas de su poder
• Sea autocrítico, con reconocimiento de errores, capacidad de adaptación, reinventarse y tenga una relación honesta (no de poder) con sus pares y equipo de trabajo.
• Permita espacios y presupuestos de innovación y creatividad, con una mirada en el futuro, la inspección y adaptación en el presente
• Este dispuesto a empoderar para generar grandes resultados,
• Entienda que en este nuevo entorno y reglas, el protagonista es su equipo y su capacidad de empoderarlos
• Negocie e involucre a otras áreas, 
• Deje de pensar en silos y vea como único fin, la generación de valor con productos y servicios customer-centric.
• Se convierta en habilitador y acelerador del cambio organizacional

Para cerrar este post una reflexión de mi estimado amigo Lucho Salazar y una nota realista

La reflexión

"Las organizaciones del siglo XXI quieren mejorar pero no quieren cambiar. Se mantienen en un estado de inmovilidad colmado de voluntades de cambio fingidas. A lo largo de mis años como agente de cambio me he encontrado con entidades cuyo propósito de renovación es simplemente un disfraz con el que ocultan su ánimo de permanecer estáticas en el tiempo. Lo que no saben estas compañías es que de no cambiar se exponen a su desaparición o al trágico rezago del que difícilmente podrán volver."@LuchoSalazarC (3)

La nota realista

"Estimad@ CIO, esta es una era del cambio y todos estamos cambiando, usted aun puede hacerlo, y es cierto, su equipo lo quiere despedir pues usted se ha convertido en su mayor obstáculo para lograr la transformación ágil y digital, por favor cambie antes que su jefe/líder se de cuenta que usted no esta emprendiendo este reto con la seriedad, compromiso e involucramiento que esto requiere"

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios, Agradecimientos y Referencias

1. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota. http://agilitrix.com/wp-content/uploads/2018/08/Una-Gui%CC%81a-de-Supervivencia-a-la-Adopcio%CC%81n-y-Transformacio%CC%81n-A%CC%81gil.pdf
2. Agradezco a todos mis amigos agilistas que me proporcionaron importantes reflexiones para este artículo, no los puedo referenciar por temas de confidencialidad pero este post, no es mío, fue solo una compilación de muchos pensamientos.
3. Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio http://www.gazafatonarioit.com/2018/04/apuntes-sobre-transformaciones-agiles_1.html

Freddie Mercury - Queen - y su definición de equipo (banda)

Hola a todos

Les comparto esta divertida entrevista a Freddie Mercury (vocalista de Queen), aprovechando que todos los estamos recordando por estos días.

Lo más interesante es la definición de banda (equipo) que tienen ellos, ¿les parece conocida?. Espero la disfruten

----

¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?

Por:
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Aunque en varios foros hemos compartido que contratar en Cascada (o tradicional, o con alcance, tiempo y costo fijos) un proyecto (o mejor, producto) ágil es completo dolor de cabeza para ambas partes, es como querer jugar rugby con las reglas del del fútbol, en este post, quisiéramos compartirte unas ideas claves de por qué no te conviene hacer esto tanto desde del punto de vista del Cliente como del Proveedor, vamos pues:

Problemas desde el punto de vista del Cliente

• El alcance no puede ser fijo en estos tiempos de alta disrupción (VUCA (1)) y es un error tratar de definir los requisitos a priori dada esta misma volatilidad(2) 
• El proceso de control de cambios (no te agregaría ningún valor)haría muy lenta las decisiones, y retrasaría el Time to Market, considerando que en ágil existe una continua repriorización y modificación de los requisitos en función del valor. 
• Tal vez (la verdad, muy seguramente) te obligues a construir lo innecesario. 
• Como la responsabilidad no es compartida, se genera una relación de competencia en vez de una relación de colaboración, impidiendo maximización del valor del producto. 
• Las estimaciones y costos con seguridad estarán inflados debido a la incertidumbre 
• Quemarás al proveedor y al equipo de trabajo, pues estos fallarán continuamente en sus estimaciones. 
• Los contratos tradicionales se basan en la desconfianza. Esto aumenta la incertidumbre y maximiza los riesgos. La incertidumbre y los riesgos nunca son buenos para el cliente, generan presión y desgaste. Se pierde el foco en lo que es realmente importante: el valor para la organización y la oportunidad. 
• Los planes se basan la percepción y no en la realidad. Lo que conduce a que haya una dedicación exclusiva a "cuidar" esos planes. Esto es desperdicio. Pérdida de dinero. Dinero del cliente. 
• La realidad es lamentable: con un contrato tradicional siempre o casi siempre hay desviación por sobrecostos, esto “hiere” mortalmente la confianza interna del cliente, es decir, entre las áreas involucradas. 
• Los continuos cambios pueden ocasionar modificaciones en las cláusulas en el contrato. Allí surgen roces entre las partes, proveedor y cliente. 

Problemas desde el punto de vista del Proveedor

Nota: este tipo de espantajos metodológico-contractuales por lo general se contratan bajo la siguiente forma: un alcance definido o que se define durante los primeros dos o tres meses y luego se hace una estimación que se parte en sprints.

• De entrada sabes que la estimación es fallida, que debes incrementar costos y tiempos y no tienes como justificarlo, y aunque lo justifiques el cliente no te creerá haciendo reducir costos y tiempo (pues el alcance lo dejan fijo) y exponiéndote a un riesgo financiero, reputacional o de penalidades. 
• Aunque estimes a priori el proyecto y ejecutes por sprint, te atrasarás debido a la incertidumbre de reinante en el mundo del software, incrementando la presión sobre el proyecto y la ejecución 
• Te la pasarás reunión tras reunión justificando por qué no estás cumpliendo el plan (sabiendo que trabajas en scrum con sprints) y tratando de reacomodar el plan 
• Los controles de cambio son un dolor de cabeza que no te permite realizar priorización por valor que le conviene más al cliente y al proyecto (producto) 
• Las métricas de seguimiento cascada aplicadas al proyecto (o producto) en ágil generan un desgaste pues no hacen match con las métricas de seguimiento ágil. 
• Quemarás a tu equipo tratando de ponerte al día con el cronograma de sprints comprometido al principio del proyecto.

Soluciones

• Contrata en ágil los proyectos ágiles (ver nuestro video sobre contratos ágiles - https://www.youtube.com/watch?v=872uF0dPYd8) 
• Pon cláusulas de terminación anticipada, que te sirvan cuando decidas no continuar con el cliente o con el proveedor según el caso. 
• En un contrato ágil nunca pongas el alcance fijo. 
• Si te preocupan los ANS o SLA, en Scrum tienes software funcionando cada dos semanas lo que permite validar si el proveedor está construyendo el producto de forma satisfactoria. 

Si tienes alguna otra disfuncionalidad a compartir, no dudes en hacerlo en la zona de comentarios


Saludos Ágiles

Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Referencias, comentarios, notas y aclaraciones

1. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
2. Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software - http://www.lecciones-aprendidas.info/2015/04/radioactividad-de-los-requisitos.html
3. Este artículo fue escrito a cuatro manos, y fue publicado en el Gazafatonario IT en http://www.gazafatonarioit.com/2018/11/por-que-no-debes-contratar-en-cascada.html

Algunos Tweets Importantes sobre Historias de Usuario

Stop worrying about writing perfect users stories. As @jeffpatton writes in User Story Mapping, stories are meant to be told, not written.

— Jim Constant (@TheAgilePO) May 28, 2014

---

"stories aren't a different way to write requirements, they're a different way to work!" @jeffpatton pic.twitter.com/cT91mB2ERe

— Andy de Vale (@andydevale) October 30, 2018

---

@jmbeas @jeffpatton @david_caicedo http://t.co/nZu7d99Va2http://t.co/pcRLrNfs48

Key point: User Stories are TOLD, not written.

— Ron Jeffries (@RonJeffries) May 23, 2015

---

Agile stories don't rely on the document as the primary mechanism for building shared understanding, they rely on the story telling. https://t.co/j735QrOCE9

— Jeff Patton (@jeffpatton) October 27, 2016

---

"We don’t need an accurate document, we need a shared understanding." - @jeffpatton

— Rich Rogers (@RichRogersIoT) April 18, 2018

---

As an author of the Agile Manifesto
I want that stupid story format to go away
So that people can get to the essence of user stories.

— Ron Jeffries (@RonJeffries) April 7, 2016

---

@keithb_b if your user story begins "As a", you haven't understood user stories.

— Ron Jeffries (@RonJeffries) October 1, 2016

De Colección: Algunas frases que sirven para el desarrollo de productos

"No hay nada más inutil que hacer eficientemente aquello que no debería haberse hecho en absoluto" [Peter Drucker]

— Lucho Salazar (@luchosalazarc) November 12, 2018

---

"La perfección no se alcanza cuando no hay nada más que añadir, sino cuando no hay nada más que quitar" Antoine de Saint-Exupéry

— Jorge Hernán Abad L. (@jorge_abad) November 13, 2018

Dos razones del cambio

“We generally change ourselves for one of two reasons: inspiration or desperation.”

― Jim Rohn

"Generalmente cambiamos por una de estas dos razones: inspiración o desesperación"

― Jim Rohn

 ----

#DeColección

“We generally change ourselves for one of two reasons: inspiration or desperation.”
― Jim Rohn

— Jorge Hernán Abad L. (@jorge_abad) November 17, 2017

Todos estamos jugando a ganar.

Una Reflexión

De las cosas que mas me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR.

La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más empático y a generar mejores resultados donde hay más abundancia para las partes.

Esta habilidad me ha permitido ser mejor #influenciador y mejorar altamente la colaboración.

Saludos ágiles
Jorge Abad

Hangout ¿Cómo Contratar un proyecto ágil? (o filosofemos sobre contratos Ágiles)

Fail - Contratar el MVP con Alcance, Tiempo y Costo Fijo

Cada vez me encuentro más con empresas que dicen:

"Ok entendí qué es un #MVP, entonces constrúyanlo con un contrato a alcance, tiempo y costo fijo"

Predecir alcance, tiempo y costo en escenarios de #VUCA es imposible.

---

¿Que modelo recomiendo usar ?

Para todo tipo de proyecto o producto de desarrollo de software recomiendo, en primer lugar no ceder frente a las presiones del cliente (no es profesional, y realmente a el no le conviene aunque así lo crea), luego de ahí hacer cualquiera de los siguientes contratos:

1. Tiempo y materiales
2. Tiempo y materiales con tiempo fijo
3. Tiempo y materiales con costo fijo
y por último
4. Estimación por sprint o estimación por trabajo mensual (implica bajo riesgo con orden de trabajo mensual)
5. Tiempo y materiales con alcance fijo (no recomiendo pues implica levantamiento y perdemos flexibilidad... cosa que nos brinda el enfoque agile)
¿y ustedes que han hecho en estos casos? ¿que recomiendan?

Tip sobre Proyectos y Contratos Ágiles

"Hacer un Producto/Proyecto Ágil con un contrato tradicional (alcance, tiempo y costo fijos) es un completo dolor de cabeza para todos -cliente y proveedor-. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance."

_

Hacer un producto/proyecto #Agile con un contrato tradicional (alcance, tiempo y costo fijos) es un dolor de cabeza para todos. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance https://t.co/M2FkrzODN2

— Jorge Hernán Abad L. (@jorge_abad) October 24, 2018

Consejo: Que tus Historias de Usuario no sean como Bruce Willis "Duras de Matar"

Hola a todos

Frecuentemente encuentro Product Owners, Scrum Masters, Equipos e Interesados que tienen un concepto erróneo del tamaño de las Historias de Usuario (HU), siendo estos gigantes (HU con una o más hojas de descripción) que no cumplen ni las tres CCC (1) ni el criterio INVEST (2), pues bien, una metáfora que me ha servido para generar la comprensión que deseo es que 

las historias de usuario no pueden ser como Bruce Willis "Duras de Matar" y sobrevivir varios sprints, estas deberían morir en el sprint en que se identificaron construir 

y si la construcción toma varios sprints, significa que realmente no eran HU sino Historias Épicas.

Me explico, una HU es un pedazo pequeño y funcional de software, varias veces he compartido que lo ideal es que tome a lo sumo 3 a 4 días de esfuerzo freelance - ojalá menos tiempo (4)-, es decir, que la suma de todas las horas invertidas no supere este cantidad de tiempo (incluyendo descanso, idas al baño, tomar un café, etc.), por lo tanto, las HU deberían morir en el sprint  en el que el equipo las seleccionó para desarrollarlas (recordemos que en Scrum el Product Owner -P.O.- tiene el Product Backlog priorizado y durante el Planning el PO explica las historias priorizadas al Equipo y este las selecciona para ser parte del Sprint Backlog), en consecuencia, si tu equipo tiene HU tipo Bruce Willis, empleen criterios de división (5)(6)(7) hasta que estas tengan el tamaño apropiado para el sprint y así todas puedan fallecer en el sprint en que se identificaron (recordemos una buena eurística es que un Sprint Backlog tenga entre 6 a 10 historias de usuario).

Importante: Si la HU tiene impedimentos no corresponde al caso tratado en este post, es otra historia, y deberíamos preguntarnos varias cosas:

• ¿Comenzamos a desarrollar una HU con impedimentos?¿dependencias?
• ¿Si lleva varios sprints con el impedimento cuál es la efectividad del SM, PO y la organización para removerlo?

Bueno, hasta acá este corto compartir

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Las tres CCC - Artículo Original escrito por Ron Jeffries - clic aquí -.
2. El Criterio INVEST - INVEST in Good Stories, and SMART Tasks. Bill Wake. - clic aquí -.
3. Es en serio, las historias usuario tienen que ser pequeñas -- clic aquí -.
4. Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - - clic aquí -.
5. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario -- clic aquí -.
6. Un Método Adicional de División de Historias de Usuario: Criterio de Equipo o Hasta Acá Llegamos - - clic aquí -.
7. Algunas Ideas Claves sobre Historias de Usuario - - clic aquí -.
8. En el libro: Historias de Usuario, Una Visión Pragmática (clic aquí) también encontrarás ejemplos de como dividir épicas en historias de usuario.

Lanzamiento del libro: Historias de usuario: Una visión pragmática. Por Jorge Abad y Lucho Salazar

Hola a todos

El día de hoy, segundo dentro de las Jornadas Ágiles Latinoamericanas 2018 -http://agiles2018.agiles.org/ - mi gran amigo y colega Lucho Salazar (@LuchoSalazar) y yo lanzaremos el libro "Historias de usuario: Una visión pragmática", el cual hemos escrito con el propósito de compartirles nuestras experiencias facilitando y acompañando a equipos construyendo productos grandiosos empleando este instrumento.

Espero lo disfruten leyéndolo y usándolo como nosotros al escribirlo. A continuación les comparto el prólogo del mismo.

Saludos Ágiles
Jorge Abad

Prólogo

Con historias y contando historias es como las culturas se hacen más fuertes y sobreviven. Las historias generan conexiones entre los emisores y los receptores y hacen que unos y otros se conviertan en un solo grupo, un solo equipo, un solo ser.


Las historias son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas y las historias de usuario, tal y como las conocemos, no son la excepción a esta condición. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.


Las historias de usuario permiten a los equipos virtuosos construir los productos correctos, incluso antes de pensar en hacerlo de la manera correcta (el método o las prácticas). Nos permiten concentrarnos en el valor de los componentes de cada producto y de cómo estos componentes hacen o harán resonancia unos con otros, en vez de involucrarnos directamente desde el inicio del esfuerzo de desarrollo en los detalles del producto o en los intríngulis de la tecnología que usaremos para construirlo.


En el caso particular del desarrollo de software, las historias de usuario son el primer movimiento de esa sinfonía que es el descubrimiento del producto y de sus características. Las historias de usuario nos ayudan a entender la proposición de valor del producto desde sus inicios, nos ayudan a anticiparnos a la gran incógnita que supone si los usuarios efectivamente usarán o no el producto, nos permiten interactuar no solo con los usuarios e interesados internos, sino también con los consumidores finales del mismo.


En este libro hemos recogido algunas de las formas de hacer las cosas cuando de historias de usuario se trata, es una visión, la nuestra, soportada en la experiencia de muchísimos años no solo en proyectos y esfuerzos de desarrollo con pensamiento Ágil y Lean, sino con otros enfoques y métodos que a estas alturas son considerados tradicionalistas.


Hemos acompañado y ayudado a cientos de equipos en docenas de empresas, en Colombia y en otros países. Han sido cientos o miles de iteraciones en conjunto, cientos de personas con las que hemos experimentado continuamente y hemos encontrado algunos escenarios exitosos, otros no tanto; pero hemos crecido en el proceso. Y sobre este aspecto, que nos haya funcionado a nosotros no quiere decir que les funcione a otros; como siempre, el llamado es a experimentar en cada escenario, en cada momento e ir analizando qué funciona y qué no en sus propios espacios y ambientes.


Al hablar de historias de usuario es necesario hablar de eXtreme Programming (XP), el contexto en el que nacieron; pero también es necesario hablar de Scrum, el contexto en el que más se usan hoy día. Sin embargo, en lo posible trataremos de ser agnósticos al marco de trabajo. Hablaremos indistintamente de iteraciones o sprints para referirnos a lo mismo.


Quienes nos conocen saben que llevamos escribiendo varios años sobre este tema que nos apasiona. De hecho, el libro es una recopilación de todos esos artículos en nuestros blogs:


Lecciones Aprendidas (http://www.lecciones-aprendidas.info/) y


Gazafatonario (http://www.gazafatonarioit.com/).


Pero los hemos enriquecido con numerosos ejemplos, les dimos un hilo conductor en el sentido en que creemos es mejor abordar su lectura, aunque nada evita que se haga en direcciones diversas.


Hemos dedicado mucho tiempo y espacio a tratar el tema de lo que significa tener buenas historias de usuario (INVEST) y hemos hecho énfasis repetidamente en que estas son un instrumento de conversación entre los miembros involucrados en el desarrollo de productos, software o no. En la parte final, incluimos el Lienzo para Conversaciones sobre Historias de Usuario, ampliamente detallado y listo para uso, una herramienta, un medio de comunicación, para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. Una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.


Así es que bienvenidos a este libro y así como lo plasmado acá fue exitoso para nosotros, esperamos sea útil para ustedes, dándole aplicabilidad en su contexto.

Pueden encontrar el libro en Amazon:

Formato Kindle:
https://www.amazon.com/dp/B07HLYX68Z


Formato Tapa blanda:
https://www.amazon.com/gp/product/1723933562


Y como siempre, bienvenida cualquier retroalimentación.

Jorge y Lucho