9 Bloques: rutina para obtener requisitos con Scrum

"La parte ms difcil en la construccin de sistemas de software es

decidir precisamente qu construir" (Frederick P. Brooks Jr.)
El 60% de los problemas de los proyectos tienen su origen, directa o
indirectamente en los requisitos; y los problemas de los requisitos
surgen por alguna de estas razones:
1.- El cliente no tiene una visin clara de lo que quiere.
2.- El suministrador obtiene los requisitos de forma formal y superficial, sin
"sumergirse" en conocer el negocio del cliente y realizar desde ah el anlisis.
3.- Implicacin y comunicacin cliente-equipo de desarrollo.

La mejor solucin para el tercer punto es resolverlo va proceso: integrando en el

proceso de desarrollo la participacin y comunicacin del cliente.
Si se trabaja con Scrum, se tiene resuelto, porque el propio modelo implica al cliente en
el proyecto como "product owner", responsable de la visin del producto ("product
backlog"), y define prcticas para la comunicacin con el equipo y la monitorizacin del
proyecto (reuniones de inicio y revisin de sprint)
Pero adems de que el cliente est implicado y en comunicacin con el equipo, es
necesario disponer de una visin clara del objetivo, y comprender y analizar el entorno
del problema.
Para estos dos puntos no se puede confiar la solucin a un proceso, porque sta se
alcanza ms por el conocimiento tcito de las personas, que por el explcito del
procedimiento de obtencin y anlisis de requisitos.
Si el equipo est formado por el tipo de personas que Keith M. Eades denomina
"gilias", en su libro The New Solution Selling, contar con la suficiente intuicin y
conocimiento tcito para identificar las necesidades y la solucin necesaria, sin precisar
especial apoyo en los procedimientos, pero si no es as, o si se encuentra con puntos
especialmente difusos, la ayuda de una rutina puede resultar muy til, y la que expone el
mismo Keith en su libro, puede ser muy apropiada para incluirla en el inventario de
recursos del equipo.
La rutina que puede emplearse para ayudar a la obtencin y anlisis de los requisitos se
denomina de "9 bloques" y se puede echar mano de ella tanto a nivel de visin general,
como a nivel de elementos concretos del baklog.
En el primer es una rutina til para el responsable del funcionamiento de Scrum, cuando
se encuentra con un cliente que tiene dificultades para definir la visin y priorizar un
backlog; y en segundo, para el equipo, cuando en una reunin de principio e sprint se
topa con algun punto de backlog, especialmente difuso o difcil de comprender.

Consiste en interrogar el problema con tres tipos de preguntas:

1.- Abiertas
2.- Concretas
3.- De confirmacin
Y hacerlo de forma secuencial a travs de las tres reas de investigacin:
1.- Diagnstico del problema o necesidad
2.- Alcance del problema
3.- Visualizacin de la solucin

La representacin grfica de esta tcnica de ayuda, forma una matriz de 3x3 que le da el
nombre de "9 bloques".

La rutina consiste en:

1 Diagnosticar cul es el problema o la necesidad del cliente
1.a Partiendo de la descripcin general de la situacin
1.b Acotando y resolviendo dudas y ambigedades
1.c Contrastando que cliente e interlocutores comparten la misma conclusin
2.- Cul es el mbito del problema o de la necesidad
2.a Partiendo de la descripcin general de la situacin
2.b Acotando y resolviendo dudas y ambigedades
2.c Contrastando que cliente e interlocutores comparten la misma conclusin
3.- Cul es la solucin que se desea conseguir
3.a Partiendo de la descripcin general
3.b Acotando y resolviendo dudas y ambigedades

3.c Contrastando que cliente e interlocutores comparten la misma visin

LOS TRES TIPOS DE PREGUNTAS

Preguntas abiertas
Son la primeras que se deben plantear, para permitir al cliente expresar libremente,
desde su experiencia y conocimiento del negocio, el problema o la necesidad.
En ellas es importante mantener una escucha activa, sin ideas pre-concebidas.
Son preguntas del tipo:
Qu es lo que no te gusta del sistema actual? Qu quiere conseguir la empresa (el
departamento, el ayuntamiento, el proyecto...) con este nuevo programa?, Qu cosas
mejoraras a la aplicacin actual (a la aplicaciones de la competencia...)?
La mejoras son necesarias en turismo, o en todas las reas? Necesitis mejorar las
funcionalidades y el interfaz de los usuarios, o tambin del backoffice?
Qu es lo que hara feliz al usuario?, Cmo deberan ser los resultados? Cules son
las soluciones o las partes de las soluciones de otros productos que ms se parecen a lo
que se debera conseguir?

Preguntas de control
La exposicin abierta de las razones y necesidades del cliente plantearn dudas, y para
darles respuesta y concrecin se plantean preguntas de control que requieran respuestas
concreas del tipo s o no; o cifras y datos precisos.
Son preguntas del tipo:
Cules son, por orden de prioridad, los 3 principales objetivos que quiere cubrir la
empresa con este sistema?, Qu n de nuevos usuarios se quieren alcanzar como
mnimo con las mejoras de usabilidad?, Se puede seguir empleando el mdulo de
prstamos durante 2009?...
Cuntos departamentos tiene la empresa? Cuntos tipos de informes necesita un
departamento? Cuntos tipos de expedientes diferentes hay entre los tramitados en un
ao?
Cunto tiempo debera costar validar un informe? Cunto tiempo debera costar hacer
una compra? Cules seran algunos ejemplos de preguntas de usuario que debera
resolver el sistema, sin ayuda de operadores? Adems del n de socio se podra facilitar
tambin otros datos como DNI, e-mail, firma digital...?
De confirmacin
Despus de entender y acotar el problema, su mbito o la solucin (segn el rea de
investigacin en la que nos encontremos), es necesario contrastar que todos estamos
entendiendo lo mismo para evitar interpretaciones errneas, o diferentes sobre algn

requisito ambiguo.
Son preguntas del tipo:
Entonces, no se puede lanzar ninguna versin hasta que no incluya una auditora de
modificaciones?. Si el usuario necesitara ms de 1 minuto para darse de alta, no
servira?.
Por lo que has dicho, entiendo que el ao se podra cerrar con las consultas actuales,
pero sera un problema muy grave para la imagen de la marca que los clientes no hayan
percibido mejoras sustanciales de usabilidad, no?.

El fondo de la rutina es organizar el trabaja de obtencin y anlisis en una secuencia de

dos dimensiones:
1.- A travs de tres reas clave, que es aconsejable despejar por orden para ayudar al
trabajo de anlisis. En primer lugar se trata de diagnosticar las razones y los porqus del
cliente. Dimensionar despus el alcance de esas razones en el entorno del negocio, y
finalmente visualizar las posibles soluciones.
2.- En cada una de estas reas clave, proceder de lo genrico a lo concreto, validando la
informacin obtenida.

Derechos

http://www.safecreative.org/work/0712180343982