martes, 9 de diciembre de 2008

Cómo interpretar un burndown chart

En el artículo de hoy veremos cómo podemos interpretar los diferentes tipos de Burndown Charts que nos podemos encontrar en nuestro dia a dia. Como ya hemos visto en artículos anteriores el Sprint Burndown Chart es una herramienta muy útil para saber cómo va la evolución de nuestro proyecto de un solo vistazo. Así pués, es importante saber interpretar la información que nos dá para poder actuar en consecuencia.


Este es un burndown chart ideal. Sinceramente, nunca he visto uno así en la realidad : ). Es a lo que tendria que tender el equipo. Este BC indica que las estimaciones de tiempo se hicieron bien, que el equi

po ha podido trabajar y avanzar cada dia a la velocidad esperada y que a final de sprint se han conseguido realizar todos los puntos de historia planeados. Esto no quiere decir que el equipo no haya tenido impedimentos, pero si que indican que estos havian estado previstos en la estimación inicial, y que estos no han parado a todo el equipo, ya que cada dia se ha visto un avance. También indica que la separación en tareas ha sido buena, pudiendo definir tareas cortas que han significado un avance diario. Esto es lo que nos gustaria llegar a todos y por lo que tenemos que luchar.


Este BC lo que indica es que no se ha podido realizar toda la faena planificada, ni se ha modificado el sprint backlog para intentarlo. Este es un caso extremo ( se realiza un 10% de la faena ) pero es un tipo de BC que se suele dar. Las causas de este tipo de BC pueden ser varias: una mala estimación del sprint ( sobreestimación ), muchos impedimentos a lo largo del sprint, disminución del trabajo del equipo por enfermedad o similar, etc. Lo preocupante de este BC es que nadie ha hecho nada para intentar mejorarlo. Ni se han quitado los impedimentos, ni se ha reducido la carga de trabajo, ni se ha augmentado el equipo de trabajo. Un BC de este tipo tendria que hacer reflexionar tanto al grupo de trabajo ( ¿Qué les pasa a nuestras estimaciones? ) como al Scrum Master y al product owner ( ¿Porqué no he reaccionado a tiempo? ). Claramente es un BC a evitar.

Este BC ya nos gusta un poco más. El inicio del sprint es igual de malo que el anterior, pero a mitad de sprint el equipo ha visto que iba por mal camino. El descenso abrupto a mitad de sprint suele indicar que el product owner ha decidido sacar alguna história del sprint para intentar llegar a final de sprint de la mejor manera posible. También indica que se han eliminado impedimentos, ya que en la segunda parte del sprint el equipo avanza a una mayor velocidad. Es importante este tipo de modificaciones porque un escenario como el anterior deprime al equipo y este se pasa la mitad del sprint sabiendo que no se llegará al objetivo del sprint, cosa que puede hacer que su velocidad decaiga todavía más. Ayudando al equipo a poder cumplir con el objetivo del sprint, lo que ha hecho el product owner ( seguramente orientado por el scrum master ) ha sido mantener el equipo involucrado al 100% en conseguir el objetivo del sprint.

Este BC puede llegar a dar información tan negativa cómo el segundo que hemos visto. Si vemos un BC cómo este no tenemos porque pensar que somos los mejores desarrolladores del mundo, lo que tenemos que pensar es que es que también hemos estimado mal, y es prácticamente tan malo sobreestimar como infraestimar. Es importante que el equipo pueda hacer estimaciones realistas y que se cumplan los objetivos del sprint. De todas maneras, ni que sea por la imagen exterior que se dá, siempre es mejor este tipo de escenario que no un escenario de sobreestimación, ya que este último dá mala imagen del equipo. En el caso que el equipo consiguiera el mismo incremento de valor tanto en el escenario de sobreestimación como en este, la imagen del equipo es mucho mejor en este. Como se puede ver al final el equipo ha decidido añadir tareas de las no planificadas al sprint actual.


jueves, 13 de noviembre de 2008

SCRUM ( III )

En el artículo de hoy veremos las diferentes reuniones que se realizan a lo largo de cada uno de los sprints.


Reunión de inicio de sprint

Esta es la reunión de la que nos acordaremos más en el transcurso del sprint sinó la hacemos correctamente. Se realiza al principio de cada sprint, a poder ser un lunes por la mañana, cuando la gente está bien despierta y sin los agobios de toda la semana de trabajo. A ella acuden el dueño del producto, el scrum master y el equipo de desarrollo. La faena del dueño del producto ( como ya hemos visto en anteriores artículos ) es llegar a la reunión con el product backlog priorizado y detallado en sus histórias más prioritarias. En la reunión ( que acostuma a durar toda la mañana ) el dueño del producto explica al equipo cada una de las histórias que cree que van a entrar en el sprint y el entre todos se dedican a dividir la história en las diferentes tareas que la van a componer. Este diálogo es importantísimo ya que ayuda mucho a detallar exactamente lo que se va a implementar en el sprint y evita que al final del mismo haya malentendidos entre el dueño del producto y el equipo de desarrollo. De la misma forma, ayuda a detallar la história tal y cómo la entiende el dueño del producto, ya que el equipo puede creer que para implementar una tarea tiene que hacer un acceso a datos complicadísimo y en cambio el dueño del producto no lo cree necesario. Sin este diálogo, el equipo de desarrollo implementaria este acceso a datos, tardando un montón y haciendo código innecesario ya que el cliente no lo cree necesario.
En esta reunión, una vez detalladas las tareas, el equipo las debe estimar. Hay várias maneras de estimar una tarea, de las quales ya hablaremos algún dia. La estimación también ayuda mucho a refinar las tareas. En la estimación puede quedar reflejado que el equipo de desarrollo cree que para una tarea se debe hacer un algoritmo muy complicado y en cambio el dueño del producto quiere algo más simple. La estimación del equipo saldría con un valor muy alto, valor que sorprendería mucho al dueño del producto y se iniciaria otro diálogo para delimitar el alcance de la tarea.

Cómo podemos ver, aquí queda de manifiesto una de las cosas más importantes de las metodologías ágiles: la comunicación. Es muy importante la comunicación entre los miembros del equipo, desde el dueño del producto hasta los desarrolladores.

La reunión de planificación debe terminar decidiendo entre el equipo y el dueño de producto qué histórias entran en el sprint. Esto lo podemos hacer también de varias maneras ( que también veremos en otro artículo ) pero básicamente de lo que se trata es de estimar la velocidad del equipo en el sprint ( la cantidad de puntos de história que puede hacer el equipo ) y mirar qué histórias de usuario entran en el sprint. Si todavía no conocemos la velocidad del equipo la podemos intentar deducir. Primero asumiremos que un punto de história es el trabajo que puede hacer un desarrollador en un dia de trabajo ( no en un dia ideal, sinó en un dia "normal" ). Esta definición no es importante. Podeis utilizar la definición que queráis. Lo que es importante es que la definición la mantengáis constante a lo largo de la vida del proyecto. No puede ser que un dia utilicemos dias ideales y otro dia dias "normales".

Una vez aclarado esto, sumamos los puntos de história que puede hacer el equipo. Por ejemplo, si somos un equipo de cinco personas, tres de las quales estan a tiempo completo y dos a mitad de jornada, tendremos que en tres semanas el equipo puede asumir 60 puntos de história. A este valor, nosotros le aplicamos otro modificador, para intentar estimar los posibles impedimentos que podamos tener. Un valor normal puede ser un 70%. Por lo tanto, diremos que nuestro equipo es capaz de asumir 42 puntos de historia en un sprint. Teniendo ordenadas las histórias por prioridad, podremos ir viendo qué histórias nos entrarán en el sprint. Por ejemplo, si nuestras histórias hemos estimado que nos ocuparán 6, 10, 8, 12, 4, 8 y 12 puntos de história, decidiremos que haremos las primeras 5 histórias.

Hay dos cosas más importantes que deben decidirse en esta reunión:
  • El objetivo del sprint. Puede parecer superfluo pero és importante definir un objetivo del sprint para que el equipo sepa porqué está trabajando.
  • Definición de acabado. Cómo vimos en el artículo anterior, es vital tener una definición común de acabado entre el dueño del producto y el equipo de desarrollo.

Sprint diário

El sprint diário es la herramienta que nos proporciona scrum para que el equipo pueda compartir conocimiento y se comunique a diário. En esta reunión ( de unos 15 minutos en general cómo máximo ) cada miembro del equipo debe contestar tres preguntas:

  • Qué hice ayer.
  • Qué haré hoy.
  • Qué inpedimentos tengo para realizar mi trabajo.

Esta reunión es muy importante por la visibilidad que dá del proyecto y del trabajo de cada uno. Haciendo asistir a todo el equipo a la reunión evitamos que haya alguien que no haga nada durante un dia. El hecho de tener que decir delante de todo el mundo que no se ha avanzado en nada, hace que la gente trabaje cada día.

Esta reunión también nos sirve para tener el control del avance del proyecto. Gracias al sprint diario podemos actualizar nuestro tablero de scrum ( real o virtual ) y ver cómo avanzan las histórias, ver si tenemos demasiadas histórias en paralelo, demasiadas en testeo, etc. Lo otro que podemos actualizar gracias a la esta reunión es el gráfico de burndown, que nos dá una información muy visual del estado del proyecto y, sobretodo, de la velocidad del equipo, pudiendo ver de un solo vistazo si se llegará a final de sprint con todas las tareas realizadas o no.

Demostración

La penúltima reunión del sprint es la demostración. En la demostración el equipo de desarrollo debe mostrar a todo el mundo los avances realizados en este sprint, es decir, el incremento de valor que han dado al producto. Esto es muy importante porque el equipo se obliga a tener un producto que se pueda ensenyar, en un entorno de preproducción lo más fiable posible. También es importante porque el dueño del producto puede ver si lo que se ha implementado es lo que el pedía, si ha habido algún malentendido, si todo va a la velocidad requerida, etc. A esta reunión también puede asistir otra gente de la empresa, cuya opinión puede ser tenida en cuenta por el dueño del producto para planificar las próximas histórias a realizar. El equipo nunca debe sentirse influenciado por estas opiniones, ya que su interlocutor en qüestión de producto es el dueño del mismo.

Retrospectiva

Es la última reunión de cada sprint. En esta reunión se hace una revisión de cómo ha ido el sprint, qué ha ido bien y qué ha ido mal. Hay várias formas de hacer una retrospectiva. Una de las más habituales y rápidas es hacer una línea temporal en la pizarra e ir apuntando todo lo que se ha hecho en el sprint ( reuniones, impedimentos, logros, etc ). Una vez hecho esto, cada miembro del equipo señala aquellas cosas que le parecen más positivas y aquellas que le parecen más negativas. Las positivas se intentan repetir sprint a sprint. Las negativas se estudian porqué han ido mal y se intenta ver qué se puede hacer para solventar la situación y hacer que vaya mejor en poteriores sprints.


Mini reuniones de diseño

Estas reuniones no son obligatorias pero nosotros recomendamos hacerlas para no sobrecargar en demasía las reuniones de revisión diárias. Su cometido es comentar entre varios miembros del grupo de desarrolladores cosas relativas a decisiones de diseño de la aplicación. Por ejemplo si el miembro A del equipo empieza hoy la tarea "backup de datos de la aplicación" y no tiene claro cómo hacerla, en lugar de empezar una discusión de cómo hacerlo en la reunión de revisión, los miembros implicado se reunen a posteriori para hablar del tema.

Pués esto ha sido todo por hoy. Nos leemos en los comentarios!

martes, 11 de noviembre de 2008

SCRUM (II)

En este segundo artículo sobre Scrum veremos toda aquella "documentación" que generamos a lo largo de la gestión de un proyecto utilizando Scrum. Más allá de la propia documentación del proyecto cómo pueden ser manuales de usuario, archivos de ayuda, diagramas de diseño, etc, hablaremos de la documentación que se genera por el echo de utilizar Scrum. Dado que Scrum es un marco de desarrollo ágil y cómo tal prefiere el software que funciona por encima de la documentación exhaustiva, veremos que la documentación que generamos no es muy amplia aunque, eso sí, muy útil.

Product Backlog El product backlog es el documento donde se describen las histórias de usuario que se quiere que alguna vez esten presentes en nuestra aplicación. Es cómo la lista a los reyes magos. Este documento está mantenido por el dueño del producto, de echo mantener este documento es su principal tarea. Debe mantenerlo actualizado con las histórias que él crea conveninte y, sobretodo, lo debe mantener priorizado. El equipo tiene que saber siempre cuáles son las tareas más importantes para nuestro cliente ( es decir, que tareas tienen un mayor retorno de la inversión ) para así poder centrarse en ellas y dar el máximo valor posible en cada iteración.

Esta lista no tiene porque estar completa al principio del proyecto, de echo, dado que somos un equipo ágil y valoramos el cambio cómo una oportunidad, no nos importa que esta lista vaya variando a lo largo del proyecto. Tampoco hace falta que todos los elementos estén detallados de igual manera; los que tienen que estar más detallados són los que tengan mayor prioridad, los otros ya se irán detallando más adelante. De esta manera gastamos el tiempo del dueño del producto en las tareas más importantes a día de hoy, dejando las menos importantes para más adelante porque quien sabe si al final se van a realizar o se van a modificar.

También es importante acordar la definición de completado ( Definition Of Done - DOD). Sobre este tema, hay un montón de literatura. Cómo muestra os adjunto una imagen sacada del artículo How Do We Know When We Are Done? de lo que entiende el autor por acabado:

Como véis el autor define varios niveles de definición de acabado y es realmente detallista. Es importante tener una buena definición de acabado y que todo el mundo la tenga clara para evitar posibles desviaciones en nuestra estimación por no realizar todas las tareas necesarias.


Sprint Backlog
Es el documento resultante de la reunión de inicio de sprint. En él se detallan lo máximo posible aquellas tareas que se van a realizar en el sprint actual. Se describen con profundidad las histórias de usuario, se dividen en tareas y se estima su esfuerzo. Son estas tareas las que compondran el sprint backlog. Durante el desarrollo del sprint, cada miembro del equipo seleccionará una tarea de entre las más prioritarias cuando acabe de realizar la actual. Esta lista la tendremos que ir manteniendo dia a dia en la reunión de sprint diaria actualizando el estado de las tareas ( no empezada, empezada, acabada ) y actualizando también las horas restantes de desarrollo. Esto nos permitirá mantener los siguiente documentos que pasamos a explicar.

Tablero de scrum
Este tablero nos indica el estado actual de nuestras tareas. Vemos que se compone de una cuadrícula compuesta por filas ( las histórias del product backlog ) y columnas ( el estado de las tareas ). El equipo de desarrollo debe actualizar dicho tablero cada dia en la reunión diária y así todo el mundo puede tener una visión rápida y exacta de cómo se está desarrollando el sprint. También podemos incluir en el tablero las tareas que no estaban planeadas y que se han acabado realizando y las próximas histórias del product backlog, por si acabamos las planeadas inicialmente.
( Imágen extraída del libro Scrum y XP from the trenches de Henrik Kniberg )

Sprint Burndown Chart

En el tablero de sprint también pondremos el sprint burndown chart. Este gráfico nos indica de una manera muy visual cuál es la velocidad del equipo y nos permite vislumbrar si el equipo acabará todas las tareas en el tiempo marcado. Cada día, en la reunión de sprint, el equipo actualizará el tablero de sprint con los datos de avance de estas tareas. Estos datos de avance ( las horas que le quedan a cada tarea ) también se pondrán de manifiesto en el gráfico, haciendo una línea desde el punto de las horas que quedaban por hacer ayer y las que quedan por hacer hoy ( ya que hemos restado las que hemos echo ). Esto, si lo comparamos con la línea ideal que se dibuja desde el punto de máximas horas del dia de inicio de sprint, al punto de horas cero en el úlitimo dia de sprint nos dá información sobre si el equipo avanza a la velocidad adecuada o no. En próximos artículos ya hablaremos de cómo analizar un gráfico de avance.

Y por hoy esto es todo. Nos leemos en el próximo artículo!

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!