archivo

Archivos diarios: agosto 28, 2011

Conozco a excelentes programadores y arquitectos de software, a magníficos profesionales a los que confiaría proyectos críticos porque sé que estarían a la altura de las circunstancias, sin embargo ninguno de ellos es infalible y si no han probado de manera adecuada un producto software habrá incidencias importantes que lleguen a producción y si no se ha revisado convenientemente el análisis con los usuarios probablemente se esté lejos de cumplir las expectativas de los mismos.

Es decir, se puede tener un excelente potencial y unas cualidades magníficas que hagan que el software que se desarrolla tenga una deuda técnica aceptable y que sea, por tanto, factible de mantener y evolucionar, pero si no se es estricto con la necesidad de revisar lo que se está haciendo buena parte de ese trabajo se puede ir al traste.

No es cuestión de detectar todos los errores y desviaciones respecto a lo que el usuario espera, al menos no lo es en la mayoría de los sistemas de información que se desarrollan (sí que lo es en sistemas donde esté en juego la vida de personas o la cuenta de resultados de una organización), sino de minimizar o evitar, si es posible, el número de incidencias con un impacto grave en el entorno de producción.

Por tanto, sin testing, sin método para llevarlo a cabo, sin una sistematización de este tipo de trabajo desde el inicio del proyecto no hay confianza en que el producto llegue en condiciones a producción.

Los proyectos de desarrollo de software son complicados de controlar ya que todas las variables no dependen de una persona concreta (incluso dependiendo siempre habrá factores que se escapen o aspectos que no se sepan interpretar de manera adecuada). Por un lado está el equipo de proyecto, por otro los responsables técnicos del cliente, por otro los usuarios, cada uno con su visión, su percepción del proyecto y sus prioridades.

Como son complicados de controlar es necesario eliminar en lo posible factores que lo hagan todavía más difícil como son tener demasiados frentes abiertos, añadir complejidad por encima de la que es inherente al proyecto, no tener disponibilidad de recursos para afrontar situaciones de crisis, etc…

Cuando se pierde el control en el proyecto o por lo menos no se tiene el descontrol bajo control (que quizá sea la situación más real) es cuando se tiene la sensación de que continuamente se están apagando fuegos y prácticamente no se consigue avanzar ya que el enfoque se encuentra en resolver las crisis, que por otra parte no dejan de aparecer ya que en muchos casos sofocar un incendio origina nuevos focos o priorizar de manera inadecuada uno sobre otros provoca que estos otros se hagan más grandes.

¿Qué hacer si nos encontramos en esta situación? En primer lugar ponerla en conocimiento de todas las partes, si hay una crisis todos deben ser conscientes de lo que está pasando ya que cuando se está en problemas todos deben poner de su parte para salir de él. Después toca priorizar adecuadamente donde centrar los esfuerzos, aunque eso implique que haya módulos del sistema de información que tengan que estar durante un tiempo sin evolucionar o sin solucionar sus problemas.

Si hay algo que he podido aprender en el tiempo que llevo en esta profesión es que nadie es imprescindible.

No quiero decir con esto que todo el mundo tenga el mismo valor para la organización, ya que no es así, la marcha de determinados perfiles claves puede hacer bastante daño pero haciendo bien las cosas se conseguirá de nuevo recuperar el equilibrio (tarde o temprano).

Tal vez los que vengan no sean tan buenos en el área donde eran expertos los que se fueron pero tendrán también otras cualidades donde destaquen más que los que se han ido.

Si una organización entiende que tiene personal imprescindible es más demérito suyo que mérito de las individualidades ya que no ha sabido poner los medios adecuados para que el conocimiento que tienen los mismos se queden, aunque sea en parte, en la organización y en sus compañeros.

No se trata de un alegato que pretenda cortar por el mismo rasero a todos los que trabajan en una organización. No es así. He dicho por activa y por pasiva que una empresa debe cuidar a quienes posean talento, se sientan comprometidos con su proyecto y obtengan buenos resultados. Con mejores jugadores es más sencillo hacer un equipo que gane partidos.

Ahora bien, una organización está por encima de las personas que en cada momento la componen, independientemente del valor que estos tengan y debe poner los medios oportunos para que el conocimiento sea un activo de la organización y de los miembros que la componen y no un activo de individualidades concretas.

Uno de los problemas de los desarrollos siguiendo el ciclo de vida clásico o en cascada es que se tiende a entregar versiones completas de un sistema de información invirtiendo prácticamente todo el presupuesto del proyecto en conseguirla.

¿Problema? Tenemos una aplicación con muchas funcionalidades (cuando no muchos subsistemas) y sobre la cual el usuario empezará a reportar mejoras y correcciones, con el objeto de adaptar el sistema a sus expectativas. Esto no sería problema si estuviera contemplado en el presupuesto, pero lo más normal es que no lo esté y estaremos en una situación de poner en marcha un sistema casi sin recursos, lo que imposibilitará materializar el feedback del usuario.

Esta situación la tendremos incluso con un análisis óptimo del sistema y esto es así porque la naturaleza del software no es predictiva sino adaptativa o evolutiva. Un buen analista conseguirá reducir el margen de error entre la predicción y lo que el usuario realmente quiere (teniendo en cuenta además las contingencias propias de cualquier desarrollo, como que por ejemplo a mitad de la partida cambien las reglas del juego).

Por ese motivo lo mejor es aplicar un enfoque ágil, con una visión iterativa e incremental del sistema, de esa forma un buen trabajo de análisis es más efectivo, se reduce el tiempo en el que pueden ocurrir circunstancias que afecten al desarrollo y permite enfocar los esfuerzos en aspectos concretos del sistema. Es más, soy partidario de que incluso si se prevé que la primera versión del producto se extienda demasiado, se entreguen esqueletos andantes, sobre todo si existe voluntad de los usuarios en participar activamente en el proceso de desarrollo.

De esta forma, con la puesta en marcha paulatina de funcionalidades se puede controlar la existencia de muchos frentes abiertos, ya que la prioridad debe ser que cada módulo liberado del sistema esté acorde a las expectativas del usuario.

Cuando existen muchos frentes abiertos la sensación (y la realidad) es que las circunstancias controlan el proyecto en lugar de ser tú quien lo maneja. Apagar fuegos soluciona problemas a muy corto plazo, pero difícilmente ofrece una solución a futuro.

Hace poco un amigo me comentó que efectivamente las metodologías eran más efectivas si se adaptaban al proyecto con el que se iba a trabajar pero que dicho cambio de contexto también tenía un coste.

Él me equiparaba esta situación a cambiar de modelo de bicicleta en función de la carrera, sin embargo en la mayoría de los casos realmente lo que supone es un cambio de marcha, ya que generalmente no suelen cambios bruscos, ya que la tipología de proyectos en los que está especializada una organización son generalmente los mismos, existiendo matices en función del cliente, el presupuesto, el proceso o procesos que se quieren informatizar, etc…

Sí que entiendo la existencia de un coste adicional si se tiene que cambiar sensiblemente la dinámica de trabajo porque toda adaptación lo tiene, sin embargo cuando se trata de matizar la forma en la que habitualmente trabajamos no tiene por qué originar coste alguno.

Conforme se va adquiriendo experiencia en el desarrollo de software vamos automatizando en nuestro trabajo determinadas prácticas que nos han ido funcionando de manera adecuada. De hecho es de esta forma como vamos amortizando nuestra experiencia, ya que si no aprendemos de nuestros errores, fracasos, aciertos y éxitos estamos condenados a no evolucionar, a no ser mejores en nuestro trabajo, algo a lo que prácticamente todos aspiramos independientemente de que pensemos que le damos una mayor o menor importancia.

Francis Glassborow es un consultor inglés, especializado en la programación y en la aplicación de buenas prácticas en la misma. De hecho es miembro de la ACCU (acrónimo inicialmente de Association of C and C++ Users aunque en la actualidad se ha extendido a un mayor rango de lenguajes de programación), asociación que tiene como objetivo el fomento del profesionalismo en el mundo de la programación y la mejora de sus estándares.

Como miembro de la ACCU, Francis Glassborow ha revisado personalmente aproximadamente mil publicaciones relacionadas con la programación, por lo que estamos hablando de un profesional con una experiencia lo suficientemente dilatada como para tener en cuenta su siguiente reflexión: “Los buenos programadores utilizan sus cerebros, sin embargo las buenas prácticas nos permite no tener que pensar en todos los casos”.