jueves, 17 de octubre de 2013

Repitamos juntos: No bañaré en oro mis proyectos.

"Bañar en oro" los proyectos es una importante fuente de problemas y sin embargo dicha práctica se viene repitiendo y repitiendo como piedra en la que caemos continuamente. Está en nuestra naturaleza, lo de caer varias veces en la misma piedra, por tanto tal vez sea conveniente repetirlo como un mantra todas las mañanas.

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

lunes, 16 de septiembre de 2013

KANBAN: Cuaderno de Bitácora tras 9 meses de viaje

Cuando leí “From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department” de David J. Anderson y Dragos Dumitriu sobre la aplicación de Kanban en un equipo de mantenimiento de software encontré una gran analogía con las características de un grupo de desarrollo en mi último cliente. En ese momento decidí (después de profundizar en el método) utilizar esta aproximación para la dirección de dicho equipo.



lunes, 26 de agosto de 2013

Estimación Relativa por un niño de 9 años

La estimación relativa nos permite valorar el esfuerzo que nos supondrá llevar a cabo un determinado trabajo utilizando de unidad de medida otro trabajo que nos resulte familiar. En lugar de utilizar las métricas de horas, días u hombre/mes, cuando llevamos a cabo una estimación relativa utilizamos un valor que aproxime el tamaño de dicho trabajo. Existen diferentes formas de definir este valor: puede ser numérico (conocido como Puntos) o utilizando el tamaño de las tallas de camisetas (conocido como "T-Shirt Sizing"). En general nos resulta más sencillo clasificar las tareas comparándolas con otras que ya hemos realizado en lugar de estimar el número de horas o jornadas (no digamos cuando saltamos a la dimensión hombre/mes).

Este verano he podido comprobar su facilidad de aplicación en un entorno muy diferente al desarrollo del software con mi hijo de 9 años. Os resumo la experiencia:

lunes, 22 de julio de 2013

La "vieja" práctica de inspección de código ¿sigue manteniendo el tipo?

Todos hemos escuchado/leído las bondades de esta práctica y la mejora substancial en la calidad y mantenibilidad de nuestro código...entonces...¿por qué es tan poco utilizada? Tal vez yo he tenido muy mala suerte... pero pocas veces la he visto claramente integrada en un proceso de desarrollo.

Las inspecciones de código tienen como principal objetivo mejorar la estructura del código fuente, no descubrir bugs (de hecho inspeccionamos los fuentes no los vemos en ejecución) por lo que el hecho de incorporar una fase de revisión en el proceso de desarrollo no implica que puedas evitar la fase de testing. Tal vez este sea uno de los motivos por lo que no es tan utilizada: los tiempos de desarrollo se alargan... no podemos dedicar ese tiempo extra en nuestros proyectos... la calidad es cara y no podemos pormitírnosla (el cliente no la pide, no la paga,... no la tiene), además ya vamos tarde... como para encima dedicarnos a revisar código.... Hasta que alguien plantea una solución intermedia ¿Y que tal si hacemos un manual de estilo y lo sigue todo el mundo? Y ahí acaba todo, en las 100 o 200 hojas de manual de estilo que nadie suele leer.

¿Te suena la escena?

miércoles, 17 de julio de 2013

Kanban: Las 8 metas "realistas" que puedes alcanzar

Antes de afrontar un proyecto o llevar a cabo un cambio importante en cualquier ámbito de nuestra vida es importante plantearnos por qué nos interesa afrontarlo, qué esperamos conseguir, personal o profesionalmente, tras realizar el cambio.

Este mismo razonamiento debes realizar si estás planteándote cambiar la forma de trabajo de tu departamento de desarrollo para adoptar alguna práctica ágil. Definir qué pretendes obtener en su aplicación es de vital importancia puesto que una u otra práctica tienen "prescripciones" diferentes y por tanto te llevarán a distintas metas.

En este post repasaremos las metas que David J. Anderson en [1] "promete" que podemos alcanzar a través de la aplicación del método Kanban a nuestro proceso de desarrollo de software. Mi opinión personal, después de su aplicación en equipos de desarrollo, es que sí son metas realistas. Probablemente ninguna de estas metas debieran ser fuerzas motrices de tu cambio, pero estarás de acuerdo conmigo que no te hará ningún daño alcanzarlas.