lunes, 20 de abril de 2009

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 $.

jueves, 16 de abril de 2009

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.

domingo, 5 de abril de 2009

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.