Un “rol”, es una figura que adquiere una persona y que conlleva ciertas responsabilidades
o comportamientos asociados. En el desarrollo de software, los integrantes de un
equipo adquieren rol o roles según la función que desempeñen. El rol es independiente
del puesto (o por lo menos no hay ningún motivo para que dependa de él) y una misma
persona puede desempeñar varios roles al mismo tiempo.
En el desarrollo de software tradicional hay una serie de roles bien marcados. los
analizaremos uno a uno y compararemos su función en metodologías tradicionales
con el desarrollo de software ágil. Los roles a considerar son: Cliente,
Líder de proyecto, Analista, Arquitecto, Diseñador, Programador y Tester.
Cliente
Es la entidad (o persona representante) que tiene la necesidad de un sistema o software
nuevo (o de la modificación de uno ya existente). Una parte importante relativa
al cliente es el usuario operador, que es la persona concreta que va a utilizar
el sistema. Puede, y es además bastante probable, que el cliente o dueño final del
sistema a construir no sea la misma persona que el usuario.
Líder de proyecto
Es el responsable (directo) de llevar a buen término el proyecto, por lo menos de
parte de la empresa constructora del software. Debe coordinar al resto del equipo
para que trabajen en armonía y eficientemente, también es el responsable de concretar
las fechas de entregar de cada fase y garantizar que son cumplidas. El resto de
personas del equipo trabajan bajo su dirección
Analista
Es rol encargado de analizar las necesidades del cliente en cuanto a su futuro sistema.
Debe tener la capacidad de concretar todo lo expuesto por dicho cliente en una colección
de requisitos a construir, además debe entender el negocio del cliente (que seguramente
le es ajeno) y poder hablar su mismo "idioma". Una de las partes mas complicadas
del rol de analista, es poder asumir que el mismo cliente no comprende completamente
sus necesidades, ni las múltiples soluciones software a este. El cliente generalmente
solo va a querer automatizar el trabajo que ha estado haciendo hasta ahora y va
a mostrar una gran resistencia al cambio y a su forma de trabajar. Pero el problema
es que cambio es realmente necesario, sino no necesitaría un nuevo sistema software.
Si el analista no es capaz de comprender esto, el desarrollo se alargara mucho más
tiempo del calculado, y creara una sensación de insatisfacción tanto del cliente,
como del equipo constructor, que sentirá esta andando en círculos y sin sentido
durante todo el proyecto.
Arquitecto
El rol de arquitecto es uno de los mas confusos que existen (asumiendo a veces roles
de programador o diseñador), pero en esencia debe encargarse del sistema a un nivel
"macro". Debe asegurar que el sistema encaja perfectamente en el resto de sistema
de la empresa, que se esta construyen con las patrones, metodólogas y herramientas
adecuadas, garantizando que el sistema presenta una continuidad de negocio con el
escenario actual de la empresa y que está preparado para adaptarse a los futuros
, y posiblemente desconocidos, cambios venideros. Además debe detectar los componentes
reutilizables de un sistema (que son mas de los que a priori se cree) y asegurase
que son creados, utilizados y conocidos, por el resto del equipo.
Diseñador
Es el responsable de convertir los requisitos obtenidos por el analista, en "algo"
que se pueda traducir en software, mediante las guías e indicaciones de la arquitectura
de software. Se encarga de definir el sistema en un nivel detallado y concreto.
El diseñador indicara que componentes y de qué forma se relacionan dentro del sistema
y en la lógica de negocio.
Programador
Es el constructor efectivo del sistema, resolviendo los requisitos mediante código
fuente, que a su vez es convertirlo en dicho sistema. Debe ser experto en las tecnologías
es las que está trabajando, aunque es frecuente que a veces se auto capacite según
las necesidades del sistema, con éxito disparejo. Debe tener capacidad de participar
en un escenario colaborativo con el resto de los codificadores
Tester
Es el encargado de validar que el software cumpla con los criterios de calidad establecidos,
es decir que el software funcione. Se puede considerar que un software sea de “calidad”,
en diversos aspectos incluyendo el aspecto el grafico (interacción con el usuario),
el funcional (que cumpla lo requerido), o el operativo (que siga funcionando en
determinadas circunstancias como carga excesivas o situaciones de uso “anormales”).
Roles en metodologías de desarrollo de software tradicionales
En las metodologías de software tradiciones, se sigue una secuencia de fases más
o menos estricta (que puede repetirse en varias vueltas o ciclos). Cada fase tiene
una entrada y una salida, en las primeras fases (análisis y diseño), se convierte
las requisitos de usuarios, en documentación, en las fases de construcción, se “convierte”
la documentación en software.
Cliente
Curiosamente el cliente no tiene gran relevancia en las metodologías tradicionales,
interviene al principio de la fase de desarrollo (en la que es entrevistado), y
al final al recibir el sistema construido. Pocas veces se le considera como parte
del flujo de desarrollo de software, salvo por reuniones puntuales que no tienen
más objetivo que garantizar que el software se sigue construyendo.
Líder de proyecto
Uno de los roles más importantes. De su capacidad de organización y gestión dependerá
el éxito del proyecto. Debe coordinar al equipo para llevar a cabo el objetivo,
que es la generación del sistemas en tiempo y forma.
Analista
Debido a que es el iniciador del proceso y es el que extraerá los requisitos directamente
del cliente, su importancia es alta. Una mala interpretación del analista puede
ocasionara una desviación importante en el proyecto. El análisis es una fase que
suele alargarse bastante puesto que el cliente no suele estar presente en otras
fases del desarrollo.
Arquitecto de software
En las metodologías pesadas el papel del arquitecto de software no es tan relevante,
no porque la arquitectura no lo sea sino porque generalmente el sistema está pensando
más como un elemento único y no se tiene un enfoque parecido a una fábrica de software.
En este escenario el diseñador toma parte de las responsabilidades del arquitecto.
Diseñador
El diseñador es el puente entre el analista y los programadores, traducirá los "requisitos",
en definiciones y diagramas, para que posteriormente sean convertidos en código
fuente. La coherencia de sus diseños, se trasladara al sistema final, si sus diseños
no son coherentes, se acara teniendo un motón de código fuente que tiene sentido
como piezas individuales, pero no como un sistema integral.
Programador
Como mencionamos el programador convertirá la documentación obtenida hasta este
punto en código fuente, aquí tomara decisiones relativas a la optimización, la estructuración,
o a la resolución de problemas concretos relacionados con el lenguaje o la tecnologías
seleccionadas.
Tester
Es parte de las secuencias de fases del desarrollo. una vez construido el sistema
se pasa a pruebas y se devuelve si no son satisfechas.
Roles en metodologías de desarrollo de software agiles
Para la resolución de metodologías agiles hay varios enfoques, pero todos alzan
el valor del software productivo (ya construido), y las iteraciones humanas, frente
a los procesos y la documentación.
Cliente
El cliente es el elemento más importante y se considera como parte del equipo del
trabajo. Hay que tener en cuenta que todo el significado y motivo de creación del
sistema, es la resolución de una necesidad el cliente. El cliente interactúa de
diversas formas y frecuentemente en todas las fases del proyecto
Líder de proyecto
Las responsabilidades dentro de un modelo ágil están distribuidas en un modelo mas
"plano", dividiendo dichas responsabilidades entre todos los participantes del proyecto.
Si bien es necesario alguien que se encargue de llevar el seguimiento y control,
no suele tener un puesto diferente al del resto de sus compañeros.
Arquitecto de software
Es el que define las políticas técnicas en cuento a la creación de software, aunque
más que políticas son una caja de “herramientas” de soluciones que funcionaron en
determinadas circunstancias y son reusables en el futuro, para otros proyectos.
Aquí se incluye el uso de patrones de software, librerías y framework. El arquitecto
debe vigilas que se apliquen las políticas adecuadas en cada momento, pero con la
flexibilidad necesaria para adaptar, crear o derogar políticas según sea necesario.
Analista
El contacto con el cliente es, con diferencia, mucho más frecuente en las metodologías
Ágil, lo cual hace que el rol de analista sea menos crítico. A diferencia de las
metodologías pesadas, se asumen una incapacidad inicial de comprender la necesidad
del cliente, dicha capacidad es suplida con entregas realizadas en corto tiempo,
que aportan cada vez más funcionalidad a la solución fácil, hasta que tanto cliente
como desarrolladores están conformes con el resultado.
Diseñador
La formalización del diseño (en documentación) no es tan importante, debido a que
si hay una buena colección de estándares, guías y arquitecturas, debiera quedar
implícitamente la forma de resolver un problema. En las metodologías agiles se asumen que los requisitos
van a cambiar con lo que cualquier propuesta de software debe asumir ese cambio
y estar preparado. Es decir en lugar de crear un software que solucione un problema,
hay que enfocarse en un software cuyo cambio no tengan un impacto excesivo en el
sistema.
Programador
Los programadores son la parte más relevante en las metodologías agiles, en la que
frecuentemente suele complementar su roles de programador, con los de analista y
diseñador. Esto es debido a que como no hay una excesiva documentación, la necesidades
de comunicación son más directas e inmediatas. Es esencial la comunicación oral
y el trabajo en equipo. De igual forma se necesita que los desarrolladores tenga
experiencia, sean respetuoso de los estándares y que conozcan todo las herramientas
reutilizables que tienen a su disposición .
Tester
Las pruebas en las metodologías agiles de hacen de forma más frecuente y continuada,
no es necesario que esté terminado el sistema para comenzar pruebas. El software
está diseñado de forma que se pueda probar unitariamente e incluso podría usarse
un desarrollo orientado a pruebas, esto es crear primero las pruebas y dar por satisfecha
la construcción del sistema cuando todas las pruebas tengan existo. Como vemos las
pruebas pueden comenzar desde muy temprano en un desarrollo ágil.
¿Cual usar?
Frecuente se dice que si tu proyecto es grande uses una metodología pesada, y si
es pequeño una ágil. En lo personal no estoy de acuerdo con este razonamiento, porque
parece más un temor a una metodología nueva que otra cosa, al considerar que si
el proyecto es pequeño se podría corregir cualquier desviación. Yo creo que lo que
define cual metodología usar, es la madurez y la capacidad de comunicación y colaboración
del equipo, cuanto mayor sea mayor es la posibilidad de éxito con una metodología
ágil, cuanto menor sea es mejor el uso de una metodología tradicional que garantiza
que cada paso está siendo perfectamente guiado y documentado.
