- Reuniones todos los dias.
- Diseño, discrusion y rediseño.
- El jefe da de alta una tarea en algun sistema de gestion de tareas y un programador tiene que ir completando las horas con lo que haciendo.
- Se hace integracion continua.
- Se tiene un equipo de integracion y estandar de calidad.
-Etc..
Todas son buenas ideas y todas pueden llevar al exito en la gestión de equipo de desarrollo de software. Si alguien aplica todo esto (o algunas cosas) y llega al exito genial. Pero se puede aplicar esto (y mas cosas) y no tener exito.
¿Que es el exito? el exito es conseguir los objetivos. Si el objetivo principal es tener lo que el cliente desea, el producto, en los plazos deseados pues se ha tenido exito. Si se tiene antes entonces has tenido mas exito. Si se tiene mas tarde has tenido menos existo. Si no lo tienes ha tiempo entoces no has tenido exito (has fallado).
Todas estas medidas (todas estas cosas) no se pueden aplicar solo porque sean buenas. Hay que tener siempre en cuenta las características de nuestro grupo de desarrollo:
- Si los programadores no estan contentos en generla (ganan poco dinero o algo asi) aprovecharan cualquier oportunidad en la que esten todos para quejarse. Por lo que una reunion no es una buena idea.
- Si los programadores no tienen iniciativa entonces no querran discutir un diseño. Quieren un diseño.
- Si el sistema de gestion no es dinamico y lleva poco tiempo usarlo entonces los programadores pensaran que es una perdida de tiempo o si los jefes dan de alta tareas en sistema de gestion y no son reflejos de lo que se esta haciendo en realidad entonces todos dejaran de usar la herramienta.
- Si no se usa la integracion continua para usar los datos que proporciona entonces al final se convierte en un mantenimiento que lleva mucho tiempo.
-Etc...
Hay que "leer al grupo". Habran cosas que se puedan implantar y funcionen. Pero habra otras donde habra que adaptarlas al grupo o no usarlas.
