En este artículo describiré mi forma de ver la gestión de equipos de desarrollo de software en particular. Como se debe articular un grupo de desarrollo de Software para:
- Tener una forma de trabajo sencilla de entender y aceptar por el equipo
- Trabajar de forma eficiente: capacidad de medir el tiempo de desarrollo y tomar decisiones para mejorarlo
- Cubrir varios proyectos a la vez por un mismo equipo
- Equipo distribuido geográficamente
Metodología es necesaria para esquematizar una serie de etapas que concluyen el producto final. En mi experiencia profesional, son las ágiles las metodologías que se acercan más a la realidad. Me basaré en:
- Scrum desarrollo ágil de cualquier tipo de producto, define roles, y forma de reproducir las iteraciones medibles, reuniones necesarias …
- eXtremeProgramming metodología más específica al desarrollo de aplicaciones, define forma en la que se deben automatizar pruebas, control de versiones,requisitos, código colectivo,…
La metodología nos aportará:
- Labores a desarrollar en cada etapa
- Secuencia en la que se cumplen esas etapas
Roles en el equipo (reparto de las labores de la metodología):
- Master: Vigilar el cumplimiento de la metodología, enseñarla.Define prioridades, roles, proyectos. Orquesta. Facilita cosas.
- Comercial: Primer contacto con el cliente. Vigila que todo el proceso comercial sea rentable.
- Arquitecto: Decidir tecnologías, enseñarlas. Construir el Sistema de soporte Arqo
- Calidad (Tester): Decidir tecnologías, enseñarlas. Construir el Sistema de soporte Calidad (CI, TDD, SVN)
- Analista(Product Manager): Determinar requisitos del usuario, convertirlo a esquemas entendibles por el desarrollador, priorizar dentro tareas (maximizando el ROI) y hacer demo al usuario. Maximizar la usabilidad.
- Gestor de Proyectos: planificación de iteraciones, versiones de aplicaciones, reparto de tareas entre miembros del equipo. Maximizar regularidad del equipo y reparto coherente de tareas.
- Programador de BD: desarrollo de BBDD para mínima duplicidad.
- Programador de Negocio: desarrolla las librerías de negocio para máxima reutilización (forma de APIs y WS)
- Programador front-end: desarrollo de las pantallas web para máxima usabilidad
Las parejas de roles Master-Comercial, Arquitecto-Calidad, Analista-Gestor se pueden definir como tres roles distintos. Depende del número de personas en el equipo y de como se quieran hacer las cosas.
Roles de programador habrá tantos como tecnologías implique la arquitectura, siendo los que se definen atrás los básicos (Flash, diseño web, …). También se pueden combinar en una sola persona.
Herramientas son las que van a ayudar al equipo trabajar conforme a la metodología.
- Sistema: red (ADSL), Sistema Operativo (Ubuntu: OpenOffice, navegador…)
- Comunicaciones: Correo electrónico, Video/Chat (Skype)
- Gestión de Proyectos: redmine+redminebacklogs. Control de versiones (Subversion).
- Arquitectura: IDE (Herramientas de desarrollo, Eclipse, DBDesigner,…), Dependencias de Tecnologías (Hibernate, ADF, ZK,…)
- Calidad: plugins de cobertura, servidor Integración Continua, Análisis de código, herramientas para pruebas,…
El Backlog es el que representa el trabajo diario del equipo:
Hola Sr. Lebrijo, pero los reyes magos son los padres.
Por cierto, en el dibujo/esquema de un equipo completo de desarrollo, solo hay 2 chicas. ¡Como se entere bibiana!.
Es broma. El artículo está perfecto y sería un lujo poder trabajar en un equipo que funcionsae así.
Otro post sobre gestión de equipos detallando lo que se hace mal:
Potencia tu equipo: ¡ No al sistema de castas !
Mr. Lebrijo… un artículo genial… pero sinceramente, conoce muchas empresas, equipos o personas capaces de sostener en el tiempo un organigrama de este tipo. Mi experiencia me dice que la teoría pocas veces coincide con la realidad cuando se mezclan personas con intereses diferentes… si, si, ya se que el interés es común… pero dudo que así lo vean cada uno de los integrantes de equipo…
Saludos…
Solo cuando empecemos a creer en lo que pensamos podremos empezar a trabajar en hacerlo realidad.
No conozco nigún grupo que trabaje así (sin duda me gustaría), pero la mayoría lo piensan, solo hace falta que lo crean y empezaremos a remar en esta dirección…
Mi experiencia me dice que cuando se trabaja en equipo (de verdad) se pueden llegar a hacer cosas que ni siquiera podríamos imaginar al empezar.
Saludos, y gracias por leerme 😉
Concuerdo bastante con el articulo, especialmente quisiera destacar la necesidad en cuanto a lograr establecer un patron de codificacion unico dentro de un equipo de desarrollo. Hay que prestar especial atencion a la forma en que cada desarrollador escribe su codigo, pues al final la mayoria de este no se usa por quien lo hizo, sino por revisores de calidad o personal encargado de dar soporte y mantenimiento al mismo.