DEVNETTIPS

Mi AOS2011

2011-06-23T08:36:00.000+02:00

Me encantan los Open Spaces. Mi primera experiéncia fue en Buenos Aires en marzo de 2009, y supuso una revolución para mi en la forma de encarar la organización de eventos. El segundo fue el del año pasado en Barcelona, en el que, a parte, participé en la organización. Y este fin de semana se realizó el Agile Open Spain 2011 en Pamplona, al que no podia faltar. Como siempre me encontré allí a un montón de amigos, aunque la novedad de este año fue poder ir acompañado de casi la totalidad de la gente de la oficina de Plain Concepts en Bilbao.

Una de las razones por las que me encantan los Open Spaces es porque creo que ejemplifican a la perfección el espiritu del agilismo. Es un evento hecho por la comunidad para la comunidad. Por supuesto que necesita un comité organizador ( y que lo hicieron a la perfección ) para todo el tema logístico, pero la "chicha" del evento, las 36 charlas que hubo, fueron un trabajo de los miembros de la comunidad para los miembros de la comunidad. Se formaron 36 equipos enfocados en dar el máximo valor posible a las charlas.

Yo propuse una charla sobre calidad del código que fue bien recibida y que creo que estubo bastante bien, aunque no se tocaron todos los temas que me hubieran gustado. La discusión se centró sobretodo en la cobertura de tests y en los comentarios en el código. También se habló de los equipos de QA.

Por otra parte asistí a charlas tan variopintas como Stubs, Mocks y Spies, taller práctico de histórias de usuario, talento, estimaciones, deduda técnica y romper la rutina.

Por encima de las charlas en sí ( que podéis ver en detalle en los diferentes resúmenes hechos por los participantes ) yo me quedo con las personas que asistieron al evento. Se reunieron 150 personas preocupadas por su profesión, con ganas de mejorar su entorno, con ganas de hacer cosas para ellos y para los demás y comprometidos con la excelencia.

Espero ya con ganas el Agile Open Spain del año que viene, en el que espero veros a muchos de vosotros.

Un saludo!

Instalar una plantilla metodológica en castellano en un TFS2010 en inglés

2011-06-23T08:35:00.002+02:00

Puede darse el caso que tengamos un TFS 2010 instalado en inglés pero nos interese cargar una plantilla metodológica en castellano. Nuestro primer impulso será cargar la plantilla metodológica sin hacer ningún cambio en nuestro servidor y crear un proyecto con ella. A veces es bueno seguir los impulsos, así que vamos a ello.

En nuestro querido Visual Studio 2010 vamos al menú Team y abrimos el Process Template Manager:

Y seleccionamos nuestra plantilla para cargar. Se carga la plantilla correctamente y se nos añade a la lista de plantillas disponibles.

Una vez cargada la plantilla ya podemos crear un nuevo Team Project con ella, así que creamos un Team Project con el Team Explorer y como plantilla metodológica escogemos la plantilla recién subida. Todo parece ir bien hasta que...

Le hechamos una ojeada al log y vemos que el error está en la creación del portal de Sharepoint ya que no encuentra un template del site para el idioma español (3082):

Para solucionar esto nos vamos a la web de Microsoft a descargarnos el Language Pack para nuestra versión de Sharepoint, en nuestro caso la 3.0. Y la instalamos, claro. Al finalizar la instalación nos pedirá si queremos ejecutar el asistente para configuración de Productos y Tecnologías de SharePoint.

Le decimos que si y nos ejecutará el asistente, que prácticamente no requiere de nuestra intervención.

Y si todo ha ido bien:

Si nos vamos a la carpeta C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\1033\XML (inglés) veremos que tiene un fichero ( WEBTEMP.Microsoft.TeamFoundation.SharePoint.Dashboards) que en la carpeta C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\3082\XML (español) no está.

Tenemos que conseguir este archivo de alguna instalación del TFS en español y copiarlo aquí y volvemos a pasar el asistente para configuración de Productos y Tecnologías de SharePoint dejando las opciones marcadas por defecto. Una vez hecho esto ya podemos crear el nuevo proyecto con la plantilla metodológica en castellano.

Ahora solo nos faltará editar el portal de proyecto de SharePoint para que muestre los elementos en castellano en lugar de en inglés.

Espero que haya servido de ayuda.

Un saludo!

Codificación manual y enlace a datos de tests funcionales con CodedUI

2011-06-15T16:57:00.000+02:00

En el anterior artículo, veíamos como hacer un test funcional con CodedUI grabando nosotros los pasos del test. En el artículo de hoy veremos como codificar a mano estos pasos, ya que llega a ser más rápido y más flexible hacerlo así.

Empezaremos de la misma manera, creando un proyecto de test, añadiéndole un archivo de test con CodedUI y generando una nueva grabación. La diferencia es que ahora, en lugar de hacer clic sobre el botón de grabar y empezar a realizar los pasos, arrancaremos la aplicación y arrastraremos el botón con la cruceta de la barra del test builder sobre un control de la aplicación, en nuestro caso el textbox correspondiente a la operación.

Al hacer esto se nos abrirá la misma pantalla que se nos abrió al hacer la aserción en el anterior tutorial. Esta vez, haremox clic sobre las dos flechas hacia la izquierda que hay arriba a la izquierda y se nos abrirá un panel que contiene un árbol donde se muestran los diferentes controles que vamos seleccionando.

Seleccionaremos el control que acabamos de añadir y haremos clic sobre el botón de añadir el control al UI map. Haremos lo mismo con todos los controles, incluída la cruz de cerrar la aplicación, hasta que nos quede algo parecido a esto:

Ahora ya podemos hacer clic sobre el botón de generar el código de la grabación. El Visual Studio detectará que no hemos hecho ninguna grabación y nos preguntará si queremos que añada los controles seleccionados al UI map del test. Le diremos que si.

Si nos fiajmos en el test de donde hemos partido, veremos que no ha cambiado nada, ya que no se ha realizado ninguna grabación. Vamos ahora a hacer por código lo mismo que hacia Visual Studio automáticamente por nosotros antes. Para ello, no vamos a editar el archivo UIMap.Designer.cs, ya que este archivo es autogenerado y podriamos perder los cambios realizados allí. Para permitirnos añadir nosotros nuestros tests, Visual Studio nos proporciona una clase parcial vacia situada en el archivo UIMap.cs. Es aquí donde podemos hacer un método nuevo con las acciones que queremos que se realicen.

Empezaremos incluyendo la libreria de testing para los controles Wpf:

Lanzamos la aplicación a testear:

Definimos las variables para manejar los textbox de la calculadora, que en CodedUI son WpfEdit:

Ahora definimos las variables para manejar los botones:

Inicializamos los textboxes con los valores que queremos testear:

Y simulamos un clic sobre los botones del igual y de cerrar la aplicación:

Ahora simplemente tenemos que llamar a esta función desde nuestra clase de test, y veremos que si ejecutamos el test este hace todo lo que le hemos dicho y pasa correctamente.

Por ahora solo hemos comprobado que la aplicación no le pase nada raro, pero no hemos comprobado que el resultado sea el correcto. Para ello tenemos que simular nosotros lo que, cuando grababamos los tests, eran las aserciones.

Para ello vamos ha hacer algo parecido a lo que hace automáticamente Visual Studio. Nos vamos a crear una clase que contenga todos los parámetros que necesitamos ( los dos operandos, la operación y el resultado de la operación) y vamos a crearnos una instancia pública de la misma en la clase UIMap.cs:

Modificaremos la función que acabamos de realizar en el UIMap.cs para que utilice los valores de las propiedades de esta clase y para que, después de clicar sobre el botón de igual, recupere el valor que hay en el textbox del resultado:

Ahora sólo nos queda rellenar los valores de los operandos y la operación desde nuestro test, y hacer un assert del valor esperado con el valor del parametro Resultado:

Y ahora sólo nos queda alimentar este tests con datos provenientes de un XML. Primero de todo nos creamos el XML, que tendrá una aspecto como este:

Ahora le decimos al test que sus datos se alimentaran de este XML. Para hacerlo, seguiremos los mismos pasos que si quisieramos hacer lo mismo en un test unitario. Nos vamos a la ventana de test view, seleccionamos el test y en la ventana de propiedades, clicamos sobre el botón situado en el campo Data Connection String. Se nos abrirá una pantalla como esta:

Seleccionamos XML file y clicamos en siguiente.

Clicamos sobre siguiente:

Seleccionamos la tabla adecuada en el XML ( en nuestro caso sólo tenemos una ) y verificamos que los campos sean correctos. Clicamos en finalizar. Nos pedirá de copiar el archivo en el proyecto y de añadirlo a la lista de items a desplegar. Le decimos a todo que si.

Ahora ya estamos preparados para utilizar estos datos. Para hacerlo, nos ayudaremos de la propiedad DataRow del objeto testContextInstance, de la siguiente manera:

Y ya tenemos el CodedUI tests alimentado con datos de un XML!

Espero que el tutorial os haya gustado y no os haya aburrido en exceso.

Un saludo!

Tests funcionales con CodedUI

2011-06-08T21:44:00.000+02:00

Como ya muchos sabéis, CodedUI es la tecnología de Microsoft que nos permite realizar tests funcionales sobre nuestra aplicación, sea esta del tipo que sea. En el artículo de hoy veremos como crear un test funcional básico y añadirle una aserción. Empecemos!!

Lo primero es presentaros la aplicación que vamos a testear. Se trata, como no, de una pequeña calculadora realizada en WPF y compuesta de 4 textboxes y un botón. En los tres primeros textboxes introduciremos los operandos y la operación a realizar y, al apretar el botón, se nos mostrará el resultado en el último textbox.

Para realizar los tests vamos a crear un acceso directo a la aplicación en nuestro escritorio y vamos a añadir un nuevo proyecto de test a la solución. A continuación, añadiremos un nuevo item al proyecto de test de tipo CodeUITest. Automáticamente se nos mostrará un cuadro de diálogo que nos da a elegir entre generar un nuevo grabando acciones o utilizar uno existente. Escogeremos la primera opción.

Esto hace que nos aparezca la barra del CodedUI test builder, que es una pequeña barra que nos ayudará en nuestro cometido.

Como podéis ver, la barra sólo tiene cuatro botones;

Empezar o pausar la grabación.
Ver los pasos que llevamos guardados.
Seleccionar un control para hacer una aserción (luego lo vemos).
Generar el código de la grabación existente.

Para empezar le daremos al botón de grabar y empezaremos a realizar la prueba que queremos guardar. En este caso, será hacer doble clic en el acceso directo, introducir una operación del tipo 5 + 6, darle al botón y cerrar la aplicación. Esto en nuestra clase de test genera un código tal como este:

Ahora veremos un poco más el código interno, pero por ahora nos vamos a limitar a ejecutar el test. Esto hará magia en nuestro ordenador y se nos abrirá la aplicación, se tecleará lo mismo que hemos tecleado nosotros, se pulsará el botón, se mostrará el resultado y se cerrará la aplicación. Ni Tamariz lo haría mejor!

Si miramos un poco el código interno, veremos que es prácticamente auto-explicativo:

Vemos como abre la aplicación, inserta los textos correspondientes y hace clic en los botones. Destacar sobre todo las tres líneas donde rellenamos los textboxes, porque lo utilizaremos después para alimenar al test de datos.

Ahora vamos a hacer una aserción sobre el textbox del resultado. Lo que queremos es que el test compruebe que la operación es correcta, no sólo que no hay ningún problema para ejecutarlo. Así pues, vamos a hacer un nuevo test como si fuera un test unitario, es decir, haciendo un método público decorado con el atributo [TestMethod]. En el cuerpo del método, hacemos clic con el botón derecho del ratón y seleccionamos la acción "Generato code for CodedUI test -> User CodedUI Test Builder":

Volvemos a estar como antes, con la barra del CodedUI test builder. Realizaremos los mismos pasos pero, antes de cerrar la aplicación haremos clic sobre el botón de pausa y generaremos el códig de los pasos que llevamos hasta ahora. Ahora, haremos clic en el icono de la aserción y lo arrastraremos hasta el textbox del resultado. Esto hará que se nos habra la siguiente ventana:

Hacemos clic con el botón derecho en el campo text y seleccionamos la opción "Add asertion". Esto nos abre la siguiente pantalla, donde introducimos el valor que queremos asegurar que se muestre.

Generamos el código para la aserción, empezamos otra grabación para grabar el cierre de la aplicación y generamos el código para esta última acción. El código resultante tendria que ser algo parecido a esto:

Pasamos el test y vemos que se pone en verde. Si vamos a nuestra clase calculadora y cambiamos el comportamiento de la suma para que no devuelva la suma de los dos operandos, veremos que el test deja de pasar.

Bueno, pues por hoy ya es suficiente. Espero que os haya sido útil el tutorial. En la próxima entrega, veremos como alimentar este test de datos provenientes de un XML.

Mis tres días en la XP2011!

2011-05-16T20:48:00.018+02:00

La semana pasada tuvo lugar en Madrid la conferencia internacional XP2011 sobre metodologías ágiles en desarrollo de software y de sistemas de información, la más grande de Europa y la segunda en tamaño del mundo después de la Agile Conferenceque se celebra en Estado Unidos, y tuve la inmensa suerte de asistir durante 3 días (la conferencia duraba 4, pero el primero de ellos no pude estar). Estaba realmente emocionado con la oportunidad ya que se iban a dar cita algunos de los grandes referentes en el mundo del desarrollo ágil de los últimos años cómo Mary y Tom Poppendieck creadores del término "Lean Software Development", David Anderson creador de Kanban y muchos otros cómo J.B. Rainsberger, Jurgen Appelo, Michael Feathers...

Así que con las expectativas muy altas llegaba el Miércoles por la mañana con la Keynote de Esther Derby titulada "Still No Silver Bullets" ya empezada. Después de terminar esta y de saludar brevemente a algunos compañeros de diferentes grupos ágiles de España pasamos directamente a las sesiones. El formato de la conferencia durante los dos días intermedios (el primero y el último eran talleres y tutoriales) mezclaba sesiones de una hora entera con lightning talks de 20 o 30 minutos cada una, lo que tiene su lado positivo (dinamiza mucho la conferencia) pero también su lado negativo (muchas veces el tema se toca de manera demasiado superficial).

Aun así salí contento de unas cuantas sesiones sobretodo de las de Jurgen Appelo: "The Purpose of Leadership and Governance" y la de Angel Medinilla presentando "Scrumban" (divertido e ilustrador como la mayoría de las veces que le he visto).

El primer día lo acabamos con la creación de la agenda del Open Space que se iba a realizar al día siguiente y más tarde con una cena de gala cortesía de la organización en la casa de campo de Madrid, donde se repartieron los premios a los mejores papers de la conferencia y donde después de la cena unas cuantas personas de la comunidad demostraron que no se les queda pequeño el adjetivo "ágil", con bailes imposibles, saltos fuera de lo común y movimientos de cintura realmente espectaculares... :P

El segundo día siguió un guión parecido: Keynote de Brian Marick (que consiguió que todos los presentes en la sala se pusieran a bailar tango...) y más sesiones y lightning talks. Esta vez creo que acerté un poco más con las sesiones cortas donde hubo cosas realmente curiosas cómo por ejemplo charlas sobre Zombies y Scrum por Marc Löffler, sobre rehabilitación de adictos al Command and Control por Angel Medinilla , sobre cómo Scrum podría convertirse en un nuevo paradigma del socialismo por Rafael Viveros (pero socialismo del de verdad, no del que nos venden ciertos políticos del tres al cuarto...) o alguna sesión más convencional sobre cómo empezar a hacer TDD de manera práctica por Thomas Nielssen.

Después de una interesante cena y post-cena por Madrid en compañía de unos chicos Holandeses (de los que no me acuerdo del nombre) nos fuimos a dormir cansados pero con ganas de afrontar el último día de conferencia que a priori se presentaba muy bien ya que se trataba de 2 talleres y tutoriales de 4 horas de duración cada uno.

Con 10 minutos de retraso debidos a problemas logísticos entramos al taller sobre Refactoring de Michael Feather's, que supuso una pequeña decepción...ya que la sesión no era de Refactoring!! En disculpa del señor Feathers hay que decir que en la puerta de la sesión había una hoja donde se explicaba cómo iba a ser el taller, pero al llegar tarde no nos dimos cuenta pero... ¿porqué poner ese título? Aún así la sesión nos sirvió para aprender un poco de Ruby, ya que era el el lenguaje en el que se hacía el taller

Tras pelearnos con Ruby fuimos a comer, y después una larguísima sobremesa (para mi uno de los únicos fallos de la organización, que por otro lado estuvo genial y además eran gente muy maja y a la que felicito desde aquí) nos dirigimos al último taller. Para el fin de fiesta escogí el taller de Jurgen Appelo, basado en su curso sobre Agile Management y que a priori tenía muy buena pinta. Y la verdad es que no defraudó. Aunque muchos acusan a Appelo de ser un mero recopilador de ideas de otra gente, yo creo que está creando cosas y conceptos interesantes, o por lo menos les está dando una visión que me parece muy adecuada. Además el taller fué entretenido y mezcló la teoría con juegos cómo el Delegation Poker el Meddlers of Catán o uno sobre una matriz de métricas, todos ellos muy amenos y que además te hacen pensar.

Meddlers of Catán de Jurgen Appelo

Al acabar el taller sólo tuve tiempo de despedirme de la gente y salir corriendo para no perder el AVE de vuelta a Barcelona donde cansado (pero contento por todo lo aprendido, por la experiencia vivida y por poder debatir sobre metodologías ágiles con algunas de las personas más destacadas de este país y de todo el mundo) no tardé en quedarme dormido...

Waterfalacias: Mitos y creencias sobre Scrum

2011-05-04T20:43:00.014+02:00

En toda transición hacia Scrum o cualquier otra metodología ágil es común enfrentarse a un elevado porcentaje de rechazo entre la gente que es parte de ese cambio (de hecho cualquier cambio impuesto suele generar rechazo en primera instancia). Los motivos que esta gente tienen para no aceptar este cambio no pueden ser de lo mas variado: hay quien tiene miedo a perder poder, otros intuyen que va a tener que "trabajar más" e incluso hay gente que simplemente están contentos con la situación actual, pero curiosamente muchos de ellos suelen coincidir en su argumentario a la hora de explicar el porqué de sus objeciones.

Algunos de estos argumentos comunes los recoge Mike Cohn en su estupendo libro "Succeding With Agile", y ciertamente son argumentos que yo mismo me he encontrado o que he escuchado mas de una vez cuando intentas explicar o formar a alguien en metodologías ágiles, y que ya se han convertido en mitos o creencias "populares".

En este artículo voy a intentar desmitificar algunos de estos argumentos, explicando mi visión sobre cada uno de ellos y intentado aclarar el porqué son incorrectos o inexactos.

Empecemos:

En Scrum no se planifica, por lo tanto no somos capaces de dar estimaciones a nuestros clientes

Aunque parezca lo contrario en Scrum se planifica bastante más que en las metodologías tradicionales, lo que pasa que esta planificación se lleva a cabo de una manera mucho más "responsable". En lugar de hacer todo el esfuerzo de planificación al inicio, donde la incertidumbre es mayor y estamos sujetos a cualquier tipo de cambio o imprevistos, en Scrum se va planificando durante toda la vida del proyecto, y además a diferentes niveles:

- Planificación inicial: Donde se crea, prioriza y estima el product backlog inicial del proyecto (normalmente se realiza en una iteración 0 o fase de Inception y los requisitos son definidos a alto nivel)

-Planificación durante cada iteración: Donde se refina el product backlog (Product Backlog Grooming) y se decide que se va a llevar a cabo durante la siguiente iteración (Sprint Planning Meeting)

-Planificación diaria: Donde el equipo ajusta la operativa del día a día (Daily Meeting)

Así vemos que en Scrum se está planificando continuamente y que la diferencia principal con metodologías más clásicas es que la planificación inicial no es ningún dogma, sinó que a partir de lo que se va aprendiendo durante el proyecto esta se va ajustando para cumplir mejor las expectativas del cliente.

Scrum necesita que todo el mundo sepa hacer de todo

Otro de los principales mitos de Scrum es que todo el mundo tiene que saber hacer de todo, y esto hace que los especialistas dejen de tener sentido. Aunque bien es cierto que demasiada especialización de los miembros del equipo puede ir en contra de los intereses del proyecto, realmente lo deseable es que "El Equipo" sea multidisciplinar, es decir que entre todos los miembros del mismo reúnan los "skills" necesarios para llevar a cabo el proyecto evitando cosas como equipos de analistas, equipos de testing, etc... que favorecen los nichos de conocimiento y el "lavado de manos" dentro de un proyecto. Si a esto le sumas que las personas que forman estos equipos son capaces de, más allá de su especialidad, ayudar con otras tareas en momentos concretos de los proyectos tenemos equipos donde el conocimiento está muy compartido y donde es difícil ver bloqueos ante la falta de alguno de los miembros.

Tenemos equipos distribuidos y en Scrum es necesaria la comunicación cara a cara

Al igual que as anteriores ideas, esta proviene de gente que simplemente se ha quedado en la superficie de Scrum y no ha profundizado en la misma. Uno de los principales valores de las metodologías ágiles es la comunicación entre los miembros del equipo , entonces "¿que hacemos si nuestro equipo es distribuido?" La respuesta más fácil es "no podemos hacer Scrum", aunque realmente la respuesta correcta sería: "lo mismo que si el equipo está co-localizado", aunque eso si, con matices. Obviamente la comunicación cara a cara no se sustituye con nada, pero con la tecnología actual deberíamos ser capaces de llevar a cabo un proyecto de manera muy normalizada con nuestros compañeros que trabajan en remoto (videoconferencia, chats, etc...)

Los equipos Scrum no documentan y nuestros clientes nos exigen documentación

En este punto no voy a comentar demasiado. Simplemente señalar que en Scrum y en las metodologías ágiles en general los documentos son un medio, nunca un fin, y por lo tanto se intenta evitar toda aquella documentación que no sea útil para que el proyecto se lleve a cabo satisfactoriamente y quedarse con aquella que si es importante. Es decisión de cada equipo pensar que es y que no es útil para este fin y actuar en consecuencia. Pero... ¿de verdad todavía nos creemos que toda la documentación que nos exigen algunas metodologías tradicionales tiene sentido?

Scrum no tiene en cuenta la arquitectura y el diseño

Nada más lejos de la realidad. Simplemente que el hecho de definir esta arquitectura y este diseño se lleva a cabo de manera totalmente opuesta a cómo lo intentan hacer las metodologías tradicionales: En Scrum no hay un equipo de "arquitectos" que deciden al principio del proyecto sobre un Power Point cómo va a ser la arquitectura, sino que a partir de unas líneas generales iniciales a alto nivel la arquitectura va emergiendo iteración a iteración a medida que se va desarrollando el proyecto, y además durante todo este tiempo los "arquitectos" trabajan codo a codo con los desarrolladores adaptando la arquitectura a los nuevos requisitos. De hecho en las metodologías ágiles se considera que buena parte del diseño (si no todo) está en el propio código y en consecuencia se le da el estatus y la importancia que eso implica, poniendo mucho énfasis en prácticas de ingeniería que aseguren una alta calidad y mantenibilidad del código (TDD, BDD, Pair Programming, Code Reviews, Continuous Integration, S.O.L.I.D Principles...)

Nuestros proyectos son demasiado complejos para realizarlos con Scrum

Esta es una de las ideas que menos entiendo ya que en toda la literatura sobre Scrum que he leído nuna he visto nada que pueda dar a entender esto. Precisamente Scrum funciona especialmente bien en proyectos complejos, siendo flexible a posibles cambios durante todo el proyecto, gestionando los riesgos de manera implícita iteración a iteración y potenciando además la creatividad y la innovación de los miembros del equipo lo que garantiza un porcentaje de éxito mucho mayor en cualquier proyecto.

Cómo veis, todos estos argumentos son fácilmente rebatibles desde el raciocinio y el sentido común y no deberían ser un problema real en una implantación de metodologías ágiles. Sin embargo, como ya hemos dicho antes, estas argumentaciones suelen ocultar otro tipo de miedos, y estos son el verdadero desafío a la hora de hacer que la gente esté receptiva o no ante un cambio metodológico.

Un saludo!!

Primeros pasos con Moq ( parte II )

2011-03-12T19:34:00.001+01:00

Después de unas semanas liadas con el cambio de residencia y la incorporación a Plain Concepts volvemos a la carga con los artículos referentes a Moq ( aquí está el primero de la serie ).

Empecemos por el principio, es decir, por el constructor de nuestro mock. Al hacer el new tenemos dos opciones a la hora de indicar el comportamiento de nuestro objeto imitador:

MockBehaviour.Loose: el mock devolverá siempre valores por defecto si no está definido el Returns y si se llama a una función del mock que no tenga un Setup, no lanzará ninguna excepción
MockBehaviour.Strict: si se llama a una función del mock que no tenga un Setup, se lanzará una excepción y el test fallará.

Yo recomiendo utilizar la segunda opción ( MockBehaviour.Strict ) ya que seremos mucho más conscientes de lo que está haciendo el test.

En el anterior artículo vimos el uso de la función Verify. Esta función tiene 9 sobrecargas, en las que básicamente se pueden configurar dos cosas:

El string de error en caso de no cumplirse la condición.
El número de veces que queremos verificar que se ha hecho la llamada a la función.

Esta segunda opción se hace mediante la utilización de los métodos estáticos de la estructura Times. Ejemplos de utilización podrían ser:

Times.Never(): queremos verificar que la función nunca se llama.
Times.Once(): queremos verificar que la función sólo se llama una vez.
Times.Exactly(3): queremos verificar que la función se llama tres veces.
Times.Between(1, 5, Range.Inclusive): queremos verificar que la función se llama entre 1 y 5 veces, ambas incluidas.

En el anterior artículo también vimos como verificar que se había establecido el valor de una propiedad. Obviamente también podemos verificar que el valor de una propiedad se haya recuperado. Podemos verlo en el siguiente ejemplo:

[TestMethod]
public void Verify_Timeout_was_get()
{
    var mockDao = new Mock<IDAO>();
    AssetManager assetManager = new AssetManager(mockDao.Object);
    mockDao.VerifyGet(dao => dao.Timeout);
}

Siguiendo con las propiedades, también les podemos hacer un setup. La versión más sencilla es tratarlas como una función, de manera que podemos especificar el valor que queremos que devuelvan cuando se les hace un get. Para hacer esto, actuamos como si de una función se tratara:

mockDao.Setup(dao => dao.Timeout).Returns(1500);

La segunda versión es un poco más compleja, no en el código que tenemos que teclear ( muy sencillo ) sino en las funcionalidades que nos da. Si utilizamos el siguiente código:

mockDao.SetupProperty(dao => dao.Timeout);

estamos indicando a Moq que empiece a trackear la propiedad Timeout, con lo que el mock será consciente de cuando estemos intentando establecer un valor a Timeout y se guardará tal valor para futuros usos. Esto nos permitirá poder escribir un código tal como este:

[TestMethod]
public void Track_timeout_property()
{
    var mockDao = new Mock<IDAO>();
    mockDao.SetupProperty(dao => dao.Timeout);

    IDAO idao = mockDao.Object;
    idao.Timeout = 400;
    Assert.AreEqual(400, idao.Timeout);
}

Y esto es todo por por hoy. En futuros artículos veremos más características de este framework.

A testear!!

Un vistazo al ecosistema de Windows Phone 7

2011-02-21T11:28:00.000+01:00

El crecimiento que ha tenido el desarrollo para dispositivos móviles en los últimos años, propiciado por tecnologías como Cloud Computing, el auge de las redes sociales y también, por qué no decirlo, la facilidad de obtener beneficios que tienen los desarrolladores con las tiendas de aplicaciones (appstore, android market…) invita pensar que el desarrollo para dispositivos móviles (ya sean teléfonos, tablets o lo que venga después) va a ser uno de los mercados más importantes en los próximos años (si no lo es ya), y entrar en él va a ser prácticamente indispensable para todo desarrollador o compañía.

Pero entrar en el desarrollo de Smartphones se antoja complicado. La multitud de plataformas ya existentes, y las que están apareciendo, provoca una gran fragmentación en el ecosistema móvil, haciendo difícil la elección de por dónde empezar: ¿Apostamos seguro por los IPhone y IPad? ¿O mejor tirar por la opción “libre” que representa Android?¿Quizás sea mejor apuntar a un tipo de cliente más de negocio cómo el que representa Blackberry?¿Bada, WebOs…? También existe la opción multiplataforma, donde estándares cómo el promovido por WAC y la W3C prometen interoperabilidad total, pero por ahora no pasan de ser intentos más o menos acertados.

Uno de los últimos grandes actores en sumarse a este mercado ha sido Microsoft, con su SO Windows Phone 7, que viene a sustituir al ya caduco Windows Mobile. A priori se podría pensar que el salto llega un poco tarde, con Apple ya consagrada y Android creciendo cada vez más, pero el buen trabajo realizado con el SO, la gran comunidad de desarrolladores y su reciente alianza con Nokia (anunciada en el pasado Mobile World Congress de Barcelona) hacen que se les haya que tener en cuenta.

Interfície gráfica

La original y sencilla interfície de usuario hacen de WP7 un sistema fresco y muy atractivo visualmente. Centrándose en el contenido y la tipografía han conseguido desmarcarse de las características interfícies de usuario de sus competidores basadas en listas e iconos, añadiendo además conceptos interesantes cómo el sistema de vista panorámica.

Menú principal de un dispositivo con Windows Phone 7

Sistema de vista panorámica

Desarrollo

Siendo el número potencial de usuarios de nuestras aplicaciones mucho menor, por el momento, que el de las otras grandes compañías, ¿qué nos ofrece a los desarrolladores Microsoft para que nos decidamos por ellos?

Plataformas y Herramientas

Una de las grandes ventajas de Microsoft, es su set de plataformas y herramientas, ya que son las mismas que utilizan los desarrolladores de .Net para web o escritorio. Visual Studio cómo IDE (pudiendo desarrollar en C# o VB.Net), Blend Expression, y Silverlight o XNA Game Studio (para aquellos que quieran desarrollar videojuegos en WP7) permiten una curva de aprendizaje muy pequeña a todos aquellos acostumbrados a desarrollar con ellas, en comparación con el coste de aprender otros lenguajes y plataformas.

Además estas herramientas, así cómo el emulador de WP7, están disponibles de manera gratuita en AppHub, donde también podéis encontrar otros recursos en forma de foros, tutoriales, etc.

Servicios y funcionalidades

Las APIs de WP7 proporcionan acceso a funcionalidades del teléfono como la geo-localización, la pantalla multi-táctil, el acelerómetro o el micrófono, además de servicios como la reproducción multimedia o las notificaciones Push (que permiten actualizar los bloques de la pantalla principal).

Por contra, el sistema no soporta multitarea, dejando en manos de los desarrolladores la opción de implementar opciones de salvar y recuperar el estado (de hecho lo recomiendan cómo Best Practice) para dar la sensación de que la aplicación no deja de funcionar en ningún momento.

WP7 tampoco permite el acceso a la API nativa de Windows. Microsoft justifica esta decisión en base a asegurar la fiabilidad de las aplicaciones desarrolladas, pero esto penaliza en la extensibilidad y personalización de la plataforma.

SDK de WP7

La distribución de aplicaciones WP7 se realiza “únicamente” a través del Windows Marketplace. En este sentido la política de Microsoft es bastante cercana a la de Apple, no permitiendo instalar aplicaciones por otra vía que no sea la de su tienda (aunque es probable que haya gente que encuentre atajos :P). La cuota de acceso al Marketplace (para poder subir y vender aplicaciones) son de 99$ al año, y si no lo he entendido mal, el precio mínimo para una aplicación son 0,99$ (no se pueden subir aplicaciones gratuitas??)

Además, como anécdota, Microsoft no permite subir código libre al Market, lo que ha generado reacciones no muy positivas por parte de la comunidad Open-Source.

De nuevo Microsoft justifica estas medidas argumentando que así evitan que el Market se llene de aplicaciones absurdas que en muchos casos sólo sirven para perder el tiempo (por ejemplo,Android Market está lleno de ellas) y garantizan un alto nivel de calidad y una gran experiencia de usuario en todas sus aplicaciones.

Para abrir una cuenta en el MarketPlace se puede hacer también través del AppHub

Conclusiones

El nuevo SO de Microsoft puede llegar a ser un importante animador en el sector de los Smartphones.Aunque de momento esté lejos en cuanto a números de las grandes dominadoras (Apple, Android, RIM…), su nombre, su gran comunidad de desarrolladores y su alianza con un gigante cómo Nokia hace que no haya que perderlo de vista.

A su favor tiene, además de lo mencionado:

Un SO realmente atractivo visualmente y original que además, da la sensación, funciona con una gran fluidez.
Herramientas conocidas por todos los desarrolladores Microsoft, permitiendo una curva de aprendizaje muy pequeña

Y cómo posibles puntos en contra:

Un sistema de distribución bastante restrictivo (aunque a Apple, con un sistema similar no le ha ido nada mal)
Un SO aún un poco verde
El limitado número de aplicaciones y clientes en comparación a las otras grandes compañías.

Espero que este pequeño artículo os haya ayudado a tener una idea global sobre WP7 y todo lo que le rodea.

Un saludo!!

Estimando en Puntos de Historia

2011-02-01T22:44:00.001+01:00

Después de una interesante discusión producida ayer en twitter y en la lista de agile-spain sobre la estimación en puntos de historia, he estado dándole vueltas al tema y me da la sensación de que es algo que mucha gente cuando empieza con Scrum no tiene demasiado claro. Lo viví en primera persona cuando me tocó supervisar la implantación de Scrum en mi última empresa, llegando incluso a tener discusiones grandes sobre porqué debíamos estimar así y no cómo se había hecho “toda la vida”… Así que me he decidido a aportar mi granito de arena y tratar de explicar de manera sencilla en qué consiste esto de los puntos de historia y qué beneficios aporta.

Antes de empezar, simplemente explicar, para quien no lo sepa, que los puntos de historia es la medida de estimación utilizada cuando se trabaja con Historias de Usuario, una de las técnicas mas utilizadas al trabajar con la metodología Scrum.

Relatividad

En primer lugar los PH son relativos no absolutos. Es decir estimamos en función de la diferencia relativa entre una historia y otra. Si a una historia le damos 1PH, y a otra 3PH, esto únicamente indica que una es el triple que la otra. ¿Pero el triple de qué? Pues eso lo veremos después. Además, la relatividad se aplica entre diferentes equipos, es decir que 3PH para un equipo no tienen que significar lo mismo para otro equipo (aunque trabajen en el mismo proyecto, no importa!!)

De ahí viene el utilizar la famosa escala de 0, 1, 2, 3, 5, 8, 13, 40.., ya que lo que interesa no es el valor absoluto, únicamente el orden de magnitud, además de que nos ayuda a evitar la tentación de estimar hasta el más mínimo detalle: ¿Que importancia tiene estimar 40 o 42? Cuanto mas grande es la historia a estimar, menos certeza y precisión tenemos sobre la misma, con lo cual la escala nos ayuda a ser conscientes de esa imprecisión.

Tamaño

Cuando se estima en puntos de historia, lo que se intenta es dar un valor del TAMAÑO de la historia. ¿Y qué implica Tamaño? Pues yo entiendo que una combinación de:

Complejidad: No es lo mismo implementar una alta en un formulario que, por ejemplo, un algoritmo de inteligencia artificial para un juego
Esfuerzo: ¿Es una tarea que tengo que repetir en muchos sitios? ¿Me va a llevar mucho tiempo aunque sea una cosa fácil?
Riesgo: ¿Estamos trabajando con una tecnología desconocida? ¿Tiene la gente del equipo experiencia en el negocio?

Utilizando cómo métrica el tamaño, sacamos al tiempo de la ecuación, de manera que evitamos la tentación de buscar conflictos del tipo “esta historia debería estar hecha en 3 días, y tu llevas 4”, o cosas de este estilo que suelen aparecer cuando se utiliza la métrica del tiempo.

Entonces, alguien se preguntará, ¿cómo les decimos a nuestros clientes cuando tenemos listo el producto? Eso lo vamos a ver en el siguiente apartado.

Velocidad

La velocidad es el factor que nos sirve para ver cuanto trabajo somos capaces de entregar en cada sprint. Si nuestra velocidad son 15PH, estamos diciendo que entregamos 15PH de media en cada iteración. Con esto conseguimos ese factor de conversión de los puntos de historia a fechas, es la manera que tenemos de poder decirle a nuestro cliente cuando estimamos que nuestro producto estará listo (ojo, es una estimación, no hay que caer en el típico error de considerar que las estimaciones son contratos!!)

Hay que tener cuidado con esto, ya que se puede caer en la tentación de hacer cuentas y empezar a pensar en tiempo en lugar de estimaciones (1 tío 8 horas = 1PH). Esto aunque en media sea cierto no lo va a ser para todas las historias, e incluso es posible que haya historias de 1 punto, que por ejemplo se tarden mas en hacer que una de dos puntos. Por suerte, la velocidad actúa también cómo factor de corrección y a la larga, todas las historias que estén estimadas con los mismos PH van a caer mas o menos en la misma zona (la distribución aproximada debería tener forma de campana de Gauss)

Tareas

Conviene aclarar que lo que he dicho hasta ahora se refiere a la estimación de historias, no a la de las tareas en las que descomponemos dicha historia durante la planificación de Sprint. No es el objetivo de este post entrar en este tema, así que sólo diré que mi recomendación para la estimación de tareas es:

No estimarlas
O dividir la historia en tareas que ocupen aproximadamente un día

En Conclusión…

Los puntos de historia permiten abstraernos del tiempo a la hora de realizar estimaciones, de manera que podemos centrarnos en aspectos cómo la complejidad o el riesgo de la historia, y valorarla en función de eso.
Al indicar el tamaño relativo de una historia respecto a otra, es sencillo realizar estimaciones triangulando, con lo cual el proceso,con el tiempo, se vuelve muy eficiente.
Los PH evitan la especificación al detalle, poniendo de manifiesto el aumento de incertidumbre de una especificación a medida que esta aumenta.
La velocidad actúa cómo factor de corrección de las desviaciones en las estimaciones y nos permite realizar la conversión a fechas para poder dar plazos de entrega a nuestros clientes o superiores cuando sea necesario.

A partir de aquí lo que toca es experimentar y probar,e intentar encontrar la medida de estimación que mejor se adapte a nuestro equipo, aunque yo sin duda recomiendo encarecidamente probar con los PH!

Ya sabéis, cualquier comentario será bienvenido!!

Primeros pasos con Moq

2011-01-29T22:05:00.001+01:00

Aprovecho que en los últimos días los compañeros Luís Ruiz Pavón y Bruno Capuano han escrito sendos artículos sobre Moles ( aquí y aquí ) para hacer una pequeña introducción a otro framework de mocking llamado Moq.

Lo primero que tenemos que hacer es bajarnos la dll de su web . Una vez hecho esto ya podemos incluir la librería (Moq.dll ) en nuestro proyecto de test.

El código que vamos a testear se compone de una clase llamada AssetManager que tiene una dependencia a IDAO, una interfície para definir la manera en que se persistirán los objetos, ya sea en una base de datos, en un fichero o en memoria. Es esta interfície la que "mockearemos", evitando así tener que codificar una implementación para testear AssetManager.

Lo primero que vamos a hacer es crear un stub para la función SaveAsset de IDAO. Para tener clara la diferencia entre un Mock y un Stub, consulta este artículo de Martin Fowler.

Veamos el código para testear esta función:

[TestMethod]
public void SaveAsset_returns_true()
{
var mockDao = new Mock<IDAO>();
AssetManager assetManager = new AssetManager(mockDao.Object);

Asset asset = new Asset();
mockDao.Setup(dao => dao.SaveAsset(asset)).Returns(true);

Assert.AreEqual(true, assetManager.SaveAsset(asset));
}

Como podemos ver estamos creando un stub de nuestra interfície IDAO indicando que cuando se llame a la función SaveAsset nos devuelva el valor true. Así, al invocar al método SaveAsset de la clase AssetManager, que a su vez llama al método SaveAsset de la interfície IDAO, nos devolverá true y el test pasará. Para comprobar que esto es cierto, basta con cambiar el valor de retorno de la función de IDAO y veremos que el test no pasa.

En el ejemplo anterior, nada nos garantiza que realmente se haya llamado a la función de IDAO, ya que SaveAsset de AssetManager podria haber devuelto true directamente. Ahora vamos a ver como podemos "mockear" una función y verificar que realmente se llama:

[TestMethod]
public void GetAssetByName()
{
var mockDao = new Mock<IDAO>();
AssetManager assetManager = new AssetManager(mockDao.Object);

assetManager.GetAssetByName("MyFirstAsset");

mockDao.Verify(dao => dao.GetAssetByName("MyFirstAsset"));
}

Como podemos ver claramente en el código, con la función Verify verificamos que se haya llamado a la función GetAssetByName de la interficie IDAO con el parámetro MyFirstAsset. Podemos comprobar que esto es cierto modificando el string "MyFirstAsset" de una de las dos llamadas por otro string. El resultado será que el test no pasará. Este tipo de cosas puede hacer que nuestro test sea demasiado frágil y, por lo tanto, difícil de mantener. Moq nos ofrece la classe It para lidiar con este tipo de problemas. Podriamos substituir el string "MyFirstAsset" por sentencias del tipo:

It.IsAny<string>() -> pasa como parámetro cualquier string
It.Is<string>(s => s.StartsWith("My")) -> pasa como parámetro un string que empieza por "My"
It.IsRegex("\ba") -> pasa como parámetro un string que empieza por la letra a

Al igual que podemos comprobar que se ha llamado a una función, quizá también nos pueda interesar comprobar que se ha seteado una propiedad. Para hacerlo, nos apoyaremos en la función VerifySet del mock:

[TestMethod]
public void Verify_ConnectionString_was_set()
{
var mockDao = new Mock<IDAO>();

AssetManager assetManager = new AssetManager(mockDao.Object);

mockDao.VerifySet(x => x.ConnectionString = It.Is<string>(s => s.StartsWith("Non")));
}

Con este código comprobaremos que se ha seteado la propiedad ConnectionString con un valor que empieza por "Non".

Y por hoy ya tenemos suficiente. Hemos visto que es muy fácil utilizar Moq y hacer los primeros pasos con él. En posteriores tutoriales veremos más características de este framework.

Hasta la próxima!

La importancia de un buen Product Owner y un buen Product Backlog

2011-01-26T19:42:00.001+01:00

Muchas de las implantaciones de Scrum ( u otras metodologías ágiles ) que he conocido estos años son implantaciones que podríamos llamar bottom-up, es decir que parten del equipo de desarrollo. Estos se dan cuenta que no pueden continuar con la organización que llevan ahora y deciden tomar cartas en el asunto y empezar a hacerlo por ellos mismos. Es lo que se denomina comúnmente agilismo de guerrilla.

Aun siendo una muy buena opción para empezar ( yo empecé así ) a la larga se acaba quedando corta y es necesaria la implicación de la gerencia para llegar a algo más completo. Para mi los principales puntos débiles son:

Adolecen de un mentor experimentado: en la mayoría de los casos, el equipo se ha documentado sobre Scrum y empieza a probarlo.
Mala repartición de los roles: sobretodo si sólo está utilizando Scrum un equipo, hay gente que tiene dos roles: equipo y Scrum Master o equipo y Product Owner. La por situación es si hay alguien que tiene los tres roles, en lo que esto tiene muchos números de convertirse en un command and control encubierto.
Product Owner poco implicado: al ser un miembro del equipo le va a costar hacer de Product Owner. No va a tener relación directa con el cliente, no va a saber todo lo que se tiene que hacer a lo largo del tiempo o no le va a gustar definir bien las historias.

Veamos este punto con un poco más de detalle. Todas las cosas en contra que he comentado no tienen porqué pasar... pero tienen muchos números de que pasen. A los desarrolladores en general no nos gusta demasiado hacer especificaciones, definiciones de acabado y cosas por el estilo. Por lo menos a mi no me entusiasma ni a ninguno de mis compañeros. Esto desemboca en que nuestro Product Backlog no sea lo que tendría que ser.

Pero llega un día en que alguien con mucha más relación con el cliente y con visión del producto se instala en tu equipo. Y empieza a generar un Product Backlog con todas las historias que quiere que a corto/medio plazo se implementen, las prioriza, detalla más las más importantes, especifica las condiciones de aceptación de cada una de ellas. Este día será un día importante en tu historia dentro del proyecto. Los cambios más importante que se producirán en tu equipo para mi son:

Ánimo dentro del equipo: ver que la gerencia se preocupa por el proyecto y pone toda la carne en el asador para que tire adelante anima a la gente.
Mayor cuidado con la aplicación: todos somos profesionales y estamos comprometidos, pero no es lo mismo que cada quince días el equipo le haga a un Product Owner "externo" la demo del sprint que se la hagan entre ellos.
Mayor acierto con la implementación de las histórias: el equipo desarrollará lo que el Product Owner quiere, no lo que él cree que el Product Owner quiere.
Mayor visión del producto: el equipo sabe hacia donde tirará el proyecto y puede tomar decisiones en función de ello.

Por lo tanto, si tienes ya un buen Product Owner en tu equipo, cuídalo y no lo dejes marchar, y sinó búscate uno en quanto puedas!

Nota 1: este post está basado en hechos reales. Ningún Product Owner, Scrum Master o miembro del equipo ha sido maltratado en la realización del mismo.

Nota 2: este post está basado en mi experiencia. Si la tuya es diferente, no dejes de contarla en los comentarios!

He leído: Clean Code

2011-01-25T11:44:00.001+01:00

Empiezo nuestra aventura en geeks con la review de un libro que tengo pendiente desde hace algún tiempo, y que no es otro que Clean Code, de Robert.C. Martin.

Lo primero que tengo que decir de Clean Code, es que es un “Must Have” de cualquier desarrollador que se precie de serlo! Es un de esos libros que debería ser obligatorio que te hagan leer en la facultad, y no sólo leer, sino casi recitar de memoria!

¿Y porqué hago tales afirmaciones? Pues porque Clean Code es un libro genial, bien explicado, con ejemplos claros y concisos, va al grano, y además, es entretenido de leer (bueno, algunos capítulos son un poco pesados, pero en general es bastante ameno)

Si, si,¿pero de que va el libro? os estaréis preguntando muchos... Pues el libro trata simplemente de cómo escribir código limpio (el propio título lo indica). Algo que parece una chorrada pero que es sumamente difícil. En el libro, Robert no das las claves para ser capaces de escribir código lo más legible posible, algo que además de facilitar la lectura (según él. el 90% del tiempo que pasamos programando, estamos leyendo código nuestro o de otras personas) va a afectar de manera directamente proporcional al diseño, la reutilización o la escalabilidad de nuestro código.

Cómo ya he comentado antes, el libro es muy conciso, presentando en cada capítulo soluciones a diferentes errores comunes que la mayoría de gente comete o ha cometido en diferentes ámbitos del código: Comentarios, Clases, Funciones, Tratamiento de errores, tests unitarios… todo ello aderezado con múltiple ejemplos sacados de proyectos reales. Esta estructura de los capítulos permite tanto una lectura secuencial cómo a modo de libro de consulta. Y además, y vuelvo a repetirme, el libro es muy ameno.

En definitiva, un gran libro que recomiendo a todos los desarrolladores (presentes, pasados y futuros) ya que puede ser una muy buena guía para intentar mejorar en nuestro trabajo.

Un saludo!!

Ahora también en geeks!

2011-01-24T22:17:00.001+01:00

Pues si, la popular comunidad de blogs sobre desarrollo y tecnologías Micrsosoft, geeks.ms nos ha abierto las puertas para que participemos en ella desde nuestro blog. Así que a partir de ahora podréis encontrar nuestros posts tanto aquí cómo en http://geeks.ms/blogs/devnettips/. Desde aquí queremos dar las gracias a Rodrigo Corral por permitirnos participar en la comunidad, a la cual intentaremos aportar material interesante y de calidad!

Un saludo desde devnettips!

CodeRetreat de Zaragoza... allí estuvimos!

2010-12-17T14:30:00.001+01:00

Después de un más que interesante Coding Dojo en Barcelona el pasado viernes, unos cuantos valientes con ganas de más nos íbamos al día siguiente al CodeRetreat de Zaragoza! Para el que no lo sepa, un CodeRetreat consiste, simplificando mucho, en juntarse un grupo de desarrolladores un día entero para programar (da igual el lenguaje, la experiencia... sólo importan las ganas) , en una serie de iteraciones de 45 minutos, una y otra vez el mismo ejercicio (normalmente el Juego de la Vida de Conway), por parejas, usando TDD e introduciendo una nueva restricción en cada una de las iteraciones. Además, por si no fuera suficiente, cada iteración se realiza con una pareja diferente! Viva la promiscuidad!! La verdad es que suena muy freak, y efectivamente lo es, sobretodo si se realiza a 300km de tu ciudad y tienes que levantarte a las 5:30 de un sábado para asistir! pero aparte de eso, es una manera excelente de aprender y mejorar, de conocer gente, de hacer networking y también de divertirse por supuesto!

Así que con muchas ganas y mucho sueño yo y Vicenç cogíamos al AVE las 7 de la mañana dirección Zaragoza. El resto de gente de Barcelona , Javier Gómez y su mujer (ingeniera informática que hace 4 años que no programa, y a la que según Javier había que devolver la sonrisa) iban en el siguiente tren!

Con el tiempo justo y gracias a que nos encontramos a Amalia (con quien habíamos colaborado en la organización delAOS 2010) y a Jorge(alias Semurat) conseguimos llegar al peculiar "Water Pavillion", el lugar donde se iba a celebrar el evento.

Digital Water Pavillion

Más de 20 personas estábamos inscritas, y ya mayoría de gente ya había llegado y tenía los portátiles preparados cuanto entramos nosotros! Aparte de mucha gente de Zaragoza y los que íbamos de Barcelona había gente de diferentes lugares de la geografía Española, cómo Madrid, Valladolid, Valencia.. Únicamente tuve tiempo para saludar brevemente a Xavi Gost, que iba a ser el facilitador del evento, a Teresa Oliver (a quién también conocía de la organización del AOS2010 y una de las culpables de la realización del CodeRetreat) y a alguna persona más que conocía de haber asistido al mismo evento justo antes de que llegara los dos catalanes que faltaban y nos pusiéramos manos a la obra.

Después de una breve ronda de presentaciones, donde de se vio que había dos grandes grupos en lo que a lenguajes de programación se refiere (Java y .Net) Xavi nos explicó la dinámica del evento, básicamente la que he explicado arriba, nos explico las 4 reglas del juego de conway que había que implementar y nos dijo que empezáramos!

Antes de empezar

La primera iteración la hice con Vicenç, y después de los primeros 45 minutos, nos pensábamos que teníamos un código bastante bueno y bonito, ingenuos... Al acabar Xavi nos reunió y fue preguntó¡ando a la gente por sus impresiones, por cómo habían enfocado el problema, etc... Hubo un poco de todo,desde gente que había empezado a desarrollar en universo entero donde situar a las células del juego hasta gente que prácticamente no había hecho una sola línea de código. Hay que tener cuenta que mucha gente no había programado con TDD en su vida. A partir de ese momento y durante las siguientes iteraciones, Xavi nos iba poniendo nuevas restricciones a la hora de implementar los tests, por ejemplo:

No instanciar nada más allá de lo estrictamente necesario
Desarrollar el test dentro del propio test
Darle semántica al código (cómo ejemplo, la mayoría de le gente utilizaba una variable boleana para indicar si una célula estaba viva o no, y Xavi nos dijo que una persona cuando muere no está a "False"...)
...

Al final hicimos unas 5 iteraciones, en las que tuve la oportunidad de tocar 3 lenguajes de programación (C#, Java e incluso Python!!) y de desarrollar con personas diferentes que tienen diferentes puntos de vista y diferentes maneras de buscar la solución, lo cual creo que es muy enriquecedor e interesante.

Después de la 5ª iteración y de una breve videoconferencia con Enrique Comba desde Londres (Enrique es uno de los firmantes originales del manifiesto por la artesanía del software, además de ser un asiduo facilitador de CodeRetreats) la gente estaba bastante cansada, y se decidió acabar con un pequeño reto a Xavi Gost: Seleccionamos una Kata que él no conocía y tenía que implementar la solución utilizando TDD, sin leerle el enunciado, únicamente a base de tests que Amalia le iba escribiendo! La kata elegida fue la de La Multiplicación a la Rusa, muy muy complicada para realizar con TDD puro y duro, así que hubo que darle alguna pista adicional a Xavi para que pudiera deducir la implementación!

Xavi Gost enfrentándose a "La multiplicación a la Rusa"

Con esto, y unas cervezas cortesía de los chicos de M asterbranch finalizaba "oficialmente" el CodeRetreat!! Y digo "oficialmente" porque el evento se alargaba para que los querían (o podían) con unas cervezas, cena y lo que surgiera! Lástima que nosotros nos tuvimos que volver esa misma noche!!

Cómo conclusión, aparte de las ganas y la motivación de la gente, el buen ambiente y el poder conocer a personas muy interesante (y volver a ver a las que ya conocía) , me quedo con la idea de que es necesario buscar la excelencia en nuestra profesión (cómo en toda profesión de hecho) y que esa búsqueda debe empezar por elevar el grado de auto-exigencia a nosotros mismos, y buscar siempre y de manera continua el ir mejorando poco a poco en todo aquello que hagamos (ya sea código o cualquier otra actividad).

Por suerte parece que empieza a haber cada vez más gente que comparte esa misma idea cómo se puede ver con los diferentes eventos que están surgiendo últimamente en diferentes lugares y de las diferentes comunidades (muchas de ellas ágiles) repartidas por el estado.

Para finalizar: muchas gracias a los organizadores, que hicieron posible este evento, a Xavi Gost por su facilitación y a todos los que asistieron por darme la posibilidad de poder aprender de ellos (especialmente a la gente con la que pude sentarme a desarrollar) y de conocerlos!!

Un saludo!!

PD: Dani Latorre ha recopilado una lista con muchas de las cuentas de twitter de los asistentes! Por si os falta alguna!!

Primer Coding Dojo en Barcelona

2010-12-14T21:03:00.001+01:00

Después del fantástico AOS 2010 celebrado en Barcelona había una idea flotando en el ambiente: hay que montar más cosas!! Así que, ni cortos ni perezosos, el grupo local de Barcelona organizamos nuestro primer Coding Dojo. El evento lo realizamos en las fantásticas oficinas de Runroom con Carlos como anfitrión.

La convocatoria fue un éxito y enseguida se apuntó mucha de gente, aunque el echo diferencial fue la promesa de Gin Tonics subvencionados por Úbeda Gin & Tapas. Todo un detallazo!

La kata que seleccionamos para hacer el Coding Dojo fue la de Cesar juega a la loteria. Es una kata interesante que se puede resolver de varias maneras y que da bastante juego. Entre los 18 participantes se realizó la kata en .Net, en Java y en JavaScript. Eso si, todos con TDD.

No se exactamente por qué, pero me parece que en Barcelona hay más programador en .Net y, en cambio, en otras comunidades hay más programador en Groovy, Rails y compañía. Por lo menos en las comunidades ágiles. Curioso.

Hicimos dos iteraciones de 40 minutos. Después de la primera iteración tocaba cambio de pareja, pero quizá por ser la primera la gente no se animó y todos continuamos con nuestra primera pareja, y con nuestro segundo Gin Tonic, claro :D.

Al final de ambas iteraciones, hicimos un poco de retrospectiva de la kata. Cada uno comentó como se había encontrado haciendo TDD, como había encarado la kata, etc.Surgieron opiniones para todos los gustos: gente que no se acababa de encontrar cómoda con TDD ( para muchos era su primer vez ), gente que se encontraba muy cómoda y la kata le iba saliendo muy bien, gente que estaba refactorizando tranquilamente por el echo de tener tests por debajo, etc.

Y para acabar vimos todos el vídeo del "The downfall of Agile Hitler" para echarnos unas risas antes de continuar con las cervezas ágiles mientras cuatro afortunados nos preparábamos para ir a la mañana siguiente al coderetreat de Zaragoza. Pero eso ya es otro post...

Diseño Ágil

2010-11-23T09:26:00.001+01:00

El presente post está basado en las conclusiones e ideas que surgieron en la sesión del mismo nombre (Diseño Ágil) en el reciente Agile Open Spain 2010 de Barcelona. La sesión, egoístamente propuesta por mi (:P), tenía cómo objetivo el determinar aquellas técnicas o maneras de diseño que mejor pueden funcionar en equipos que trabajan de manera ágil, ya sea con Scrum o con cualquier otra metodología, aunque al final el tema se desvió un poco y se acabó hablando de algunas otras cosas, aunque todas ellas muy interesantes!

Se empezó hablando de la necesidad de eliminar los grandes diseños y arquitecturas iniciales para poder tener una mejor respuesta ante cambios en los requisitos o las necesidades del cliente, y para evitar el sobrediseño, algo que suele suceder muy a menudo. En su lugar se apuesta mas por un micro diseño o arquitectura inicial a alto nivel que permita a las personas que van a trabajar en el proyecto hacerse una idea general del mismo: los diferentes subsistemas que intervienen, como se relacionan entre ellos, etc. pero sin entrar en demasiados detalles. Este micro-diseño se realizaría en el Sprint 0, antes de empezar con el desarrollo de las diferentes funcionalidades del sistema.

A partir de aquí se empezaron a enumerar las diferentes técnicas que utiliza la gente desde el punto de vista del desarrollo para garantizar un buen diseño, por ejemplo:

Diseño emergente con TDD y/o BDD
Tests unitarios para garantizar que no se rompe código anterior
Utilizar principios S.O.L.I.D y desarrollar utilizando interfaces (lo que a su vez facilita el testing)
Refactorizar, refactorizar, refactorizar!!
Patrones de diseño

La conversación, fue derivando entonces hacia la documentación, posicionándose la mayoría de la gente en que la mejor documentación es el propio código (o incluso los tests unitarios), y que documentar exhaustivamente los diseños puede tener un coste elevado, aunque también se aceptó que en ocasiones puede ser interesante que algunos diseños se documenten (por ejemplo con UML) de manera que todo el mundo pueda acceder a ellos, eso si, siempre y cuando esta documentación sea consistente con el código y no esté desincronizada. Una manera de conseguir esto, era tener una tarea en cada Product BackIog Item (o historia de usuario) del Backlog dedicada a ello.

El siguiente foco importante de discusión y comentarios, fue el decidir el momento adecuado de realizar el diseño y análisis técnico de cada historia de usuario. El consenso fue que el diseño de cada historia se debía realizar durante el proceso de estimación y división en tareas de esa historia, en la reunión de planificación de Sprint, momento en el cual el Product Owner está disponible para explicar la historia y aclarar cualquier posible duda que pueda surgir.

Se habló también de como integrar a los desarrolladores juniors o la gente nueva en el proceso de diseño, de manera que sus diseños no afecten o comprometan la calidad del trabajo de todo el equipo. Casi todo el mundo nombró Pair-Programming como la solución a este posible problema, y alguien habló que en su empresa utilizaban un sistema de mentoring, en el cual un desarrollador senior se "hacía cargo" de un junior, de manera que le supervisaba el trabajo, desarrollaban juntos, etc. durante un tiempo y éste último no empezaba a trabajar para un cliente hasta que llevaba un tiempo y ya sabía cómo debía de programar (tanto a nivel de calidad cómo de estilo, estándares, etc)

Hacía el final se empezó a hablar de que hacer con los requisitos no funcionales: seguridad, rendimiento, etc. Aquí hubo un poco más de discordia, ya que había gente que abogaba por intentar optimizar desde el principio y otras personas que preferían desarrollar sin tener muy en cuenta estos parámetros y después optimizar en función de las necesidades del cliente. Aunque casi todo el mundo opinaba que ahora la tendencia es desarrollar pensando mas en la mantenibilidad y en la escalabilidad que no en la optimización del detalle.

Cómo último punto, se trataron las revisiones de código., que todo el mundo consideró cómo necesarias. Enumero algunos de los métodos expuestos (además de Pair-Programming cómo revisión continua):

En una empresa utilizan una herramienta online (un plugin de JIRA creo) donde se registran posibles mejoras en un código que hace un "moderador". Posteriormente el moderador y la persona que ha realizado el código lo miran juntos y se buscan posibles soluciones y mejoras.
En otros lugares realizan sesiones de revisión, donde se junta todo el equipo y se realiza la revisión de un código.
En otra empresa de manera periódica hacen una reducción de código de cada proyecto, de manera que se intenta una especie de gran refactorización con todas las modificaciones hechas desde la última vez.

Seguro que salieron muchas mas ideas interesantes que me olvido o que no apunté en su momento, pero fue una sesión muy fructífera y muy entretenida debido al alto nivel de los asistentes y alto porcentaje de gente que participó con opiniones y ideas en la charla!

Espero que alguna de estas técnicas puedan servir de ayuda a equipos que estén intentado trabajar con metodologías ágiles, y si alguien tiene alguna idea o sugerencia sobre el tema, adelante!! Explicadnos cómo realizáis diseño vuestros diseños ágiles!!

Un saludo!!

ScrumMaster: ¿Parte o no del equipo?

2010-11-16T23:07:00.001+01:00

Me ha parecido, en el último Agile Open de Barcelona escuchar en varias ocasiones frases similares a esta. En algunas sesiones, en los pasillos e incluso en alguna de las cenas he oído comentarios y opiniones dándole vueltas a esa idea. De entrada,creo que sería interesante re-formular la cuestión, ya que creo que lo que se intenta debatir no es si el ScrumMaster debe estar o no en el equipo (por supuesto!!) sino si además de sus funciones cómo ScrumMaster, debe también tener otras funciones dentro del equipo (desarrollo, testing, usabilidad...). La pregunta que yo lanzo es ¿ScrumMaster full-time o part-time?

Antes de dar mi opinión, veamos lo que dice el propio Jeff Sutherland sobre el rol en cuestión:

"The ScrumMaster helps the product group learn and apply Scrum to achieve business value. The ScrumMaster does whatever is in their power to help the team be successful. The ScrumMaster is not the manager of the team or a project manager; instead, the ScrumMaster serves the team, protects them from outside interference, and educates and guides the Product Owner and the team in the skillful use of Scrum. The ScrumMaster makes sure everyone on the team (including the Product Owner, and those in management) understands and follows the practices of Scrum, and they help lead the organization through the often difficult change required to achieve success with agile development. Since Scrum makes visible many impediments and threats to the team’s and Product Owner’s effectiveness, it is important to have an engaged ScrumMaster working energetically to help resolve those issues, or the team or Product Owner will find it difficult to succeed. Scrum teams should have a dedicated full-time ScrumMaster, although a smaller team might have a team member play this role (carrying a lighter load of regular work when they do so). Great ScrumMasters can come from any background or discipline: Engineering, Design, Testing, Product Management, Project Management, or Quality Management."

Leyendo el párrafo anterior, la respuesta a la pregunta sería: Depende!! Si puedes permitírtelo, ten un ScrumMaster full-time, sino puedes porque tú equipo o organización es demasiado pequeño, usa a un miembro del equipo a modo part-time (aunque eso sí, aligerando su carga de trabajo en otras responsabilidades). Ahora bien, ¿porqué sería interesante tener un ScrumMaster full-time?

La responsabilidad del ScrumMaster es, entre otras cosas, encargarse del proceso (sí, ya se lo que pone en el Manifiesto Ágil, pero no se me ocurre otra manera de expresarlo!!) El equipo debe "hacer" algo (un producto, un proyecto...) utilizando eso proceso y el ScrumMaster debe encargarse de observar cómo lo hacen, ver como el equipo avanza, e intentar ayudarles a mejorar. Sería algo así cómo si el equipo fuera dando pequeños saltos hacia un punto mientras el ScrumMaster observa cada uno de esos saltos e intenta que el equipo aprenda a saltar mejor cada vez. Pero para que esta observación sea efectiva, es necesaria cierta neutralidad.Se debe poder mirar el proceso con un poco de perspectiva para poder obtener información objetiva sobre el mismo. Si el ScrumMaster es parte del equipo, puede perder la perspectiva, su visión puede quedar sesgada ya que su foco se está centrando también en producir (multitasking?) y la mejora continua necesaria en todo equipo Scrum es probable que sea menor.

Esto seria lo ideal, pero, cómo hemos leído en la definición de Jeff Sutherland, es posible que en equipos o organizaciones demasiado pequeñas un ScrumMaster no tenga suficiente volumen de trabajo para ejercer ese trabajo full-time. Además, muchas organizaciones dedicadas al desarrollo de software seguramente no estén aún preparadas para tener a una persona "que no produce" (nótese la ironía) a tiempo completo.

¿Entonces que hacemos? Scrum es una metodología de inspección y adaptación. Empecemos con lo que tenemos, y mantengamos la visión ideal del ScrumMaster full-time en el horizonte y, aunque es posible que nunca se llegue a completar, intentemos trabajar en esa dirección. ¿Cómo? Que varios equipos compartan SM, haciendo que el ScrumMaster sea una persona de otro equipo... o con otras opciones mucho mas creativas que las que se me ocurren ahora mismo a mi.

Como nota final, apuntar que aún más importante que decidir si el ScrumMaster es full-time o no, es escoger al candidato correcto. ¿Y quien es el candidato correcto? Pues sencillamente aquel que tiene los skills necesarios! Os remito a un interesante artículo de Xavier Albaladejo sobre el tema: "El buen gestor de un equipo ágil".

¿Que opináis? ¿Debería ser el ScrumMaster un rol full-time?¿O mejor un miembro del equipo?¿Puede llegar a trabajar sin ScrumMaster un equipo?

Espero vuestras opiniones! Un saludo!

Se acabó el AOS 2010!

2010-11-14T22:00:00.001+01:00

Ha finalizado el Agile Open Spain 2010. Ha sido mi primera asistencia a un evento en formato Open Space y las sensaciones han sido inmejorables. Mas allá de la calidad de las sesiones a las que he asistido (que difícil ha sido elegir entre las numerosas propuestas de los asistentes), con lo que me quedo es con las ganas y la energía que que han mostrado todos los asistentes que han hecho el esfuerzo de acercarse a Barcelona desde diferentes lugares de España, Europa e incluso algunos del otro lado del charco, para compartir con todos sus opiniones y experiencias en esto que llamamos Agilismo. A lo largo de los casi dos días del evento, he tenido el placer de escuchar, charlar y discutir ideas y opiniones con mucha gente, algunas con verdaderos expertos en metodologías ágiles y otras con gente que se acercaban por primera vez a ellas, pero todas han sido igual de enriquecedoras.

Sesiones técnicas, sesiones sobre gestión de proyectos (o Project Support cómo prefiere llamarlo Alan Cyment...) e incluso sesiones que podríamos considerar algo así cómo teórico-filosóficas... :P de todas ellas me llevo cosas para reflexionar e intentar mejorar tanto a nivel profesional cómo personal. Más adelante intentaré concretar alguna de estas ideas en siguientes posts.

Espero que este evento sea un punto y seguido que ayude a la comunidad Agil Española a seguir creciendo y consolidándose, utilizando para ello, quizás, algunos de las propuestas surgidas en la Retrospectiva del evento (facilitada de manera magistral por Ariel Ber a quién desde aquí doy las gracias por su colaboración y ayuda durante todo el evento), cómo por ejemplo la realización de eventos Open Spaces a escala local, la realización de eventos temáticos o sobretodo la propuesta estrella de la noche: fomentar el agilismo entre las mujeres!!

Cómo punto final, dar las gracias a todos los que han hecho posible este evento: los patrocinadores del evento (en especial al patrocinador oro Plain Concepts), a la gente de la organización, a la asociación agile-spain y sobre todo, y aquí me repito, a la gente que ha hecho el esfuerzo de acercarse al evento, ya que sin la gente no hubiera sido posible realizarlo!

Os dejo una foto de la configuración de la agenda, totalmente autoogenerada entre todos los que asistimos al evento!

Un saludo, y espero volver a coincidir con muchos de los que habéis estado en el AOS (no pongo nombres porque seguro que me dejo a gente) y sobretodo espero ver a mucha gente nueva en próximos eventos. Para empezar en el xp2011 en Madrid!!

VAN sobre integración contínua

2010-11-01T13:28:00.000+01:00

Muy buenas a todos,

el pasado viernes tube el placer de participar en la VAN sobre integración contínua que organizó Altnet hispano. La VAN estubo muy interesante, tanto por la explicación general como por las demostraciones de las diferentes herramientas que se hicieron.

Aquí os dejo el video de la VAN.

Unable to display content. Adobe Flash is required.

Entrenando tu código

2010-10-27T22:41:00.000+02:00

Kata (型 o 形) es un término Japonés utilizado, normalmente en el ámbito de la artes marciales, para describir una serie de ejercicios o movimientos preestablecidos que pueden practicarse sin rival y sirven al practicante como entrenamiento para aumentar sus capacidades. Es, de la misma manera que en otras disciplinas como la música, a través de la repetición continua y rigurosa de estos ejercicios la única manera en la que el estudiante puede llegar a dominar la técnica en su máximo nivel, además de llegar a comprender el espíritu del arte marcial en cuestión.

De la misma manera que los practicantes de artes marciales, los desarrolladores también tenemos formas de entrenar nuestras capacidades, y una de las mejores son las Katas de Código. Estas consisten en el planteamiento de diferentes problemas que tenemos que intentar resolver de la mejor manera posible. Cómo en las artes marciales, la práctica y la repetición de este tipo de ejercicios nos permiten mantener nuestras capacidades al máximo nivel. Hay que tener en cuenta que lo mas importante no es la resolución del problema, si no el proceso que lleva a la resolución del mismo.

Gracias a este tipo de ejercicios se persigue obtener una excelente base técnica, que nos permita enfrentarnos a problemas en proyectos reales con una alta garantía de éxito y centrándonos mayoritariamente en el dominio del problema y no en los aspectos técnicos del mismo.

Las katas de código pueden ser de diferentes tipos y naturaleza (algoritmos, matemáticas, modelado, centradas en tecnologías, de refactorización...) y de diferentes niveles de dificultad.

Algunos sitios web donde se pueden encontrar Katas son:

http://codingkata.org/

http://codekata.pragprog.com/

http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue

Ya podéis empezar a entrenar vuestro código!!

Un saludo!!

Reestimando historias

2010-09-26T10:40:00.008+02:00

Suele pasar en ocasiones que finalizar alguna historia de usuario nos lleva mucho mas tiempo del que a priori podíamos esperar. Esta situación suele llevar a la pregunta de si se debe reestimar o no la estimación hecha para esa historia de usuario. En este post vamos a tratar de explicar en qué situaciones se debe reestimar y en cuales no, basándonos en lo explicado por Mike Cohn en su libro Agile Estimating And Planning

Para ello vamos a ayudarnos de un ejemplo. Imaginemos que tenemos las siguientes historias de usuario en el backlog:

ID	*Historia*	*Estimación*
1	Historia A	3
2	Historia B	5
3	Historia C	3
4	Historia D	3
5	Historia E	3
6	Historia F	5

Supongamos que que las historias A, B y C tienen todas que ver en en cuanto a tamaño y complejidad ya que lidian con el mismo tipo de tecnología (por ejemplo una integración con un sistema externo mediante servicios web). Revisando las historias el equipo decide incluir en cada sprint las siguientes historias:

*Sprint 1*
Historia A	3
Historia B	5
Historia F	5
*Sprint 2*
Historia C	3
Historia D	3
Historia E	3

Al finalizar el primer sprint únicamente se ha completado la historia A y la F, es decir un total de 8 PH. El equipo sabe que la historia A es el doble de compleja que lo que habían estimado, así que tienen que decidir que hacer con las estimaciones de la propia historia y de las historias similares (B y C)

1. No reestimar

Si deciden no reestimar ninguna de las 3 historias, para el siguiente sprint deberían, en principio seguir con las historias B y C, que son un total de 8ph. Debería ser suficiente ya que en el último sprint es exactamente la cantidad de puntos conseguidos, pero el equipo sabe que las historias B y C pueden llegar a ser el doble de complejas que lo inicialmente estimado, así que aunque el total de ph sea 8, el equipo no conseguirá terminarlas en un sprint.

Velocidad estimada: 8PH

*Sprint 1*
*Historia A*	3
*Historia F*	5
*Sprint 2*
Historia B	5
Historia C	3
*Sprint 3*
Historia D	3
Historia E	3

Probablemente no se llegue a finalizar el Sprint 2, debido a que las historias B y C pueden ser el doble de grandes.

2. Reestimar únicamente la historia finalizada

Si se decide reestimar la historia finalizada, con por ejemplo el doble de puntos (6 en lugar de 3), el total de puntos del sprint queda en 11 ph. Esto seria suficiente para terminar en el sprint 2 las historias B, C y D. Sin embargo sabemos que las historias B y C pueden llegar a ser aproximadamente el doble de grandes de lo estimado inicialmente, con lo cual es muy probable que el equipo no pueda finalizar los 11ph de historia estimados para el siguiente sprint.

Velocidad estimada: 11PH

*Sprint 1*
Historia A	6
Historia F	5
*Sprint 2*
Historia B	5
Historia C	3
Historia D	3
*Sprint 3*
Historia E	3

Probablemente no se llegue a finalizar todo el sprint 2, debido a que las historias 2 y 3 pueden ser el doble de grandes

3. Reestimar las historias relacionadas entre si.

Si la reestimación se hace para las 3 historias relacionadas (la finalizada A, la B y la C), se consigue aumentar la velocidad del equipo hasta 11ph, pero ademas aumenta el tamaño del trabajo pendiente. En el siguiente sprint el equipo estaría preparado para abordar las historia B, que ahora vale 10ph, la C y la D en el tercer sprint (6ph + 3ph) y la E en el cuarto sprint.

Velocidad estimada: 11PH

*Sprint 1*
Historia A	3
Historia F	5
*Sprint 2*
Historia B	10
*Sprint 3*
Historia C	6
Historia D	3
*Sprint 4*
Historia E	5

La reestimación de todas las historias relacionadas nos permite obtener la planificación más exacta, aún a costa de ver cómo esta sobrepasa la inicialmente prevista. No reestimar o reestimar únicamente las historias finalizadas para obtener una mayor velocidad por sprint solamente consigue ocultar el retraso hasta los siguientes sprints, evitando así una de las ventajas de las metodologías ágiles : conseguir información por adelantado que nos permita tomar decisiones de manera temprana en el tiempo.

A modo de resumen:

No se deben estimar las historias finalizadas con el objetivo de aumentar la velocidad por sprint.
Se deben reestimar las historias cuyo tamaño y complejidad relativa hayan cambiado respecto al inicio de las estimaciones.

Cas 2010 - Día 2

2010-06-16T22:50:00.005+02:00

Con el cansancio acumulado del primer día pero con muchísimas ganas daba comienzo el segundo día de la conferencia.

Para empezar, uno de los platos fuertes de la conferencia: una mesa redonda de expertos donde se debatiría sobre el actual estado de las metodologías ágiles en España. Con participación de representantes de la industria, de la universidad y con algunos conocidos agilistas de la comunidad (Ángel Medinilla, José Manuel Beas y Xavier Quesada), lo que pretendía ser un apasionado debate, se quedó en algo un poco más descafeinado, debido a la poca controversia y diferencia de opiniones entre los ponentes. Por otra parte,me sorprendió gratamente ver que desde la Facultad de Informática de Madrid (FIUPM), teniendo en cuenta que la universidad es una institución eminentemente waterfall, se está apoyando y se está colaborando fuertemente en diferentes programas y de diferentes formas las metodologías ágiles.

En cuanto a las sesiones, igual que el primer día todas fueron de un gran nivel. En esta segunda jornada me centré más en sesiones a nivel de gestión o metodología y no tan centradas en prácticas de ingeniería, asisitiendo a Gestión de Ágil de Equipos e Itinerario de Implementación Ágil en la Empresa( Angel Medinilla) , Gestión ágil de requisitos (José Luis Soria), Prácticas recomendadas para la relación Cliente-Equipo... (Juan Garbajosa y Agustín Yague) y Diez maneras infalibles de asesinar Scrum (Rodrigo Corral).

Todas ellas excelentes, aunque me quedé con ganas de asistir a la sesión de Fórmula-1 y a la de TDD, pero la imposibilidad de dividirme en 2 personas, me obligó a tener que elegir unas y descartar otras!

Para finalizar, una sesión de retrospectiva, donde los asistentes podíamos decirle a la organización aquellas cosas que considerábamos se podían mejorar, aquellas que no nos habían gustado y claro está, las que se habían echo bien!! Una gran manera de involucrar a los asistentes a la vez que de intentar mejorar para futuras ediciones!

Como conclusión final, una gran conferencia, que ha sido todo un éxito tanto de asistencia como de contenidos (a mi juicio). Es estimulante saber que hay mucha gente que comparte las mismas inquietudes profesionales que tú, y es de esperar que eventos de este tipo ayuden a difundir el mensaje de que las metodologías ágiles pueden ayudar a las empresas que desarrollan software, no sólo, a ser más productivas y competitivas, sino a hacer del trabajo algo mas sostenible, motivador y ¿por qué no? , divertido!!

Un saludo!!

CAS 2010 - Día 1

2010-06-10T23:39:00.004+02:00

Hace poco más de 3 horas que ha finalizado la primera jornada de la conferencia agile-spain 2010, y sin necesidad de esperar a la segunda creo que se puede afirmar que va a ser todo un éxito. La asistencia ha sido muy alta (incluso se ha tenido que quedar gente fuera de la conferencia por problemas de aforo) lo que demuestra que el movimiento ágil está empezando a irrumpir con fuerza entre todos aquellos dedicados al mundo de las tecnologías de la información.

Resumiendo un poco este primer día, el plato estrella del día ha sido la KeyNote a cargo de Henrik Kniberg, sin duda una de las personas más relevantes del mundo en la divulgación de las metodologías ágiles, cosa que se puede entender viendo la soltura con la que se ha movido en el anfiteatro donde se llevaba a cabo la presentación. Henrik se ha metido al público en el bolsillo desde el minuto 0, y no lo ha dejado ir hasta el final, mientras iba explicando, de forma muy amena, conceptos de Scrum, Kanban o Xtreme Programming (a nivel introductor eso si). Sin duda alguna un gran inicio para la conferencia.

Después de la KeyNote han empezado los talleres y sesiones de la conferencia. La selección ha sido dura, pero finalmente he presenciado aquellas sesiones que creo que más me pueden ayudar en mi trabajo diario. Entre ellas ha habido sesiones relacionadas con prácticas técnicas, BDD o Diseño guiado por comportamiento, como montar un entorno completo de Integración Continua o una sesión (de nivel muy básico eso si) sobre buenas prácticas de desarrollo. Por otro lado he presenciado una sesión sobre como enfocar la implantación de Scrum en empresas grandes, y otra muy interesante sobre métricas y control de proyecto con metodologías ágiles.

Todas las sesiones han sido de un gran nivel y todos los ponentes lo han hecho estupendamente.

También la organización ha realizado un gran trabajo, e incluso haciendo honor al lema de que los cambios son bienvenidos en la agilidad, se ha solventado un problema de aforo en una sala (que era demasiado pequeña la verdad) realizando en poco minutos un traslado a otra sala mucho mas grande. Chapeau!!

Para resumir, algunas de las ideas con las que me quedo, para intentar mejorar en la implantación de Scrum de mi empresa:

Tener un Product Owner que haga bien su trabajo es condición, casi indispensable para que una metodología ágil funcione.
Las estimaciones de tareas a desarrollar mejoran, a medida que el número de personas implicadas en la misma aumenta.
Las estimaciones NO SON CONTRATOS!! Son inciertas y hay que aprender a vivir con ello.
Haz las cosas simples (KISS, Don't repeat yourself, YAGNI...). Que sea simple no quiere decir que sea fácil.
Necesitamos métricas explícitas para controlar los proyectos. Las métricas cuestan dinero. Minimiza el trabajo para conseguir las métricas que necesites.

Hay muchas más cosas, pero son demasiadas ideas para plasmarlas aquí, y además mañana continuamos con otro buen montón de sesiones, que a buen seguro van a se interesantísimas!

Esperemos que este tipo de eventos ayuden a difundir la cultura del agilismo en nuestro país, y que la gente involucrada de una manera u otra se den cuenta de que hay una manera mucho más sostenible, rentable, lógica e incluso divertida de llevar a cabo los proyectos tecnológicos.

Programa CAS2010

2010-05-06T18:04:00.009+02:00

Como ya anunció mi amigo Vicenç en Haciendo realidad la agilidad, los días 10 y 11 de Junio se celebra en Madrid la primera conferencia sobre métodos ágiles en España, con el reclamo de Henrik Kniberg como ponente principal del evento.

Pues bien, ya se ha hecho público el programa de la conferencia, donde además del mencionado Kniberg se van a dar cita algunas de las figuras mas importantes a nivel nacional dentro del movimiento de desarrollo y metodologías Ágiles cómo Angel Medinilla, Xavier Quesada, Rodrigo Corral o Xavier Albaladejo entre otros y donde podréis escoger entre sesiones y talleres de todos los gustos y colores.

Os recomiendo encarecidamente a todos los que tengáis algún tipo de interés o relación con las metodologías ágiles que no dudéis en pasaros por allí porque va a ser una gran oportunidad de aprender de la mano de los que más saben del tema, además de una gran oportunidad para intercambiar experiencias y conocimientos. Ahora el verdadero problema va a ser elegir entre tanta sesión de calidad!

Un saludo y nos vemos en Madrid!!

PD: Viendo el alto nivel de los ponentes no es de extrañar que mi propuesta de sesión sobre integración continua no haya pasado el corte (de todas maneras lo volveré a intentar el año que viene).

Tratando con Bugs en Scrum

2010-03-23T22:02:00.004+01:00

¿Se deben o no se deben estimar los BUGS usando Scrum? Nos preguntábamos hace unos días en el trabajo esta cuestión, sin llegar a tener claro cual debe ser el enfoque a utilizar para introducirlos de manera fluida en el ciclo de Scrum.

Durante mucho tiempo he defendido la idea de que los Bugs debían ser tratados cómo si fueran nuevas historias de usuario, , añadiendolos al backlog y realizando su correspondiente priorización y estimación en Puntos Historia. Esto funciona razonablemente bien si los Bugs detectados no son los suficientemente críticos cómo para poder esperar al siguiente Sprint para corregirlos, pero no es un buen método cuando los Bugs tienen que ser arreglados ya.

Además este enfoque presentaba algunos problemas teóricos relacionados con la metodología, a saber:

Estimación de un bug, implica contabilizar dos veces el mismo trabajo (uno cuando se estima la historia, y otro cuando se estima el trabajo para arreglar lo que se ha hecho mal en la historia)
Estimación en Scrum se utiliza para contabilizar el valor (relativo) que cada funcionalidad aporta al cliente, cómo los Bugs no aportan valor (más allà de solucionar un error cometido por nosotros mismos) no deberian estimarse.

En cambio, creo que el enfoque correcto (o el que a mi me gusta más) es el de tratar los Bugs como “tareas adicionales” dentro de la historia donde se ha generado.

Usando este enfoque, la estimación de la historia no varía, pero si que variará el tiempo dedicado a finalizarla, poniendo de relieve el impacto de los mismos en aquellas historias donde se producen y consiguiendo que la velocidad del equipo no sea un dato falseado (hacer muchos puntos en cada Sprint, pero teniendo que arreglar muchas de las historias en el/las siguiente/s iteraciones). Cómo consecuencia de esto, al tener más consciencia sobre el impacto de los Bugs en las historias implementadas, se puede lograr una disminución importante en los defectos de futuras iteraciones.

¿Cuál os parece a vosotros el enfoque mas adecuado? ¿Qué otro tipo de enfoque utilizáis para tratar los defectos ? Espero vuestros comentarios y aportes.

Haciendo realidad la agilidad

2010-03-19T18:31:00.002+01:00

Ya tenemos a la vuelta de la esquina la primera conferencia sobre métodos ágiles en España. Tendrá lugar el 10 y 11 de Junio en el Campus de la E.U. Informática de la U.P.M en Madrid. Podéis obtener toda la información que necesitéis en la web de la conferencia.

No seáis tímidos y proponed cosas! Podéis proponer sesiones, contribuciones y talleres. Vendrá Henrik Kniberg como orador, así no que no os podéis perder la oportunidad de compartir cartel con el.

Y por supuesto, si queréis patrocinar la conferencia lo podéis hacer.

Nos vemos el 10 de junio en Madrid!

Integración continua con Hudson

2010-02-26T11:21:00.000+01:00

Espero que a estas alturas de la película ya estemos todos convencidos de la necesidad de tener un mecanismo de integración continua en nuestro sistema de desarrollo. Hay un montón de herramientas que nos pueden ayudar como Team Foundation Server, Cruise Control o, el que empezaremos a ver hoy, Hudson.

Hoy empezaremos a ver como configurar Hudson para tener una tarea que se descargue un proyecto de Subversion, lo compile y pase los tests. Obviaremos la instalación tanto de Subversion como de Hudson por ser muy sencilla y poderse encontrar en muchos sitios.

Lo primero que tenemos que hacer una vez instalado Hudson tenemos que instalar los plugins que vamos a necesitar. En nuestro caso estos son: Hudson Subversion Plugin, Hudson MSBuild Plugin, Hudson MSTest Plugin y el imprescindible Chuck Norris Plugin :-). Para instalarlos tenemos que ir al menú Gestionar Hudson -> Gestionar Plugins, seleccionarlos de la pestaña Todos los plugins, seleccionar dichos plugins y clicar sobre el botón instalar.

Ahora vamos a configurar un poco Hudson antes de ponernos con las tareas. Nos vamos al menú de Gestionar Hudson -> Configurar Sistema y cambiamos la ruta del directorio raiz si lo consideramos conveniente.

También le tenemos que configurar la ruta del MSBuild para poder llamarlo en nuestra tarea

Y finalmente le vamos a configurar el servidor de correo a utilizar. Tenemos que configurar la dirección del administrador, la dirección del servidor de Hudson para que funcionen los links que se nos envian, el sufijo por defecto si queremos que se extraigan las direcciones de correo de los usuarios de subversion y la configuración de nuestro servidor de correo saliente, en nuestro caso gmail.

Ahora ya podemos empezar a configurar la tarea. Para ello hacemos click sobre el link Nueva Tarea y nos aparecerá una ventana con varias opciones. En nuestro caso escogemos "Crear un proyecto de estilo libre".
Lo primero es configurar es configurar un par de cosas básicas como la descripción de la tarea y el directorio personalizado del proyecto en caso de no querer el directorio por defecto de Hudson.

A continuación configuraremos el repositorio de subversion al que nos queremos conectar y la periodización de dicha conexión. En este caso nos conectaremos al repositorio para bajarnos el código a los cinco minutos de cada hora.

Ahora vamos a añadir un par de tareas para realizar tareas especificas de .Net. En este caso será realizar una compilación con MSBuild y lanzar los tests con MSTest. Para la tarea de MSBuild añadiremos la tarea llamada "Build a Visual Studio project or solution using MSBuild", escogemos la versión de MSBuild adecuada para nuestro proyecto, la solución a compilar y los parámetros de dicha compilación.

Seguidamente añadiremos un nuevo paso del tipo "ejecutar línea de comandos (shell)" para ejecutar los tests. Tenemos que introducir manualmente el comando para ejecutar MSTest desde línea de comandos generando un archivo .trx con los resultados de los tests para que Hudson los pueda interpretar.

Finalmente sólo nos falta configurar las opciones que nos interesen de las que ofrece Hudson al final de la página de configuración. En nuestro caso será necesario activar la opción "Publish MSTest result report" (especificando el archivo .trx que hemos generado anteriormente), "Notificación por correo" y, claro está, "Activate Chuck Norris" :-). Ahora ya podemos clicar sobre el link "Construir ahora". En caso que algún paso no esté bien configurado o el programa dé algún error, se nos enviará un mail con el error y en la página web de Hudson nos aparecerá la tarea al lado de un circulo rojo indicando que hay algún error. Si todo está bien, el circulo será azul y sólo se nos enviará un mail en caso que anteriormente hubiera habido una ejecución incorrecta, informándonos así que la build vuelve a estar bien.

Espero que con este tutorial podáis empezar a trabajar con Hudson. Es un gran programa con un montón de opciones que iremos comentando a medida que nos parezcan interesantes.

Programación asíncrona

2010-01-30T13:13:00.002+01:00

Hoy vamos a hacer un post un poco más técnico, que ya hace tiempo que no hacemos ninguno. Vamos a hablar, en la línea de este otro post, de la programación asíncrona.

Quién no se ha encontrado alguna vez con la necesidad de hacer una tarea que consume mucho tiempo ( acceso a ficheros, cálculos complejos, acceso a la red, etc ) y no quiere que su interfície de usuario se vea afectado por ello? No veo ninguna mano alzada, así que supondremos que es algo recurrente.

Este tipo de programación se ha llevado a cabo históricamente mediante hilos. Aunque .Net ha facilitado mucho la programación con ellos, hacer un uso de los mismos no deja de ser añadir complejidad al programa y es una fuente típica de errores. Es por esto que existen otras alternativas a la programación asíncrona sin tener que utilizar explícitamente hilos. Estas alternativas son las siguientes:

Llamadas asíncronas a delegados.
Llamadas asíncronas utilizando la interfaz IAsyncResult.
El componente BackgroundWorker.
Llamadas asíncronas basadas en eventos.

En este artículo nos centraremos en esta última aproximación ya que es la más completa y la más recomendada.

Este patrón se apoya en la utilización de dos clases de ayuda proporcionadas por .Net: la clase AsyncOperationManager que utilizaremos para crear instancias de la otra clase de ayuda, la AsyncOperation que utilizaremos para efectuar el seguimiento del progreso de la tarea asíncrona e informar del mismo. Una de las ventajas que tiene es que los eventos de progreso y cancelación se hace en el hilo adecuado, con lo que podemos actualizar la interfíce de usuario directamente, sin tener que recurrir a Invoke.

Vamos a ver paso a paso como crear una clase que implemente este patrón y como crear una clase cliente que la instancie y utilice.

Lo primero que tenemos que hacer es, obviamente, crear nuestra clase que queremos que se pueda llamar de manera asíncrona. En nuestro caso creamos una clase llamada LazyClass.

Seguidamente vamos a declarar los delegados y los eventos públicos que necesitamos para informar al cliente del progreso y terminación de la tarea asíncrona.

public delegate void LazyTaskProgressChangedEventHandler(LazyTaskProgressChangedEventArgs pArgs);
public delegate void LazyTaskCompletedEventHandler(object pSender, LazyTaskCompletedEventArgs pArgs);

Esto nos obliga a definir los argumentos LazyTaskCompletedEventArgs y LazyTaskProgressChangedEventArgs.

La clase LazyTaskCompletedEventArgs tendrá la definición de las cosas que queremos que se informen al exterior cuando se haya terminado la tarea asíncrona. Esta clase puede ser tan compleja como queramos, aunque nosotros, por el bien del entendimiento del ejemplo, la hemos reducido lo máximo posible.

public class LazyTaskCompletedEventArgs : AsyncCompletedEventArgs

{

private int m_iNumIterations = int.MinValue;

private int m_iTotalTime = int.MinValue;

///

/// Constructor

///

public LazyTaskCompletedEventArgs(int pNumIterations, int pTotalTime, Exception pException, bool pCancelled, object pState) : base (pException, pCancelled, pState )

{

m_iNumIterations = pNumIterations;

m_iTotalTime = pTotalTime;

}

///

/// Número de iteraciones

///

public int NumIterations

{

get

{

RaiseExceptionIfNecessary();

return m_iNumIterations;

}

///

/// Tiempo transcurrido

///

public int TotalTime

{

get

{

RaiseExceptionIfNecessary();

return m_iTotalTime;

}

Como se puede ver, en cada una de las propiedades antes de devolver el valor se llama a una función ( del espacio de nombres System.ComponentModel ) llamada RaiseExceptionIfNecessary. Esta función se utiliza para evitar que alguien acceda a los valores de la clase si se ha producido algún error o se ha cancelado la invocación asíncrona. En tal caso, al acceder a cualquiera de las propiedades de la clase recibiremos una excepción del tipo InvalidOperationException.

La clase LazyTaskProgressChangedEventArgs derivará de la clase ProgressChangedEventArgs del espacio de nombres System.ComponentModel. En nuestro caso no le añadimos nada ( con el porcentaje tenemos suficiente ) pero se le podría añadir todo lo necesario para nuestra tarea en concreto.

///

/// Classe que define los argumentos del progreso de la tarea

///

public class LazyTaskProgressChangedEventArgs : ProgressChangedEventArgs

{

public LazyTaskProgressChangedEventArgs(int pPercentatge, object pState)

: base(pPercentatge, pState)

{

}

Lo siguiente es implementar los delegados privados que utilizaremos como puente para informar al cliente del progreso de la tarea. Estos delegados tendrán una firma del tipo SendOrPostCallback, definida también en el espacio de nombres System.ComponentModel.

private SendOrPostCallback onProgressDelegate;

private SendOrPostCallback onCompletedDelegate;

Y los inicializamos en el constructor de la clase:

onProgressDelegate = new SendOrPostCallback(LazyTaskProgress);

onCompletedDelegate = new SendOrPostCallback(LazyTaskCompleted);

A continuación vamos a declarar el delegado encargado de realizar el trabajo que queramos hacer en nuestra clase. Este delegado tendrá que recibir un parámetro del tipo AsyncOperation que se utilizará para hacer el seguimiento del progreso de la tarea asíncrona y un delegado de tipo SendOrPostCallback que se utilizará para notificar del fin de la operación. También puede recibir cualquier otro parámetro que necesitemos para la ejecución de la tarea.

private delegate void WorkerEventHandler ( AsyncOperation pOperation, SendOrPostCallback pCompletionMethod );

Después declararemos una colección para administrar las diferentes operaciones asíncronas que se produzcan en nuestra clase. Podemos utilizar un Dictionary, un HibrydDictionary o lo que más nos convenga.

ListDictionary m_ldTasks = new ListDictionary();

A continuación pasamos a implementar los eventos públicos que utilizaremos para informar al cliente del progreso y terminación de la tarea asíncrona.

///

/// Implementación del delegado del progreso

///

private void LazyTaskProgress(object pSate)

{

ProgressChangedEventArgs e = pSate as LazyTaskProgressChangedEventArgs;

FireOnLazyTaskProgressChanged(e);

}

///

/// Implementación del delegado de tarea completada

///

private void LazyTaskCompleted(object pSate)

{

LazyTaskCompletedEventArgs args = pSate as LazyTaskCompletedEventArgs;

FireOnLazyTaskCompleted(args);

}

///

/// Lanza el evento de tarea completada

///

private void FireOnLazyTaskCompleted(LazyTaskCompletedEventArgs pArgs)

{

if (OnLazyTaskCompleted != null)

{

OnLazyTaskCompleted(this, pArgs);

}

///

/// Lanza el evento de progreso en la tarea

///

private void FireOnLazyTaskProgressChanged(LazyTaskProgressChangedEventArgs e)

{

if (OnLazyTaskProgressChanged != null)

{

OnLazyTaskProgressChanged(e);

}

Y para acabar con la implementación de delegados tan sólo nos falta implementar el delegado de finalización de la tarea. Este delegado se llamará cuando se haya terminado la ejecución de nuestra tarea. En este método es donde se elimina el identificador de la tarea de la colección y donde se da por terminada la tarea asíncrona llamando al método PostOperationCompleted. Una vez llamado este método, cualquier intento de utilización de la AsyncOperation a la que se refiere nos dará una excepción.

/// Método que se llamará cuando la ejecución de la tarea de forma asíncrona haya acabado

///

private void LazyTaskCompletionMethod(object pLazyTaskState)

{

LazyTaskState taskState = pLazyTaskState as LazyTaskState;

AsyncOperation operation = taskState.Operation;

int iNumIterations = taskState.NumIterations;

int iTotalTime = taskState.TotalTime;

bool bCancelled = false;

Exception eException = taskState.TaskException;

LazyTaskCompletedEventArgs args = new LazyTaskCompletedEventArgs(iNumIterations, iTotalTime, eException, bCancelled, operation.UserSuppliedState);

lock (m_ldTasks.SyncRoot)

{

if (m_ldTasks.Contains(operation.UserSuppliedState))

{

m_ldTasks.Remove(operation.UserSuppliedState);

}

operation.PostOperationCompleted(onCompletedDelegate, args);

}

Ahora ya podemos pasar a implementar la función que hará el trabajo real de nuestra clase. En nuestro caso será algo tan trivial como un for con un sleep dentro para simular una tarea pesada.

///

/// Realiza la operación que queremos

///

private void DoTask(AsyncOperation pOperation, SendOrPostCallback pCompletionMethod)

{

Exception ex = null;

try

{

for (int i = 0; i < 100; i++)

{

if (!TaskCanceled(pOperation.UserSuppliedState))

{

System.Threading.Thread.Sleep(100);

LazyTaskProgressChangedEventArgs pChangedEventArgs = new LazyTaskProgressChangedEventArgs(i + 1, pOperation.UserSuppliedState);

pOperation.Post(this.onProgressDelegate, pChangedEventArgs);

}

catch ( Exception e )

{

ex = e;

}

if (!TaskCanceled(pOperation.UserSuppliedState))

{

LazyTaskState state = new LazyTaskState(100, 10000, pOperation, ex);

pCompletionMethod(state);

}

En este código podemos ver tres cosas. La primera es que nos apoyamos en una función llamada TaskCancelled. Esta función, que la debemos implementar nosotros, simplemente mira en la colección si está el identificador de tarea que le pasamos como parámetro. Por otra parte podemos ver que cada vez que queremos informar de un cambio en el progreso de la tarea llamamos a la función Post de la AsyncOperation que recibimos como parámetro. Y finalmente vemos que cuando acabamos la realización de la tarea llamamos al delegado del completionMethod.

Y ya nos vamos acercando al final. Ahora tan sólo nos queda implementar los métodos para iniciar y cancelar el trabajo. En el método para iniciar la tarea nos tendremos que asegurar que el identificador de tarea que nos pasan cómo parámetro es único mirando si está en la colección. En el método para cancelar, tan sólo tendremos que quitar la tarea de la colección. El framework hará el resto.

///

/// Realiza la tarea asíncronamente

///

public virtual void DoLazyTaskAsync(object pTaskID)

{

AsyncOperation operation = AsyncOperationManager.CreateOperation(pTaskID);

lock (m_ldTasks.SyncRoot)

{

if (m_ldTasks.Contains(pTaskID))

{

throw new ArgumentException("Ya existe una tarea con este identificador", "taskID");

}

m_ldTasks[pTaskID] = operation;

}

doTaskDelegate = new WorkerEventHandler(DoTask);

doTaskDelegate.BeginInvoke(operation, completionMethodDelgate, null, null);

}

///

/// Cancela la ejecución de una tarea asíncrona

///

public void CancelLazyTaskAsync(object pTaskId)

{

lock (m_ldTasks.SyncRoot)

{

if ( m_ldTasks.Contains(pTaskId ) )

{

AsyncOperation operation = (AsyncOperation)m_ldTasks[pTaskId];

if (operation != null)

{

m_ldTasks.Remove(pTaskId);

}

Ya tenemos nuestra clase con una llamada a un método asíncrono preparada para ser utilizada por un cliente. Para completar su funcionalidad deberíamos tener también un método para que podamos llamarla de forma síncrona por si nos interesa.

La implementación del cliente es muy sencilla. Simplemente nos tenemos que subscribir a los eventos de progreso y finalización y llamar a los métodos de inicio y cancelación cuando nos interese. Podéis ver el código completo en el adjunto.

Espero que este pequeño ejemplo os haya servido de ayuda. Podéis descargaros el ejemplo de aquí.

Programación en pareja

2010-01-17T22:03:00.002+01:00

Esta es más o menos la cara que se le queda a un gestor de proyectos tradicional cuando le comentas que quieres implantar que el equipo trabaje en parejas. Sin embargo es una de las mejores decisiones que hemos tomado para mejorar la calidad de nuestro código. Que ventajas le vemos? Pues las siguientes serian las principales:

Calidad del análisis previo: no sólo programamos en pareja, sino que también hacemos el análisis técnico de la solución en pareja. Esto hace que el diseño sea mucho mejor ya que el error que uno sólo no detectaría, con la ayuda del otro si que lo hace.
Calidad del código: el código que sale de la programación en parejas es de mucha más calidad que el hecho por uno sólo. La idea que no tiene uno, la tiene el otro. El comentario que a uno le da pereza añadir, el otro se lo recuerda. El test que uno no cree necesario hacer, el otro le obliga a hacerlo. Y así una larga lista.
Concentración: si uno trabaja sólo y tiene ciertos problemas de concentración es posible que no dedique todo el tiempo que seria deseable a programar. Messenger, mail, charlas con el compañero son pequeñas cosas que, si no se gestionan correctamente, pueden hacer perder mucho tiempo a un programador. Trabajando en pareja esto se minimiza muchísimo. Nadie se atreve a charlar por el messenger si está con el compañero trabajando. El focus se aumenta muchísimo.
Aprendizaje: siempre se aprenden cosas de los compañeros, a no ser que haya demasiada diferencia entre las capacidades de ambos, con lo cual sólo aprendería uno. Pero si la pareja está bien montada ambos aprenden el uno del otro.
Propiedad colectiva del código: al ir cambiando de pareja y de tarea el conocimiento de las características del código va fluyendo entre los integrantes del equipo, haciendo mucho más fácil que alguien se incorpore al equipo.
Ánimo del equipo: en general a la gente le gusta más trabajar en equipo que no sólo y el hacerlo le anima a seguir trabajando y cohesiona al grupo.

Así que espero que a partir de ahora os animéis a probar la programación en pareja!

Planificando entregas con Scrum (I)

2010-01-11T22:01:00.010+01:00

En el post que nos ocupa vamos a ver los pasos para realizar la planificación de las diferentes entregas o releases de un proyecto, utilizando Scrum (aunque este proceso podría fácilmente aplicarse a cualquier metodología iterativa).

Lo que se quiere conseguir es crear una planificación a mas largo plazo, de mas duración que una iteración y que abarque las diferentes entregas del proyecto (que pueden ser varias si se realiza por fases o puede ser una única entrega), y que permita definir una previsión de que funcionalidades se podrán tener finalizadas en una determinada fecha.

En su estado más básico, una planificación de entrega o de proyecto debería contar con como mínimo la siguiente información:

Una lista de historias de usuario, a ser posible estimadas y priorizadas (product backlog)
Los miembros del equipo que participan en el proyecto (desarrolladores, analistas, administradores de bbdd...)
Fecha de inicio de la primera iteración y fecha de fin de la última iteración.

Es importante indicar que este nivel de planificación no se debe caer en el error de intentar entrar en el detalle de que personas van a realizar que tareas, en que secuencia se van a realizar las mismas etc... Estos detalles deben dejarse para la planificación de cada iteración, momento en el que las historias de usuario se dividen en tareas a nivel técnico.

Los pasos generales para realizar la planificación de las entregas son los siguientes:

Determinar los criterios mas relevantes para el éxito del proyecto, por ejemplo entregar antes de una fecha determinada, tener un conjunto mínimo de funcionalidades pero una fecha flexible, una combinación de ambas...

Realizar la estimación de las historias de usuario, concretamente de aquellas que tienen una alta probabilidad de formar parte de la siguiente entrega. Este proceso se realiza entre el Product Owner y los miembros del equipo (¡¡Solo hace estimaciones el equipo!!) y se estima en puntos de historia o días ideales (y usando alguna técnica estilo Planning Poker)

Seleccionar la duración de las iteraciones, en base a la duración del proyecto. Lo normal es de 2 a 4 semanas, pero en proyectos de larga duración se pueden realizar iteraciones mas largas (aunque yo no lo recomiendo) o en proyectos muy cortos se pueden llegar a hacer iteraciones de una única semana.

Realizar una estimación de la velocidad, en puntos de historia (o días ideales) del equipo. Si este ya ha trabajado junto se puede utilizar la velocidad media en anteriores iteraciones, si no lo mejor es hacer una estimación con alguna de las técnicas existentes para ello y ir ajustándola a medida que avance el proyecto.

Priorizar las historias de usuario, de manera que siempre esté claro cual es la siguiente a desarrollar. Una buena manera de asegurar esto es utilizando el enfoque de Henrik Kniberg en su muy recomendable Scrum and XP For The Trenches, donde utiliza el atributo importancia, en lugar de prioridad. La priorización la decide el Product Owner, pero es aconsejable que escuche la opinión de los miembros del equipo, sobre todo en cuestiones relativa a la secuenciación de las historias de usuario.

Seleccionar las historias y la fecha de entrega, en base a la velocidad y a la estimación realizada. Si el factor mas importante en el proyecto es la fecha de entrega, lo que se hará será calcular el conjunto de funcionalidades que se preveen tener listas para esa fecha, si por el contrario, el factor importante son las funcionalidades mínimas, se deduce la fecha estimada de finalización.

Comprobar que se cumplen los criterios de éxito del proyecto. Si no es así se debe volver a los procesos de estimación y priorización, haciendo los cambios necesarios (subdividir historias en otras mas pequeñas, cambiando la priorización...) hasta conseguir dar con un grupo de funcionalidades para la entrega que cumpla con los criterios de éxito.

Otras cosa a tener en cuenta durante el proceso es la decisión de determinar por adelantado que funcionalidades se desarrollarán en cada iteración, o por el contrario sólo se deciden las funcionalidades a entregar en la iteración más próxima (de entre todas las planeadas para la entrega)

Cómo punto final, remarcar que es importantísimo que la planificación no sea un "papel colgado en la pared", sinó que hay que ir actualizándola y revisándola con cierta frecuencia, de manera que se pueda conocer rápidamente las desviaciones o los cambios que ocurren. Una buena opción es replanificar al inicio de cada iteración , justo antes de la planificación de la misma.

Aprovecho para hacer referencia al post anterior Calendario de Sprint relacionando el concepto aquí explicado, con una de las reuniones propuestas en el mismo. Concretamente, la planificación de entregas seria lo que en el calendario llamabamos Project Planning (aunque en algunas organizaciones podría ser una fusión de las dos primeras reuniones explicadas, Project Review y Project Planning)

En el siguiente Post, mostraré un ejemplo práctico de cómo realizar la Planificación de Entregas de un proyecto sencillo.

Calendario de Sprint

2009-12-26T11:35:00.002+01:00

Uno de los mayores problemas que se pueden dar en una implantación de Scrum es el empezar con la idea preconcebida de que es una metodología que no requiere "mucho esfuerzo". Esto le sucede a mucha gente que ha oído hablar de Scrum o metodologías ágiles en general y que únicamente se han quedado con la idea de que Scrum es "no documentar" o barbaridades similares. Pero la realidad es que implantar Scrum en una empresa o departamento requiere de mucho esfuerzo y ganas por parte de todos los implicados. En este post voy a tratar de explicar una manera de enfocar Scrum que creo que puede ser muy útil, sobretodo al inicio de una implantación. Para ello lo único que se necesita es crear un Calendario de Sprint.

Aunque parezca algo trivial, hacer un calendario nos puede ayudar sobretodo en las primeras etapas de la implementación de la metodología, cuando aún no están claras las diferentes prácticas y artefactos que intervienen en Scrum. El calendario de Sprint que os propongo está basado mas o menos en cómo funcionamos en nuestra empresa (Sprints de dos semanas y de miércoles a miércoles) pero obviamente se puede adaptar a lo que mas convenga a cada equipo y/o empresa.

El calendario propuesto es el siguiente:

Ahora vamos a detallar que significa cada uno de los diferentes puntos del calendario:

Project Review

Descripción: Revisión del estado de los proyectos. Comunicación de cambios de requisitos, modificaciones, problemas, riesgos,impedimentos, etc...
Duración: 1h
Asistentes: Responsables de proyectos y personas implicadas (clientes, gestores, gerentes, etc.)
Documentación: Acta de reunión documentando todos los cambios y las decisiones tomadas.

Project Planning

Descripción: Adición, eliminación o división de historias de usuario de cada proyecto (en base a lo detectado en la reunión de Project Review). Priorización y estimación de las nuevas historias de usuario y preselección de aquellas a desarrollar en el nuevo Sprint.

Duración: 1h

Asistentes: Responsables de proyectos y miembros del equipo de desarrollo (no tienen porque ser todos)

Documentación: ProductBacklog y documentos de diseño si son necesarios.

Sprint Planning

Descripción: Decidir los puntos a hacer durante el Sprint (basado en los días laborables, recursos disponibles y proyectos en curso). División en tareas de las historias escogidas y estimación (en horas ideales o puntos de historia). Escoger nuevas historias si caben en el Sprint. Preparación del Task Board

Duración: 2h

Asistentes: Equipo de desarrollo

Documentación: SprintBacklog y toda la información adicional necesaria(decisiones de diseño, dudas, comentarios...).

Daily Scrum

Descripción: Sincronización de las tareas diarias hechas y actualización del Task Board.

Duración: 10 mins.

Asistentes: Equipo de desarrollo.

Documentación: Actualización del estado del Sprint Backlog.

Sprint Review

Descripción: Demostración funcional de las historias desarrolladas durante el Sprint.

Duración: 1h

Asistentes: Equipo de desarrollo, cualquier persona interesada en el proyecto

Documentación: Acta de la reunión con el feedback proporcionado, y con posibles errores y bugs encontrados durante la demo (Esta información se utilizará en la siguiente reunión de Project Review)

Sprint Retrospective

Descripción: Valoración del sprint (objetivos, gestión, resolución de impedimentos, etc.)

Duración: 1h

Asistentes: Equipo de desarrollo

Documentación: Acta de la reunión con las conclusiones y los objetivos para el siguiente sprint.

Lab

Descripción: Tiempo dedicado a investigación/pruebas sobre temas interesantes para cada persona

Duración: 1h

Asistentes: Equipo de desarrollo

Cómo se puede ver el calendario es simplemente una guía o base para seguir durante los Sprints, y no se tienen en cuenta todos los aspectos que pueden ir apareciendo durante el mismo (reuniones con clientes, sesiones de diseño, etc...), pero a pesar de todo creo que puede ser una buena práctica para aquellos equipos u organizaciones que están empezando con la implantación de Scrum.

Scrum y la motivación

2009-11-05T12:31:00.000+01:00

Uno de los handicaps mas importantes de cualquier proyecto de software suele ser la motivación de los integrantes del equipo. Es muy dificil llevar a buen puerto un proyecto si el equipo no está lo suficientemente motivado e identificado con el mismo, por eso mismo creo que uno de los objetivos y de las prioridades de cualquier jefe o responsable de proyecto debería ser siempre intentar mantener un alto grado de motivación y compromiso por parte del equipo.
Sin entrar a juzgar los diferentes tipos de "técnicas" o estrategias de motivación que suelen usar en la mayoria de proyectos de software los gerentes, gestores o responsables de proyecto que corren por el mundo, voy a intentar mostrar cómo Scrum puede ayudarnos un poco a la hora de mejorar la motivación y el compromiso buscados. Para ello vamos a repasar algunos de los conceptos y de puntos que forman o que persigue la metodología y ver cómo nos pueden ayudar:

Reunión planificación de proyecto/sprint: Estas reuniones aumentan la visibilidad del equipo respecto a los diferentes proyectos en los que tienen que participar,y además, al participar plenamente en la toma de decisiones (a nivel de diseño, arquitectura, desarrollo...) los miembros del equipo suelen considerar el proyecto cómo algo propio, aumentado de esta manera la motivación, y probablemente con ello la velocidad y calidad de los desarrollos.
Seguimiento diario: Con las reuniones de seguimiento diario se consigue que las personas mantengan un grado de concentración mayor, y una responsabilidad para con los otros miembros del equipo (al tener que responder de los avances delante de ellos) con lo que de nuevo aumenta la motivación de cara al proyecto.
Demostraciones: Las demostraciones al final de la iteración consiguen que el equipo observe su trabajo, lo muestre y vea las reacciones de otra gente de la compañia. Es cómo un reconocimiento (siempre que la demo vaya bien ;) ) al trabajo hecho, cosa que ayuda de nuevo a que el equipo siga motivado para la siguiente iteración.
Retrospectivas: El hacer que el equipo pueda opinar sobre como ha ido la iteración fomenta de nuevo el sentimiento de equipo y de propiedad de los proyectos, que cómo pasa en los puntos anteriores ayudan a que las personas sigan motivadas.

Con los puntos vistos anteriormente, vemos que aplicando Scrum , de manera implicita, se fomenta la motivación del equipo, sin necesidad de técnicas de presión, amenazas, etc. a las que tanto se recurre habitualmente.

Un saludo!

Primeros pasos debugando de verdad

2009-08-21T16:11:00.003+02:00

El otro dia nos encontramos con un problema en el trabajo. Teniamos una aplicación que cascaba aleatoriamente y no sabíamos por que. Teníamos que encontrar el problema y solucionarlo de manera urgente o algún cliente estaria muy pero que muy enfadado.

Como profanos en la materia empezamos nuestro estudio con nuestro amigo el Administrador de Tareas de windows. Un vistazo a la memória del proceso y al máximo de memória nos hacía pensar que alguna acción de nuestra aplicación hacia que la memória tubiera picos que después se recuperaban. En uno de estos picos, la aplicación acababa diciendo basta y empezaba a funcionar muy mal, llegando a cerrarse. Como primer paso no estaba mal, pero no teniamos ni idea de cómo solucionarlo.

Después de un rato navegando por internet buscando información sobre profilers nos decidimos a probar el windbg. Algunos artículos de los grandes Rodrigo Corral, Pablo Doval y David Salgado nos ayudaron a hacer nuestros primeros pinitos con la herramienta, pero todavía no eramos lo suficientemente hombres cómo para utilizarla correctamente, así que buscamos alguna otra manera de hacerlo.

Llegamos a este artículo de Ro drig o donde se comenta cómo determinar que tipo de problema de memoria tiene una aplicación. Pusimos los tres contadores en la máquina de preproducción ( bytes privados del proceso, bytes en todos los montones y colecciones de generación 2 ) y lo que parecía indicar el gráfico resultate ( ver imágen ) es que no teniamos una fuga de memoria ( o por lo menos no era nuestro mayor problema ) sinó que teniamos un incremento escandaloso de memoria manejada. Esto nos llevó directos a la segunda parte del artículo de Rodrigo, donde se habla de la herramienta CLRProfiler. Con esta herramienta pudimos ver que función era la que creaba el problema.

Lo que hacía la función era cargar un archivo en memoria para calcularle un MD5. Cómo esta operación se podia realizar a la vez en unos 50 ficheros que podian llegar a los 5MB, el incremento de memoria que tenia el sistema era preocupante. Modificamos esta función para no cargar todo el archivo y hacerla más liviana y el problema se vió reducido a la nada.

Esto es sólo el principio de lo que esperamos sea un aprendizaje de todas estas herramientas y de las entrañas del CLR. Intentaremos ir posteando nuestras experiéncias y las cosas que vayamos aprendiendo.

Saludos!

El tablón como herramienta de gestión

2009-05-11T23:16:00.000+02:00

Uno de las prácticas de más importancia cuando se habla de Scrum son las reuniones diarias delante del tablón. A pesar de ello son pocos los equipos que utilizan un tablón cómo herramienta de gestión (al menos que yo conozca), o si lo utilizan normalmente no se le extrae todo el provecho posible ¿Que ventajas puede aportar el utilizar un tablón donde se registran las tareas, su estado, el trabajo que nos queda...? ¿No es posible realizar esto mismo con una herramienta informática evitando así perder un tiempo valiosísimo cada día delante del tablón?

Desde mi punto de vista, y basándome en mi (todavía poca) experiencia, la utilización correcta del tablón de Scrum en las reuniones diarias es una de las prácticas indispensables de la metodología, y aunque cada organización que implante Scrum puede y debe adaptarla a sus necesidades, estas reuniones no deberían faltar, ya que muchas de las ventajas que aporta la metodología se consigue a través de esta práctica (comunicación, colaboración...)

Obviamente es básica la utilización de alguna herramienta de software adicional (por ejemplo Hojas Excel, Jira, Trac, Team Foundation Server o cualquier otra que se adecue a nuestras necesidades) ya sea para tener trazabilidad e información del estado de las diferentes tareas de un proyecto, por temas legales (auditorías, certificados de calidad, ...) o por cualquier otra necesidad, pero combinándolo con la gestión día a día delante del tablón es cuando vamos a conseguir explotar mucho mas las ventajas de Scrum (algunas explícitas otras más implícitas):

-Sensación real y inmediata de progreso (o de no progreso)
-Visibilidad a terceros del estado del proyecto
-Mayor sensación de equipo
-Mayor motivación entre los miembros del equipo
-Identificación con los proyectos y responsabilidad para con ellos

Sin la utilización de un tablón los programadores y otros componentes del equipo no van a tener una visión global y fácilmente accesible del avance del proyecto, ni tampoco otros roles interesados en el estado (comerciales, directivos, analistas de negocio...), lo que puede generar en desconfianzas, desmotivaciones, etc...

Si por el contrario mantenemos el tablón actualizado y bien visible vamos a conseguir que, además de las ventajas listadas antes , los roles interesados en el avance del proyecto conozcan la velocidad y la capacidad de generar software de cada equipo, lo que debería desembocar en un mayor entendimiento entre los diferentes departamentos de la organización implicados o interesados en el desarrollo de una determinada pieza de software evitando en la medida de lo posible las interferencias en medio de iteraciones, etc.

¿Que opináis vosotros sobre la gestión con el tablón? ¿Que ventajas o inconvenientes encontráis?

Programando con estilo

2009-03-26T16:49:00.005+01:00

Antecedentes

Tradicionalmente el desarrollo de software ha sido una actividad individual. Muchos proyectos se llevaban a cabo con la participación de un único programador, o dos a lo sumo, que se encargaban de todas y cada una de las fases del proyecto. A medida que las necesidades de los usuarios han ido aumentado y la tecnología avanzando, el ámbito de los proyectos ha crecido, y con ello la necesidad de añadir más participantes (no sólo programadores sino también otros roles) al proceso de desarrollo de software. Este cambio, el paso de trabajar individualmente a trabajar en equipo, requiere un esfuerzo por parte de las personas involucradas, pero es especialmente importante el impacto que tiene en los programadores (se pasa de un programador que controla todas y cada una de las partes del código a un mismo código que puede ser modificado por varios individuos a la vez) Para solucionar este problema se empezaron a utilizar herramientas cómo el control de versiones, pero no basta con esto. Problemas cómo la poca documentación en el código, la poca estructuración, nomenclaturas extrañas... dificultan la legibilidad del código cuando un programador tiene que modificar código realizado por otro (o incluso cuando se tiene que tocar código realizado por uno mismo tiempo atrás) Esto acaba repercutiendo en una menor productividad de los desarrolladores hace los códigos poco reusables,escalables, etc.
Para solucionar esto se necesita organización y disciplina por parte de los implicados y es aquí donde puede entrar en juego la Guía de estilo.

¿Qué es?

Una guía de estilo no es mas que la definición de una serie de pautas que han de seguir los programadores cuando estén creando o modificando código. Una guia de estilo hace incidencia en cómo debe presentarse el código, o sea en la forma y no en el fondo del mismo. Pero cómo ahora veremos, esto tiene un importante impacto en cómo va a funcionar el mismo.

Las pautas que puede dictar una guía de estilo son muchas, desde cómo debe indentarse el código, a cómo se deben nombrar las variables, funciones, métodos, clases u objetos que aparecen en el código. También son muy importantes los comentarios realizados en él, y más si estamos trabajando en el ámbito de una metodología ágil donde el código se considera parte esencial de la documentación del proyecto.

¿Que nos aporta?

A priori se puede pensar que aplicar una guia de estilo al código de nuestros proyectos es simplemente una herramienta de “burocratización” que lo único que hará será más lenta y tediosa la tarea de programar (muchos programadores son reacios a ello, sobretodo los que estan acostumbrados a trabajar de manera individual), pero la realidad es bien distinta. La principal aportación de “estandarizar” el código es el incremento de la legibilidad por parte de todos los desarrolladores, haciendo que disminuya el tiempo que una persona necesita para entender el código, ganando tiempo al codificar (al asimilar las reglas de nombrado de clases, variables, etc, se pierde menos tiempo), facilitando la refactorización, lo que puede llevar a incrementar la escalabilidad del código, la reusabilidad, la modularidad, la facilidad para la generación de testos unitarios,etc.

Toda esta serie de mejoras que se pueden conseguir acaban impactando en dos factores clave para cualquier proyecto de software:
● La calidad del código
● La productividad de los programadores

Ejemplos

Algunos ejemplos de Guias de Estilo que podems encontrar en Internet pueden ser los siguientes:

Guia de estilo para el diseño de aplicaciones .NET - http://msdn.microsoft.com/es-es/library/czefa0ke(VS.71).aspx
Guía de estilo Philips Medical Systems(C#) -http://www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf
Guía de estilo programación en Java - http://java.sun.com/docs/codeconv/
Guía de estilo Mono: http://www.mono-project.com/Coding_Guidelines
Guía de estilo para el nucleo de Linux: http://lxr.linux.no/linux/Documentation/CodingStyle

Para empezar no se debe intentar implantar una guia de las dimensiones y el alcanze de las aquí mostradas. Es mucho mejor empezar con pocas reglas y irla adaptando y ampliando a medida que sea posible y/o necesario.

Conclusiones

Cómo se puede ver una guia de estilo es una excelente manera de “estandarizar” el código de los proyectos de desarrollo de software, estandarización que puede impactar muy positivamente en la productividad y la calidad de los desarrollos siempre y cuando realmente se aplique a la hora de las implementaciones.
La poca predisposición por parte de muchos desarrolladores a que “les digan” cómo deben hacer su código, y la dificultad para realizar un control de manera eficiente (puede ser peor el remedio que la enfermedad) hacen que la implantación de una guia de estilo de manera que tenga un impacto real sea dificil. Si por el contrario los desarrolladores ponen de su parte y se puede llevar a cabo un control que imponga burocracia 0 (hay herramientas que permiten este control de manera sencilla) para hacer que el código cumpla con la guía los beneficios que aportará al proyecto serán muchos e importantes .

Agile Open Buenos Aires

2009-03-15T19:38:00.010+01:00

El pasado 6 y 7 de Marzo tuve el placer de asistir al Agile Open Buenos Aires. Este evento, organizado por la comunidad latinoamericana de metodologías ágiles, se desarrolló en formato Open Space y fue sumamente interesante.

El evento se dividió en dos sesiones. El primer día se dedicó a planear los temas de las charlas y el horario de las mismas y el segundo se dedicó a las charlas en sí.

Lo primero que me gustaría destacar es la afluencia de público a estas sesiones. Debíamos ser unas cien personas hablando de metodologías ágiles! Sinceramente, a día de hoy no me imagino un evento de esta magnitud aquí en España. Espero que muy pronto, con el impulso que le estamos dando desde la comunidad española, esto sea posible.

Así pues nos encontramos cien personas el viernes por la tarde para hablar sobre metodologías ágiles. Nuestro facilitador fue Alan Cyment, ayudado en todo momento de su inseparable campana.

Lo primero que hicimos fue proponer el tema de las charlas. Cada persona que quería que al día siguiente se hablara sobre algún tema, se levantaba, se ponía en el centro de la sala y exponía brevemente el tema. A mi, un poco acongojado por el nivelazo de la gente, me costó un poco decidirme, pero al final decidí alzarme y proponer la deuda tecnológica como tema a debatir. Es importante recalcar que la persona que propone la charla no tiene que ser un experto en el tema, simplemente tiene que tener ganas de debatir con otras personas sobre el mismo. Es más, hubo gente que propuso temas sobre los que no tenía ninguna idea ni experiencia y que querían hablar de ellos precisamente por esto, para empezar a conocerlos.

Una vez hubimos propuesto todos los temas que consideramos interesantes empezamos con las votaciones. Cada uno de nosotros tenia cinco votos a repartir entre las propuestas que quisiera, pudiendo repetir votos si lo consideraba necesario. Mi propuesta tubo unos muy honrosos cinco votos :D

Después de votar armamos la grilla ( como decían por Argentina ), es decir, establecimos el horario de cada una de las charlas. Es importante recalcar que todo esto lo hicimos los participantes, en ningún momento Alan o cualquier otro miembro de la organización participó activamente en esta organización. Así pues el resultado fue el que el público consideró más oportuno, tanto en temas a tratar, como en horarios. Se puede ser más ágil?

Cómo podéis ver mi charla quedó emplazada para las 9 de la mañana del día siguiente.

Y al día siguiente, después de un buen desayuno, empezaron las charlas. La charla empezaba con una breve intervención de la persona que la había propuesto explicando las razones por las cuales lo había hecho. Y después empezaba un diálogo entre todos los asistentes donde cada uno daba su punto de vista, explicaba su experiencia, donde estaba fallando, donde lo hacía bien, etc. Aquí os pongo un breve resumen de las charlas a las que yo fui.

Deuda Tecnológica

En esta charla discutimos por lo que entendíamos por deuda tecnológica. Llegamos a la conclusión que deuda tecnológica eran aquella deuda que se contrae cuando se decide hacer las cosas rápido para, por ejemplo, llegar a una entrega y que no cumplen con los estándares de calidad de nuestra organización, siendo susceptibles de impedir el futuro desarrollo de nuestro software. Ante esto se llegó a la conclusión de atacarla por distintos frentes:

Intentar evitarla.
Reportar al cliente cuando se contrae la deuda para que esté informado que algún día se tendrá que arreglar el estropicio.
Se hizo incapié en que ser ágil es un ejercicio de honestidad.
Capacitar al equipo para minimizar la deuda que se contrae por culpa de malas implementaciones.
Mostrar al cliente el valor de no tener deuda técnica.

Cómo evangelizar a mi equipo

Esta charla fue propuesta por Nico para tratar el tema de aquellos miembros del equipo que no quieren seguir algún paso de la metodología porque no lo consideran oportuno. Aquí cada uno explicó sus batallitas sobre el tema y propuso algunas soluciones, o acciones que quizá pudieran servir. Aquí van algunas:

Que el Scrum Master haga aquello que estos miembros no quieren hacer para que se den cuenta que es importante.
Cuando se detecta alguna barbaridad en el código, enviar un screenshot a todo el equipo.
Rotar los roles para que la gente vea que cuando no hace una cosa está molestando a un compañero.
Implementar un sistema de premios para cuando el equipo trabaja correctamente.

Trabajo ágil en entornos no ágiles

En esta charla se habló de cómo trabajar de una manera ágil en empresas que no lo son, ya sea porque tienen una forma caótica de trabajar o porque tienen una forma demasiado rígida de hacerlo. Ante esta dificultad se propusieron diferentes soluciones:

Internamente trabajar de forma ágil para cumplir los requerimientos no ágiles.
Adaptar el rol de Product Owner para que sea una especie de proxy entre la parte no ágil de la empresa y nuestro grupo de desarrollo.
Hablar con la gente no ágil con vocabulario no ágil ( fases, hitos, reunión de avance semanal, etc ).

Product Backlog

En esta charla hablamos de la creación y mantenimiento del Product Backlog. Aquí cada uno explicó cómo lo hacia él y qué problemas le surgían. Había desde la gente que hacía una mezcla de Scrum con Lean o con Kanban, a la que no mantenía un burndown chart ni estimaba las tareas, etc. Esta charla fue interesante porque tubo la participación de Xavier Quesada que aprovechó la ocasión para introducir temas de otra charla sobre visual management que al final no pudo dar.

Scrum distribuido

Y para finalizar estuvo esta charla, en que la gente que tenia experiencia implantando Scrum en grupos distribuidos nos contó sus experiencias. Aquí la tecnología tiene un papel importante a la hora de guardar y mostrar la información del avance del proyecto. Desde softwares comerciales, a hojas de excel compartidas, videoconferencias, llamadas telefónicas a altas horas de la madrugada, etc.

En definitiva fue una experiencia muy interesante. Cómo se comentó en la retrospectiva del evento, si alguna mente privilegiada del agilismo se hubiera puesto a pensar temas para una conferencia, seguramente no hubiera llegado al nivel que se llegó en este evento.

Una vez más, agradecer a la comunidad argentina el buen trato recibido y aprovecho para mandar un saludo a todos ellos. Un placer!

Definiendo historias de usuario en Scrum

2009-03-10T09:42:00.035+01:00

Uno de los puntos que más interrogantes provocan en la gente que se acerca a Scrum es cómo dividir el desarrollo de un proyecto en historias de usuario, es decir en tareas lo más pequeñas posibles que aporten valor funcional al cliente.

En este artículo voy a tratar de explicar el enfoque que yo adopto cuando trato de describir un requisito funcional cómo historia de usuario. Obviamente no es la única opción, ni la mejor, de echo es probable que esté pasando un montón de cosas por alto y que muchos se lleven las manos a la cabeza, pero creo que puede ser útil cómo primera aproximación para aquellas personas que no tengan del todo claro un procedimiento a seguir.

Vamos a tomar cómo ejemplo un problema de la asignatura de Especificación de Software de la Facultad de Informática de Barcelona (Enginyeria del Software: Especificació. Especificació de sistemes orientats a objectes amb la notació UML. EDICIONS UPC), que presenta el siguiente enunciado:

Se quiere desarrollar un sistema sencillo de control de préstamos en un a biblioteca. El sistema debe admitir el alta y la baja de socios y de libros. Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. Cuando llega a cero el socio se de de baja automáticamente.

Ahora supongamos que este problema nos lo ha planteado nuestro cliente, que quiere que le construyamos exactamente el sistema descrito en el enunciado ¿Cómo llegamos desde el mismo, a la lista de tareas del backlog? Por el momento vamos a obviar aquellas tareas que a simple vista no aportan valor al cliente pero que son del todo necesarias para el proyecto (definir e implementar la arquitectura del sistema por ejemplo) y vamos a centrarnos únicamente en los objetivos funcionales.

Lo que vamos a hacer va a ser un “clásico” análisis de requerimientos, intentando extraer del texto (lo que nos dice el cliente) las diferentes funcionalidades que debe tener el sistema. Para ello analizamos los párrafos del texto. A simple vista podemos extraer las siguientes funcionalidades:

De la siguiente frase: El sistema debe admitir el alta y la baja de socios y de libros extraemos las siguientes posibles historias de usuario:

Alta Libro
Baja Libro
Alta Socio
Baja Socio

Del párrafo siguiente: Los socios pueden pedir libros en préstamo, pero no se pueden tener mas de tres libros en préstamo en un momento determinado obtenemos una única funcionalidad o historia

Préstamo libro

En este párrafo: Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente creo que podrían identificarse dos historias (es mi opinión, quizás otra gente opine que sólo hay una posible historia)

Devolver libro
Penalizar socio

En el último párrafo obtenemos otra posible historia: Cuando llega a cero el socio se de de baja automáticamente. Aunque pueda parecer que es una historia repetida, yo considero que a nivel de valor al cliente es una funcionalidad diferente.

Baja automática de socio

Aparte de las historias que aparecen más o menos explícitas en el código, quizás podrían deducirse otras historias cómo:

Iniciar sesión en el sistema
Cerrar sesión
Alta usuario
Baja usuario

La lista completa de historias que tendríamos sería la siguiente:

Alta libro
Baja libro
Alta socio
Baja socio
Préstamo de libro
Devolver libro
Penalizar socio
Baja automática de socio
Iniciar sesión en el sistema
Cerrar sesión
Alta usuario
Baja usuario

Si estuviéramos en una metodología clásica de desarrollo, en este punto deberíamos hacer los casos de uso para los requerimientos identificados, sus diagramas de secuencia, etc. En una metodología cómo Scrum, por definición, no es necesaria esta documentación (queda a elección de cada uno decidir que documentación necesita su proyecto) y lo que nos quedaría por hacer es definir e introducir las historias en el backlog. ¿Y cómo se define una funcionalidad en forma de historia de usuario? Pues la idea es expresarla desde el punto de vista del cliente, o del usuario que va a usar el sistema, con un lenguaje que pueda ser entendido perfectamente por ellos (nada de UML, OCL o demás lenguajes de especificación) y que no cree ambigüedades. Por ejemplo:

Historia: Préstamo de libro
ID: 5
Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento.
Importancia: 300
Cómo probarlo:

Introducir un número de socio incorrecto y comprobar que se indica error
Introducir un socio que ya tiene 3 libros en préstamo y comprobar que se indica error
Introducir un libro del que no hay ejemplares y comprobar que se indica un error
Introducir todos los datos correctos y comprobar que el número de ejemplares disponibles del libro disminuye y el número de préstamos del socio aumenta en uno.

Cómo vemos, en Scrum se detalla de manera poco explícita la funcionalidad, únicamente se explica a nivel de cliente. La ventaja es que no se fijan los detalles de la implementación hasta el momento en que se va a realizar (en la descomposición en tareas) con lo que se puede reaccionar más ágilmente ante los cambios de los requisitos o de las necesidades del cliente.

Haciendo lo mismo con las demás funcionalidades, nos quedaría un product backlog similar al siguiente (se ha obviado la parte de test de las historias):

Historia	Importancia	Descripción
Alta libros	600	Dar de alta un libro en el sistema
Baja libros	250	Dar de baja un libro del sistema
Alta socio	500	Dar de alta un socio en el sistema
Baja socio	300	Dar de baja un socio del sistema
Pedir libro	350	Pedir prestado un libro
Devolver libro	340	Devolver un libro
Penalización socio	330	Penalizar al socio por retrasarse en la devolución
Baja automática	320	Dar de baja automáticamente de socio
Iniciar sesión en el sistema	550	Iniciar una sesión de usuario en el sistema
Cerrar sesión	500	Terminar sesión con el sistema
Alta usuario	450	Dar de alta un nuevo usuario en el sistema
Baja usuario	400	Dar de baja un usuario del sistema

En este punto tenemos identificadas todas las tareas funcionales del proyecto, y se ha descrito cada una de ellas cómo una historia de usuario.

Aunque ya tenemos completa la lista de funcionalidades, es obvio que el product backlog tal y como está no es suficiente para poder avanzar en el proyecto, ya que no aparecen todas aquellas tareas que no son funcionales (historias técnicas, requisitos no funcionales o como se le quieran llamar) pero que son necesarias para el desarrollo del proyecto. Pero la mayoría de estas tareas no aportan valor al cliente, entonces ¿Se deben incluir estas tareas en el backlog? ¿Y de que manera? No vamos a discutir en este artículo el tema, ya que daría para muchos posts, pero a modo de apunte se podría gestionar de la siguiente forma:

En proyectos que se están iniciando, es fácilmente justificable introducir tareas técnicas o no funcionales, ya que sin ellas el proyecto no existe. Así bajo la forma de Epics (o super historias de usuario) se podrían englobar tareas tales cómo Implementar la capa de datos, implementar la capa de comunicaciones, etc. Estas tareas se llevarían a cabo en las primeras iteraciones, o incluso en una primera iteración mayor que las otras.

En fases más avanzadas del proyecto, es difícil justificar tareas no funcionales, cómo la refactorización de módulos, instalación de servidores de pruebas, etc. Ya que el cliente querrá priorizar aquellas historias que le aporten valor. En este caso lo ideal es intentar que el cliente comprenda la importancia de las tareas a realizar, o si eso no es posible utilizar otras técnicas, cómo introducirlas dentro de alguna de las historias de usuario, o mantener una lista separada de historias técnicas con un porcentaje de tiempo no negociable con el dueño de producto.

Cómo hemos visto el proceso de definir historias de usuario es tan simple (o tan complicado) cómo realizar un análisis de requerimientos, proceso para el cual no hay ningún truco infalible y dependerá en gran medida de la experiencia y pericia del analista o analistas que se encarguen de él, y expresar las funcionalidades resultantes del análisis en un lenguaje que pueda ser fácilmente entendido por el cliente de nuestro proyecto.

Por si queréis ampliar información os dejo algunos links interesantes sobre Historias de Usuario i Scrum (o Agile en general). Esperamos vuestros comentarios!

http://en.wikipedia.org/wiki/User_story
http://www.userstories.com/
http://www.joelonsoftware.com/articles/fog0000000036.html
http://ezinearticles.com/?Scrum-User-Stories&id=1605892
http://scrummethodology.com/scrum-user-stories/
http://kanemar.com/2006/09/09/writing-user-stories/

Experiéncias implantando SCRUM

2009-02-12T12:30:00.004+01:00

En este artículo vamos a tratar de explicar nuestra experiéncia implantando Scrum y prácticas ágiles en general en nuestro proceso de desarrollo de software. Hemos divido el artículo en diferentes capítulos que explican cada una de las fases por las que hemos pasado. Esperemos que nuestra experiéncia os ayude de alguna manera. Nos gustaría remarcar que hablamos en nombre de todo el grupo de trabajo, que ha sido el que, trabajando todos unidos en una misma dirección, ha tirado adelante esta história.

ANÁLISIS

Después de un par de años trabajando en nuestra empresa, vimos que necesitábamos una manera mejor de trabajar. El equipo era demasiado especializado, cada persona tenía conocimiento sobre áreas muy concretas del sistema y esto penalizaba mucho las ausencias de algunas personas. Además a pesar de que al principio se trabajaba de manera relativamente tranquila poco a poco, a medida que los clientes aumentaban, la dinámica fue degenerando hasta convertir el trabajo diario en un “apaga fuegos”, solucionando bugs de anteriores versiones, dando asistencia, y intentado desarrollar nuevas funcionalidades en tiempo récord. Además existía una paralelización excesiva de las tareas (se empezaban muchas de golpe y pocas se acababan en un tiempo razonable ), los requisitos cambiaban con facilidad al igual que las prioridades y había poca comunicación entre el equipo, tanto de las tareas que realizaba cada uno cómo del conocimiento. Algo que si que teníamos era un seguimiento del trabajo exhaustivo por parte de nuestra responsable, que también estaba preocupada por mejorar nuestra manera de trabajar.

DESCUBRIMIENTO

Una vez que vimos que teníamos que buscar otra manera de trabajar, fuimos investigando por foros de internet, páginas web, experiéncias de conocidos hasta encontrar un documento que cambió completamente nuestra visión del desarrollo. El documento es el conocido “Scrum y XP desde las trincheras” y en él descubrimos conceptos tan importántes como Scrum, Integración Contínua o testeo unitário. Algunos de estos conceptos era nuevos para nosotros, otros ya los conocíamos pero no eramos conscientes del impacto que podían tener en nuestro día a día. El echo de conocer la experiéncia de gente que trabajaba en proyectos grandes e importantes y que consideraban esto vital, nos dio el empujón definitivo para emprender esta aventura.

PRIMEROS PASOS

Cuando tuvimos claro por donde tirar empezamos ha hacer una prueba piloto con un grupo reducido de personal, en concreto tres personas. Lo primero que hicimos fue montar un repositorio de código (con Subversion) y empezar a utilizar Scrum para nuestra organización interna, todo esto a espaldas de nuestros jefes. Antes de llenarle la cabeza con ideas “extrañas y novedosas” que pudieran provocar su rechazo creímos conveniente experimentar por nuestra cuenta un tiempo, para intentar mostrarles algo sólido, con técnicas ya probadas y con resultados que respaldaran nuestra idea.

Nuestros primeros pasos con Scrum consisitieron básicamente en aglutinar una serie de tareas (o historias) que teniamos en cola (¿product backlog?) , priorizarlas , realizar la división en subtareas , hacer una estimación (utilizando planning poker) y la realización de las reuniones diarias.

Aunque era todo muy “precario”, nuestra primera impresión con Scrum fue muy positiva. De tener a un equipo al que tan sólo se le controlaba la faena a intervalos relativamente grandes de tiempo, con la consiguiente tardanza en aplicar cambios de diseño o requerimientos y la lentitud en detectar errores, pasamos a tener un equipo que cada día compartía la información del trabajo realizado y al que era muy fácil orientar a resultados. Por otra parte, la utilización de un repositorio de código hacía que se eliminaran las tediosas sesiones de juntar versiones de diferentes programadores, ejercicio que era un generador de bugs terrible.

EXPANDIENDO LA SEMILLA

Una vez vimos que ibamos por la senda correcta, y que Scrum podia ayudarnos a mejorar nuestro trabajo, nos dispusimos a introducir el gusanillo de las metodologías ágiles al resto del grupo de desarrolladores, todavía a espaldas de nuestros responsables. No queríamos decirles nada hasta ver que esta técnica era válida para un grupo grande de personas, aunque nuestra responsable directa ya supiera algo de todo esto, pués es complicado esconder ciertas cosas. Cómo queríamos que el grupo se sintiera implicado en la toma de la decisión y no queríamos imponer nada, hicimos una presentación al grupo mostrándoles la manera de trabajar que teníamos ahora con nuestros diferentes gestores y a la vez explicando cómo contrapunto la gestión que se podría llevar a cabo con una metodología ágil (en concreto Scrum). Una vez acabada la presentación les preguntamos si creían que la manera actual de trabajar era una buena manera y, obviamente, la respuesta fue negativa; todo el mundo creía que se podían hacer las cosas mejor, que nuestra gestión del tiempo era deficitária y que el hecho que la toma de decisiones se centrara en nuestra responsable, que por su parte tenía un exceso de trabajo, hacía que el desarrollo se viera penalizado. Por suerte nuestra, esto coincidió con la decisión de nuestra responsable de delegar todo el trabajo que tenía que ver con desarrollo en nuestras manos, decisión que vino apoyada por el hecho que viera que teníamos capacidad para autoorganizarnos. Así que decidimos proponer al grupo un cambio en la manera de trabajar, básicamente centrandonos en dos aspectos:

Desarrollo: Les propusimos empezar a utilizar buenas prácticas de programación de manera conjunta y coordinada -> Instauranado el repositorio de código y enseñando cómo utilizarlo, creando una guía de estilo para homegenizar el código de todo el departamento, instaurando el testeo unitario, configurando un servidor de integración contínua, etc.
Gestión: Les propusimos instaurar Scrum como nuestra metodología de trabajo.

De esta manera empezamos nuestros primeros sprints. Al principio nos centramos en las reuniones de inicio de sprint, en los seguimientos diários y en pequeñas retrospectivas muy básicas. La reacción del grupo fue muy positiva y poco a poco empezamos con las demostraciones internas, aunque esto todavía tenemos que mejorarlo.

IMPULSO DEFINITIVO

El impulso definitivo ha sido la participación de nuestra jefa en todo el proceso de Scrum, principalmente en la reunión de inicio de sprint y en las demostraciones y retrospectivas. Esto ha sido muy importante para poder definir de manera más detallada las tareas a realizar, para la decisión de que entra y que no entra en cada sprint y, sobretodo, en que viera que somos un grupo que trabaja unido para obtener resultados. Ha sido también vital hacerle ver que la parelización de tareas es contraproducente y tan sólo lleva a tener muchas tareas sin acabar al final del sprint ( que es lo que nos pasaba en los primeros sprints ). Ahora todo el equipo se centra en una historia de usuario ( a lo sumo dos ) y a final de sprint siempre podemos mostrar un producto con incremento de valor sobre la iteración anterior.

IMPEDIMENTOS

Son muchos los impedimentos que nos hemos ido encontrado a lo largo de nuestra aventura, y seguramente nos encontraremos muchos más. Vamos a intentar exponer en forma de lista los que consideramos más importantes:

Dificultad a la hora de estimar: Aunque cada dia afinamos más, todavía nos falta un buen trecho para llegar a hacer buenas estimaciones de las histórias de usuario. Esto normalmente se vé reflejado en que conseguimos realizar menos histórias de las previstas. Afortunadamente, el hecho de que ultimamente el equipo se centre en menos histórias a la vez ha hecho que se minimice el impacto de este impedimento.

El equipo no sólo se dedica a programar. Nuestro equipo no es un equipo de desarrollo al 100%. También hace testeo, instalación en el cliente, resolución de incidencias, etc. Esto hace que nuestras estimaciones se vean penalizadas por una carga de trabajo no previsto que retrasa el desarrollo.

Incompresión por parte de otros gestores. La respuesta de nuestra jefa a nuestra propuesta ha sido espléndida, nos apoya al 100% e intenta colaborar en todo lo posible, pero no sólo trabajamos con ella. El hecho que haya en nuestra empresa gente con mentalidad tradicional respecto al desarrollo de software (o incluso sin ninguna mentalidad), hace que a veces choquemos frontalmente con su forma de dirigir los proyectos y que sea complicado realizar nuestro proceso productivo tal cómo nos gustaría.

Respeto a las iteraciones: En ocasiones no hemos podido llevar a cabo sprints completos, debido a “grandes marrones” que llevaban tiempo aparcados y que de golpe se deben solucionar, cambiando de un día para otro (a veces justo al dia siguiente de la reunión de inicio) todas las tareas programadas.

Grandes aprendizajes. Todos nosotros somos nuevos en el mundo de la gestión de proyectos informáticos y, aunque intentamos aplicar todas las técnicas de manera razonable y a pasos pequeños, hay muchas cosas que aprender, tanto técnicas ( a configurar un servidor de integración continua, a programar con testeo unitario, a relizar testeo funcional, etc ) como metodológicas. Por suerte, cada vez tenemos más experiéncia y vamos dando pasos más grandes y seguros.

Reticencia de algunos desarrolladores. Algunos desarrolladores veían algunas de estas técnicas como algo que disminuía su velocidad de trabajo, cosa que se veía reforzada por el hecho de trabajar con los gestores tradicionales que antes comentábamos. Aquí nuestra tarea “evangelizadora” ha sido importante, haciendo charlas, propiendo lecturas, analizando artículos, etc. Al final, hemos podido convencer a todo el mundo y esto se ha notado en el dia a dia.

Dificultad para realizar algunas prácticas: Aunque parezca increíble, practicas básicas de Scrum cómo poder estar sentado todo el equipo junto, o tener una sala con el panel de scrum donde poder realizar las reuniones diarias son “difíciles” de llevar a cabo en algunas empresas.

EL FUTURO

Creemos que el futuro que nos espera va a ser mucho mejor. Todavía tenemos muchas cosas que mejorar: demostraciones, retrospectivas, reuniones de incio… La preparación de las demostraciones nos llevan mucho tiempo (ganar experiéncia con nuestra herramienta de ALM nos ayudará mucho ) y tenemos poco tiempo para hacer buenas retrospectivas.

Esperamos también aumentar la visibilidad de nuestro proceso y hacerlo extensivo a toda nuestra sección, hacer más públicas nuestras demostraciones ( por ahora internas ), dar permiso a todo el mundo para que vean el avance de nuestro proyecto via web con los diferentes reportes ( tablero de scrum, burndown, tasa de resolución de bugs, etc ) e intentar impregnar al resto del departamento o incluso de la empresa de nuestra filosofía de trabajo.

También esperamos que nuestros desarrollos sean cada vez más estables gracias a la incorporación masiva del testeo unitario, la integración contínua, mejora en los procesos de testeo, etc. Esto hará que las interrupciones en el desarrollo por la irrupción de bugs también sea menor. El hecho de tener sistemas más estable también hará que podamos delegar trabajo de instalación y mantenimiento a otras secciones de nuestra empresa, ganando así tiempo para desarrollar más y mejor.

CONCLUSIONES

Cómo conclusión podemos decir que nuestra experiencia con las metodologías ágiles en general y con Scrum en particular está siendo muy positiva, tanto en el ámbito personal cómo en el profesional (mejora en el trabajo diario al disminuir los impedimentos, alineación con el cliente para alcanzar objetivos, focalización en incremento de valor…). También es importante tener claro que Scrum y las metodologías ágiles en general no son una bala de plata. Son metodologías que requieren de un esfuerzo “extra” a corto plazo por parte de todos los roles implicados en el desarrollo del proyecto (esfuerzo que es posible que algunas personas no estén dispuestas a pagar) y que requieren de un contexto apropiado para su buen funcionamiento (hay tipos de proyectos que difícilmente encajarían en Scrum). Cómo dice Rodrigo Corral en este artículo “nadie dijo que no exigiera un esfuerzo”.

Por nuestra parte os animamos de manera entusiasta a que hagáis el esfuerzo de conocer Scrum porque el esfuerzo vale realmente la pena.

Cómo interpretar un burndown chart

2008-12-09T15:29:00.008+01:00

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.

Insertando una ProgressBar en un DataGridView

2008-11-24T08:00:00.000+01:00

Después de unos cuantos posts orientados hacia el terreno de la metodologías y la gestión de proyectos, con este artículo vamos a volver al campo del desarrollo puro y duro.

El objetivo de este post es mostrar cómo poder insertar un control de tipo ProgressBar en una columna del control DataGridView. Este problema, a priori complicado de solucionar ya que el DataGridView no permite la inserción directa de controles en sus columnas, es relativamente sencillo de abordar si se comprende el modelo de objetos que utiliza el control DataGridView de .Net.

No vamos a entrar en detalle sobre el citado modelo de objetos, únicamente explicaremos que para poder crear nuevas columnas (cómo la nuestra de ProgressBar) necesitamos crear una nueva clase que represente el tipo de columna, y una nueva que represente el tipo de celdas que pertenecen a dicha columna. Para ello basta con crear clases que deriven de DataGridViewColumn (o una de sus clases hijas) y DataGridViewCell (o una de sus clases hijas)

Para crear una columna que permita añadir objetos ProgressBar vamos a crear una clase que derive de DataGridViewImageColumn (después veremos porque concretamente de esta y no de la clase base o de alguna de las otras subclases)

public class DataGridViewProgressColumn : DataGridViewImageColumn
{
public DataGridViewProgressColumn()
{
CellTemplate = new DataGridViewProgressCell();
}
}

En esta clase vemos que en el constructor se asigna una propiedad llamada CellTemplate. Esta propiedad se encarga de definir el tipo de celda que corresponde a la columna, de manera que cuando se tengan que crear nuevas celdas el DataGridView sepa cómo crearla. Cómo podemos ver se esta asignado a la propiedad una nueva instancia del tipo DataGridViewProgressCell, que es una clase que también tenemos que crear. Ahora vamos a ver cómo construir la clase que representará a nuestro nuevo tipo de celda:

class DataGridViewProgressCell : DataGridViewImageCell
{ }

Lo primero es derivar del tipo de celda correspondiente (DataGridViewImageCell, que es el tipo de celda que corresponde a la columna de la que habíamos derivado nuestra ProgressColumn)

Ahora vamos a explicar como funcionará esta clase para poder entender todo el código que va a ir dentro de ella:

La celda mostrará una barra de progreso (en el ejemplo la estándar de Windows, pero ya veréis que será muy fácil modificarla al gusto de cada uno) , que irá actualizándose en base al valor que nosotros le pasemos a la celda. Es decir nosotros asignaremos valores enteros entre 0 y 100 y la barra de progreso se irá actualizando. Parece lógico pero ya veréis que si no de deja claro ahora puede ser complicado entender el siguiente código:

Añadimos los siguientes constructores a la clase:

static Image emptyImage;

static DataGridViewProgressCell()
{
emptyImage = new Bitmap(1, 1, System.Drawing.Imaging.PixelFormat.Format32bppArgb);
}
public DataGridViewProgressCell()
{
this.ValueType = typeof(int);
}

En el constructor estático (o de clase) se inicializa una variable de tipo Image mientras que en el contructor público se indica el tipo de datos de la columna, que será un entero. Este valor será el que se utilizará para recoger el porcentaje que se debe mostrar en la barra de progreso y ahora veremos que utilidad tiene la imagen del cosntructor estático.

El siguiente paso es sobreescribir el método GetFormattedValue. Este método sirve para transformar el valor de entrada de la celda (que en este caso es un entero) en el objeto que espera el DataGridView, que al estar derivando de DataGridViewImageCell es una imagen (Ahora se entiende el porqué de la imagen del constructor estático)

protected override object GetFormattedValue(object value, int rowIndex, ref DataGridViewCellStyle cellStyle, TypeConverter valueTypeConverter, TypeConverter formattedValueTypeConverter,
DataGridViewDataErrorContexts context)
{
return emptyImage;
}

Cómo veis, en lugar de formatear el valor de entrada y devolver la imagen correspondiente que parecía la opción más lógica según lo expuesto arriba en este método devolvemos directamente la imagen vacía, ya que en nuestro caso no se va a utilizar este método para representar el valor del ProgressBar, pero se debe devolver una imagen por consistencia con el tipo de datos de la celda madre (DataGridViewImageCell).

Y finalmente vamos ver cómo tenemos que a sobreescribir el método Paint de la celda. En este método será donde representemos realmente el valor del progreso. Con esto completaremos la clase:

protected override void Paint(System.Drawing.Graphics g, System.Drawing.Rectangle clipBounds, System.Drawing.Rectangle cellBounds, int rowIndex, DataGridViewElementStates cellState, object value, object formattedValue, string errorText, DataGridViewCellStyle cellStyle, DataGridViewAdvancedBorderStyle advancedBorderStyle, DataGridViewPaintParts paintParts)
{
int progressVal;
if (value != null && value.GetType() == typeof(Int32))
progressVal = (int)value;
else
progressVal = 1;

float percentage = ((float)progressVal / 100.0f);

Brush backColorBrush = new SolidBrush(cellStyle.BackColor);

Brush foreColorBrush = new SolidBrush(cellStyle.ForeColor);

base.Paint(g, clipBounds, cellBounds, rowIndex, cellState, value, formattedValue, errorText, cellStyle, advancedBorderStyle, (paintParts & ~DataGridViewPaintParts.ContentForeground));

const int margin = 4;

ProgressBar pb = new ProgressBar();
pb.Height = cellBounds.Bottom - cellBounds.Top - (margin * 2);
pb.Width = cellBounds.Right - cellBounds.Left - (margin * 2);
pb.Value = progressVal;

Bitmap bmp = new Bitmap(pb.Width, pb.Height);

pb.DrawToBitmap(bmp, pb.ClientRectangle);

g.DrawImage(bmp, new Point(cellBounds.X + margin, cellBounds.Y + margin));
}

Lo que estamos haciendo aquí es que cada vez que se llama al evento Paint de la celda se actualiza el estado de la variable ProgressBar interna de la misma y se "pinta" el control dentro de la celda (mediante GDI). Ahora vemos cómo a partir de un entero de entrada tenemos el control ProgressBar en pantalla. El utilizar GDI para "pintar" el control aporta mucha flexibilidad ya que permite darle la apariencia que se quiera: Por ejemplo en lugar de utilizar un control ProgressBar interno y "ver su imagen" podríamos dibujar el resultado del progreso de la manera que mejor nos pareciera, con los colores que mas nos gustasen, con efectos, con texto, etc...

Ahora que ya tenemos las clases preparadas vamos a ver cómo utilizarlas en un DataGridView de manera que podamos visualizar el control en las diferentes filas que se añadan al mismo.

En el ejemplo vamos a suponer que creamos el DataGridView en tiempo de diseño (aunque se podría hacer en tiempo de ejecución). Lo primero es arrastrar el control DataGridView a nuestro formulario y visualizar la pantalla de propiedades del control.

Arrastramos el DataGridView al formulario

Pantalla de propiedades

En esta pantalla definimos las columnas que tendrá nuestro DataGridView. Pulsando el botón Add aparece una pantalla donde se indica entre otras cosas el tipo de la columna y aquí ya podemos ver que en la lista aparece un nuevo tipo, DataGridViewProgressBarColumn, que será el que seleccionaremos para la columna que tiene que mostrar la barra de progreso (Para que el nuevo tipo de columna aparezca hay que tener acceso al espacio de nombres donde hemos definido la clase desde el formulario).

Añadiendo la columna de progreso

Cuando hayamos añadido las columnas necesarias (en el ejemplo añadiremos únicamente dos) volvemos al formulario y creamos un objeto BindingSource arrastrándolo hacia el mismo. Con este objeto implementaremos el enlace entre los datos y el DataGridView.

En la pantalla deberíamos tener algo parecido a esto:

DataGridView con las dos columnas y el objeto BindingSource

El siguiente paso es crear un DataSet que será el que contenga los datos. Este DataSet podríamos extraerlo de una base de datos, de un servicio Web o de cualquier otro origen de datos, en nuestro ejemplo lo construiremos y lo llenaremos programáticamente.

private void InitializeDataSet()
{
//Creamos el DataSet y definimos las columnas.
customDataSet = new DataSet();
customDataSet.Tables.Add(new DataTable("TablaEjemplo"));
customDataSet.Tables["TablaEjemplo"].Columns.Add(new DataColumn("DSNombre", typeof(string)));
customDataSet.Tables["TablaEjemplo"].Columns.Add(new DataColumn("DSProgreso", typeof(int)));

DataRow row1 = customDataSet.Tables[0].NewRow();
row1["DSNombre"] = "Fila 1";
row1["DSProgreso"] = 25;
customDataSet.Tables[0].Rows.Add(row1);

DataRow row2 = customDataSet.Tables[0].NewRow();
row2["DSNombre"] = "Fila 2";
row2["DSProgreso"] = 35;
customDataSet.Tables[0].Rows.Add(row2);

//Ponemos a false el valor AutoGenerateColumns para utilizar las columnas definidas en vista de diseño
dataGridView1.AutoGenerateColumns = false;

//Enlazamos el Dataset con el DataGrid
bindingSource1.DataSource = customDataSet.Tables[0];
dataGridView1.DataSource = bindingSource1.DataSource;
}

Volvemos a la vista de diseño del Grid e indicamos la relación entre las columnas del DataGrid y las del DataSet (opción Columnas de las propiedades del control)

En la opción DataPropertyName de cada columna ponemos el nombre de la columna del DataSet que enlazaremos. Fijaros que son las columnas definidas en customDataSet

Si ahora ejecutamos el proyecto vemos que aparecen las dos filas creadas y que la barra de progreso de cada una corresponde a los valores dados a las columnas del DataSet. Si quisíeramos modificar ese valor sólo tendríamos que ir cambiando el valor de la celda DSProgreso del DataSet y automáticamente se vería reflejado en el Grid y en la barra de progreso.

Gracias al potente modelo de objetos que .Net define para el DataGridView podemos de manera similar al ejemplo mostrado definir columnas para hospedar casi cualquier tipo de control que necesitemos. En ocasiones habrá que derivar de la columna DataGridViewImageCell cómo en el ejemplo, pero podemos cualquiera de las otras clases base según la funcionalidad que necesitemos insertar en nuestra nueva columna.

Os esperamos con vuestras opiniones, sugerencias sobre el tema o críticas al artículo en los comentarios!

Un saludo!!