El tiempo es la condición basica de un proyecto de desarrollo de software. Es la moneda del proyecto. Se pueden tener infinidad de criterios a tener en cuenta: dinero, recursos, tecnologia, complejidad, etc... pero al final todo se traduce en tiempo
Es bastante dificil estimar cuanto se tardar en realizar un proyecto de desarrollo de software y es una de las tareas a las que se suele dedicar menos tiempo y se suele hacer de manera poco rigurosa (como se suele decir se levanta el dedo y como sople el viento pongo esto o esto otro).
Para poder cumplir con el tiempo de desarrollo del proyecto se debe hacer una planificación donde queden completamente claras las tareas que hay que realizar y las dependencias entre esas tareas. Esta planificación es la guia para todos los miembros del equipo y que los miembros del equipo usen esta guia es la condición basica para que se cumplan los plazos y con la calidad requerida.
Pero los miembros del equipo de un equipo de desarrollo de software no siguen nunca una planificación. Para un programador una planificación es un estorbo, no se ve la utilidad de seguir una planificación; es mas no ve la utilidad de tener que informar del estado global de su desarrollo. Esto ultimo es lo mas desconcertante ya que un programador informa antes de un problema tecnico que le bloquea su desarrollo (que es un problema de bajo nivel que por definición deberia solucionar el programador) que de un problema de dependencias con otros sistemas (que puede afecta al diseño) o del estado global (que afecta a la planificación).
Hay que hacer que los miembros del equipo se mentalicen con que hay que cumplir con la planificación y que hay que acostumbrarse a informar del estado de la tarea actual que estan desarrollando.
Pero tampoco hay que olvidar la contrapartida a que los miembros del equipo no usen la planificación y es que el tiempo asignado al desarrollo del proyecto de software es poco o muy justo. ¿Que pasa cuando el tiempo de desarrollo de software es poco o muy justo y hay que acometer el desarrollo?
En estos casos hay que intentar acometer el desarrollo de la mejor manera posible por lo que es seguro que la calidad del software se vera resentida. Alguna vez se ve tan resentida que el software es directamente no valido. Esta es la peor situción posible (y lo malo es que se cumple en la mayoria de los casos) ya que los criterios no estan claros y cuando las cosas no funcionan todo el mundo en el equipo de desarrollo de software cree tener razon y nadie parece tener la culpa de nada.
