Desarrollo de software. Antipatrón. Garantía sin garantía

Un error muy frecuente es no prever un nivel de servicio en la garantía. Esto es muy problemático principalmente en los enfoques en cascada donde todo se juega a una carta, ya que por mucho testing que se haga, sabemos que habrá incidencias que lleguen a producción, muchas de las cuales no se detectarán hasta que el producto se esté utilizando de manera efectiva, algo que no ocurre necesariamente tras el paso a producción.

Al proveedor hay que entenderle ya que tras cerrarse el objeto de contrato necesita volver a asignar tareas facturables a los componentes del equipo de proyecto. También hay que entender al cliente que querrá que esas incidencias se corrijan en un tiempo razonable, ya que algunas de ellas podrían afectar a las funcionalidades más críticas del sistema.

Lo que suele pasar es que el proveedor se hará cargo de sus responsabilidades contractuales (no sin protestar o sin poner trabas en algún caso) pero los tiempos de respuesta no serán, generalmente, buenos, porque dedicará pocas personas a este trabajo, las cuales a su vez estarán asignadas a otro proyecto o proyectos.

Peter Drucker. Mejor arriesgarse

No se trata de saltar al vacío, no se trata de perder la cabeza. A veces hay que arriesgar porque no siempre contamos a priori con todas las respuestas.

La adaptación al cambio tiene riesgos porque sueles introducirte en terreno desconocido, tienes que tomar decisiones para pasar de una situación que controlas o que has empezado a controlar a otra totalmente nueva.

Se asociar error a riesgo y es algo comprensible, pero también nos equivocamos muchas veces por esperar demasiado o por mantener una posición dentro de nuestra zona de seguridad. Y probablemente si lo ponemos en la balanza tengamos más o menos nivelados nuestros errores por actuar como por no hacerlo.

Ya lo dice Peter Drucker: «Las personas que no toman riesgos suelen hacer sobre dos grandes errores al año. Las personas que hacen correr riesgos suelen hacer sobre dos grandes errores al año».

La diferencia entre arriesgar o no es que en el primer caso lo haces con intención y en el segundo eres sujeto pasivo esperando a que el problema pase o que se encargue otro de él.

Desarrollo de software. Antipatrón. Parálisis por tamaño o complejidad

Este antipatrón surge cuando no se consigue poner remedio a esa sensación de bloqueo que tenemos cuando nos encontramos ante nosotros con una carga de trabajo de gran magnitud y/o ante un problema de gran complejidad, sabiendo además que nuestros recursos son limitados y que nos espera mucho esfuerzo, tiempo y hacer las cosas muy bien para superarlo.

Esa montaña se nos hace todavía más grande de lo que es y no por el hecho de evitarla va a terminar desapareciendo, es más, resulta probable que el problema siga creciendo a la par de que dispongamos menos tiempo o medios para hacerle frente.

Esa sensación nos las encontramos con frecuencia en los proyectos de desarrollo de software y la única manera de que no se termine convirtiendo en antipatrón y nos traiga todos sus inconvenientes, es empezar a trabajar en la solución, ya que de esa forma, poco a poco, el muro se hará más pequeño.

Es curioso, lo sabemos y sin embargo seguimos sintiéndonos bloqueados por esa situación, no obstante de la misma forma que otras veces hemos encontrado el camino (con más o menos éxito), lo volveremos a encontrar si dejamos de mirar hacia el obstáculo y de autocompadecernos.

Desarrollo de software. Antipatrón. Espíritu de Dunkerque

El concepto de espíritu de Dunkerque surge como consecuencia del esfuerzo realizado en mayo de 1940 por ciudadanos británicos en conjunción con sus fuerzas armadas para la evacuación del grueso de las tropas aliadas en la 2ª Guerra Mundial, como consecuencia del empuje de las fuerzas alemanas y el riesgo de quedar arrasadas ante la imposibilidad de defensa u otras vías de escape.

Se considera que el esfuerzo y el riesgo de unos pocos, implicados directamente o no en la guerra, permitió salvar a muchos.

Por tanto, ese concepto se utiliza para representar un espíritu de unión ante una situación adversa o complicada.

¿Cómo puede considerarse algo así un antipatrón y cómo se relaciona con el desarrollo de software?.

Existen proyectos que se consiguen salvar o que llegan a tener éxito gracias al esfuerzo de unas cuantas personas, generalmente las que están en el día a día, pese a que las condiciones de partida se encontraban próximas a un Death March Project y/o el conjunto de toma de decisiones hacían todo mucho más difícil.

Este antipatrón surge cuando tras la realización de ese esfuerzo (con ese espíritu de Dunkerque), esa mala negociación inicial, esa mala venta o esas decisiones tomadas de forma negligente quedan ocultas o minimizadas, con el riesgo de que en el siguiente proyecto pueda volver a pasar lo mismo, si el responsable o los responsables no han aprendido nada de lo sucedido.

Además, cómo no ha pasado nada, el mérito del equipo no será tenido en cuenta de manera adecuada, pudiendo pasar, como sucede muchas veces que el mérito se lo lleve quién o quiénes provocaron la situación de partida o han provocado resistencias en el proyecto.

No es cuestión de quién se lleve las medallas, sino de ser justo. Probablemente si el equipo siente que no ha existido justicia será mucho más complicado que el espíritu de Dunkerque vuelva a aparecer.

Te preguntarás, ¿qué se hace entonces?, ¿se deja fracasar el proyecto para que esos problemas salgan a la luz? No. El equipo de proyecto ha actuado como debe, sacando adelante un proyecto en unas condiciones muy complicadas. Es un problema de carácter organizativo ya que los responsables o jefes de quiénes han provocado esta situación, no han llegado a darse cuenta del problema, ya sea porque no han dedicado la suficiente atención, lo han seguido desde demasiado lejos o han realizado una gestión basada en números. O peor aún, siendo conscientes de la situación, no han hecho nada.

¿Y si vuelve a ocurrir?, ¿qué hacemos? Yo no soy partidario de bajar los brazos, mi opinión es que el equipo debe seguir trabajando de la mejor manera posible, si no lo hace, se convierte en cómplice y creo que eso no sería justo con el equipo. Si bien, entiendo perfectamente que la motivación y como consecuencia, la productividad baje, porque somos humanos y estas cosas nos afectan.

Desarrollo de software. Antipatrón. Pensamiento de grupo

Una buena actitud para un gestor es contribuir a la creación de un ambiente en el que las decisiones se tomen por consenso, entre otras cosas porque de esta manera, se tienen en cuenta más puntos de vista, más opiniones, más experiencias, lo que hace que la probabilidad de acierto sea mayor y que las personas estén más comprometidas, porque se sienten parte y responsables de la solución.

Es importante tener en cuenta que actuando de esta manera no se reparte la responsabilidad, ya que la misma sigue siendo de la persona que tiene la última palabra (y que cobra por ello). La excepción la tendríamos en órganos colegiados donde la decisión se hace bien por consensos o por mayorías.

Este buena práctica se convierte en antipatrón en el momento que se producen alguna de las siguientes circunstancias:

– Se quiere hacer copartícipe de la responsabilidad a otras personas por si la decisión que se toma no ha sido la más adecuada. Es decir, la búsqueda del consenso se hace como mecanismo de defensa, pensando en uno mismo y no pensando en los beneficios reales que tiene para el proyecto. Esto termina degenerando, generalmente, en que solo se termina recurriendo al consenso en situaciones que pueden ser conflictivas en el caso de que salgan mal y pasando de él en el resto de los casos.

– Cuando incluso con la mejor de las intenciones, se trata de someter a consenso decisiones de carácter operativo, provocando un bloqueo en el día a día del proyecto, invirtiendo esfuerzo innecesario por parte de terceras personas que pudiera ser mejor aprovechado en las tareas u objetivos que tienen encomendado.

– Cuando teniendo que tomar una decisión en ese momento, no se toma (siendo esta la peor solución), por no haberse conseguido un consenso entre las personas implicadas.

Peter Drucker. Los superhéroes no son la solución

Si una organización o un proyecto sobrevive por la extraordinaria capacidad de algunos individuos, nos encontramos ante una situación poco sostenible: En el momento en que esas personas se vayan, bajen el nivel o dejen de funcionar sus estrategias, todas las debilidades quedan expuestas y como no tienes mecanismos de defensa, se va a tardar en reaccionar, a veces tanto que lo mismo ya no hay solución o las pérdidas económicas son enormes.

Para Peter Drucker: «Ninguna institución puede sobrevivir si necesita genios o superhombres para su gestión. Deben organizarse de tal manera que puedan ser gestionadas adecuadamente por seres humanos medios».

Claro que el talento es importante y decisivo y que cuanto más talento tengas mejor. No se trata de evitarlo, sino de diversificar los pilares que sostienen a la organización. Se trata de minimizar el impacto en el caso de que esas personas decisivas dejen, por el motivo que sea, de serlo.

Desarrollo de software. Antipatrón. Shotgun surgery

Este antipatrón surge como consecuencia de múltiples cambios en una aplicación que se llevan a cabo de forma simultánea en el mismo, de manera que es posible que se haya aplicado la misma solución en diferentes partes del código, de manera que tendremos clases y/o métodos con un comportamiento parecido aunque tengan codificación diferente.

También es posible que se haya llegado a él, no por el hecho de no poder controlar la programación de personas distintas en diversas funcionalidades de la aplicación, sino por la mala práctica de ir copiando secciones de código, realizando las modificaciones oportunas, achacándolo a las prisas y a la presión por la entrega y/o por terceros.

Como consecuencia tenemos un código más complejo, con más deuda técnica y, por tanto, con un mayor esfuerzo de evolución y mantenimiento (hay que tener en cuenta que es posible que con estas prácticas, para hacer un cambio sea necesario hacer modificaciones en tantos puntos como ese código haya sido replicado).

Desarrollo de software. Antipatrón. Modelo en avalancha

La definición clásica de este antipatrón es que es el resultado de una mala combinación entre el modelo en cascada y las prácticas ágiles y que como consecuencia de ello, el proyecto termina en una espiral de falta de control y coherencia en los desarrollos, esfuerzo malgastado, alta deuda técnica y en un más que probable fracaso.

¿Dónde empieza el problema? Todavía se piensa en el desarrollo en cascada, se conocen algunos de sus inconvenientes y se tratan de resolver aplicando determinadas prácticas ágiles a modo de parches y sin entender muy bien las consecuencias. Es decir, se quiere dar un salto a la agilidad sin haber terminado de comprender bien sus valores y principios.

La evolución natural hacia esquemas menos rígidos pasa por ir realizando una división en fases del proyecto (se reduce el alcance del objeto de trabajo y se puede aprovechar el conocimiento de la fase anterior como entrada para las siguientes) como una primera aproximación a un ciclo de vida iterativo incremental.

Una mala práctica que termina en avalancha consiste en no entender o no organizar de manera adecuada la iteración (teniendo en cuenta que serán más pesadas a nivel de proceso, ya que todavía se sigue orientando a entregables documentales), comenzando unas sin tener cerradas otras, solapando alcances entre iteraciones de varios equipos que están trabajando en el proyecto, comenzar una iteración de manera sistemática sin tener la materia prima (requisitos o historias de usuario) preparadas, acumular versiones entregadas pero que todavía no se han podido pasar a producción, multiplicación de entornos, etc…

Y todo ello manteniendo viejas costumbres (no achacables a los enfoques clásicos y sí a las formas tradicionales de trabajar), como la falta de comunicación entre todos los implicados, la gestión desde la distancia, la falta de flexibilidad, papeles secundarios o inexistentes para el feedback, las retrospectivas y la refactorización, etc…

Esa situación lleva al caos, porque si no se pone remedio (y cuesta hacerlo cuando ya se ha entrado en esa inercia), el problema será cada vez más grave.

Desarrollo de software. El propósito como motor

Uno de los problemas de que a los desarrolladores se les trate como ganado es que de esta forma es muy complicado que vean un propósito que les sirva como elemento motivador en su día a día. De esta forma solo ven tareas, una tras otra y nada más.

Un desarrollador puede ser productivo de esa manera, pero será menos consistente y más irregular, y tendrá que ser bastante fuerte para no dejarse vencer por la tentación de convertirse en un cumplidor o todavía peor en alguien que aparente cumplir (muchos más frecuentes estos últimos).

El desarrollo de software produce mucho desgaste porque los problemas no se terminan cuando sales de la puerta del trabajo sino que te lo llevas en tu cabeza y tardan en desaparecer (si es que lo hacen). Si detrás de esto no hay algo que te motive, te terminas convirtiendo en un robot.

El propósito no se toma en pastillas, ni se construye con cuatro gestos bien intencionados o de cara a la galería. El propósito es creer en un proyecto (es algo más amplio que un proyecto concreto de desarrollo de software), en una forma de hacer las cosas, en sentir de verdad que tu trabajo hace mejor y te hace mejor. Además debe alimentarse de un trato justo por parte de la organización porque de lo contrario se pierde equilibrio.

El problema de todo esto es que muchos gestores piensan que con el salario ya se ha conseguido todo y no es así.

Diferencia entre el ciclo de vida iterativo y el ciclo de vida iterativo incremental

En un ciclo de vida iterativo (o en un enfoque iterativo), se trabaja sobre un conjunto de funcionalidades y se perfeccionan, sin incluir nuevas funcionalidades.

En el ciclo de vida iterativo incremental se van añadiendo funcionalidades.

En el enfoque iterativo existe feedback, se pueden realizar retrospectivas, pero se trabaja sobre componentes, subsistemas o productos completos.

Se puede considerar que el enfoque iterativo podría ser una siguiente fase a la cascada: «tengo una primera versión del producto, vamos a mejorarlo».

Es un modelo eminentemente teórico porque incluso en modelos que prevén unos requisitos (posteriores funcionalidades) estables, como el clásico, hay variaciones sobre las especificaciones iniciales.