Muchas veces me he topado en las charlas de Scrum, en los
dojos de historias de usuario ( dojo =
lugar de entrenamiento) con amigos agilitas que me han preguntado: ¿cómo hago historias de usuario y Scrum
si mi equipo es de ingeniería electrónica y trabajamos adaptando dispositivos
electrónicos de los más diversos protocolos para nuestras soluciones?
La verdad algunas veces respondía:
- Debe ser lo mismo que en software
- Estas construyendo un producto tiene que ser posible aplicar Scrum
- Invítame y miramos (la verdad no me invitaban)
Lo bello de la vida es que te da la respuesta a las
preguntas que le haces (o por lo menos así me funciona a mi), hace unos meses
trabajo en una empresa donde en efecto, tenemos una solución hardware-software,
y tenemos dos equipos:
- Uno de ingenieros de software que trabajan desarrollo web sobre php.
- Y otro de ingenieros electrónicos que trabajan adaptando dispositivos electrónicos y generando firmware respectivamente.
En esta empresa me desempeño como Director de Operaciones y
Scrum Master, el gerente que es quien tiene la visión de los productos y es
nuestro Product Owner (decidimos estos roles luego de pensar como adoptar Scrum
en la organización).
En realidad lo que hicimos fue disciplinar un poco a ambos
equipos, firmware y software pues ya contaban con varias reuniones:
- Planning
- Review
- Listado de requerimientos en un backlog
y hubo un tiempo hacían juiciosos el daily, práctica que
habían perdido, pero lo recordaban.
Luego de trabajar un tiempo con el equipo de firmware
comprendí varias cosas:
- Invierten un buen tiempo entendiendo el protocolo de funcionamiento de un dispositivo, luchando en el terreno de la anarquía o caos (ver imagen anterior) hasta que por fin des-encriptan, logran comunicarse y hacer que el dispositivo haga lo que ellos quieren.
- Este tempo en la anarquía o caos es un tiempo en efecto de ensayo y error, este tiempo no es estimable, se ponen una meta de lograr algo retándose para “X” fecha (por lo general lapsos mayores a 5 días), pero realmente no saben si lo van a lograr, a veces dicen: es probable que me demore menos o más pues se parece a algo que ya había trabajado, pero no es responsable comprometerme con una fecha.
- Luego de des-encriptado el componente electrónico y su protocolo, los ingenieros SI son capaces de hacer estimaciones, pues caemos en el terreno conocido de lo “complejo” y Scrum aplica perfectamente allí.
Después de entender esto, estuvimos mirando cómo escribir
las historias de usuario, he aquí unos resultados interesantes (y que actualmente usamos):
Historia
de usuario
Título: Cambio de
Contraseñas del panel
Descripción: Crear un menú
que permita personalizar las contraseñas del panel
Escenario 1: Si no se han personalizado las contraseñas
el panel debe aceptar solo las contraseñas por defecto
Criterios de Aceptación:
DADO: Que no se haya personalizado contraseñas
CUANDO: Ingresen al nivel
1 ó 2 del panel
ENTONCES: Debe validar
solo con las contraseñas por defecto
Escenario 2: Si se ha
personalizado la clave de un nivel, debe validar con esta clave personalizada
y con las por defecto.
Criterios de Aceptación:
DADO: Que se haya personalizado la contraseña del
nivel
CUANDO: Ingresen al nivel
personalizado
ENTONCES: Debe validar con
la contraseña personalizada o con las contraseñas por defecto
|
Historia
de usuario
Título: Memoria SD- crear
archivos en el interior de cualquier carpeta.
Escenario 1: la
memoria SD tiene la carpeta ya creada pero en su interior está vacía.
Criterios de Aceptación:
DADO: el encendido a la tarjeta
CUANDO: verifique por la
existencia de los archivos
ENTONCES: si no existen
los crea y guarda información de una venta en el mismo formato en el que se
guardaría en el servidor.
Escenario 2: la memoria SD
ya tiene el archivo con el nombre válido creado pero está vacío.
Criterios de Aceptación:
DADO: La tarjeta SD en el sistema
CUANDO: el encendido a la tarjeta
ENTONCES : verificar la
existencia del archivo en la ruta ya especificada.
Y: se verifica que el
archivo esté vacío y guardar información en el principio del archivo como una
venta completa en el formato en el que se manda al servidor
Escenario 3: la memoria SD
ya tiene el archivo con nombre válido creado y ya tiene ventas o cualquier
tipo de información almacenada.
Criterios de Aceptación:
DADO: el encendido a la tarjeta
CUANDO: va a guardar la información.
ENTONCES : verifica si el
archivo existe,
Y: se posiciona al final
del archivo
Y: guarda la información
en el formato adecuado para que el servidor la reciba.
|
Historia
de usuario
Título: XXXXXX y YYYYYYY utilizando
el gps obtener datos.
Escenario 1: iniciar
el programa sin tener conexión con el gps
Criterios de Aceptación:
DADO: El encendido a la tarjeta
CUANDO: la tarjeta recibe respuesta del gps
ENTONCES: Colocar el
mensaje en pantalla "ok"
Escenario 2: Hacer los cálculos
matemáticos para el XXXXXX y YYYYYYY
Criterios de Aceptación:
DADO: el encendido a la tarjeta y la señal de "ok"
CUANDO: la obtención de los datos por el puerto
serial
ENTONCES : Calcular con
los datos del gps la distancia y el tiempo
Escenario 3: almacenar los
datos del XXXXXX y YYYYYYY
Criterios de Aceptación:
DADO: el encendido a la tarjeta y la señal de "ok"
CUANDO: son calculados los datos de XXXXXX y YYYYYYY de forma matemática
ENTONCES : enviar los
datos del XXXXXX y YYYYYYY a la memoria del microcontrolador MMMMMMM.
Escenario 4: Enviar por
medio del protocolo ZZZZZZZZ los datos
del XXXXXX y YYYYYYY
Criterios de Aceptación:
DADO: el encendido a la tarjeta y la señal de "ok"
CUANDO: sean calculada la distancia y el tiempo
de forma matemática y sean guardados en el micro
ENTONCES : enviar los
datos del XXXXXX y YYYYYYY por medio
del protocolo ZZZZZZZZ
Nota para los lectores: Creo
que entienden que MMMMMMM, XXXXXX, YYYYYYY y ZZZZZZZZ, son nombres reservados
de las tecnologías que usamos
|
He observado varias cosas:
·
El equipo prefiere tener pocos criterios de
aceptación
·
Los eventos por lo general corresponden a
eventos de hardware:
o
Envíos
o
Lecturas
o
Encendidos
o
Apagados
o
Estímulos de otros componentes
o
etc
·
Las respuestas son igualmente comportamientos de
los componentes, ya sean en forma de :
o
Encendido de bombillos, leds, etc.
o
Mostrar datos en un panel visualizador
o
Enviar datos
o
Registro y almacenamiento de datos
o
Entre muchos otros
Respecto a las historias, estas son estimadas en puntos, donde:
·
Un punto =
es un DÍA FELIZ (Léase: día
enfocado trabajando sin desconcentraciones
Por lo general estimamos los puntos basados en la métrica
del “clima del día anterior”, pero nos comprometemos unos cuantos puntos más
para ver si podemos alcanzar a hacerlos.
Y Scrum…
El equipo a pesar que realizaban ciertas prácticas el hecho
de involucrar Scrum y otras técnicas más en su día a día les ha reportado
beneficios:
·
Compromiso y foco con lo que se va a realizar en
el sprint
·
Las retrospectivas dan elementos de mejora para
el siguiente ciclo
·
Se han percibido grandes ganancias en las:
o
Uso de criterios de aceptación, pues ya no sabe
lo que esperan del desarrollo y no comienzan a trabajar de forma “desordenada”
como se hacía antes
o
Pruebas pares, pues ya no se escapan tantos
escenarios, y permiten distribución del conocimiento
o
El daily, Les sirve para sincronizarse y ayudar
al compañero que esta “enredado” resolviendo una historia de usuario.
o
El Kanban y el Burndown les ha permitido
enfocarse y comprometerse más como equipo para lograr metas comprometidas.
o
El Scrum Master trabaja en la solución de los
impedimentos, permitiendo foco al equipo.
Espero este post, le se ayuda a mis amigos los ingenieros
electrónicos y vengan muchos más similares. Si conocen de alguno similar o lo
escriben ustedes, no duden en participármelo para linkearlo en este post.
Postdata:
La verdad no estaba tan perdido cuando daba la respuesta “Debe ser lo mismo que en software” pero definitivamente la
experiencia es la mejor maestra y ya puedo dar una mejor respuesta cuando me
pregunten sobre Scrum e historias de usuario en ambientes de ingeniería
electrónica.
Saludos ágiles
Jorge Abad.
