Gestión de requisitos

  • Jordi Pradel Miquel

    Jordi Pradel Miquel

    Ingeniero de Informática por la Universidad Politécnica de Cataluña. Socio fundador e ingeniero de software en Agilogy, profesor en el Departamento de Ingeniería de Servicios y Sistemas de Información de la UPC, consultor de los Estudios de Informática y Multimedia en la Universitat Oberta de Catalunya y miembro del Grupo de Investigación de Ingeniería del Software para Sistemas de Información de la UPC, en el que ha publicado varios artículos de investigación en el campo de la ingeniería del software y de la aplicación a sistemas de información.

  • Jose Raya Martos

    Jose Raya Martos

    Ingeniero de Informática por la Universidad Politécnica de Cataluña. Compagina su actividad como ingeniero de software en Agilogy (empresa de la cual es socio fundador) con la de consultor en el Área de Ingeniería del Software en la UOC y la de profesor a tiempo parcial en el Departamento de Ingeniería de Servicios y Sistemas de Información de la UPC. A lo largo de los años ha trabajado en proyectos de sectores varios, como el financiero, la Administración pública o las telecomunicaciones, ejerciendo tareas técnicas y de gestión, lo que le ha dado una amplia perspectiva sobre el mundo del desarrollo de software y de su diversidad.

PID_00191250
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-Compartir igual (BY-SA) v.3.0 España de Creative Commons. Se puede modificar la obra, reproducirla, distribuirla o comunicarla públicamente siempre que se cite el autor y la fuente (FUOC. Fundació per a la Universitat Oberta de Catalunya), y siempre que la obra derivada quede sujeta a la misma licencia que el material original. La licencia completa se puede consultar en: https://creativecommons.org/licenses/by-sa/3.0/es/legalcode.ca

Introducción

En este módulo presentamos varias técnicas para decidir cuáles de los posibles requisitos (requisitos candidatos) formarán parte del software que queremos desarrollar.
A diferencia de la obtención de requisitos, donde el énfasis está en encontrar el máximo número posible de éstos, en esta etapa tenemos que elegir cuáles incorporamos a nuestro software y cuáles no. Este proceso es crítico para el éxito del software como producto, puesto que la satisfacción de sus usuarios depende directamente de ello.
Empezaremos viendo una introducción general a la gestión de requisitos y a los factores básicos que hay que tener en cuenta a la hora de decidir qué requisitos elegimos y cuáles descartamos. Uno de estos factores es la estimación del coste. Veremos diferentes técnicas para estimar el coste de los requisitos, como por ejemplo la triangulación o el planning poker.
Otro factor importante es la prioridad (o estimación del valor), por lo que haremos una pequeña introducción a la gestión de productos (entendiendo el software como un producto) y, a continuación, veremos algunas técnicas de priorización de requisitos, como la visión de producto, las prioridades limitadas o el modelo Kano.
Finalmente, hablaremos de la gestión de los cambios en los requisitos y de cómo tiene que ir evolucionando la lista de requisitos a lo largo del proyecto de desarrollo.
Todo esto lo ilustraremos, al final del módulo, con el caso práctico de Viajes UOC.

Objetivos

El objetivo principal de este módulo es dar a conocer al estudiante las herramientas necesarias para, a partir de un conjunto de requisitos candidatos, decidir cuáles son los más prioritarios para el producto de software a desarrollar.
En concreto, al finalizar este módulo el estudiante tiene que alcanzar los objetivos siguientes:

  1. Saber crear una lista priorizada y estimada de requisitos candidatos.

  2. Saber elegir de la lista cuáles son los requisitos más adecuados y prioritarios para el producto de software que hay que desarrollar.

  3. Entender cómo tiene que evolucionar esta lista a lo largo del proceso de desarrollo del software.

1.Factores que hay que considerar para la gestión de requisitos

En los módulos anteriores nos hemos centrado en obtener el máximo número posible de requisitos de manera que tengamos en cuenta todos los intereses de los stakeholders. Antes de poder planificar el proyecto de desarrollo, sin embargo, hay que saber cuáles de estos requisitos candidatos son los que finalmente formarán parte de nuestro software.
Denominamos gestión de requisitos al proceso mediante el cual decidimos cuáles de los requisitos candidatos de nuestro software formarán parte del conjunto definitivo de requisitos.

1.1.Factores básicos para la gestión de requisitos

Para tomar esta decisión necesitamos más información de la que disponemos ahora mismo. Por ejemplo, necesitamos una estimación del coste que representa incluir cada uno de los requisitos (puesto que muchas veces la decisión de incluirlo o no dependerá de este coste).
Supongamos que estamos considerando un requisito como por ejemplo “El usuario tiene que poder compartir el plan de viaje en las redes sociales”.
Como casos extremos, si nos dicen que incorporar este requisito nos cuesta dos días de desarrollo y que el proyecto, en total, lo hemos estimado en un año de trabajo, nuestra predisposición a implementarlo será mayor que si nos dicen que nos cuesta un mes de trabajo sobre un total de seis meses de duración del proyecto.
Otro factor básico para la gestión de requisitos es el valor aportado por los mismos, puesto que, de forma parecida, el valor que aporta un requisito al conjunto del software será decisivo a la hora de determinar si lo incorporamos o no:
Volviendo al ejemplo anterior, aunque sea un mes de trabajo sobre seis, si entendemos que ese requisito será nuestro gran valor añadido y que el éxito de la empresa depende de esa funcionalidad, estaremos mucho más predispuestos a implementarlo que si, simplemente, se trata de una idea feliz de uno de los stakeholders, pero que en realidad sabemos que nadie usará.
Hay requisitos que, con independencia del valor que aporten al producto en sí, pueden sumar una gran ventaja para el equipo de desarrollo, que, precisamente por este motivo, puede decidir priorizarlos por delante de otros requisitos. Es el caso de los requisitos que nos ayudan a generar conocimiento o a reducir riesgos.
En nuestro ejemplo, si tenemos otros requisitos relacionados con las redes sociales y hemos identificado como riesgo la interacción con las mismas, tenemos que considerar la posibilidad de priorizar el requisito de integración con las redes sociales como manera de mitigar este riesgo (una vez lo hayamos implementado, ya sabemos que podemos implementar el resto).
Aunque no lo consideremos un riesgo para el éxito del proyecto, igualmente nos puede interesar priorizarlo sólo por el conocimiento que genera (cómo integrarse con las redes sociales).
A la hora de seleccionar los requisitos, tenemos que tener en cuenta cuatro factores básicos: el valor que aporta el requisito, su coste de desarrollarlo y soporte, la capacidad de generar conocimiento a la hora de desarrollarlo y el riesgo que eliminamos por haberlo desarrollado.
Tomamos como ejemplo la autenticación de usuarios en el nuevo sistema de ventas de Viajes UOC.
Desde el punto de vista del valor, a pesar de que nuestros clientes esperan que el nuevo sistema sea seguro, si sólo les damos la opción de autenticarse pero no pueden hacer nada más, difícilmente estarán interesados en usar nuestro sistema, por lo que, desde el punto de vista del valor, la autenticación de usuarios no es un requisito prioritario.
En cambio, el coste de desarrollar esta funcionalidad puede variar significativamente si lo hacemos al principio respecto de si lo hacemos más adelante. Como se trata de una funcionalidad que sabemos seguro que incluiremos, tenemos que valorar si nos vale más la pena incluirla desde un principio y desarrollar el resto del sistema con la base de esta funcionalidad implementada o bien desarrollar el sistema sin autenticación de usuarios y añadirla más adelante.
Desde el punto de vista del conocimiento, a pesar de que esta funcionalidad no nos ayudará a conocer mejor el producto que queremos desarrollar, nos puede ayudar a conocer mejor la infraestructura de seguridad que tenemos que usar. Se podría dar el caso, por ejemplo, de que tuviéramos que usar un mecanismo de autenticación que no hemos usado nunca y que, por lo tanto, se genere nuevo conocimiento al implementar esta funcionalidad.
El último factor es el riesgo. ¿Puede pasar que, si encontramos problemas a la hora de implementar la autenticación de usuarios y no la podemos implementar como queríamos, se ponga en peligro la viabilidad del proyecto? Por ejemplo, si hemos decidido usar cierto framework de seguridad que no hemos usado antes y no tenemos ninguna alternativa pensada, quizás nos convenga implementar la autenticación de usuarios al principio y comprobar que el framework cumple con lo que esperábamos.
De los cuatro factores que hemos visto, uno (el valor) lo tenemos que obtener de los stakeholders, mientras que el resto (coste, conocimiento y riesgo) los tenemos que determinar de manera colaborativa entre los stakeholders y los desarrolladores. Por eso, la gestión de los requisitos es un trabajo que involucra a todos los actores interesados en el desarrollo del sistema informático, sean stakeholders o desarrolladores.

1.2.Impacto financiero de los requisitos

La mayoría de proyectos de desarrollo de software se llevan a cabo para generar nuevos ingresos o para reducir gastos. Por eso, vale la pena que estudiemos con algo más de detalle cómo se puede aproximar el impacto financiero de los requisitos.
Una manera habitual de generar ingresos es mediante la ampliación de la cuota de mercado del producto (aportando nuevos clientes).
En el caso de Viajes UOC, la posibilidad de vender viajes por Internet está claramente enfocada a la ampliación de la cuota de mercado. Por lo tanto, habrá una serie de funcionalidades que amortizaremos mediante la mencionada ampliación de la cuota.
En el caso del software que no se ha desarrollado pensando en su comercialización, una posible manera de generar ingresos puede ser facilitando la comercialización del mismo.
En todo momento hemos supuesto que el software que estamos desarrollando para Viajes UOC será un software de uso interno, pero una posible vía de generación de ingresos sería hacer que Viajes UOC pudiera vender este software a otras franquicias de agencias de viajes.
También podemos aportar nuevos ingresos mediante el incremento de los ingresos por cliente, ya sea porque con una funcionalidad nueva los clientes existentes están dispuestos a comprar más licencias, porque la funcionalidad se comercialice como un paquete adicional o, simplemente, porque los clientes estén dispuestos a pagar más por el producto si cierto requisito está presente.
En el caso de Viajes UOC, se ha planteado la posibilidad de que el nuevo sistema ayude a ofrecer productos a otras empresas, como, por ejemplo, seguros de viajes.
Otro factor que cabe considerar desde el punto de vista financiero es el coste de oportunidad de un requisito: el coste que supone que la funcionalidad no esté presente en nuestro producto. Por ejemplo, podría pasar que si no implementamos cierta funcionalidad, los clientes actuales dejen de renovar sus licencias y, por lo tanto, se produzca una reducción de los ingresos.
Por ejemplo, si decidimos no permitir que los clientes paguen por Internet y los obligamos a ir a la agencia, tenemos que tener en cuenta que esto puede significar que dejemos de vender algunos viajes, ya que no todos los clientes estarán dispuestos a presentarse en la agencia físicamente.
Finalmente, debemos tener en consideración las mejoras en eficiencia para la organización que supondrá la utilización del nuevo sistema o producto que estamos desarrollando. Estas mejoras acostumbran a llegar mediante la automatización (total o parcial) de procesos manuales o mediante mejoras en la integración y la comunicación entre departamentos.
En Viajes UOC sabemos que una persona dedica tres días cada mes a integrar los datos de ventas con el sistema de facturación. Si conseguimos automatizar este proceso, ahorraremos a la empresa tres días del sueldo de esta persona, que podrá dedicarse a tareas con más valor añadido.

2.Estimación de requisitos

La estimación de requisitos es una tarea muy compleja, puesto que siempre trabajamos con información incompleta (todavía no sabemos exactamente qué problemas nos encontraremos a la hora de implementar el requisito). Por este motivo, todas las técnicas que veremos a continuación tratan de determinar el coste del requisito por aproximación.
La estimación de requisitos consiste, pues, en etiquetar cada requisito con un valor que dé una idea de cómo afecta al coste total del proyecto la inclusión de ese requisito.
Idealmente, este valor es un valor expresado en términos económicos (un importe) a pesar de que, como este coste económico depende de muchos factores que no están relacionados con el trabajo que hay que hacer (como por ejemplo, los costes por hora de trabajo de los desarrolladores), se suelen usar otras magnitudes para expresar el coste.

2.1.Magnitudes para la estimación de requisitos

La magnitud más inmediata para estimar el coste de un requisito es la duración del mismo: la duración nos dice el número de horas de trabajo que supondrá implementar el requisito. Una vez que sabemos el número de horas necesarias (magnitud que necesitaremos para poder planificar el proyecto), estas se pueden trasladar a coste aplicando un precio por hora.
Si hemos estimado el requisito “Publicar el plan de viaje en las redes sociales” en 23 horas de trabajo, para calcular el coste sólo tenemos que multiplicar 23 por el precio/hora y ya tenemos una estimación del coste de desarrollo del requisito.
El principal problema con que nos encontramos a la hora de estimar la duración es que esta depende de una serie de circunstancias muy difíciles de predecir, como, por ejemplo, la moral de los desarrolladores, la materialización o no de los riesgos del proyecto, cambios en el entorno, etc.
Por este motivo, a menudo se usan las “horas ideales” (suponiendo que no hay ninguna interrupción, que los riesgos no se materializan, etc.) y se les aplica un factor de corrección en el momento de calcular el coste. Este factor de corrección es el que recoge el impacto de estas circunstancias difíciles de predecir.
Así, en el ejemplo anterior, si las 23 horas son 23 horas ideales, a la hora de calcular el coste, este no será 23 × precio/hora sino 23 f × precio/hora, donde f es el factor de corrección.
Uno de los problemas con la estimación en “horas ideales” es que, a la hora de comunicar la estimación, se hace difícil justificar la diferencia entre “horas ideales” y “horas reales” (¿cómo puede ser que tardemos 8 horas en hacer una cosa que hemos estimado hacer en 3 horas ideales?).
Por este motivo, las metodologías ágiles proponen una manera alternativa de estimar el coste de los requisitos: en lugar de estimar la duración estimamos el tamaño (una medida arbitraria en función del volumen de trabajo y la complejidad, que supone implementar un requisito en comparación con el resto de requisitos).
Si hemos estimado que “Publicar el plan de viaje en las redes sociales” supone, a grandes rasgos, el triple de trabajo que “Enviar el plan de viaje por correo electrónico”, podemos estimar el coste de “Publicar el plan de viaje en las redes sociales” a partir del coste de “Enviar el plan de viaje por correo electrónico” (multiplicando por tres).
Esta separación simplifica el problema de hacer estimaciones aplicando el principio de “divide y conquistarás”. Ahora la persona o personas que hacen la estimación sólo se tendrán que fijar en un concepto: el tamaño del requisito.
Para reforzar esta separación, la estimación del tamaño se suele hacer en una unidad ficticia, que no tenga ninguna relación con la duración del requisito estimado. Mike Cohn los denomina puntos de historia. La estimación en puntos de historia no solo nos ayuda a separarla de la estimación de la duración, sino que nos centra en la comparación y triangulación como técnicas fiables para estimar historias de usuario (y, por lo tanto, requisitos).
Como por sí misma una estimación de 5 puntos de historia para un requisito no quiere decir nada, nos fuerza a compararla con otros requisitos ya estimados. Entonces es cuando podemos ver que 5 puntos de historia quiere decir que es algo más del doble que otro requisito que hayamos estimado en 2 puntos, y algo más de la mitad que otro requisito que hayamos estimado en 8 puntos.
Finalmente, para obtener la duración (en horas reales) de un requisito a partir de su tamaño (en puntos), se puede hacer a través de la velocidad del equipo:
La velocidad es una medida del progreso de un equipo por unidad de tiempo.
Supongamos que estamos a punto de empezar un proyecto de desarrollo que hemos estimado en 500 puntos.
Antes de finalizar la primera iteración todavía no hemos obtenido ningún beneficio respecto a estimar en horas, ya que no sabemos cuánto se tarda en implementar 500 puntos y, por lo tanto, nuestra estimación de duración es igual de fiable que si la hubiéramos calculado en horas ideales o en horas reales.
Al finalizar la primera iteración, sin embargo, tenemos un dato muy importante: el número de puntos que suman los requisitos implementados durante aquella iteración. Si hemos implementado completamente, por ejemplo, requisitos por un total de 90 puntos, ya podemos hacer una primera estimación basada en datos reales: a 90 puntos por iteración, necesitaremos entre 5 y 6 iteraciones para finalizar el proyecto. En este caso, decimos que la velocidad del equipo es de 90 puntos.
A medida que vamos completando iteraciones, tendremos más valores de velocidad para estimar la velocidad de las iteraciones que nos quedan antes de acabar el proyecto y, por lo tanto, la fiabilidad de nuestra estimación irá creciendo.

2.2.Precisión de las estimaciones

La estimación en el desarrollo de sistemas informáticos es un problema difícil ya identificado desde hace mucho tiempo. Algunos autores (como Barry Boehm, creador del ciclo de vida de desarrollo en espiral) ya hablaban de ello en los años ochenta diciendo que las estimaciones en ingeniería del software presentaban desviaciones importantes.
Las causas de estas dificultades son muchas, incluyendo la carencia de información, la incertidumbre, la presencia de riesgos, etc. Es por eso por lo que es importante ser capaces de estimar de forma pragmática conociendo cuál es la precisión que podemos esperar de las estimaciones que hacemos. Por estas razones, hay que elegir bien qué valores adjudicamos a nuestras estimaciones.
Los físicos, por ejemplo, cuando miden la realidad, indican los valores con un número de dígitos significativos que refleja la precisión de la medición. Indicar que el peso de una muestra es de 6,00 g no tiene sentido si el instrumento de medición tiene una precisión de 0,1 g. En todo caso, dicen que el peso es de 6,0 g. De manera parecida, a la hora de hacer estimaciones de requisitos, hay que elegir una forma de expresar las estimaciones que refleje la precisión que tienen.
Por otro lado, las personas somos mejores haciendo estimaciones por comparación y triangulación si la medida de aquello que estimamos es relativamente parecida. Mike Cohn propone los valores 1, 2, 3, 5 y 8 para estimar requisitos de medida parecida.
Supongamos, por ejemplo, que estamos estimando la altura de la Torre Agbar de Barcelona en una unidad ficticia, los “puntos de altura”. Saber que una persona tiene una altura estimada de 1 punto no nos ayudaría mucho, puesto que nos cuesta comparar dos alturas tan diferentes. ¿Mide 50 veces lo que una persona? ¿100 veces?
En cambio, si sabemos que la Torre Mapfre de Barcelona está estimada en 3 puntos de altura, podemos llegar a la conclusión de que son de alturas similares y asignar también un 3 a la Torre Agbar.
Teniendo en cuenta que la Torre Agbar mide140 m de altura y la Torre Mapfre mide 150 m, el valor estimado es bastante bueno (el valor real sería 2,8) y, para muchos usos, suficiente.
Por esta razón, a medida que los requisitos tienen granularidad más gruesa, serán más grandes y difíciles de estimar por comparación. Habrá que tener en cuenta, pues, que la precisión todavía será menor. Para reflejarlo, de nuevo, Mike Cohn propone añadir los valores 13, 20, 40 y 100 (redondeando y añadiendo imprecisión a los 13, 21, 34, 55, 89 que seguirían en la escala de Fibonacci).
Siguiendo con el ejemplo anterior, si estimamos alturas de elementos asignando 1 punto de altura a la altura de una persona, diríamos que la altura de las torres Agbar y Mapfre es de 100. No sería una estimación nada precisa, pero como, a diferencia de las torres, los requisitos grandes se descompondrán en requisitos de granularidad más fina cuando estemos más cerca de su implementación, entonces ya refinaremos la estimación calculando los requisitos en los que se ha descompuesto.

2.3.Técnicas de estimación

A continuación veremos algunas de las técnicas que podemos usar para estimar el coste (sea a partir de la duración o a partir de la medida) de un requisito.
2.3.1.Comparación y triangulación
Una de las técnicas más básicas e importantes para la estimación de requisitos es la comparación. Esta consiste, a la hora de estimar un requisito, en buscar otro ya estimado que tenga un coste comparable, y establecer el coste del nuevo requisito por comparación con el requisito ya estimado.
Supongamos que queremos estimar el requisito “El usuario tiene que poder compartir el plan de viaje en las redes sociales”.
Como no sabemos cuál puede ser el coste de este requisito, buscamos otro que ya tenga un coste parecido, como por ejemplo, “El usuario tiene que poder compartir la ficha de un destino en las redes sociales” y miramos cuál es la estimación de este requisito (por ejemplo, seis días persona).
En lugar de estimar el nuevo requisito de cero por cualquier otra técnica, por comparación podemos decir que también tendrá un coste de unos seis días/persona de desarrollo.
Días/persona
Los días/persona o días/hombre son otra forma de aproximar la duración de un requisito: 1 día/persona representa el trabajo que una persona hace en 1 día de 8 horas (sean ideales o reales).
Así, un requisito estimado en 3 días/persona implica que una persona sola tardaría 3 días en implementar el requisito.
Hay que tener en cuenta, sin embargo, que esto no quiere decir necesariamente que tres personas lo implementen en 1 día. Cómo dice el dicho: “Nueve mujeres no hacen un hijo en 1 mes”.
A menudo, es muy difícil encontrar un requisito del mismo tamaño y se usa la técnica de triangulación para aproximar el coste del requisito. En este caso, en lugar de comparar con un solo requisito, comparamos con dos: uno más grande y otro más pequeño. Como estamos incorporando más información al cálculo (ya no dependemos de una sola estimación, sino que dependemos de dos), el resultado es más fiable que en el caso anterior.
Supongamos de nuevo que queremos estimar el requisito “El usuario tiene que poder compartir el plan de viaje en las redes sociales”.
Si quisiéramos aplicar la técnica de triangulación, lo que haríamos sería encontrar uno más pequeño (como por ejemplo, “El usuario tiene que poder consultar los datos de su viaje”, 3 días/persona de trabajo) y uno más grande (como por ejemplo, “El usuario tiene que poder identificarse en el sistema con las credenciales de las redes sociales a través del protocolo OAuth”, 13 días/persona) y determinaríamos la relación respecto a estos dos:
“El usuario tiene que poder compartir el plan de viaje en las redes sociales” es el doble de grande que “El usuario tiene que poder consultar los datos de su viaje” (3 × 2 = 6) y, al mismo tiempo, es la mitad que “El usuario tiene que poder identificarse en el sistema con las credenciales de las redes sociales a través del protocolo OAuth”) (13/2 = 6,5). Por lo tanto, tomaremos como valor de la estimación 6 días/persona.
2.3.2.Estimación colaborativa: planning poker
Una manera de paliar el problema de la información incompleta es hacer uso de las técnicas colaborativas de estimación, como por ejemplo, el planning poker.
Mediante la estimación colaborativa, las diferentes personas involucradas en la estimación comparten su conocimiento sobre el problema que hay que solucionar, así como sobre el espacio posible de soluciones.
La estimación es mucho más fiable si participan en ella los desarrolladores que tienen que implementar el requisito, puesto que son quienes mejor conocen el espacio posible de soluciones. Como efecto colateral, el equipo de desarrollo estará mucho más comprometido con una estimación que ellos mismos hayan hecho que no con una estimación que les venga dada.
La técnica del planning poker, propuesta por James Grenning en el 2002, recibe su nombre del hecho de que, igual que en el juego del póquer, cada persona hace su estimación sin saber cuál será la estimación de los demás (y, de hecho, a menudo se hace con una baraja de cartas especial).
En una sesión de planning poker se reúne a un grupo de personas y se reparte a cada participante un conjunto de cartas con los diferentes valores acordados como posibles para las estimaciones.
Para estimar un requisito concreto, se comenta en voz alta el requisito para que todo el mundo trabaje con la misma información. A continuación, cada participante escoge una carta y la pone encima de la mesa boca abajo de manera que el resto de participantes no puedan ver el valor elegido.
Una vez que todos los participantes han elegido su carta, se descubren los valores. En el caso de no coincidir, los participantes vuelven a hablar para entender el motivo de la diferencia de criterio y se vuelve a repetir el paso anterior hasta que se llega a una coincidencia en las diferentes estimaciones.
El diálogo que se produce antes de estimar el requisito, así como el que se produce en caso de no coincidencia es el que nos permite paliar el problema de la información incompleta. Por este motivo es muy importante que, en el caso de no coincidir en las estimaciones, los participantes no se limiten a hacer una media de las diferentes estimaciones, sino que hablen y vuelvan a estimar hasta que todo el mundo coincida en el mismo valor.

2.4.Estimación de requisitos no funcionales

La estimación de cada requisito mediante las técnicas descritas es bastante clara para los requisitos funcionales que se van implementando de forma individual. ¿Cómo se estiman, sin embargo, los requisitos no funcionales?
Algunos de estos requisitos no funcionales son locales a alguno o algunos requisitos funcionales (es decir, solo afectan a un requisito funcional o a un número reducido de ellos). Estos se consideran restricciones sobre el requisito funcional y, por lo tanto, se tienen en cuenta a la hora de estimar el requisito funcional, pero no se estiman por sí mismos.
Por ejemplo, si tenemos el requisito funcional “Publicar el plan de viaje en la red social X”, podría ser que esta red nos obligara a cumplir algún requisito no funcional, como por ejemplo, “cuando se publica algo en la red social, tenemos que enviar la petición de publicación, la red nos enviará una petición de confirmación a una dirección predefinida y, si la confirmamos, la publicará. Esta petición de confirmación tiene un tiempo máximo de un segundo (y si en un segundo no se ha confirmado, se descartará la petición de publicación)”.
En este caso, el tiempo de respuesta de la confirmación es un requisito local, puesto que sólo afecta a la publicación en esta red en cuestión y, por lo tanto, lo podemos incorporar a la estimación de tamaño del requisito “Publicar el plan de viaje en la red social X”.
Otros requisitos no funcionales son globales (es decir, afectan a todos los requisitos funcionales o a la mayor parte de estos). Estos, de nuevo, se tendrán en cuenta como restricciones que pueden tener efecto sobre qué soluciones son válidas para resolver un requisito funcional y, por lo tanto, afectarán a las estimaciones de los requisitos funcionales, pero no se estiman por sí mismos.
Supongamos, por ejemplo, que tenemos un requisito no funcional de rendimiento, que dice que el sistema tiene que dar respuesta a cualquier consulta en menos de 2 segundos. Este requisito será global y se tendrá en cuenta a la hora de estimar cualquier requisito funcional, puesto que puede afectar a la estimación, haciéndola más costosa de implementar.
En algunos casos, sin embargo, un requisito no funcional puede requerir alguna tarea de desarrollo que se puede incluir en la lista de requisitos del producto. En este caso, el requisito no funcional tiene una estimación propia y es un requisito más a tener en cuenta.
Supongamos que tenemos un requisito que consiste en adaptar el diseño ya existente para que la funcionalidad ya implementada también satisfaga este requisito. Esta tarea vendrá dada por el propio requisito no funcional y, por lo tanto, el requisito no funcional también tendrá que ser estimado y tenido en cuenta durante el resto del proceso de gestión de requisitos.

3.Priorización y selección de requisitos

Otro elemento básico para decidir si un requisito formará parte o no del conjunto de requisitos del software desarrollado es el valor que aporta. El valor aportado es siempre una medida relativa al resto de requisitos y depende, como hemos dicho anteriormente, de los stakeholders (diferentes stakeholders pueden tener percepciones diferentes del valor de un requisito).
Supongamos que queremos estimar el valor del requisito “Una agencia tiene que poder vender productos que no sean de Viajes UOC”. Para Dolores Sánchez (propietaria de una agencia de viajes franquiciada) es muy importante que el sistema cumpla este requisito, pero en cambio, para Sonia Cases (directora de marketing de Viajes UOC) es muy importante que no lo cumpla.
Denominamos priorización de los requisitos al proceso mediante el cual ordenamos por prioridad los requisitos.
La priorización de requisitos es un elemento clave de la planificación de cualquier proyecto, especialmente si seguimos el ciclo de vida incremental, puesto que la priorización de requisitos nos dice en qué orden tenemos que ir implementando las diferentes funcionalidades.
La selección de requisitos consiste en seleccionar, finalmente, cuál de los requisitos candidatos incorporaremos al producto y cuál descartaremos.
Más allá de los conflictos evidentes, a menudo es muy difícil para los stakeholders renunciar a un requisito que les aporta valor pero que no ha sido seleccionado. Por este motivo, hay técnicas que nos ayudan a establecer la prioridad relativa de los requisitos. A continuación veremos algunas de estas técnicas.
Hay que advertir que todas las técnicas que veremos tienen su origen en algún método de desarrollo y, por eso, a veces la nomenclatura puede no ser coherente entre distintas técnicas. A la hora de estudiarlas, pues, es importante fijarse en la finalidad de la técnica más que la nomenclatura.
Así, del mismo modo que sabemos que cuando hablamos del backlog de producto este término es habitual en los métodos ágiles para dar nombre a la lista de historias de usuario pendientes de implementar, también podemos aplicar el mismo concepto a las listas de requisitos o a los casos de uso. Muchas de estas técnicas se pueden combinar con las técnicas descritas en otros métodos de desarrollo.
Hemos clasificado las técnicas que estudiaremos en dos grupos: por un lado, las relacionadas con la gestión de productos de software, que ven el producto como un todo y están relacionadas con otras disciplinas diferentes a la ingeniería de requisitos propiamente dicha. Por otro lado, las que hemos denominado “técnicas de priorización”, más enfocadas a, dado un conjunto concreto de requisitos, determinar la prioridad relativa entre ellos.

3.1.Gestión de productos de software

Para establecer la prioridad de los requisitos, tenemos que tener en cuenta, además del coste y el valor, otros factores relacionados con la gestión del producto de software, como por ejemplo, cuál es la oportunidad de mercado, cuál es el objetivo que se quiere lograr, etc.
Por este motivo, es importante que conozcamos algunas de las herramientas básicas de la gestión de productos antes de estudiar las técnicas concretas que usaremos para priorizar los requisitos.
3.1.1.La visión del producto
La visión del producto es la herramienta básica para asegurar que la colaboración entre los diferentes stakeholders y los desarrolladores sea fructífera, puesto que nos asegura que todos los actores implicados comparten los mismos objetivos y avanzan en la misma dirección: la que nos lleva hacia la materialización de la visión del producto.
La visión del producto describe por qué se está llevando a cabo el desarrollo y cuál es el estado final deseado.
La visión del producto nos ayuda a determinar cómo queremos que sea el producto que desarrollaremos y, por lo tanto, nos ofrece un primer criterio de priorización: son más prioritarios aquellos requisitos que nos ayudan a materializar la visión del producto.
Más concretamente, la visión del producto tendría que poder responder las siguientes preguntas:

  • ¿A quién va dirigido el producto? ¿Quién lo comprará? ¿Quién lo usará?

  • ¿Qué necesidad o qué oportunidad cubre? ¿Cuál es el valor añadido del producto?

  • ¿Qué atributos del producto son críticos para su éxito? ¿Cómo será, a grandes rasgos, el producto?

  • ¿Cómo se compara el producto con los demás productos existentes? ¿Qué es lo que lo hace diferente?

  • ¿Cómo se recuperará la inversión? ¿Cuáles serán las fuentes de ingresos que generará el producto?

  • ¿Es factible pensar que lo podremos desarrollar y amortizar?

Esta visión, sin embargo, no tiene que ser un documento formal, sino, idealmente, una frase que condense toda esta información. Jim Highsmith nos sugiere esta plantilla:
Para <clientes potenciales> que <explicación de la necesidad o de la oportunidad>, el <nombre del producto> es un <categoría del producto> que <beneficio clave, razón principal para la compra>. Al contrario que <principal alternativa con la que compite el producto>, nuestro producto <explicación de la diferenciación principal>.
En el caso del nuevo sistema de ventas de viajes, de Viajes UOC, podríamos usar la siguiente visión de producto:
Para las agencias de viajes que quieren vender viajes por Internet, el nuevo sistema es un sistema de ventas que permite interactuar con los clientes a través de Internet. Al contrario que el sistema actual, nuestro producto permite un modelo mixto entre compra en línea y compra en la agencia.
La finalidad de la visión del producto es ayudarnos a mantener una línea coherente durante todo el proceso de desarrollo y asegurarnos de que todos los actores implicados en el desarrollo (stakeholders y desarrolladores) avanzan en una misma dirección.
Para poder conseguir esto, es importante que la visión sea compartida y unificadora. Si la visión no es compartida, cada stakeholder (y también los desarrolladores) avanzará en una dirección diferente y se despilfarrarán los esfuerzos. Es importante, pues, que todos los actores implicados en el desarrollo estén comprometidos con la misma visión.
La visión del producto también tiene que dar margen para la creatividad individual. Una visión de producto demasiado restrictiva limita la capacidad de las personas de implicarse en su consecución.
Finalmente, la visión del producto tiene que ser breve y concisa. Un ejemplo es la llamada “prueba del ascensor”: tenemos que poder explicar la visión del producto en el tiempo que se tarda en subir a la oficina en el ascensor. Es importante resaltar los atributos clave del producto y no hacer una lista completa de funcionalidades.
En este sentido, Jim Highsmith nos recuerda que “encontrar 15 o 20 características para un producto es fácil. Lo que es realmente difícil es decidir cuáles son las 3 o 4 que harán que se decida comprar el producto”.
Jim Highsmith nos recomienda la técnica de “diseñar la caja” para encontrar la visión del producto. Esta técnica consiste en hacer grupos de entre 4 y 6 personas (idealmente de varios perfiles) y, asumiendo que el producto se venderá empaquetado en una caja, diseñarla por delante y por detrás. En la parte de delante estará el nombre del producto, una ilustración y tres o cuatro puntos que ayuden a “vender” el producto. En la parte de atrás, habrá una descripción más detallada del producto, así como los requisitos.
Lo más habitual es que equipos diferentes acaben con cajas muy diferentes, lo cual es un buen punto de partida para una discusión que ayude a identificar la visión del producto y a conseguir que esta sea compartida por todo el mundo.
3.1.2.Producto mínimo entregable
Otra herramienta de gestión de productos es el producto mínimo entregable: el producto mínimo entregable es el producto con la funcionalidad mínima que cumple las necesidades de unos clientes concretos.
El producto mínimo entregable es el producto mínimo que cumple la visión del producto.
Por lo tanto, los requisitos que forman parte del mismo son los que aportan más valor y, en un desarrollo incremental, son los requisitos que priorizaríamos.
Entregar un producto de mínimos nos permite experimentar con el mercado potencial y reaccionar en función de su respuesta en lugar de tener que predecir su comportamiento. También nos ayuda a minimizar las pérdidas en el supuesto de que el producto no tenga éxito y haya que cancelar su desarrollo.
Un buen ejemplo de producto mínimo es el teléfono móvil iPhone. Cuando se presentó en el 2007, carecía de muchas de las funcionalidades que eran habituales en otros productos de la competencia, como copiar y pegar texto o mandar un mensaje SMS a un grupo de destinatarios.
A cambio de estas limitaciones, Apple pudo introducir el producto en el mercado antes que la competencia (siendo, por ejemplo, uno de los primeros teléfonos en tener una pantalla táctil capacitiva que cubriera casi toda la superficie del teléfono).
Más adelante, Apple pudo reaccionar al mercado e introducir las características que el mercado realmente quería, como la tienda de aplicaciones, creando un nuevo mercado capaz de mover miles de millones de dólares.
La experimentación con el mercado se tiene que hacer de manera organizada, siguiendo un proceso de cuatro etapas conocido como el “ciclo de Deming”:
1) Planificar (plan). Establecemos una hipótesis (por ejemplo, que los clientes están interesados en pagar por Internet).
2) Hacer (do). Implementamos la versión más básica de la funcionalidad para sacarla al mercado y ver cómo reacciona este. También se podría aplicar a la creación de modelos de la interfaz de usuario o prototipo, de modo que no hubiera que implementar la funcionalidad completa (reduciendo así el coste del experimento).
3) Verificar (check). Verificamos el resultado del experimento y determinamos si ha tenido éxito o no. ¿Era correcta la hipótesis de partida? Si no lo era, ¿podemos determinar cuál era el error?
4) Actuar (act). Decidimos cuál será nuestro siguiente paso en función de cómo haya ido el experimento. En caso de que no haya tenido suficiente éxito, este paso podría ser el de eliminar la funcionalidad del producto, modificarla para que funcione de manera diferente, desarrollarla algo más o probar algo radicalmente diferente.
La ventaja de este proceso es que nos permite trabajar con información empírica (datos que hemos recogido a través de un experimento) y no con suposiciones.
3.1.3.User-story mapping
Esta técnica nos ayuda a determinar cuáles son los requisitos que tienen que formar parte del mínimo producto entregable. Se basa en la idea de organizar las funcionalidades en dos dimensiones: el eje vertical determina la importancia (grado de necesidad) de una funcionalidad concreta mientras que el eje horizontal se utiliza para situar las funcionalidades de importancia similar al mismo nivel.
75593m3002.gif
Una columna de un mapa de historias incluye todas las tareas relacionadas con una funcionalidad concreta ordenadas por prioridad. En la parte superior están las más necesarias para cumplir la visión del producto mientras que en la parte inferior están las menos necesarias.
Una fila de un mapa de historias incluye todas las tareas que tienen un nivel de importancia similar. No implementaremos ninguna funcionalidad de una fila del mapa hasta que no hayamos implementado todas las funcionalidades de las filas superiores.
75593m3003.gif
La principal ventaja de esta técnica es que permite maximizar el valor obtenido por el desarrollo, puesto que, al hacer el recorrido de la tabla a lo ancho, evitamos situaciones en las que tenemos una funcionalidad muy desarrollada pero otra igual de importante sin empezar.

3.2.Técnicas de priorización

En este subapartado, como indicamos, presentamos aquellas técnicas que, en lugar de ver el producto como un todo, se centran en determinar la prioridad relativa de los requisitos en un conjunto de requisitos determinado.
3.2.1.La técnica de los 100 dólares
La técnica de los 100 dólares (Leffingwell y Widrig, 2000) consiste en dar 100 dólares imaginarios a cada uno de los stakeholders y decirles que los repartan entre los diferentes requisitos. Idealmente, cada stakeholder repartirá sus dólares entre los requisitos según el valor de cada uno. Así, si un requisito es muy importante, se le asignarán muchos dólares para asegurarse de que salga escogido, mientras que si no lo es, se le asignarán menos (o ninguno).
De este modo daremos prioridad a aquellos requisitos que, o bien son muy importantes para alguna de las partes (que habrá puesto una gran cantidad de dólares para asegurarse de que el sistema cumple ese requisito) o bien son importantes para muchas de las partes implicadas (y, por lo tanto, por acumulación de pequeños importes al final consiguen sumar un importe elevado).
Supongamos, por ejemplo, que tenemos que priorizar estos tres requisitos:

  • El cliente tiene que poder ver quién ha hecho una recomendación.

  • El cliente tiene que poder compartir el plan de viaje en las redes sociales.

  • El cliente tiene que poder pagar por transferencia bancaria.

Si nos piden, individualmente, si tenemos que incluir o no cada uno de los requisitos, la respuesta será, probablemente, que sí.
En cambio, si nos dicen que sólo tenemos dos votos y que los tenemos que repartir entre todos los requisitos, nos veremos obligados a decidir cuál de los tres es menos importante.
Si además añadimos que otros stakeholders también votarán, es probable que, incluso, nos planteemos dar los dos votos al mismo requisito para asegurarnos de que salga escogido (sólo en el supuesto de que este requisito sea realmente más importante que los otros).
3.2.2.Prioridades limitadas
Uno de los problemas que nos podemos encontrar a la hora de priorizar los requisitos es decidir la prioridad relativa de requisitos que no tienen ninguna relación entre ellos.
¿Es más prioritario mostrar la foto del hotel en la ficha de detalle de un hotel o mostrar con un símbolo gráfico si una recomendación es positiva o negativa?
Para ahorrarnos largas discusiones sobre si una funcionalidad es, por ejemplo, de prioridad 25 o 26, muchos métodos recomiendan limitar el número de prioridades posibles. Así, Alistair Cockburn nos propone clasificar los diferentes requisitos de un sistema en sólo tres categorías:

  • Sacrificar otros requisitos por este.

  • Intentar mantener.

  • Sacrificar este requisito por otros.

Siguiendo esta clasificación, si decidimos que la facilidad de uso tiene la prioridad de “Sacrificar otros por este”, salir al mercado lo antes posible tiene la prioridad de “Intentar mantener”, y rendimiento tiene la prioridad de “Sacrificar por otros”, estamos diciendo que estamos dispuestos a retrasar la salida del producto al mercado a cambio de mejoras en la facilidad de su uso, pero no a cambio de su rendimiento.
Otro ejemplo de prioridades limitadas es el llamado MoSCoW (el acrónimo viene de los nombres de las prioridades que propone) propuesto por el método DSDM (dynamic systems development method), donde, para cada iteración, se decide qué requisitos son:

  • Musthave (sin estos requisitos la iteración es un fracaso).

  • Shouldhave (son igual de importantes que los musthave, pero podemos pasar sin ellos temporalmente).

  • Couldhave (también denominados nice to have en el sentido de que su presencia incrementa la satisfacción del cliente a pesar de ser menos prioritarios).

  • Won’t have (no entran en la iteración actual y, por lo tanto, de momento no los tenemos en cuenta).

3.2.3.El modelo Kano
El modelo Kano es una teoría de desarrollo de productos orientada a la satisfacción del cliente. La finalidad de este modelo es predecir el nivel de satisfacción del cliente (para poderlo maximizar) en función de cuáles sean las características presentes en el producto.
Así pues, este modelo nos ayudará a determinar cuáles de las características del producto (es decir, qué requisitos) son más importantes para garantizar el éxito del producto desarrollado (y, por lo tanto, más prioritarias).
En la figura siguiente podemos ver tres líneas, que corresponden a las llamadas características básicas, lineales y apasionantes.
75593m3004.gif
Las características básicas son aquellas que el cliente espera del producto. También se las conoce como características obligatorias puesto que, si carece de alguna de estas, el cliente considerará el producto incompleto. Su presencia, en cambio, no aumenta significativamente la satisfacción del cliente.
Los clientes de Viajes UOC considerarán la posibilidad de buscar un hotel a partir del nombre de la ciudad donde quieren ir como una funcionalidad básica, en el sentido de que, si no pueden hacer la búsqueda, creerán que nuestro producto está incompleto y su satisfacción será muy baja. En cambio, por muy bien que implementemos la búsqueda de hotel a partir del nombre de la ciudad, es difícil que consigamos incrementar significativamente su satisfacción más allá de cierto punto. Es por esto que, en la figura anterior, la flecha correspondiente a las características básicas acaba plana.
El segundo grupo que encontramos, las lineales (en inglés, performance features) se caracterizan por tener una relación lineal entre la presencia de la característica y el nivel de satisfacción del cliente (“cuanto más, mejor”).
En el caso de Viajes UOC, la amplitud de la base de datos de hoteles y destinos podría ser una característica lineal: cuanto más amplia sea la selección de hoteles y destinos más satisfechos estarán nuestros clientes.
Hay, sin embargo, un tercer grupo de características: las apasionantes. Mientras que las características lineales nos permiten lograr un buen nivel de satisfacción del cliente, normalmente son características que el cliente espera del producto. Por lo tanto, pueden no ser suficientes para hacer que el producto destaque entre las alternativas. Las características apasionantes son las más difíciles de encontrar, ya que se trata de encontrar una necesidad que el cliente todavía no sabe que tiene; precisamente esto es lo que hace que aumente tanto el nivel de satisfacción.
Poder compartir el plan de viaje en las redes sociales podría ser una característica “apasionante” del nuevo sistema de ventas de Viajes UOC si consideramos que es una característica que los clientes no esperan, pero que, cuando esté implementada, utilizarán con asiduidad. Sin embargo, el problema con este tipo de características es, tal como hemos dicho antes, que hasta que no las ponemos en manos de los clientes no podemos saber si son o no apasionantes.
El modelo Kano hace una predicción interesante: a lo largo del tiempo, las características apasionantes se convierten en lineales y las lineales, en básicas, por lo cual, con el paso del tiempo hay que revisar la clasificación de las diferentes características.
Un ejemplo representativo de este hecho es la inclusión de la cámara de fotos en los teléfonos móviles. En su momento, era una característica apasionante que distinguía los teléfonos que la incorporaban del resto. En cambio, con el tiempo su presencia se fue normalizando hasta convertirse en una característica lineal (cuanta más resolución mejor) y, más adelante, en una característica básica: se espera de cualquier teléfono móvil que incorpore una cámara de fotos y, si no la incorpora, consideramos que tenemos un producto incompleto.
Lo que nos enseña este modelo es que, para maximizar la satisfacción de los clientes, no basta con preguntar a los stakeholders qué esperan del producto a desarrollar, sino que tenemos que hacer propuestas innovadoras que nos permitan destacar positivamente.
La finalidad del modelo Kano es poder encontrar el punto de equilibrio que nos permita combinar características básicas, lineales y apasionantes de manera que maximicemos la satisfacción del cliente.
Clasificar un requisito concreto según el modelo Kano no es fácil, puesto que lo que nos parece apasionante a nosotros puede dejar indiferente al resto. Por eso, es importante poder contar con la opinión de los usuarios potenciales del producto, habitualmente a través de un cuestionario.
El problema con los cuestionarios es que podemos perder información. Por ejemplo, en el caso de la cámara en el teléfono móvil, seguramente si hubiéramos preguntado si creíamos que era importante tener una cámara en el móvil, hubiéramos contestado que no, pero esto no significa que esta característica no fuera deseable.
Mike Cohn nos propone un tipo de cuestionario diseñado para evitar estos problemas y que consiste en hacer dos preguntas al usuario potencial: una preguntando qué le parecería disponer de una característica y otra (en forma “disfuncional”) preguntando qué le parecería no disponer de la misma. La combinación de estas dos preguntas es la que nos dice cómo tenemos que clasificar la característica.
En el caso de Viajes UOC, podríamos hacer a nuestros clientes potenciales dos preguntas: “¿Qué piensas de tener la posibilidad de compartir el plan de viaje en las redes sociales?” y dar cinco respuestas posibles: “Me gusta”, “Era de esperar”, “Me es indiferente”, “Puedo convivir con esto” (con el hecho de poder compartir el plan de viaje) o “No me gusta”.
Después podemos hacer la pregunta de manera disfuncional: “¿Qué piensas de no tener la posibilidad de compartir el plan de viaje en las redes sociales?” y dar las mismas cinco opciones.
A partir de la información obtenida podemos cruzar las respuestas con las dos preguntas para decidir dónde situamos el requisito en cuestión:
75593m3005.gif
Esta figura introduce tres nuevos tipos de característica: contraria (el usuario quiere la característica contraria a la propuesta), cuestionable (no tenemos muy claro dónde clasificarla) e indiferente (no afecta a la satisfacción del cliente).
Finalmente, hay que agregar los resultados obtenidos de los diferentes clientes para decidir en qué categoría clasificamos cada requisito. Podemos recoger los resultados estadísticos y clasificar los requisitos según la distribución de las respuestas:

Característica

A

L

B

I

C

Q

Categoría

Generar el plan de viaje

10%

12%

52%

8%

10%

8%

Básica

Compartir el plan de viaje

40%

20%

20%

10%

5%

5%

Apasionante

Pagar en la agencia

2%

11%

15%

40%

7%

25%

Indiferente

Amplitud de la base de datos de hoteles

6%

33%

32%

12%

0%

17%

Lineal/Básica
3.2.4.A/B testing
La técnica A/B testing es una técnica que nos permite evaluar dos opciones (A y B) para decidir cuál es más atractiva para los usuarios del software o más eficaz para conseguir un objetivo concreto.
Esta técnica se basa en el siguiente proceso:
1) Se deciden cuáles son las dos alternativas (por ejemplo, dos maneras de compartir el plan de viaje).
2) Se establece una manera de determinar la eficacia de cada métrica (por ejemplo, cuántos usuarios han compartido el plan de viaje con cada opción concreta).
3) Exponer un subconjunto de los usuarios a la opción A y otro a la B y medir.
A partir de los datos recogidos podemos ver fácilmente cuál de las dos alternativas es más eficaz para conseguir nuestro objetivo de que los usuarios compartan su plan de viaje en Internet.
Esta técnica se usa mucho en desarrollo web, donde, por ejemplo, A es el diseño actual de la aplicación/lugar web y B es el nuevo diseño. Se distribuye el tráfico de usuarios entre las dos versiones y se recoge la medida de la métrica decidida.
Por ejemplo, supongamos que Viajes UOC se está planteando el diseño de la página principal de la aplicación web y queremos decidir dónde situaremos el formulario de inscripción.
Lo que haremos será dividir a los usuarios en dos grupos: al grupo A le mostraremos una distribución de elementos y al grupo B otra:
75593m3006.gif
A continuación, medimos el número de altas con la versión A y el número de altas con la versión B y seleccionamos la versión que obtenga un número mayor de altas. Así, por ejemplo, si el grupo A ha obtenido un 30% de altas y el grupo B un 60%, nos quedaremos con la opción B.
Una prueba A/B se hace, pues, con un objetivo concreto, como por ejemplo incrementar el número de inscripciones o incrementar la ratio de ventas por visita.
Con este objetivo presente, se plantean diferentes alternativas (diferentes ubicaciones de los elementos del diseño, demanda de más o menos datos durante el proceso de inscripción, etc.) y se lleva a cabo la prueba. Algunas de las características que se prueban normalmente son:

  • Diseño gráfico (colores, textos, ubicación de los diferentes elementos en la pantalla) del elemento que tiene que usar el usuario para llevar a cabo la acción concreta (botón de “Comprar”, botón de “Registrarse”, etc.).

  • En general, los diferentes textos, tanto a nivel de títulos como de descripciones de los productos.

  • Longitud de los formularios y tipos de campos de los formularios.

  • Precio del producto y/o promociones especiales.

  • Relación entre texto e imágenes en las pantallas.

Es importante probar las dos alternativas en el mismo momento del tiempo, puesto que, de no hacerlo así, es posible que en las decisiones de los usuarios influyan otros factores.
Por otro lado, como en cualquier estudio estadístico, es importante acumular una muestra significativa (es decir, no finalizar la prueba demasiado pronto), puesto que, de lo contrario, es posible que las conclusiones a las que lleguemos no sean correctas. Hay que tener en cuenta, sin embargo, que tampoco es conveniente alargar demasiado el estudio, ya que, mientras tanto, tenemos un porcentaje significativo de los usuarios usando una versión del software que tiene un rendimiento peor que la otra (por ejemplo, la ratio de ventas por visita es menor).
También hay que evitar confusiones a los usuarios y mostrar una versión consistente a cada persona. Un caso típico de error de A/B testing es aquel en el que una persona puede ver dos precios diferentes para un mismo producto en visitas diferentes de una tienda on-line. En este caso, esta diferencia generará desconfianza y puede afectar negativamente a las ventas. En la misma línea, hay que aplicar las variaciones a toda la aplicación. Por ejemplo, si estamos probando colores para el botón de “Comprar”, es importante que, para una persona en concreto, el botón en cuestión se muestre siempre del mismo color, que no se muestre de un color en una pantalla y de otro color en otra.

3.3.Selección de requisitos: El backlog del producto

El resultado de la selección de requisitos candidatos es una lista de los requisitos priorizados y estimados que se tendrán en cuenta para el proyecto. Scrum, uno de los métodos ágiles más populares, da el nombre de backlog de producto a esta lista. Nosotros usaremos el mismo término para referirnos a ella. Así pues:
El backlog es una lista priorizada de trabajo pendiente para finalizar el proyecto de desarrollo.
El contenido más habitual de un backlog son los requisitos funcionales. Habitualmente, en los proyectos ágiles, estos requisitos se documentan en forma de historia de usuario; pero también se pueden documentar en forma de caso de uso o utilizando cualquier otra técnica de documentación de requisitos funcionales.
Además, pero, un backlog tiene que incluir los requisitos no funcionales y, en general, cualquier otra tarea necesaria para finalizar el proyecto, como por ejemplo, tareas de preparación del entorno, tareas de lanzamiento, etc.
Denominamos entrada de backlog a cada uno de los elementos que forman un backlog de producto, ya sean historias de usuario, casos de uso, otros requisitos funcionales o no funcionales o tareas que hay que hacer.
De hecho, no es necesario que todas las entradas del backlog sean homogéneas. Podríamos tener un backlog donde se describen los requisitos funcionales como historias de usuario y donde también se describe un requisito de usabilidad, por ejemplo, mediante un pequeño esbozo a mano alzada de las pantallas.
Pichler dice que, además de estar estimado y priorizado, un buen backlog tiene que tener las cualidades de estar detallado apropiadamente y de ser emergente.
Un backlog está priorizado, habitualmente, porque las entradas que contiene se ordenan de más a menos prioridad. En algunos casos, sin embargo, puede ser útil etiquetar cada entrada con un número o descripción que indique la prioridad.
Un backlog está estimado porque todas las entradas están estimadas de tal modo que, para cada una, tenemos una estimación del coste de desarrollo que aquella entrada implica.
Un backlog está detallado apropiadamente cuando usa niveles de detalle diferentes para las entradas que contiene (y el nivel de detalle es el adecuado para cada entrada).
Un backlog es emergente porque puede evolucionar a medida que cambia el conocimiento que tenemos sobre las necesidades de los stakeholders y las tareas que hay que hacer en cada momento.
3.3.1.Requisitos no funcionales y el backlog
La dinámica del backlog consiste en una lista ordenada de requisitos y otras tareas que se van consumiendo a medida que se desarrollan. ¿Cómo encajan aquí los requisitos no funcionales?
Los requisitos no funcionales típicamente se documentan en el backlog en forma de restricciones.
Así, por ejemplo, el requisito de que todas las pantallas de la aplicación tienen que mostrar el logo de Viajes UOC es una restricción, puesto que nos limita a la hora de implementar las pantallas.
Como hemos visto anteriormente, podemos distinguir entre requisitos no funcionales locales y globales. Los requisitos no funcionales locales expresan restricciones que afectan a un pequeño conjunto de los requisitos funcionales, mientras que los requisitos globales afectan a gran parte o a todos los requisitos funcionales.
El ejemplo antes mencionado, que indica que todas las pantallas tienen que tener el logo de Viajes UOC, es evidentemente un requisito global. De manera parecida, también podemos considerar que el requisito de que el sistema sea utilizable sin red es global.
En cambio, el requisito que nos indica que hay que guardar constancia de todos los accesos a información personal de los clientes solo afectará a aquellos requisitos funcionales que incluyan acceso a este tipo de datos.
Los requisitos no funcionales locales se considerarán, generalmente, parte del requisito o requisitos funcionales a los cuales afectan. Así, cuando se haya implementado el requisito funcional correspondiente y se consuma, también daremos por consumida la restricción asociada. Los podemos considerar, por lo tanto, anotaciones adicionales a la historia de usuario o caso de uso que documente el requisito funcional.
Los requisitos no funcionales globales, sin embargo, no se pueden considerar “implementados” y, por lo tanto, no se consumen. De hecho, cada vez que se finaliza una iteración, habrá que satisfacer estos requisitos, pero siguen estando presentes para la siguiente iteración.
Como están fuera de la lista de prioridades que vamos consumiendo al implementar el sistema, los requisitos no funcionales globales, a los que también podemos denominar restricciones del sistema, se documentan, habitualmente, en un apartado separado del backlog de producto.
3.3.2.El backlog y otros documentos de requisitos
El uso de un backlog no excluye al equipo de usar cualquier otro documento de requisitos complementario que considere necesario. Así, además del backlog, un equipo puede usar un modelo del dominio en forma de diagrama de clases UML, esbozos de las pantallas a mano alzada, mapas navegacionales para interacciones elaboradas entre el usuario y el sistema en forma de diagramas de estados UML, o cualquier otro artefacto que sea útil para comunicar requisitos.

4.Gestión de los cambios en los requisitos

A pesar de que la situación ideal para el desarrollo del software sería partir de un conjunto de requisitos estable y definitivo, la realidad es que esto sucede en muy pocas ocasiones. Los motivos por los cuales cambian los requisitos son muy diversos y hay que tenerlos en cuenta durante el desarrollo.

4.1.Factores de cambios en los requisitos

Dean Leffingwell y Don Widrig nos proporcionan una lista bastante extensa de factores de cambio en los requisitos, y distinguen entre factores externos e internos al propio proceso de desarrollo.
Los factores externos son aquellos sobre los cuales el equipo de desarrollo no tiene ningún control. Por lo tanto, no hay nada que el equipo pueda hacer para evitarlos y se tiene que organizar y planificar teniéndolos en cuenta como una parte normal del proceso de desarrollo. Estos factores externos pueden ser:

  • Cambios en el problema que estamos solucionando debidos a modificaciones en la economía, regulaciones (aparición de nuevas leyes) o cambios en el mercado (cambios en las preferencias de los clientes o la aparición de un nuevo competidor).

  • Cambios en la opinión de los clientes respecto a lo que quieren, como por ejemplo, si cambiamos de interlocutor (debido a que nuestro interlocutor deja el trabajo o cambia de departamento) y el nuevo interlocutor tiene una idea diferente.

  • Cambios en el entorno, como la aparición de nuevas tecnologías que hacen que los requisitos sobre un sistema cambien (por ejemplo, al aparecer la red Internet, muchas empresas se encontraron con la necesidad de dar acceso remoto a sus aplicaciones, necesidad que antes no existía).

  • Cambios debido al hecho de que los usuarios, al usar el software, se han dado cuenta de que este no acaba de satisfacer del todo sus necesidades.

Estos factores, a pesar de no poder evitarse, pueden gestionarse como parte del proceso de desarrollo de software, ya sea intentándolos congelar (como es el caso del método en cascada) u organizando el desarrollo de manera que el impacto de los cambios sea mínimo (como es el caso de los métodos ágiles).
Por otro lado, Leffingwell y Widrig también identifican factores internos de cambio, como por ejemplo, no haber efectuado correctamente el proceso de ingeniería de requisitos (no haber hecho correctamente la obtención de requisitos o haber priorizado los requisitos equivocados) o no haber gestionado correctamente los cambios que se han ido detectando (por ejemplo, intentando congelar los requisitos hasta que los cambios acumulados son demasiado importantes como para ignorarlos).

4.2.Los cambios en el backlog

En el apartado anterior hemos dicho que una de las propiedades deseables de un backlog es que este tiene que ser emergente; es decir, que ante los cambios tenemos que poder añadir, modificar o eliminar entradas en los requisitos. Esto es debido a que, como acabamos de ver, no podemos evitar completamente la aparición de cambios en el software.
Cuando los requisitos cambien, habrá que añadir, modificar o eliminar entradas del backlog para reflejar estos cambios. Así, cuando se descubran nuevos requisitos habrá que añadirlos como entradas en el backlog (estimándolos y priorizándolos). Si un requisito cambia, puede ser necesario reestimarlo o repriorizarlo. Finalmente, podemos descubrir que un antiguo requisito deja de serlo y habrá que eliminar la entrada de backlog pertinente.
Por todos estos motivos es importante dedicar cierto tiempo en cada iteración a revisar y mantener el backlog, añadiendo, quitando o modificando las entradas que haga falta a medida que los diferentes factores de cambio (sean internos o externos) provoquen cambios en los requisitos o en la estimación de su coste o valor.
Además, el backlog tiene que reflejar el trabajo hecho hasta ahora en el desarrollo. Si una entrada de backlog ha sido ya desarrollada y verificada, se eliminará del backlog e, inmediatamente, la siguiente entrada más prioritaria pasará a ocupar su lugar. Así, a medida que completamos entradas, las que eran menos prioritarias van ganando prioridad relativa, en el sentido de que van avanzando hacia arriba en la lista y pasan a ocupar las primeras posiciones.
Por otro lado, también hemos dicho que el backlog tenía que estar detallado apropiadamente. La finalidad de esto es no dedicar esfuerzos a las entradas que tienen más probabilidades de sufrir cambios (las menos prioritarias, que son las que están más lejanas en el tiempo).
Así, las entradas más prioritarias tienen que ser requisitos con objetivos de más bajo nivel, de granularidad más fina. Estas son entradas que se tendrán en cuenta antes. A medida que tienen menos prioridad, las entradas tienen que tener niveles de objetivo más generales, tienen que tener una granularidad más gruesa.
Supongamos, por ejemplo, que tenemos en el backlog de Viajes UOC el requisito “Comprar un viaje por Internet”. Si este no fuera un requisito priotario, quedaría así, sin detallar, en el backlog hasta que fuera más prioritario y se descompusiera en requisitos de nivel de usuario, como por ejemplo “Ver información sobre un destino” o “Hacer el pago de un viaje”.
Se dice que el backlog tiene que tener forma de iceberg, donde la parte de arriba contiene las entradas sobre las que estamos trabajando actualmente, pequeñas, de granularidad muy fina, y la parte de abajo, a medida que nos alejamos de la punta, contiene entradas de granularidad cada vez más gruesa, con menos nivel de detalle y, por lo tanto, más grandes.
75593m3007.gif
El objetivo de esta manera de detallar el backlog es no destinar demasiado tiempo a detallar unas entradas de backlog que aún no se usarán porque no son suficientemente prioritarias. A medida que se van consumiendo entradas de backlog, se van descomponiendo, y detallando cada vez solo las entradas más prioritarias que quedan en el backlog.

5.Caso práctico

En este apartado se ponen en práctica algunas de las técnicas que hemos visto a lo largo del módulo. Para hacerlo, explicamos una historia ficticia sobre cómo se llevó a cabo, en la práctica, parte de la planificación del desarrollo de Viajes UOC. En esta historia intervienen los siguientes personajes:

  • Alberto y Cristina, dos desarrolladores.

  • Marta, especialista en experiencia de usuario.

  • Luisa, product manager.

5.1.Visión del producto

Cuando Luisa recibió de la dirección de Viajes UOC el encargo de convertirse en la product manager de la nueva plataforma de esta agencia, lo primero que hizo fue redactar la visión del producto:

“Para las agencias de viajes que quieren vender viajes por Internet, Viajes UOC 2.0 es un sistema de ventas que permite conseguir nuevos clientes a través de Internet sin renunciar a su negocio tradicional (clientes de la agencia). Al contrario que el sistema actual, nuestro producto permite un modelo mixto entre compra on-line y compra en la agencia.”

Es importante que tengamos presente esta visión a lo largo de todo el proceso que seguiremos a continuación.

5.2.Obtención de requisitos candidatos

Una de las áreas funcionales que se tuvo en cuenta es la de la presentación de información sobre los destinos. En concreto, se hizo una sesión de brainstorming y surgieron las siguientes historias de usuario candidatas:
Descripción textual
Como cliente, quiero ver la información que hay sobre un destino.
Como agente de viajes, quiero añadir una opinión sobre un destino.
Como cliente, quiero hacer una pregunta sobre un destino.
Como cliente, quiero recibir una alerta cada vez que se publique nueva información sobre un destino.
Como cliente, quiero solicitar un chat en directo con un agente de viajes.
Como comercial, quiero hacer una oferta de viaje a un destino concreto.
Como usuario, quiero recibir una alerta cuando haya una oferta de viaje a un destino concreto.
Como propietario de agencia, quiero poder hacer ofertas a usuarios concretos.
Como cliente, quiero solicitar un chat en directo con otros usuarios interesados en este destino.
Como cliente, quiero comparar precios con otras agencias de viajes virtuales.

5.3.Estimación de los requisitos

Para estimar el tamaño de los requisitos, Alberto, Cristina, Marta y Luisa se reunieron para llevar a cabo una sesión de estimación colaborativa.
Como Alberto y Cristina son quienes están más familiarizados con la técnica del planning poker, Alberto es quien se encargó de explicar a Marta y a Luisa el funcionamiento del planning poker y de los puntos de historia.
“Como no podemos estimar el volumen absoluto de trabajo que nos supondrá este nuevo desarrollo, de momento nos conformaremos con estimar el coste relativo de las diferentes historias de usuario y, para eso, usaremos los puntos de historia. El único significado de los puntos de historia es que una historia de 2 puntos es el doble de complicada de implementar que una de 1 punto (y la mitad que una de 4 puntos)”.
5.3.1.Estimación de la primera historia
“Para la primera historia se nos presenta el problema de que no tenemos con qué compararla y, por lo tanto, es difícil hacer la estimación. De momento nos conformaremos con saber si es una de las grandes (complicadas) o de las pequeñas (sencillas), y estimaremos el resto de historias basándonos en esta”.
“Empezaremos, si os parece bien, por ‘Como cliente, quiero ver la información que hay sobre un destino’”. “¿Cuál es esta información?” preguntó Marta. “Es importante saber cuál es la información a mostrar si tengo que pensar en cómo quedaría en la pantalla”. Cristina añadió: “y para mí es muy importante saber cuál es esta información puesto que me servirá para saber a cuántas fuentes de datos tendré que acceder”.
Luisa respondió “La información sobre un destino es un conjunto de elementos multimedia (fotos, etc.), el nombre y ubicación del destino, las opiniones que haya al respecto, así como las preguntas y respuestas que se hayan hecho sobre el destino. Las opiniones incluyen el nombre de la persona que ha expresado la opinión así como una valoración cualitativa en forma de comentario”. Dicho esto, Alberto propuso al resto si querían hacer más preguntas, y como ya nadie tenía dudas procedieron a la primera ronda de estimación.
Para hacer la estimación, como solo Alberto, Cristina y Marta tendrán que llevar a cabo las diferentes tareas, solo ellos estimarán el volumen de trabajo que habrá que realizar. La primera ronda de estimaciones quedó de la siguiente manera:

Persona

Primera ronda

Alberto

5

Cristina

8

Marta

13
“¿Cómo puede ser esto?” preguntó Luisa. “Tranquila, es normal, puesto que se trata de la primera historia y la primera ronda, y es probable que no todos tengamos lo mismo en mente” respondió Alberto, “empezaré yo explicando por qué creo que es un 5: me da la impresión de que esta funcionalidad es de las más sencillas que tenemos para implementar, ya que solo se tienen que consultar datos y mostrarlos por pantalla y, por lo tanto, un número mayor hará que todo el resto de estimaciones quede demasiado grande. De todos modos, creo que Marta ha considerado algunos factores que yo he ignorado y por eso hay tanta diferencia. ¿Es posible?”.
Marta añadió: “Yo creo que es una de las funcionalidades más complicadas, al menos para mí, puesto que es la pantalla más importante de la aplicación y habrá que hacer pruebas de usabilidad antes de decidir el diseño definitivo. Por lo tanto, no se trata sólo de programar las consultas, sino de hacer dos o tres propuestas alternativas de organización de la información, probarlas y entonces decidir con cuál nos quedamos”. Alberto respondió: “visto así, veo que había subestimado el trabajo. De todos modos, ¿este problema no lo tendremos con todas las funcionalidades?”. “No” respondió Marta, “sólo en esta, que es la más importante”. “Entendido, si Cristina no tiene ninguna pregunta más, podemos proceder a la segunda ronda”.

Persona

Primera ronda

Segunda ronda

Alberto

5

8

Cristina

8

8

Marta

13

13
“Yo continúo pensando que es una funcionalidad muy complicada y que traerá mucho trabajo y un 8 me parece muy poco” dijo Marta. “Pero ten en cuenta que esto es una estimación relativa” respondió Alberto, “un 8 puede ser mucho o poco, ya veremos, en función del resto, pero piensa que una funcionalidad que sea el doble que esta será un 26 y, por lo tanto, cuatro veces esta será ya prácticamente imposible de estimar. ¿Tan complicado es?”. “Sí. No habrá ninguna más que sea cuatro veces esta, pero sí que tendremos algunas que serán la cuarta parte”. “Entendido, volvemos a estimar”.

Persona

Primera ronda

Segunda ronda

Tercera ronda

Alberto

5

8

13

Cristina

8

8

13

Marta

13

13

13
“Muy bien, ya tenemos consenso. Tomaremos como referencia esta historia con 13 puntos”.
5.3.2.Estimación de las siguientes historias
Alberto explicó “La segunda historia es ‘Como agente de viajes, quiero añadir una opinión sobre un destino’. Luisa nos dará los detalles”. “En este caso, se trata de permitir que el agente de viajes pueda añadir una opinión sobre un destino. La opinión es un texto donde explica su punto de vista y si es positivo o negativo”. Marta preguntó: “si el agente ya ha opinado sobre el destino, ¿tiene que poder editar la opinión que ya había dado?” “Sí”, respondió Luisa. “¿Y puede llegar a tener dos? ¿O si vuelve a opinar tiene que modificar forzosamente la que ya tenía?” preguntó Alberto. “Buena pregunta” dijo Luisa “yo creo que es mejor que un agente sólo haya podido dar una opinión y si la quiere modificar, que desaparezca la anterior”. “Entendido” dijo Alberto, “procedemos, pues, a la estimación. Recordad que 13 puntos para la historia anterior es la referencia”.

Persona

Primera ronda

Alberto

5

Cristina

5

Marta

5
“Muy bien. Parece que esta vez hay consenso a la primera” dijo Alberto. “De ahora en adelante ya podemos triangular (comparad con esta que son 5 y con la anterior que son 13)”.

5.4.Priorización de los requisitos

Para la priorización de los requisitos se llevó a cabo otra reunión donde estaban presentes las siguientes personas:

  • Juan, un agente de viajes.

  • Sonia, directora de marketing.

  • Dolores, propietaria de una agencia.

  • Ramón, ingeniero de requisitos.

Ramón les dijo, “queremos hacer un desarrollo incremental. Por lo tanto, queremos empezar por las funcionalidades más importantes. Os propongo aplicar la técnica de los 100 dólares para que tengamos una idea de cuáles son estas funcionalidades más críticas. Por si no la conocéis, la técnica de los 100 dólares consiste en que cada uno de vosotros tiene 100 dólares de presupuesto que puede repartir como quiera entre las diferentes funcionalidades. Al final sumaremos el importe asignado a cada funcionalidad y las ordenaremos por puntos. Las funcionalidades a considerar son:
1: Como cliente, quiero ver la información que hay sobre un destino.
2: Como agente de viajes, quiero añadir una opinión sobre un destino.
3: Como cliente, quiero hacer una pregunta sobre un destino.
4: Como cliente, quiero recibir una alerta cada vez que se publique nueva información sobre un destino.
5: Como cliente, quiero solicitar un chat en directo con un agente de viajes.
6: Como comercial, quiero hacer una oferta de viaje a un destino concreto.
7: Como usuario, quiero recibir una alerta cuando haya una oferta de viaje a un destino concreto.
8: Como propietario de agencia, quiero poder hacer ofertas a usuarios concretos.
9: Como cliente, quiero solicitar un chat en directo con otros usuarios interesados en este destino.
10: Como cliente, quiero comparar precios con otras agencias de viajes virtuales.
Avisadme cuando hayáis repartido los puntos.”

1

2

3

4

5

6

7

8

9

10

Juan

100

Sonia

10

10

10

10

20

10

10

10

10

Dolores

20

20

30

30

Total

30

110

30

10

20

40

10

40

10

En este caso, como Juan había puesto todos sus puntos en la misma funcionalidad, esta fue considerada la más prioritaria, mientras que Sonia, que aplicó la estrategia contraria (repartir al máximo su voto) se encontró con que su voto (por repartido) era prácticamente irrelevante.

5.5.Selección de requisitos

Como el requisito número 10 (“Como cliente, quiero comparar precios con otras agencias de viajes virtuales”) no lo votó nadie, se decidió descartarlo y no incorporarlo al backlog.
Finalmente, el backlog priorizado quedó así (tened en cuenta que en caso de empate se ha optado por ordenar sobre la base de otro criterio que ahora no viene al caso).

Cost

Como agente de viajes, quiero añadir una opinión sobre un destino.

5

Como comercial, quiero hacer una oferta de viaje a un destino concreto.

20

Como propietario de agencia, quiero poder hacer ofertas a usuarios concretos.

20

Como cliente, quiero hacer una pregunta sobre un destino.

3

Como cliente, quiero ver la información que hay sobre un destino.

13

Como cliente, quiero solicitar un chat en directo con un agente de viajes.

100

Como cliente, quiero recibir una alerta cada vez que se publique nueva información sobre un destino.

3

Como usuario, quiero recibir una alerta cuandohaya una oferta de viaje a un destino concreto.

3

Como cliente, quiero solicitar un chat en directo con otros usuarios interesados en este destino.

100

Resumen

Hemos visto que la gestión de requisitos es el proceso mediante el cual decidimos cuáles de los requisitos candidatos de nuestro software implementaremos. Para tomar esta decisión, necesitamos estimar, como mínimo, el coste y la prioridad.
La prioridad de un requisito vendrá determinada, principalmente, por el valor aportado por el mismo, pero también por el conocimiento aportado o el riesgo que podamos eliminar implementándolo.
También hemos visto que podemos simplificar el proceso de estimación del coste de un requisito si nos limitamos a estimar el “tamaño” (medida arbitraria de la complejidad relativa de este requisito comparado con el resto de estos) usando unidades ficticias, como por ejemplo, los puntos de usuario. Una escala como por ejemplo la serie de Fibonacci, además, nos permite ajustar la precisión del valor estimado a nuestra capacidad de predecir con exactitud este valor (ya que tiene menos precisión a medida que aquello que estamos estimando es más “grande”). También hemos visto que esta estimación se puede hacer de manera colaborativa con la técnica del planning poker.
Para estimar la duración de un proyecto podemos usar la velocidad, que es la medida de las unidades de estimación (puntos de historia) que completamos en un periodo concreto (una iteración). Una de las ventajas de la velocidad es que se puede medir empíricamente a partir del final de la primera iteración.
En cuanto al valor, hemos visto cómo la visión del producto nos ayuda a asegurarnos de que todos los actores implicados en un desarrollo están alineados en la misma dirección. También nos ayuda a determinar cuál es el conjunto mínimo de requisitos que tenemos que implementar (el producto mínimo entregable) para satisfacer la necesidad de nuestros clientes.
Para el resto de requisitos hemos visto técnicas, como las prioridades limitadas (MoSCoW), los 100 dólares, el modelo Kano o las pruebas A/B, que nos ayudan a encontrar cuáles son los requisitos más prioritarios dentro de una lista.
Finalmente, hemos hablado del backlog de producto (la lista priorizada de trabajo pendiente para finalizar el proyecto de desarrollo) y de cómo este tiene que evolucionar y cambiar frecuentemente a medida que evoluciona nuestro conocimiento de las necesidades de los stakeholders.

Actividades

1. Supongamos que estamos practicando la estimación de tamaño y que nos piden estimar el peso de los siguientes animales en “puntos de peso de animal”: un ciervo, una ardilla, un elefante, un ratón, un zorro, un jabalí y un topo. Calculad una estimación relativa de pesos.
a) Hacedla estimación sin mirar el peso real de ningún animal.
b) Hacedla estimación suponiendo que un jabalí pesa unos 90 kg.
2. Supongamos que estamos calculando una estimación colaborativa mediante la técnica del planning poker y nos encontramos con esta situación:
Juan: 5, Alberto: 5, María: 5, Pol: 5, Luisa: 20
a) ¿Cuál es el valor de la estimación que tenemos que tomar en este caso?
b) ¿Y si fuera Juan: 1, María: 5, Pol: 10?
3. En el módulo 1 describimos CrowdArt, una plataforma de crowdfunding de proyectos artísticos donde los artistas proponen proyectos y los usuarios (a los que denominamos mecenas) hacen aportaciones económicas a los mismos. Cada proyecto tiene un plazo determinado para conseguir la financiación mínima y, sil lega al plazo, se hace el cobro a los usuarios y se transfiere el importe al artista. Las aportaciones se hacen sobre la base de una serie de recompensas que ofrece el artista (por ejemplo, por 10 € figurará su nombre en el programa de la obra de teatro, por 20 € le regalamos una entrada y por 100 € se lo agradeceremos públicamente el día del estreno).
Nos han pedido que les ayudemos a priorizar los requisitos mediante el modelo Kano. Concretamente, los requisitos a considerar son:

  • Que el artista pueda añadir una foto a un proyecto.

  • Que el artista pueda añadir un vídeo a un proyecto.

  • Que el artista pueda añadir un audio a un proyecto.

  • Poder cancelar una aportación si todavía no se ha llegado a la fecha tope.

  • Añadir nuevas recompensas a un proyecto que ya ha empezado a pedir financiación.

  • Modificar las recompensas de un proyecto aunque algún mecenas ya se haya comprometido (por ejemplo, habíamos dicho que regalaríamos una entrada y una camiseta pero ahora nos lo hemos pensado mejor y sólo queremos regalar la entrada).

  • Poder reducir el límite de la financiación solicitada una vez iniciado el proceso si vemos que no podremos llegar a tiempo.

  • Transferir el dinero al artista aunque no se llegue al mínimo.

a) Diseñad un cuestionario para pasar a los usuarios potenciales (tanto artistas como mecenas), que nos ayude a clasificar los requisitos según el modelo Kano (básico, lineal, apasionante, contrario, cuestionable o indiferente).
b) Supongamos que hemos pasado el cuestionario de la solución al apartado a a 10 artistas y hemos obtenido el resultado que se muestra en la siguiente tabla, ¿cuáles son los requisitos que tenemos que priorizar? ¿Hay alguno que tengamos que descartar? ¿Por qué?

A1

A2

A3

A4

A5

A6

A7

A8

A9

A10

P1

A

A

E

E

E

E

E

E

E

E

P2

N

N

N

N

N

N

I

N

P

P

P3

I

A

A

A

E

A

E

A

E

A

P4

E

N

E

E

I

N

I

I

N

P

P5

E

P

I

E

A

N

E

I

E

I

P6

P

E

E

I

E

E

P

I

I

I

P7

E

E

P

E

P

P

I

E

P

E

P8

A

A

E

A

E

A

I

A

A

E

P9

E

I

I

I

E

E

I

P

I

E

P10

N

E

N

E

N

N

P

I

N

P

P11

A

A

E

E

I

A

P

A

A

P

P12

I

E

A

A

A

E

A

P

P

A

P13

I

A

A

E

A

A

I

A

I

E

P14

N

N

N

I

N

N

P

N

E

P

G=Me gusta, E=Era de esperar, I=Indiferente, P=Puedo vivir con esto, N=No me gusta

Ejercicios de autoevaluación

1. ¿Cuáles son los cuatro factores básicos de la gestión de requisitos?

2. ¿Cuál es la principal ventaja de estimar el tamaño de los requisitos respecto a estimar la duración?

3. ¿Qué es la velocidad de un equipo de desarrollo? ¿Para qué sirve?

4. ¿Por qué motivo se usa la serie de Fibonacci para estimar el tamaño de los requisitos?

5. ¿Qué hay que hacer en una sesión de planning poker si no hay consenso entre las diferentes estimaciones?

6. ¿Cuál es la finalidad de la visión del producto?

7. ¿Cuál es la principal ventaja de la técnica user story mapping?

8. ¿Qué son las características básicas según el modelo Kano?

9. ¿Qué dice el modelo Kano respecto a la evolución de la percepción de las características de un producto a lo largo del tiempo?

10. ¿Qué es el backlog de producto?

11. ¿A qué nos referimos cuando decimos que el backlog de un producto es emergente?

12. ¿Qué queremos decir cuando decimos que el backlog tiene que estar detallado apropiadamente?

Solucionario

Actividades
1. Esta es solo una de las posibles soluciones al ejercicio. Lo que es importante no es tanto el resultado final como el proceso mediante el cual se ha llegado al mismo. También es interesante reflexionar sobre la precisión de las estimaciones y sobre la relación entre margen de error y magnitud estimada.
a) El primer paso es elegir un animal como punto de referencia. Un animal de peso intermedio es el zorro, al cual le podemos asignar 10 puntos. A partir de aquí, estimamos el resto de animales:

Animal

Puntos

Ciervo

100

Ardilla

1

Elefante

1.000

Ratón

0

Zorro

10

Cerdo jabalí

100

Topo

5
Podemos observar los siguientes hechos interesantes: debido a la enorme diferencia de peso entre los diferentes animales de la lista no hemos podido aplicar la serie de Fibonacci y hemos tenido que estimar en órdenes de magnitud. De aquí podemos extraer una primera conclusión: “Es muy difícil estimar en una misma escala elementos de medida muy diferente”.
b) En este apartado, podríamos volver a revisar nuestras estimaciones o bien partir de las estimaciones anteriores y calcular el peso del resto de animales a partir del dato del jabalí:

Animal

Estimación (puntos)

Peso estimado

Peso real

Ciervo

100

90 kg

70-150 kg

Ardilla

1

0,9 kg

0,2-0,3 kg

Elefante

1.000

900 kg

5.000-6.000 kg

Ratón

0

0 kg

0,01-0,03 kg

Zorro

10

9 kg

4,5-8,5 kg

Cerdo jabalí

100

90 kg

60-120 kg

Topo

5

4,5 kg

0,2 kg
Podemos observar los siguientes hechos interesantes:

  • La estimación del ciervo era bastante acertada, probablemente debido a que tiene un peso bastante similar al del jabalí.

  • El peso de la ardilla, sin embargo, está bastante sobrestimado, debido, en parte, a la escala utilizada. Como no hemos querido usar decimales, teníamos que elegir entre 0 gr y 1kg, demasiada diferencia si tenemos en cuenta la escala de peso en la que nos movemos. Por lo tanto, tendríamos que introducir los decimales en la escala o bien usar una unidad más pequeña.

  • El peso del elefante, en cambio, está subestimado por un motivo similar, a pesar de que, en este caso, es posible que el error de estimación sea debido, en parte, a la carencia de referencias intermedias con las que comparar (el animal que más se acerca al peso real del elefante es unas 50 veces menos pesado).

  • El zorro y el ratón están bastante aproximados pero el topo no (ni mucho menos). En este caso, es evidente que la persona que hizo la estimación creía que un topo es un animal bastante más grande delo que realmente es. En este caso, una estimación colaborativa nos hubiera ayudado a detectar este déficit de información.

2. En los dos casos, hay que volver a discutir la funcionalidad hasta llegar a un consenso. No es válido ni descartar una de las estimaciones por ser diferente del resto ni hacer una media de las estimaciones, puesto que el hecho de que no haya consenso quiere decir que es probable que no todo el mundo esté trabajando con la misma información.
3.
a) El cuestionario tiene que tener, para cada requisito, dos preguntas: Una en forma “funcional” (qué pasa si se dispone de esta funcionalidad) y una “disfuncional” (qué pasa si no se dispone de esta funcionalidad). Para cada una de estas preguntas, tenemos que dar cinco respuestas posibles: “Me gusta”, “Era de esperar”, “Me es indiferente”, “Puedo convivir con esto” y “No me gusta”. Por lo tanto, un posible cuestionario sería:
1. “¿Qué te parecería que el artista pudiera añadir una foto a un proyecto?”
2. “¿Qué te parecería que no hubiera la posibilidad de que los artistas pudieran añadir fotos a los proyectos?”
3. “¿Qué te parecería que el artista pudiera añadir un vídeo a un proyecto?”
4. “¿Qué te parecería que no hubiera la posibilidad de que los artistas pudieran añadir vídeos a los proyectos?”
5. “¿Qué te parecería que el artista pudiera añadir un audio a un proyecto?”
6. “¿Qué te parecería que no hubiera la posibilidad de que los artistas pudieran añadir audios a los proyectos?”
7. “¿Qué te parecería que un mecenas pudiera cancelar una aportación a un proyecto si todavía no se ha llegado a la fecha tope?”
8. “¿Qué te parecería que un mecenas no pudiera cancelar una aportación a un proyecto a pesar de que todavía no se hubiera llegado a la fecha tope?”
9. “¿Qué te parecería que el artista pudiera añadir nuevas recompensas a un proyecto que ya ha empezado a solicitar financiación?”
10. “¿Qué te parecería que el artista no pudiera añadir nuevas recompensas a un proyecto una vez este ha empezado a solicitar financiación?”
11. “¿Qué te parecería que el artista pudiera modificar las recompensas de un proyecto aunque algún mecenas ya se haya comprometido a hacer una aportación a cambio de aquella recompensa?”
12. “¿Qué te parecería que el artista no pudiera modificar las recompensas de un proyecto si algún mecenas ya se ha comprometido a hacer una aportación a cambio de aquella recompensa?”
13. “¿Qué te parecería que el artista pudiera reducir el límite de la financiación solicitada antes de la fecha tope si ve que no llega?”
14. “¿Qué te parecería que el artista no pudiera reducir el límite de la financiación una vez se ha empezado a solicitar?”
b) El primer paso para aplicar el modelo Kano es ver cómo ha clasificado cada artista cada uno de los requisitos según la tabla de cruces del subapartado 3.2.3.

A1

A2

A3

A4

A5

A6

A7

A8

A9

A10

R1

L

L

B

B

B

B

I

B

I

I

R2

I

L

A

A

I

L

I

A

B

A

R3

I

I

I

I

A

C

I

I

I

I

R4

C

C

I

C

I

C

I

C

C

I

R5

B

I

B

I

B

B

I

I

B

I

R6

A

A

C

C

C

A

C

A

A

C

R7

L

L

L

I

L

L

I

L

I

I

L=Lineal, B=Básico, I=Indiferente, A=Apasionante

A partir de esta información, calculamos la frecuencia de cada clasificación:

Q

A

L

C

I

B

R1

0

0

2

0

3

5

R2

0

4

2

0

3

1

R3

0

1

0

1

8

0

R4

0

0

0

6

4

0

R5

0

0

0

0

5

5

R6

0

5

0

5

0

0

R7

0

0

6

0

4

0
Según esta tabla, el primer requisito (“poder añadir una foto a un proyecto”) ha sido clasificado, mayoritariamente, como básico, mientras que el segundo (“poder añadir un vídeo”) lo ha sido como apasionante y el tercero (“poder añadir un audio”), como indiferente.
El cuarto (“poder cancelar una aportación”) ha sido clasificado como “contrario” (es decir, que resta valor). El quinto (“poder añadir recompensas una vez iniciado el proceso de financiación”) en cambio, presenta división de opiniones: tenemos el mismo número de artistas que lo consideran indiferente que de artistas que lo consideran básico.
El sexto requisito (“modificar las recompensas”) también presenta división de opiniones entre “apasionante” y “contrario”, lo cual demuestra que tenemos un problema importante de división y que, por lo tanto, lo deberíamos clasificar como “cuestionable”.
Finalmente, el séptimo (“poder reducir el límite de financiación”) lo consideraremos lineal.
Por lo tanto, la prioridad relativa es:
“Poder añadir una foto”, puesto que es básico y sin esta posibilidad el producto está incompleto.
“Poder añadir un vídeo”, puesto que, como requisito apasionante, nos permitirá diferenciar nuestro producto. En cuanto a prioridad, este requisito competiría con el de “poder añadir recompensas una vez iniciado el proceso de financiación”, puesto que si lo consideramos básico será más prioritario, pero si lo consideramos indiferente lo será menos.
“Poder reducir el límite de financiación” vendría a continuación como requisito lineal que es.
“Poder añadir un audio” es indiferente y, por lo tanto, ya veremos si se implementa o no.
“Poder cancelar una aportación” es un requisito que tenemos que descartar, puesto que se ha clasificado como contrario.
Finalmente, no hemos podido decidir qué hacer con el requisito “poder modificar las recompensas una vez iniciado el proceso de financiación”, puesto que tenemos tanto opiniones a favor como en contra. Lo mejor será, pues, preguntar a más artistas o, mejor todavía, preguntar a los mecenas qué piensan.
Ejercicios de autoevaluación
1. Los cuatro factores básicos de la gestión de requisitos son: valor, coste, conocimiento y riesgo. Ver el subapartado 1.1.
2. La principal ventaja es que la persona o personas que hacen la estimación solo tienen que fijarse en un concepto: el tamaño, y no tienen que tener en cuenta factores como el estado anímico del equipo, riesgos que se pueden materializar, etc. Ver el subapartado 2.1.
3. La velocidad es una medida del progreso de un equipo por unidad de tiempo y sirve para estimar la duración de un proyecto a partir del tamaño de sus requisitos. Ver el subapartado 2.1.
4. A medida que los requisitos tienen granularidad más gruesa, serán más grandes y difíciles de estimar por comparación y, por lo tanto, la precisión será menor. La serie de Fibonacci nos ayuda a reflejar este hecho. Ver el subapartado 2.2.
5. En el caso de no coincidir, los participantes vuelven a hablar para entender el motivo de la diferencia de criterio. Ver el subapartado 2.3.2.
6. La visión del producto describe por qué se está llevando a cabo el desarrollo y cuál es el estado final deseado. Ver el subapartado 3.1.1.
7. La principal ventaja de esta técnica es que permite maximizar el valor obtenido por el desarrollo, puesto que, al hacer el recorrido de la tabla en anchura, evitamos situaciones en las que tenemos una funcionalidad muy desarrollada pero otra igual de importante sin empezar. Ver el subapartado 3.1.3.
8. Las características básicas son aquellas que el cliente espera del producto (...). Si carece de alguna de estas, el cliente considerará el producto incompleto. Su presencia, en cambio, no aumenta significativamente la satisfacción del cliente. Ver el subapartado 3.2.3.
9. A lo largo del tiempo, las características apasionantes se convierten en lineales y las lineales, en básicas, por lo cual hay que revisar la clasificación de las diferentes características con el paso del tiempo. Ver el subapartado 3.2.3.
10. El backlog es una lista priorizada de trabajo pendiente para finalizar el proyecto de desarrollo. Ver el subapartado 3.3.
11. Un backlog es emergente porque puede evolucionar a medida que cambia el conocimiento que tenemos sobre las necesidades de los stakeholders y las tareas a hacer en cada momento. Ver el subapartado 3.3.
12. Un backlog está detallado apropiadamente cuando usa niveles de detalle diferentes para las entradas que contiene (y el nivel de detalle es el adecuado para cada entrada). Ver el subapartado 3.3.

Glosario

A/B testing m
Técnica empírica de priorización de requisitos que consiste en implementar dos requisitos alternativos (A y B), establecer una métrica que determine cuál de los dos tiene más éxito y exponer a un subconjunto de los usuarios al requisito A y otro subconjunto al B.
backlog m
Lista priorizada de trabajo pendiente para finalizar el proyecto de desarrollo.
comparación f
Técnica de estimación consistente en buscar otro requisito ya estimado y establecer el coste del requisito a estimar en función de coste del requisito estimado.
estimación (de requisitos) f
Consiste en etiquetar los requisitos con un valor que dé una idea de cómo afecta al coste total del proyecto la inclusión de aquel requisito.
gestión de requisitos f
Proceso mediante el cual decidimos cuáles de los requisitos candidatos formarán parte del conjunto definitivo de requisitos.
Kano (modelo) m
Teoría de desarrollo de productos orientada a la satisfacción del cliente, que tiene como finalidad poder predecir el nivel de satisfacción del cliente en función de cuáles sean las características presentes en el producto.
planning poker m
Técnica de estimación colaborativa donde cada persona hace su estimación sin saber cuál será la estimación de los demás.
priorización de requisitos f
Proceso mediante el cual establecemos la prioridad relativa de los requisitos del software.
producto mínimo entregable m
Producto con la funcionalidad mínima, que cumple las necesidades de unos clientes concretos.
puntos de historia m pl
Unidad ficticia de estimación de tamaño de requisitos.
requisito candidato m
Requisito que todavía no hemos decidido si tendremos o no en consideración a la hora de desarrollar el software.
tamaño (de un requisito) f
Dimensión de estimación relativa que no tiene en cuenta la duración, sino la complejidad y los riesgos que comporta implementar un requisito.
triangulación f
Técnica de estimación consistente en buscar un requisito de coste superior y uno de coste inferior al requisito en cuestión y establecer el coste definitivo del requisito en función de estos dos costes estimados.
velocidad (de un equipo de desarrollo) f
Magnitud que mide el progreso de un equipo por unidad de tiempo (típicamente en puntos de historia por iteración).
visión (del producto) f
Punto de vista que describe por qué se está llevando a cabo el desarrollo y cuál es el estado final deseado.

Bibliografía

Bibliografía principal
Cohn, Mike (2006). Agile estimating and planning. Prentice Hall Professional Technical Reference.
En esta obra Mike Cohn ofrece un conjunto de herramientas ágiles y prácticas para la estimación, priorización y planificación en entornos ágiles. A pesar de que está bastante centradaen las historias de usuario, las herramientas que da son totalmente aplicables a cualquier forma de documentación de requisitos.
Bibliografía complementaria
Leffingwell, D. (2010). Agile Software Requirements. Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.
La obra de Leffingwell presenta un enfoque ágil a la ingeniería de los requisitos. En el apartado de priorización de requisitos documenta el modelo Kano.
Cohn, Mike (2006). I Didn’t Know I Needed That! Finding Features to Satisfy Your Customers. Better Software – StickyMinds.com.
Mike Cohn explica en este artículo el modelo Kano de forma sencilla y con ejemplos prácticos.
Pichler, Roman (2010). Agile Product Management with Scrum. Creating Products that Customers Love. Addison-Wesley.
Ken Shcwaber (2009). Agile Project Management with Scrum. O’Reilly Media, Inc.
Cockburn, Alistair (2005). Crystal clear: A Human-Powered Methodology for Small Teams. Addison-Wesley.
Referencias bibliográficas
Chopra, Paras. The Ultimate Guide to A/B Testing. https://www.smashingmagazine.com/2010/06/24/the-ultimate-guide-to-a-b-testing/ (última visita: febrero del 2012).
Highsmith, Jim (23, agosto, 2001). “Design The Box”, “Agile Project Management E-mail Advisor”. Se encuentra a través del post “Product Vision”, del blog de Joel Spolsky.
Cockburn, Alistair (2008). Walkingskeleton. https://alistair.cockburn.us/Walking+skeleton (última visita: febrero del 2012).