¿Son aplicables los Poka-Yoke al desarrollo de software?

El Poka-Yoke es un sistema de prevención de errores utilizado en manufactura lean para minimizar el desperdicio, literalmente significa "a prueba de errores". Un dispositivo Poka-Yoke es cualquier mecanismo que ayude a prevenir errores antes de que ocurran y, este se puede diseñar con dos funciones, para prevenir errores para advertir sobre estos:

Función de control: que imposibilita de algún modo el error, como por ejemplo una tarjeta de memoria SD o un conector USB que no se puede enchufar de manera equivocada.

Función de advertencia: que resalta el error cometido de tal manera que sea obvio para el que lo haya cometido, como por ejemplo el pitido del coche cuando sacamos la llave del contacto si las luces están encendidas.

Los dispositivos Poka-Yoke fueron introducidos por el ingeniero Shigeo Shingo en Toyota en la década de 1960, y forman parte de lo que se conoce actualmente como Sistema de Producción Toyota. 

Las características principales de un buen dispositivo Poka-Yoke son:

• Es sencillo
• Es parte del proceso
• Está puesto en el lugar donde ocurre el error

Las pruebas de software son una forma de dispositivo de detección, no tanto las pruebas en su forma tradicional que se producen demasiado tarde en el proceso de para permitir una retroalimentación rápida, pero si las pruebas unitarias, las pruebas de humo y las pruebas automatizadas. Estas se acercan a la noción de Poka-Yoke ya que se encuentran cercanas al momento de los errores potenciales, y su respuesta rápida permite evitar que los errores se propaguen a lo largo del proceso.

A quién esté interesado en técnicas Poka-Yoke para la detección de errores en la construcción de software lo invito a leer el artículo de Harry Robinson "Using Poka-Yoke Techniques for Early Defect Detection".

¿Cómo incrementar la velocidad del equipo?

Incrementar la velocidad,
cortesía de Clipart Panda

Este post nace de la consulta de un alumno que empezaba su duda con "Leyendo sobre literatura acerca del uso de historias de usuarios he encontrado en varios textos la siguiente afirmación: si las historias de usuario están listas o ready (DoR) para su implementación, el equipo de trabajo puede duplicar su velocidad de desarrollo. También se afirma que la introducción de los criterios de aceptación y la definición de hecho (DoD) ayudan a incrementar la velocidad del equipo...".

Con solo el hecho de implementar Scrum se propicia la creación de equipos ganadores, equipos maduros en Agilidad de los que se habla de hiperproductividad, en que su velocidad, partiendo de equipos clásicos como se constituyen al principio en los proyectos con metodología tradicional, se puede incrementar de media un 400%. No hay magia ni heroicidad en ello, son diversos factores para los que Scrum crea el ambiente idóneo, los que hacen que un equipo incremente su velocidad de esta forma tan espectacular:

• La comunicación, la conversación en las reuniones y la creación de una base de conocimiento compartida
• La integración y la confianza entre los miembros
• Un objetivo común a nivel de equipo
• La ayuda entre miembros para formarse, desbloquear tareas y compartir ideas
• Los canales de comunicación abiertos entre equipo de desarrollo y negocio
• El compromiso adquirido, siendo el equipo quién pone los límites del sprint
• La autogestión y autoorganización que propicia el control sutil (el autocontrol)
• Planificación constante (daily-scum) que irradia la situación y da sensación de avance
• El ritmo de entregas periódico con el reconocimiento de trabajo bien hecho a final de sprint
• Y como no, las pizzas y cervezas, el team-building :-)
• Y finalmente también DoR (Definition of Ready) y DoD (Definition of Done)

Tener las historias de usuario susceptibles de entrar en el siguiente sprint cumpliendo con DoR (definición de listo), significa que los usuarios (o Propietario del Producto) han hecho sus deberes y están listas para comunicarlas al equipo de desarrollo con todo el detalle necesario. Con ello el equipo de desarrollo tendrá muy claras las ideas sobre lo que han de codificar y el código que escriban se ajustará realmente a los requisitos, haciendo que el equipo sea más eficiente y que se evite el retrabajo.

Los criterios de acepación y DoD (definición de hecho) extreman la eficiencia, si el programador sabe qué criterios ha de satisfacer de antemano tiene muchos puntos para hacer un software excelente, ya que el código que escribirá cumplirá con todos los criterios de aceptación (que son de negocio y técnicos) y cumplirá con la definición de hecho, que es aplicable a todas las historias, lo que permitirá darlas como realmente finalizadas en la revisión de sprint.

¿Qué significa cuando en Scrum se habla de trabajar por fases solapadas?

En un proyecto en cascada las fases en que se desarrolla este son secuenciales, una fase seguida de la siguiente. A priori esto parece que sea de lógica aplastante: 

• Piensa lo que quieres
• Escribe lo que has pensado
• Efectúa un plan sobre lo que has escrito
• Sigue tu plan para construir lo que has pensado

Pero si lo pensamos un poco más a fondo nos daremos cuenta de que eso nos obliga a tener todo muy claro al principio del proyecto, lo que no se piensa de entrada no tiene lugar después. Una buena idea que aparezca a medio proyecto puede convertirse en una verdadera pesadilla. Y todos sabemos que los proyectos de TI varían y cambian...

Scrum se basa en fases solapadas, estas se pueden imaginar como que a principio del proyecto se inicia de forma gradual un flujo por cada especialidad/rol necesarios para el proyecto, flujo que durará hasta finalizar el producto. Se inicia un flujo de análisis que irá por delante del de desarrollo, y a la vez este irá por delante del de las pruebas, por ejemplo:

Fases solapadas, cortesía de Scrum Manager

En el sprint 0, que es un sprint para preparar el entorno, la tecnología, las herramientas, etc., el Propietario del Producto trabaja con el cliente las historias de usuario susceptibles de entrar en el sprint 1.

Mientras el equipo trabaja en las historias del sprint 1, el Propietario de Producto trabaja junto con el cliente en las historias susceptibles para entrar en el sprint 2. Resaltar que se produce un flujo de toma de requisitos que va por delante de desarrollo y está solapado con este. Dentro del equipo tenemos algo similar, ciertas historias pueden requerir de un análisis para diseñar la solución y no es hasta que se termine este que se empieza a desarrollar. Probablemente analista y desarrollador sean el mismo, pero sus actividades son secuenciales y solapadas con otras actividades de otros miembros.

¿Qué conexión hay entre Scrum y el Budismo?

Un buen Scrum Master es difícil de encontrar:
Las personas ilustradas están por todas partes,
¡pero un buen buda de madera es difícil de encontrar!

Dice la leyenda que Jeff Sutherland es un monje budista y que sus vivencias en un monasterio budista le proveyeron de valores muy afines al Manifiesto Ágil y eso lo preparó para ser el creador de Scrum. Investigué un poco, leyenda o realidad, monje budista o no, lo cierto es que Jeff nos habla en un artículo sobre la bendita Arya Tara, una diosa tibetana que simboliza la actividad de todos los Budas...

Encontré un artículo "If You See the Buddha in Your Scrum, Say Hi" de Todd Hoff y me animé a resumirlo, enriquecerlo un poco y en definitiva a escribir este post.

Un catedrático en inteligencia artificial del MIT le enseñó a Jeff un robot insectoide donde cada pata tenía su procesador, además de estos tenía otro procesador en la espina dorsal dotado de pocas reglas muy simples y un chip en la cabeza que conocía esas reglas y actuaba como referente de las demás partes. Cada vez que se encendía el robot este aprendía a andar por primera vez, y con cada paso aprendía, se adaptaba y adquiría seguridad. Se trataba de un sistema emergente que se caracteriza por resolver problemas, al menos en apariencia, de forma espontánea: es decir, sin recurrir a una inteligencia de tipo centralizado o jerarquizado (descendente), sino de forma ascendente, desde la base, a partir de elementos relativamente no inteligentes. Y Jeff se preguntó ¿Qué ocurriría si pudiéramos dar con un conjunto de reglas para que las personas trabajaran en equipo como hacen esas patas? Como es de imaginar ese fue un punto de inflexión para Scrum.

Pero volvamos al budismo. Los primeros campamentos permanentes de Buda y de sus seguidores se llamaban Sanghas, estos fueron los precursores de los monasterios budistas, un refugio para los seguidores de Buda durante las lluvias monzónicas. Cuando se juntan personas en convivencia son necesarias ciertas reglas de gobierno como: ¿cuáles son los derechos y obligaciones de cada uno? ¿quién o quiénes están al cargo?, etc. y, ¿cuáles fueron las respuestas de Buda a estas cuestiones?

Buda propugnó la administración descentralizada basada en la autoridad y responsabilidad personal. Por tanto en el Sangha no hay una autoridad central, todos los miembros se consideran iguales. Buda nunca se preocupó de un líder central porque consideraba que cada uno es responsable de sí mismo. Buda era contrario a la coerción, pensaba que los monjes debían de actuar por su propia convicción y no estar forzados a seguir las directrices de nadie. En situaciones de crisis entre diferentes facciones del Sangha, Buda decía que ambas partes debían de tratarse con respeto y buscar la solución por ellos mismos. Esto sitúa claramente a los Sanghas en la autogestión y en la autoorganización de sus miembros, tal como lo conocemos en los equipos ganadores que propicia el marco de Scrum.

Lo que comparten los miembros de la orden son estilo de vida y enseñanzas, y para unir a los diferentes grupos, estos se reúnen cada 6 años para recitar una confesión común de la fe llamada "enlace":

• Abstenerse de todo lo que es dañino
• El logro de lo que tiene valor
• Purificar la propia mente

Esto es lo que enseña Buda.

• Tolerancia y paciencia son las más altas de todas las austeridades
• Y los Budas declaran que el Nirvana es el valor supremo
• Nadie que dañe a otros ha "salido" verdaderamente de la vida en el hogar
• Nadie que hiera a los demás es un verdadero monje
• No criticar, ni hacer daño, comedimiento
• Conocer las reglas respecto a la comida, la cama y la silla individual
• Aplicación en la percepción más alta derivada de la meditación

Esto es lo que enseñan los Seres Despiertos.

Esto no es exactamente el Manifiesto Ágil, pero hay un claro espíritu que comparten ambos.

Buda pensaba que los siguientes valores garantizarían la supervivencia de la Orden:

• Sea consciente, esté espiritualmente alerta, sea enérgico y fiel a las disciplinas de meditación que es lo único le que puede traerle la iluminación
• Evitar actividades torpes como chismorrear y holgazanear
• No tener amigos sin principios y evitar caer bajo el hechizo de esas personas
• No deje su búsqueda a mitad de camino y no esté satisfecho con lo mediocre
• Sea autosuficiente así no necesita depender de ninguna autoridad

Estos valores no tienen relación directa con los valores ágiles, pero hay paralelismos muy interesantes. Es muy significativo que la orden haya sobrevivido 2500 años.

Desde finales del siglo XIX, cuando Marconi comenzó a patentar ideas de otras personas, la innovación dejó de ser colaborativa y se volvió competitiva. La cultura competitiva se extendió e introdujo la formalidad y métodos de control para mantener arriba a los de arriba y abajo a los de abajo para que estos hagan lo que se les dice.

En el siglo XXI los equipos ágiles están desafiando el status quo y el cambio de la forma en que pensamos sobre el trabajo. Para hacer que cualquier cosa crezca se necesita de un ambiente amistoso que le de la fuerza necesaria para estirar de los que se resisten al cambio. Esta corriente de pensamiento, la Agilidad y su capacidad de adaptación al cambio como principal concepto, que se resume en una serie de valores y conceptos paralelos al budismo, ya se considera la principal aportación de la ingeniería de software a la gestión de proyectos, la cuestión es: ¿sobrevivirá la Agilidad 2500 años?

¿Qué es y cuáles son los valores y principios del Manifiesto Ágil?

Cortesía de los autores firmantes del manifiesto, declaran
que este puede ser copiado libremente en cualquier
forma pero sólo en su totalidad - https://agilemanifesto.org

En marzo de 2001, 17 críticos de los modelos de producción basados en procesos, convocados por Kent Beck, se reunieron en Snowbird, Utah, para discutir sobre el desarrollo de software. En la reunión se acuñó el término "Métodos Ágiles" para definir a aquellos que estaban surgiendo como alternativa a las metodologías formales: CMM-SW, (precursor de CMMI) PMI, SPICE (proyecto inicial de ISO 15504), a las que consideraban excesivamente "pesadas" y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo en el momento de mayor incertidumbre.

Los "Métodos Ágiles" no son una metodología, son una mentalidad y un comportamiento guiados por valores y principios. 

Los valores ágiles deben de estar fuertemente interiorizados en quienes nos consideremos ágiles, creemos en ellos y deben de formar parte de nuestro ADN, ya que afectan directamente a como las personas nos vamos a comportar. 

Valores del Manifiesto Ágil:

Los integrantes de la reunión resumieron en cuatro valores lo que ha quedado denominado como "Manifiesto Ágil", que son los valores sobre los que se asientan los métodos ágiles:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

• A los individuos y su interacción, por encima de los procesos y las herramientas
• El software que funciona, por encima de la documentación exhaustiva
• La colaboración con el cliente, por encima de la negociación contractual
• La respuesta al cambio, por encima del seguimiento de un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Principios del Manifiesto Ágil:

Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los principios que de ellos se derivan:

• Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor
• Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente
• Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves
• Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto
• Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea
• 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
• El software que funciona es la principal medida del progreso
• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida
• La atención continua a la excelencia técnica enaltece la agilidad
• La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial
• Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizados
• En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

¿Cómo se realiza la planificación diaria?

Reunión diaria o daily-scrum

La reunión diaria, o daily-scrum, es una reunión de microplanificación del equipo y para el equipo, donde se comparte el estado del trabajo, se hace visible el ritmo de avance, se sincroniza el trabajo y se establece el plan para las siguientes 24 horas, por ende donde se produce la autoorganización.

Entre sus beneficios están los de sacar a la luz puntos en que los miembros pueden ayudarse unos a otros, poner sobre la mesa problemas e impedimentos y tomar medidas como muy tarde a las 24 horas de producirse, y fomentar el aprendizaje y una base de conocimiento común al mostrar cómo trabajan los otros según sus especialidades y experiencias. Es una reunión que conecta a los miembros del equipo en su día a día.

Reunión diaría
gracias a David Jiménez

En la reunión cada miembro explica:

• Lo que ha hecho desde la reunión diaria anterior
• Lo que hará hasta la reunión siguiente (autoasignación de tareas)
• Los problemas que tiene o si prevé tener algún impedimento

Para equipos inmaduros en Scrum es muy importante no cambiar las 3 cuestiones de la reunión, ya que estas están diseñadas para mejorar de forma continua la autoorganización del equipo.

Es una reunión a la que asisten el equipo y el Scrum Master, y a la que pueden asistir el Propietario del Producto y todo tipo de interesados, eso si, como oyentes sin derecho a voz ni voto. La asistencia del Propietario del Producto es deseable si este se limita a resolver dudas, si siente tentaciones de intervenir en la organización del equipo, como puede ocurrir con Propietarios de Producto reciclados de jefe de proyecto, lo mejor es que se aparte hasta que sea capaz de no intervenir.

Lo ideal es hacer la reunión ante un tablero Kanban físico y de pie para que sea breve, de unos 15 minutos de duración. En ella se actualiza el estado de las tareas de tablero, las horas pendientes y el gráfico burndown.

¿Cómo se realiza la planificación de release?

Actualmente estoy diseñando la planificación de release para una compañía que tiene un plan estratégico de transformación ágil. Para ello me he basado en una serie de prácticas usuales en Agilidad y en otras que son directas de Scrum, diseño que quiero compartir en este post.

La planificación de release se encuentra en el tercer nivel de la planificación ágil y consta de dos partes, la obtención inicial de un proceso de negocio (Value Stream Mapping), de una pila de producto (User Story Workshop), con una estimación inicial, y la replanificación de la misma (User Story Refinement) cuando esta se refina y reestima, evento que ocurre con la misma frecuencia que los sprints. El ciclo de los eventos de la planificación se muestra en la siguiente figura:

Ciclo de eventos de la planificación de release

Recordemos que por encima de la planificación de release tenemos la hoja de ruta del producto, y cuando se toma la decisión de abordar una nueva etapa, se ha de desgranarla en sus flujos de valor (procesos de negocio) y efectuar el User Story Workshop para obtener una primera proyección a futuro del producto. Periódicamente, usualmente una vez por sprint, se efectúa el User Story Refinement que tratará los cambios acaecidos, permitirá replanificar y ajustar la proyección a futuro manteniendo el proyecto lo más cercano posible a la realidad.

User Story Workshop

Obtenidos los diferentes flujos de valor a través de talleres Value Stream Mapping, se realiza un User Story Mapping sobre cada uno de los procesos desde los diferentes puntos de vista de quienes interactúan con el sistema (es muy útil hacer una User-Persona de estos para establecer empatía con los mismos). Asisten a este evento, liderado por el Propietario del Producto, quienes conocen el negocio, entre ellos usuarios, así como parte o todo el equipo de desarrollo. Las actividades y conversaciones que se producen tienen un gran beneficio porque abren canales de comunicación entre las personas de negocio y tecnología.

Tableros User Story Mapping y Release Planning de ejemplo

En la imagen se ve un ejemplo que representa un proceso de venta desde el punto de vista del cliente que compra un libro por la web, punto 1. En un carril del tablero, marcado con un 2, se desglosa el proceso en sus pasos y en la zona 3 se desarrolla cada paso en sus funcionalidades en forma de epics e historias de usuario. 

Habiendo obtenido los elementos de la pila de producto, estos se trasladan al tablero de Release Planning, flecha 4, priorizando las historias de usuario en función de la release de la que se pretende que formen parte (carril 5 y sucesivos). Resaltar que con esta actividad se está planificando la ejecución del proyecto en forma de entregas, a diferencia de como se suele concebir ejecuciones de proyectos en cascada que suelen ser en capas horizontales pensadas para construir el proyecto de inicio a fin o entre hitos.

En caso de múltiples flujos de valor se realiza un User Story Mapping independiente para cada proceso, sus historias de usuario y epics se trasladan y consolidan después en un solo tablero de Release Planning.

Varios procesos de negocio requieren cada uno su tablero para User Story Mapping correspondiente

El siguiente paso consiste en la colorización que trata de la añadidura de historias técnicas por parte del equipo. Muy posiblemente la primera release requiera preparar un entorno de producción, arquitectura... historias sin las que sería imposible que funcionara el software construido. El término colorización viene de la idea de utilizar colores distintos en los post-its para historias de usuario e historias técnicas.

Juntando las diferentes historias de usuario de los diferentes flujos de valor, y también las de la pila de producto, si esta existiera, se obtiene la pila de producto actualizada y priorizada por releases. Es el momento de estimar hasta donde sea posible, probablemente todas las historias de usuario hasta donde aparezcan las funcionalidades en forma de epics. La estimación la debe de realizar el equipo en la unidad de tamaño establecida y en la que se mide la velocidad (puntos de historia, horas ideales...)

A partir de aquí el Propietario del Producto realiza el gráfico de producto o gráfico "burnup", esta es su herramienta de planificación por excelencia y que presenta visualmente la evolución previsible del producto, proyectando en base a la velocidad del equipo y en el tiempo la construcción del producto. Este toma a continuación la pila de producto con las releases previstas, en el caso del ejemplo tiene previsto lanzar la versión 1.0 cuando disponga de las cuatro primeras historias, que tienen un esfuerzo estimado de 950 puntos (150+250+250+300):

Pila de producto con releases, cortesía de Scrum Manager

Para trazar la previsión, este sitúa cada versión en el eje vertical en la posición correspondiente al esfuerzo estimado para construir todas las historias que incluye. Los puntos de corte que marca esta posición con las líneas de velocidad del equipo (pesimista, realista y optimista) proyectan en el eje horizontal la fecha o sprint en el que se completará la versión. Finalmente el Propietario del Producto habrá obtenido el "burnup" o gráfico de producto que proyecta de la forma más realista posible la construcción del software:

"Burnup" o gráfico de producto, cortesía de Scrum Manager

Para poder explicar fácilmente lo que se va a crear en la siguiente release y para cuando se tiene previsto que estará lista se puede utilizar el siguiente patrón:

LA <nombre de la release>

QUE ESTA PREVISTA PARA EL <fecha prevista de la release>

Y SE CARACTERIZA PRINCIPALMENTE POR <característica principal>

PERMITIRÁ A <beneficiario principal>

LOGRAR <beneficio obtenido>

User Story Refinement

La pila de producto es un documento vivo, posiblemente varíe de sprint en sprint, o bien porque el cliente haya madurado y concrete sus necesidades a medida que tomen importancia, o bien porque este debe de adaptarse a variaciones en su negocio y a las oportunidades de mercado. Por tanto el "burnup" o gráfico de producto, también es un documento vivo cuya evolución preestablece la del producto. Como herramienta ágil no debe considerarse para representar planes estables, sino las previsiones tras cada evolución de la pila de producto. 

Este evento suele producirse a mitad de cada sprint, en este el Propietario del Producto presenta al equipo las variaciones, la repriorización y los posibles desgloses de epics en historias de usuario. El equipo debe de reestimar la pila de producto hasta dónde sea posible y así el Propietario de Producto podrá realizar el gráfico de producto o gráfico "burnup" actualizado, que representará una proyección realista de ese momento.

Se puede complementar la planificación de release con un tablero para irradiar la información y reforzar la visibilidad y transparencia, como la imagen que sigue con un ejemplo. Es importante resaltar a todos los interesados que el tablero refleja la situación actual y que variará a medida que se avance en el proyecto.

Tablero Release Planning, gracias Alberto

Cierro con una frase de Mike Beedle:

"Quién predice sin medir, se equivocará"

¿Cómo se realiza la visión del producto?

Podemos resumir que una visión del producto consiste en un artefacto para explicar un producto que todavía no existe a alguien, sea un inversor, un cliente, o un equipo de desarrollo. Cuando todos los involucrados conocen y comprenden el producto desde una perspectiva más amplia y se sienten parte de algo más, saben de qué y donde participan, con lo que sus decisiones van a ser mejores y más acertadas. Pensemos por ejemplo que los miembros de los equipos toman diariamente decisiones, que aunque técnicas, afectan directamente el producto.

Para generar la visión del producto presentaré la técnica del elevator pitch, una de las actividades de la Incepción Ágil. Esta toma su nombre de una supuesta situación en la que, en lo que dura un viaje en ascensor, algo menos de 2 minutos, se debe despertar el interés del interlocutor por el proyecto, ya sea un inversor, un cliente potencial o un posible colaborador.

Elevator pitch de un grupo de alumnos

En el contexto de la planificación ágil esta técnica ayuda a arrancar conversaciones que permiten compartir información, alinear y enfocar a las personas involucradas en la dirección correcta del proyecto/producto y hacia un mismo objetivo y, eventualmente hasta permite tomar decisiones. Será a partir de esta visión, que marca el valor de negocio, por la que el Propietario del Producto priorizará los epics y las historias de usuario.

Se trata de un mensaje corto, de tres o cuatro frases, donde se condensa la propuesta de valor, es decir el problema identificado y la manera en que se pretende resolverlo, transmitiendo ideas claras, concisas y sintéticas.

Como es usual en Agilidad la comunicación se ve enormemente potenciada cuando acompañamos nuestro cometido con elementos visuales. Arriba a la izquierda el resultado de un ejercicio de uno de los cursos, en que el grupo expuso una solución en la que a través de big data se pueden controlar los procesos de incapacidad laboral temporal.

Para generar este mensaje se debe de dar respuesta a estos tres conceptos:

• Quién es el público: ¿Quién va a utilizar tu producto?
• Qué problema tiene: ¿Qué problema o necesidad latente se va a satisfacer?
• Qué solución se ofrece: ¿Cómo se va a satisfacer?

Alex Brown propone el siguiente patrón como una forma de escribir o crear una visión: 

PARA <cliente objetivo>

QUIEN <declaración de necesidad>

EL <nombre de producto> QUE ES UN/A <categoría del producto>

QUE <beneficio clave, razón de peso para comprar o usar>

A DIFERENCIA DE <competidor/alternativa>

NUESTRO PRODUCTO <declaración diferencial>

Ejemplo de una visión:

PARA sociedades propietarias de drones
QUIEN tienen necesidad de asegurar sus drones y cubrir su responsabilidad civil
EL producto prodrone QUE ES UN seguro gestionable de forma on-line
QUE es un producto específico para los profesionales de drones
A DIFERENCIA DE nuestra competencia que solo dispone de un producto de contratación presencial
NUESTRO PRODUCTO es totalmente personalizable de forma on-line en cuanto a coberturas y duración se refiere

Elevator Pitch del Agile Inception
Deck de Jonathan Rasmusson

Como consejo derivado de mi experiencia, para una utilización positiva de este patrón, si hubiera elementos en negativo en la parte de A DIFERENCIA DE, propongo escribirlos en positivo en NUESTRO PRODUCTO, convierte nuestro mensaje en más positivo y por tanto en más poderoso.

"Un enunciado de visión exitoso

es lo suficientemente convincente

para ser ampliamente compartido,

conciso y fácil de recordar"

¿La pila de producto y la de sprint se estiman en la misma unidad?

La estimación de la pila de producto se produce en la planificación de release y en la reunión de refinamiento, ambas reuniones conducidas por el Propietario del Producto. Lo ideal es utilizar la estimación relativa, si el equipo ya tiene un recorrido, lo mejor es estimar en comparación con otras historias de usuario que hayamos hecho en el pasado. La unidad en que estimemos el tamaño de las historias, puntos de historia, son una convención del equipo y representan el tamaño o esfuerzo(no el tiempo), de forma que los números representan la tamaños relativos entre historias.

Pila de producto (NOT SELECTED)
y pila de sprint (SELECTED)

Ahora bien, en la reunión de planificación de sprint el equipo desgrana las historias en tareas y estima estas, quizá en horas. Quiero dar la idea de que las unidades no tienen porqué ser iguales para las dos pilas, de hecho es mejor que sean unidades distintas, ya que acabado el sprint, la unidad en que se debe de utilizar para medir la velocidad del equipo es la de la pila de producto, no la de sprint, y con unidades diferentes se evitan confusiones.

Si somos capaces de establecer una unidad única que signifique lo mismo para todo un proyecto o empresa con varios equipos, todos los equipos serán capaces de estimar, si se les da el conocimiento necesario, con una unidad de tamaño común para todos ellos. Independientemente de eso, cada equipo tiene su propia velocidad, probablemente distinta de otros equipos. Así tendremos equipos más lentos y equipos más rápidos, pero todos hablarán el mismo idioma. Quiero resaltar que tener equipos de diferentes velocidades puede ser perfectamente deseable, un equipo de élite para lo crítico y un equipo de fondo para los trabajos más de molinillo y menos gratos.

Daré un ejemplo: Alexander hace 20 años programaba en un lenguaje que se llamaba Clipper (quizá a alguien de por aquí le suene). Entonces estimó una historia en 3 puntos de historia y tardó 9 horas en realizarla. Si ahora Alexander tuviese que realizar la misma tarea probablemente tardaría, bufff, ¿30 horas? (Dios no quiera que tuviera que volver a ello, jajaja). ¿Quiere eso decir que la historia de usuario ha crecido y ahora debería de ser algo como 9 puntos de historia? No, simplemente Alexander ha reducido su velocidad por haber estado ausente de la tecnología durante 20 años, el tamaño de la historia sigue siendo el mismo.

Os invito a leer un post mío relacionado: ¿Qué ocurre con la velocidad del equipo cuando las horas estimadas de una historia de usuario son inferiores a la suma de las horas estimadas en las tareas correspondientes de la pila de sprint?

¿Qué patrones de testing son posibles para evolucionar de una gestión clásica a Scrum?

Recordemos que los incrementos resultantes de un sprint solo están finalizados cuando cumplen con la definición de hecho (DoD), definición que incluye pasar todas las pruebas con éxito. Llegar a obtener incrementos con todo el testing realizado implica una gran madurez en Agilidad. Después de 50 años de ingeniería de software hemos llegado a la conclusión de que las pruebas son un buen lenguaje para especificar requisitos funcionales, y es por ello que los criterios de aceptación, que se traducen en pruebas, toman tanta importancia en las historias de usuario. La mejor solución hasta hoy en día para garantizar pruebas completas dentro de un sprint, son la integración continua y las pruebas automatizadas. Implementar esta solución, TDD (Test Driven Development) o BDD (Behavior Driven Development), tiene sus dificultades que requiere una madurez que no es fácil de alcanzar.

Recientemente fui co-trainer de Mike Beedle en uno de sus cursos y en este describió 6 patrones de pruebas, los 5 primeros con soluciones gradualmente más cercanas a las necesidades de Scrum.

1. Sprint de integración y estabilización: en esta solución se dedica un sprint entero a hacer el testing de varios sprints anteriores. Esta solución se parece a trabajar en cascada y por ello se le da los nombres de ScrumFall o WaterAgile. La desventaja es que el sprint de pruebas puede ser una auténtica bomba de relojería que puede destapar una avalancha de incidencias.
2. Un equipo de pruebas testea después de la planificación del siguiente sprint: de esta manera cada sprint tiene su fase de pruebas, pero tiene la desventaja de que las incidencias entran en sprints posteriores afectando a estos de manera imprevisible. Una avalancha de incidencias puede romper un sprint.
3. Un equipo de pruebas testea antes de la revisión del sprint: esta fase de test al final del sprint produce estrés adicional a la entrega y se produce un constante peloteo entre equipo de desarrollo y el de pruebas. El equipo de pruebas se queja de la mala calidad del equipo de desarrollo, y este, de que constantemente el equipo de pruebas está rompiéndoles con las incidencias su ritmo de trabajo, agravado por el sentimiento de que otro equipo está destapando los errores propios.
4. Build diario con un equipo de pruebas en otro turno horario: cada mañana el equipo se encuentra con las incidencias detectadas, tiene la desventaja de que el equipo se encuentra cada mañana con una pila de sprint cambiada y que también se produce algo de peloteo entre los dos equipos.
5. Build diario con un equipo de pruebas a última hora del día: tiene la ventaja de que se detectan las incidencias de forma muy rápida pero la desventaja de convertir los días del equipo de desarrollo en días muy largos, ya que seguramente poco antes de que tengan intención de irse a casa ya reciban incidencias del equipo de pruebas y se pongan a resolverlas.
6. Integración continua y pruebas automatizadas: se pueden realizar a petición docenas de pruebas automatizadas cada día. A petición, el sistema efectúa de forma automática el juego de pruebas completo y en cuestión de minutos el equipo de desarrollo tiene un reporte completo con las incidencias, pudiendo resolver estas en caliente con la mente aún inmersa en el código testeado.

En febrero asistí a un meetup en el que el Centro de Innovación del BBVA compartió sus experiencias con BDD y automatización de las pruebas. Allí vi de primera mano como una compañía había implementado integración continua y pruebas automatizadas.

Meetup "Cucumbeando, que es pepino" en el Centro de Innovación del BBVA

La herramienta que utilizan es Cucumber, un software de test que ejecuta las pruebas al estilo de BDD. La primera tarea de un desarrollador es escribir las pruebas en Gherkin, un lenguaje que usa Cucumber y se escribe desde el negocio, un lenguaje específico que permite describir el comportamiento del software sin detallar cómo se implementará ese comportamiento. Una vez escritas las pruebas el desarrollador empieza a codificar y cada vez que tiene una parte testeable lanza las pruebas automatizadas para probar su código. Cuando pasa todas las pruebas el sistema da garantías de un software sin incidencias, aunque no de que haga lo correcto.

Tengo la convicción de que dentro de 10-20 años todos trabajaremos con pruebas automatizadas y las personas solo efectuarán aquellas en que aporten valor como las pruebas funcionales complejas y las pruebas exploratorias. Muchas de las pruebas ejecutadas por personas serán para entonces prehistoria y anécdotas del pasado.