domingo, 26 de octubre de 2008

SCRUM (I)

Qué es SCRUM

Scrum es un marco de trabajo para el desarrollo ágil de proyectos de software, aunque lo podéis aplicar a cualquier otro ámbito. Si quereis gestionar vuestra vida de pareja con Scrum, adelante!

Scrum, cómo buena metodología ágil y moderna divide el trabajo en iteraciones, a las que llama sprints, que generalmente se alargan entre 2 y 4 semanas. Cada sprint parte de un conjunto de histórias de usuario ( el llamado product backlog ) de las que el equipo de desarrollo con la ayuda del product owner y en la reunión de inicio de sprint escogen aquellas que entraran en el sprint, decidiendo así el sprint backlog. A lo largo del sprint el equipo realiza una reunión diária ( sprint daily meeting ) en la que cada miembro describe el estado de su tarea. Al final del sprint se realiza una demo para mostrar el avance del proyecto en el sprint y después una reunión para evaluar el sprint y su desarrollo ( sprint review meeting ). El objetivo de todo esto es poder entregar un incremento de valor del producto al cliente cada cierto periodo de tiempo de una manera regular.

Si todo esto os suena a chino, no os precupéis que ahora lo vamos detallando un poco.

Los actores de Scrum

Antes de ver cuáles són los diferentes roles en un equipo de Scrum os voy a contar un cuento. Resulta que un dia se encontraron una gallina y un cerdo en el campo. La gallina le dijo al cerdo: He tenido una idea. Vamos a montar un restaurante entre tu y yo. El cerdo le preguntó que cómo se llamaría el restaurante, a lo que la gallina le respondió que huevos con jamón. Cuando lo escuchó el cerdo desestimó la idea alegando que el estaria realmente comprometido con el proyecto, mientras que la gallina sólo estaria involucrada. Si aplicamos esto a Scrum, significa que los desarrolladores són los cerdos ( con perdón :D ) y son los que están realmente comprometidos con el avance del proyecto, ya que son los que lo desarrolan, mientras que la demás gente son gallinas, y aunque de alguna manera u otra están involucrados en el proyecto no estan tan involucrados como los desarrolladores.

Scrum define básicamente tres roles: El equipo, el scrum master ( o facilitador ) y el product owner.

Product owner
O propietario del producto. Es el encargado de mantener el product backlog ( la lista con las historias de usuario ) actualizado y priorizado. Representa al cliente y está presente con voz y voto en la reunión de inicio de sprint para explicar al equipo de trabajo las historias con detalle y llegar a un acuerdo con este sobre las que entran en el sprint backlog.

Equipo de desarrollo
Son los más cerdos de todos ( en el sentido scrumiano de la palabra ). Són los responsables de desarrollar el proyecto. Se reunen con el product owner para aclarar todas las dudas sobre las histórias, estiman lo que van a tardar en hacerlas y se reunen cada dia con el scrum master para controlar el avance del proyecto. Al finalizar el sprint, realizan la demo para mostrar el resultado de su trabajo y se reunen con el scrum master para hacer la evaluación del sprint.

Scrum master
O facilitador. Es el encargado de hacer todo lo posible para que el equipo de desarrollo pueda realizar su faena de la mejor de las maneras. Es su representante en el exterior. Se encarga de eliminar todos los problemas que pueda tener el equipo y de hacer que las reglas de Scrum se cumplan.

El resto de personajes que puedan estar en el proceso son las gallinas de nuestra historia. Pueden asistir a las reuniones pero no tienen voto en ninguna de ellas y voz en muy pocas. Entre estas gallinas podemos encontrar a otros grupos de desarrollos, gente de la empresa interesada en el proyecto, comerciales, etc. Pueden dar su opinión, en ocasiones muy valiosa, pero no pueden interferir en el desarrollo del proyecto.

Y por hoy ya está todo. En próximas entregas veremos la documentación asociada y las diferentes reuniones. Nos leemos!

domingo, 19 de octubre de 2008

Implantando una metodología ágil

Implantar una metodología ágil en una empresa no es fácil. Desde nuestra posición de desarrolladores se pueden hacer algunas cosas pero es importante tener un jefe que te permita ciertas licencias. Si este es tu caso, siempre tienes posibilidades de llegar más lejos en tu implantación.

Aqui vienen algunas directrices desde nuestra pequeña expieriéncia en nuestra empresa. Quizá no es el mejor modo de hacer las cosas, pero es el que nosotros hemos podido hacer dentro de nuestras posibilidades. Esperemos que te sirva de ayuda.
  • Implanta un repositorio de código: Si quieres hacer trabajo colaborativo, que el hacer merge de tu código con el de tus compañeros no sea un infierno en el que se pierden funcionalidades y mucho tiempo, si quieres recuperar versiones anteriores sin dificultad, esto es lo primero que debes hacer. Y lo mejor de todo es que no hace falta que te gastes un duro. Puedes, por ejemplo, utilizar subversion. Si todavía te quieres complicar menos la vida, instala el servidor de subversion llamado svnserver. Y sobretodo, aprende a utilizar bien el repositorio de código. Si no lo haces puedes perder el trabajo de varias horas de trabajo y lo que conseguirás es justo el resultado contrario: no vas a poder implantar la metodología.
  • Empieza a programar testeos unitarios en tu código: Al principio verás que tu velocidad de programación se reducirá bastante ( puede llegar a descender hasta un 50% ) pero a medio plazo ( o incluso a corto plazo ) verás que tener tu red de seguridad de los tests unitarios es una gozada. Puedes refactorizar el código, hacer canvios en el diseño, hacer pequeños cambios en el código o lo que quieras, que siempre sabrás que tu código cumple con lo que especifican los tests. No hace falta que hagas TDD, con hacer los tests después de programar hay suficiente.
  • Porque no pruebas SCRUM? O alguna otra metodología ágil. Nosotros te recomendamos esta, que es la que intentamos implantar. Te será dificil al principio concienciar a tus jefes de seguir esta metodología al pie de la letra, pero poco a poco los irás convenciendo. Intenta ser estricto en su utilización. Programa las reuniones de inicio de sprint, utiliza planning poker para tus estimaciones, decide la duración de tu sprint, decide qué cosas entran y cuales no en tu sprint, programa un dia para la demo y diselo a todo el mundo. Haz las reuniones diárias y que estas no se alarguen en demasía. Haz la demo el dia que has programado y haz después una reunión de revisión de sprint.
  • Implanta un sistema de integración continua: Algo muy importante para mejorar el rendimiento de tu equipo es la detección temprana de errores. Junto con el testeo unitario, otra de las herramientas claves para conseguirlo es la implantación de un sistema de integración continua (CI). Puedes hacer que cada vez que alguien sube código al repositorio, el servidor de CI inicie una compilación del código, pase los tests programados y te enviee el resultado de todo esto. Así puedes saber al momento si una modificación hecha por algún desarrollador ha roto la build.
  • Conciencia a tu equipo de las bondades de las metodologías ágiles: todo el equipo tiene que estar concienciado en este nuevo camino. Si no motivas al equipo, no notarás el avance en la implantación. Si la gente no es consciente de que todo lo que se está haciendo es para mejorar el trabajo de todo el mundo no se esforzarán lo suficiente en hacer todo lo que se propone. Es importante que entre todos paséis el abismo que se abre al implantar una nueva forma de trabajar para poder avanzar a mayor velocidad.
  • Documentate: Lee mucho. Sé critico con tu trabajo y también con lo que lees. Aprende de la expieriéncia de la gente que lleva muchos años más que tu implantando este tipo de cosas. Documéntate sobre otras metodologías y evalua cual se adapta mejor a tu entorno. Habla con tu equipo, con tus jefes y con todo el mundo que puedas sobre tus ideas. No intentes imponer nada, sinó que intenta que todo el equipo sea quien toma la decisión.
Bueno, estos son sólo unos pequeños consejos que provienen de nuestra experiéncia. No los tomes al pie de la letra, cada uno tiene un equipo distinto, trabaja en una empresa distinta, tiene unos jefes distintos, etc. Tampoco hace falta que los implantes en este orden. Este es el orden en que lo hemos hecho nosotros y por ahora nos va bastante bien ( por lo menos sobrevivimos! ).

Nos leemos en el siguiente artículo.

domingo, 12 de octubre de 2008

Procedimientos almacenados en Firebird

Todo gestor de base de datos que se precie ofrece a los usuarios la posibilidad de programar procedimientos almacenados. Firebird no podía ser menos, así que en este artículo veremos cómo crear dichos procedimientos y cómo llamarlos desde nuestra aplicación .Net.

Creación

Veamos un pequeño ejemplo de procedimiento y después pasaremos a comentarlo línea por línea.

CREATE PROCEDURE FILL_MOVIE ( PARAM1 INTEGER )
AS
DECLARE VARIABLE VAL INTEGER;DECLARE VARIABLE CNT INTEGER;
begin
DELETE FROM MOVIE;
val = 0;
val = GEN_ID (GEN_MOVIE_ID, val - GEN_ID (GEN_MOVIE_ID,0) );


Cnt = 1;
WHILE (Cnt <= 3) DO BEGIN INSERT INTO MOVIE (TITLE, DIRECTOR,YEAR) values('Trainspotting','Danny Boyle', '1996'); Cnt = Cnt + 1; END suspend; end


Este pequeño procedimiento lo que hace es insertar tres veces la película Trainspotting en nuestra base de datos.

En la primera línea del procedimiento estamos creando el mismo, indicándole su nombre y si tiene parámetros, tanto de entrada cómo de salida, el nombre y el tipo de los mismos. En la siguiente línea, y siempre entre el AS y el BEGIN ponemos la declaración de las variables que se utilizaran en el procedimiento. Esta declaración se realiza mediante las palabras reservadas DECLARE VARIABLE seguidas del nombre de la variable y su tipo.

Ya en el cuerpo del procedimiento, lo primero que se hace és borrar el contenido de la tabla MOVIES y resetear el generador de identificadores asociado a la tabla. Cómo no existe ninguna función para establecer directamente el valor de este generador, deberemos llamarlo pasándole como incremento su valor actual en negativo.

Una vez hecho esto, pasamos a realizar un bucle utilizando un WHILE donde haremos el INSERT y actualizaremos el valor de la variable CNT.


Llamada desde .Net

Una vez tenemos hecho el procedimiento, es hora de poder llamarlo desde nuestra aplicación .Net. Para hacer esto nos ayudaremos de la libreria para acceder a Firebird desde .Net. Desde nuestras clases de acceso a datos, deberemos crear una nueva función enargada de llamar a un procedimiento remoto. Esta función será prácticamente igual a la que tengamos para ejecutar un ExecuteNonQuery, con la salvedad que antes de hacer la llamada, deberemos establecer el tipo de comando a StoredProcedure.

private int ExecuteStoredProcedure(string pNameStoredProcedure, bool pIgnoreError)
{
try
{
using (FbConnection connection = new FbConnection(Connection.ConnectionString))
{
int result = 0;
connection.Open();
FbTransaction transaction = connection.BeginTransaction( IsolationLevel.ReadUncommitted);
if (transaction != null)
{
FbCommand command = new FbCommand(pNameStoredProcedure, transaction.Connection, transaction);
command.CommandType = CommandType.StoredProcedure;
result = command.ExecuteNonQuery();
transaction.Commit();
}

connection.Close();
return result;
}
}
catch (Exception e)
{
Tracer.WriteLine("ExecuteStoredProcedure : '" + pNameStoredProcedure + "'. Missatge: " + e.Message);
return -1;
}
}


return 0;
}

Y hasta aquí este pequeño tutorial. Espero que os sea útil. Para cualquier duda, nos leemos en los comentarios!