Nota del autor

Si la entrada que estás leyendo carece de imágenes, no se ve el vídeo que teóricamente lleva incrustado o el código fuente mostrado aparece sin formato, podéis conocer los motivos aquí. Poco a poco iré restableciendo la normalidad en el blog.
Este blog es un archivo de los artículos situados previamente en Lobosoft.es y ha dejado de ser actualizado. Las nuevas entradas pueden encontrarse en www.lobosoft.es. Un saludo,
Lobosoft.

martes, 17 de febrero de 2009

ALM, la gestión del ciclo de vida del software

Esta mañana asistí, junto a unos compañeros, a un seminario sobre el ciclo de vida del software (ALM) desde la perspectiva de Microsoft, es decir, mediante el uso de las herramientas que Team Foundation Server y la familia de productos de Visual Studio Team System nos ofrecen.


La verdad es que he de manifestarme como un convencido de las metodologías y su repercusión en el buen resultado de los proyectos de desarrollo. De poco nos sirve contar con buenos desarrolladores si los continuos cambios de requisitos terminan por minar su autoestima y su convicción de que el trabajo que realizan es el adecuado. Es decir, si son profesionales sometidos a todas las ocurrencias que tan genialmente plasma Ender cada semana en su Sinergia sin control.


Volviendo al seminario que nos ocupa, el ponente, Hadi Hariri, recientemente laureado como MVP C# 2008 de Microsoft, afrontó los contenidos con una aproximación que me pareció muy adecuada: plantear los problemas y posibles soluciones desde la perspectiva de la adopción de metodologías ágiles como Scrum y el desarrollo guiado por pruebas (el archifamoso TDD), para después, sin obviar que existen otras herramientas disponibles gratis, o con menor coste, plantear cómo se afrontaría un proyecto de desarrollo con las que nos ofrece Microsoft, con una integración bastante adecuada entre ellas: la gestión de plantillas de proyecto, documentación (especificación de requisitos, o historias de usuario en metodologías más ágiles), la asociación entre tareas, código desarrollado, pruebas unitarias y control de código fuente, integración continua… Sin duda, todo lo que vimos ya está inventado, y en mayor o menor medida, con más o menos configuración, podemos conseguirlo con otras herramientas libres o más baratas, aunque lo cierto es que para desarrollos .NET, la suite de utilidades que nos ofrece Microsoft es bastante interesante, aunque también habría que sentarse a echar cuentas sobre las licencias que tanto software y equipo nos requeriría. Posiblemente para un equipo medio o grande, es una buena opción, pero para desarrollos sobre múltiples plataformas o un equipo pequeño el traje, creo, puede quedarnos algo grande.


También estuvimos viendo un poco lo que está por venir con Visual Studio 2010, su editor de código en WPF, el generador de diagramas de secuencia para los objetos, similar al generado por herramientas como SequenceViz, que probé hace unos meses y me pareció bastante interesante. Y, por último, asistimos a la generación de pruebas sobre la interfaz de usuario, funcionales y de integración, gracias a Microsoft Camano, una herramienta para testers que permite, entre otras florituras, la grabación de videos de pruebas con sus resultados, la reproducción automática de pruebas grabadas en modo “macro”, de forma similar a como se llevan a cabo con NUnitForms o Selenium, para aplicaciones web y WPF (de lo que deduzco que los fans de Silverlight tendrán también aquí motivo de alegría y diversión futuras).


En resumen, una más que interesante charla, que nos hace augurar un futuro a medio plazo bastante prometedor para todos aquellos a quienes nos gusta “cacharrear” con el software. ¿Y vosotros, habéis jugado un poco con la (algo inestable aún, eso sí) CTP de Visual Studio 2010? ¿Qué os parece la tendencia de Microsoft a “reinventar la rueda” (haciéndola, eso sí, un poco más redonda y aplicándole mejoras como los radios al invento :) )?

8 comentarios:

  1. Yo también soy muy partidario de asumir e intentar implantar una correcta gestión del ciclo de vida del software. Lo que ocurre en nuestro caso es que no realizamos grandes desarrollos software ni desarrollos homogéneos. Además, un día desarrollamos una aplicación para Android con Eclipse, la siguiente semana montamos una web con GWT y al mes picamos una pequeña aplicación de consola en .NET para testear stored procedures en MySQL. Como ves, hay para todos los gustos y colores...

    Por eso, aunque me han comentado que hay formas de conectarse desde Eclipse a Team Foundation Server etc., sigo manteniendo que las herramientas AML de Microsoft sirven únicamente si desarrollas 100% en .NET, con quien hay que admitir que la integración es perfecta. Además, doy por hecho que la licencia de TFS es carísima...

    Con este post me acabas de recordar que tengo que reactivar la búsqueda y hacer unas cuantas pruebas con algunas herramientas de software libre para ALM que encontré en su día, sobre todo para temas de SCRUM.

    SaludoX.

    ResponderEliminar
  2. ¡Buenas!

    Ahí le has dado. El tema de TFS lo veo idóneo para desarrollos .NET, ya que si desarrollas con otras plataformas la integración la tienes más complicada. Ahí optaría por una mezcla de xUnit (para el lenguaje que fuese) + TeamCity o alguna otra herramienta con la compilación automatizable mediante scripts de Ant o NAnt + Subversion (o similares). También es útil para proyectos en los que trabajan varias (o muchas) personas, es decir, para consultoras y grandes empresas de software, o no tan grandes pero que tengan una línea de productos bastante delimitada.

    En cualquier caso, el tema de las licencias (empieza a sumar: los Visual Studio TS, el servidor TFS, los SQL Server, el SharePoint, los Windows y Office varios...), y la poca apertura hacia otras plataformas (aunque según nos comentaron, se anda trabajando en un estándar de comunicaciones con otros sistemas, que permita el uso de distintas herramientas de forma intercambiable) creo que son los máximos impedimentos para adoptar a Team Foundation Server, por muy dotneteros que seamos, y a pesar de lo bien que parece funcionar.

    Sobre SCRUM y otras hierbas también quiero profundizar algo en breve, así como en TDD. A ver si comentándolo me "obligo" a ponerme con ello :D

    Un saludo.

    ResponderEliminar
  3. ¡Hola! Pues estaría bien eso de profundizar un poco sobre SCRUM, yo estoy interesado en el tema, de un tiempo a esta parte. Y también en cualquier tipo de alternativa libre a Team Foundation Server, pues siempre es útil recomendar cosillas gratis cuando te piden información... . La charla en la que has estado parece muy interesante :). Slds!

    ResponderEliminar
  4. ¡Buenas des!

    La verdad es que sí, SCRUM es muy interesante para los desarrollos, así como el uso de otras metodologías ágiles. Yo también tengo pendiente profundizar algo más en el mismo, de hecho aquí mismo en el blog y bajo "presión" vuestra, jejeje. Así que a ver si me pongo un poco con ello.

    En cuanto a alternativas a TFS, las hay, claro está. Requieren algo más de trabajo para la integración de unas herramientas con otras, pero resultan bastante útiles y efectivas. Así, sin tirar demasiado de memoria (aunque podría ser tema para otra entrada), podría sugerir:

    VCS: Subversion, suficientemente maduro y flexible.
    Sistema de seguimiento de errores/incidencias: Redmine (Me encanta).
    Integración continua: TeamCity (en efecto, no es gratis para desarrollos comerciales, y tiene sus limitaciones... aquí habría que buscar un poco más).
    Portal: Posiblemente MediaWiki, aunque ya que Redmine trae incorporada su propia wiki, tal vez un CMS más genérico como Drupal.
    Framework de pruebas: algún xUnit, según los lenguajes de programación que intervengan en el desarrollo.
    IDE: Eclipse, por su versalitidad.

    Como digo, un tema en el que sería interesante profundizar.

    ¡Saludos!

    ResponderEliminar
  5. Anda, Redmine es algo nuevo, no lo conocía. Subversion + Trac son mis herramientas de control de versiones y seguimiento de proyectos favoritas, traen lo esencial de forma magistral :) . Para wiki el mismo de Trac me vale, la verdad.

    ResponderEliminar
  6. Buenas.

    Personalmente, tanto con Trac como con Redmine (e incluso Mantis) me he enfrentado a nivel personal, bien jugueteando con ellos, bien con proyectos de menor envergadura en los que los he hecho encajar. En el trabajo, especialmente en uno anterior, utilizábamos JIRA a nivel de gestión de trabajos, integrándolo con Oracle+CVS+OpenCMS, y la verdad es que es muy configurable, pero con una licencia relativamente onerosa.

    De entre todos ellos, me gustó Redmine precisamente por el parecido que guarda con JIRA, aun siendo bastante más simple en su manejo y configuración, y extendiendo las funcionalidades que aporta JIRA con su wiki, un gestor documental e, incluso, una serie de informes que incluyen diagramas de Gantt y perspectivas de la evolución del proyecto. Además, está programando en Ruby, y me apetecía profundizar un poco en él.

    Lo que sí descubrí hace algún tiempo, y puede que resulte interesante a quienes deseen contrastar lo que ofrece cada uno de estos gestores de bugs y tareas, es una entrada en la Wikipedia que se dedica a compararlos. Dejo por aquí el enlace para aquellos a quienes pudiera interesar:

    http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems

    Saludos.

    ResponderEliminar
  7. Nosotros también utilizamos Subversion como sistema de control de versiones. Respecto a sistemas de issue/bug-tracking, en su día utilizamos de forma bastante activa "Flyspray" (http://flyspray.org/). Herramienta muy sencilla, incluso a nivel de instalación y configuración, la experiencia fue bastante buena, exceptuando los cabreos que te pillabas cuando alguien te asignaba bugs ;-).

    Por cierto, un par de taggeos interesantes relacionados con acceso opensource a Team Foundation Server:
    http://delicious.com/lonifasiko/tfs

    SaludoX.

    SaludoX.

    ResponderEliminar
  8. ¡Buenas!

    Pues voy a echarle un vistacillo a esos enlaces, y a Flyspray, que no conocía. ¡¡Gracias por la información!!

    Un saludo.

    ResponderEliminar