miércoles, 20 de mayo de 2020

¿Cómo afectan los requerimientos no funcionales a la pila de producto?

Los requerimientos funcionales como restricciones
Los requerimientos no funcionales, o NFRs (nonfunctional requirements), representan cualidades generales y restricciones que afectan aplicaciones y sistemas enteros; por tanto afectan a los epics e historias de usuario, que a diferencia de los NFRs definen junto a y sus criterios de aceptación comportamientos y funciones específicas. Una historia de usuario no se puede considerar hecha si no cumple con los requisitos no funcionales asociados.

Los requerimientos no funcionales aseguran que el sistema cumple con cualidades como la usabilidad, seguridad y otras como las que siguen:

Accesibilidad Confiabilidad Disponibilidad Interoperabilidad Operabilidad Fiabilidad Seguridad
Extensibilidad Trazabilidad Rendimiento Recuperabilidad Mantenibilidad Certificación Robustez
Compatibilidad Conformidad Escalabilidad Implementabilidad Configurabilidad Eficiencia Usabilidad

La implementación de nuevos NFRs suele requerir de nuevos elementos en la pila de producto en forma de historias técnicas, estas, una vez incluidas en un sprint, evolucionan el sistema a nuevas restricciones.

Para el cumplimiento de los NFRs se suelen reflejar las restricciones en los criterios de aceptación de las historias de usuario; si se trata de restricciones persistentes se suelen añadir como elementos nuevos en la en la definición de hecho (DoD).

Como todo requerimiento los NFRs se han de describir y cuantificar para arrojar claridad sobre los mismos. Un patrón para describir NFRs es el siguiente:

Paso 1
Nombre (Name): [en forma de cualidad.subcualidad]
Escala (Scale): [Qué medir (unidad)]
Métrica (Meter): [Cómo medir (método)]

Paso2
Objetivo (Target): [Nivel de éxito a alcanzar]
Restricción (Constraint): [Nivel de fallo a evitar]
Línea base (Baseline): [Nivel actual]

Veamos un ejemplo partiendo de la siguiente historia de usuario relacionada con una librería on-line:

Como cliente
Quiero poder explorar libros
Para poder escoger el que voy comprar

para la que hemos determinado el tiempo de respuesta como requerimiento no funcional, ya que si la página tarda en cargar más de 3 segundos el comprador buscará otras opciones a poco más de un click de distancia:

Paso 1
Nombre: usabilidad.rendimiento
Escala: milisegundos entre que el comprador clica "buscar" y se le presenta la página con el resultado
Métrica: promedio de los tiempos de búsqueda de libros

Paso2
Objetivo: <200 milisegundos (lo que Google considera como tiempo de respuesta máximo)
Restricción: >3000 milisegundos (cuando el comprador empieza a sentir ansiedad)
Línea base: 1800 milisegundos

domingo, 17 de mayo de 2020

¿Es necesario que una PI Planning dure dos días?

Si, ¡¡¡absolutamente!!! Estamos hablando de alrededor de 100 a 125 personas haciendo una planificación trimestral, pero no es por el volumen de personas, sino por la naturaleza del evento por lo que son necesarios 2 días. El patrón de la PI Planning podría verse como sigue:

Día1: Intención -> Borrador del plan -> Crisis ->Día 2: Plan inicial -> Alineamiento
  • Intención: representada por los elementos de la pila de producto, en este caso de programa a nivel de tren (ART), esto no es más que el deseo de las capa estratégica y Product Management.
  • Borrador del plan: hasta que las personas expertas que vayan a hacer el trabajo no hayan revisado la pila de producto y creado un plan factible, recordemos que los equipos de desarrollo saben mejor que nadie qué es posible y qué no, no podremos iniciar una ejecución con garantías de éxito.
  • Crisis: el borrador del plan puede representar una auténtica jarra de agua fría de realidad para Product Management. Es el momento de la crisis, de cotejar deseo con factibilidad y tomar decisiones. Recordemos que crisis también significa oportunidad.
  • Plan inicial: para converger la factibilidad un poco más hacia la intención podemos darle una segunda vuelta de tuerca a los planes, basándonos en ajustes identificados en la crisis.
  • Alineamiento: los planes iniciales representan la factibilidad, y si negocio los acepta habrá pleno alineamiento entre negocio y ejecución, queda claro lo que es posible construir y los equipos se sienten convencidos del plan inicial. Esto lleva a su vez al compromiso y a tener todos los números para un plan inicial que admita cambios y que termine en una ejecución exitosa.
La razón del porqué de dos días está en la crisis, en el evento de revisión de managers (management review) que ocurre al final del primer día:
Agenda de una PI Planning con los puntos a tratar y quienes intervienen en cada paso - gracias Ángel por la foto
Para la revisión de managers los equipos de desarrollo habrán terminado su jornada y se habrán ido a casa, quedan los Business Owners, Product Managment, RTE, arquitectos y otros líderes y directivos que han recibido un plan impregnado de realidad que probablemente no cuadre al 100% con sus deseos expresados en la pila. Es el momento de aprendizaje sobre lo que es factible, y decidir que ajustes hacer para llevar el segundo día de la PI Planning para acercar así los planes un poco más al deseo. Preguntas que deben de hacerse los managers:
Preguntas en la revisión de managers - cortesía de Pixabay
  • ¿Qué acabamos de aprender?
  • ¿Necesitamos ajustar la visión? ¿Alcance?
  • ¿Necesitamos ajustar la dotación de personal?
  • ¿Hay cuellos de botella?
  • ¿Esta solución será viable a largo plazo?
  • ¿El plan equilibra los objetivos de negocio y de TI?
  • ¿Qué decisiones debemos tomar entre hoy y mañana para resolver las brechas?
Los ajustes resultantes son cosas que comunicaran a los equipos al día siguiente para que éstos replanifiquen en la medida de los posible, son ajustes del tipo:
Resaltar que los ajustes no pueden ser directamente sobre los planes de los equipos, eso les quitaría la propiedad sobre sus planes y por tanto anularía su compromiso. Vayamos pues al porqué de PI Plannings de dos días.

Estamos acostumbrados a la contabilidad de costes poniendo el foco en la eficiencia y en la productividad, y desde esta perspectiva parece que hacer la PI Planning en un día es más eficiente y menos costoso. La realidad es que esa perspectiva ignora el coste de la demora, el coste por no hacer la PI Planning en dos días, el coste por no obtener un plan verdaderamente factible y comprometido por todo el mundo.

Mentes cansadas que han de crear el plan inicial al final de una larga jornada no tendrán el estado mental óptimo para un plan de este calibre. Con una PI Planning de dos días, donde el plan inicial lo elaboran personas despiertas y lúcidas, evitará meses de posibles retrasos por un plan elaborado sin la dedicación adecuada.

jueves, 14 de mayo de 2020

¿Cómo ha de ser la relación entre el equipo y los usuarios?

Clarificación versus priorización - imágenes cortesía de
Pixabay: usuarios, Propietario del Producto y equip de desarrollo
Esta es una pregunta clásica de personas que vienen de entornos más tradicionales donde el equipo raramente interactúa con los usuarios y/o el cliente. Recordemos el cuarto principio del Manifiesto Ágil que establece que:

Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto

por tanto debe de existir una estrecha relación entre unos y otros. Las diferentes relaciones entre los responsables para construir el mejor producto posible las debe de fomentar el Scrum Master, me gusta decir que el Scrum Master tiende puentes para conectar los diferentes roles.

Las tres relaciones clave para construir un producto competitivo son como siguen:
LeSS, el marco de escalado para las empresas más maduras en Agilidad, lo muestra claramente en la siguiente imagen:
Product Backlog Refinement en LeSS

martes, 12 de mayo de 2020

¿Cómo potenciar la polinización cruzada entre equipos?

Una de las preocupación de Recursos Humanos ágiles, para con sus trabajadores de conocimiento, debe de ser su capacitación continua para asegurar que tengan las habilidades y las informaciones correctas para poder desempeñar sus funciones así como la toma de decisiones descentralizada. En un ambiente sistémico de equipo de equipos, como las tribus o los trenes (ARTs), el conocimiento está en todos los individuos del sistema en forma de mente colectiva. Para mantener esa mente colectiva y difundir el conocimiento a todos, es esencial fomentar la colaboración autoorganizada en forma de polinización cruzada.

La polinización cruzada se basa en individuos que comparten conocimiento, no solo aprovechando conocimiento de otros, sino también motivándose al compartir su conocimiento de forma proactiva. La polinización cruzada creará vínculos entre individuos con intereses similares desde los que pueden surgir grandes ideas e iniciativas.

Una de las mejores propuestas que he experimentado son las que hacen Craig Larman y Bas Vodde con los "Travelers" y "Scouts":
Travelers y Scouts, de Large-Scale Scrum: More with LeSS de Craig Larman y Bas Vodde
Travelers: una forma temporal de viajero que adopta un miembro de equipo experto cuyo objetivo es difundir su conocimiento, probablemente escaso, con los demás equipos, y así explotar y romper cuellos de botella creando esas habilidades en otros. Estos pueden unirse en cada sprint a un equipo diferente para enseñar y mentorizar a los demás mediante pair programming y talleres y sesiones de entrenamiento. Es importante destacar que éstos no realizan el trabajo que requiere de su expertise, enseñan al equipo a hacerlo.

Aunque los travelers no se hayan ideado para formentar la coordinación y la colaboración, al unirse a diferentes equipos crean o fortalecen la tribu o al tren, que es exactamente lo que se necesita para los canales informales de coordinación y colaboración.

Scouts: una técnica simple para la colaboración entre equipos es enviar un Scout a aprender algo de otro equipo, para después traer el aprendizaje al propio equipo. Un evento ideal para iniciar una acción de Scout es atender a la reunión diaria del equipo visitado. Es importante destacar que no debe de ser el Scrum Master el que haga de Scout, quien debe de llevarse el conocimiento es alguien que luego los use en su día a día, por tanto ha de ser un miembro del equipo.

jueves, 7 de mayo de 2020

¿Porqué Scrum se basa en equipos funcionales?

Los equipos funcionales son equipos que están compuestos por miembros con las diferentes habilidades y especialidades necesarias para poder construir funcionalidades, componentes de sistemas o historias de usuario de principio a fin. Son equipos con continuidad a largo plazo de entre 3 a 9 miembros colocalizados que se mantienen unidos e integrados para un mayor rendimiento, y aunque los miembros puedan tener habilidades especializadas y áreas en las que estén más enfocados, la responsabilidad recae en el equipo como un todo.

A diferencia de estos, los equipos de componentes están formados por grupos, usualmente temporales, de personas cuya área principal de preocupación se centra en un componente específico o conjunto de componentes del sistema, con una responsabilidad individual sobre "su" parte según su especialización.

Actualmente estoy realizando un curso de LeSS en on-line con Gene Gendel, y la siguiente imagen me inspiró a ver la importancia de los equipos funcionales desde la perspectiva de donde se encuentre la complejidad.
Equipos de componentes versus equipos funcionales - Feature Teams
La complejidad en los equipos de componentes se encuentra entre la pila de poducto y los equipos, en como los equipos toman los elementos de la pila y que dada a su especialización tienen que coordinarse para pasarse el elemento de uno a otro. Usualmente habrá un Propietario del Proyecto focalizado en distribuir y coordinar estos elementos entre los equipos; intentará optimizar el flujo entre equipos, gestionar las dependencias y lidiar con bloqueos y cuellos de botella, en vez de focalizarse en el valor que aportan los elementos al usuario/cliente. Esto por ende convertirá al Propietario de Producto en un gestor de complejidad en forma de jefe de proyecto.

Dado que los equipos de componentes son especializados y se les medirá por las tareas de su especialidad, su interés por colaborar será mínimo y prácticas colaborativas como Sprint Planning 1, Big Room Planning o PI Planning, que podrían resolver la complejidad, no funcionarán.

En el caso de los equipos funcionales, que construyen los elementos de la pila de producto de principio a fin, el Propietario del Producto no ha de preocupare de qué equipo construye qué, y puede focalizarse en la pila, en interactuar con usuarios/clientes y maximizar el valor de negocio. La complejidad está entre los equipos y las funcionalidades o componentes a construir, cuando varios equipos trabajan al mismo tiempo en las mismas funcionalidades o componentes.

Pero esa complejidad tiene solución con técnicas y prácticas conocidas desde hace tiempo con eXtreme Programming y ahora con DevOps. La integración continua facilita la propiedad del código compartido, las pruebas automatizadas aseguran que los componentes sigan comportándose como es esperado después de cada cambio, los despliegues por lotes pequeños que permite DevOps rebajan el riesgo de despliegues fallidos, y su posible impacto, de forma dramática... y quizá debamos de recalcar que las automatizaciones, si están bien implantadas, no fallan nunca, en cambio, el ser humano en su naturaleza, cuyo valor es su creatividad y emocionalidad, es limitado en la amplitud de lo que pueda percibir y abarcar en un mismo momento, y comete errores en cuestiones repetitivas y no motivantes.

viernes, 1 de mayo de 2020

¿Cuál ha de ser el tamaño de una pila de producto?

Granularidad de pila de producto
Tener una pila de producto con un tamaño adecuado es esencial para una buena operativa. Una pila demasiado pequeña se "quema" demasiado rápido y existe el riesgo de que el equipo se quede sin historias de usuario y por tanto sin trabajo. Una pila demasiado grande implica que hay un montón de historias de usuario en ella que son irrelevantes y crean ruido.

Las últimas dos terceras partes de una pila demasiado grande seguramente vayan a cambiar en el futuro, y no vale la pena invertir esfuerzo en gestionar historias que sabemos que van a cambiar. Por otro lado una pila demasiado grande afecta seriamente a la capacidad para administrar las historias de usuario de valor, porque nos sumiremos en tratar con cientos de historias posiblemente irrelevantes o simplemente incorrectas o duplicadas. Lo más grave es que desviará nuestro foco del descubrimiento de nuevas historias de valor para nuestros clientes y no seremos capaces de actualizar las historias existentes a medida que obtengamos nueva información fresca.

No es inusual ver casos disfuncionales en los que la pila tiene más de 300 historias y el equipo que las construye tiene una velocidad media de 5 historias por sprints de dos semanas.

Una buen tamaño resulta en una parte superior de la pila de producto con 2 a 3 sprints de historias que cumplan con la definición de listo (DoR), y el resto de elementos que conformen la release en curso con elementos menos granulares en forma epics. La siguiente release debería de tener epics y temas, y las releases futuras solo grandes elementos como los son los temas.
Las pilas anidadas que forman la pila de producto en el marco de SAFe
Si nos hacemos la misma pregunta en un marco de escalado como SAFe® hemos de recordar primero que la pila de producto estará divida en varias pilas anidadas y mirar cada una de ellas:

Pila de equipo (Team Backlog): el tamaño de la pila queda limitado a las historias de usuario que el equipo haya incluido en la PI Planning para el siguiente PI, un periodo de tiempo de entre 2 y 3 meses. En mi experiencia estamos hablando de entre 20 y 40 historias de usuario.

Pila de programa (Program Backlog): un tren (ART) o tribu gestiona en su tablero Kanban aproximadamente tantas features como las que pudiera construir el tren en 3 PIs, un periodo correspondiente de entre 6 y 9 meses. En mi experiencia estamos hablando de entre 20 y 40 elementos, de los que entre 10 y 15 son pila del PI en curso.

Pila de solución (Solution Backlog): para los trenes de trenes, los Solution ART, los números en capabilities, muy grandes features, son similares.

Pila del portfolio (Portfolio Backlog): el tamaño dependerá de la pila con iniciativas estratégicas, o epics en SAFe, y dependerá de cuantas lineas de negocio cubra y cuantos trenes o personas estén asociadas a sus Value Streams. En un portfolio con un solo tren de unas 120 personas tiene sentido un tablero Kanban que gestione de 10 a 15 epics anuales y que tenga alrededor de 3 en curso; en un portfolio con trenes que sumen unas 2000 personas tiene sentido un tablero Kanban con alrededor de 150 epics anuales, con entre 30 y 40 en curso.

Estos números son números que he recolectado en diferentes clientes y experiencias, y que no pretenden ser nada más que para dar una idea aproximada.


Ningúna pila visible para el equipo debe de tener más de un trimestre corrido de trabajo proyectado. Más sería desperdicio.
Diana Larsen, del meetup "How do limits empower your Agility?"

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

sábado, 25 de abril de 2020

¿Qué mentalidad debe de haber detrás de Design Thinking?

El proceso de Design Thinking
Recordemos que Design Thinking es un proceso de desarrollo centrado en el cliente para crear productos deseables y que sean rentables y sostenibles durante su ciclo de vida. Se centra en la comprensión de la necesidad a resolver, el contexto en el que se utilizará el producto y como este ha de evolucionar. Como podemos ver Design Thinking se focaliza en el proceso, en las herramientas y las prácticas asociadas.

Lo que nos lleva a la pregunta de cuál debe de ser la mentalidad que debe de haber detrás, de como es la mentalidad que coloca al cliente en el centro de la estrategia de producto. La conocemos como customer centricity, o centricidad en el cliente, y es una mentalidad y una forma de hacer negocios que se enfoca en crear experiencias positivas para el cliente a través del conjunto completo de productos y servicios que ofrece la empresa. Esto nos lleva a una frase de UX (User Experience):

Una buena experiencia de cliente es retorno de inversión garantizado

Toma de decisiones teniendo en cuenta a los clientes - cortesía de Pixabay
Las empresas centradas en el cliente toman decisiones teniendo en cuenta como estas afectan a sus clientes y usuarios. Su mentalidad está impregnada de consideraciones como las que siguen:
  • Nos centrarnos en el cliente: utilizamos la segmentación de clientes para alinearnos y enfocarnos en segmentos de clientes objetivo.
  • Queremos comprender las necesidades del cliente: no solo escuchamos las solicitudes de nuestros clientes, sino que también invertimos esfuerzo y tiempo para identificar las necesidades subyacentes y continuadas de los mismos.
  • Intentamos pensar y sentir como el cliente: intentamos ponernos en el punto de vista de nuestros clientes.
  • Construimos productos que son soluciones completas: diseñamos nuestros productos de forma evolutiva para dar solución en todo momento a las necesidades emergentes de nuestros cliente.
  • Conocemos el valor a largo plazo del cliente: fomentamos relaciones de partnership con nuestros clientes para que, entendiendo el valor que nuestro producto les aporta, nos hagamos crecer mutuamente.
Los clientes nos recordarán por lo que les hemos hecho sentir, por haberles hecho sentir que importan, y no por los servicios y productos que les hayamos brindado. Esto también es válido para los coaches ágiles y trainers; los equipos, Propietarios del Producto, Scrum Masters, interesados, lideres y alumnos nos recordarán por como nos hemos preocupado de ponernos en su piel y acompañarles, entrenarles y enseñarles desde sus necesidades.