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.
Mostrando entradas con la etiqueta RUP. Mostrar todas las entradas
Mostrando entradas con la etiqueta RUP. Mostrar todas las entradas

domingo, 21 de septiembre de 2008

Usando Java desde .NET

En los fines de semana aprovecho –como todos, imagino- para ponerme al día con todo aquello que, por un motivo u otro, no he podido hacer durante el resto de la semana. Esto incluye todo tipo de lecturas (entre las que se incluye la que os comento al final de la entrada) y pruebas que quiero realizar de nuevo software: aplicaciones, sistemas operativos… o como es el caso de hoy, unas librerías y una máquina virtual. En concreto, hablo de IKVM.NET, una implementación libre de Java para Mono/.NET Framework. Posiblemente recordaréis la batalla legal que establecieron Sun y Microsoft hace unos años (una de tantas) sobre el particular uso que de Java hacía la compañía de Redmond, modificando a su antojo las particularidades del lenguaje. También hubo conflictos en si Windows XP bloqueaba o no el uso de Java, y a resultas de todo aquello, Microsoft dejó de poder usar Java (al menos, distribuir un Java “modificado”), y esto supuso el lanzamiento de la plataforma .NET (“su” Java modificado ;) que, de paso, incluye entre sus lenguajes J#, que es compatible a nivel de sintaxis con Java). La cuestión es que, como siempre, los desarrolladores y usuarios de los sistemas somos los perjudicados ante estas diferencias, ya que nos encontramos con decenas de entornos similares ante los que decantarnos, habitualmente según lo haga también el mercado. En la variedad está el gusto, dicen, y no afirmaré lo contrario, pero en ocasiones resulta engorroso encontrar soluciones parciales a nuestros problemas, porque parte de lo que necesitamos está en un lenguaje, otra parte en otra, y debemos habilitar todo tipo de mecanismo de interoperabilidad entre esos sistemas heterogéneos para conseguir alcanzar nuestro objetivo.


Pero bueno, comencé diciendo que iba a hablar de IKVM.NET y, como siempre, comienzo a divagar. La herramienta de que os hablo consta de una máquina virtual Java implementada completamente en .NET, así como una implementación de las librerías Java en .NET y diversas herramientas que permiten la interoperabilidad Java-.NET. La instalación es muy simple, basta con descargar el instalador y ejecutarlo. Una vez hecho esto, nos será posible escribir aplicaciones en Java usando ensamblados .NET y que serán compiladas como CIL, o reutilizar código en Java desde .NET. También es posible convertir archivos .jar a ejecutables .NET usando una herramienta que incorpora el paquete de IKVM.NET. Posiblemente tenga oportunidad de hacer un uso mayor del mismo en alguna aplicación real dentro de poco, por lo que ya os iré comentando mi parecer si me encuentro con algo "extraño". De momento, un hola mundo en Java funciona desde .NET :) .


Aún me queda por probar Moonlight, el port de Silverlight a Mono. Aunque voy a ver si convenzo a mi amigo Fernando, de Albloguera, para que rompa su prolongado silencio con alguna entrada sobre este asunto ;) .


¡Ah, y no se me olvida! La lectura que os comentaba la encontré ayer revisando posts que había dejado de lado durante la semana. En Pensamientos Ágiles comentaban un artículo de InfoQ sobre el uso de piezas de Lego (cuyas figuritas, por cierto, cumplían 30 años hace unos días) para la gestión ágil de proyectos. Esto, que podría parecer un absurdo o una extravagancia (ahora lo llaman frikismo :) ), tiene realmente su interés. Por lo que he podido leer al menos, el uso de estas piezas para definir tareas y “encajarlas” según las dependencias entre éstas y su prioridad da una visión rápida de lo que tenemos pendiente. Al menos, resulta mucho más claro a golpe de vista que una pizarra llena de postits. En cualquier caso, se trata de una interesante aproximación al tema del desarrollo ágil del software, tan en boga (y con razón) en nuestros días.

jueves, 17 de abril de 2008

Introducción a Scrum

Sebastian Chabal y Scrum


La solidez del equipo de rugby, con su líder alerta ante las presiones del entorno es una de las bazas de la metodología de desarrollo Scrum, tal y como refleja la imagen superior. Scrum proporciona un conjunto de reglas para proveer dicha protección y una mayor comunicación entre los miembros del equipo, y recibe precisamente su nombre del de la formación en que se disponen estos jugadores. Está inscrita dentro de las metodologías ágiles, entre ellas Extreme Programming (XP), y sus valores derivan del Manifiesto Ágil.


En cualquier caso, la intención de esta entrada es dar una breve introducción a Scrum, aunque que existen varias muy completas y accesibles que pueden encontrarse al pie del artículo, pero en este caso pretendo estudiarlo desde la perspectiva de la integración de Scrum con Test-Driven Development (TDD) y el Rational Unified Process (RUP).


La definición que para RUP tiene la Wikipedia es:




Un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.


El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Por otro lado, TDD ya es conocido por los lectores del blog, y se trata de una metodología de desarrollo que basa el mismo en la guía mediante pruebas unitarias del software. De este modo, tenemos un proceso de desarrollo, RUP, que consta de cuatro fases (Concepción, Elaboración, Construcción y Transición), unas directrices proporcionadas por Scrum, y una metodología que es la aportada por TDD. ¿Cómo encajar todo esto en una organización en la que está implantado RUP? Lo primero, como ya apuntaba en su día respecto a la implantación de TDD en la empresa, es comenzar por pequeños equipos que actúen como motor de transición para el resto de la organización. Además, a esto se suma que Scrum está especialmente indicado para equipos que consten de 7 a 15 miembros, aproximadamente. Comenzaremos, ya que introdujimos TDD en su día, a hacer lo propio con Scrum, para ir ampliando tanto uno como otro en sucesivas entradas.Ante todo, debemos tener claro que Scrum plantea ciclos de desarrollo de unos 30 días, y define unos roles muy específicos en todo el proceso. Comenzando por los roles, tendremos:

  • Cliente: en efecto, es quien piensas :).

  • Product Owner: muy cercano al cliente, o un miembro de la organización que conozca claramente el producto y los requerimientos asociados al mismo.

  • Scrum Master: similar al jefe de equipo, se encargará de definir tareas, y será el “paraguas” que cubrirá al equipo de desarrollo, evitando que se interfiera en el proceso de desarrollo.

  • Scrum Team: el equipo de desarrollo. A sus miembros se les suele denominar cerdos (pigs). Antes de que nadie se ofenda, diremos que en Scrum hay dos tipos de individuos: los cerdos, que se comprometen con el desarrollo, y las gallinas (chickens), que se involucran, tienen interés en el producto, pero no se implican. La mejor explicación que he encontrado para estos roles es la siguiente tira cómica:



060911-scrumtoon-spanish.jpg






En cuanto a las actividades definidas por Scrum, tenemos:

  • Product Backlog: donde el Product Owner define los requisitos, las nuevas funcionalidades y errores a subsanar.

  • Sprint Planning Meeting: El Product Owner se reúne con el Scrum Master y el Scrum Team. Definen DE FORMA REALISTA, last areas a realizar durante los próximos 30 días.

  • Sprint Backlog: Durante 30 días se desarrolla para conseguir alcanzar los objetivos, definidos en la Sprint Planning Meeting. Diariamente el Scrum Master se reunirá con el Scrum Team (Daily Scrum Meeting), para dar respuesta a tres cuestiones, para cada miembro del equipo:

    • ¿Qué he hecho desde la última reunión?

    • ¿Qué haré hasta la próxima?

    • ¿Existe algún problema que me impida cumplir con las tareas asignadas?






El Scrum Master deberá actuar como paraguas del equipo, evitando que se interfiera en el trabajo. Durante todo el Sprint Backlog no se redefinirán tareas, ni se incorporarán cambios. Al finalizar los 30 días, existirá un entregable. El Product Owner podrá hacer una presentación del mismo a los clientes o directivos de la empresa. Se llevará a cabo otra reunión, de forma retrospectiva, como evaluación del Sprint Backlog, para ver el grado de alcance de los objetivos fijados, y cuáles han sido los logros y problemas encontrados (lecciones aprendidas).

Se volverá a entregar un nuevo paquete de trabajo del Product Backlog, y se comenzará un nuevo ciclo de Sprint Backlog.





En los sucesivas entradas iremos viendo cómo integrar estos ciclos con TDD y, a mayor escala, con RUP en toda la empresa.

Para saber más: