domingo, 24 de septiembre de 2017

Roles principales en el desarrollo de software, una comparación tradicional-ágil.


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.

No hay comentarios:

Publicar un comentario