Si no puedes medirlo, no puedes mejorarlo

8 12 2008

Llevo bastante tiempo preguntándome cómo medir un requisito, sin encontrar respuestas que me satisfagan plenamente. Después de estos meses, creo que la pregunta de partida estaba mal formulada; antes de determinar qué atributos son medibles en un requisito es necesario determinar cuál es el objetivo de esta medición.

A diferencia de otras parcelas del desarrollo software donde la medición es tangible y persigue unos objetivos claros en cuanto a métricas de calidad, mantenibilidad y sostenibilidad del código, complejidad, cobertura de los test, etc., la medición de requisitos debe centrarse en otro tipo de atributos, tales como personas involucradas en el proceso, seguimiento y mantenimiento de requisitos, prioridad, estado, etc.

La adquisición de los atributos con los que obtener estas mediciones está repartida durante el ciclo de vida de un proyecto software, por lo que ser ordenado y metódico es fundamental. Algunas mediciones podrán ser obtenidas durante el Proceso de Toma de Requisitos, otras durante el Proceso de Definición de Requisitos, y otras en el Análisis, Verificación y Validación de Requisitos.

Métricas del Proceso de Toma de Requisitos
Para hacer estas mediciones es imprescindible disponer de mecanismos que en cualquier momento permitan responder a las siguientes preguntas:

  • ¿Quién solicitó el Requisito y cuándo, y quién es el responsable del mismo? Cuantificar y localizar el trabajo involucrado en la definición y mantenimiento del Requisito para poder tomar decisiones cualitativas al respecto. Esta métrica permitirá sentar las bases del historial de modificaciones para cada requisito.
  • ¿Por qué lo solicitó? Cuantificar el grado de cobertura de los objetivos definidos (objetivos que son alcanzados). Esta métrica permite evaluar si se cumplen los objetivos (a nivel de Análisis), con el cumplimiento de los Requisitos que lo sustentan. Los Requisitos sirven para alcanzar, al menos, un objetivo. De lo contrario, el Requisito dejará de ser vital en el negocio y por tanto negociable.
  • ¿Qué prioridad tiene? Cuantificar el impacto o criticidad del requisito en el negocio del usuario originario de cada Requisito.

Métricas del Proceso de Definición de Requisitos
Estas mediciones se realizan sobre las especificaciones definidas para cada Requisito, y están íntimamente relacionadas con cuestiones de forma, recogidas en los 13 mandamientos del Proceso de Definición de Requisitos:

  • Condicionalidad: grado en el que intervienen tiempos condicionales.
  • Especificidad: grado en el que intervienen expresiones vagas en significado, como “generalmente …”, “comúnmente …”
  • Opcionalidad: grado en el que intervienen opciones en la descripción de un Requisito. La opcionalidad en un Requisito se modelará como atributos del Requisito o en nuevos Requisitos, pero nunca en el mismo Requisito.
  • Atomicidad: grado en el que se detalla en un Requisito cada necesidad, de forma individual. Inversamente proporcional a la Opcionalidad. Muchos verbos concentrados en un Requisito dificultan su comprensión y su posterior trazabilidad.
  • Legibilidad: grado en el que un Requisito es legible y comprensible. Evitar el exceso de información en cada Requisito; las informaciones se mezclan si se proporciona demasiado detalle (ese detalle se indicará en Casos de Uso, refinando los Requisitos). No recurrir a Acrónimos, salvo que se recojan en Glosarios u Ontologías de Términos. No usar pronombres.

Métricas del Proceso de Análisis de Requisitos

  • ¿Relación con otros Requisitos? Cuantificar el grado de cobertura de los Requisitos definidos (Requisitos que son alcanzados). Esta métrica permite evaluar si se cumplen los Requisitos (a nivel de Análisis), con el cumplimiento de otros Requisitos que los sustentan.
  • ¿En qué versión se encuentra el Requisito? Cuantificar la variabilidad en base al cambio y al impacto del mismo, es necesario disponer de mecanismos que permitan llevar a cabo control de versiones para los Requisitos. De esta forma se podrán seguir los cambios durante la vida de cada Requisito, acorde al avance de las etapas/iteraciones de análisis, diseño y desarrollo, así como el feedback que se genere con los usuarios originarios de cada Requisito.
  • Negociabilidad: grado en el que los Requisitos son negociables. Para mejorar el feedback con el cliente, se partirá de Requisitos que recojan una breve descripción de los mismos. La negociabilidad de estos Requisitos es alta. Los detalles se recogerán progresivamente, durante la fase de “conversación”, reduciéndose su negociabilidad. De este modo se evita partir de Requisitos con demasiados detalles, que limitan la conversación con el cliente. Con esta métrica se controla la aparición del fenómeno “Ignorancia”, descrito en posts anteriores.
  • Valor: cada Requisito tiene que generar valor para el cliente (ya sea el usuario final o “el que paga”). Una buena manera de conseguir Requisitos valiosos es hacer que sea el propio cliente quien los escriba; les será mucho más cómodo escribirlos una vez se den cuenta de que los Requisitos no son un contrato y son negociables. Con esta métrica se controla la aparición del fenómeno “Pollaque”, descrito en posts anteriores.
  • Estimable: los desarrolladores tienen que ser capaces de estimar (de forma aproximada) el esfuerzo necesario para construir cada Requisito, para permitir al equipo fijar prioridades e hitos. Los problemas más comunes que pueden encontrar los desarrolladores al estimar Requisitos son: falta de conocimiento de dominio (en cuyo caso hay una necesidad de una mayor negociación/conversación con el cliente), y Requisitos demasiado grandes (han de ser divididos en pequeñas historias).
  • Pequeño: un buen Requisito debe ser pequeño en esfuerzo; por lo general, nunca debe representar un esfuerzo de más de 2-3 semanas de trabajo una persona. De lo contrario, pueden haber errores asociados con el alcance y la estimación.
  • Testeable: cada Requisito tiene que ser comprobable, y cada aserción y verificable y medible de forma sencilla, para la “validación” final que tendrá lugar. Si no es posible probarlo/medirlo/verificarlo, nunca se sabrá cuando se ha terminado. Típicos ejemplos de Requisitos no testeables o difíciles de medir: “el software debe ser fácil de usar”, términos como “accesible”, “amigable”, “rápido” y “eficiente”.




Pollaques vs Ignorancia

6 12 2008

Recientemente, en una de las últimas entradas se lanzaba la pregunta siguiente: ¿Qué es peor? ¿Un pollaque o la ignorancia? Antes de exponer mis conclusiones (mías, propias), me gustaría presentar varias perspectivas sobre los pollaques y la ignorancia, todas ellas fruto de experiencias que he tenido recientemente, analizadas con cierto grado de pesimismo (pero reales en definitiva).

Perspectivas de un “pollaque”

El pollaque visto desde la perspectiva del cliente no suele ser concebido como tal. El cliente no entenderá que existan necesidades o expectativas que no sean críticas en el negocio y que de ser incluidas en la especificación harán peligrar las planificaciones inicialmente definidas, y esto provocará, en el mejor de los casos, malestar:

  • El cliente considerará que todo es crítico en el negocio, y por tanto todo ha de ser incluido en la especificación de los sistemas a construir.
  • Es cierto que existen clientes con los que es posible razonar; tras justificar por qué ciertas consideraciones no son vitales para el negocio y por qué la inclusión de dichas consideraciones (no planificadas inicialmente) hacen peligrar el cumplimiento de planificaciones temporales y económicas, se retractan del pollaque. No obstante, en mi experiencia (no demasiado dilatada, todo hay que decirlo), esto no es lo común.
  • Este riesgo que genera una vulnerabilidad se puede convertir en oportunidad. La clave, la negociación. Si tras justificar la no viabilidad temporal y económica del pollaque éste finalmente ha de ser incluido en las especificaciones, la negociación es la única salida. ¿Y qué negociar? la planificación temporal y económica; cuando éstas sean intocables, el alcance del proyecto (si meto por aquí, habrá que quitar por otro lado).

El pollaque visto desde la perspectiva del equipo de desarrollo. Si se supo justificar al cliente la no viabilidad del pollaque y éste lo acepta, el pollaque se disolverá o dejará de ser pollaque para convertirse en nuevos requisitos (tras haber revisado la planificación temporal, económica, o el alcance del proyecto). Por este motivo el equipo de desarrollo no debería percibir pollaques. Sin embargo, si llegan a observarlos:

  • Será síntoma de que se incluyó en las especificaciones sin revisión de tiempos, costes ni alcances, lo cual se traduce en sobre-esfuerzo, y éste a su vez en malestar el equipo de desarrollo.
  • Haciendo malabarismos con los recursos, podría ser posible asumir estos sobre-esfuerzos sin sobrecargar al equipo de desarrollo, pero siempre a costa de resentir otros proyectos, trasladando ese malestar desde el equipo hacia los clientes de esos otros proyectos.

El pollaque visto desde la perspectiva de la Jefatura de Proyecto. Al igual que en el caso anterior, el pollaque habría podido desaparecer o convertirse en nuevos requisitos (tras haber revisado la planificación temporal, económica, o el alcance del proyecto). Por este motivo la Jefatura de Proyecto tampoco debería percibir pollaques. Sin embargo, si llegan a observarlos, ésta cuestionará el trabajo del Analista Funcional por:

  • Malestar del cliente.
  • Malestar del equipo de desarrollo.
  • Asumir riesgos (no sé hasta qué punto innecesarios) que podrán poner en peligro la ejecución del proyecto en cuanto a planificación temporal y económica. 

Perspectivas de la ignorancia

La ignorancia vista desde la perspectiva del cliente no suele ser concebida como tal. El cliente no entenderá que existieran cosas que no sabías que no sabías y esto provocará, en el mejor de los casos, malestar:

  • El cliente considerará que se transmitieron todas sus necesidades y expectativas, y que se hizo en un lenguaje claro, directo y sin ningún tipo de vacíos.
  • Los procesos de toma y verificación de requisitos suelen ser costosos y el cliente no suele recibir con entusiasmo estos costes (aunque estén planificados), menos aún si se trata de abordar las consecuencias de esa ignorancia (que no suelen estar planificadas). Por otra parte, los usuarios expertos tampoco los encajan bien porque iterar sobre la visión adquirida del negocio para refinarla, resolver ambigüedades, … supone esfuerzo que se traduce en tiempo, tiempo que a veces se concibe como perdido y no como invertido.
  • Si la ignorancia se manifiesta sobre el sistema en producción, entonces las consecuencias pueden ser desastrosas ya que la solución podría no aportar valor al cliente. En este caso el malestar puede elevarse a la enésima potencia: no fidelización con el cliente, rescisiones de contratos, etc.

La ignorancia vista desde la perspectiva del equipo de desarrollo hace que éste se cuestione cualquier omisión sobre los requisitos: ¿no está porque no tiene que estar o porque no lo hablaste con los usuarios expertos? El equipo, una vez se sumerge en el negocio, detecta restricciones, reglas de negocio, etc. que pueden parecer lógicas y aplicables. Algunas serán fruto de esa hiperactividad mental que nos caracteriza y se desechan. Otras, serán el fruto de lo que no sabías que no sabías y se formularán a los usuarios expertos para generar nuevos requisitos.

  • Éstas fomentarán las consecuencias anteriores sobre la ignorancia vista desde la perspectiva del cliente.
  • Además, podrán hacer crecer cierta desconfianza por parte del equipo sobre lo especificado, y esto aumenta esa hiperactividad mental, que a su vez hace que aumenten las preguntas ¿no está porque no tiene que estar o porque no lo hablaste con los usuarios expertos?, y así sucesivamente.
  • En cada iteración completa de este bucle el malestar del cliente y la desconfianza del equipo tenderán a crecer.
  • Si la ignorancia se manifiesta sobre el sistema en producción, será necesario dedicar esfuerzo adicional (normalmente no presupuestado, ¡ni remunerado!) para poder remendar los efectos de la ignorancia (a costa de robar dedicación a otros proyectos y de sobrecarga en el equipo).

La ignorancia vista desde la perspectiva de la Jefatura de Proyecto hace que ésta cuestione el trabajo del Analista Funcional por los puntos expuestos anteriormente:

  • Malestar del cliente.
  • Desconfianza del equipo de desarrollo.
  • Si la ignorancia se manifiesta sobre el sistema en producción, existirán proyectos abiertos eternamente que nunca llegan a facturarse, aumentando el malestar del cliente y el del equipo de desarrollo que probablemente tenga que retrabajar para cubrir esas carencias fruto de la ignorancia.

Mis conclusiones

Antes responder a la pregunta ¿Qué es peor? ¿Un pollaque o la ignorancia? , es necesario conocer el entorno (Cliente, Equipo de Desarrollo y Jefatura de Proyecto) y sus características (asunción de responsabilidades -el cliente también asume las que le corresponden-, empatía, concepción del equipo -el cliente también forma parte de él-, percepción del tiempo -es perdido o invertido-, tolerancia ante el cambio, implicación y motivo de implicación, grado de interés en alcanzar el éxito y hasta dónde se está dispuesto a llegar para alcanzarlo).

Conociendo mi entorno y sus características, mi conclusión es que los pollaques son menos perjudiciales que la ignorancia:

  • Sus consecuencias son menos dañinas que las de la ignorancia. Las perspectivas anteriores lo justifican.
  • A pesar de ser su gestión más compleja e incómoda, ofrecen más margen de maniobra. Es mejor ponerse la cara colorada al inicio del proyecto que el que te la pongan al final.
  • Pueden tornarse en oportunidades cuando son gestionadas con maestría (no lo digo por mí, pero sí he presenciado algunas). De la ignorancia nunca surgirá una oportunidad (tal vez sí, oportunidades para la competencia …).
  • Se ven venir, y en consecuencia se pueden definir estrategias con las que sobreponerse. La ignorancia, por contra, es un enemigo que acecha desde la sombra. Lo único que puedes hacer es rezar para que ataque lo antes posible.