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.

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.

La innovación, el progreso y nuestra propia evolución personal y profesional solo son posibles desde el cambio. Puede ser disruptivo o más pausado y supone el abandono de un estado para pasar a una siguiente fase.

Precisamente la dificultad del cambio se encuentra en la necesidad de dejar de lado o reformular determinadas ideas y concepciones, así como aceptar que otras opciones son posibles.

Esto resulta muy complicado cuando se trata de conocimientos o experiencias adquiridas en tu etapa formativa o dentro de tu experiencia profesional, que además se encuentran consolidadas dentro de tu entorno, lo que las convierte prácticamente en un dogma.

En este contexto, toda idea que sugiera un cambio encontrará con la resistencia de ese entorno, ya que no entiende la necesidad de salirse de la ruta establecida y con nuestra propio temor por haber iniciado una línea de actuación diferente, un nuevo camino en el que tal vez, al principio, estemos solos.

Precisamente, uno de los principales problemas de la implantación de enfoques y estrategias ágiles en las organizaciones lo encontramos en la negativa a considerar nuevas alternativas al desarrollo de software que vayan más allá de las tradicionales y de los procedimientos que ya se encuentran establecidos, ya que al fin y al cabo, con más o menos éxito, con más o menos coste, con más o menos sacrificio, son las que se han aplicado hasta ahora y la organización sigue funcionando, de hecho ese será el principal argumento esgrimido tanto exteriormente como internamente (cuando lo estén analizando) por los principales detractores al cambio.

El británico John Maynard Keynes es considerado como uno de los mejores economistas de todos los tiempos y una de las personas más influyentes del siglo pasado. Sobre la dificultad que suponen los cambios realizó la siguiente reflexión: “La dificultad no consiste tanto en el desarrollo de nuevas ideas como en escapar de las antiguas”.

En el artículo de enero de 2001 en la revista IEEE Computer, que Barry Boehm y Victor R. Basili publicaron con el título: “Software Defect Reduction Top 10 List” y que ya mencioné en la entrada: “El impacto del esfuerzo evitable“, hay otra estimación que me pareció muy interesante: “Las prácticas personales disciplinadas pueden reducir la tasa de introducción de defectos en más de un 75%”.

Boehm y Basili en su artículo indican algunos datos empíricos en la aplicación de determinados tipos de metodologías como la PSP de Watts Humphrey, si bien lo importante no es realmente que el término medio sea un 75% o no, sino que todos sabemos en base a nuestra propia experiencia que si se siguen buenas prácticas y una cierta disciplina a la hora no solo de programar sino de probar lo que se desarrolla tanto a nivel de componente, de integración y de sistema el número de errores que se introducen es mucho menor, permitiendo además, detectarlos gran parte de ellos de forma temprana.

Pese a eso, sabemos que existe un mal endémico en los desarrolladores y es que “no se prueba” y eso no es siempre problema de actitud, sino más bien un problema cultural, algo que está ahí, que parece normal y que, sin embargo, provoca un sobrecoste en los proyectos, problemas en el entorno de producción, un desgaste en las relaciones con el usuario, etc…

Alguien resolutivo no es quien te codifica antes un determinado artefacto sino quién es capaz de hacerlo, dentro de un tiempo razonable con el menor número de defectos posible. Es preferible tardar más y hacer un trabajo limpio, que hacerlo en menos tiempo y después estar arreglando problemas mucho más tiempo que el que se entendió que se ganó por hacer el desarrollo tan deprisa.

El cambio de enfoque se puede hacer de manera progresiva, incluyendo esas buenas prácticas y controles de manera paulatina, de manera que las decisiones adoptadas se vayan ajustando a lo que el proyecto necesita. Conforme se vayan consolidando, se considerarán prácticas del trabajo diario, independientemente de que haya proyectos que, por sus condiciones especiales, requieran una mayor exhaustividad.

Sabemos que el desarrollo de software está sustentado por personas y que todo resulta mucho más sencillo (pero no por ello es necesariamente garantía de éxito) si la comunicación e interacción entre ellas es óptima.

No se trata solo de tener actitud sino que la misma esté fundamentada en el convencimiento de que el camino que se está tomando es el correcto o, lo que es lo mismo, que las ideas estén alineadas, independientemente de que se discrepe o haya matices en actuaciones puntuales.

La siguiente reflexión de Charles Eames muestra la clave: “Finalmente todo conecta – personas, ideas y objetos. La calidad de las conexión es la llave de la calidad”.

Cuando existe conexión, lo notas, lo sabes, el proyecto se beneficia de ello. Cuando no la hay, vas directo al precipicio. En medio, toda una gama de grises.

Mantener la conexión es muy difícil porque las personas somos complejas, cometemos errores, vemos las cosas de distinta manera y nuestro estado de ánimo depende de una infinidad de variables.

Si a nivel individual somos complejos, cuando hablamos de relaciones entre grupos de personas, la dificultad crece exponencialmente. Si a eso le sumas la presión del proyecto y/o de tus jefes, todo se hace más cuesta arriba.

Pero no es imposible, por lo que nuestro objetivo debe ser llegar y preservar esa situación de equilibrio porque todo es más fácil cuando hay entendimiento y se persigue un objetivo común.