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.
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.
jueves, 16 de abril de 2009
Los defectos no son bugs
domingo, 5 de abril de 2009
PSP poco a poco (parte 2)
jueves, 19 de marzo de 2009
PSP poco a poco (parte 1)
martes, 10 de marzo de 2009
Haz que las cosas sucedan
lunes, 2 de marzo de 2009
Causas (y sospechosos) comunes
- 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".
martes, 24 de febrero de 2009
¿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.
jueves, 19 de febrero de 2009
De árboles y PSP
Al final de la clase, salías con 3 o 4 kilos de papel, del cual sólo 2 hojas era tu programa y lo demás era candidato para irse al boiler, a la jaula de tu mascota o al periodiquero.
Había hojas que sólo se imprimían indicando que te faltaba una coma, un paréntesis ó que no habías declarado una variable, entre otros defectos.
El Personal Software Process es un marco de trabajo que te ayuda a hacer componentes de Software de manera disciplinada, con fases que van desde planear qué y cómo lo vas a hacer hasta tu compromiso personal con tu mejora contínua. Para nuestro caso, hay una fase donde revisas tu código antes de compilar.
Si tan sólo PSP hubiera nacido antes, muchos árboles se hubieran salvado.
miércoles, 18 de febrero de 2009
Técnica salvaje de estimación
Esta semana leí un post en un blog que habla sobre una técnica de estimación que seguramente se sigue usando, sobre todo en situaciones donde algún líder de proyecto novato o desesperado (o amenazado!) tiene que dar aproximados del esfuerzo necesario en la elaboración de requerimientos de parte de su equipo.
Esta técnica conocida como Wild Guesses o "suposiciones aventuradas" (por intentar darle una traducción al español) trata de preguntarle a tu gurú de confianza "como cuanto le calculas?" esperando que te responda personas y tiempo requeridos.
Me acuerdo de aquellos tiempos cuando el jefe se acercaba y te lo preguntaba, y en un gesto de amabilidad y reprocidad por el halago (de reconocerte como experto) le contestabas "pues como 2 personas 3 meses", frase que después se volvería entre cliché y estándar para responder a esas situaciones.
Sin darte cuenta estabas iniciando tu sentencia de muerte, ya que después no era ni el número de personas ni el tiempo suficiente, y como siempre hay un culpable en las empresas inmaduras (o "hechas un desmadre" por intentar darle una traducción al mexicano), pues el candidato a la hoguera era quien dió la estimación.
Desde entonces uno aprende a no dar ese tipo de respuestas sin exigir el tiempo necesario para realizar una estimación formal, documentada, sustentada,con varios colegas, como debe de ser, respondiendo "no sé" cuando ya te rompen la paciencia de tanto "bueno, pero como cuanto le echas?".
De vuelta al blog que leí, mi sugerencia fué que si se llega al grado extremo de tener que hacer una estimación así, se haga aplicando Wide-Band Delphi: preguntale por lo menos a 3 y calcula una media. El autor del post me respondió: "mejor solo uno por que no distraigo a varios del equipo". Pero sigue siendo demasiado riesgoso.
Tal vez que los distraigas 15 minutos te pueden salvar de la hoguera.