PSP poco a poco (parte 1)

Algunos programadores se oponen al cambio, les es dificil comprar alguna idea que al aplicarla les pueda consumir tiempo de codificación, aunque sea para mejorar la calidad de su código y ahorrar tiempo.

¿No le ha pasado que a la mitad de la construcción de un componente (sea una pantalla, función, proceso, etc.) tiene que reconstruir parte por haberse olvidado alguna funcionalidad o se acordó que ya lo habia hecho antes?

El Personal Software Process (PSP) nos permite a los programadores desde la etapa inicial, planear cómo se va a construir el componente asignado. Desde el inicio ya estamos invirtiendo tiempo para ahorrar más tiempo.

Le invito a que siga los siguientes pasos de mi propuesta para introducirse en este eficiente proceso de mejora personal.

Paso 1: Registre sus tiempos

Por lo mismo que es difícil integrar una metodología en nuestra jornada laboral, le sugieron que empiece por el hábito de registrar sus tiempos. Klok es una herramienta que le ayuda a llevar ese registro de manera atractiva y divertida. Sorpréndase de los tiempos que le consumen terminar un componente.

Procure poner Klok en pausa cuando haga otras actividades como contestar el teléfono o levantarse de su lugar.

Paso 2: Haga una estimación "Wild Guess"

Una vez que haya registrado por primera vez los tiempos de su componente, avance al siguiente escalón: Trate de adivinar cuanto tiempo le tomará la construcción de otro componente usando "suposiciones aventuradas". Como estamos iniciándonos en PSP si se vale, con la experiencia se dará cuenta que no. Haga su estimación en horas y registre el tiempo de construcción de su componente.

Paso 3: Compare su estimación con su registro

Como paso final (por ahora) compare las horas que supuso que se iba a tardar con las horas reales que le tomó construir. ¿Supuso más horas o se tomó mas tiempo del esperado en construirlo? 

Una vez que ha seguido estos pasos le invito a que se pregunte lo siguiente:

¿Como puedo ser mas exacto en mis estimaciones?

¿Cuantas líneas de código hice en ese tiempo?

¿Cuantas líneas de código haré en otra tecnología?

¿Bastante interesante no? En el siguiente post contestaremos estas preguntas.

Haz que las cosas sucedan

Al jefe hay que aprenderle, suena a cliche pero es tan obvio que a veces se nos olvida. Sea como sea, Usted puede aprenderle a su jefe ya sea sus aciertos, para aplicarlos en un futuro, o sus errores para evadirlos.

Tuve un jefe a quien admiro y aprecio por haberme enseñado varias cosas que hasta la fecha aplico al día a día.

Una de sus enseñanzas es tan sencilla como esto: "Haz que las cosas sucedan".

Suena sencillo, pero esas palabras exigen demasiado: dedicación, constancia, ánimo, fé, necedad, hasta puede que termine Usted cayendo "gordo" de tanta insistencia con tal de hacer que las cosas se den, pero no importa, la meta es que las cosas sucedan.

Enchulé a manera de 50 Cent la enseñanza de mi ex-jefe dejándola así: "Haz que las cosas sucedan or die trying" :)

Causas (y sospechosos) comunes

En mis 20 años de experiencia en proyectos de TI, he vivido "en carne propia" y sabido por colegas, de muchas situaciones que terminan comúnmente por retrasar el proyecto o hasta terminar la relación con el cliente.

Entre la gran variedad de causas, las más comunes han sido las siguientes:

• Algún ejecutivo de ventas hizo la estimación del esfuerzo, sin consultar a algún experto en las tecnologías involucradas.

• Involucrar al personal sin capacitación y/o sin experiencia, "ni están todos los que son, ni son todos los que están"

• El tiempo de las fases de análisis y diseño terminó consumiendo tiempo de la fase de construcción.

• Especificaciones funcionales mal hechas, incompletas, inentendibles, poco claras que ocasionan la participación directa de los arquitectos en la construcción.

• Mala administración de la configuración, se pierde código o documentos "por alguna razón desconocida".
  

Seguramente Usted lector ha vivido alguna de éstas, o varias en el peor de los casos, u algunas otras que quisiera compartir. 

El reto está en ingeniarnos las acciones que, personalmente, podamos realizar para que estos problemas no sucedan, y si suceden, que minimicen el impacto en el proyecto.

Si alguien le parece sospechoso, denúncielo :)