archivo

Archivos Mensuales: julio 2013

Los principios de Peter o Dilbert nos dan una respuesta a cómo es posible que determinadas personas hayan llegado (y mantenido) a según qué puestos en sus organizaciones.

Otra respuesta la tenemos también en las condiciones que ha tenido el mercado hasta hace pocos años, en los que entraba suficientemente dinero como para que apenas importase lo que se hacía mal, en los que prácticamente sin esfuerzo, se conseguían unos resultados más que aceptables.

Esta situación dio lugar a una burbuja de gestores: muchos y con unos méritos más que dudosos.

Ya lo decía Deming: “Cualquier gestor puede hacerlo bien en un mercado en expansión”.

Ahora con el doble o el triple de esfuerzo, equivocándonos mucho menos, se puede optar, en la mayoría de los casos, a la mitad que antes.

La competencia es mucho más fuerte, quienes sobreviven son los que mejor se han conseguido adaptar, y todo eso en un contexto en el que aparece nueva competencia cuyas bases se encuentran ya adaptadas a la situación actual.

Anuncios

Se llega a este antipatrón por la creencia de que si se retrasa la entrega, se llegará a producción con un mayor número de funcionalidades y de más calidad.

Es posible que quien haga esta planteamiento lleve razón pero un retraso en la entrega debe sustentarse en bases más sólidas, ¿más solidas que esa? Sí, porque, ¿quién te dice que cuando termine ese mes no se va a hacer de nuevo el mismo planteamiento? y así sucesivamente, no se terminará de entregar el producto.

La búsqueda de la perfección en el desarrollo de software no suele dar buenos resultados porque llegado a un punto el esfuerzo necesario para producir una mejora crece exponencialmente respecto a la mejora conseguida, a eso súmale que se sigue trabajando sobre un producto que no está en producción y aunque tengamos versiones sobre las que se pueden hacer pruebas y obtener feedback, seguiremos trabajando con fogueo y no con fuego real por lo que lo mismo se está invirtiendo esfuerzo en evolucionar un producto que cuando se utilice realmente se deba orientar de otra manera.

No se trata de negarnos a retrasar una entrega, negarnos a eso de base sin analizar la situación es un error, sino de evitar que ese retraso sea consecuencia del miedo (lógico) que existe a dar el paso final de tener el producto (o una nueva versión del mismo) en producción.

Otra vez más, no será la última, vendrán muchas más, en la que he tenido que escuchar, que cómo es posible que tal proyecto esté en unas condiciones tan lamentables si se ha desarrollado siguiendo una determinada metodología ágil.

Todo eso teniendo en cuenta que se hace esa afirmación sin datos suficientes de si efectivamente se ha aplicado esa metodología, ciertas prácticas de la misma o algo totalmente distinto, pero que los desarrolladores o alguien de manera equivocada lo han llamado así. Tampoco sin tener en cuenta qué es lo que realmente ha fallado, si la metodología, el enfoque, la arquitectura, la tecnología, el equipo de desarrollo, los responsables funcionales, ¿algunos?, ¿todos?.

Ni Scrum, ni ninguna metodología asegura nada, son solo instrumentos. Tampoco es infalible ni es la mejor solución en todos los casos. Pero, ¿por qué tanto ruido cada vez que un proyecto desarrollado o supuestamente desarrollado siguiendo enfoques ágiles falla?, ¿por qué hay que estar pasando continuamente un examen?.

¿Por qué no pasa lo mismo con los fracasos tras fracasos de muchos proyectos realizados en cascada?.

Supongo que será por salirse de la norma, pero no considero los enfoques ágiles como un acto del rebeldía contra nada sino como otra forma de entender el desarrollo de software, que si ha terminado enfrentándose con los enfoques clásicos ha sido como consecuencia de la difícil convivencia de dos culturas diferentes, en la que hay extremos, pero muchos puntos intermedios, ya que la transición a la agilidad, en muchos casos ha sido paulatina, partiendo primero de un cambio de actitud y tras él la aplicación de determinadas prácticas de desarrollo o, al revés, si bien soy de la opinión de que para ser ágil hay que entender primero qué significa.

Yo vengo de los enfoques clásicos, de muchos proyectos desarrollados de esa manera, de una formación donde era la única alternativa que te enseñaban y he sentido lo que es trabajar de esa forma y los problemas derivados de la misma, por tanto, tengo criterio suficiente para saber que el desarrollo de software pide y necesita otros enfoques, sin que por ello se deba descartar su aplicación si realmente se determina que puede ser la solución más apropiada para un proyecto.

No me siento atado ya por las enfoques clásicos, tampoco lo estoy por los enfoques ágiles por mucha que sea mi atracción sobre ellos. Solo hay que sentirse atado por las necesidades del proyecto, siempre con una mente abierta para tratar de aplicar, equivocadamente o no, la opción que entendamos más válida.

Me parece muy acertada la siguiente reflexión de Watts Humphrey (traducción libre):

“Los cambios en los procesos de desarrollo de software se complican a menudo por el hecho de que no hay nadie responsable de que se lleven a cabo.

Si la mejora de los procesos de desarrollo de software no es el trabajo de nadie, no te extrañes de que no se consiga. Si es lo suficientemente importante, alguien debe tener asignada la responsabilidad ofreciéndole los recursos que sean necesarios.

Hasta ese momento, la mejora en los procesos de desarrollo de software seguirá siendo algo interesante que hacer algún día, pero no hoy”.

¡Cuántas horas de charla en reuniones e interminables hilos de correos electrónicos para nada!. Filosofando sobre qué está fallando y cómo podemos mejorarlo, discutiendo (incluso acaloradamente) sobre distintos puntos de vista porque cada uno ve el desarrollo de software desde su perspectiva, formación y experiencias.

La realidad es que las palabras se quedan en nada si no hay nadie dispuesto a asumir el peso del cambio y si no se le ofrecen los medios necesarios.

Y el cambio es un proceso continuo, no termina nunca si lo que se quiere es encontrar el camino de la mejora continua.

No basta con hacer una ruptura con respecto al modelo actual porque lo mismo la solución es equivocada y seguro que será mejorable, no debemos quedarnos ahí. El problema es que una vez alcanzada esta fase cuesta otra vez mucho trabajo volver a realizar cambios, de manera que en lugar de ser continuos se convierten en escalonados (si es que se consigue de nuevo tener voluntad para el cambio) y se reacciona, tal vez, demasiado tarde ante circunstancias que no son positivas en los procesos de desarrollo.

Supuestamente dentro de un proyecto de desarrollo de software todo el equipo tiene acceso al código que se está desarrollando y, por tanto, se podría considerar que existe una propiedad colectiva del mismo, sin embargo esa apreciación es más teórica que real, porque lo que suele suceder es que los desarrolladores pongan reparos en que otros toquen lo que han construido. Somos así, ¿qué le vamos a hacer?.

Considero un acierto por parte de XP que considere como práctica la propiedad colectiva del código, es decir, que se fomente que cualquiera pueda trabajar y mejorar con cualquier sección del código la hubieran desarrollado ellos o no. Y no lo comento solo por motivo de dar una mayor flexibilidad o disponibilidad al equipo, sino porque otro punto de vista generalmente suele ser positivo (por eso ese mismo enfoque de desarrollo tiene entre sus recomendaciones la programación por pares).

Para que este concepto se aplique de manera efectiva en un proyecto es fundamental el respeto. En el momento en que se pierden las formas por la solución en que una persona ha realizado un desarrollo, se empiezan a levantar muros. Y es que es fácil reirse o llevarse las manos a la cabeza por determinadas codificaciones pero realmente haríamos lo mismo si revisásemos código nuestro construido hace años (o tal vez no desde hace tanto tiempo).

También es importante no olvidar que se tiene que desarrollar con intención con propiedad colectiva o sin propiedad colectiva, es decir, no se trata de ponerme a retocar tal o cual funcionalidad o a refactorizar tal o cual clase o módulo, sin un propósito o poniendo en riesgo los compromisos que el equipo ha pactado para el sprint.

Hay una famosa cita que dice que: “una persona que dice que no se puede hacer, no debería interrumpir a la persona que lo está haciendo”.

Precisamente una de las causas que impide la evolución de muchas organizaciones (y de muchas personas) es esa, dar por sentado que no se puede y no dar ni siquiera la posibilidad a intentarlo pese a que, incluso fallando, se obtendrá en el proceso un aprendizaje importante, pese a que, incluso no existiendo otra posibilidad que la de progresar se cierran en banda a cambiar cualquiera de esos conocimientos y experiencias que se consideran leyes inmutables (tal vez lo fueron en su día, pero el mundo sigue dando vueltas).

Tan malo resulta lo anterior como poner todo tipo de resistencias a quien está tratando de conseguir ese objetivo aprovechando sobre todo los momentos de debilidad, cuando las cosas parecen peor dadas, y en donde parece que los acontecimientos quitan la razón a quien lo intenta y se lo da a quien no tardará en comentarte: “te lo dije“.

Y es que lo mismo variando el enfoque es posible encontrar caminos donde se piensa que no hay. Lo importante es progresar, evolucionar, adaptarse al cambio y para ello hay que tener una mentalidad más abierta para nosotros y para los demás y dar la posibilidad a que (dentro siempre de una coherencia) las personas se equivoquen.

Para sacar el máximo rendimiento a una sesión en la que se está trabajando con el product owner en la definición de historias de usuario o requisitos, lo mejor es centrarnos en unos temas concretos y que tanto él como nosotros no terminemos saturados con un exceso de información.

Si se tienen estudiados y trabajados con anterioridad a la sesión, mucho mejor, ya que se partirá con una base que permitirá ser mucho más efectivo, aún cuando se descarte la solución o soluciones que se hayan pensado. No se trata de acertar a la primera, se trata de ir trabajando en la definición.

El exceso de información es difícil de procesar durante y después (sobre todo cuando se trata de aspectos de negocio o técnicos que tienen una cierta complejidad) y aunque pueda permitir delimitar el alcance de una serie de historias de usuario, nos daremos cuenta después de que hay una gran cantidad de detalles que se nos han escapado y es en esos detalles donde se encuentra realmente la clave para cumplir o no las expectativas del usuario.

¿Dónde está el límite? Cuando ya llevas trabajando un tiempo con el product owner y con tu equipo, sabrás donde tienes que poner el listón.

También es importante tener en cuenta la frecuencia con que podemos reunirnos con el product owner. Si está poco accesible y el proyecto tiene un ritmo medio o alto, es normal y casi necesario que pese a que no sea la mejor solución, tratar de aprovechar las sesiones para obtener toda la materia prima posible.

Esta circunstancia no es deseable ya que el nivel de implicación del product owner debe ser alto y como poco debe ajustarse a lo que el proyecto necesita.

Otro aspecto a tener en cuenta es el nivel de madurez de las historias de usuario con la que estás trabajando.

Cuando se trabaja en un módulo o en un subsistema nuevo y no se sabe por dónde empezar (ni usuarios, ni nosotros), no es malo poner sobre la mesa, las ideas generales que se tienen del mismo y en sesiones posteriores tratar de ir profundizando en aspectos concretos.

Es importante partir de esa visión general, aunque se tarde más de lo que nos gustaría en tenerla, ya que sirve como esquema para usuarios y desarrolladores, de lo contrario se corre el riesgo de que empecemos a desarrollar demasiado pronto y cuando hayamos completado un buen número de historias, el usuario se de cuenta de que las piezas no encajan y que eso no es lo que quiere o cómo lo quiere.

No hace falta, no es necesario, no es ágil, la especificación detallada porque cuando empecemos a desarrollar surgirán inevitablemente cambios, pero tampoco es bueno empezar casi a ciegas.