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.