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.





Lo que sé que sé, lo que sé que no sé, lo que no sé que sé y lo que no sé que no sé

17 09 2008

Ante una frase como la que titula este post, hace 8 años, en el instituto, lo que se me hubiese pasado por la cabeza serían figuras retóricas como aliteración, anadiplosis, anáfora, encabalgamiento o paradoja. A día de hoy me evoca otras mucha sensaciones, que me llevan a pensar que la retórica no sólo puebla la literatura universal, también se presenta en el día a día del Analista Funcional.

Este perfil, por la horizontalidad de su trabajo, se suele ver salpicado por cualquier conflicto que aparezca durante la vida de un proyecto software. En mi opinión esto no es ni bueno ni malo, es inherente a la naturaleza de las responsabilidades asumidas por el propio perfil. Cuanto más expuesto se está al peligro, más consciente se ha de ser de este tipo de circunstancias. Recientemente un compañero de la oficina pasaba el enlace a un artículo que trataba estas cuestiones; me gustaría rescatar de él esta frase, mordaz y a la vez llena de sentido (FA, Functional Analyst): … All fingers often point to the FA. If the FA does their job, then everything should work out. If something is found to be missing from the solution, then the FA is often the role that is blamed first.”

En los procesos de toma de requisitos existen factores que condicionan el éxito de los mismos; según el porcentaje de ocurrencias de estos, la balanza se inclinará hacia un lado o hacia el otro. Estos cuatro factores que me acosan cada día son los plasmados en la siguiente imagen (probablemente se podrían definir con una granularidad mucho más fina).

Cuando sé que sé, lo que sé adquiere validez axiomática, y se plasma en un requisito. Este es el factor en el que el riesgo en el proceso de toma de requisitos es nulo, siempre y cuando los requisitos capturados se definan de acuerdo a los 13 mandamientos en el proceso de definición de requisitos.

Cuando no sé que sé, lo que sé es porque hay un bagage de información, buenas prácticas y habilidades que en cierto modo están arraigadas en la metodología de trabajo, en la forma de concebir el negocio de cada cliente, etc. En definitiva, es el resultado de la experiencia (la mía no es aún demasiado dilata, todo hay que decirlo). Este factor incorpora un cierto nivel de riesgo, que se puede mitigar.

Cuando sé que no sé, es necesario lanzar una nueva iteración en el proceso de toma de requisitos. De este tema me gustaría hablar más detalladamente en futuros posts, aunque todo gira en torno al enfoque JIT (Just In Time), consistente en obtener el nivel de detalle necesario en el momento oportuno.
En la capacitación del Analista Funcional, las suposiciones no suelen ayudar. Lanzar preguntas abiertas (la respuesta no es un sí o un no) sí. Las preguntas sí/no, si son necesarias, se harán en la última iteración del proceso. Estas preguntas abiertas serán del tipo ¿y si …? y ¿qué sucede en caso de …?, entre otras. No obstante, constituyen un arma de doble filo dado que las respuestas podrían venir acompañadas a su vez de preguntas del tipo ¿Pues ya que …? (comúnmente denominadas “pollaques”), las cuales, en el peor de los casos, derivarán en una revisión del alcance del proyecto (y en el consecuente arrojo a la hoguera del Analista Funcional).

Cuando no sé que no sé, … cuando no sé que no sé … ¡No sé! Este factor es el que introduce mayor riesgo en el proceso, la felicidad del ignorante, y si no es detectado puede originar auténticos fracasos. Por orden de aparición y de magnitud del desastre, nos encontramos el retrabajo (y el consecuente esfuerzo malgastado), las planificaciones y alcances infravalorados, retrasos en hitos, malestar de los involucrados en el proyecto y, por qué no, rescisiones de contratos (afortunadamente para el Analista Funcional, fue echado a la hoguera hace mucho). ¿Realmente se debe delegar este factor al destino? Estoy empezando a alcanzar conclusiones sobre esto, y necesito madurarlas un poco. La respuesta, en futuros posts.





Los 13 Mandamientos en el Proceso de Definición de Requisitos

14 09 2008

… Entonces Jehovah dijo al Analista Funcional:
— Escribe estas palabras, porque conforme a ellas he hecho pacto contigo y con el Equipo de Desarrollo.

El Analista Funcional estuvo allí con Jehovah cuarenta días y cuarenta noches. No comió pan ni bebió agua. Y en las tablas escribió las palabras del pacto, los trece mandamientos:

  1. No pensarás el cómo, tan sólo el qué y el por qué.
  2. No te pronunciarás en tiempos condicionales; en todo caso, te pronunciarás en tiempos imperativos.
  3. Evitarás recoger Detalles de Diseño.
  4. No te pronunciarás con expresiones vagas en significado, como “generalmente …”, “comúnmente …”
  5. Evitarás recoger opcionalidad en la descripción de un Requisito. Si existen distintas opciones en un Requisito, las modelarás como atributos del Requisito o en nuevos Requisitos, pero nunca en el mismo Requisito.
  6. Detallarás en un Requisito cada necesidad, de forma individual. Muchos verbos concentrados en un Requisito dificultan su comprensión y su posterior trazabilidad.
  7. Evitarás el exceso de términos y de verbos en cada Requisito. Las necesidades o informaciones se mezclarán si se proporciona demasiado detalle; ese detalle se indicará en Casos de Uso, refinando los Requisitos.
  8. No recurrirás a los Acrónimos, salvo que se recojan en Glosarios u Ontologías de Términos y previamente se haya aprobado su uso.
  9. Respetarás el equilibrio entre la necesidad a describir y el número de sílabas por palabra y el de palabras por frase, usando “,” y “;” apropiadamente en la descripción de los Requisitos para fomentar la legibilidad de los mismos.
  10. No usarás pronombres.
  11. No usarás pseudocódigo: “si fecha es mayor que …”, “iterar sobre …”, etc.
  12. No usarás términos como accesible, amigable, rápido y eficiente, entre otros; son difíciles de medir. En su lugar usarás unidades físicas para medir, por ejemplo, cómo de rápido debe rendir un Requisito, o WAI AA, para especificar claramente cómo de accesible ha de ser el Requisito.
  13. Verificarás que las aserciones puedan ser medidas de forma sencilla. Como contraejemplo, abstente de expresiones del tipo “sin sobrecargar demasiado el servidor”.
Los 13 mandamientos

Los 13 Mandamientos en el Proceso de Definición de Requisitos

Estos diez mandamientos se encierran en dos:

Amarás a la desambiguación y a lo axiomático sobre todas las cosas y a las 3 C´s (concisión, claridad y concreción) como a ti mismo.





Welcome to the Jungle

14 09 2008

Hoy tiene lugar el comienzo de mi andadura en la sociedad de la conversación, de la mano de este blog. 

Quiénes me conocéis, sabéis cuáles son mis preferencias musicales, y aunque Guns N’ Roses no está entre los favoritos, sí que he decido bautizar este blog con un post cuyo nombre es el de una de las más famosas canciones de este grupo norteamericano: Welcome to the jungle, escrita por Axl Rose y Slash.

Quiénes me conocéis, también sabéis que me gustan las metáforas, y es por este motivo por el que he escogido este título para mi primer post.

  • You know where you are?, you’re in the jungle baby, you’re gonna die! El estado que presenta actualmente la blogosfera hace que sea una auténtica jungla, a la que me doy la bienvenida, esperando no “morir” en el intento.
  • Axl Rose dió forma a sus conclusiones tras un pequeño incidente con un vagabundo mientras caminaba por la ciudad de Nueva York, naciendo así este tema. Por mi parte, también intentaré dar forma a mis conclusiones (actualmente algo dispersas en cuadernos de anillas), profundizando más en mis áreas de conocimiento, no sólo a través de las reflexiones propias del día a día, sino también a través de los comentarios e impresiones que surjan a raíz de cada post. 

¿Qué encontraremos en este blog? Trataré (espero que poco a poco sea un tratare-MOS) cuestiones relacionadas con Ingeniería Software, en materia de Procesos y Metodología, Gestión del Ciclo de Vida de Proyectos Software, Prácticas, Valores y Factores de Éxito y Gestión de Requisitos, además de reflexiones de índole variada sobre estas y otras cuestiones.

… ¡Pero no todo iba a ser trabajo! Quiénes me conocéis, también sabéis mi gran pasión por el buen comer, que me ha llevado a ser erigido como Líder Gastronómico en la Oficina. Haremos algunos guiños a la buena cocina en Sevilla, para que conquistéis vuestros paladares y los ajenos con cientos de colores y sensaciones gustativas.