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.
Tabla de contenido
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.
Para realizar las estimaciones disponemos de muchas técnicas, estas algunas de las más utilizadas.
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.
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.
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.
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.
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.
Ingeniero informático y desarrollador de aplicaciones web. Experto en desarrollo web, Webmaster, e-commerce y SEO.
2 comentarios. Comentar
Buen resumen sobre la gestión de requisitos
lo releeré
Gracias, me alegro que te guste