Saltar al contenido
Codifíca.me | Desarrollo web | Programación

Gestión de requisitos

23 junio, 2014
php frameworks

[vc_row][vc_column][vc_column_text]En esta etapa decidiremos cuales de los requisitos candidatos van a formar parte de los requisitos que finalmente desarrollaremos.

En los post anteriores hemos visto como obtener el máximo número de requisitos candidatos ahora vamos a ver cómo elegir cuales de los requisitos candidatos son los que finalmente se van a desarrollar.

Factores que influyen en la gestión de requisitos

Encontramos muchos factores que nos pueden influenciar en la elección de unos u otros requisitos, generalmente los factores son:

 

–          El coste que supondría desarrollar un requisito.

–          La importancia que representa tener este requisito o no.

–          La ventaja frente a otros productos que el producto en cuestión tenga ese requisito.

–          El riesgo de que al no desarrollar determinados requisitos la aplicación no funcione como esperábamos.

Estas son algunas de las causas pero podemos encontrar muchas más causas que dependerán un poco de los stakeholders.

Estimación de requisitos

Para realizar las estimaciones disponemos de muchas técnicas, estas algunas de las más utilizadas.

Comparación

Una técnica que se utiliza muchas veces para la estimación de requisitos es la comparación, es decir, comparamos el proyecto con otros proyectos que ya hayamos desarrollado antes y estimamos el tiempo o valor en función del proyecto que anteriormente hemos desarrollado.

Planing pokker

Esta es una técnica de estimación colaborativa, se realiza de la siguiente forma:

Se reúnen los desarrolladores y escala de cartas del 1 al 10 a cada uno de los desarrolladores, se habla del primer requisito, y cada uno estima el tiempo que se va a tardar en realizar ese requisito, cada uno estima con una carta boca abajo, que después se mostrará a todos los asistentes.

Se comparan los valores y si son dispares, se vuelve a exponer el requisito y él porque de los valores dispares, se trata de llegar a un acercamiento después de exponer los puntos, así que se vuelve a repetir el proceso, y vemos si hay acercamiento entre los asistentes. Se repite el proceso hasta que todos los asistentes tienen un punto de vista más o menos común.

Priorizar requisitos

Después de obtener todos los requisitos y gestionar cuales pueden ser los mejores, más económicos, más viables, etc. Es necesario priorizar entre todos los requisitos cuales son los que desempeñan un valor más alto para la aplicación.

Para esto utilizamos algunas herramientas como pueden ser la visión del producto, el producto mínimo entregable.

La visión del producto responderá a preguntas como a quien va dirigido, quienes serán sus clientes, quien lo usara, que necesidades cubre, compararemos el producto con otros, etc. En resumidas cuentas valoraremos cómo será el producto.

Para tener una visión clara de los puntos fuertes del producto Jim Highsmith recomienda utilizar la técnica de la caja, exponer en la parte de delante de caja una imagen del producto y tres características, junto al nombre del producto. Y en la parte de atrás un número considerable de características.

Si realizamos el proceso con diferentes grupos de stakeholders veremos que cada uno de ellos expondrá una caja diferente, por lo que nos podremos hacer una idea de lo importante para cada grupo de implicados en el desarrollo.

El producto mínimo entregable, será realizar un balance de las características mínimas que debe de tener el producto para que se cumpla la visión general del producto.

 

Técnicas de priorización

Tenemos varías técnicas, vamos a comentar la técnica de los 100 dólares.

–          La técnica de los 100 dólares, consiste en repartir 100 dólares imaginarios y los stakeholders los invertirían en los requisitos que ellos consideren más importantes dando un valor más alto para los más importantes.

Selección de Requisitos y backlog

El backlog se define cómo la lista de prioridades de todos los requisitos que quedan por desarrollar para finalizar el desarrollo.

El backlog estará compuesto de las funcionalidades que forman el producto, las historias de usuario casos uso, requisitos funcionales, requisitos no funcionales, tareas, etc.