martes, 9 de marzo de 2010

Fábricas de Software – El Diagnóstico

En mi post anterior sobre fábricas de software escribí un poco de lo que  estas son a nivel general. Como comenté, la primera etapa para la implementación de estas es conocida como Diagnóstico. Pero concretamente, ¿qué aspectos son los que debo diagnosticar? bueno, son estos aspectos los que empezaré a comentar:

La Metodología: este aspecto suele ser el más básico201003-01-FabricaSWDiagnostico. Pero muchos piensan que hablar de metodología es hablar de algo complejo o pesado, de documentación en abundancia y artefactos por doquier. Realmente no es así, metodología es hacer que los métodos comúnmente aplicados por miembros de mi equipo se formalicen e implanten no a nivel individual, sino de equipo. Es por ello que cada método o procedimiento debe ser analizado por todos los miembros, se deben comparar y así determinar el más adecuado (basándonos en criterios como eficiencia, calidad, esfuerzo requerido, etc.), posteriormente esto se puede documentar aunque sea en un formato checklist (ojo también pueden ser plantillas más elaboradas) y aplicar el versionamiento respectivo.

El Equipo: es fundamental conocer al equipo que se posee, conocer sus competencias técnicas y de aptitud. Es necesario tener claro el perfil de cada miembro del equipo, así como los temas de su preferencia o dominio (línea de negocio que más le guste o aplique). El conocer el equipo me permitirá identificar a su vez aspectos claves como: roles con los que cuenta el equipo (a veces todos son programadores, y resulta que también necesito Analistas Funcionales, Testers, etc.), si conocen la tecnología que requiere el cliente, si se encuentran actualizados, si encajan con lo que ofrece mi servicio. En base a esto debería apuntar por lo menos a cubrir los siguientes roles: Jefe de Servicio, Jefe de Proyecto, Arquitecto de Software o al menos Líder Técnico, Analista Funcional, Analista Desarrollador o al menos Desarrollador, Analista de Control de Calidad o al menos Tester, y Help Desk. Si no tengo cubiertos todos estos roles, dificilmente pueda cumplir con el servicio que debería ofrecer una fábrica de software.

Las Herramientas: hay herramientas principales que debería identificar como: software de gestión de proyectos (por lo menos algo como MS Project), control de código fuente, portal de colaboración (administrador de contenido del proyecto), software de modelado BPM/UML/Diagramas de Flujo que me permita modelar el negocio y sistema, software de modelado de ER/base de datos, entorno de desarrollo integrado (popularmente conocido como IDE) de la tecnología a utilizar, software de pruebas unitarias (generalmente incluido en el IDE), software de documentación de observaciones (al menos algo como MS Excel) y software de incidencias (que me permita generar tickets de atención a usuarios del sistema). Todas las herramientas identificadas deben documentarse brevemente; además, debe tenerse información de soporte como How To’s, ayudas, videos, manuales, etc.

La metodología, el equipo, las herramientas y el workflow de servicio son los aspectos claves que debo diagnosticar. La calidad de estos determinará, en mayor o menor medida, el cumplimiento adecuado del servicio de mi fábrica de software“

El Workflow de Servicio: este aspecto es clave, practicamente es el que determina si ciertamente cumpliré con lo mínimo requerido por mi cliente. Un flujo de servicio determina, o debería determinar, el flujo de atención de mi fábrica. Hay que desarrollar aspectos claves como: tipos de proyectos que se atienden, duraciones, documentación a generar para cada tipo, roles que intervienen (sobre todo para las aprobaciones), entregables e indicadores de medición de mi servicio.

Como consecuencia del diagnóstico debería obtenerse conclusiones que me permitan tomar medidas preventivas, de seguimiento y control, y correctivas del servicio brindado por mi fábrica de software.

No hay comentarios:

Publicar un comentario