Uno de los principales insumos en
el desarrollo de productos son las especificaciones
funcionales, donde clientes y usuarios describen a los desarrolladores lo
que desean del producto. Cuando éstas son escritas, están sujetas a
interpretaciones, malos entendidos y resultados que no satisfacen las
expectativas. La comunicación humana se enriquece con las conversaciones, ya
que el tono de voz y los gestos comunican más que las palabras, por esta razón
en SCRUM se incorpora el concepto de Historias
de Usuario (User Story), especificaciones compuestas de una pequeña ficha
(card) que esquematiza la redacción del requisito, conversaciones entre el
Product Owner y el Equipo de Desarrollo y Criterios de aceptación que
especifican las condiciones que debe cumplir dicho requisito (3C: Card
Conversaciones Criterios).
La redacción de la historia de
usuario describe para el rol involucrado, la funcionalidad requerida y el objetivo
de la misma en una frase corta, la cual tiene la forma: Como
Quiero Para . Por ejemplo: Como Estudiante
quiero consultar mis programas en línea para ahorrar tiempo y dinero.
Los criterios de aceptación deben
describir un contexto, un evento y la respuesta o consecuencia esperada. La forma
más utilizada para describir los criterios de aceptación es: Dado
Cuando Entonces .
Aquí un ejemplo: Dado un estudiante autenticado en el sistema académico
Cuando accede a la opción de programas en línea Entonces se le
redirige automáticamente a la lista de programas de la carrera en la cual está
inscrito.
Una buena historia de usuario
debe cumplir un conjunto de características, conocidas con el acrónimo INVEST: Independiente (poderse
desarrollar sin depender de otra), Negociable (entre el Product Owner y el
Equipo de Desarrollo), Valiosa (para los clientes), Pequeña (desarrollable en
poco tiempo) y Testeable (con los criterios de aceptación bien definidos para
ser probada). Adicionalmente, el equipo de desarrollo acuerda con el Product
Owner las condiciones que debe cumplir una historia de usuario para estar lista
(Definition of Ready) y poder ser
incluida en el Sprint Backlog, por ejemplo debe cumplir los requisitos INVEST, estar
redactada de la forma Como-Quiero-Para,
y detallados los Criterios de aceptación de la forma Dado-Cuando-Entonces.
Finalmente, el equipo de SCRUM
también debe acordar las condiciones que debe cumplir la historia de usuario
para darla por terminada (Definition of
Done) y disponer de un producto entregable y usable, por ejemplo todos los
criterios de aceptación funcionan correctamente, todos los archivos fuentes
están en el repositorio adecuado, entre otros.
En el Product Backlog, pueden
registrarse historias de usuario generales, de gran complejidad, que cuando
pasan a ser prioritarias, se descomponen en más pequeñas. A estas historias se
les conoce como épicas (epic) y la
estimación general que se puede utilizar es XS (muy pequeña), S (pequeña), M (medio),
L (grande) y XL (muy grande). Para las historias de usuario que van al Sprint
Backlog, la estimación de esfuerzo puede utilizar la secuencia de Fibonacci,
técnica sobre la cual les hablaré en el próximo artículo.
Gracias por leerme.
No hay comentarios:
Publicar un comentario
Gracias por tus comentarios :)