Kent Beck. El coste de no estar en producción

Llegar a producción da miedo. El área usuaria siempre tendrá el “síndrome de la última versión” y, por tanto, querrá incluir toda la funcionalidad que puedan y pondrán los umbrales de aceptación muy altos.

A los desarrolladores también les entra el pánico porque por muchas pruebas que se hayan realizado al producto es en producción donde se pasa el examen final, todo lo anterior son exámenes parciales que si bien hay que superarlos no tienen más trascendencia (y no con ello quiero quitale importancia) que crisis puntuales en el proceso de desarrollo.

Si hay presión en el desarrollo, no es comparable con la que se recibe si el producto llega a producción y es un desastre.

Esta situación puede eternizar el paso a producción en muchos proyectos de desarrollo de software.

Ante esto hay que reflexionar (usuarios y desarrolladores) sobre las características del sistema de información que vamos a poner en producción, si se trata del software de una central nuclear o un software crítico que puede poner en riesgo vidas humanas, la salud de las personas, el medio ambiente o la continuidad de la organización se puede entender que toda precaución es poca, pero fuera de ese círculo (que es la inmensa mayoría de los sistemas que se desarrollan) hay que evaluar el coste real que implica retrasar sistemáticamente un paso a producción por el intento de alcanzar una perfección que nunca se va a conseguir.

Ya lo dice Kent Beck: “No estar en producción es gastar dinero sin hacer dinero”.

Desarrollo de software. No hay magia tras los procesos

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: “el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos” o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.

La programación no debe ser una actividad mecánica

Puedes trabajar con factorías de software siguiendo el modelo que más pueda convenir: Offshore, Nearshore, Onshore y conforme exista más distancia entre los equipos que tratan las especificaciones y el equipo que las desarrolla más mecánico se convierte el trabajo del equipo de programadores: “toma las especificaciones, te las modelo y desarrolla según la arquitectura y framework pactado”.

Es posible que esa distancia la puedan reducir los equipos de trabajo aplicando distintos tipos de técnicas y herramientas porque como he dicho en otras ocasiones el impacto de la distancia depende mucho de la actitud de todas las partes. Sin embargo cuando por encima de los técnicos, hay jefes de proyecto o gerentes “contables” la actitud (si existe) queda difuminada y se entra en un peligroso modelo de trabajo basado en el antipatrón “arrojar al otro lado del muro”.

Como bien dice un amigo, no hacen falta factorías de software para caer en ese antipatrón, te puede pasar perfectamente con el proveedor incluso compartiendo oficina.

En el momento en que se entra en ese juego la programación desgraciadamente se convierte en una actividad mecánica: el programador se limita a ejecutar tareas, conociendo solo el sistema que se desarrolla a bajo nivel. Con esto perdemos el feedback del programador tanto a nivel técnico: tal vez sean recomendables ciertos cambios en la arquitectura o el framework para adaptarlos mejor a la naturaleza del software que se desarrolla, como funcional: Esto no termina de ser coherente con otros módulos del sistema y es necesario que las especificiones sean más claras o que se estudie esa falta de consistencia con el usuario.

En un proyecto todos suman, los programadores por supuesto también (y mucho). Todas las personas que están en el proyecto están capacitadas para aportar ideas y soluciones, tengan el rol que tengan, a veces estarán acertadas y otras se equivocarán pero lo que no podemos hacer es dejar de escuchar sus opiniones porque estaremos despreciando toda la capacidad y talento de los componentes de nuestro equipo.

Desarrollo de software. El conocimiento de las aplicaciones que se venían utilizando hasta ahora

Muchas veces cuando se decide desarrollar un nuevo sistema de información se quiere hacer tábula rasa y no tener en cuenta las aplicaciones o herramientas que venían utilizando hasta ahora. En alguna ocasiones la excusa es no dejarse contaminar por lo anterior en otros casos es que simplemente no interesa porque “no lo he inventado yo“.

Que el usuario te va a especificar lo que quiere no es suficiente para obviar lo que se venía utilizando hasta ahora. Es conveniente conocer los puntos fuertes y débiles de esas soluciones para evitar volver a caer en los mismos errores y para aprovechar todo lo positivo que tuvieran.

Los usuarios van a extrañar y mucho todo lo que en el anterior sistema les gustaba o les resolvía y el nuevo sistema no y hasta que dicha funcionalidades no las tenga el sistema o no estén ejecutadas acorde a sus expectativas, van a existir ciertas resistencias por parte de los usuarios sobre el nuevo sistema y que complicarán la puesta en marcha del mismo y el trabajo del equipo de desarrollo).

Otro aspecto positivo de tener en cuenta estos sistemas es que sabemos que al usuario le cuesta acertar con sus especificaciones (necesita iterar) por la diferencia que existe entre las expectativa que tiene y que están plasmadas en una imagen abstracta y la realidad del funcionamiento del sistema. Utilizando uno que está en funcionamiento y con años de feedback sobre el mismo tenemos un instrumento muy interesante que sirve de apoyo al usuario y a los desarrolladores.

Desarrollo de software. Antipatrón. Estimaciones desde la euforia

Si hacer estimaciones es complicado y si equivocarse en las estimaciones puede condicionar gravemente un proyecto, quiere decir que es una actividad que no debe tomarse a la ligera.

A alto nivel las estimaciones en un proyecto deberían ser referencias porque todos conocemos el grado de incertidumbre que existe sobre todo si se trata de un sistema nuevo o de una evolución importante de uno ya existente. Considerarlas más allá de eso, supondrá una gestión maś rígida del triángulo de hierro (alcance, plazos y costes) y la existencia de una serie de limitaciones que dificultan la agilidad en los desarrollos.

Desgraciadamente las estimaciones a alto nivel se toman demasiado en serio. Entendedme bien, no digo que no sean serias, no digo que se deban ignorar, sino que es necesario que se tengan en cuenta las circunstancias del proyecto y no se ignore que cuando se realizó la estimación se pensó en un alcance del que se disponía realmente de poca información y en unas condiciones que probablemente van a cambiar.

Las estimaciones suelen ser optimistas porque se suele pensar en condiciones ideales. También tiene mucho que ver la presión que puede venir por parte de los usuarios o del cliente, que desean que cuanto antes y por el menor coste posible se tenga el producto en producción.

Ese optimismo se convierte en temeridad (todavía más), cuando las estimaciones se realizan en momentos de euforia, generalmente poco tiempo después de realizar una demo del producto con éxito, haber recibido felicitaciones por el trabajo bien hecho, haber superado una crisis complicada, etc… Es recomendable tratar de evitar la realización de estimaciones en esas condiciones (o por lo menos tratar de diferirlas lo que sea posible) porque incluso las personas más frías pueden verse afectadas por esa situación.

Desarrollo de software. Antipatrón. Esto está casi

Caso particular del antipatrón “Trampas evitables” y consecuencia en muchas ocasiones de “Al servicio de Pareto“.

A veces por exceso de optimismo y otras por presiones del área usuaria, del cliente o de tus jefes, se tiende a mencionar la fatídica frase del: “Esto está casi”, cuando realmente no es esa la realidad.

No olvidemos que la curva de progreso en el proyecto es pronunciada al principio pero que el final se tuerce mucho porque es necesario alinear todos los detalles para poder hacer una entrega en condiciones y sabemos lo complicado que resulta (hablo de hacer una entrega con garantías no de entregar por entregar).

En el momento en que pronuncias “Esto está casi”, estás generando una expectativa (y mucho peso). Cuidado con eso, ya que es absolutamente necesario hacer una buena gestión de las mismas, de lo contrario se pierde confianza y credibilidad, que son piezas fundamentales en las relaciones entre los diferentes implicados que participan en el proyecto.

No digo que no se deba ser transparente, al contrario, si no lo eres te estás equivocando, lo que sí estoy comentando es que hay que ser prudente y medir bien qué se dice, a quién se dice y en qué momento.

Desarrollo de software. Antipatrón. Presión desmedida

La falta de tensión no es buena, tampoco el exceso de presión. La presión en un momento dado puede ayudar a mantener o recuperar el enfoque en el proyecto, incluso a dar ese 110% que puede ser necesario, siempre y cuando sea durante un período de tiempo soportable.

Pero más allá de eso, es nefasta. También lo es en períodos cortos cuando se trata de conseguir un sobreesfuerzo que está por encima de la capacidad de los desarrolladores y/o del problema en cuestión que existe en ese momento.

Yo también he dicho más de un vez que bajo presión funciono mejor, pero no es así realmente. Bajo presión estás más concentrado y tienes tus sentidos dedicados al objetivo, pero eso es así porque es una presión controlada, no te obligas o no te obligan más allá las de lo que puedes admitir, en el momento en que te exiges o te exigen más, empieza el bloqueo, los nervios y las contramedidas para quitarte de encima esa presión que pasa por tratar de terminar cuanto antes y como sea, con la consiguiente merma de calidad del producto final.

Resulta complicado no trasladar presión a tu equipo si a su vez estás sometido a una gran presión. Es importante que ellos vean y sientan lo que está en juego pero no ir más allá. Tener la capacidad de absorber esa presión y no saturar con ella al equipo es una gran virtud y en contraprestación conseguirás mejores resultados gracias a un trabajo más productivo.

Desarrollo de software. Antipatrón. Desarrollo a la primera

Este antipatrón surge cuando se asigna un presupuesto para el desarrollo de un producto y no se tiene en cuenta que tras la construcción del mismo va a ser necesario continuar con su evolución ya sea ampliando funcionalidades o realizando modificaciones sobre las ya existentes.

Esto lo podemos encontrar tanto en enfoques clásicos como en los iterativos incrementales. Es muy frecuente sobre todo en los primeros, ya que suelen tener un enfoque de contrato cerrado: “esto es lo que hay que hacer y este es el dinero que te voy a pagar”, no obstante los segundos también se ven afectados en el momento en que se agota el presupuesto y se detecta que es necesario seguir trabajando sobre el sistema.

Pensar que se va a desarrollar el producto a la primera es una quimera tan grande como pensar que incluso consiguiéndolo no se van a dar circunstancias que hagan necesario realizar una mantenimiento.

Lo mismo piensas: “Bueno, si hace falta más dinero, se pone y ya está”. Eso no es tan fácil, ya que dependerá de la holgura que permita el presupuesto de la organización. En el caso de proyectos con la Administración resulta todavía más complejo porque los procesos de contratación requieren su tiempo y porque existe menos flexibilidad presupuestaria.

Desarrollo de software. Antipatrón. Criptocracia

Antipatrón organizativo que se caracteriza por la existencia de una jerarquía en la organización, basada en áreas, departamentos, jefes, puestos intermedios, etc… pero que realmente nadie sabe cómo funciona, de manera que el organigrama es tan solo un dibujo que trata de dar un orden y sentido a lo que no lo tiene, ya que trata de expresar una realidad que no existe.

Ante esta situación la organización sigue funcionando en “piloto automático”, siguiendo prácticas, estrategias o procesos del pasado, de cuándo la misma tenía un orden, lo que le permite seguir en marcha, si bien, cada vez más en precario ante la incapacidad de poder adaptarse a los cambios, de tal forma que llegado el momento todo se hará insostenible.

A esa dificultad hay que sumarle el hecho de que ante la falta de liderazgo y objetivos, cada cuál termina haciendo la guerra por su cuenta, lo que hace más pronunciada, si cabe, su caída.

Pero, si estas circunstancias son tan graves, ¿cómo es que hay organizaciones que pese a tener este problema siguen subsistiendo?.

He expresado una situación extrema, en muchos casos lo que sucede es que sí que existe una cierta organización y un reparto de roles, pero con una excesiva división en capas tanto a nivel vertical como horizontal, lo que provoca que el funcionamiento quede difuminado entre la burocracia y los puestos y departamentos de dudosa utilidad en el presente (que tal vez la tuvieron en el pasado). En estos casos lo que tenemos es una organización ineficiente y rígida.

Otra causa que puede mantener a flote la organización es el “heroísmo” de ciertas personas o departamentos que con sus resultados sobresalientes permiten mantener la estructura.

También es posible que la fidelidad de determinados clientes y/o el éxito de algunos de los productos generen los suficientes ingresos como para compensar una situación así.

Desarrollo de software. Antipatrón. Testing de fogueo

Este antipatrón surge en aquellos casos en los que los desarrolladores (o el equipo de desarrollo) dan por correctas determinadas funcionalidades sin haber pasado el suficiente número de casos de prueba que permitan testearlas teniendo en cuenta diversas casuísticas en los juegos de datos, en la interacción con terceros sistemas o en la propia operativa del usuario.

El testing de fogueo es una de las causas que provocan que un mayor número de defectos se detecten más tarde de lo que debieran, como por ejemplo en la integración con otros módulos, con otros sistemas o incluso en producción.

Aplicando testing de fogueo se obtiene una imagen del estado del proceso de desarrollo que no se corresponde con la realidad, por eso insisto mucho en que las funcionalidades tienen que estar bien probadas porque de lo contrario se crean expectativas en cuanto al avance de los trabajos que pueden provocar que, cuando nos demos cuenta de los problemas, sea demasiado tarde para reaccionar.

No se debe confundir con el antipatrón: “No probado pero finalizado, ya que este tipo de prácticas no son necesariamente provocadas por la necesidad de cumplir unos plazos más o menos complicados, sino que vienen “de serie” con los desarrolladores.

Ya lo decía Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido“.