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

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 :) )?

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: