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.

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.

Siempre existe la posibilidad de que te toque la lotería (si la juegas) pero en el desarrollo de software lo mejor es no dejar cosas al azar.

Cuando de manera desestructurada “sueltas” a un conjunto de personas en un proyecto sin analizar si realmente tienen la capacidad para llevarlo a cabo, estás esperando prácticamente que el azar haga que las cosas vayan bien, para ello, sería necesario entre otras cosas que dicho grupo se autoorganizase de manera adecuada, fuera capaz de motivarse y ser más productivo y de tener la resistencia necesaria para hasta adquirir las habilidades requeridas (no solo técnicas) para sacar adelante el trabajo. Esa transformación es posible pero muy complicada.

Ese grupo, además, contará con muy poco apoyo de la organización, salvo que sus resultados sean lo suficientemente llamativos, ya que poco se puede esperar de quiénes han confiado de manera tan pobre en el proyecto y no le han dedicado lo que necesita.

En el caso de que ante tantos obstáculos se consiga el éxito hay algo de lo que no tendrá que preocuparse ese equipo y es el de levantarse temprano el día que repartan las medallas ya el día anterior los mismos que los pusieron en el disparadero se la habrán llevado todas.

La intención es la realización de acciones como resultado de una reflexión previa basada en hechos objetivos que pretende mejorar el producto (incrementar su valor) en cada iteración.

Conforme nos salimos de esta definición más nos acercamos al extremo opuesto, la prueba y error (no necesariamente malo porque habrá circunstancias donde se tenga que optar por esa estrategia).

La intención, por tanto, es tomar decisiones con una cierta base y si se acierta con ellas el ratio valor/número de iteraciones crecerá.

La intención se nutre del feedback, de nuestro background profesional y de nuestra interpretación del contexto actual y de su posible evolución.

La intención no supone conocer de antemano el éxito o el fracaso de la aplicación de las acciones, ya que de lo contrario estaríamos hablando de certezas, pero sí supone tratar de jugar con las mejores cartas ya que así existirán más posibilidades de acertar.

No contamos con presupuestos ilimitados y se quieren resultados acordes a la inversión realizada, más pronto que tarde, si no se desarrolla con intención, empezará a no existir un equilibrio entre coste y consecución de objetivos, conforme la distancia entre ambos se haga más grande más posibilidad hay de que existan conflictos entre usuarios y desarrolladores, entre cliente y proveedores, los cuales, a su vez crean resistencias que complicarán más, si cabe, el proyecto.

Aplicar prácticas teóricas fundadas en procesos y procedimientos que quedan muy bien en los libros (cuando vienen de libros) sin tener en cuenta cuál es la realidad de la organización, su contexto, de las personas que tienen que participar en los mismos, de la realidad económica existente, no traerán resultados acordes a la inversión realizada, no solo para implantarlas y controlarlas, que lo mismo no es el mayor gasto, sino por el hecho de cumplirlas, por el sobreesfuerzo que hay que realizar y por la reducción de la flexibilidad a la hora de afrontar un determinado proyecto.

¿Qué aportan realmente esos procesos? No todo va a ser negativo, probablemente algunos de ellos sean muy beneficiosos, pero, ¿y todos los demás?. Generalmente, en lugar de entrar en un proceso de mejora continua en el que se de valor a lo que resulta útil y se modifique, descarte o cambie el enfoque de lo que no funciona, se tiende a mantener una línea continuista con cambios poco significativos, ya que la respuesta ante la crítica o las quejas por los procesos, será no tenerlas en cuenta, creando una brecha cada vez más amplia entre quienes definen esos procesos y quienes los tienen que trabajar.

De esta forma se seguirá de espaldas ante la realidad porque no se debe ignorar a quién trabaja con esos procesos ya que nadie mejor que ellos saben si se adaptan o no lo que le toca vivir todos los días y al cumplimiento de los compromisos adquiridos.

No siempre van a tener razón los desarrolladores, a veces, no tienen en cuenta determinadas necesidades organizativas. No se trata, por tanto, de decir a todo que sí, sino de tratar de buscar soluciones consensuadas, de esta forma sí será posible buscar una alternativa rentable, sostenible y que genere menos desgaste, que se siga adaptando con el paso del tiempo a los cambios de contexto y necesidades.