Buscar en Gazafatonario IT

lunes, noviembre 28, 2016

Las historias de usuario como instrumentos de negociación


Hablemos un poco de ese continuum que significa diseñar y construir soluciones de valor para una organización. Las organizaciones hoy día están hechas de software, el software está en todas partes y si de construir software se trata, los equipos ágiles tenemos algo que decir.
De los incontables utensilios que contamos en nuestra mesa de trabajo las historias de usuario están siempre a la vista de quienes transitamos por los senderos de los problemas complejos y las soluciones para ellos. Para nosotros, trabajar en soluciones mejora la comprensión de los problemas. Esta es posiblemente la razón principal por la cual los enfoques iterativo e incremental son mejores que cualquier otro en la actualidad. Y si los combinamos, mucho mejor. Los Agilistas fantásticos:
1.     Construimos de manera iterativa para minimizar el riesgo
2.    Construimos de manera incremental para maximizar el retorno de la inversión (ROI)
3.    ¡Repetimos  1 y 2 hasta la saciedad! O hasta que se esté generando el suficiente valor como para detener nuestro esfuerzo de desarrollo.
En ese camino hemos aprendido que los problemas no son subjetivos. Lo subjetivo es la percepción que tengamos de esos problemas. En general estos se basan en la realidad. Además, los enfoques de pensamiento, nuestro mindset, pueden llegar a redefinir esos problemas por completo.
Ya sabemos que una historia de usuario no es un contrato firmado en piedra, más bien es una carta de intención de algo que el sistema debe hacer y cuyos detalles se abordan durante la conversación entre el usuario (Dueño del Producto) y el equipo de desarrollo. También son cartas de negociación entre unos y otros, pero solo habrá una negociación fluida si el usuario está realmente interesado en el éxito del esfuerzo de desarrollo, si está dispuesto a comunicarse de manera efectiva y a trabajar con y como parte del equipo.
Los ingredientes clave de una historia de usuario son: quién es el usuario, qué quiere hacer el usuario y por qué lo necesita. Contrario a lo que mucha gente cree, las personas (usuarios o consumidores finales, expertos con el conocimiento, interesados, patrocinadores y otras personas impactadas por la historia), constituyen lo más importante de una historia de usuario. Esto permite o posibilita la comunicación para que hagamos las cosas correctas y nos ayuda a identificar el valor para priorizar lo que haremos primero y lo que haremos más adelante.
La parte “conversación” de una historia de usuario idealmente es una colaboración entre el usuario y el equipo que construye la solución, es una asociación para entender el problema y trabajar precisamente en una solución que resuelva ese problema y también permite confirmar más adelante que esa solución de hecho resuelve el problema adecuadamente.
Las historias de usuario proporcionan un entorno, un medio para adaptarnos, para buscar oportunidades. Si encontramos un obstáculo que no es posible sortear, siempre podemos buscar otra historia relacionada que nos permita avanzar. Es posible que, al hacerlo, encontremos la solución a la historia que no nos permitía progresar en principio y podemos volver a ella.
Ahora bien, si esa carta de intención, esa necesidad que tiene el usuario, es muy específica, la tarea del equipo es preguntar “¿por qué?” ¿Por qué y para qué se necesita esa historia?; en cambio, si es muy abstracta, preguntaremos “¿cómo?” ¿Cómo lo hace? ¿Cómo quiere o quisiera la solución? Las historias de usuario siempre son sobre “negociación” si queremos un buen balance entre costo y valor.
En general, las historias de usuario nos permiten a los Agilistas fantásticos:
1.     Lograr este balance en pequeños alcances,
2.    Construir la solución, o los incrementos de esta, de tal manera que podamos obtener una efectiva retroalimentación anticipada.
3.    Trabajar en los aspectos de más valor primero para que sean entregados y empiecen a generar ROI lo más pronto posible.
Finalmente, ninguna discusión o exposición sobre historias de usuario estaría completa si no incluimos la palabra “confianza”. Si la confianza es poca en un equipo Scrum, las historias de usuario se convertirán muy pronto en piezas muy concretas de descripciones de problemas que el Dueño de Producto le entregará al equipo de desarrollo y que quizás nadie querrá resolver. Si esto ocurre, seguramente el equipo de desarrollo también va a solicitar, con grado de exigencia, unos criterios de aceptación muy concretos. El resultado: el muy pesado, extenso y falto de humanidad documento de especificación de requisitos funcionales y no funcionales del pasado, el mismo que cargaba consigo el sinsabor de la frustración y la derrota.
Entonces, para que positivamente las historias de usuario sean una herramienta auténtica de negociación entre las áreas de TI y las del negocio y para que sean una representación de los problemas de este último y de las soluciones que puedan proporcionar los primeros, es necesario que en el ambiente haya un alto grado de confianza. El Equipo Scrum en pleno, e incluso los interesados del entorno, tienen que conformar un equipo propiamente dicho, donde el trabajo colaborativo, la adaptación, el mejoramiento continuo y la entrega continua de valor sirvan de pilares y de integradores entre sus miembros para que todo lo anterior sea posible.

sábado, noviembre 26, 2016

User Story Mapping - Una introducción


El User Story Map es una herramienta que permite generar una representación visual del producto completo. Ofrece una vista general de todas las funcionalidades que lo componen (the big picture) de punta a punta. 

Permite identificar Historias de Usuario faltantes en el Backlog, planificar Releases (entregas) dividiéndolo en porciones (Slicing) y visualizar cómo se distribuyen las funcionalidades de acuerdo a las diferentes áreas del sistema.

Son diferentes a los backlogs típicos de historias de usuario en cuanto: 

  • Hacen visible el flujo de trabajo o la cadena de valor
  • Muestran las relaciones entre historias más grandes y sus historias hijas
  • Ayudan a confirmar la completitud del backlog
  • Proporcionan un contexto útil para la priorización
  • Permiten planear entregas (releases) en porciones valuadas y completas de funcionalidad

En esta presentación, basada en el trabajo de Jeff patton, hago una breve introducción al tema de User Story Mapping. La pueden descargar de:


martes, noviembre 08, 2016

Más de cómo ser un Scrum Master extraordinario

Créditos de la foto: Dean Potter's solo walk at Taft Point in Yosemite by Photographer Jeff Cunningham.
Entender que Scrum no es una metodología sino un marco de trabajo (framework) que propone unos pocos lineamientos ayuda. No existen reglas que apliquen a todos y cada uno de los escenarios posibles donde se usa, solo algunas prácticas que han funcionado en algunas organizaciones con anterioridad.
Como Scrum Master o Coach ágil necesitas determinar o encontrar por tu cuenta lo que funciona para la Organización con la que estás involucrado. Si lo logras, lo conviertes en un destino, no en un proceso. De eso se trata el empirismo.
Ser Scrum Master o Coach ágil es principalmente acerca de liderazgo y coaching. No es un rol de gestión. No eres un gerente de proyectos ni de personas. Además, ser Scrum Master o Coach ágil definitivamente no es acerca de reforzar los procesos.
Scrum no está diseñado para Contadores. Algunas métricas son útiles para entender la salud de un equipo Scrum pero por lo general insistir en “cumplir con distintas KPI” (como por ejemplo ‘compromisos versus velocidad’) no ayuda. Si eres un Scrum Master excepcional seguro mantendrás a tu equipo libre de esta clase de presión.
Scrum no tiene mucho que decir sobre el proceso que habilita al Dueño de Producto a llenar el Backlog con historias de usuario de valor, usables y factibles. El descubrimiento del producto basado en Lean UX, Design Thinking o Lean Startup puede ayudar a esta causa. Un Scrum Master extraordinario quiere o querrá que su equipo sea parte de esta carrera evolutiva – por ejemplo, haciéndolos partícipes de entrevistas con los usuarios o haciendo experimentos.
La comunicación del equipo con los interesados no debería ser únicamente a través de un guardián o “proxy” (por ejemplo, solo a través del Dueño de Producto). Hacerlo así hiere de gravedad la transparencia y afecta negativamente el desempeño del equipo. Las revisiones de Sprint son una buena forma de presentar el valor entregado por el equipo durante el Sprint que está finalizando pero también es una buena manera de estar en contacto cercano con los interesados.
Si quieres llegar a ser un Scrum Master extraordinario enfoca tu energía en construir un entorno grandioso para tu equipo, probablemente así no tendrás que pasarte la vida, tu fantástica vida como Scrum Master, removiendo impedimentos.
De esta manera encontrarás ese balance del que habla mi amigo Johhny Ordoñez* y que requiere la Agilidad Moderna para seguir evolucionando y seguir transformándonos en mejores personas cada día, ese balance a nivel personal, de equipo, de grupo, de organización y de sociedad.
-----
Más sobre cómo ir de Scrum Master bueno a Scrum Master grandioso en http://www.gazafatonarioit.com/2015/05/de-scrum-master-bueno-scrum-master.html

miércoles, noviembre 02, 2016

Planear sprints en horas y no por puntos


Hace algunos días nuestro amigo Carlos Jaramillo nos preguntaba a algunos colegas si estábamos de acuerdo con el legendario Mike Cohn cuando dice que los sprints deberían planearse con horas y no con puntos. Carlos se refirió específicamente al artículo Why Sprints Should Be Planned with Hours, Not Points (Por qué los sprints deberían planearse con horas, no con puntos).

Como lo dice Cohn al inicio de su artículo, para mí y creo que para muchos de los que hemos leído su libro Agile Estimating and planning (Estimación y Planificación Ágil) fue una sorpresa cuando vimos el título ya que sabemos que él es un gran referente y promotor de los puntos de historia y de su uso. Pero pasemos a la que fue mi respuesta entonces:

¡Estoy de acuerdo!

En particular, estoy de acuerdo con Mike cuando dice que “los puntos (de historia) son demasiado imprecisos para ser útiles en el corto plazo”, es decir, en un sprint de menos de un mes. También me gustaría destacar aquello de que la velocidad, aunque ligeramente, puede variar de sprint a sprint.

Además de lo que dice Cohn en su artículo algunas otras razones me llevan a pensar así:

No hay una correlación directa entre puntos de historia y el esfuerzo de implementación de la historia de usuario. Es decir, no existe tal regla o ley que señale que si un punto de historia toma H horas implementarse, N puntos de historia tomarán N x H horas implementarse (por ejemplo: si la implementación de una historia de un (1) punto toma 25 horas, entonces la implementación de una historia de 2 puntos tomará 50 horas, no).

Es probable, eso sí, que al final, después de muchos sprints, el promedio muestre tendencia hacia esos números, pero nada evita, en el escenario propuesto, que una historia de 2 puntos le tome al equipo 15 horas y otra también de 2 puntos le tome 35 horas para implementarla o cualquier otro número, incluso podríamos tener una historia de 2 puntos cuya implementación tome 10 horas o menos. En cualquier caso, eso apenas sería la tendencia natural.

Además, aun con ritmo sostenido y con entrega de valor constante en cada sprint, no es lo mismo un equipo en el primer sprint del proyecto que en el séptimo o en el décimo noveno. No es lo mismo un equipo en abril que en septiembre o en diciembre. No es lo mismo un equipo si el proyecto va bien desde varios puntos de vista, como el valor entregado, la calidad, el consumo de presupuesto, etcétera, o si va regular o mal; y no es lo mismo si el equipo y aun la organización a la que pertenece han estado mejorando continuamente o si su crecimiento personal y profesional se ha estancado por acción del proyecto.

Todos esos factores que acabo de mencionar impactan positiva o negativamente la motivación del equipo y por consiguiente, el rendimiento de los miembros del equipo. Lo que finalmente se traduce en número de horas de esfuerzo necesarias para implementar una historia, o sea, para llevarla de ‘Propuesta’ o ‘En proceso’ a ‘Terminada’.

La misma calidad y el tamaño de las historias de usuario también afectan de una forma u otra el esfuerzo requerido para su implementación. Me refiero a la calidad con que son comunicadas al equipo por el Dueño de Producto o por quien corresponda, así también perturba de manera distinta una historia de 2 puntos que una de 5 o una de 8.

Y todo esto para concluir que en cada Planificación de Sprint se debe hacer el ejercicio de, precisamente, planear por horas de esfuerzo, de eso se trata esta ceremonia inicial de Scrum después de todo. La gran diferencia con la planificación de los métodos tradicionalistas es que no vamos a planear seis meses de trabajo o un año o dos, no, se trata solo de adelantarnos a lo que va a pasar en las próximas 2 semanas de trabajo, quizás tres.

Nuestros equipos deben o deberían tener el conocimiento y la experiencia para decirle al Dueño de Producto y al mismo Scrum Master, al final de la Planificación, cómo intentarán hacer su trabajo en el sprint que comienza y eso incluye contarnos el número de horas de esfuerzo que tomará implementar una historia de usuario en particular. Se trata es de dilucidar cuando nos tomará el diseño, la programación, las pruebas, la integración, la documentación y cualquier otra actividad concerniente a la construcción de la historia. Después de todo, para eso fue que precisamente se conformó el equipo.

¡Pero hay más!

Usamos Puntos de Historia para estimar el backlog y el esfuerzo a mediano y largo plazo porque son o representan un valor abstracto. También sabemos que es posible usar otros métodos abstractos de estimación como 'tallas de camisetas', días ideales, colores, tamaño de los planetas o, incluso como dice mi amigo Jorge Abad en sus Lecciones Aprendidas, podemos usar la técnica del ‘ojo de buen cubero’, estimar con Garrapatandamandapispuntos o con cualquier otra medida cuyas convenciones sean bien conocidas por todo el equipo.

El precepto fundamental aquí es que todos estos métodos producen estimados y los estimados, sobre todo en software, están condenados al error. Casi 50 años de experiencias después de aquella remota conferencia de la OTAN en Garmisch en la que de alguna manera se dio vida a la Ingeniería de Software nos han demostrado eso.

En cualquier caso para estos escenarios de mediano/largo plazo, si un usuario o cliente está exigiendo estimar en horas un proyecto Ágil, todavía no ha entendido el enfoque y necesita guía en ese sentido. Las horas son algo concreto sí, pero solo para lo que he explicado arriba, estimar un sprint corto o muy corto, de muy pocos días a dos semanas.

Pero igual que con los puntos, estimar con horas no nos eximirá del error inherente a las estimaciones. Así que en vez de salir corriendo detrás de las horas, deberíamos enfocarnos en habilitar y empoderar nuestros equipos para que hagan un mejor trabajo.
----------
¿Ustedes qué creen? ¿Cómo estiman los sprints? Déjenmelo saber en el foro.


----------
Más sobre Planificación en:



El artículo de referencia de Mike Cohn lo pueden encontrar en: