Desarrollo de software. Pete McBreen. Descubrimiento

Para Pete McBreen: “La maestría o la sabiduría no han sido nunca resultado de encontrar la mejor manera, sino el resultado de un viaje de descubrimiento en que nuevas ideas son posibles, incluso en las más mundanas de las tareas”.

Por tanto, se trata de un viaje sin fin, en el que vamos evolucionando conforme vamos ampliando nuestras experiencias y conocimientos y, en donde en cualquier situación y con cualquier persona tenemos la capacidad de mejorar.

Las ideas están ahí fuera es muy pretencioso pensar que todas las tenemos en nuestra cabeza.

En el momento en que pensamos que lo sabemos casi todo y que muy pocas situaciones o personas nos pueden aportar cosas, estamos limitando, no solo nuestro conocimiento sino nuestro margen de maniobra ante un determinado problema si pensamos que la solución al mismo solo puede proceder de nosotros mismos.

Cuando trabajas con más personas, pensar que nadie te puede aportar nada o que solo algunos de ellos puede hacerlo estás cometiendo un error, te estás poniendo límites sin necesidad, estás dejando que tu arrogancia ponga resistencia al éxito.

Este tipo de actitudes llevadas al campo de los proyectos de desarrollo de software producen resultados nefastos ya que tiendes a crear castas: aquellos a los escuchas y aquellos que solo están para ejecutar trabajo y eso produce división y desmotivación entre aquellos que consideran que su opinión o conocimientos no vale para nada.

Desarrollo de software. Visualizar el flujo de trabajo

Es ciertamente potente, muy potente. Conocer de un solo vistazo el estado de las tareas y detectar cuellos de botella (aplicando Kanban o no) y que esté siempre presente supone una guía muy importante (cómo va cada cosa, qué está terminado, qué no ha empezado, etc…) para el equipo de proyecto y para el conjunto de personas implicadas en el proyecto.

Esa información se puede tener en la cabeza pero la efectividad no es la misma que captarla con la vista, es lo de siempre, no es lo mismo una imagen abstracta, por muy claro que se tenga la situación, que algo que estás viendo con tus propios ojos y más cuando se trata de un trabajo en equipo y hay una serie de personas que tienen que dialogar y tomar decisiones en base a esa información (en general y más allá de la visualización de un flujo de trabajo resulta de mucha utilidad tener esas reuniones cerca de una pizarra, es más, si te es posible pon todas las pizarras que puedas cerca de tu equipo de proyecto).

Hay muchas formas de implementar esto (orientación horizontal o vertical del flujo de trabajo, aplicar Kanban o no, hacer una separación por proyectos o no, etc…), no hay fórmulas magistrales para definir el flujo de trabajo, dependerá del proyecto y también del equipo de trabajo.

Desarrollo de software. Bob C. Martin. Individualidades y colectivo

Un desarrollador de alto nivel en el rol que desempeña es capaz de rendir exponencialmente mejor que otro que no tenga sus conocimientos, experiencia y brillantez.

Cuando se trata de proyectos donde el equipo es muy reducido unas buenas individualidades pueden compensar un mal funcionamiento colectivo.

Cuando el equipo es más numeroso no vale solo con tener buenas individualidades sino que debe funcionar como tal, no se trata del no aprovechar el talento sino optimizarlo como parte del talento colectivo de manera que la suma de todo el conjunto supere a la suma de las individualidades.

Un héroe puede salvarte una vez, dos, tres veces…, tal vez incluso pueda salvar el proyecto pero no es el camino, a medio y largo plazo serán muchos los proyectos que fracasen mientras esperan que el héroe vuelva a hacer un imposible.

Hay mucho trabajo que hacer en el proyecto y cada cual se tiene que encargar de lo suyo sin olvidar que forman parte de un equipo por lo que debe existir comunicación e interacción con los demás y estar siempre a disposición del equipo para echar una mano donde haga falta. Si cada cual hace la guerra por su cuenta está creando una resistencia para el resto de sus compañeros, los cuales verán mermada su eficacia.

Bob Martin realiza la siguiente reflexión: “Un equipo de desarrolladores medios que se comunican bien tienen más probabilidades de tener éxito que un grupo de superestrellas que fallan al interactuar como equipo”.

Muchos proyectos fracasan porque no se consigue formar ese equipo (dentro de los desarrolladores) y en extensión cuando no se consigue formar un equipo con el resto de implicados en el proyecto.

Es muy importante construir ese equipo y eso no se consigue simplemente juntando una serie de personas. Muchos gestores olvidan eso y piensan que todas las combinaciones pueden ser válidas y no es así. Dentro de las opciones existentes hay que procurar conformar la mejor, a partir de ahí, con un buen equipo, se tendrá una buena base para luchar por el éxito en el proyecto.

Una vez elegida una buena combinación toca consolidar el equipo y mantenerlo que es lo más difícil teniendo en cuenta el desgaste existente en un proyecto de desarrollo de software sobre todo en circunstancias de presión, algo que por desgracia ocurre casi siempre.

Desarrollo de software. Proyectos corales

Un proyecto coral es aquel en el que muchos opinan y muchos toman decisiones tanto en lado de los desarrolladores como en el lado de los usuarios. En este tipo de proyectos sobran las palabras y falta responsabilidad porque cuando tantos intervienen cuesta que alguien asuma el papel de coordinador de su área.

Mi opinión es que se deben evitar este tipo de situaciones porque por intentar contentar a muchos se abre demasiado el sistema implementando funcionalidades innecesarias e incrementando su complejidad, todo esto en un contexto de falta de liderazgo y si eso se produce en el área usuaria y/o en el equipo de desarrollo tenemos un problema muy serio.

El área usuaria debe tener un Product Owner y el equipo de desarrollo un coordinador. ¿Qué dentro de cada área se quieren tomar decisiones por consenso?, ¿qué se quiere que participe y opine mucha gente? Me parece perfecto, pero el responsable de cada una de ellas lo es también de las decisiones que se toman y de las consecuencias de las mismas.

Desarrollo de software. Estabilizar la velocidad requiere su tiempo

Lo deseable es que el equipo coja velocidad de crucero desde el primer sprint, sin embargo es algo que resulta muy complicado salvo en aquellos proyectos en los que el equipo esté habituado a trabajar junto y/o con una orientación a sprint, esté perfectamente habituado a la tecnología de desarrollo y en donde las historias de usuario sean de calidad y fácilmente asimilables por los desarrolladores.

Lo más normal es que el equipo pueda asumir menos carga de trabajo al principio y la vaya aumentando conforme los factores anteriores se van asentando, hasta llegar a esa velocidad de crucero, que, ¿por qué no?, podría ir mejorando con el paso del tiempo.

Trabajar con agendas puede implicar un nivel de exigencia alto al equipo desde el primer sprint, un nivel de exigencia que se sitúa por encima de lo que el equipo puede dar en ese momento. Desde mi experiencia os puedo asegurar que no es positivo porque no asegura el adecuado cumplimiento de los compromisos (que esté programada una funcionalidad no es cumplir el compromiso, cumplirlo es que funcione y esté en disposición de pasarse a producción si así se considerase oportuno) y porque el equipo empieza a desgastarse desde muy pronto y eso afecta negativamente a los trabajos teniendo en cuenta que todavía queda mucho proyecto por delante.

¿Qué hacemos? Si se puede intentar adaptar la agenda a lo que el equipo puede dar e incrementar si se puede el equipo o la dedicación de las personas que ya participan en él (si hay personas que puedan incorporarse al equipo en donde su saldo de participación neto: lo que aporta menos lo que el equipo tiene que invertir para conseguir esos resultados es positivo o puede serlo a muy corto plazo y hay trabajo por delante que lo justifique).

Por tanto, es conveniente dejar que el equipo vaya adquiriendo paulatinamente esa velocidad de crucero, no hay que olvidar que tienen que cumplir unos compromisos, que ponen mucho en juego y que por tanto, ellos de manera responsable deben autogestionar la capacidad de trabajo que pueden asumir en cada momento.

Desarrollo de software. Anticipación al cambio

Es necesario adaptarse al cambio cuando surge un nuevo contexto. Cambiar es casi siempre posible pero el tiempo y esfuerzo que se invierte en ello puede provocar que lleguemos demasiado tarde y/o que hayamos gastado gran parte o casi todo el esfuerzo disponible en ese cambio dejándonos sin posibilidades ante futuros cambios o ante la propia evolución del sistema.

No todos los cambios son iguales ya que hay contextos tan radicalmente diferentes al anterior que no hay proyecto que lo pueda sostener salvo que se redefinan las restricciones del mismo (principalmente el presupuesto).

Sin embargo cuando el cambio sea “más suave” sí que resulta necesario estar preparado para ello y no supone realmente una inversión adicional al proyecto sino que el esfuerzo destinado a ello empieza a amortizarse prácticamente desde el principio.

Sí, hablo de una arquitectura y un código que favorezcan la mantenibilidad del producto a través de una deuda técnica acorde a las características del proyecto y los recursos disponibles pero no solo se tratan de aspectos técnicos ya que un equipo (y no hablo solo del equipo de desarrollo, sino que lo extiendo también a los responsables funciones o al Product Owner y al conjunto de personas que intervienen de manera más o menos directa en la construcción del producto) que se entiende, que se comunica, en el que hay confianza y que es consciente de que puede haber cambios de contextos tomará decisiones más acertadas, de manera más rápida y pensando en el bien general.

También hablo de una adecuada gestión de riesgos. Hay cambios de contexto que suceden y es complicado tener una previsión de los mismos, sin embargo, hay otros cambios de contexto que son el resultado de la materialización de riesgos (en algunos casos pueden ser evitables y en otros caso no).

Desarrollo de software. Antipatrón. Falta de ritmo

La falta de ritmo y los parones, que con mayor o menor duración, se pueden producir en un proyecto de desarrollo de software suelen hacer mucho daño.

Hay que tener en cuenta que el equipo de desarrollo está centrado en la realización de este trabajo (independientemente de que alguno de sus integrantes comparta su tiempo con algún otro proyecto) y que si no recibe materia prima para poder trabajar, ocurrirá alguna de las siguientes circunstancias:

- El equipo de proyecto quedará parado o realizando tareas secundarias a la espera de recibir trabajo y ese coste se imputa al cliente.

- Como el cliente no suele asumir ese coste, el proveedor tratará de recolocar a los componentes del equipo en otros proyectos, de tal manera que su colaboración en los mismos sea puntual, para de esta forma poder “rescatarlos” en el caso de que haya una reactivación.

Habrá algún miembro del equipo que no pueda volver por compromisos en el nuevo proyecto en el que está (a veces lo puntual termina por convertirse en una integración efectiva en otro equipo de trabajo) y otros tardarán algo más de lo que inicialmente se esperaba. Esta situación tenderá a ir a peor conforme vaya aumentando el tiempo de parón.

Si la organización no tiene proyectos donde recolocar a algunas de estas personas y el cliente no se hace cargo de este período de inactividad, probablemente la mayoría de ellas deje de trabajar para la organización.

En función del grado de avance del proyecto y de la especialización del personal que participa en él, el impacto de que haya cambios importantes en el equipo puede ser mayor o menos, teniendo en cuenta que incluso en el mejor de los casos hay coste, porque se ha perdido la inercia existente, se requiere un tiempo para la puesta al día y para que la maquinaria vuelva a estar engrasada.

Desarrollo de software. Antipatrón. El usuario estima

Forzar a que un equipo de proyecto admita más trabajo que el que soporta su capacidad en un momento dado del tiempo no suele funcionar. Tal vez se desarrollen las funcionalidades pretendidas pero es más que probable que el grado de acabado de las mismas no sea bueno, de tal forma que la calidad del resultado final se resentirá: más bugs, deficiencias funcionales y funcionalidades que no están totalmente rematadas?.

Y no solo eso, será complicado que se respeten los plazos fijados, así como los compromisos adquiridos. El triángulo de hierro es poco maleable y si mueves uno de sus vértices el resto se resiente, esa flexibilidad adicional te la da el esfuerzo adicional del equipo de proyecto que si bien puede salvar la situación durante un tiempo no podrá sostener un nivel de presión y de overtime de manera sostenida sin que afecte a su propia productividad y a la calidad de los trabajos. Esto es un hecho y seguro que lo has vivido en primera persona.

Se llega a este antipatrón, por un lado por el deseo de avanzar más rápido y en muchos casos por la desconfianza en las estimaciones que se realizan. La confianza requiere un tiempo cimentarla, mientras tanto, pide explicaciones si no terminas de entender alguna de las estimaciones y admítela salvo que entiendas que la desviación respecto a lo que debería ser es flagrante (si tienes dudas, dala también por válida), al final, pasado un tiempo, el propio proyecto irá poniendo las cosas en su sitio.

¿Por qué dejar que sea el equipo quién estime? Pues porque es el equipo al que se le exige el cumplimiento de los compromisos. Puedes exigir si ellos establecen sus límites, si los pones tú no solo te arriesgas a los inconvenientes indicados en párrafos anteriores sino que estás dejando la puerta abierta a que te pongan la excusa de que las condiciones que has planteado eran imposibles.

Si todo lo demás se desmorona te queda el equipo

Trabajas en el contexto de una organización, puede que la misma no funcione bien, no preste atención al proyecto o a tu equipo. Lo mismo no es cosa de la organización (o también) y es cosa de tu inmediato superior (o de su superior), ¿qué te queda?, ¿qué os queda? Vuestra fuerza como equipo.

Si os lo ponen imposible será imposible pero si no es así tendréis la oportunidad de luchar por el proyecto, no digo que se consiga sacar adelante porque lo mismo la resistencia es tal que no se consigue vencer.

Un equipo que funciona como tal, compacto, que se autogestiona, donde se entiende que el trabajo no sale adelante sin la colaboración de todos (cada uno dentro de su rol) es muy potente y es capaz de crear una membrana que lo hace resistente a ingerencias o situaciones externas que afectan al equipo y/o al proyecto.

Por eso es tan importante crear un equipo y si el mismo se extiende a otros stakeholders mejores serán los resultados.

Crear equipos no es tarea sencilla porque no solo depende de quien los coordina sino de la actitud de sus componentes y más difícil todavía resulta mantenerlo en el transcurso del proyecto donde seguro habrá problemas y crisis que será necesario gestionar para no romper esa armonía (o para si se abren pequeñas grietas cerrarlas cuanto antes).

Desarrollo de software. Formar un equipo

Considero que existe un equipo cuando hay un grupo de personas que colaboran para alcanzar un objetivo u objetivos comunes. La colaboración supone ayudar incluso en circunstancias donde resulta complicado hacerlo (por ejemplo, por carga de trabajo) o que traspasen tu ámbito de actuación en el proyecto. La colaboración (efectiva) requiere confianza.

Después, las personas, de manera individual, pueden tener sus propios objetivos y ser tan importantes o más que aquellos por los que está trabajando el equipo, lo importante en este caso es dejar el suficiente espacio a los objetivos del proyecto como para que no interfieran con los demás. Si no se deja ese espacio la colaboración se resentirá y con ello el equipo.

Si hay voluntad ese espacio puede crearse. Si no la hay, lo individual se impondrá a lo colectivo.

Es obvio que formar un equipo dentro de tu ámbito competencial en el proyecto, por ejemplo, si sois los desarrolladores, formar el equipo de desarrollo es fundamental para que ese grupo de personas que trabajan juntas funcione y no solo eso, sino que el todo sume más que las individualidades. Sin embargo, debe ser algo tan obvio que se ignora por completo y en lugar de equipo lo que se hace es juntar una serie de personas que después si tienen buena voluntad y se autoorganizan pueden formar un equipo real.

El desarrollo de software no es cuestión de que funcionen bien los diversos equipos implicados. Los mismos pueden funcionar estupendamente y después no entenderse con los demás. Eso en un proyecto es nefasto. Por tanto, conseguir que los distintos equipos funcionen como uno solo debe ser un objetivo porque reduce obstáculos y resistencias e incrementa la productividad.

Crear un equipo es complicado, crear un equipo formado por diferentes equipos mucho más. Se requiere creer en esta forma de trabajar, tener unas miras amplias (más allá de tus objetivos individuales o de tu equipo concreto), saber escuchar, saber dar a cada uno su espacio y gestionar bien los conflictos que, sin duda, aparecerán.