Aprender las cosas como son

Cuando a alguien se le encarga gestionar el desarrollo de una aplicación (o parte de esa aplicación), su principal tarea es ver que falla de la tarea, como plantearla, como planificarla, etc.. y el gran problema es que el gestor esta obligado a hablar de asuntos tecnicos cuando se supone que un gestor "no debe saber nada" de tecnología.

Se debe abandonar los hábitos de poco esfuerzo (ser gestor y no querer saber nada técnico). No debe saber lo mismo que un técnico pero tiene que hablar el mismo idioma.

¿Como sabes que estas hablando el mismo idioma?
 - Si lo único que un gestor le dice a un técnico es "¿cuanto te queda?", "¿como vas?  y acto seguido le dice el gestor que le queda (se nota que no ha entendido la explicación de como va)". Esto es síntoma de que el gestor y el tecnico no hablan el mismo idioma.

Solución: Gastar tiempo del gestor y del tecnico y que el tecnico le explique al gestor como esta implementando la tarea. Ojo, el gestor nunca tiene que hacer "nada tecnico" pero debe ser capaz de entender lo que el tecnico le dice y ser capar de pedir cambios (en el idioma del tecnico).

Estimation by approach. Always usefull

Sometimes the project manager people think the agile methods cant be used in the projects developed by a traditional approach. The things are not always black or white, we can use agile methods for all kind of projects. For example, the estimation by approach, we can use it for estimating task in projects with a traditional way of work.

In addition, the estimation by approach is always the best way for estimating task if you want a real estimation. The one way for a real estimation is to know the time a developer have spent in some task. This is the great true and, in conclusion, the bes† way to estimate a task is to use the known duration of some task and use this duration for estimating other task.

The estimation by approach is very simple, if we know that a developer spend 3 days for completing a login screen and we suppose the list of costumer screen has four times the login screen size then a good estimation for a list of costumer screen is 12 days.

How you can see, we are using a estimation by approach without change the way of work. 

Desenredar los cables

Cuando has trabajado en varios proyectos de desarrollo de software de mediano-gran tamaño te das cuenta que la tendencia normal es que no exista documentación que te guíe por el código, los compañeros te ayudan pero como mejor saben (y cada uno a su manera), etc.. Esto hace que cuando se le pide a un programador que implemente sus primeras tareas este tenga la sensación de tener que "desenredar los cables" para poder empezar.

Al analizar esta situación en detenimiento, todo esto se traduce en muchos factores no deseados:

• Insatisfacción y frustración del programador.
• Costes de aprendizaje que se multiplican.
• Sensación de mala estructura del proyecto.

Siempre se debe tener un mecanismo de formación "automático" (quiero decir que no necesite de una tercera persona, es decir se le puede decir al miembro del equipo "toma esto" y con lo que se le de entonces puede formarse) para que un miembro del equipo pueda consultarlo y pueda usarlo como guia.

El procedimiento para tener un mecanismo de formación automático es tener una documentación técnica apropiada. Esta documentación tiene que tener las siguientes características:

• Estar escrita en un idioma de programadores. Lo cual garantiza que no se "hace larga de leer" y va directa al grano.
• Estar escrita en un formato cómodo de leer para un programador. Recomiendo una pagina web antes que un documento de texto.
• Que sea facil de mantener. Importante. Se debe mantener y que sea facil hacerlo ya que si no es facil de mantener entonces se abandonara.