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”.




Lo que sé que sé (Parte I)

27 09 2008

En entradas recientes hablaba sobre aquello que sé que sé, sobre aquello que sé que no sé, sobre aquello que no sé que sé y sobre lo que no sé que no sé. Acontecimientos de los últimos días me han hecho reflexionar sobre cómo de axiomático debe ser lo que sé que sé.

Las responsabilidades del Analista Funcional deben ir más allá de volcar lo que sabe que sabe en requisitos:

  • Durante el Análisis de los requisitos, tras la captura de los mismos (tras la definición de lo que se sabe que se sabe), las responsabilidades del Analista Funcional podrían resumirse en la verificación de cómo de realistas son estas necesidades y expectativas volcadas en requisitos, en la priorización de los mismos y en la identificación de problemas como ambigüedades, inconsistencias y escenarios mal negociados que hagan peligrar los alcances y los propios planes de hitos.
  • Tras el Análisis de los requisitos, comienza una iteración de especificación y refinamiento de los mismos: los requisitos continúan tomando forma, permitiendo a los individuos involucrados añadir detalles (que en fases previas eran impensables) sobre los distintos modelos y reglas de negocio, casos de uso (o historias de usuario, o escenarios funcionales, etc.) y prototipos (en papel, no ejecutables). También es en esta iteración cuando comienza a tener sentido la gestión del cambio (en base a mecanismos de trazabilidad entre artefactos de Análisis), e identificar la forma en que se han de satisfacer ciertas necesidades de información mediante la integración con aplicaciones y procesos existentes (en el mejor de los casos, cajas negras mantenidas por terceros).
  • Tras esta iteración de especificación y refinamiento, se lanza la verificación y validación de lo especificado: los distintos individuos involucrados validan que su visión inicial del negocio es la que se refleja en los flujos generados y que los detalles son exactos y completos, para asegurar que el sistema a construir se ajusta (desde su concepción) a las necesidades deseadas, incluso en materia de integración con sus entornos de trabajo.

Algunas de estas responsabilidades parecen requerir además de la colaboración de otros perfiles del equipo, más teniendo en cuenta el skill del Analista Funcional (del que hablaremos en futuros post). De lo contrario …

  • ¿Cómo de idónea será la identificación de ambigüedades que realice el Analista Funcional? No perdamos de vista que el cliente final del Análisis es el propio equipo de desarrollo (ajeno a los procesos anteriormente descritos), y que siempre existirá una porción de información que no sabrás que no sabías (de hecho, los propios individuos involucrados en el proceso de toma de requisitos tampoco sabrán que no sabían, de ahí que antes hablase de visión inicial).
  • ¿Cómo de idónea será la negociación y priorización que lleve a cabo el Analista Funcional sobre cada una de las necesidades detectadas? Del conjunto de necesidades se han de distinguir aquellas que impactan transversalmente en el negocio de las que simplemente quedarían bien. Tal vez en esta cuestión el Analista Funcional con su skill tenga mucho que aportar por su papel de interlocutor, pero no perdamos de vista que la viabilidad, el esfuerzo y el impacto final de cada requisito está en la mente del propio equipo de desarrollo (naturalmente hablo de equipos de desarrollo relativamente auto-organizados, experimentados y disciplinados).

El equipo, la comunicación y la colaboración sencilla y eficaz son la clave de este proceso, aunque le pese a Confucio y a uno de sus proverbios más citados: saber que se sabe lo que se sabe y que no se sabe lo que no se sabe; he aquí el verdadero saber.





Lo que sé que sé (Parte II)

24 09 2008

Estas conclusiones apuntan a que los procesos de definición y gestión de requisitos pueden mejorarse enormemente aplicando ciertas buenas prácticas (inspiradas por valores). En el lugar donde trabajo intentamos día a día refinar y mejorar nuestros procesos, y creo que empezar por adoptar ciertas ideas de Scrum y del Product Backlog puede ser un buen punto de partida.

Sin ser un experto en metodologías ágiles, y con mucho camino aún por recorrer, sí vislumbro ciertos valores y prácticas que mejoran los procesos, y que deben acompañarlos en cada fase del ciclo de vida. Concretamente, y en las fases en las que interviene el Analista Funcional, considero interesantes los siguientes valores y prácticas:

  • Los artefactos de Análisis deben contener información viva, en continuo crecimiento y evolución, que durante el ciclo de vida se va desarrollando en paralelo con el resto de actividades; de esta forma siempre se proporcionará al cliente el mayor valor posible. Este valor es fundamental, aunque se ha de asumir que los alcances (medidos en necesidades a su vez expresadas en requisitos) son negociables.
  • La concepción del negocio por parte del cliente (su visión) ha de ser conocida por todo el equipo. Cuando esta visión sea comprendida por el equipo, sus aportaciones introducirán (o descartarán) funcionalidades, mejoras y tecnologías, permitiendo la detección y corrección de errores de forma prematura, que se incorporarán a los productos de Análisis a través de sucesivas iteraciones del proceso.
  • Como resultado de estas iteraciones, el equipo generará una visión real, aún más comprendida y compartida por todo el equipo. Este valor, a su vez, refuerza a las anteriores prácticas.

Esta es mi visión (mía, propia, particular), que espero seguir refinando y mejorando poco a poco (porque será un síntoma claro de madurez) en futuros post sobre cómo materializar estos propósitos y buenas intenciones en el día a día.