¿Qué es eso de las metodologías? ( I )

Una de las decisiones más importantes a la que nos enfrentamos en el inicio de todo proyecto es la elección de metodología a emplear; ¿cómo vamos a trabajar?. No es una decisión trivial, obviando muy a menudo esta pregunta, ya de de ella depende gran parte del éxito del proyecto.

Además, como veremos, elegir y aplicar una metodología implica un trabajo importante y suele implicar un cambio de mentalidad importante en las organizaciones, cosa que no siempre es fácil de conseguir.

Poniendo los cimientos: las buenas prácticas

Antes de empezar a profundizar en busca de una respuesta para esta pregunta debemos tener claro una cosa; el primer paso para aplicar una metodología es disponer de unas bases sólidas sobre la que se asiente; estas bases no son más que las buenas prácticas de desarrollo que todos deberíamos estar aplicando en nuestros proyectos.

Independientemente de la elección metodológica el uso de buenas prácticas es algo indispensable en todo proyecto de software. Conocerlas, saber cómo se usa y sobre todo aplicarlas es la base del éxito. Esta afirmación puede llegar a parecer muy obvia y lógica pero muy pocas empresas lo tienen tan claro, ya que no es nada habitual el uso de estas prácticas.

Algunas de las prácticas que deberíamos usar son:

· Disponer de una herramienta de control de fuentes. Disponer de esta herramienta es algo vital para poder realizar un buen trabajo en equipo. El gestor de fuentes hace de repositorio común para todos los miembros comunes, de manera que en todo momento el código está localizable en un único punto. Estas herramientas permite funcionalidaes de versiones, históricos o trabajo múltiples líneas de desarrollo. Adicionalmente, por ser un único punto para todo el código, en el punto ideal sobre el que hacer backups. Existen múltiples herramientas en el mercado que ofrecen esta funcionalidad, como SourceSafe, CVS, SubVersión o ClearCase.

· Disponer de una herramienta de gestión de incidencias. Tener constancia de las incidencias de mis desarrollos, saber el estado de las mismas, cuándo aparecieron, cómo se encontraron, cómo se corrieron….son puntos que deberíamos conocer en todo momento para poder conocer el estado del proyecto y poder tomar decisiones sobre él. ¿Cómo sabemos si estamos cerca de sacar una release si no tenemos una gestión de incidencias?¿Cómo podemos hacer una gestión de incidencias sin una herramienta adecuada?

· Automatizar las compilaciones de tu aplicación. En todo momento la aplicación completa debe poder compilarse sin ser un proceso traumático. Con un solo click, deberíamos poder disponer siempre de una versión de nuestra aplicación lista para poder ser desplegada.

Compilar de manera automatiza todo los días nos va a ayudar a detectar problemas de una manera rápida. ¿Quién no ha oído alguna vez la frase “Pues en mi máquina compila”? Es una frase muy habitual, que poco a poco deberíamos evitar, pero que si tiene que pasar, al menos enterarnos lo antes posible.

Pero este no es el aspecto más importante por el cuál hay que compilar de manera diaria, sino por la posible de poder realizar pruebas unitarias y pruebas de humo sobre la última versión de nuestra aplicación.

· Las pruebas unitarias y las pruebas de humo son un completo perfecto a las compilaciones diarias.

Las pruebas unitarias no es más que código que prueba otro código, pero que nos permite probar de una manera sencilla y periódica si nuestros desarrollos cumplen con lo que deberían hacer. Hacemos una vez un programa de pruebas y lo pasamos tantas veces como queramos.

Para los detractores de las pruebas unitarias diremos que escribir pruebas unitarias no es escribir el doble de código. Lógicamente, sí hay que escribir más código pero nunca el doble.

Si podemos hacer compilaciones y pruebas unitarias automáticas, nadie nos impide que las pruebas unitarias se pasen, también de manera automática, después de las compilaciones.

Del mismo modo, las pruebas de humo son una serie de pruebas funcionales que se deben pasar después compilar y desplegar nuestra aplicación para verificar el correcto funcionamiento de la misma.

Hacer este tipo de pruebas aumenta considerablemente la calidad de nuestros desarrollos y el descubrimiento temprano de errores, ya sean errores nuevos o regresiones a errores que ya se habían solucionado y ahora vuelven a fallar. ¿ Os suena la frase: “Pues esto funcionaba antes”? Con estas pruebas podremos evitar en gran medida esta frase.

· Escribir especificaciones, por pequeñas que sean es fundamental. Aunque en muchas ocasiones las personas más técnicas del grupo de desarrollo suelen ser reacias a escribir documentación ( igual hay que hacer que el Visual Studio sea también un editor de texto para que las escriban J ) es muy importante que lo hagan ya que ayuda a definir de una manera más clara qué es lo que debe hacer nuestra aplicación.

Escribir ayuda a tener que pensar y pensando se descubren situaciones que no se habían tenido en cuenta. Descubrir estas situaciones en esta fase reduce considerablemente el tiempo de desarrollo.

Para los que estéis interesado en conocer más sobre las buenas prácticas os recomiendo que echéis un vistazo al Test de Joel.

(http://www.joelonsoftware.com/articles/fog0000000043.html )

¿Cómo puedo empezar a usar buenas prácticas?

Muchos de vosotros en este momento os estaréis preguntado cómo podéis empezar a utilizar en vuestros proyectos estas buenas prácticas; ¿Qué herramientas tengo que usar?¿Cuándo me van a costar? Seguro que muy costoso usar todas estas herramientas..

Las dudas que pueden surgir pueden ser muchas, pero tenemos una herramienta de Microsoft para ayudarnos en esta labor; Team System. Este nuevo producto de Microsoft está orientado a la gestión del ciclo de vida del software y dispone de una gran variedad de herramientas y utilidades para que podamos usar en nuestros desarrollos; gestor de fuentes, gestor de incidencias, pruebas unitarias, compilaciones etc…

Independientemente de otras ventajas que ofrece Team System, seguramente más importante, destacamos la importante labor de integración que ha hecho Microsoft en este nuevo producto, ofreciendo de una manera integrada dentro de Visual Studio un gama muy amplia de herramientas necesarias para el día a día de nuestros desarrollos.

Muchas de las herramientas que incluyen ya existían antes de este producto y se podían ya utilizar pero lo importante es la integración; todas las herramientas se encuentran accesibles desde un único punto y se conocen entre ellas. Que se conozcan entre ellas es muy importante ya que podremos usaras de manera conjunta. Por ejemplo, sería sencillo poder compilar usando la última versión que esté en el gestor de fuentes y una vez compilado, pasar automáticamente nuestras pruebas unitarias.

Salvando los obstáculos del camino…

Llegado este momento más uno estaréis pensando que todo lo que hemos contado hasta ahora está muy bien, pero que es imposible que lo uséis en vuestras empresas. Entendéis que es necesario usar buena prácticas pero igual no está en vosotros la decisión de empezar a usarlas y la persona que puede tomar la decisión no entiende la importancia de usarlas y lo ve como un trabajo innecesario que no lleva a ningún lado.

Desgraciadamente este situación es muy habitual y aunque está cambiando poco a poco, el cambio el lento y largo. La resistencia al cambio es el factor más importante contra el que se tiene que luchar para poder empezar a aplicar este tipo de acciones que comentamos anteriormente. La decisión suele depender de personas que no llegan a comprender las necesidad de estas prácticas y que prefieren no “arriesgarse” usándolas y seguir como siempre, ya que mal o bien siempre se han conseguido terminar las cosas. Si os habéis fijado ponemos entre comillas la palabra “arriesgado”, porque aplicar buenas prácticas nunca se puede considerar un riesgo sino una manera de rebajar los riesgos en nuestros proyectos.

Tampoco podemos negar que partiendo de cero empezar a usar buenas prácticas no conlleve su esfuerzo inicial extra para el proyecto, pero lo debemos ver más como una inversión que como un gasto.

Una primera alternativa para solventar los las reticencias puede ser buscar un sponsor. Alguien dentro de la organización que sí que tenga poder de decisión y que pueda ayudarnos a realizar los cambios que necesitamos. Esta labor puede llegar a ser tan vital como tan difícil de conseguirla ya que muy pocas personas están interesadas en participar en procesos de mejora y tampoco se le puede robar tiempo al trabajo diario para poder afrontar esas mejoras.

Una segunda alternativa es comprar un sponsor. Es buscar a alguien y darle el poder suficiente para poder realizar los cambios que son necesarios. Este alguien es mejor que sea alguien de fuera, ya que está demostrado que cuando viene alguien de fuera suele caminar sobre las aguas y se le ve con más respeto y autoridad que a alguien de dentro de la organización. Esta opción también suele ser complicada de llevar a cabo, ya que para poder contratar a una persona de fuera es necesario disponer de la financiación necesaria para ello, cosa que no suele depender del equipo de desarrollo.

Existe un tercer camino más sencillo y que no necesita la ayuda de nadie pero que no nos sirva para implantar grandes cambios o cambios que se salgan del ámbito del proyecto. Actuar como el Caballo de Troya puede ser muchas veces la única alternativa que nos quede. Se trata de ir haciendo poco a poco cambios para mejorar día a día; si no tiene un gestor de fuentes, instálalo. Si no tienes un gestor de fuentes, instálalo. Son pequeños cambios que pueden mejorar nuestro trabajo e incluso podrían valer para poder llegar a conseguir un sponsor que vea que las mejoras que se han introducido son útiles y que siguiendo ese cambio se pueden conseguir más cosas.