Table of Contents
El proyecto de desarrollo de software al igual que cualquier otro proyecto tiene múltiples técnicas de priorización de requerimientos, restricciones presupuestarias y plazos ajustados. Por lo tanto, existe la necesidad de priorizar los requisitos de software ya que es imposible hacer todo a la vez. Por lo tanto, se deben tomar decisiones sobre qué conjunto de requisitos se deben implementar primero y cuáles se pueden retrasar hasta una versión posterior.
Normalmente, los PO de proyectos ágiles desean desarrollar software que sea de alta calidad y de gran valor, y la forma más sencilla de desarrollar software de alto valor es implementar primero los requisitos de mayor prioridad. Esto les permite maximizar el ROI de las partes interesadas.
Como normalmente los requisitos cambian con frecuencia, se necesita un enfoque simplificado y flexible para la gestión de cambio de requisitos, por ejemplo, product backlog (Scrum). Por lo tanto, en el desarrollo ágil, la priorización de requerimientos de software se considera una parte vital del proyecto. Y, por ejemplo, para priorizar las historias de usuario, podríamos usar los 5 criterios principales de priorización de requerimientos, como el valor que los usuarios le dan a la visión del producto, la urgencia, las limitaciones de tiempo, la técnica de complejidad y las preferencias de las partes interesadas.
Además, muy a menudo los proyectos deben ser priorizados adecuadamente tanto para los objetivos principales del proyecto como para las tareas específicas que lograrán los objetivos. Por lo tanto, nos ocupamos de la priorización en dos niveles: nivel de producto y nivel de tarea. Especialmente teniendo en cuenta que los clientes normalmente tienden a no entender que no pueden obtener todas las características que desean en la versión 1.0 de un nuevo producto de software. Cada proyecto debe tener prioridades de las características solicitadas, casos de uso y requisitos funcionales. La priorización de requerimientos de software ayuda al gerente de proyectos a resolver conflictos, planificar entregas escalonadas y tomar las decisiones de compensación necesarias.
Una de las mayores diferencias entre las empresas que prosperan y las que fracasan es la capacidad de priorizar de manera efectiva, pero la priorización de los requisitos de software nunca es fácil. A menudo implica decisiones dolorosas y pocas compensaciones, y para las empresas en etapa inicial y de expansión, existe la presión adicional de tratar de lograr mucho con tiempo y recursos limitados. Para lograr crecimiento, un equipo debe estar dirigido únicamente a las cosas que realmente importan y que van a tener un impacto máximo.
La priorización de requisitos de software es uno de los mayores desafíos que enfrenta un equipo de software. De hecho, el 25% de los líderes tecnológicos dijo que priorización de requerimientos de software es su mayor desafío.
Pero de acuerdo con las investigaciones de Jeanne Ross y Peter Weill en su libro IT Governance, «Las empresas que gestionan sus inversiones en IT con mayor éxito generan retornos que son hasta un 40% más altos que los de sus competidores».
En general, las empresas deben asegurarse de que cada miembro del equipo no solo esté trabajando en una lista de tareas. Deben tener una comprensión clara del impacto que tiene la tarea en la que están trabajando, al ver su contribución directa al proyecto. También necesitan tener claro el propósito del producto, no solo comprender la necesidad del cliente sino también el valor y los objetivos del negocio.
Puede haber ciertas cosas como la arquitectura de back-end que no es visible para los clientes, sino para los desarrolladores que pueden señalar cualquier problema arquitectónico que podría afectar el rendimiento del producto en el futuro. Por eso es tan importante asegurarse de que todos los ingenieros del equipo entiendan el producto hacia atrás y hacia adelante.
La priorización de los requisitos del software no tiene por qué ser una fuente constante de dolor. Con el método correcto, puede potenciar la toma de decisiones y llevar a resultados enormemente mejorados. Se han desarrollado numerosos métodos y tecnologías sobre cómo priorizar los requisitos, ya que es un gran problema para muchos equipos y empresas. Veamos los más populares y eficientes:
Las técnicas más populares de priorización de requerimientos de software
Analiza las áreas clave que se tienen en cuenta antes de tomar una decisión importante
Beneficio: una ventaja que obtiene la empresa como resultado de la implementación requerida.
Penalización: una consecuencia de no implementar un requisito.
Costes – esfuerzo y recursos que se requieren para implementar un requisito.
Riesgo: una probabilidad de que el requisito no entregue el valor esperado.
Dependencias: una relación entre los requisitos, por ejemplo, cuando el requisito requiera completar otro requisito para su implementación.
Sensibilidad de tiempo: fecha de caducidad, urgencia.
Estabilidad: la probabilidad de que el requisito permanezca estático.
Cumplimiento de políticas: requisitos que deben implementarse para cumplir con los requisitos reglamentarios.
Mapa de dependencia
Siempre es una buena idea crear un mapa de dependencia para comprender mejor las dependencias entre los requisitos. Especialmente teniendo en cuenta que la mayoría de los requisitos son interdependientes y difícilmente encontrarás un requisito que sea independientemente.
¿Cómo puedes hacerlo? Déjame darte un ejemplo: tienes 8 requisitos X, Y, Z, P, Q, R, M, O y N con prioridades, en una escala de 5 niveles donde 1 es más crítico y 5 menos crítico, como 1, 2,1,4,5,1,2,2,3. Entonces, con estas prioridades, sería lógico, comenzar con los requisitos X, Z y R.
Ahora, pasemos al ejemplo de la parte de dependencia: necesitamos completar X antes de comenzar con Y, aunque X e Y tienen los mismos niveles de prioridad. De manera similar, necesitamos completar O antes de comenzar a R, aunque R tiene mayor prioridad que O. Entender los requisitos de dependencia es tan importante como la priorización. Sin entender la dependencia de los requisitos, es muy poco probable que llegue al orden correcto de la implementación de los requisitos. Por lo tanto, es una buena idea tener el mapa de dependencia de requisitos en tu lugar antes de priorizar los requisitos, especialmente cuando se trabaja en proyectos de software.
MoSCoW
El método MoSCoW funciona mejor que el sistema de calificación numérica, ya que es mucho más fácil para las partes interesadas calificar los requisitos como Must, Should, Could or Would
El acrónimo representa lo siguiente:
Must – obligatorio
Should – de alta prioridad
Could – Preferido pero no necesario
Would – puede ser pospuesto y sugerido para futura ejecución
Votación
Esta es la forma más simple de priorización de requerimientos de software. Cuando hay demasiados requisitos que deben categorizarse en diferentes categorías con aportes de diferentes partes interesadas, la votación es una de las mejores formas de resolver la priorización de requerimientos de software. Digamos que si se están debatiendo 10 características, las partes interesadas tienen 10 puntos y deben difundirlas a través de estas características. Por ejemplo, menos importante 1, más importante 10.
Técnica de clasificación de burbujas
Muy similar a votar, pero para algunas personas, esta técnica les ayuda a obtener la prioridad correcta más rápido. Para priorizar los requisitos utilizando la técnica de clasificación de burbujas, debe cumplir dos requisitos y compararlos entre sí. Si descubre que un requisito tiene mayor prioridad que el otro, puede cambiarlos según corresponda. Luego continúa de esta manera hasta que el último requisito esté correctamente ordenado. El resultado es una lista de requisitos que están clasificados.
Método – cien dólares
Este método simple es útil en cualquier lugar donde múltiples interesados necesitan votar democráticamente sobre qué requisitos son los más importantes. Todas las partes interesadas obtienen 100 dólares conceptuales, que pueden distribuir entre los requisitos. Como tal, el interesado puede optar por dar los 100 dólares a un único requisito, o la persona puede distribuir los puntos de manera más pareja. Cuanto mayor sea la cantidad asignada a cada requisito, mayor será la prioridad del requisito. Al final, se cuenta el total y los requisitos se ordenan según el número de puntos recibidos.
Cinco “porqués”
A menudo sucede que los interesados quieren implementar una determinada característica por razones que no se basan en argumentos lógicos o en los intereses comerciales de la empresa. Con cinco porqués, el analista pregunta repetidamente al participante (cinco veces o menos) por qué el requerimiento es necesario hasta que se establece la importancia de los requisitos. Las respuestas revelan si el requisito es realmente necesario o si se puede cancelar / posponer una vez que se determina la prioridad.
Entonces, ¿qué técnica de priorización de requerimientos de software es la mejor? No hay una respuesta correcta, puedes combinarlas o usar uno para 1 proyecto y otro para el segundo proyecto. Lo más importante es que analices los puntos clave que impactan en el negocio.
Ejemplo de priorización de requerimientos de software
Fijémonos en el ejemplo de cómo puede ser el proceso de priorización de requerimientos de software:
1. En primer lugar, lo que hace es crear una lista de todos los requisitos, características o casos de uso que quieres priorizar en una hoja de cálculo. Si ciertas funciones están vinculadas lógicamente, incluye solo la función de conducción en el análisis.
2. El segundo paso es estimar el beneficio relativo que cada característica proporciona al cliente, el negocio en una escala de 1 a 9, donde 1 indica muy poco beneficio y 9 es el máximo beneficio posible.
3. El tercer paso es estimar la penalidad relativa que el cliente o empresa sufriría si la característica no está incluida. Nuevamente, usa una escala de 1 a 9, donde 1 significa esencialmente no penalizar y 9 indica una desventaja muy seria.
4. Luego va el valor total: es la suma del beneficio relativo y la penalidad. Por defecto, el beneficio y la penalidad se ponderan por igual.
5. ¿Qué sigue? Estimación del costo relativo de implementar cada característica, nuevamente en una escala que varía desde un mínimo de 1 a un máximo de 9.
6. Los desarrolladores estiman el grado relativo de riesgo técnico u otro asociado con cada característica en una escala de 1 a 9.
7. Una vez que ingresas las estimaciones en la hoja de cálculo, calcula un número de prioridad para cada característica y das los resultados teniendo en cuenta todas las entradas.
8. Ordena la lista de características en orden descendente por prioridad calculada. Las características en la parte superior de la lista tienen el saldo más favorable de valor, coste y riesgo, y por lo tanto deberían tener una mayor prioridad de implementación.
Espero que este artículo te haya resultado útil si conoces otras técnicas de priorización de requerimientos de software, por favor compártelas en la sección de comentarios a continuación.
Y si estás interesado en otros consejos de desarrollo de software, te recomiendo que te suscribas a nuestro boletín mensual aquí.
Si este artículo sobre HTTPS para Dummies te gustó, te puede interesar:
Simular respuestas del servidor con Nodejs
Principio de responsabilidad única
Arquitectura de microservicios
F-bound en Scala: traits genéricos con higher-kinded types
Scala Generics I : Clases genéricas y Type bounds
