Un tweet sobre #Agile

#Agile reduce costos pero no es más barato. Un equipo de desarrollo siempre costará lo mismo, el enfoque al valor es la gran diferencia.

— Jorge Hernán Abad L. (@jorge_abad) July 26, 2017

Algunas Ideas Claves sobre Historias de Usuario

Hola a todos:
Les quisiera compartir un listado de ideas centrales sobre historias de usuario que por lo regular comparto en los entrenamientos en Scrum:

1. Las historias de usuario no son especificaciones
2. Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema (Leonardo Agudelo)
3. Es preferible una historia de usuario ambigua que una bien escrita (la razón: la ambigua invita a la conversación) (Jeff Patton)
4. Paremos de especificar las historias de usuario comencemos a explicarlas (Jeff Patton)
5. Es en serio, las historias de usuario tienen que ser pequeñas (ver post aquí)
• Una buena historia de usuario debe tomar entre 3 y 5 dias persona de esfuerzo para lograr el DONE
• Una buena historia de usuario tiene entre 4 a 8 criterios de aceptación
6. Lo más importante de una Historia se usuario es que sea menos importante que la conversación (Juan Pablo Bernal)
7. Un buen sprint backlog tiene entre 6 a 10 historias de usuario (ver más acá)
8. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante (Lucho Salazar).
9. Es un error decir: "la historia de usuario está mal especificada", pues la historia de usuario no es una especificación, es mejor que este "mal escrita" por que invita a una conversación y una aclaración sobre la misma.
10. Se llaman historias de usuario no "especificaciones de usuario", por lo tanto el énfasis se debe hacer en la historia que cuenta el usuario y no en lo que esta escrito o tratado de especificar.
11. Las historias de usuario deben ser porciones funcionales end-to-end, que cuando funcionen se implementen agreguen valor, o sea, pasen exitósamente el siguiente test:
• ¿puedo ponerla en producción?
• ¿un usuario final puede usarla sin necesidad de algun truco o script extraño?¿es decir, se puede acceder desde la interfaz de usuario y funciona completamente?
12. Una historia de usuario debe ser construible en su totalidad durante un sprint (incluyendo pruebas, documentación, despliegue y todo lo que este en la "Definition of Done")
13. "Las historias de usuario son DICHAS,  no escritas." / "Key point: User Stories are TOLD, not written".(Ron Jeffries)

@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

Espero les sean útiles estas cortas ideas.

Saludos Ágiles

Jorge Abad

De Colección: Laloux Culture Model and Agile en español

Laloux Culture Model and Agile en español from Agile For All on Vimeo.

Un tweet sobre Historias de Usuario

Lo más importante de una Historia se usuario es que sea menos importante que la conversación#Agile #Leadership #DreamTeam

— Juan Pablo Bernal M. (@NeoBernal) July 12, 2017

Hablemos sobre Contratos Ágiles

Hablemos de Contratos Ágiles from Jorge Hernán Abad Londoño

---

Notas del Taller de Retrospectivas con Ágiles México

Notas del taller de Retrospectivas en @AgilesMexico parte 1 de 2 pic.twitter.com/UhJHlDRLnK

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

---

Notas taller de Retrospectivas en @AgilesMexico parte 2 de 2 pic.twitter.com/dUCPhejlr4

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

---

Charla de retrospectivas por @jorge_abad en @AgilesMexico pic.twitter.com/UGA2Y4gOiY

— Carlo Gilmar (@CarloGilmar) March 17, 2017

---

La Diferencia entre el Cumplimiento y Entender el Propósito

Hola a todos

Hace poco salí con mi familia y unos amigos de paseo y nos encontramos en una situación vergonzosa: íbamos todos en el mismo carro de regreso al hotel en carretera destapada (no pavimentada) y de repente a unos 10 metros de nosotros un motociclista tiene un accidente, se cae de la moto con su novia o esposa, e inmediatamente los dos automóviles que estábamos cerca nos detuvimos a auxiliar a la pareja, no fue grave el incidente, algunas raspaduras y heridas leves. todos sacamos nuestro botiquín y nos encontramos conque ambos contábamos con lo mínimo que nos exige la ley (confieso que ese el mismo que yo tenía en mi carro):

• Un pedazo de gaza 
• Algodón
• Guantes
• Un desinfectante (alcohol antiséptico)
• Un aplicador
• Cinta microporo

Con esto tan insignificante no logramos atender las heridas del motociclista y su novia, el recuadro de gasa era insuficiente necesitábamos más para cubrir la herida en la mano y que el pudiera conducir su moto, el alcohol lo acabamos rápido, realmente estábamos limitados; de suerte que a los pocos minutros pasó otro automóvil con un botiquín serio (no el que teníamos los dos carros - que era el para cumplir la regulación-) y pudimos auxiliar y prestar los primeros auxilios a la pareja, vendarlos etc.

De este pequeño incidente me quedaron varias enseñanzas.

• Teníamos un botiquín solo para cumplir con la regulación colombiana, pero no nos sirvió para un leve accidente 
• No entendíamos el propósito del botiquín en nuestros carros, si fuéramos conscientes que con este atenderemos un herido ya sea nuestro o externo no seríamos tan irresponsables de andar con un botiquín de juguete.
• Cuando nos centramos en el cumplimiento y no entendemos el propósito nuestras soluciones no son las correctas.
• El botiquín no esta en mi carro para evitar sancionado por la ley, sino para ayudar a salvar mi vida, la de mi familia, o de alguien que requiera mi ayuda.
• Cambiar inmediatamente el botiquín de primeros auxilios de mi auto.

Y extrapolando esto a la agilidad

• No podemos usar frameworks y metodologías como SCRUM, Kanban, XP, SAFe, LESS sin saber que son y cual es su propósito y el problema que pretenden resolver
• Sin propósito cualquier implementación de Agile se hará por cumplir o por moda y con seguridad carecerá de los elementos necesarios para ser exitosos en su contexto.
• Tener personas ejecutando roles (PO, SM, Team Members, etc) en los cuales ellos no tengan claro el propósito y la razón de ser del mismo llevará a implementaciones erróneas e ineficientes (ya lo he vivido, de seguro ustedes también)
• Igualmente no tener claro el por qué de los artefactos y de las ceremonias, hará que estos sean implementados de forma incorrecta y no proporcionarán los resultados y beneficios esperados. (ya lo he vivido, de seguro ustedes también)(1)

Unas cuantas preguntas para cerrar:

• ¿sabes cual es propósito de tu rol?
• ¿por que usas scrum, y no xp, u otro framework?
• tu transformación hacia ágil tiene propósito o es solo ponerse a la moda
• ¿sabes por que las historias de usuario deben ser pequeñas? (Es en serio, las historias usuario tienen que ser pequeñas (clic aquí) )
•  ¿Tienes claro que el MVP - Mínimo Producto Viable - debe ser lo mas pequeño posible? ¿o tu MVP es de todo el producto?

Consejo:

• Busca siempre entender cual es el propósito de lo que haces y esto como suma al propósito general.

Bueno hasta acá este compartir

Saludos ágiles

Jorge Abad

Notas, aclaraciones, comentarios y referencias

1. Todo esto me hace recordar mi anterior reencarnación en la que fui ingeniero civil (ejercí esta hermosa profesión 3 años antes de adentrarme de lleno al apasionante mundo de la ingeniería de software) y resulta que existe un método bien claro para diseñar la estructura de un edificio para lo cual se requiere un ingeniero civil calculista que determine de que tamaño son las estructuras y materiales que deben tener (concreto, acero, etc), pero en Colombia los maestros de obra en los barrios populares construyen (fuera de la ley) estructuras de 1, 2, 3, hasta 4 pisos (si no es más - ojala no-) replicando lo que esquemas que han visto en las construcciones en las que han trabajado con ingenieros civiles pero estas soluciones no son ni las mejores costo-eficientes, y ni se sabe si resistirán las calidades sísmicas de la zona en la que se encuentran.