archivo

Archivos Mensuales: junio 2011

La solución al desengaño por las metodologías no es prescindir de ellas y entregarse en manos del Cowboy Coding, donde en cada paso del proyecto se deciden las próximas acciones a ejecutar.

La solución pasa por encontrar la metodología que mejor se adapte al tipo de proyecto en el que vas a trabajar y eso es la suma de muchos factores: características del proyecto, del equipo de trabajo, del cliente, etc… Tal vez, como me ha sucedido a mi, el problema ha sido trabajar siempre con una determinada metodología (con los matices que le haya podido aportar a cada proyecto), afortunadamente y en lo posible le estoy poniendo remedio.

El Cowboy Coding cuando una trabaja solo puede dar resultados, no lo niego, pero cuando se trabajan con equipos de proyecto, con clientes, es necesario que exista un plan de trabajo, una referencia para todas las partes involucradas.

Si el plan de trabajo se escribe con el desarrollo del producto, todos los participantes en el proyecto tendrán la incertidumbre de cuál es el próximo paso a realizar, lo cual hace perder enfoque por parte de los mismos y se pierde capacidad de análisis.

Soy de la opinión de que la incertidumbre no le hace bien a los proyectos porque tiende a crear inestabilidad a las personas que intervienen y a sus departamentos. Para evitarlo se requiere la existencia de un cierto control y eso requiere una cierta predecibilidad en las acciones a realizar.

Una de las consecuencias más directas de la crisis del software es la crisis de confianza de todos los que participan en los proyectos de desarrollo de software.

De esa crisis de confianza la que más nos debería preocupar a los que nos dedicamos a esta profesión es la que tienen los usuarios finales y las organizaciones en las que trabajan.

¿Cuál pensáis que es la visión general que tienen los usuarios y los clientes de nosotros?, sé sincero y no te centres solamente en tus proyectos, sino en tu experiencia en el mercado.

Si queremos mejorar en reconocimiento, en que se valore realmente nuestro trabajo, en que los proyectos valgan realmente lo que valen, es necesario dejar atrás a la crisis del software. No es algo que podamos hacer solos, ya que se trata de toda una industria, pero detrás de esa industria están las personas que nos dedicamos a ella y todos podemos sumar para cambiar esa situación.

De hecho queremos hacerlo, la aparición de las primeras metodologías ágiles, el manifiesto ágil, la tendencia hacia lo artesano, el deseo por hacer las cosas bien, la orientación al cliente…

El camino será largo y difícil, pero no por ello deja de estar al alcance de nuestra mano.

Para tu organización puede ser ganar dinero, para el cliente puede ser informatizar un proceso para mejorar en productividad y eficacia, para tu jefe puede ser subir un par de peldaños más, pero para tu equipo el objetivo debe ser la satisfacción del usuario.

En realidad debería ser el objetivo de todos los que participan en el proyecto.

Con respecto al proveedor, hay que tener claro que quien tiene una empresa quiere beneficios y a ser posible mayores que los que tendría invirtiendo ese dinero en otros negocios, en renta fija, en bolsa, etc… Sin embargo, hay que tener en cuenta que los beneficios de hoy pueden ser las pérdidas de mañana y que las pérdidas de hoy pueden ser los beneficios de mañana.

Centrarse en los resultados de un proyecto concreto por lo que ha ganado o por lo que se ha perdido es un error, es una visión cortoplacista. Es necesario analizar cómo ha transcurrido el proyecto en su conjunto y cuál ha sido el nivel de satisfacción de los usuarios y del cliente.

Si el cliente y/o el usuario ha quedado insatisfechos, puede que los pierdas y ese beneficio que has obtenido en el proyecto, lo mismo mañana no es nada, porque te tocará buscar otro cliente, que lo mismo lo encuentras o no y si lo encuentras lo mismo resulta nefasto.

Si el cliente y/o el usuario quedan contentos, la puerta siempre quedará abierta. Si has tenido pérdidas, analiza los motivos, pero de la manera más objetiva que te sea posible, ¿por qué se han producido pérdidas?, ¿se ha presupuestado mal?, ¿quién ha presupuestado mal?, ¿el proyecto ha sido mal dirigido?, ¿el equipo de trabajo no ha sido productivo?, ¿se han pedido más cosas que las inicialmente previstas?, ¿se ha cambiado la orientación del proyecto a lo largo de su desarrollo?, ¿el problema ha sido la metodología?, etc…

Las causas pueden ser muchas y es necesario conocerlas, obtener un feedback que pueda ser útil para un futuro para la propia organización en sí, para el equipo de proyecto o para el trato con ese cliente o con ese tipo de clientes. Este análisis se debe hacer tanto perdiendo como ganando dinero, sin embargo, casi nunca se hace, lo cual te condena a repetir una y otra vez los mismos errores.

Se ha podido perder dinero, pero si se aprende de los errores, el enfoque para el siguiente proyecto puede y debe ser distinto. Para otro proyecto con el cliente, si parte del problema (sea mucho o poco) ha sido debido a él, es cuestión que se le plantee en el próximo trabajo las mejoras que se entienden que se deben realizar para que todos terminen contentos, este planteamiento debe hacerse con tacto y teniendo en cuenta la relación que se mantenga con el cliente.

Si piensas que el planteamiento es utópico es que tal vez no lo has intentado y si lo has intentado y el cliente o clientes no atienden a razones, es más que posible que no hayas tenido suerte con los que has trabajado, pero ten por seguro que en el mercado sí que hay clientes sensatos porque un modelo de desarrollo de software que tiene más posibilidades de salir bien es aquel en el que todos ganan.

Son términos que pueden dar lugar a confusión, de manera que se piense que más o menos hablan de lo mismo, pero no es así.

En el Cowboy coding, los desarrolladores actúan en cada momento como ellos entienden que deben hacerlo, de manera que no existe un proceso o metodología que los guíe. Es un modelo de funcionamiento de equipos de trabajo totalmente adaptativo, ya que nada hay más flexible que reescribir las reglas cada vez que sea necesario.

Esa flexibilidad en el funcionamiento de los equipos de trabajo y su capacidad de adaptación rápida a los cambios son rasgos comunes con las metodologías ágiles, sin embargo, la principal diferencia es que mientras que en un caso estamos hablando de ausencia de procesos de desarrollo, en el otro sí que los hay, sí que existen unas líneas maestras para desarrollar el software según la metodología elegida.

En las metodologías ágiles se marca un camino y dentro de ese camino existe una cierta flexibilidad o margen de maniobra para conseguir la máxima adaptación posible dentro de ese marco de trabajo a la naturaleza del proyecto a desarrollar. Sin embargo en el Cowboy coding, ese camino se va construyendo a la misma vez que se va realizando el proyecto.

La beta perpetua es un concepto relacionado con la web 2.0 y con el desarrollo de software siguiendo los principios ágiles.

Las aplicaciones que se pueden considerar parte de la web 2.0 se han caracterizado por su rápida respuesta a los cambios y por un feedback continuo de la comunidad de usuarios.

¿Hay alguna diferencia respecto a lo que se pretende con respecto a los desarrollos ágiles? En esencia ninguna. En ambos casos se pretende desarrollar un sistema que se adapte lo máximo posible a las necesidades de los usuarios y la clave para eso es el feedback y no hay mejor forma de obtenerlo que a través del uso que hacen los mismos de las aplicaciones en entornos de producción.

La beta perpetua no es más que considerar el software en fase beta durante un período de tiempo indefinido, pudiendo ser esa fase cerrada a un conjunto concreto o elegido de usuarios o bien abierta.

En cierto modo, cuando se realiza un desarrollo iterativo incremental, hasta que no tenemos una versión relativamente estable del producto, que no se obtiene hasta pasada una cuantas (bastantes) iteraciones, se podría decir que estamos ante una beta perpetua, lo que pasa es que lo que viste muy bien para la web 2.0 no resulta muy políticamente correcto utilizarlo en desarrollos de software con relación directa cliente/proveedor.

En mi organización vamos a realizar un estudio de una serie de sistemas de información (entre el 50 y el 75% aproximadamente de los mismos) con el objeto de detectar en ellos una serie de clases que pueden resultar conflictivas desde el punto de vista de la mantenibilidad.

Cualquier clase que cumpla alguna de las siguientes condiciones la consideraremos sospechosa (son solo métricas, que pueden encender determinadas alarmas, pero después resulta aconsejable revisar si existe justificación o no en que tomen esos valores) y será objeto de estudio con la finalidad de tomar una decisión sobre la necesidad de su refactorización:

1) Acoplamiento. Utilizaremos como base la métrica RFC de Chidamber y Kemerer.

RFC(clase)>=50 y RFC(clase)/Nº Métodos(clase)>=10

2) Cohesión. Utilizaremos como base la métrica LCOM4 de Chidamber y Kemerer.

LCOM4(clase)>=2

3) Complejidad Ciclomática de Thomas J. McCabe.

Complejidad Ciclomática(clase)/Nº Métodos(clase)>=10

Los valores anteriores por cada clase se obtendrán utilizando las métricas obtenidas a partir de Sonar.

En agosto de 2009, Bob C. Martin (Uncle Bob) propuso un quinto principio para el Manifiesto Ágil, denominado inicialmente como “Artesanía sobre mierda” (Craftsmanship over Crap), aunque más tarde cambió la denominación a unos términos más políticamente correctos “Artesanía sobre ejecución”.

La asociación del término artesanía al desarrollo de software surge como una necesidad, más que como una respuesta. De la necesidad de acabar con la entrega de productos de calidad deficiente, con la necesidad de terminar con las situaciones de desgaste con los clientes y con la necesidad de disfrutar con nuestra profesión.

Como dice Bob C. Martin, surge por la necesidad de hacer un buen trabajo. ¿Acaso no es satisfactorio ayudar a construir algo?, ¿no es más satisfactorio finalizar un proyecto con la sensación de un trabajo bien hecho?. Muchos piensan que lo importante es el dinero, tanto el que puede ganar uno, como el que puede ganar tu organización (porque al final, lo mismo te hace ganar a ti también), no le resto importancia a esa variable, pero somos también muchos los que además de dinero queremos algo más, sentir que lo que hacemos permite mejorar, a una organización, a sus integrantes, a la sociedad.

¿Puede ser utópico? Puede ser, pero me resisto a pensar, que solo somos máquinas de sacar trabajo adelante (bien, regular o mal).

La artesanía no va de la mano de un modelo concreto de organización, si bien existen estructuras empresariales que favorecen la creación de un contexto que favorece esta forma de trabajar.

La organización en la que se trabaja influye, pero al final todo depende de las personas, ya que al fin y al cabo somos el factor más importante en los proyectos de desarrollo de software.

Todo depende de las personas y este principio está orientado a las personas, a los que participan en el desarrollo y a los destinatarios de nuestros trabajos. Por tanto la artesanía, como medio para alcanzar estos objetivos, estará por encima de la ejecución, por encima de entregar productos por entregarlos, caiga quien caiga y pase lo que pase e intentar que sea el desgaste, las palabras, las que resuelvan los compromisos, en lugar de hacerles frente con la entrega de un producto en las mejores condiciones posibles.

Llegar a esto requiere un cambio de mentalidad de las personas que participan en los desarrollos, de la forma en que interactúan todas las partes que participan en un proyecto (clientes, proveedores, usuarios, etc…), de los procedimientos que se aplican, de la forma de organizar los equipos de trabajo, de favorecer la creación de un entorno que facilite el desarrollo de las personas, de la forma de vender los proyectos.

Es difícil porque los que estamos acostumbrados a otros modelos pensamos a veces que es imposible cambiar porque la espiral del desarrollo de software funciona de una determinada manera y no vamos a tener fuerza para salir de ella ya que son muchos años adquiriendo hábitos que resultan complicados de dejar atrás.

La proliferación de empresas o de profesionales independientes que tratan de enfocar su trabajo hacia lo artesano deja bien a las claras que cada vez son más las personas que están convencidas de que otro modelo de trabajo, más satisfactorio, es posible.