archivo

Archivos Mensuales: noviembre 2012

Cuanto más difícil es un reto, un problema o una tarea más satisfacción nos supone superarlo. Nuestra capacidad, nuestro esfuerzo, nuestra experiencia ya sea de manera individual o en compañía de otros ha sido capaz de superar lo que parecía infranqueable.

Es cuestión de tener voluntad y no rendirse. Contra lo imposible no se puede pero lo difícil sí que se puede luchar sabiendo que a veces ganaremos y otras perderemos.

En el desarrollo de software encontraremos proyectos de todos los sabores, unos serán más cómodos que otros. Unos que empezarán pareciendo simples se convertirán en pesadillas y otros que parecen complejos después pueden que no lo sean tanto.

Lo que sí tengo claro es que si se huye de la dificultad no la vas a superar, tal vez la evites un tiempo pero tarde o temprano te encontrarás con una situación en la que te hubiera resultado muy útil haber adquirido la experiencia en una circunstancia similar (hayas tenido éxito o no) y tengas éxito o no ahora.

Me parece muy interesante la siguiente reflexión de Dale Carnegie: “La mayoría de las cosas importantes del mundo han sido logradas por personas que lo han seguido intentando cuando parecía que no había esperanza”.

Se documenta muchas veces “por imperativo legal”, es decir, porque nos lo pide el cliente y/o porque nos lo piden nuestros propios procesos.

Hacer la documentación de esa manera, con tan poco cariño, no suele dar buenos resultados ya que se hace para cubrir el expediente y no se cuida que realmente sea útil.

Documentar por documentar no sirve de nada, documentar tiene sentido si aporta un valor.

Como os he comentado en diversas ocasiones vengo de una formación en enfoques clásicos y de trabajar en proyectos con metodologías clásicas en los cuales la documentación es el elemento común en todas las fases del proyecto. De la documentación generada solo suele ser útil una porción de la misma (se sobredocumenta para justificar que se cumplen con los hitos y por otro lado la calidad deja mucho que desear y eso que en los enfoques clásicos la documentación no es un elemento extraño sino que de convivir con ella se considera parte esencial del proyecto) y de ella gran parte de su valor se va perdiendo conforme se evoluciona el producto (si con la misma no se actualiza la documentación).

En enfoques clásicos la documentación como engranaje en las distintas etapas del desarrollo tiene su utilidad, sin embargo otra cosa bien distinta es que realmente sea la base sobre la cual se desarrolla porque incluso en este tipo de enfoques los requisitos y las especificaciones cambian en etapas tardías y estos cambios no se suelen llevar aparejadas actualizaciones en la documentación (suelen quedar recogidos en actas de reunión en el mejor de los casos). A esto hay que sumar lo comentado en el párrafo anterior en donde la orientación a cumplir el proceso suele dar lugar a una documentación cuya calidad no suele ser proporcional al esfuerzo puesto en ella.

Cuando es el propio proceso el que sobredocumenta el proyecto, el desarrollador realizará ese trabajo adicional sin ganas, sin cariño (como decía al principio) e impacta sobre la calidad de la documentación que podría tener utilidad.

La documentación tiene valor cuando encuentra un lector que encuentra utilidad en la misma. Eso es importante. Muchas veces se documenta para un lector futuro que nunca llegará o que cuando llega es tan tarde y la aplicación habrá cambiado tanto (o lo suficiente) que no se amortizará el esfuerzo de haberlo realizado.

La documentación es un instrumento, también se utiliza en las metodologías ágiles, de hecho las historias de usuario, las pilas de producto, etc… son documentación (en las que los procesos y/o los desarrolladores le dan la formalidad que estiman conveniente) por tanto su valor o no va más allá del enfoque del proyecto y está relacionado, como decía antes, con la utilidad real que tenga y su alcance y estrategias de actualización dependerán de las características del sistema que se desarrolla y del contexto del proyecto (y estará muy condicionada por el proceso o procesos de desarrollo si se establecen directrices relacionadas con la documentación).

La comunicación entre las personas es una herramienta muy potente que siempre ha estado ahí y que los procesos se han encargado de dejar en un segundo plano por la visión formalista que se le ha dado tradicionalmente a los mismos. Ese formalismo situó a la documentación como elemento que dinamiza el desarrollo (engranaje lo llame antes) cuando la dinamización debe ser cosa de las personas que intervienen en el proyecto. Si la documentación se convierte en una herramienta más y no en el centro del proyecto es posible (y así es efectivamente) que cada documento se centre exclusivamente en sus objetivos (prescindiendo de contenido de escaso valor para el lector) y que haya documentos (de trámite) que sean innecesarios.

Los que van quedando son los supervivientes. Ahora es lo que importante lo que pasó ayer ya es demasiado tarde.

Interesante reflexión de Jerry Weinberg: “Cada uno de nosotros, después de todo, es el descendiente directo de innumerables líneas de supervivientes”.

El negocio del desarrollo de software es así. Supervivencia en un entorno de gran competencia cada vez mejor preparada y que está deseando quedarse con tu trozo del pastel (en situaciones de crisis como la actual, el pastel mengua a la vez que la competencia crece.

En la supervivencia no vale todo porque determinadas victorias son tus derrotas de mañana. Una victoria donde dejas un profundo desgaste y descontento por el camino te da de comer hoy y te lo quita mañana. Es verdad que hay expertos en sobrevivir de esta manera pero no por ellos deben ser ejemplos de nada.

La supervivencia tiene gran parte de aguante y de saber adaptarse a las circunstancias, si no resistes, si no te adaptas lo normal es que termines perdiendo porque otros sí que resistirán y otros sí que conseguirán adaptarse con más o menos esfuerzo al nuevo contexto.

Para Leonardo: “La verdad era la única hija del tiempo”.

Es cierto que la verdad lo es o no pero también que muchas veces es el tiempo el que viene a demostrar si estábamos en lo cierto o nos estábamos equivocando.

Es importante tener presente que el resultado de nuestras decisiones no es algo que en muchos casos sabremos mañana sino que su impacto puede tardar incluso años en salir a a la luz. Y lo será tanto con nuestras propias decisiones como con las decisiones de los demás, nuestra realidad, nuestro contexto es como un campo en el que siembre se está sembrando, en el que hay buenas y malas cosechas y en el que hay semillas que germinan, otras que no y otras que, por error en su elección, dan lugar a cultivos que no queríamos.

Existe por tanto una incertidumbre, debiendo contar con ella y con la posibilidad que tenemos de rectificar si empezamos a darnos cuenta (y queremos darnos cuenta) de que nos hemos equivocado.

Un proyecto de desarrollo de software parte de una situación con muchas variables y en el que diversas personas toman decisiones antes, durante y después de su ejecución. Esas decisiones son propiciadas por la percepción que la persona tiene del proyecto en ese momento y por el contexto existente (modula la decisión). El producto es el resultado de esas decisiones y de la adecuada aplicación de las mismas y será el tiempo el que nos diga al final si se han satisfecho o no las expectativas que se tenían en la aplicación.

La incertidumbre será menor cuanto más próximos estemos a la entrega del producto (si es que en medio se han puesto los medios adecuados para reducir esa incertidumbre: enfoque evolutivo y feedback), no se trata por tanto de tirar la moneda al aire y esperar si sale cara o cruz, conforme vayamos avanzando en el proyecto tendremos nociones (cada vez más certeras) de si los resultados se van aproximando a lo que esperamos y esperan (los usuarios).

Pese a todo, es cierto que no es hasta el final (porque pueden pasar muchas cosas) cuando sabremos si hemos tenido éxito o no.

Como tu lo ves no es necesariamente como lo ve tu compañero de al lado por más que lo hayáis hablado, por más que estéis de acuerdo en muchas cosas, por más que el problema o la solución parezcan evidentes.

Es muy importante entender esto en un trabajo colaborativo en el que intervienen tantas personas como es el desarrollo de software y que precisamente por eso, es importante conocer las impresiones de los demás por que tal vez tu percepción no sea correcta ya sea porque te falta información o porque la interpretas de manera no adecuada (parcialmente o en su totalidad).

Es cierto que hay veces que las percepciones son totalmente divergentes pero por regla general son matices lo que diferencian unas de otras. Matices que lo mismo por separado resultan poca cosa pero que de manera conjunta sí que permiten obtener una visión más próxima realidad de la situación.

Sobre esto me parece interesante la siguiente cita de Louis Jon Bentley: “Un algoritmo diferente es el resultado de una visión diferente del problema”.

Leonardo realizó la siguiente reflexión: “La sabiduría es la hija de la experiencia”.

Estoy totalmente de acuerdo. El conocimiento se tiene que confrontar con la realidad, con la experiencia. Antes de eso solo es teoría.

¿Acaso pensamos lo mismo del desarrollo de software ahora que cuándo estábamos en nuestro período de formación?.

Lo que sabemos es el resultado de la experiencia y, por tanto, conforme vamos avanzando en nuevos trabajos, nuevos proyectos, nuevos retos, vamos incrementamos lo que sabemos como consecuencia de esos nuevos contextos en los que hemos aplicado nuestros conocimientos.

La experiencia no es lineal con el tiempo, el tiempo por sí mismo no genera experiencia, depende de lo que nosotros hagamos en ese tiempo, por ese motivo la experiencia no debe ser medida en años sino que debe ser contrastada con las actividades realizadas en los mismos.

Otros dos interesantes conceptos de Kanban son el Lead time y el Cycle time.

El primero se corresponde con el tiempo que existe entre que existe la petición de realizar una tarea y el momento en que la misma está terminada.

El segundo se corresponde con el tiempo que se tarda en realizar la tarea desde que esta empieza a procesarse.

Una tarea ha podido tener un Lead time de 200 días y un Cycle time de 2 días. Es importante tener en cuenta que el Cycle time no es lo mismo que el esfuerzo neto dedicado a la tarea ya que ha podido pasar que la misma haya quedado bloqueada un tiempo en alguna de las fases hasta que ha continuado con su tratamiento.

Como es lógico el Cycle time nunca puede ser mayor que el Lead time y el esfuerzo neto para realizar la tarea nunca puede ser mayor que el Cycle time (Lead time >= Cycle time >= Esfuerzo neto).

Veamos a continuación ambos conceptos no desde un punto de vista de una tarea sino desde el punto de vista del proceso completo (valores medios).

Cuando en Kanban hablamos de predecibilidad la podemos ver desde el punto de vista del Lead time y del Cycle time, si bien es en esta última donde realmente podemos tener una influencia directa para conseguirlo ya que se tiene ajustada (limitada) la cantidad de trabajo que se puede asumir con la capacidad del equipo, manteniéndose constante mientras la capacidad no aumente o disminuya.

El Lead time es la suma del tiempo de espera más el Cycle time. El tiempo de espera dependerá de la política que se defina para el tratamiento de las peticiones; si se quiere tener algún tipo de predecibilidad será necesario algún tipo de mecanismo de priorización que tenga en cuenta el tiempo que una tarea lleve en la cola de entrada al flujo de trabajo.