archivo

Archivos Mensuales: mayo 2014

Hay una cosa cierta, de cada proyecto en el que trabajamos, si tenemos la intención, aprendemos más y por tanto, tenemos la posibilidad de adaptar mejor nuestra forma de trabajar a las circunstancias que se presenten y de poder hacer uso de esa experiencia para tratar de acertar más en nuestras decisiones.

Por ese motivo me parece muy interesante la reflexión de Lowell Lindstrom que si bien está centrada en la programación extrema es perfectamente extensible a cualquier otro esquema de trabajo (traducción libre): “XP no es el final del viaje, es sólo el pozo de agua corriente que es especialmente sabroso para muchos. Vamos a aprender más con cada proyecto que hacemos”.

Cada proyecto es diferente e incluso dentro de cada uno hay circunstancias que implican cambios más o menos sensibles en el enfoque, por ese motivo si nos limitamos exclusivamente a aplicar las mismas ideas, prácticas y métodos de trabajo probablemente estamos restringiendo nuestra capacidad de poder aplicar determinadas soluciones que pueden resultar más aconsejables al contexto del proyecto.

Ojalá todo fuera tan fácil en el desarrollo de software como seguir unas guías, de hecho si así fuera la mayoría de los proyectos tendrían éxito y el concepto de crisis del software estaría erradicado.

¿Tienen éxito la mayoría de los proyectos? Lo mismo tu respuesta es que precisamente no tienen éxito por no aplicar en ellos marcos de trabajo o metodologías. No quiero decir que no se hagan uso de ellas, sino de que sea excesivamente rígido con la forma en que se aplican y de que no se tenga en cuenta de que nuestro conocimiento y las técnicas que tenemos a nuestra disposición son herramientas que tenemos la posibilidad de aplicar o no en función de las necesidades del proyecto.

Anuncios

Prever contractualmente todo lo que puede pasar en un proyecto de desarrollo de software es muy complejo, acentuándose en proyectos de envergadura y/o de larga duración.

Precisamente ese es uno de los problemas que provoca desgaste en las relaciones cliente/proveedor salvo que las dos partes entiendan que por encima de todo está la colaboración entre las partes.

Sin esa colaboración el proyecto irá mal para ambos, ya que pequeñas victorias relacionadas con aspectos económicos después se terminan difuminando porque si los resultados finales no son los esperados, todos van a perder. Es cierto que es difícil que todos pierdan por igual, pero creo que el objetivo de un proyecto o de una colaboración entre entidades y equipos de trabajo no debe ser tratar de perder menos que el otro.

El objetivo debe ser ganar y ese objetivo se consigue si se establece un objetivo común entre todos los participantes en el proyecto. Es cierto que después habrá otra multitud de intereses tanto a nivel de organizaciones como de las personas que participan, pero si se consigue establecer la cultura de que si el proyecto sale bien lo más probable es que la mayoría de esos otros objetivos también se conseguirán de manera transitiva, las posibilidades de colaboración entre todos se incrementarán.

Y no solo se trata de ganar, se trata también de trabajar en un ambiente más adecuado, con menos desgaste, esto redundará en la calidad del trabajo de las personas y en consecuencia, del proyecto.

Me parece muy interesante la siguiente reflexión de Jim Horning: “La importancia de las especificaciones formales finalmente debe descansar en su utilidad en si o no se utilizan para mejorar la calidad de software o para reducir el costo de producción y mantenimiento de software”.

Al final, por tanto, es conveniente tener unos objetivos y medir si esas especificaciones, procesos y metodologías nos están llevando a los mismos y hacer las adaptaciones y rectificaciones que sean necesarias para alcanzar esas metas y también, ¿por qué no?, ajustar esos objetivos a la realidad de la organización, ya que, a veces, se pretende alcanzar unos umbrales que no se corresponden al contexto del mercado, de la organización, etc… o que requiere unos tiempos para alcanzarse que son superiores a las expectativas que se tienen.

No se trata de definir normas de desarrollo de software exclusivamente por el simple hecho de armonizar unos esquemas de funcionamiento de los equipos de trabajo o de las propias arquitecturas del software. Esto es importante y generalmente ofrecerá resultados, pero es conveniente plantearse si es posible mejorar, en qué y qué dirección y sentido se debe elegir para conseguirlo.

Como decía al principio, es importante, muy importante, medir y también recoger las impresiones de las personas que trabajan con esos esquemas de funcionamiento, es importante lo objetivo pero es interesante complementarlo con lo subjetivo porque no siempre se acierta con los indicadores que se miden o simplemente no se está midiendo bien.

A partir de ahí, retrospectivas, análisis y adaptación para que cada vez nos encontremos más cerca de las expectativas.

Los procesos y las metodologías delimitan un camino y eso de por sí restringe las posibilidades de actuación. Esto no es ni bueno ni malo de por sí, depende realmente de hasta dónde llegan esas restricciones y de las posibilidades que tenemos de hacer excepciones cuando el proyecto lo requiera.

Cuando un proceso o una metodología entran en un nivel de detalle alto nuestro margen de maniobra se reduce, si quien controla (en el caso de que haya alguien) el cumplimiento de la misma no permite excepciones nuestra frontera empieza y termina allí, esto podría ser interesante cuando tienes la mayor parte de los detalles de un proyecto bajo control pero sabemos que esas condiciones, prácticamente ideales, son complicadas de conseguir.

No se trata de elegir entre extremos sino de ser flexible ya que no siempre es problema de la rigidez de quién especifica los procesos, también es importante que nosotros seamos flexibles y entendamos que la organización también necesita gestionarse y que por ese motivo, a veces, se establecen ciertas premisas que aunque puedan no gustarnos los gestores entienden que son necesarias (aunque no por ello tienen que ser acertadas siempre).

Al final es cuestión de que todas las partes sean sensatas y no se posicionen en esquemas de funcionamiento que no se adapten a un contexto y a las necesidades del proyecto.

La calidad es el cumplimiento de las expectativas del usuario teniendo en cuenta que además:

– Una deuda técnica acorde al contexto en el que se ha desarrollado.

– Una tasa de errores y un grado de acabado de los requisitos no funcionales como por ejemplo rendimiento y seguridad en función de las características del producto que se ha desarrollado.

¿Y la documentación? La que requiera el proyecto y el posterior mantenimiento/uso del producto, ni más, ni menos.

Si la calidad se centra en el proceso y no en el producto, nos encontramos con esta situación (es posible que difieras con mi definición de calidad del software pero lo más probable es que esté centrada en el producto y no en el proceso).

El origen del mismo es la creencia de que a través del proceso se consigue la calidad del producto, algo que en el desarrollo de software solo se conseguiría en proyectos donde las personas son algo secundario y no aportan valor, como pueden ser adaptaciones simples de productos ya existentes.

El problema lo tenemos cuando en cualquier circunstancia se quiere aplicar esta estrategia para asegurar la calidad del producto final, lo que resta flexibilidad al proceso de desarrollo, limitando la posibilidad de elegir la estrategia o enfoque más apropiado, mermando además, la capacidad de adaptación al cambio, algo que resulta esencial en el contexto de incertidumbre que rodea al desarrollo de software.

Hay que tomar decisiones, lo fácil es que sea otro quien las tome por ti pero eso no siempre va a funcionar porque muchas veces serás el último eslabón de la cadena teniendo en cuenta, además, que estamos todo el día tomando decisiones.

A veces se tarda más de lo conveniente en tomar una decisión y cuando se toma, aunque sea acertada, resulta que es demasiado tarde y ya no sirve de nada. No tengo que daros ningún ejemplo porque cada uno de nosotros ha vivido esto en reiteradas ocasiones en primera persona.

Es cierto que no todas las decisiones son iguales y que en unas expones y arriesgas más que en otras y que las consecuencias tampoco son las mismas. En tu rol tendrás que tomarlas y asumir tus errores de la misma forma que te llenan tus éxitos. A veces los errores serán graves y tendrán consecuencias pero, ¿quién no ha tenido errores de este tipo? El desarrollo de software es complejo y no contamos con un mapa que nos guíe hasta el éxito del proyecto, en medio podremos equivocarnos y lo mismo nuestras acciones impactan en el resultado final del proyecto pero es parte del juego, parte de nuestra profesión.

Toma decisiones, equivócate, acierta, es parte de la vida misma y nuestro día a día personal y profesional.

Sobre esto Jerry Weinberg realiza la siguiente reflexión (traducción libre): “Si no puedes soportar ser un tonto público (quedar en ridículo), no vas a tener éxito en un rol en donde todas tus acciones son estudiadas al detalle”.

El enfoque clásico de desarrollo de software hace aguas en un entorno de incertidumbre como el que rodea a la mayoría de los proyectos. Me pide el cuerpo poner todos en lugar de mayoría porque la incertidumbre es inherente al desarrollo de software (desde mi perspectiva), otra cosa es que la misma pueda ser mayor o menor, materializarse sus riesgos asociados o no, sin embargo prefiero dejarlo así por no cerrar todas las posibilidades.

Y es que hacer predicciones partiendo de un conocimiento incompleto del problema y en un contexto que puede cambiar, incluso radicalmente, es muy complicado. No hay más que ver la gran cantidad de errores de estimación de esfuerzo y tiempo que se producen, incluso poniendo sobre la mesa la experiencia personal y un estudio previo del problema.

Como os he indicado en diversas ocasiones vengo de una formación clásica y de años trabajando con este enfoque y os puedo asegurar que no funciona. No quiero decir que sea imposible cumplir los objetivos, satisfacer las restricciones de plazo o de tiempo o satisfacer las expectativas del usuario, claro que es posible, generalmente con un gran desgaste de las personas implicadas en el proyecto porque las desviaciones no favorecen un clima de cordialidad y concordia. Sin embargo, lo habitual es que el proyecto y en consecuencia el producto se resienta.

Tal vez mi caso no sea muy representativo pero no hay más que mirar los resultados que se obtienen por regla general con este enfoque (no quiero decir que los otros enfoques sean infalibles) y seguro que no tienes que mirar muy lejos para hacerlo.