archivo

Archivos diarios: agosto 24, 2013

El proceso de paso a producción suele realizarse fuera del ámbito de actuación del equipo de desarrollo, ya que es realizado por otros perfiles que incluso pertenecen a otros departamentos: administradores de base de datos y de servidores de aplicaciones, técnicos que se encargan de realizar una verificación de la entrega y del producto, etc…

Al no existir una alineación de objetivos entre los departamentos y tampoco una gestión de la capacidad y de las prioridades, pero sobre todo al no existir nadie que gestione todo ese proceso, la realidad es que una vez que el producto entra en esa fase no se sabe muy bien cuándo sale de ella. Lo más que podemos hacer es realizar estimaciones, en función de la complejidad de la entrega y de las garantías de la misma y de lo que se haya conseguido negociar con los departamentos y personas implicados.

En cualquier caso, no queda otra que seguir muy atento el recorrido de la entrega y tratar de responder cuanto antes si existe alguna disconformidad, tratando a priori de evitarlas ya que el tiempo de paso a producción crece casi exponencialmente cuando se entra en el bucle de rechazo, nueva versión, rechazo, nueva versión. Es cierto que la mayoría de las veces puede ser evitable pero también lo es que somos humanos. Por ese motivo, es muy importante que quien rechaza, sepa valorar si es más importante el impacto de la no conformidad que el retraso en la puesta en marcha de la versión y eso no se puede ni se debe baremar en base al cumplimiento o no de un checklist.

La realidad es que la duración mínima que puede tener un sprint debería ser el tiempo estimado de paso a producción de una entrega. De lo contrario corremos el riesgo de tener más de una versión en fase de desarrollo, algo que personalmente no me gusta. Por eso muchas veces cuando leo que se pueden fijar sprints de una o dos semanas no termino de verlo, no porque no sea posible, sino porque en los proyectos en los que participo no puedo garantizar que el paso a producción se pueda realizar en ese tiempo.

¿Cómo mejorar la agilidad del paso a producción si tenemos ese contexto? Mejorando la comunicación, flexibilizando procesos y anticipando a las personas que participan en el proceso de paso a producción todas las peculiaridades que se van a encontrar y por supuesto, tratándolas de implicar lo máximo que sea posible en el proyecto y sus objetivos. Y por supuesto y como decía antes, estando muy atento a las contingencias y bloqueos que se puedan producir.

Esa recomendación es una acción a corto plazo que trata de resolver un problema concreto, lo más razonable es que si se sabe que existe ese problema, se intenten buscar o aplicar soluciones más generales.

Lao-Tsé refleja en un par de citas, un aspecto esencial que tenemos que tener en cuenta a la hora de abordar un proyecto de desarrollo de software y en general para cualquier tarea de un cierto tamaño que queramos afrontar:

“Proyecta lo difícil partiendo de donde aún es fácil”.

“Realiza lo grande partiendo de donde aún es pequeño”.

Precisamente uno de los grandes problemas del ciclo de vida en clásico o en cascada es ese, construir un producto demasiado grande que después resulta complicado de reajustar.

Cuanto más grande sea, más dinero nos habremos gastado, por lo que menos disponibilidad presupuestaria tendremos para hacer modificaciones (a la par de la presión por amortizar la inversión) y la deuda técnica hará más costosas las modificaciones, y eso casi en el mejor de los casos, porque si hay que cambiar arquitectura o estrategias de diseño, los costes se disparan.

Si encima el producto cubre un proceso de negocio estratégico el impacto será aún más fuerte.

Precisamente quienes conocen este problema tratan de dividir el sistema en diferentes versiones, siguiendo un enfoque incremental. Eso es un primer paso para hacerlo también iterativo, en el sentido de que en cada versión se subsanen deficiencias de las anteriores, que no solo llegan a nivel correctivo, sino también perfectivo y evolutivo.

Se mejora de esta forma, pero si la duración de las iteraciones es demasiado prolongada, seguiremos teniendo en esencia el problema inicial, atenuado, pero seguirá ahí.

Por ese motivo, el siguiente paso es la realización de ciclos más cortos. Si son fijos o variables en tiempo, es otro tema de debate.

Para Bertrand Meyer: “El único gran enemigo de fiabilidad (y tal vez la calidad del software en general) es la complejidad”.

En mi opinión hay muchas más variables pero sí que es cierto que la complejidad condiciona, sin lugar a dudas, el resultado final de un producto, su usabilidad y la capacidad de realizar mantenimientos sobre él o, lo que es lo mismo, la capacidad de evolucionarlo.

Si nos dejamos seguir por las modas, si se imponen restricciones técnicas o de arquitectura que no condicionan sobre manera el proyecto, si miramos la solución como un juguete o un banco de pruebas, probablemente se le esté añadiendo la resultado final una complejidad innecesaria y que después va a resultar muy costosa de eliminar.

Si el producto se empieza a “engordar” con funcionalidades que no son necesarias, con módulos que no tienen nada que ver con su objeto final (porque resulta más barato incluirlos en la plataforma que crear un sistema desde cero para ellas), etc…, también se estará añadiendo complejidad que hay podido ser evitable.

A más complejidad más probabilidad de que existan errores y que no sean detectados. A más complejidad más deuda técnica.