5 razones para adoptar un proceso de Software

Durante mis años de programador cowboy se me quemaban las manos por empezar a generar líneas de código. Los requerimientos y el diseño los hacía "al vuelo": conforme iba programando iba diseñando la solución, a veces me acordaba que había código que ya habia hecho a la mitad de la construcción (que pudo haberme ahorrado tiempo), aplicando pruebas como no queriendo, etc.

Cuando apliqué costos ($) a mis defectos, olvidos y retrabajos, me di cuenta de todo lo que perdía tanto en tiempo como en dinero. Por eso me convencí de adoptar un proceso de Software en mi día a día y estos fueron algunos de mis motivos:

1. Para ahorrar de tiempo

Tener su propia base de código reusable, sus formatos y sus estadísticas le evitan costosísimo retrabajo, dándole tiempo para otras actividades personales.

2. Para ahorrar de dinero

El tiempo que se invierte en corregir defectos una vez entregado el componente construido es mucho mas caro que el tiempo invertido en etapas iniciales.

3. Para destacar en mi trabajo

Lo bien hecho siempre se nota, sale a flote, resultando hasta en promociones y aumentos de sueldo.

4. Por el compromiso de calidad con mi equipo y mis clientes

Siempre que se va un defecto a pruebas de integración o de sistema, todos los miembros del equipo tienen que estar al pendiente en la oficina o en las instalaciones del cliente. Esto origina desgaste del equipo y mala imagen ante el cliente a nivel personal o hasta de la consultoría.

5. Por el compromiso conmigo de mi mejora continua

Por el mismo sentimiento de ser mejor tanto en lo personal como en lo profesional.

Existen varios procesos de Software que podemos adoptar como PSP, RUP, AUP, o cualquier otro, lo importante es comprender los muchos beneficios de trabajar estructuradamente, como dejar de perder $.

Los defectos no son bugs

Muchos programadores cometemos errores, errores humanos que originan bugs y defectos en la construcción de nuestros componentes asignados. Y hay ingenieros que tratan los defectos como bugs: los bugs y los defectos no son lo mismo.

Los bugs son características del Software que no cumplen con la calidad requerida sin afectar el funcionamiento principal del sistema ni comprometer su estabilidad. Un ejemplo es un mensaje al usuario con faltas de ortografía o un color que rompe con el estándar de colores definido.

Los defectos son bombas de tiempo que pueden hasta costar vidas humanas, como en el caso del London Ambulance System. 

Los programadores debemos comprometernos con la calidad de nuestros productos. Estoy de acuerdo que es difícil tener cero defectos, mas bien nuestra meta debe ser hacer todo lo posible para lograrlo. 

Este compromiso nos hace mas productivos, se reconoce nuestra labor y nos da mayores satisfacciones.

PSP poco a poco (parte 2)

En el post anterior vimos como registrar el tiempo que nos lleva hacer un componente y a hacer suposiciones de nuestro esfuerzo necesario. 

Ahora continuemos con una variación al paso 1.

Paso 4: Registre su tiempo productivo real (tiempo Delta)

El tiempo que tomamos para hablar por teléfono, para tomarnos un break o para ir al banco son tiempos que no deben cargarse al tiempo de construcción del componente, ya que obtenemos que nos estamos tardando más de lo real. Este tiempo de interrupciones también lo vamos a registrar junto con sus causas, para darnos cuenta los motivos que nos pueden atrasar. Yo personalmente lo registro entre corchetes [ ].

Cuando separamos el tiempo de interrupciones obtenemos nuestro tiempo productivo real conocido como tiempo Delta. 

Seleccione un componente a desarrollar pero ahora cambiemos de herramienta y procure hacerlo con lineas de código nuevas, sin reusar, sin que sean generadas automaticamente.

Paso 5: Cuente sus líneas de código (LOC)

Si el componente que hizo tiene pocas líneas de código, puede contarlo manualmente pero sin contar los comentarios. Existen varias herramientas para contar código como Code Counter Pro o SourceFoge Code Counter.

El método para obtener las LOCs de un componente es más complejo, ya que depende si hubo LOCs reusadas, autogeneradas, modificadas, etc. En futuros posts veremos su cálculo a detalle.

Paso 6: Calcule su productividad inicial

Suponiendo que las LOCs fueron completamente nuevas, aplique la siguiente fórmula:

Productividad = LOCs / T

Donde LOCs es la suma de todas las líneas de código de su componente y T es el tiempo productivo real o Delta.

Por fin tenemos un factor inicial de productividad! Guarde este factor bajo la tecnología seleccionada y repita los pasos en otra tecnología. Más adelante compararemos nuestra productividad inicial con la que obtengamos aplicando PSP.

En el siguiente post veremos las fases de PSP que nos ayudan a desarrollar componentes con calidad, con ahorros de esfuerzo y presupuesto.

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 :)

¿Cuanto cuesta tener un "héroe"?

En una empresa “inmadura” donde trabajaba hace ya algunos años, compartíamos proyectos (y otras calamidades) con el “héroe”, aquel amigo quien jugaba el rol de “bombero apagando fuegos”. Cuando un proyecto iba mal, el líder era el primero en pedirles a los directores la presencia del “héroe” para recuperar lo perdido, a veces con éxito y a veces imposible.

Reinaba la paz y la felicidad en aquellos proyectos rescatados, hasta que llegaba el momento en que el equipo debía hacer la documentación para la entrega y se daba cuenta que el código estaba “hecho  con las patas” (sic). 

Cuando leías el código fuente del “héroe” podías encontrar nombres de variables que iban desde animales hasta objetos, tales como:

Dim goma as Integer

Dim goma2 as String

Además líneas de código sin identar, varias instrucciones en una sola línea, etc, etc. El costo de "maquillar" sus "apagones" eran al final del proyecto tan costosos como si lo hubiera hecho un programador novato.

Algunas veces un "héroe" puede incrementar el costo del proyecto silenciosamente y alguien al final lo termina pagando.