archivo

Archivos Mensuales: enero 2013

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.

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í.

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.

Comenta Stephen Hawking que: “La inteligencia es la habilidad de adaptarse a los cambios”. Y es así, si no lo haces, estás abocado a no evolucionar, a esperar sentado a que otros (personas y circunstancias) decidan tu suerte.

Adaptarse al cambio requiere tener mentalidad abierta, no estar atado a prejuicios y contemplar más posibilidades que las que nos pueden parecer, a priori, más válidas.

En los proyectos de desarrollo de software trabajamos en un entorno de incertidumbre, en el que las condiciones cambian, en donde se pasan de situaciones supuestamente bajo control a otras que se nos escapan de las manos, en donde las que eran las mejores decisiones la semana pasada requieren ser revisadas.

Adaptarse al cambio no es improvisación sino entender la propia naturaleza del desarrollo de software. Ahora bien, la línea que la separa ambos conceptos es muy delgada, de ahí que sea una habilidad la adaptación al cambio, primero por la detección de la necesidad (y la inteligencia y el valor para darnos cuenta de que tenemos que actuar en consecuencia) y en segundo lugar porque todo se debe tratar de hacer con intención, no vale cualquier respuesta, la que tomemos, pese a estar equivocada, no debe basarse en un prueba y error, salvo que no seamos capaces de detectar que una de las opciones sea la mejor.

Este antipatrón surge cuando en una organización existen departamentos o grupos de trabajo que funcionan sin tener en cuenta la existencia de otros, provocando que no se puedan aprovechar sinergias, trabajos o estrategias y no solo eso, ya que cuando funcionan de esa forma pierden la visión de organización y de conjunto, entendiendo que sus fines son los únicos que existen, lo que puede afectar negativamente a los demás.

Es posible que el funcionamiento de esos departamentos sea óptimo en términos de colaboración y comunicación interna y que incluso tengan una relación fluida, correcta y eficiente con la dirección, pero al entender que sus objetivos son los más legítimos, prioritarios y valiosos no consideran necesario la colaboración con otros departamentos, salvo que sea (muy) estrictamente necesario.

El día a día nos hace egoistas y sentir que nuestros problemas son los más importantes. Si hay un grupo de personas que lo comparten, tienen los mismos objetivos y sienten que se tienen que centrar en ellos, olvidándose de todo lo demás y la organización lo permite, nos encontramos ante un caldo de cultivo ideal para este antipatrón.

Y sí, el principal culpable de que lleguemos a él es la propia organización que lo consiente y no solo en estos casos, sino en aquellos en los que directamente por su propio organigrama o división funcional han creado de serie las barreras o muros, sin prever o fomentar la necesidad de colaborar o comunicarse.

Es muy frecuente encontrarnos con personas no solo que no sean productivas sino que su productividad neta sea negativa. ¿Por qué negativa? Porque el daño que hacen a la producción es mayor que lo que aportan y esto no es solo provocado por lo que pueden estropear, eso es casi lo de menos, sino por el impacto que tienen en la productividad de los demás.

Este antipatrón surge cuando conociéndose ese problema no se hace nada al respecto, lo que es lo mismo que admitir que tu capacidad de producción tiene una resistencia que no vas a eliminar. Lo peor de todo esto es que esta resistencia generará nuevas resistencias (teoría de las ventanas rotas) porque la cultura del nunca pasa nada es de lo peor que le puede pasar a una organización.

No se trata de generar una cultura de miedo (que es totalmente negativa) sino una cultura de responsabilidad, que es algo totalmente diferente.

El principio de Dilbert como solución a este problema es una huida hacia adelante porque lo que haces es desplazar el problema, ya que aunque lo separes de la línea de producción y lo coloques en un puesto donde sea inocuo, el mensaje sigue estando ahí: “no importa lo mal que lo hagas, que incluso te recompensaremos con ello” y eso termina calando en la organización, hasta tal punto que termina convirtiéndose en parte de la cultura de la misma.

Guy Kawasaki, es en la actualidad director de una de las empresas de capital riesgo más importante de los Estados Unidos, es experto en marketing y en mercados tecnológicos y ha sido consejero de Apple.

Tan extendido está el antipatrón que Guy Kawasaki llegó a decir que: “Hay dos tipos de compañías, las que reconocen que son exactamente como la de Dilbert y las que también lo son pero aún no lo saben”.

Es cierto que hay muchas personas que consideran que es muy exagerado decir que estas malas prácticas están extendidas ya que son totalmente contrarias a una política racional de recursos humanos y de desarrollo de la carrera profesional, pero también son muchísimas las que consideran que es una práctica habitual. Todo dependerá de nuestras experiencias personales y de nuestra objetividad.