Inicio arrow Artículos - apuntes arrow 9 Bloques: rutina para obtener requisitos con Scrum Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

9 Bloques: rutina para obtener requisitos con Scrum
Valoración del artículo: / 16
MaloBueno 
18.12.2007

9 bloques"La parte más difícil en la construcción 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 visión clara de lo que quiere.
2.- El suministrador obtiene los requisitos superficialmente, quizá siguiendo un proceso, pero sin "sumergirse" en conocer el negocio del cliente y realizar desde ahí el análisis.
3.- Implicación y comunicación cliente-equipo de desarrollo. 

 

La mejor solución para el tercer punto es resolverlo vía proceso: integrando en el proceso de desarrollo la participación y comunicación 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 visión del producto ("product backlog"), y define prácticas para la comunicación con el equipo y la monitorización del proyecto (reuniones de inicio y revisión de sprint)

Pero además de que el cliente esté implicado y en comunicación con el equipo, es necesario disponer de una visión clara del objetivo, y comprender y analizar el entorno del problema.

Para estos dos puntos no se puede confiar la solución a un proceso, porque ésta se alcanza más por el conocimiento tácito de las personas, que por el explícito del procedimiento de obtención y análisis 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 intuición y conocimiento tácito para identificar las necesidades y la solución 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 obtención y análisis de los requisitos se denomina de "9 bloques" y se puede echar mano de ella tanto a nivel de visión 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 visión y priorizar un backlog; y en segundo, para el equipo, cuando en una reunión de principio e sprint se topa con algun punto de backlog, especialmente difuso o difícil de comprender.


Consiste en interrogar el problema con tres tipos de preguntas:
1.- Abiertas
2.- Concretas
3.- De confirmación

Y hacerlo de forma secuencial a través de las tres áreas de investigación:

1.- Diagnóstico del problema o necesidad
2.- Alcance del problema
3.- Visualización de la solución


La representación gráfica de esta técnica de ayuda, forma una matriz de 3x3 que le da el nombre de "9 bloques".


9 bloques


La rutina consiste en:
1 Diagnosticar cuál es el problema o la necesidad del cliente
1.a Partiendo de la descripción general de la situación
1.b Acotando y resolviendo dudas y ambigüedades
1.c Contrastando que cliente e interlocutores comparten la misma conclusión

2.- Cuál es el ámbito del problema o de la necesidad
2.a Partiendo de la descripción general de la situación
2.b Acotando y resolviendo dudas y ambigüedades
2.c Contrastando que cliente e interlocutores comparten la misma conclusión

3.- Cuál es la solución que se desea conseguir
3.a Partiendo de la descripción general
3.b Acotando y resolviendo dudas y ambigüedades
3.c Contrastando que cliente e interlocutores comparten la misma visión



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 mejorarías a la aplicación actual (a la aplicaciones de la competencia...)?

¿La mejoras son necesarias en turismo, o en todas las áreas? ¿Necesitáis mejorar las funcionalidades y el interfaz de los usuarios, o también del backoffice?

¿Qué es lo que haría feliz al usuario?, ¿Cómo deberían ser los resultados? ¿Cuáles son las soluciones o las partes de las soluciones de otros productos que más se parecen a lo que se debería conseguir?


Preguntas de control
La exposición abierta de las razones y necesidades del cliente plantearán dudas, y para darles respuesta y concreción se plantean preguntas de control que requieran respuestas concreas del tipo sí o no; o cifras y datos precisos.

Son preguntas del tipo:

¿Cuáles 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 mínimo con las mejoras de usabilidad?, ¿Se puede seguir empleando el módulo de préstamos durante 2009?...

¿Cuántos departamentos tiene la empresa? ¿Cuántos tipos de informes necesita un departamento? ¿Cuántos tipos de expedientes diferentes hay entre los tramitados en un año?

¿Cuánto tiempo debería costar validar un informe? ¿Cuánto tiempo debería costar hacer una compra? ¿Cuáles serían algunos ejemplos de preguntas de usuario que debería resolver el sistema, sin ayuda de operadores? ¿Además del nº de socio se podría facilitar también otros datos como DNI, e-mail, firma digital...?

De confirmación
Después de entender y acotar el problema, su ámbito o la solución (según el área de investigación en la que nos encontremos), es necesario contrastar que todos estamos entendiendo lo mismo para evitar interpretaciones erróneas, o diferentes sobre algún requisito ambiguo.

Son preguntas del tipo:

Entonces, ¿no se puede lanzar ninguna versión hasta que no incluya una auditoría de modificaciones?. Si el usuario necesitara más de 1 minuto para darse de alta, ¿no serviría?.
Por lo que has dicho, entiendo que el año se podría cerrar con las consultas actuales, pero sería 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

Consiste en organizar el trabajo de obtención y análisis en una secuencia de dos dimensiones:

1.- A través de tres áreas clave, que es aconsejable despejar por orden para ayudar al trabajo de análisis. En primer lugar se trata de diagnosticar las razones y los porqués del cliente. Dimensionar después 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 genérico a lo concreto, validando la información obtenida.

 

Safe Creative #0712180343982

Trackback(0)
Comentarios (3)Add Comment
Excelente Rutina
escrito por Andres Cea, December 23, 2007
Particularmente en estos momentos nos encontramos junto a un colega planificando la introducción de SCRUM en el funcionamiento de nuestra empresa. He estado leyendo varios articulos de SCRUM, personalmente en lo que he leido me han quedado algunos vacios en cuanto a la aplicación de la metodología en aspectos concretos como la obtención de requerimientos, la cual tiene una tremenda importancia en la obtencion del exito de un proyecto. Al leer esta entrada he quedado algo mas claro en este sentido.

Muchas gracias, creo que nos será de gran ayuda esta rutina.
GRACIAS POR LA GUIA
escrito por Edwin Pulido, February 14, 2008
HE LEIDO CON ATENCIÓNEL ARTICULO Y ME HA AYUDADO EN UN TRABAJO QUE ADELANTO ACTUALMENTE SI TIENEN POR FAVOR MÁS DOCUMENTACIÓN ME PODRIAN HACERLA LLEGAR AL CORREO, MIL GRACIAS POR SU AYUDA.
ERP
escrito por Solis, March 29, 2010
Eh estado revisando la informacion sobre lo publicado en Proyactos Agiles y se me hace bastante interseante yo estoy en una etapa en la cual estoy definiendo una metodologia para el desarrollo de un ERP por lo cual me gustaria aundar mas sobre los requeriemintos metodologias y conceptos ya que es un proyecto que creeo muy intresante.
Por otro lado cabe mencionar que visto ya varios ERP´S y tengo muchas innovadoras ideas sobre lo que quiero. algunos de lo ERP´S EL SAP, SENTAI , NET SUITE INTELESIS de los mas comeciles en Mexico por su puesto y obiamente de todos estos e sacado muy buenas ideas ahora lo que sigue es sentarlas y relizarlas por lo que pido si tiene informacion sobre el como empezar este proyecto les agardeceria mucho mi correo es: Esta dirección de correo electrónico está siendo protegida de \"spam bots\", necesita habilitar Javascript para poder verla.

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative