El secreto de las herramientas. Un secreto gritado a voces.

Todos sabemos que las herramientas ayudan a los profesionales de todos las áreas en su trabajo.

Algunas herramientas son más completas, otras más eficaces, algunas facilitan el trabajo, otras permiten hacer el trabajo más rápido. Como sea, sin herramientas muchos trabajos no se podrían realizar.

Clavar un clavo sin un martillo o ajustar los tornillo de una rueda sin al menos un llave CRUZ, serían tareas demasiado complejas, difíciles o imposibles de ejecutar, incluso para profesionales avezados.

La herramienta sola no es nada, dependemos de la habilidad de quien la usa, la herramienta debe estar en manos de un trabajador (worker); él es quien cambia el destino de una batalla.

Tener la herramienta sin el worker sólo te hace poderoso en una mesa, durante una charla, pero no en el campo de batalla.

En el área de conocimiento de software las personas y las herramientas son elementos importantes de la calidad, diría que la interacción producida entre la persona y la herramienta es mucho más importantes que los elementos por separado. La persona tiene el conocimiento y el herramienta el don de facilitarlo. El conjunto es un simbiosis fundamental.

No es concebible desarrollar software sin ambos elementos, mucho menos con calidad; pero recuerda el verdadero secreto no es la herramienta sino la persona que la usa.

De este modo comprenderás que si pones tu éxito sólo en las herramientas te estarás equivocando y si solo lo ponés en las personas será insuficiente deberás realizar una mezcla útil.

Tampoco puedes esperar que la relación se base en tomar un individuo  y darle una herramienta. El individuo debe conocer y saber hacer con la herramienta.

El éxito de la relación lo consigues cuando el profesional sabe usar la herramienta y tiene arraigado los conceptos que le permiten volverla más eficaz.

De nada sirve que se tenga una herramienta para modelar diagramas de actividad, si el profesional no conoce sobre  diagramas de actividad. Puede que haga un dibujo con componentes de diagrama de actividad, pero ¿estará haciendo un diagrama de actividad?

Tareas de Análisis. Características

Introducción

Sin importar la forma que le des al proyecto, ni cual ciclo de vida tomes como base; un proyecto de desarrollo siempre tendrá las tareas de análisis, diseño, codificación y prueba. Son tareas básicas.

Puedes tener motivos y razones super convincentes para negar una actividad básica. Puede suceder que utilices un generador de código y la programación se simplifique, estamos de acuerdo; se consume menos esfuerzo; pero la tarea existe.

La forma que adquiera el proyecto no es nuestro centro. Algunas personas prefieren invisivilizar ciertas tareas, diciendo que no hay diseño, o que no se realiza la prueba. No importa lo que digan. Si no explicitas la prueba te está faltando o esta oculta bajo otro título.

No se debería pasar un producto de software al cliente sin hacer pruebas; no debería comenzarse la programación sin un diseño mínimo. Lo que no se haga donde corresponde quedará en manos del que sigue en un proceso de desarrollo. Si el que sigue es el cliente, bueno es tu riesgo.

Luego según la cultura de tu empresa, de tu equipo o tu región realizarás proyectos en donde algún tipo de tarea destaque sobre otra; siendo, por ejemplo, las pruebas mínimas y de un solo tipo.

En este blog trataremos las características de las actividades básicas. Nuestro centro es la tarea de análisis.

Objetivo

Explicitar las características generales de la tarea básicas de análisis dentro del marco de un proyecto.

Análisis

El análisis es un tarea que puede especializarse en muchas subtareas y muchas formas; pero una característica casi natural es que es una actividad netamente iterativa y cognitiva; estas son las características que la destacan.

Un analista realiza un conjunto de acciones para comprender el sistema bajo estudio, volviendo y una otra vez sobre tareas que parecían terminadas, pero no lo están.

Característica 1. Materialización del producto de trabajo.
Un analista realiza una entrevista y comienza el análisis; como consecuencia descubre omisiones, falta de información y otras yerbas; el resultado volver a realizar una entrevista.

El párrafo anterior muestra que avance pero no produje nuevos artefactos; comencé con una entrevista y por el estado del arte regresé por una nueva entrevista. Es cierto que he avanzado pero no en forma lineal sino iterativa. Continuo relevando el sistema pero con otro conocimiento inicial.

Luego pasaron 2 días y el analista tiene más dudas que productos de trabajo elaborados. Esto es y debe considerarse completamente natural. Lo importante no es documentar el sistema, sino comprenderlo y luego documentar la comprensión. Como sea, pueden pasar varios días de borradores, bosquejos y anotaciones; pero ninguna producción concreta.

Es importante tener presente está característica pues, en una tarea de análisis de una semana es probable que comencemos a ver producción a partir del día 3 o 4; esto es aproximadamente en el 50% del esfuerzo ejecutado. En una tarea de análisis de 15 días se puede comenzar a ver la producción de la documentación cuando la tarea lleva un 20 %, pero no será cerrado hasta un 90%  avanzada su ejecución.

Estas ideas son cuestionables; en el sentido que las personas tienden a tener distintas estrategias de trabajo. Algunos profesionales crean al principio todos los documentos que saben que usarán, lo cual puede parecer que se han desarrollado muchísimos artefactos; pero ninguno está ni siquiera completado con contenido significativo; ver muchos documentos realizados es una falsa presunción de avance en muchos casos.

Característica 2. Cantidad de productos de trabajo
El análisis es una de esas tareas que crea un número interesante de artefactos: listas de requerimientos, reglas de negocio, maquinas de estado, modelos del dominio, tabla de actores, diccionarios de datos.

Mientras que en otro tipo de negocios cada actividad produce un producto de trabajo ( o 2), en el análisis se producen al menos una decena. Algunos ni siquiera estaban planeados...grrrr.

Esta cantidad no es sinónimo de tamaño. Hacer 10 productos de trabajo sobre un total de 20 no significa que se ha realizado el 50 % de la tarea. Si pensabas eso, pues lo siento no es así.

Característica 3. Evolución de productos de trabajo
El análisis tiene eso viste, pensás que estás terminando un producto de trabajo y cuando comenzás (o continuás con) otro; descubrís que estabas errado.

Ey!!!!, no debería decir que la tarea de análisis es una tarea compleja; pues bien lo es.

Ahora bien, la tarea de analisis es de estas tareas que cuando más crees que avanzaste, más seguro estás que no; luego finalmente como por arte de magia, se estabiliza y todo fluye.

Aquí se presentan algunos ejemplos que muestran la evoluciones típicas en la producción de artefactos / productos de trabajo:
Ejemplo 1

Este podría decirse que es el más natural, escasos o nulos artefactos al comienzo de la actividad / tarea y luego de superado el 50 % un crecimiento continuo.
Observe que no se indica el tiempo en números es simplemente una idea de evolución teórica.
Ejemplo 2

En este caso se intenta mostrar que al principio no existen artefactos, pero luego comienza a aparecer hasta alcanzar la totalidad de artefactos que debían crearse. En este fenómeno el analista estuvo un tiempo importante realizando procesos mentales hasta que decidió que el trabajo ya podría comenzar a materializarse. Tiene ciertas semejanzas con el ejemplo anterior.

Ejemplo 3

Aquí se intenta mostrar que se producen una serie de artefactos al principio y el resto al final.
Este es el caso del analista se apresura a crear artefactos pero no completará mucho hasta acercarse al final.

Ejemplo 4

Este caso no es real en el análisis. Aquí se muestra que la producción de artefactos es continua y constante, nada más irreal en la tarea de análisis.

Claro está que no son las únicas evoluciones, pero la intensión es simplemente ejemplificar la idea.