Medir

Medir es una actividad muy-bien-vista por los altos directivos de muchas organizaciones. Ni hablar cuan alentada es si el resultado de la medición es expuesto utilizando un montón de amontonados y diminutos numeritos representados por extravagantes gráficos.

La primera distinción que se me ocurre respecto este punto está asociada a diferenciar datos de información. Wikipedia define a información como un conjunto organizado de datos procesados, que constituyen un mensaje que cambia el estado de conocimiento del sujeto o sistema que recibe dicho mensaje. Personalmente, los datos descriptos en el párrafo anterior no generan en mi ninguna de estas cosas.

Luego, ¿Cual es la estrategia que debiera poner en práctica para que sea posible presentar información en lugar de datos?  Una primera respuesta podría desprenderse de revisar algunas definiciones básicas del universo de las métricas.

• -      Atributo: Característica mensurable. Por ejemplo el tamaño del sistema o su calidad.
• -      Medida: Asignación de un valor resultante de una medición a un atributo. Para el atributo tamaño del sistema las posibles medidas podrían ser 5.754 líneas de código, 213 páginas de especificación o 659 horas de desarrollo. Para el atributo calidad de un sistema una posible medida podría ser 27 bugs identificados, 177 casos de prueba ejecutados o 879 horas de testing.
• -     Métrica: Referencia cuantitativa del modo en que un objeto de medición posee un atributo dado.  Siguiendo con los ejemplos anteriores, la métrica para evaluar la calidad de un sistema podría ser  cantidad de bugs por líneas de código.
• -    Indicador: Es la interpretación de la métrica. Se construye en función del interés del observador. Por ejemplo, un indicador podría ser nivel de calidad de un sistema que pueda tomar lo los valores: muy buena, buena, media y nula (valores que se definen en en función de la interpretación del resultado de la métrica).

Las métricas e indicadores proveen un alto nivel de visibilidad sobre procesos, proyectos y productos. En particular, si lo que se pretende es exposición de información, el indicador es, sin dudas, la estrella protagónica.

Entonces… usar indicadores resulta una herramienta –muy potente- para presentar información sobre el estado de procesos, proyectos y productos. De ahí a las acciones que se tomen en función de los resultados obtenidos, es un tema muy-mucho-mas-difícil que no faltará oportunidad de discutir en futuros posts.

Ciclo de Deming

También conocido como PDCA (Plan.Do.Check.Act) el ciclo de Deming puede definirse como el circuito canónico para la mejora de procesos. Luego, si lo que se desea es proyectarse hacia el universo en donde mejora continua está a la orden del día, la ejecución sistemática de los cuatro pasos de este ciclo constituye una herramienta poderosa para cumplir ese objetivo.

Los cuatro pasos:

• Plan: Planificación del proceso. En esta etapa se deben definir los objetivos y la estrategia para cumplirlos. También se confecciona la lista de actividades a realizar y los tiempos asignados para éstas.
• Do: Llevar a cabo el proceso.  Es muy importante tener visibilidad sobre la ejecución (cómo resulta la experiencia de seguir el plan y cuales son los desvíos identificados, entre otras posibles observaciones)
• Check: Verificar el proceso. Una vez finalizada su ejecución, es necesario realizar la evaluación del mismo;  comparar los resultados esperados con los obtenidos e identificar oportunidades de mejora.
• Act: Adaptar el proceso en función del conocimiento adquirido en los pasos anteriores.

Para aquellos que tengan intención de reconsiderar sus procesos apuntando a  una próspera mejora continua para el año que viene, tal vez poner en práctica las sugerencias propuestas por el ciclo de Deming no sea una mala idea. Éxitos -en cualquiera las formas que los deseen- y feliz, muy feliz 2011!

Administración del tiempo

Insustituible, inexorable, indispensable, inelástico y equitativo. No es posible comprarlo, acumularlo, reemplazarlo ni por supuesto, dejar de consumirlo. Estamos hablando de tiempo, claro.

El  universo de tópicos relacionados con la gestión del tiempo es realmente grande. Asociado a las actividades de calidad, hay un tema en particular que se caracteriza por presentarse una y otra vez: la desmesurada asignación de prioridad a lo urgente sobre lo importante. En general, las impunes cuestiones urgentes siempre, pero siempre –con esa intempestividad que las caracteriza- irrumpen sobre las inofensivas, bondadosas y fructíferas actividades de calidad, tan importantes que son.

Una solución concreta y efectiva que previene la fuga de la tortuga que encamina los temas importantes, es comprometer –COMPROMETER- algunas horas (del día, de la semana o del mes) a realizar actividades asociadas a los temas importantes sin dejarse avasallar por las urgencias que imprevisiblemente surgen. Aunque suene fácil, es todo un desafío poder mantener esta práctica a lo largo del tiempo.

Pero las irrespetuosas cuestiones urgentes no se llevan solas todas las medallas. Hay –muchos, muchos- otros  factores que interfieren con la adecuada administración del tiempo; entre ellos podemos distinguir la  procrastinación, la parálisis por análisis y las reuniones no-efectivas entre otros muchos ladrones del tiempo.

Una estrategia sugerida por los ágiles es conocida con el nombre de Time boxing, la cual está fundamentada en una ley conocida como la Ley de Parkinson que dice que  ”el trabajo se expande hasta llenar el tiempo disponible para que se termine”. Está relacionada con evitar extender los tiempos inicialmente definidos para realizar actividades. Es decir, una vez cumplido el tiempo asignado para una actividad, ésta debe darse por finalizada esté o no completa. Este tipo de práctica ayuda a entrenar a los integrantes de un equipo en realizar las actividades en el tiempo definido para estas.

El video  ”Deadline” -en formato stop motion con post-it- ilustra varias de estas cuestiones.

Juegos para aprender

Juegos Para aprender es el nombre de un encuentro al que asistí hace un tiempo, organizado por Ágiles@BsAs en modalidad Open Space.

Dos de los juegos para aprender me resultaron particularmente interesantes; uno presentado por Fernando Claverino -amigo, coach para el desarrollo de este blog y ferviente impulsor de las metodologías ágiles- y otro por Claudio Juan Bidau. El primero consistió en una experiencia de dibujo de a pares conocido como Pair drwaing, y el segundo fue una actividad de diseño, construcción y trabajo en equipo bautizada  el  desafío del marshmallow.

Haciendo Pair drwaing es posible identificar con claridad los beneficios del trabajo de a pares:

• -      Entusiasmo: Trabajar en parejas es más divertido y da mayor seguridad a las partes
• -      Aprendizaje: Trabajar en parejas es una forma amena de compartir conocimientos
• -      Cohesión de equipo: La gente se familiariza más rápidamente con la actividad
• -      Visión unificada: Cuando las actividades de un proyecto se realizan en parejas, y las parejas se rotan con frecuencia, las buenas prácticas se van “mezclado” y pasan a formar parte del conocimiento común

El desafío del  marshmallow permite identificar con claridad los típicos errores de diseño (aplicables perfectamente al proceso de desarrollo de software) al proponer la competencia -en equipos- de construir la torre más alta en 18 minutos (utilizando fideos crudos, cinta adhesiva, un piolín, y la estrella: el marshmallow). El desafío consiste en construir la torre más alta, que tenga el marshmallow en la punta superior. Una experiencia realmente divertida que ilustra con claridad cuanta facilidad tenemos para cometer errores.

El próximo encuentro de Ágiles@BsAs es el  Miércoles 15 -este miércoles-  y el tema es Story mapping: un enfoque visual a la construcción del product backlog.

Visibilidad

La falta de visibilidad sobre los proyectos de una organización podría considerarse un escenario equivalente a no disponer de iluminación para inspeccionar como se está cocinando el Volcán de Chocolate en el interior del horno.

En el contexto de desarrollo de software, es posible dirigir la visiblidad sobre un proyecto en tres sentidos; hacia el cliente, hacia la organización y hacia los miembros del equipo.

Planteados los distintos destinatarios, es común que se presentarse una pequeña pero no por eso poco importante dicotomía:

Las prácticas de Scrum están fuertemente alineadas con la primera de las opciones, defendiendo la transparencia sobre estado del proyecto. Por otro lado, la segunda de las opciones tiene sus incuestionables beneficios, pero se le asocia la desventaja de tener que sumar a la inversión de esfuerzo que requiere generar los informes, el trabajo de adaptarlos.

Las métricas automáticas proveen una solución cuantitativa concreta para obtener clara visiblidad sobre variables significativas de un proyecto…  Pero claro, una solución tan maravillosa no puede menos que ser cara, difícil de mantener y requerir mucha disciplina por parte todos los miembros del proyecto…

Una práctica que maximiza la relación costo beneficio en este plano es realizar reuniones de avance periódicas. En dichos encuentros es posible presentar el estado del proyecto, los desvíos respecto a la planificación y la lista de riesgos.  Adicionalmente, reuniones complementarias a las de avance, como el kickoff y el postmortem (o restrospective -como le dicen los ágiles-) también proveen un montón de visibilidad sobre los proyectos y los procesos de la organización.

Como conclusión,  podríamos decir que resulta central para la salud de nuestros proyectos que los involucrados puedan advertir con claridad el estado actual, hacia donde se dirigen, y cuán bien -o mal- encaminados están. Y en definitiva, lo que cueste esta práctica siempre va a ser un precio menor al costo asociado a que los involucrados en un proyecto no sepan en donde están ni hacia donde  van.

Enseñando ágilmente

Enseñando ágilmente es un trabajo que llevamos adelante con Fernando Waisman -Amigo, Colega y compañero de aventuras- en la Cátedra de Calidad de Software de la Carrera de Analistas Sistemas de Computación del Instituto de Tecnología ORT.

La propuesta plantea un cambio al modelo docente tradicional -la clase magistral- aumentando el nivel de compromiso y participación de los alumnos. La idea se basa en otorgar a quienes participan en las clases un mayor protagonismo en la definición de los contenidos de la materia. Este cambio se asocia principalmente en la incorporación de algunas de las prácticas propuestas por el conocido y siempre bien ponderado marco de gestión Scrum.

El trabajo fue presentado en la 39 jaiio y la versión completa del paper se encuentra disponible en http://www.39jaiio.org.ar/sites/default/files/39jaiio-asse-03.pdf.

El cultivo de las buenas prácticas

Se dice que la confianza se construye durante años y se derrumba en un instante… Con el ejercicio de las buenas prácticas, sucede algo parecido.

Una buena práctica es aquella que de alguna manera, en alguno de los planos posibles, contribuye con la mejora…  lo cual no necesariamente significa que tenga que estar definida en un modelo de madurez o en un marco de desarrollo de gestión de proyectos (ni la recíproca, es decir,  una práctica propuesta por los distintos modelos no tiene por que ser útil para toda organización) El arte: tener la sensibilidad para identificar, en un contexto determinado,  las que sirven de las que no…

En el marco del desarrollo de software, resulta muy difícil implementar actividades que favorezcan el proceso de mejora (y esa es la parte fácil). El real desafío -archiReContraSuperDifficile- es mantenerlas. Desde mi percepción, algunas de las razones por las que el ejercicio de las buenas prácticas se va disipando están relacionadas con:

• -      Si no son adecuadamente implementadas, pueden convertirse en actividades exclusivamente burocráticas
• -      El retorno de la inversión del tiempo invertido no es claramente perceptible (y mucho  menos en el corto plazo)
• -      En algunas organizaciones está implantada la idea que se puede ser ágil (dinámico, pro, canchero, alineado con las metodologías de moda) ignorando la metodología tradicional…  sin implementar tampoco prácticas de las metodologías ágiles!

Entonces… ¿Cuáles son las posibles acciones que se pueden tomar para evitar que las buenas prácticas se vayan diluyendo?

• -      Elegir, en primer lugar, el subconjunto de actividades con el mayor retorno de inversión, y hacer foco en logar institucionalizarlas
• -      Institucionalizarlas implica: Capacitar, coachear, seguir, controlar, evaluar, adaptar…
• -      Identificar con claridad el beneficio para cada una de las personas que participan en la implementación de las distintas prácticas, y comunicárselos…

Y como dice Antón Pirulero… Que cada cual atienda su juego… y en particular cada organización, sus buenas prácticas!

Repostería y desarrollo de software

La receta para preparar un rico volcán de chocolate, es la siguiente:
Ingredientes: 200 g de chocolate, 40 g de manteca, 4 yemas, 50 g de azúcar, 2 claras. Preparación: Derretir el chocolate con la manteca por un lado, batir las claras a punto nieve (con la pisca de sal) por otro y batir las yemas con el azúcar a punto blanco. Luego mezclar claras con las yemas y finalmente integrar el chocolate. En moldes enmatecados llevar 10 minutos al horno.

Si la calidad del volcán se gestionara con criterios equivalentes a los que se utilizan para desarrollar software…

• -      No hubiéramos validado que los huevos estuviesen en buen estado
• -      El equipo que prepara las claras hubiera pensado que el azúcar se lo ponía el equipo que preparaba las yemas, y el de las yemas, que el azúcar era responsabilidad del otro grupo.
• -      Batir a blanco las yemas lo hubiéramos considerado un improvement y lo hubiéramos postergado para otra iteración.
• -      Las claras a nieve las prepararíamos en la licuadora
• -      Nos daríamos cuenta que es necesario sacar el  volcán del horno al empezar a  sentir el olor a quemado

Una vez  listo el volcán, al probarlo consideraríamos bugs

• -     Que tiene un dejo de gusto a rancio
• -     Que le falta azúcar
• -     Que se quemó un poco

Para resolverlo…

• -     Le rasparíamos los sectores quemados
• -     Lo espolvorearíamos con azúcar impalpable
• -     Y le agregaríamos dulce de leche para disimular el sabor rancio del huevo en mal estado.

El desafío de este blog es arrojar algo de claridad sobre el universo de posibilidades que nos permitirán mejorar la forma en que desarrollamos software.