archivo

Archivos Mensuales: marzo 2013

Cuando la deuda técnica de un componente impide un desarrollo fluído ya sea porque se requiere un mayor esfuerzo y/o porque la posibilidad de que se produzcan efectos colaterales es muy alta o cuando el usuario advierte que el producto tiene alguna deficiencia funcional en un aspecto fundamental de su funcionamiento es el momento de plantearse el dar una solución a esos problemas antes de continuar con la evolución del producto.

Huir hacia adelante no suele funcionar bien en el desarrollo de software porque el problema no se elimina de esa forma y por el coste que tiene arrastrar con esa deuda técnica y/o esas deficiencias.

Desde mi punto de vista esa decisión no debe ser tomada unilateralmente por el desarrollador sino que debe ser consensuada con el responsable funcional, product owner o como queremos denominarlo porque es responsabilidad del mismo definir la línea de desarrollo del producto y, si vamos a realizar acciones que van a ralentizar la evolución del producto (a corto plazo), debe ser consciente de ello y autorizarlo.

Si la tarea de refactorización puede desarrollarse dentro de la iteración se consideraría como una tarea más de la misma y se ejecutaría sin más (avisar o no al product owner dependería de las políticas que, al respecto, se tuvieran definidas en el proyecto).

Anuncios

Si creemos que lo sabemos todo no vamos a evolucionar. Afortunadamente este mal tiene solución y tras cada batacazo que nos damos tenemos la oportunidad de recapacitar, si bien, para ello es necesario asumir que hemos sido parte del problema.

El conocimiento parte de cuestionar lo que creemos que sabemos, esto implicará analizar otras alternativas, aunque no te gusten, aunque pienses que no funcionan.

A veces las desecharás por completo, de otras cogerás una parte e incluso puede que alguna te lleve a un nuevo estado de iluminación en el que creas (de nuevo erróneamente) que vuelves a saberlo todo.

Analizar otras alternativas, escuchar a personas que ponen en tela de juicio tu forma de actuar o tu proyecto no es sencillo porque ellos pueden que no estén en primera línea y tu sí, porque tu eres el que se lleva los “golpes” cuando algo no va bien. Sin embargo, viene bien escuchar porque lo mismo tu día a día te impide ver cosas que desde fuera se aprecian más claramente.

Si es importante escuchar a personas de fuera, todavía lo es más con aquellas que trabajan contigo. Valora que te indiquen otras alternativas y valora que no estén de acuerdo contigo porque seguro que de esas situaciones se extrae conocimiento para una parte, para la otra o para ambas.

Siempre es posible desarrollar un software aplicando las mismas técnicas de gestión que para construir un puente, sin embargo estaríamos prescindiendo de una de sus principales características, su maleabilidad, lo que le permite adaptarse al cambio y modificar criterios con un coste asumible (siempre y cuando se tenga la deuda técnica bajo control).

Cuando tienes un puente a medio construir, tomar la decisión de poner un carril más en cada dirección puede ser prácticamente imposible o requerir una inversión muy superior a la que hubiera sido necesaria si se hubiera tenido en cuenta desde el principio.

En el desarrollo de software no es así. Es cierto que el cambio tiene un coste pero no es equiparable al de las construcciones físicas.

Renunciamos a la maleabilidad del software cuando lo importante es el cumplimiento de una agenda, es decir, se prioriza mantener previsiones de costes y plazos sobre la posibilidad de entregar un producto con mayor valor. Hay que analizar cada circunstancia y es posible que no haya otra alternativa que cumplir con la agenda: no es posible dedicar mayor presupuesto al proyecto y/o modificar los plazos, siempre y cuando se entienda que no es posible la cuadratura del círculo: cumplir agendas y tener al producto sometido a continuos cambios de criterio.

Mi apuesta es incrementar el valor del producto que se pone en producción y eso requiere un enfoque iterativo incremental para aprovechar el feedback del usuario. Esto tiene implicaciones presupuestarias que se solucionarían bien teniendo abierto el presupuesto del proyecto o si está cerrado centrarse en que las funcionalidades prioritarias vayan bien (esto último siempre y cuando no nos encontremos en una situación de Death March Project en la cual todo será mucho más complicado).

Yamamoto Tsunetomo fue un conocido samurai en la segunda mitad del S.XVII y las dos primeras décadas del S.XVIII. En su retiro, un joven samurai llamado Tashiro Tsuramoto transcribió las conversaciones que tuvo con él, dando lugar al Hagakure, en el que se describe por primera vez el código guerrero de los samurai.

Une reflexión sobre la intención que aparece en ese libro es la siguiente: “Si uno lanza sin vigor, siete de cada diez acciones no llegan a término”.

Me habéis leído escribir muchas veces sobre la intención, como el deseo real convertido en acciones fundamentadas que pretenden conseguir un objetivo. El fundamento de la acción viene dado por un análisis objetivo de la misma, tratando de reducir en lo posible actuaciones basadas en el prueba y error o sin suficiente conocimiento como para esperar que se obtengan los resultados esperados.

Precisamente es una de las causas principales de que un desarrollo iterativo incremental no sea efectivo, dando lugar a más iteraciones de las necesarias y a un mayor coste que si no se puede asumir puede dar lugar a que el proyecto fracase.

No se trata de tener toda la información, de tener completa seguridad de que la decisión que se toma es la correcta, porque pocas veces vamos a encontrarnos con esa situación de partida o tras un trabajo más o menos elaborado, sino de entender que tenemos más posibilidades de acertar si se han realizado las tareas y acciones oportunas que permitan elegir el camino más adecuado.

Ese es el desarrollo de la intención, antes hay que querer alcanzar el objetivo y estar dispuesto a invertir el esfuerzo que sea necesario, precisamente muchas de las decisiones que se toman en el transcurso de una reunión se quedan en nada, solo en palabras, debido a que parece que la energía se queda en la mesa una vez que todos (o por lo menos, los que tienen que desarrollar las acciones) se levantan de la mesa.

Uno de los problemas que nos podemos encontrar con frecuencia en un proyecto de desarrollo de software lo tenemos cuando el desarrollador piensa que sabe tanto del negocio como los usuarios y se olvida de que el producto no es para él sino para los usuarios.

Que un desarrollador conozca el negocio muy bien es algo muy interesante para el proyecto siempre y cuando no se caiga en el error de empezar a tomar decisiones sobre lo que le gustaría a él que hiciera el producto sin contar con la aprobación del usuario.

Siempre hay que contar con los usuarios. Un producto desarrollado a sus espaldas difícilmente se ajustará a sus necesidades reales. Generalmente cuando esto sucede es por culpa del área usuaria que se niega a dedicar al proyecto los recursos que son necesarios, dejando todo el peso a los desarrolladores. Esta situación es necesario revertirla cuanto antes y en caso contrario intentar cerrar el proyecto con el menor daño posible entre las partes, si bien, no siempre será posible una cosa o la otra porque el nivel de toma de decisiones al respecto se situará en otra escala de la organización que tendrán sus propias políticas y criterios.

Si contamos con la ayuda y dedicación del usuario y sin embargo tomamos decisiones funcionales por él, estamos cometiendo un grave error.

Al respecto me parece interesante la siguiente reflexión de Donald Norman: “Los diseñadores no son usuarios típicos. Llegan a ser tan expertos en el uso de los objetos que se han diseñado que no pueden creer que alguien más pueda tener problemas. Sólo la interacción y pruebas con usuarios reales en todo el proceso de diseño puede evitar eso”.

Un desarrollador de alto nivel en el rol que desempeña es capaz de rendir exponencialmente mejor que otro que no tenga sus conocimientos, experiencia y brillantez.

Cuando se trata de proyectos donde el equipo es muy reducido unas buenas individualidades pueden compensar un mal funcionamiento colectivo.

Cuando el equipo es más numeroso no vale solo con tener buenas individualidades sino que debe funcionar como tal, no se trata del no aprovechar el talento sino optimizarlo como parte del talento colectivo de manera que la suma de todo el conjunto supere a la suma de las individualidades.

Un héroe puede salvarte una vez, dos, tres veces…, tal vez incluso pueda salvar el proyecto pero no es el camino, a medio y largo plazo serán muchos los proyectos que fracasen mientras esperan que el héroe vuelva a hacer un imposible.

Hay mucho trabajo que hacer en el proyecto y cada cual se tiene que encargar de lo suyo sin olvidar que forman parte de un equipo por lo que debe existir comunicación e interacción con los demás y estar siempre a disposición del equipo para echar una mano donde haga falta. Si cada cual hace la guerra por su cuenta está creando una resistencia para el resto de sus compañeros, los cuales verán mermada su eficacia.

Bob Martin realiza la siguiente reflexión: “Un equipo de desarrolladores medios que se comunican bien tienen más probabilidades de tener éxito que un grupo de superestrellas que fallan al interactuar como equipo”.

Muchos proyectos fracasan porque no se consigue formar ese equipo (dentro de los desarrolladores) y en extensión cuando no se consigue formar un equipo con el resto de implicados en el proyecto.

Es muy importante construir ese equipo y eso no se consigue simplemente juntando una serie de personas. Muchos gestores olvidan eso y piensan que todas las combinaciones pueden ser válidas y no es así. Dentro de las opciones existentes hay que procurar conformar la mejor, a partir de ahí, con un buen equipo, se tendrá una buena base para luchar por el éxito en el proyecto.

Una vez elegida una buena combinación toca consolidar el equipo y mantenerlo que es lo más difícil teniendo en cuenta el desgaste existente en un proyecto de desarrollo de software sobre todo en circunstancias de presión, algo que por desgracia ocurre casi siempre.

Procesos o interacción entre personas, enfoque clásico, enfoque ágil. Dos mundos, que no son incompatibles salvo que uno no se quiera uno mover de los extremos, algo que desde luego y desde el punto de vista del agilista no sería nada ágil.

Ya sabéis cuál es mi punto de vista en el desarrollo de software y que vengo del mundo de los procesos. Ser un converso no me impide ver que los procesos tienen que existir como background al proceso de desarrollo y que puede haber casos donde sea necesario que su presencia sea mayor.

Lo que no puedo entender y no es la ceguera del converso es que se siga pensando en los procesos como la única solución a los problemas del desarrollo de software, como si las personas fuéramos algo secundario. Es cierto que en su momento supusieron un primer avance cuando se pasó de los desarrollos heróicos a un enfoque más organizado pero una vez subido ese primer peldaño no consiguió superar el siguiente que es mejorar la situación (o erradicarla) que provocaba la crisis del software.

Es cierto, como decía antes, que los procesos pueden producir buenos resultados en ciertos contextos, pero siempre será necesario que el factor humano funcione porque como comentan Roy Miller y Christopher Collins: “Ningún proceso es lo suficientemente completo como para que sus usuarios puedan apagar el cerebro”.