domingo, 14 de febrero de 2010

Consejos últiles para gestión proyectos de software

Si bien la gestión de proyectos de software no es una ciencia exacta, mas bien es un arte o una destreza que se mejora con la experiencia, existen algunos consejos útiles para no cometer errores que pueden causar el fracaso de un proyecto.

Quien haya gestionado algún proyecto de software sabe que debe hacer malabares entre múltiples temas de gestión, como las personas (el equipo de desarrollo, el cliente, etc), los tiempos, las entregas, las estimaciones erróneas y sus costos extra, la replanificación, etc. Para comenzar un proyecto de software con el pie derecho aquí dejo algunos consejos útiles:

Pruebas unitarias
Desde el inicio del proyecto se deben establecer las pruebas unitarias que se implementarán en la etapa de implementación, estableciendo por escrito cuales serán los casos de prueba y sus respectivos resultados esperados.
Esto sirve para tener un criterio claro de lo que se desea probar y para estimar el tamaño de las pruebas a implementar, este costo se debe considerar para la etapa de implementación, ya que la implementación no es solo para la funcionalidad del sistema que estemos creando, es también para las pruebas de dicho sistema.
Si no se planifican las pruebas unitarias desde el inicio, no se considerará su costo de implementación, y las estimaciones serán erradas. Por otro lado la calidad del software se verá afectada por no tener un criterio claro de pruebas a implementar.

Documentación
Desde el comienzo del proyecto se debe hacer énfasis en la documentación que será creada, ya que el software no es solo un conjunto de archivos fuente, el software es eso más la documentación. Sin una correcta planificación de la documentación a generar, el equipo de desarrollo no sabrá qué debe documentar y cómo. Es necesario definir estándares de documentación y capacitar al equipo de desarrollo en los mismo, además es útil hacer incapié en lo valioso que es contar con documentación correcta y completa, ya que muchas veces el equipo de desarrollo desestima la documentación y no la hace, o la hace incorrecta o incompleta.
También es útil fijar la documentación necesaria desde el inicio del proyecto, ya que nos llevará tiempo crear esa documentación, y ese tiempo debe ser contemplado en la planificación para no tener atrasos, replanificaciones innecesarias y costos extras.
Es bueno contar con plantillas para los documentos que deban ser creados, de forma de partir con una plantilla que siga los estándares de documentación que se fijen, ahorrando tiempo al equipo de desarrollo.

Comunicación
La poca o mala comunicación entre los miembros del equipo de desarrollo y con el cliente es la principal causa de fracaso en los proyectos de software. La comunicación es un tema muy sensible, ya que es necesario planificarlo y dedicarle tiempo.
La planificación de la comunicación implica determinar qué medios de comunicación se usarán, entre qué personas serán usados esos medios, y para qué motivo particular se usarán. Muchas veces no todas las personas debe tener contacto directo con otras personas, por ejemplo ¿qué pasa si el cliente le envía un email directamente a un miembro del equipo de testing cuando el cliente debe ser atendido solo por el responsable del proyecto?
Otras veces cuando se tienen grupos de trabajo por área, y cada grupo tiene varios integrantes, es bueno definir un encargado de la comunicación de cada grupo, así la comunicación entre los grupos se hace mediante dos personas, en lugar de juntar a los grupos completos, muchas veces desperdiciando horas de trabajo.
Los grupos no deben ser islas, el trabajo de cada grupo, por ejemplo desarrolladores, testers, analistas, etc, debe ser público para todos los miembros del equipo de desarrollo.
Las charlas de pasillo son muy importantes para la comunicación. Una situación distendida, por ejemplo ir a tomar café a la cocina, puede ser un pretexto excelente para comunicar a los miembros del equipo de desarrollo, para preguntar por el avance en su trabajo, qué problemas encontraron, etc.
Una llamada por teléfono o un email a cada miembro del equipo, nunca está de más.

Medir el avance
Medir el avance del proyecto no es una tarea sencilla, muchas veces nos encontramos en una situación donde le preguntamos a un miembro del equipo ¿cómo vienes con eso? y él nos responde: "venimos bien". Esa respuesta no nos dice nada, no nos dice "tenemos el 75% implementado", nos dice "venimos bien", esa es una respuesta que debemos evitar recibir. Para esto es necesario planificar desde el inicio del proyecto cuál será el mecanismo de medida del avance. Para esto primero es necesario determinar el alcance del proyecto, o sea todo lo que se va  a hacer y lo que no se va a hacer. La medida de avance más simple es la del 100%, o sea ir marcando las tareas terminadas, el problema de este enfoque es que no podemos hacer medidas intermedias del avance, o la tarea está en 0% o en 100%, nunca vemos un 25% o 50%. Para medir avances intermedios es bueno partir una tarea en pedazos y asignarle a cada pedazo un valor, si la tarea completa tiene valor 100, cada subtarea tendrá su propio valor, el cual se irá ganando a medida que se avance en cada una de ellas, este es el enfoque del "valor ganado".
Medir el avance de un proyecto nos permite saber si las estimaciones de tiempo que hicimos al principio son correctas, y nos permite detectar desvíos de esas estimaciones. Cuando se detectan desvíos es útil analizar las causas, y muchas veces se termina en una replanificación. Por ejemplo, si estimamos 10 horas para una tarea y vemos que ganamos el 50% del valor de la tarea en 7 horas, estimaremos que la tarea será finalizada con 14 horas de dedicación, o sea que o el equipo debe apurarse para terminar el 50% de la tarea en 3 horas o se le debe sacar tiempo a otra tarea posterior para no atrasar todo el proyecto.