archivo

Archivo de la etiqueta: antipatrón

Todas las medidas que supongan un obstáculo a la comunicación entre los componentes de un equipo de trabajo o entre equipos de trabajo diferentes suponen una resistencia importante al proyecto de desarrollo de software.

Se pueden establecer ciertas reglas orientadas a conseguir un mayor orden y una comunicación más eficiente pero es necesario evitar todas aquellas que creen entre personas y equipos que den lugar a que la comunicación sea mayoritariamente asíncrona (cuando no prácticamente inexistente) provocando un distanciamiento entre los equipos (no se trata de un hecho físico ya que pueden estar distanciados equipos que incluso trabajan en la misma sala), la aparición de antipatrones como: “Arrojar al otro lado del muro y que las funcionalidades se desarrollen o las decisiones se tomen sin contar con toda la información disponible lo que dará lugar a unos mayores costes debido al más que probable incremento del número de iteraciones necesarias para tener el producto.

A veces la comunicación se deteriora por conflictos entre personas o entre equipos que provocan que como medida de autodefensa se pongan como un escudo que dificulta o impide la comunicación. Por el bien del proyecto y de las personas que participan en él este tipo de situaciones hay que atajarlas cuanto antes y no dejarlas ir porque cuando se entra en enfrentamientos personales los mismos no terminan por arte de magia cuando acaba el proyecto.

También los gestores cuando no tienen una visión global tienen mucha que ver con el aislamiento de los equipos de trabajo.

Frederick Brooks en su libro “The Mythical Man Month” comenta lo siguiente: “Entonces, ¿cómo se comunicarán los equipos unos con otros? De tantas formas como sea posible”.

Una objetivo fundamental de un jefe o gestor de proyectos, Scrum Master o cualquiera que sea el nombre que queramos darle, es la de tratar de conseguir un contexto lo más estable posible que permita que todas las partes involucradas en el proyecto desempeñen su función de la manera más eficiente posible.

Además del trabajo sobre el contexto que va más sobre líneas generales del proyecto: relación de confianza, gestión adecuada de expectativas, del valor ganado y de la inversión realizada hasta el momento, etc…, en el día a día del proyecto existen contingencias que pueden afectar al rendimiento del equipo de proyecto y que conviene solucionar cuanto antes para que el impacto sobre la productividad y los resultados sea el menor posible.

Está claro que un facilitador eficiente hace mucho bien al proyecto, parece un trabajo fácil pero no lo es en absoluto porque tiene mucho de inteligencia emocional, ya que para resolver esos problemas del día a día o para tratar de mantener un equilibrio en el proyecto se requiere mucha interacción y comunicación con otras personas que probablemente tengan unas prioridades y objetivos diferentes a los del equipo de proyecto.

Cuando el facilitador lo hace bien, las personas que trabajan con él tienden a despreocuparse de la resolución de determinadas contingencias que perfectamente podrían resolver ellos y/o el propio facilitador con el objetivo de que el equipo esté centrado en su trabajo decide asumir que toda la intendencia del proyecto pase por él.

Esto puede llegar a convertirse en un antipatrón por varios motivos: el facilitador se puede terminar convirtiendo en un cuello de botella, si el facilitador por el motivo que sea no puede dedicar tanto tiempo al proyecto se necesitará que los desarrolladores den un paso al frente para resolver estos problemas y/o para tratar de que el equipo siga gestionándose de manera adecuada pudiendo darse el caso de que no se encuentren preparados para realizar esas tareas o no las consideren de la suficiente importancia, degradándose paulatinamente el rendimiento y productividad del equipo impactando directamente en los resultados.

Cuando trabajamos desde una actitud ágil aplicando prácticas, estrategias o metodologías ágiles, tendemos a centrarnos en el incremento del valor del producto, sin olvidarnos de tener una deuda técnica sostenible, mientras solemos dejar de lado algunas tareas de gestión que llegado el momento nos pueden ahorrar algún problema.

Partamos de la base de que la agilidad funciona en un marco de trabajo en el que existe confianza entre las partes, cuanto mayor sea la separación entre las personas y los equipos más dominará la metodología y la burocracia y menos la agilidad (antipatrónarrojar al otro lado del muro“), sin embargo a veces en los proyectos intervienen factores externos que terminan por afectar a su desarrollo normal produciéndose problemas.

Por ejemplo, una de las partes cambia sensiblemente su posición en el proyecto exigiendo alcances o incrementos de presupuesto, siendo la situación del proyecto tal que no es posible alcanzar un acuerdo sin que alguna de las partes ceda de manera considerable.

En esos momentos, por muy buena voluntad que sigamos teniendo los que estamos en las trincheras tanto por parte del cliente y del proveedor, el partido se suele jugar en otras instancias, las cuales empiezan a solicitar a los equipos evidencias para tratar de utilizarlas en el proceso de negociación (o confrontación), evidencias que no irán más allá en muchos casos que el contenido de la pila de producto o de los sprints, lo que será insuficiente y luego se empezarán a pedir explicaciones por determinados tipos de acuerdos verbales que no se han registrado por escrito.

¿Cuál es la solución? Puedes optar por aplicar una táctica defensiva en todos los proyectos o realizar ajustes en función del mismo. La táctica defensiva consiste en tratar de registrar documentalmente todos los acuerdos parciales en el proyecto sin salirnos de la línea base del acuerdo inicial, esto puede servir como coraza (aunque quien quiera liarla, la liará con esto y sin esto).

Una táctica que considero más adecuada al desarrollo ágil consiste en analizar realmente qué tipo de proyecto estamos realizando, qué exigencias tiene nuestra organización y cuál es nuestra experiencia con el proveedor o con el cliente y a partir de ahí tomar tus propias decisiones sobre qué debe tener evidencia documental y que no (además de estas evidencias la propia metodología o procesos de las organizaciones pueden imponer otras, que tendrás que seguir quieras o no).

Si las normativas, procedimientos o procesos de desarrollo de software de tu organización no cambian o lo hacen en contadas ocasiones y en aspectos de poca trascendencia querrá decir, probablemente, que nos encontramos con alguna de las siguientes circunstancias:

1) Se ha descubierto un “martillo de oro” que permite que todos los desarrollos de la organización se realicen de la forma más efectiva posible independientemente de las características propias de cada proyecto.

2) No existe ningún tipo de intención y/o política de mejora continua y no por el hecho de que se haya encontrado esa llave que abre todas las puertas, sino porque se ha creado una cierta zona de seguridad sin analizar si realmente la misma aporta o no un valor a la altura de la inversión que hay que realizar en la misma tanto para su aseguramiento como para su aplicación (sobre todo).

Aunque pueda parecer sorprendente, cuando la normativa no cambia es porque hay un poco de ambas, por un lado se cree que se ha alcanzado una solución óptima para el contexto (es importante eso porque, muchas veces, cuando se analizan cambios, la defensa del inmovilismo se centrará en que las innovaciones no son válidas para el entorno de trabajo o la naturaleza de la organización) y por otro, el proceso está tan consolidado (que no es equivalente a obtener resultados) que apetece poco hacer cambios.

Ante estas circunstancias, podemos sospechar y lo más probable es que no nos equivoquemos es que unos procesos que no cambian se convierten con el paso del tiempo en obstáculos cada vez mayores porque los proyectos sí que viven en primera instancia la incertidumbre y los cambios de contextos y si se establecen límites artificiales, ajenos a esta realidad, se estará mermando la capacidad de las personas de poder hacer frente a ellos.

Si quieres acabar con la productividad de un desarrollador o de un equipo de trabajo solo tienes que socavar su confianza y/o crear un contexto en el que se tema cometer cualquier error.

¿Se trabaja mejor con presión? A corto plazo puede valer (otra cosa es analizar el coste que tendrá después ese esfuerzo de más que se tiene que echar), más allá es un lastre porque no olvidemos que somos personas y cuando estamos sometidos mucho tiempo a una nivel de exigencia muy alto terminamos por obtener peores resultados.

También se tiende a arriesgar menos y a ir por caminos más seguros independientemente de que sea algo que convenga o no realmente al proyecto, tal vez de esa forma nadie pueda reprocharnos un error ya que al fin y al cabo hemos tirado de manual pero también de esa forma estamos limitando nuestra capacidad de aprendizaje.

Eso de ser correcto aunque no se obtengan resultados es una de las características del cumplidor y se debe huir de la creación de un contexto que haga que proliferen ese tipo de figuras. Personalmente prefiero un desarrollador se equivoque y aprenda del error que un desarrollador que no se manche las manos ya que en el primer caso existe posibilidad de evolución y en el segundo solo tendremos a alguien que quedará bien en las fotos.

No se trata de premiar el error sino de entenderlo y de dar confianza a la persona que lo ha cometido. Es cierto que la confianza no puede ser infinita y si nos equivocamos mucho más que acertamos es posible que independientemente de todo lo que estemos aprendiendo nos pidan responsabilidades y eso debemos aceptarlo como algo normal, como parte de nuestro negocio y lo que puede ser un fracaso profesional hoy mañana puede haber sido el detonante de un éxito mayor.

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,

Si un proyecto puede presentar problemas presupuestarios cuando se prevé un alcance y una complejidad mayor que cuando se hizo su estimación económica, la solución debería pasar, no por intentar meter todas las funcionalidades con calzador, sino por tratar de buscar una solución más racional que permita obtener un producto que satisfaga las prioridades que se han establecido con un alto nivel de calidad, aunque esto implique dejar fuera o para más adelante (en muchos casos es necesario gestionar con los responsables funcionales el síndrome de la última versión), otra serie de funcionalidades que pueden resultar interesantes.

El primer paso debería consistir en dividir el proyecto en diferentes entregas, siendo conscientes todas las partes de que el desarrollo será iterativo incremental porque del feedback de cada versión vendrán, muy probablemente, solicitudes de mejora por parte del área usuaria.

Si se trata hacer todo de golpe se correrá el riesgo de que se agote el presupuesto y que en medio del proceso de desarrollo se entre en un conflicto entre las partes sobre cuál será el alcance final.

La experiencia dice que por muy buen acuerdo que se alcance se verá afectada la calidad del software porque el proveedor tratará de minimizar pérdidas, porque los desarrolladores tendrán overtime y llegado a un punto el cansancio y las ganas de terminar darán lugar a precipitación que se traduce en deuda técnica y en un producto menos probado.

Por otro lado, el cliente tendrá una mayor desconfianza y la comunicación entre las partes, tan necesaria en un proyecto de desarrollo de software, perderá fluidez y en función del grado de desgaste en las relaciones podría dar lugar a situaciones del antipatrón “arrojar al otro lado del muro“.

También se puede agotar el presupuesto con el enfoque iterativo incremental, la diferencia está en que al reestructurar el proyecto de esta manera todas las partes conocen las reglas del juego: se trabaja así no solo porque sea el enfoque que mejor pueda convenir al proyecto sino porque permite gestionar de manera adecuada las prioridades, el seguimiento y consumo económico del proyecto.

El siguiente paso consiste en trabajar con pila de producto e historias de usuario. Los responsables funcionales priorizan estas historias que una vez tasadas y ajustadas a la capacidad del sprint, se convierten en lo que será el resultado final de la entrega.

Si no lo ves claro (y también si lo ves claro), no dudes en dividir el proyecto en partes y cada parte en componentes o trabajos más simples (historias de usuario). Será más manejable, te beneficiarás el feedback y la gestión económica será mucho más transparente y mejor entendida entre las partes.