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.

lunes, 8 de abril de 2013

¿Quieres ser más productivo?... recuerda afilar la sierra (I)

En tiempos de "vacas gordas" las organizaciones tienden a sobredimensionarse. Los ingresos van como un tiro y la cuenta de resultados no se ve demasiado afectada por los gastos... necesitamos capacidad productiva que nos permita obtener más ingresos aunque esta capacidad productiva resulte cara o ineficiente...da igual, los ingresos están garantizados, los márgenes son grandes, las comisiones jugosas, todo el mundo está contento... ¿por qué preocuparse? En España ocurrió de forma exagerada en el sector de la construcción por lo que gran parte de una generación abandonó las aulas para incorporarse a un mercado laboral que ofrecía sueldos significativamente superiores que a titulados universitarios... El sector IT, por supuesto, también se subió al carro... había un tiempo en que "recién licenciado + 1 año de experiencia en el lenguaje X" era una pieza cotizada en el mercado laboral... y si me apuras... lo de "recién licenciado" era opcional...

El sueño se acabó, primero en nuestro sector cuando "descubrimos" (con el pinchazo de las punto-com) que la nueva economía no tenía nuevas reglas... que no existía fórmula secreta para evitar los ciclos económicos y que la cuenta de resultados tarde o temprano debe abandonar el rojo. Posteriormente se acabó el sueño para todos... de nuevo al "descubrir" que no existe ninguna regla económica que obligue al precio de la vivienda a crecer eternamente (tesis defendidas por reconocidas publicaciones de color salmón) e incluso pueden bajar.

Ahora los ingresos son moderados (por decir algo...), las tarifas se tiran por los suelos hasta el punto que en ocasiones da la sensación de que se ganan proyectos por el mero hecho de tener a la gente ocupada... En este contexto (ciñéndonos de nuevo a nuestro sector IT) parece tener mayor sentido lo que comentábamos en  ¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean. El término Lean Software Development  se acuñó en 1992,  ufff... en aquella época España estaba a punto de iniciar su "milagro español" como para preocuparnos de eficiencias, mejoras continuas y eliminación de desperdicios...¿verdad? Lo nuestro era el "dame más madera"...

Sin embargo, ahora resulta imprescindible preocuparnos de estos temas porque debemos mejorar nuestra productividad y de ahí que me viene a la memoria el libro de Stephen Covey, Los 7 hábitos de la gente altamente efectiva [1] que descubrí años atrás gracias a un proceso más que recomendable de Coaching. Los hábitos descritos por Covey son interesantes para cualquier situación pero vienen al pelo en épocas en que necesitamos que tanto nosotros individualmente como los equipos y organizaciones de los que formamos parte seamos los más productivos posibles.

Covey realiza la siguiente clasificación de los 7 hábitos:

PARTE PRIVADA
  • Primer hábito: Se proactivo
  • Segundo hábito: Empieza con un fin en mente
  • Tercer hábito: Establece primero lo primero
PARTE PÚBLICA
  • Cuarto hábito: Piensa en ganar/ganar
  • Quinto hábito: Procura primero comprender y después ser comprendido
  • Sexto hábito: La sinergia
RENOVACIÓN
  • Séptimo hábito: Afila la sierra.
Aunque sea empezar la casa por el tejado únicamente me centraré en el último porque es el que hace posible al resto y además es más que suficiente (creo) para que puedas intuir qué hay detrás y si te interesa o no profundizar en el tema. Covey nos introduce el séptimo hábito a través la parábola del leñador y de ahí coge su nombre. Un visitante inesperado en medio del bosque se encuentra con un leñador:

—¿Qué está usted haciendo?
—¿No lo ve? Estoy cortando este árbol.
—¡Se le ve exhausto! ¿Cuánto tiempo hace que trabaja?
—Más de cinco horas, y estoy molido. Esto no es sencillo.
—¿Por qué no hace una pausa durante unos minutos y afila la sierra? Estoy seguro de que cortaría mucho más rápido.
—No tengo tiempo para afilar la sierra. Estoy demasiado ocupado aserrando.

Si sustituimos al leñador por España, al visitante por Alemania y recordamos nuestra filosofía de "más madera" durante el "milagro español"...creo que la parábola resume perfectamente nuestra situación. Lo malo es que, hasta el momento, las propuestas desde los diferentes gobiernos que nos intentan sacar de esta situación es básicamente la bajada de salarios y de beneficios sociales, con lo que se supone ganaremos la ansiada mejora de productividad... pero me temo que de afilar la sierra se habla poco. Curioso porque otros países como Estados Unidos o Inglaterra están considerando necesario incluir la tecnología y la programación como materia básica en las escuelas... hasta Obama hizo mención de ello en su último Discurso de la Nación.

Como no tenemos demasiada capacidad de decisión en esos niveles al menos intentemos desde el nuestro hacer todo lo posible por afilar la sierra. Tal vez tus decisiones sólo te afecten a ti (esta será tu mejor inversión) o a tu departamento o a tu empresa...pero la suma de cada pequeña mejora es lo que hace cambios importantes.

Detrás de afilar la sierra está por supuesto la formación, pero hay mucho más, como la administración eficiente de nuestro tiempo, aunque va más allá que el hecho de utilizar este o aquel método de planificación que aunque es necesario se queda muy en la superficie. Afilar la sierra te va a resultará más costoso que aplicar un método de gestión personal del tiempo,... de hecho considera que ya has trabajado en los seis principios anteriores y se enfoca en trabajar sobre las cuatro dimensiones de nuestra naturaleza: la física, la espiritual, la mental y la social/emocional. En el próximo post comentaremos cómo de relacionadas están estas cuatro dimensiones y qué hay detrás de cada una de ellas.


Referencias:
Stephen R. Covey, (2005). Los 7 Hábitos de la Gente Altamente Efectiva: La Revolucion Etica en la Vida Cotidiana y en la Empresa, Ediciones Paidos Ibérica.