westartup es un evento que une a desempleados y emprendedores para impulsar ideas de negocio. El próximo evento se va a celebrar en Gijón, del 6 al 8 de mayo 2011.

¿En qué consiste el evento?

El evento consiste en desarrollar dos ideas de negocio, ver su viabilidad y hasta desarrollar prototipos del producto / servicio de la idea. Tanto si tu idea sale seleccionado como si no trabajarás en un equipo multidisciplinar, de forma ágil y aprendiendo constantemente. Apúntate, es una experiencia única.

¿Cuanto dura el evento?

El evento comienza el viernes 6 de mayo a las 16 horas y finaliza el domingo 8 de mayo con la cena de fin de westartup, dos días y medio intensos y llenos de experiencias que no te puedes perder.

¿Cómo es el proceso de Inscripción?

Se ha de mandar un correo electrónico a la dirección tuoportunidad@westartup.org para recibir las instrucciones para formalizar la inscripción

¿Es necesario presentar una idea de negocio para participar?

No, no hace falta. Los asistentes que no quieran presentar una propuesta son bienvenidos igualmente. Podrán participar en las votaciones de selección de ideas y luego trabajar en la idea que prefieran de las dos ganadoras.

¿Qué tiene además de novedoso este evento?

En este evento se va a aplicar Scrum (metodología ágil) para el desarrollo de las dos ideas de negocio, esto permite disponer ya de una primera beta del plan de empresa el sábado para posteriormente redefinirlo el domingo. Por tanto los asistentes se benefician además de la experiencia de trabajar en un entorno ágil con una metodología ágil.

El evento está organizado por la asociación ImpulsaTIC (formada por: Inxeniu Internet Media, Domótica Davinci, Gedpro, Iniciamedia y Cowork Asturias).

Tenéis más información en la página oficial westartup: http://www.westartup.org/

Por fín he terminado de leer Clean Code, el famoso libro de Robert C.Martin a.k.a. Uncle Bob, que algunos conoceréis por ser uno de los autores del manifiesto ágil. Después de haberme encontrado con innumerables referencias al libro – tanto en twitter, como en algunos blogs que sigo habitualmente (que ahora recuerde este de @kinisoftware y este de @jacegu) – me propuse leerlo como uno de los objetivos para este año.

Escribir código que funciona es una tarea relativamente sencilla. Lo difícil es escribir código que, con el tiempo, no se convierta en un “chorizo” imposible de ampliar y/o mantener, y que sea entendible por otros programadores. En Clean Code, Uncle Bob nos explica su visión del buen código: el código limpio.

Resumiendo mucho, un código limpio (y bueno según el autor):

• Incluye nombres significativos en variables, funciones, clases, etc.
• Incluye funciones con responsabilidades bien diferenciadas, los parámetros justos, un nivel de abstracción uniforme.
• No repite código.
• Está autodocumentado, por lo que no es necesario usar comentarios.
• Está bien diseñado. Por ejemplo, hace uso de interfaces en vez de implementaciones concretas.
• Tiene bien separado el manejo de errores para que esto no interfiera en la comprensión del código.
• Se integra bien con otras aplicaciones, manteniendo limpias las fronteras y transformando la información externa en objetos de nuestra aplicación.
• Está cubierto al 100% por una batería de tests que comprueban todos los posibles caminos de ejecución.
• Está dividido y organizado en clases de un tamaño justo con responsabilidades bien definidas.
• Separa claramente la construcción e inicialización del sistema de lo que es la ejecución en sí.
• Crece de una forma sostenible, es decir que la arquitectura evoluciona incrementalmente y el código no va degenerando sino todo lo contrario, con cada cambio es más “fino” y siempre cumple las 4 reglas de Kent Beck para escribir código limpio.

El libro está repleto de código escrito en Java. Hay 2 capítulos donde Uncle Bob explica las refactorizaciones de una clase de JUnit y la clase org.free.date.SerialDate. Estos ejemplos son muy educativos, aunque exigen bastante atención.

En general no es un libro “de piscina” ni “de váter”, sino que requiere bastante esfuerzo: reeler los ejemplos para entenderlos, subrayar y tomar notas, consultar referencias, etc.

Me ha gustado por que no sólo te explica cómo escribir si no que tiene bastantes referencias y conceptos como la Ley de Demetrio, Desarrollo guiado por pruebas (TDD) y las reglas F.I.R.S.T., Separation of Concerns, Single Responsability Principle (Principio de Responsabilidad Única), Open-Closed Principle, Inversion of Control y el patrón Depency Injection, Domain Specific Languajes, etc.

También ayuda a ver y compreder algunos patrones de diseño como Abstract Factory y Adapter (Wrapper).

El último capítulo incluye una referencia de “Smells and heuristics”, que son una ampliación de los Code Smells del libro de Refactoring de Martin Fowler y que sirve como muy buen resumen del resto del libro.

Sin duda, Clean Code puede marcar un antes y un después en tus capacidades de programación si lo estudias con dedicación.

Y cómo la práctica hace al maestro, ¡ahora toca practicar!

• Pass all tests.
• Clear, expressive & consistent.
• Duplicates no behavior or configuration.
• Minimal methods, classes, & modules

Cuya traducción al castellano vendría a ser:

• Estar bien cubierto y satisfacer las aserciones de una buena batería de tests unitarios.
• Expresar las ideas que nosotros como programadores queremos expresar (código auto-documentado).
• Decir cada cosa una única vez (DRY -> Don’t Repeat Yourself).
• Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro (You ain’t gonna Need it -> YagNi); y tener el mínimo número de clases y métodos (teniendo en cuenta el Principio de Responsabilidad Única).

Me he enterado de la existencia de estas reglas gracias al libro Clean Code, que llevo tiempo leyendo y que mucha gente considera de obligada lectura para cualquier desarrollador de software.

Una kata (programación) es un ejercicio de programación que pretende mejorar las cualidades de un programador mediante la práctica y resolución repetitiva de problemas.

Son ejercicios muy interesantes por dos razones: te obligan a encontrar una solución a un problema; y te permiten contrastar tu solución con las de otras personas, ayudandote a descubrir nuevas formas de afrontar dicho problema.

Generalmente se resuelven utilizando desarrollo dirigido por pruebas, es decir, escribiendo primero las pruebas y luego el código, y es interesante resolverlas programando en parejas.

La iniciativa #12meses12katas o #12months12katas

Hace un tiempo leí en twitter acerca de esta iniciativa, que consiste en resolver una kata cada mes. Si mucha gente se anima, al final de cada mes puedes contrastar tu solución con el resto y aprender mucho. Me gustó tanto que me lo marqué como objetivo para este año.

Fruto de esta idea, kinisoftware se ha lanzado y ha creado 12meses12katas.com, que en breve se convertirá en un punto de encuentro y lugar centralizado donde compartir los enunciados de las katas y las diversas soluciones.

La kata: String Calculator

La kata consiste en hacer una calculadora que recibe una cadena con un formato específico y realiza la suma de sus operandos. La mayor complicación radica en el parseo de la operación. Yo me decanté por utilizar expresiones regulares, y fue en la escritura de estas donde invertí más tiempo.

Mi solución

Mi solución está implementada con Ruby y RSpec. He de reconocer que he necesitado 3 intentos y que no estoy muy contento con la solución para el caso de diversos delimitadores.

De momento, he colgado la solución en mi cuenta de GitHub y también la incluyo a continuación.

Dado que el objetivo de este ejercicio es aprender, cualquier comentario/crítica/observación será muy bien recibido

Si eres desarrollador de software te animaría a que te sumases a la iniciativa.

En este video de 4:44, Ward explica la historia y motivaciones de esta metáfora.

Ward comenzó a utilizar esta métafora mientras desarrollaba una aplicación relacionada con las finanzas (por eso usó una anología financiera). La idea es que cuando implementas unas solución de una forma rápida, adquieres una deuda, igual que la deuda que obtienes con un banco cuando este te concede un préstamo. En el momento ganas en velocidad (tiempo), y si pagas la deuda rápido no habrá problemas. El problema ocurre cuando mantienes esa deuda técnica: mientras sigas endeudado, seguirás pagando intereses.

Hay muchas tareas en el desarrollo de software que pueden ser objeto de la deuda técnica, como: refactorizaciones del código de la aplicación para que sea más limpio y tenga un mejor diseño, documentación (como el Javadoc por ejemplo), implementación de los tests, etc.

Un proyecto donde sólo se desarrollan nuevas funcionalidades y se aumenta continuamente la deuda técnica es muy probable que fracase, debido a los intereses que hay que pagar: código que sólo los desarrolladores que comenzaron el proyecto son capaces de entender, código espagueti; mayores probabilidades de que los desarrolladores estés desmotivados y escriban peor código, etc.

Por eso, hay que tomar medidas para saldar periódicamente nuestra deuda técnica (en aquellos casos en que se haya producido). Por ejemplo: llevar un registro de esas tareas pendientes y reservar tiempo en el futuro próximo para llevarlas a cabo. Según Ward, la aplicación debería reflejar en todo momento la comprensión que los desarrolladores tienen sobre el problema.

En definitiva, y según mi experiencia, coincido con el contenido del vídeo: no es bueno dejar este tipo de cosas para mucho más tarde, porque en la mayoría de ocasiones “Later equals never”. ¿Cuántas veces, ante un código que funciona has pensado: “mañana lo reviso y lo refactorizo para que esté más limpio”; y, tiempo más tarde, ni siquera tú entendías lo que hace? Seguro que sabes de lo hablo. En estos casos, corremos el riesgo de caer en un “efecto bola de nieve” en el que cada día aumenta la entropía de la aplicación. Y es entonces cuando el proyecto tiene todas las papeletas para fracasar.

El propósito de este post es ayudarte a configurar una aplicación Ruby On Rails muy sencilla, con soporte para la definición de tests de aceptación de usuario con Cucumber. Son los pasos que yo he seguido para iniciarme en el mundo del BDD (desarrollo dirigido por comportamientos). El ejemplo consiste en la clásica aplicación Rails (versión 2.3.5) de gestión de Posts, generada usando Scaffolding.

He colgado la aplicación resultante en mi cuenta de GitHub: https://github.com/alonsogarciapablo/cucumber_rails_test.

Configuración previa

Antes de empezar, es necesario instalar las siguientes gemas:

Gherkin

Gherkin son dos cosas:

• El lenguaje que ha surgido a partir de Cucumber. Más concretamente es un DSL (lenguaje específico de dominio) que permite hacer BDD (desarrollo dirigido por comportamiento).
• La librería para parsear dicho lenguaje.

$ gem install gherkin

Cucumber y Cucumber para Rails

Como introducción a Cucumber, te recomiendo leer Cucumber Backgrounder, donde Aslak Hellesøy explica cómo se puede integrar Cucumber en una aplicación Rails, y la sintaxis para definir Features, Scenarios y Steps.

$ gem install cucumber-rails

Webrat

Webrat permite escribir tests de aceptación que simulan el comportamiento de un navegador web y de los usuarios en definitiva. Permite simular cosas como: ve a la página principal, rellena el campo nombre de usuario con “Pablo”, rellena el campo contraseña con “Alonso”, pincha en el botón “Login”.

$ gem install webrat

Database Cleaner

Database Cleaner define una serie de estrategias para limpiar una base de datos. Originalmente se pensó para garantizar un estado “limpio” entre la ejecución de los tests automáticos.

$ gem install database_cleaner

Aplicación de prueba

Creamos una aplicación Rails y la configuramos para que funcione con Cucumber

Creamos la aplicación Rails:

$ rails cucumber_rails_test
$ cd cucumber_rails_test

Generamos los ficheros necesarios para usar Cucumber con Webrat:

$ script/generate cucumber --webrat
      create  config/cucumber.yml
      create  config/environments/cucumber.rb
      create  script/cucumber
      exists  features/step_definitions
      create  features/step_definitions/web_steps.rb
      create  features/support
      create  features/support/paths.rb
      create  features/support/env.rb
      create  lib/tasks
      create  lib/tasks/cucumber.rake

Generamos una Feature

Generamos una feature con dos escenarios, uno para la creación y otro para el borrado de Posts:

$ script/generate feature post title:string body:text published:boolean
      exists  features/step_definitions
      create  features/manage_posts.feature
      create  features/step_definitions/post_steps.rb

Se deben haber creado automáticamente dos nuevos ficheros, un fichero con la definición de la funcionalidad de Gestión de posts (features/manage_posts.feature):

Feature: Manage posts
  In order to [goal]
  [stakeholder]
  wants [behaviour]
 
  Scenario: Register new post
    Given I am on the new post page
    When I fill in "Title" with "title 1"
    And I fill in "Body" with "body 1"
    And I uncheck "Published"
    And I press "Create"
    Then I should see "title 1"
    And I should see "body 1"
    And I should see "false"
 
  Scenario: Delete post
    Given the following posts:
      |title|body|published|
      |title 1|body 1|false|
      |title 2|body 2|true|
      |title 3|body 3|false|
      |title 4|body 4|true|
    When I delete the 3rd post
    Then I should see the following posts:
      |Title|Body|Published|
      |title 1|body 1|false|
      |title 2|body 2|true|
      |title 4|body 4|true|

, y otro fichero con la definición de los pasos (features/step_definitions/post_steps.rb):

Given /^the following posts:$/ do |posts|
  Post.create!(posts.hashes)
end
 
When /^I delete the (\d+)(?:st|nd|rd|th) post$/ do |pos|
  visit posts_path
  within("table tr:nth-child(#{pos.to_i+1})") do
    click_link "Destroy"
  end
end
 
Then /^I should see the following posts:$/ do |expected_posts_table|
  expected_posts_table.diff!(tableish('table tr', 'td,th'))
end

Ejecutamos los tests de aceptación

Como todavía no está implementada la funcionalidad, la ejecución de los dos escenarios falla. No existe todavía el modelo Post, ni la ruta asociada a la creación de un nuevo Post:

$ rake cucumber
(in /Users/paul/Proyectos/cucumber_rails_test)
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -I "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/lib:lib" "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/bin/cucumber"  --profile default
Using the default profile...
F-------F--
 
(::) failed steps (::)
 
undefined local variable or method `new_post_path' for #<Cucumber::Rails::World:0x8194fd00> (NameError)
./features/support/paths.rb:14:in `path_to'
./features/step_definitions/web_steps.rb:16:in `/^(?:|I )am on (.+)$/'
features/manage_posts.feature:7:in `Given I am on the new post page'
 
uninitialized constant Post (NameError)
./features/step_definitions/post_steps.rb:2:in `/^the following posts:$/'
features/manage_posts.feature:17:in `Given the following posts:'
 
Failing Scenarios:
cucumber features/manage_posts.feature:6 # Scenario: Register new post
cucumber features/manage_posts.feature:16 # Scenario: Delete post
 
2 scenarios (2 failed)
11 steps (2 failed, 9 skipped)
0m0.124s
rake aborted!

Generamos el scaffold del modelo Post y ejecutamos las migraciones pendientes

$ script/generate scaffold post title:string body:text published:boolean
$ rake db:migrate

Volvemos a lanzar las pruebas

$ rake cucumber
(in /Users/paul/Proyectos/cucumber_rails_test)
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -I "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/lib:lib" "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/bin/cucumber"  --profile default
Using the default profile...
...........
 
2 scenarios (2 passed)
11 steps (11 passed)
0m0.261s

Ahora sí que funcionan los tests y nuestra aplicación ya tiene una cobertura muy básica de tests de aceptación para la funcionalidad de gestión de posts, y los escenarios de creación y borrado. Ya tenemos listo nuestro entorno para empezar a desarrollar the-bdd-way ¿A que no era tan difícil?

Estas son mis notas y retrospectiva acerca de la Conferencia Agile Spain 2010, la primera conferencia de metodologias ágiles en España celebra en Madrid durante los días 10 y 11 de Junio.

Jueves 10 de Junio

Llegué bastante pronto en el cercanías a Vallecas. Pensé que sería de los primeros. En el camino, coincido con algunos de los chicos de Mobivery y me uno a ellos en la “ginkana” que nos llevaría hasta la zona de recogida de acreditaciones. Una vez allí, mucha gente ya esperando, algunos con camisetas amarillas moviéndose de un lado a otro a un ritmo frenético, ultimando los detalles.

Tras unos minutos deambulando por la sala y reconociendo el terreno en busca de alguna cara conocida me doy cuenta de que no conozco a nadie… ¿Cómo puede ser que ningún compañero de facultad esté por aquí? O ¿algún antiguo compañero de trabajo? Me doy cuenta de que he de ser ágil si quiero integrarme un poco.

Se abre la recogida de acreditaciones. En la fila oigo voces de latinoamericanos detrás mío. “Estos no son de Vallecas”, pienso… Nos presentamos. Se trata de Facundo, Fernando y Francisco, socios de la empresa 3F Soluciones Informáticas y recién llegados de Argentina. Desayunamos juntos y empiezo a conocer a algunos twitteros como Jorge Uriarte y Carmen Vidal.

Tras la presentación del evento por el parte del equipo organizador (Agustín Yagüe, Xavi Albadalejo, Juan Garbajosa), comienza la Keynote de Henrik Kniberg, titulada “The essence of Agile”. Henrik disfruta explicando e introduciendo todos esos términos que posteriormente se desarrollarían en sesiones y talleres (SCRUM, XP, Pair Programming, etc.)

Comienzan las sesiones y la gente comienza a desperdigarse…

Behavior Driven Development aplicado en Acceptance Test Automation (Christian Ramírez)

Llego a la sala y está repleta de gente. Mucha gente de pié y algunos en la puerta. Entro y decido sentarme en el suelo, practicando la postura del sastre con el portátil en las piernas.

Christian nos explicó el lenguaje que se utiliza a la hora de definir los tests de aceptación automáticos y que permite centrarse en el negocio. Se habla de las historias de usuario como herramienta para capturar los requisitos de un proyecto y describir las unidades mínimas de funcionalidad a implementar.

En la segunda parte, Christian nos explica dos herramientas concretas:

• Cucumber, que soporta más de 30 idiomas y está basado en el lenguaje Gherkin. Funciona con Ruby, Java, .NET, Python y otros.
• Twist. Herramienta de ThoughtWorks con un IDE propio.

Por último vimos un ejemplo de código de un proyecto real. Por problemas de la conexión con la wi-fi, Christian no pudo ejecutar la demo que traía preparada .

Enterprise Scrum – Scrum en la empresa (Xavier Quesada)

Salgo rápidamente a la siguiente sala. Resuelvo de nuevo la “ginkana” y llego a tiempo. Aula más grande y muchos sitios libres. Xavier comienza la charla de fórma ágil con un experimento. Nunca había asistido a algo así. Los asistentes propusimos y priorizamos los temas a tratar.

Empezamos hablando sobre las distintas condiciones que podían darse en una empresa referidas a la implantación de metodologías ágiles (apoyo de la gerencia o no, existencia de algún proyecto piloto,experiencia previa, etc). Me gustó el concepto de “Scrum de Guerrilla”, es decir, utilizar métodos ágiles sin que nadie lo sepa, ya sea a nivel individual (con prácticas como TDD) o a nivel de equipo. Si en tu empresa no te permiten hacer Pair Programming, tendrás que “Pair under the radar” .

Xavi recomienda contratar a un ScrumMaster al principio para guiar al equipo en algún proyecto piloto de pequeña envergadura y nos relata de forma muy amena algunas de sus experiencias pasadas y actuales en Bélgica.

Pasamos a hablar de Prácticas Técnicas que todo equipo ágil debe utilizar: Control de versiones (parece mentira pero hay gente que no lo usa), Integración Contínua que permita hacer despliegues automáticos y que incluya un ambiente de prubas, una cobertura mínima de Tests funcionales automatizados (por ejemplo con Selenium) y Tests de unidad.

El tiempo pasó rápido y hubo muchas preguntas en la sala, dando lugar a un interesante debate.

Comida

Quite hungry, I head towards the restaurant. I’m alone again. I don’t find any familiar face around. Fortunately, I realise that Erling Wegger Linde is the person behind me in the queue. I don’t have the oportunity to speak to a Thoughtworks‘s employee everyday, so I don’t doubt it and start talking to him. We ended up having lunch together and I had the oportunity to ask him about his company, about life in London and Norway, and about the industry of software development. I had a very good time. Thanks dude!

Pair Programming Strategies (Erling Wegger Linde)

Earling me abandona para terminar su presentación, y yo busco a los chicos de 3Fs para “platicar” un rato con ellos. Conozco a Joseba y a otro chico más de Bilbao y hablamos hasta que Jorge Uriarte nos avisa de que ya es la hora.

Me dirigo al taller de Pair Programming and when I arrive, the classroom it’s full again. I manage to find a chair and I sit at the back of the classroom. Beside me, Mike Scott sitting on the floor.

It was my first time to take part in an Open Space Session. After a short introduction by Erling, we proposed tracks to talk about, prioritize them and choose three of them. I participated in the “How to get started with Pair Programming” one, mostly because I have never practiced Pair Programming inside a company, and also because Henrik Kniberg was there and I felt like speaking in english. Henrik talked us about “Ping pong pair programming” which consists in one person writting a test and switching the keyboard to the other person so that he/she has to write the code to make the test pass. He proposed that the driver should program for 3 minutes and “slide” the keyboard to his partner. We also talked about things like visualizing the current story the programmers are working on, the needs of a special physical space to pair program, the pressure and necessary resting periods, etc.

Among my group, there were some members of Mobivery, a programmer from EA, Mike Scott, and more.

The rest of the groups talked about “Distributted Pair Programming” and another topic I don’t get to remember .

After a short presentation of each group’s results, Erling asked us to evaluate his session with some Post-its on the door (see the picture on top of this post).

I ended up with the convinction that Pair Programming can be really useful and its regular practice can reduce the number of bugs in the code. I’ll have to practice it from now on . Erling posted a summary of the discussions in his blog.

Integración Continua punta a punta (Xavier Quesada)

Continúo de nuevo in Spanish. Me quedo sin bajar al café para asegurarme un sitio en la siguiente charla. Volvemos con Xavier Quesada. La sala 4 abarrotada. Las personas que están fuera fuera del aula se quejan (con razón) y los organizadores deciden cambiarnos de sala. Nada grave, los agilistas recibimos con gusto los nuevos requisitos .

Xavi retoma la charla a toda pastilla y comenta las claves de la integración contínua:

• Usar un sistema de control de versiones (Git está de moda, pero SVN también vale lógicamente)
• Hacer varios commits al día.
• Llevar a cabo la integración contínua cada vez que se hace un commit. Remarca que este proceso no debería tardar más de 10 minutos.

Después comienza a dibujar en la pizarra su entorno de integración ideal, que incluye:

• Los desarrolladores con su PC y BD propia,
• Un ambiente de testing con una BD predecible, donde se ejecutan los tests de regresión y con posibilidad de refrescar los datos de prueba,
• Un ambiente demo donde se ejecutan los User Acceptance Tests y que, dada la fiabilidad del deploy en este punto, puede atacar a los datos de producción para ejecutar estos tests.
• Ambiente de producción.

Reconozco que me suena todo un poco a ciencia ficción y que nunca he trabajado en un entorno tan complejo (aunque me encantaría verlo funcionando). Ante la pregunta de “¿De donde sacamos tantos ordenadores en la empresa para montar esto?”, Xavi responde muy expontáneamente “¡Los robais!”. Risas mil en el público.

Prácticas de programación para hacer realidad la agilidad: Refactorización, IC y TDD (Alberto Pérez y Carmen Vidal)

La última charla del día, cortesía de Carmen Vidal y Alberto Pérez, de Paradigma Tecnológico(patrocinador de la conferencia). Carmen comienza nombrado los nombres de algunos twitteros como Israel Alcázar, Joaquín (A.K.A. Kinisoftware), y el mío propio, por sendos posts en los que publicamos que asistiríamos a su charla. Gracias a estos comentarios tuve la oportunidad de desvirtualizar a Israel y Joaquín .

La afluencia es masiva aunque se ven ya caras de cansancio (incluída la mía). Carmen y Alberto dieron un muy buen repaso a muchas de las técnicas propias del desarrollo ágil: testing, refactoring, propiedad colectiva del código, etc. La charla fue muy completa, aunque varias cosas ya habían sido explicadas (al menos en mi itinerario) en sesión anteriores. Me sirvió para descubrir una empresa en la que seguramente no me importaría trabajar .

Termina el Jueves y vuelvo a coincidir con Erling, con quien comparto el viaje de vuelta en metro. Seguimos charlando sobre las diferencias entre las ciudades europeas y llegamos a la conclusión que son todas bastante parecidas en general.

Viernes 11 de Junio

Llego bastante justito de tiempo al Panel. Interesante discusión con varias figuras claves en esto del agilismo. Preguntas y respuestas fluyen por el auditorio. Pregunto por twitter por qué no se está enseñando esto ya en la universidad. Alguien por detrás grita: “¡La universidad es Waterfall!”. Muchas risas. Juan Garbajosa contesta que lógicamente no es muy sencillo modificar un plan de estudios. Me quedo tranquilo al saber que gente como él y Agustín Yagüe están metidos en el equipo docente de la UPM.

Actualmente trabajo en la Universidad de Oviedo y estoy en un punto en que debo decidir si continuar mi carrera profesional por la rama de la Investigación. Me interesaba mucho la sesión de contribuciones para ver sobre qué se está investigando en estos temas pero… no podía irme de Agile Spain 2010 sin ver una sesión de Ángel Medinilla. Cambié ágilmente mis planes y decidí ir a ver la primera sesión de Ángel y la segunda parte de la sesión de Contribuciones…

Gestión Ágil de equipos (Ángel Medinilla)

Cómo Ángel ha colgado su presentación, la incrusto aquí porque creo que merece la pena verla. Ángel es un auténtico “showman” y consigue ganarse al público con sus experiencias y analogías. Habló de liderazgo, de motivación a los equipos de desarrollo, anti-patrones en la gestión de equipos, etc. En definitiva nos dió las claves para un correcta gestión de un equipo, sin estructuras verticales, eliminando la cultura del miedo, etc. He aquí su presentación:

Me gustó mucho el “Piensa en el peor jefe que hayas tenido y nunca hagas lo que te hizo a tus empleados. Piensa en el mejor jefe que hayas tenido y sé como él cada día con tus empleados”.

Contribuciones (2ª parte)

Me incorporo a la 2ª parte de la sesión de contribuciones. Muchos comentarios en twitter apuntaban a que estaba siendo un éxito. Se presentan algunos papers muy interesantes. Me gustaron especialmente KOWLAN: A Multi Agent System for Bayesian Diagnosis in Telecommunication Networks por mostrar un caso real de implantación de Scrum en una empresa de gran tamaño como Telefónica I+D (donde por cierto inicié mi carrera profesional) y Spanish vs European Agile Methods Adoption: Results of an Empirical Study, que compara la implantación de metologías ágiles en España y Europa.

En definitiva una fuente de inspiración para posibles artículos de investigación en estos temas. Al final de la sesión tuve la oportunidad de hacerme con un ejemplar de las “Actas de 1ª conferencia de Agile-Spain CAS 2010″ donde se incluyen todos los papers. Thanks!

Se nos echó el tiempo encima y salí a comer rápidamente junto con Facundo, Fernando y Jorge Uriarte.

Gestión ágil de requisitos – Construyendo nuestro backlog (Jose Luis Soria)

Pasamos a una de las charlas que más ganas tenía de ver para intentar solucionar muchas de mis dudas sobre las historias de usuario y el Product Backlock.

En esta charla, Jose Luis nos contó el formato de las historias de usuario y tests de aceptación. Una de mis dudas era cuando y en qué medida hay que detallar las historias de usuario. Según Jose Luis se debe:

• Detallar lo suficiente para poder empezar a trabajar.
• Detallar más las historias más importantes (que saldrán antes del Backlog).
• Esperar a que los detalles más concretos surjan y aborden durante el desarrollo.

Se habló de las características que debe cumplir una buena historia de usuario: INVEST.

Algunos consejos referentes a las historias de usuario:

• Dividir las historias hasta que proporcionen funcionalidad demostrable.
• Las historias deben estar basadas en objetivos del usuario.
• El aumento de detalles debe ser progresivo.
• No detallar demasiado las interfaces de usuario.
• Hay cosas que no son historias ()
• Especificar bien los roles de los usuarios.
• Tratar los requisitos no funcionales como restricciones de cada historia, en la parte de los tests de aceptación.

Posteriormente, Jose Luis habló un poco sobre las distintas formas de realizar las estimaciones, ya sea en forma de medidas absolutas (días, horas, etc) o de medidas relativas (tallas de camiseta, puntos de historia). Se discutieron las ventajas de cada sistema y tengo la sensación de que la gente se decantaba más por el sistema absoluto por ser más objetivo, robusto y coherente en el tiempo.

Por último Jose Luis nos introdujo algunos “bad smells” en proyectos ágiles:

• Historias de usuario demasiado pequeñas.
• Historias de usuario dependientes entre sí.
• Requisitos inventados por los usuarios.
• Historias de usuario con demasiados detalles.
• Historias dificilmente priorizables.
• Clientes que no se involucran en el proyecto.

Charla muy productiva para mí. Muchas dudas resueltas, aunque supongo que en la práctica no será todo tan bonito como aquí se pintó .

Integrando prácticas ágiles y de experiencia de usuario en Telefónica I+D (Mónica Izquierdo y Ana Mª de Alarcón)

La charla sobre la experiencia de Telefónica I+D me interesaba porque, como comenté anteriormente trabajé allí durante 6 meses durante mi último curso de carrera… y no recuerdo que la cosa fuese muy ágil por aquellos entonces . Me senté en una de los laterales de la sala para enchufar el portátil y poder seguir tomando notas.

Las ponentes comenzaron introduciendo la iniciativa “Agile Telefónica I+D” explicando como un grupo de personas tomaron la iniciativa y empezaron a investigar y evangelizar a los compañeros en temas de metodologías ágiles. Actualmente forman parte de un grupo dentro de TID destinado a asesorar en temas de métodos ágiles a sus propios compañeros.

Mónica y Ana explicaron 8 puntos clave para la implantación de metodologías ágiles:

• Equipo de UX, diseñadores y desarrolladores forman un único equipo.
• Un representante de UX forma parte del Product Owner Team.
• Realizan user insights para generar ideas o productos.
• Utilizan Personas como método guía para identificar las historias de usuario.
• Realizan un trabajo de conceptualización y diseño previo.
• Utilizan la técnica de Parallel Tracks para abordar el problema del diseño de interfaces: La historia de usuario se diseña en un sprint y se codifica en el siguiente.
• Prueban continuamente los incrementos con usuarios finales, y disponen de un entorno ficticio donde realizar estas pruebas.
• Realizan documentación de lo imprescindible, dando prioridad a la comunicación cara a cara.

Me gustó especialmente porque se hizo mucho hincapié en el tema de la Experiencia de Usuario, algo que yo considero sumamente importante para el éxito de un proyecto. Sin duda, se enfrentan un gran reto y un trabajo apasionante al mismo tiempo.

Testing de aceptación con Ruby (Luismi Cavallé y Sergio Gil)

La última sesión fue bastante intensa. Luismi Cavallé y Sergio Gil nos sorprendieron con una presentación muy bien preparada y algunos ejemplos en video. En la sala, algunos cracks como David Calavera y Fernando Guillén, a quienes me había presentado en un descanso.

Volvimos a repasar el formato de los tests de aceptación y escenarios en las historias de usuarios y Luismi nos mostró cómo estos pueden ser generados a partir de una descripción textual con Cucumber. Tendremos que probarlo.

Sergio nos explicó Capybara, un DSL que permite simular el comportamiento de un navegador en un lenguaje cercano a los usuarios. Entre otras acciones, es posible: visitar una página, pinchar enlaces, rellenar campos de texto, marcar checkboxes, comprobar que una página ha renderizado determinados elementos, etc. También explicó las características de algunos de los drivers:

• Rack Test (Viene por defecto)
• Selenium (De facto, depende de Java, el único que usa realmente el navegador)
• Celerity/Culerity (depende de Java)
• Envjs (Basado en SpiderMonkey)

Sergio presentó finalmente la herramienta que ellos utilizan, y que ha sido creada por el propio Luismi: steak, otro DSL para describir tests de aceptación en Ruby.

Por si no fuera poco, hicieron un repaso de más herramientas y técnicas: fixture replacement (en Ruby puro o con Factory Girl y similares), delorean (volver al pasado), database cleaner, email spec, webmock (simulación de peticiones http), y MundoPepino (Colección de pasos muy genéricos).

He de decir que al final quedé un poco abrumado con tantos “productos” diferentes y no sé si algún día tendré tiempo de probarlos todos, pero la sesión mereció la pena.

Conclusiones

Terminaron las sesiones y participé en la última parte de la Retrospectiva. En general casi no hubo comentarios negativos, sí algunos puntos en los que se podría mejorar.

Personalmente quedé muy satisfecho con el encuentro. Salvo las mínimas molestias ocasionadas en la sala 4, que quedó un poco pequeña en algunos casos, me pareció un precio muy razonable y 2 días me parece una duración adecuada (más tiempo habría sido mucho para participantes y organizadores). Aprendí mucho, aunque finalmente me quedé con ganas de apuntarme a algún taller para practicar un poco.

Lo más importante para mí, sin duda alguna, fue comprobar que cosas sobre las que llevo leyendo algunos meses son ya una realidad en España, y que hay una auténtica comunidad de personas muy motivadas que utilizan y promueven las metologías ágiles en España. Poder compartir un tiempo con ellos, es algo que no tiene precio .

Aprovecho para felicitar a la organización. ¡Nos vemos en la próxima!

Esta semana asistiré a la conferencia Agile Spain 2010. Muchas sesiones y talleres interesantes, tantas que ha sido difícil elegir a cuales asistir y renunciar a los talleres. Intentaré ir resumiendo en este blog cada una de las charlas a las que asista:

Jueves

• Behavior Driven Development aplicado en Acceptance Test Automation (Christian Ramírez)
• Enterprise Scrum – Scrum en la empresa (Xavier Quesada)
• Pair Programming Strategies (Erling Wegger Linde)
• Integración Continua punta a punta (Xavier Quesada)
• Prácticas de programación para hacer realidad la agilidad: Refactorización, IC y TDD (Alberto Pérez y Carmen Vidal)

Viernes

• Ser ágil en España, un caso real con equipos de trabajo en remoto (Enrique J. Amodeo y Antonio David Fernández)
• One year of software developments to win a world racing championship (Luca Minudel)
• Gestión ágil de requisitos – Construyendo nuestro backlog (Jose Luis Soria)
• Integrando prácticas ágiles y de experiencia de usuario en Telefónica I+D (Mónica Izquierdo y Ana Mª de Alarcón)
• Testing de aceptación con Ruby (Luismi Cavallé y Sergio Gil)

Además el sábado asistiré al workshop gratuito de JRuby impartido por David Calavera.

¡Nos vemos en Agile Spain 2010!

PD: Otros itinerarios de asistentes: Itinerario de kinisoftware, itinerario de Israel Alcázar…

Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.

Wikipedia