Abril 2008
L M X J V S D
« Mar   May »
 123456
78910111213
14151617181920
21222324252627
282930  

Publicando en el blog con Office 2007

Estoy escribiendo esta entrada desde Word 2007. No se trata de que esté escribiendo el artículo en sí, y luego use la herramienta de pegado desde Word que incorpora Wordpress, o que haga un “copy&paste”™ desde el mismo sino que, como curiosidad, quería explicar cómo podemos publicar directamente desde Word, escribiendo y pulsando en un botón que a tal efecto dispone el mismo. En cierto modo, se trata de una opción que ya proporciona software freeware como bloggar, que es el que suelo usar para publicar en los variopintos blogs por los que deambulo, pero puede resultar útil para aquellos que quieran amortizar el coste de la licencia que hayan pagado a Microsoft (¿porque lo habéis hecho, verdad?) por su copia legal de Office.

Bueno, vamos al grano. Publicar desde Word resulta tan sencillo como:

  1. Pulsar sobre el botón de inicio de Office (sí, el redondito de arriba a la izquierda), seleccionar la opción “Publicar” y, dentro de la misma, “Blog”.

  2. Usaremos el asistente que se despliega para configurar los datos de acceso a nuestro blog. Su URL (incluyendo el “/xmlrpc.php”, que no es más que el protocolo basado en RPC que permite la publicación remota, usando XML como sistema de codificación, y sobre HTTP para la comunicación). Daremos también los datos de login, para que Word pueda conectarse al blog.
  3. Vemos que Word muestra un nuevo grupo de opciones en un Ribbon especialmente preparado para la publicación en blogs.

  4. Realmente pueden gestionarse varios blogs, y podremos gestionarlos desde la opción “Gestionar cuentas”:

  5. En cualquier caso, lo interesante es que podemos escribir en el blog, como estoy haciendo ahora con éste. Permite indicar el título, insertar imágenes (una de las opciones a configurar es dónde y cómo almacena el blog las mismas). También podemos abrir los post que ya tenemos publicados o como borrador para editarlos.

  6. Podremos escoger la categoría del post, abrir existentes para su edición…

  7. Podemos ir guardando versiones del documento en la opción “Publicar – Publicar como borrador”. Cuando terminemos con la escritura, pulsaremos en el botón “Publicar” y… ¡listo! (Eso sí, monta un cirio con el HTML que genera. Después de publicar la entrada he tenido que entrar en Wordpress para “retocarla” un poco).

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:


Entradas relacionadas:
  • ALM, la gestión del ciclo de vida del software
  • Testing Experience
  • Pruebas de caja blanca automatizadas en .NET
  • El ascenso de Ícaro
  • Pruebas sobre la interfaz de usuario en aplicaciones Windows
  • Etiquetas: , , ,

    |