Nov 16 2010

Hasta el año que viene, Agile Open Spain

Categoría: Eventos, VideosJuan @ 11:18 pm

El pasado fin de semana en Barcelona se celebró el Agile Open Spain 2010 (o AOS2010).

Más de 150 personas se dieron cita para lograr un evento fantástico ya que todos y cada uno de los asistentes pusieron su granito de arena para que fuera todo un éxito. He aquí la belleza de los Open Spaces.

Ya que hay otros muchos resúmenes mejores que cualquiera que yo escribiera (para muestra un botón, y otro, y otro…), en lugar de hacer una entrada larga sobre lo qué pasó allí, voy a dejar un pequeño video resumen para que os hagáis una idea de cómo fue. Espero que os guste.

Se me olvidó lo más importante: dar las gracias a todos los asistentes y, en especial, a los organizadores y voluntarios que han puesto su tiempo libre en hacer realidad el AOS2010, ellos son:

  • Teresa Oliver
  • Amalia Hernández
  • Joao Gama
  • Jose Raya
  • Juan Antonio Sosa
  • Jaume Jornet
  • Vicenç Garcia

Gracias también a La Salle por ceder las instalaciones y a todos los patrocinadores (más info, aquí)

Etiquetas: , ,


Sep 01 2010

Agile Open Spain 2010

Categoría: EventosJuan @ 1:15 pm

Agile Open Spain 2010 Ya está aquí de nuevo el Agile Open Spain 2010, esta vez en Barcelona (campus de La Salle, C/ Quatre Camins, 30) el 12 y 13 de Noviembre de 2010 (en jornada de viernes tarde y  sábado completo).

¿Que qué es el Agile Open Spain?, es la segunda edición (mira aquí si quieres saber más sobre la primera edición) de un evento organizado por voluntarios dentro y fuera de Agile Spain que será en formato Open Space. ¿Qué significa esto?, que el programa lo haces tú.

Muy brevemente, en un Open Space los asistentes se auto-organizan proponiendo los temas y programando una serie de reuniones (viernes tarde) que van a tener lugar justo a continuación (todo el sábado). Las reuniones pueden tener lugar simultáneamente y los asistentes son libres de decidir a qué sesiones quieren asistir y de cambiar de reunión en cualquier momento.

Será una excelente oportunidad para aprender y compartir experiencias. ¡No os lo perdáis!

Etiquetas: , ,


Ago 21 2010

Getting to Yes

Categoría: LibrosJuan @ 7:11 pm

Son incontables las ocasiones en las que tener buGetting to Yesenas aptitudes de negociación puede ayudar a mejorar el resultado esperado: pedir un aumento de sueldo, facilitar determinados tipos de reuniones, vender una casa, vencer la resistencia al cambio, etc.

Getting to Yes. Negotiating Agreement Without Giving In” es un libro que trata sobre cómo negociaciar y qué actitudes tomar en estas situaciones. Es un libro muy sencillo de leer con multitud de ejemplos que ayudan a entender los conceptos y, sobre todo, a poner al lector en situación.

No es que el libro diga nada asombroso que no sepamos de antemano o que se salga del sentido común, sin embargo, lo que hace muy bien es poner todo este conocimiento e ideas en contexto y explicar las razones para actuar una manera u otra en distintos contextos y escenarios.

Me ha parecido un libro interesante y entretenido que, creo, puede ayudar a mejorar las aptitudes de negociación de todo aquel que lo lea.


Jun 13 2010

CAS2010. Todo un éxito

Categoría: Eventos, VideosJuan @ 9:52 pm

El pasado jueves y viernes se celebró la primera conferencia sobre prácticas y métodos ágiles en España, la CAS2010.

Como uno de los organizadores, estoy muy orgulloso de lo que hemos hecho y del resultado aunque haya habido errores y haya cosas que mejorar para próximas ediciones. Lo mejor, sin duda, los participantes que son quienes han hecho que la conferencia haya sido un éxito. En total se han superado los 250 participantes entre asistentes, ponenetes, patrocinadores, etc. Además, y muy a nuestro pesar, tuvimos que dejar cerca de 50 personas fuera por la limitación de las instalaciones.

Creo que hay que destacar el buen ambiente, la posibilidad de conocer a mucha gente, el buen nivel de la mayoría de las sesiones y talleres y el empujón que se ha dado a la comunidad y a las nuevas comunidades locales. Personalmente, me he perdido muchas de las sesiones a las que tenía intención de asistir debido a tareas organizativas (habilitar la wifi, impresos de última hora, indicaciones, etc.) como, por ejemplo, el juego de simulación de Teresa Oliver (Pragmatic) o la sesión “One year of software developments to win a world racing championshi” de Luca Minudel.

Sin embargo, poco a poco iremos poniendo videos de algunas sesiones (como la key note de Henrik Kniberg, la mesa redonda y algunas otras), las presentaciones, fotos y podcast para todos aquellos que, como yo, no han podido atender a las sesiones. Ahora mismo se están agregando a http://groups.google.es/group/agile-spain/web/agilespain2010 si queréis hechar un vistazo.

Muchas gracias de nuevo a todos los participantes y a los patrocinadores, sin ellos, la conferencia no hubiera sido posible.

Finalmente, como agradecimiento a todos los organizadores y voluntarios que han trabajado mucho en esto, han puesto mucho esfuerzo y tiempo de sus horas libres, dejo este video. Que lo disfrutéis.

Etiquetas: , ,


Mayo 12 2010

CAS2010 casi a punto

Categoría: EventosJuan @ 11:00 am

Conferencia Agile Spain 2010La CAS2010 ya está casi a punto.

Después de mucho esfuerzo y muchas horas, ya tenemos un gran programa, una buena selección de sesiones y de talleres, un excelente key note, Henrik Kniberg y una buena variedad de ponentes.

Si tenéis curiosidad de cómo se han elegido las sesiones y los talleres, aquí tenéis el proceso de selección. También podéis ver quién está detrás de todo esto: organizadores y voluntarios. Tanto los unos como los otros, en su tiempo libre, están intentando que esta conferencia sea todo un éxito y que los participantes, empresas, patrocinadores… deseen no perdérsela de nuevo el año que viene.

Como uno de los organizadores me siento orgulloso de lo que estamos haciendo, aunque, por supuesto, haya muchas cosas que mejorar (es la primera y estamos aprendiendo). Esperemos que todo siga igual que hasta ahora y tengamos una excelente conferencia. Para ello, lo más importante sois vosotros, los participantes.

Hace un par de días abrimos el sistema de inscripción dónde ya podéis comprar vuestra entrada a la conferencia y a los talleres (no incluidos en el precio de la conferencia). Hemos intentado poner el precio más bajo posible teniendo en cuenta todos los gastos y los patrocinadores que tenemos. La entrada, finalmente, son 95 ¤ e incluye el desayuno y la comida de los dos días más dos cafés cada día (uno por la mañana y otro por la tarde).

Sólo me queda dar las gracias a todos los patrocinadores de la conferencia a día de hoy (especialmente a nuestro patrocinador oro ATSistemas), sin ellos, esta conferencia no sería posible. Recordar también, si alguien está interesado, que:  ¡todavía podéis ser patrocinadores!

¡Espero veros a todos en la CAS2010! ¡No os la perdáis!

Etiquetas: , ,


Mar 11 2010

CAS2010

Categoría: EventosJuan @ 3:24 pm

Conferencia Agile Spain 2010La CAS2010, primera conferencia sobre métodos y prácticas ágiles en España, ya está en marcha

Será el 10 y 11 de junio en Madrid, exactamente en el Campus Sur de la U.P.M. en la E.U. Informática.

La gente de Agile Spain le estamos poniendo muchas ganas no sólo para que esto salga adelante, sino para que sea una conferencia de la que todo el mundo está orgulloso y con ganas de repetir en próximos años.

La conferencia contará con la presencia de Henrik Kniberg, autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además miembro de la junta directiva de la Agile Alliance, y uno de los máximos divulgadores internacionales en la aplicación práctica de las metodologías ágiles.

Ahora estamos en fase de recepción de sesiones, talleres, charlas, etc., ¡anímate y participa!

Etiquetas: , ,


Mar 11 2010

Reflexiones sobre los problemas del desarrollo orientado a pruebas

Categoría: Test UnitariosJuan @ 2:45 pm

Hace tiempo llegó a mis manos un enlace sobre TDD (si no recuerdo mal, en un comentario a alguna anotación del blog de JMB), dónde el autor explicaba los problemas de TDD y por qué, en su opinión, hacer TDD no merece la pena. Hoy voy a escribir un poco sobre esto y a dar mi punto de vista sobre TDD y sobre lo que el autor comenta sobre TDD.

El autor comienza exponiendo que no está demostrado por la comunidad científica que TDD aporte mejoras significativas en el desarrollo del software. Como ejemplo cita a un par de párrafos de Maria Siniaalto en su artículo Test-Driven Development: empirical body of evidence. De esos dos, me quedo con el siguiente:

The empirical evidence on the practical use of TDD and its impacts on software development are still quite limited.

[La evidencia empírica en el uso práctico de TDD y su impacto en el desarrollo del software esta, todavía, muy limitada]

Con este soporte, pasa a dar su opinión que defenderá en el resto del texto:

I mention this first because I’ve concluded that not only is TDD not useful for me but I don’t think it’s a generally useful technique

[Menciono esto primero porque he concluido que no sólo TDD no es útil para mi, sino que no creo que sea una técnica útil en general]

No hace mucho, en la lista de correo de TDD en español (en la cual os invito a participar si estáis interesados en este tema) hablamos de lo mismo debido a otro articulo diferente. Mi punto sigue siendo el mismo que en aquel entonces (de hecho, he reutilizado algunas frases). Un estudio para ver si TDD mejora o no la calidad, rendimiento, etc., tiene que tener muchísimas variables en cuenta. Se me ocurren tres escenarios:

  • Proyectos distintos (con y sin TDD), gente distinta. La comparación no es posible porque la gente es distinta, los proyectos son distintos, los equipos son distintos, los comportamientos son distintos, etc.
  • Mismos proyectos (con y sin TDD), misma gente. Si ponemos primero a gente en un proyecto sin hacer TDD y se estudia, y luego se repite el estudio con la misma gente haciendo TDD, tampoco es posible hacer una buena comparación porque los individuos ya tienen conocimiento y experiencia en el proyecto.
  • Proyectos distintos (con y sin TDD), misma gente. Igualmente habría muchas variables dentro de los proyectos que podr�an influir en el resultado del mismo (complejidad, asuntos personales, ambiente…).

Según lo veo yo, para hacer un estudio de estas características se necesitan un número suficientemente grande de gente y proyectos para que sea estadísticamente significativo (y eso es mucho dinero y mucho tiempo). No creo que vaya a pasar y por tanto siempre habrá unos artículos dónde salga que TDD es mejor y otros en los que se diga que TDD es peor ya que, como se ha dicho, hay muchos otros factores influyen en el resultado.

Lo importante para mi no es que haya artículos de investigación que “demuestren” las maravillas o la perdida de tiempo que supone hacer TDD. Lo que a mi me importa es lo que yo veo y siento cuando hago TDD y lo que, por mi experiencia, veo en equipos e individuos cuando hacen TDD. Personalmente, a mi me sirve para hacer mejor código, más claro y más testeable. Mi código es mejor, mi actitud es mejor, me obligo a pensar más en las pruebas, tengo más confianza en que lo que he hecho funciona y, además, disfruto haciéndolo.

En el artículo mencionado al principio, el autor dice que TDD no da confianza en que el código funcione. La explicación es que en TDD no se pueden añadir pruebas que no hagan fallar código:

TDD by itself cannot give you that confidence because it excludes the idea of adding tests which are expected to pass

[TDD por sí mismo no puede darte esa confianza porque excluye la idea de añadir pruebas que se espera que pasen]

Estoy completamente en desacuerdo. Es más, no estoy del todo seguro de que, incluso siendo purista, no se puedan añadir pruebas que no hagan fallar el código. Robert C. Martin (Uncle Bob) escribe en su artículo “Las tres reglas de TDD“, la siguiente regla número dos: “You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures“. Esta frase se puede interpretar como que una vez que has escrito una prueba que haga fallar el código, no esté permitido escribir ninguna otra prueba más, pero eso no tiene que significar que todas las pruebas que se escriban deban fallar en un principio. Es más, Kent Beck en su libro Test-Driven Development by example habla de sólo dos reglas fundamentales antes de presentar más:

  1. Write new code only if an automated test has failed [Escribe nuevo código sólo si una prueba automática ha fallado]
  2. Eliminate duplication [Elimina la duplicidad]

Ninguna de estas reglas supone una contradicción al escribir pruebas que pasen. Si lo miramos desde un punto de vista práctico, no hacemos más que asegurarnos de que ese caso pasa, ¿qué tienes esto de malo?, ¿por qué deberíamos borrarlo o no usarlo si pasa?, ¿por qué debería estar prohibido?. Cuando escribimos código para hacer pasar un test, escribimos el código más simple que podemos pensar para hacer pasar la prueba, sin embargo, esto no tiene por qué conllevar que ese “código mínimo” solamente hace pasar ese test específico. Algunas personas que hacen TDD dicen que lo que habría que hacer es “romper el código” artificialmente para ver cómo la prueba falla y después “arreglarlo” para verla pasar. En mi opinión esto es una pérdida de tiempo y ganas de hacer que una buena práctica parezca una religión. (Incluso el diagrama de flujo en la wikipedia, no ve contradicción en escribir una prueba que pase :-) )

El autor también habla de que TDD no considera el peor caso o casos límite. ¿Cómo?. Claro que no, esto es puramente dependiente del programador (igual que lo es si hacemos pruebas al final), de lo cuidadoso que sea con las pruebas y de cuanto piense en los casos que necesita. No obstante, hay una gran ventaja al hacer TDD y es que para que escribir el código tienes que escribir las pruebas antes y eso te garantiza, al menos, cierto número de casos (¿cuantos se garantizan al hacer pruebas al final?). Obviamente, hay que pensar y esforzarse, eso no viene gratis por el hecho de TDD. Sin embargo, en mi experiencia es más fácil olvidarse de un test cuando ya tienes el código escrito que cuando todavía está por escribir y tienes que pensar en casos y comportamientos. Habla también del rendimiento y de cómo TDD no se centra en ello. Estoy de acuerdo en que TDD no es la mejor aproximación a la programación de algoritmos pero eso no quita para que no se pueda hacer. Igual que se hacen otro tipos de pruebas, se pueden añadir pruebas de rendimiento y mejorarlo en la fase de refactorización sin cambiar el comportamiento. ¡Para eso tenemos las pruebas!

Hay algunas cosas más de las que habla el autor, pero estas eran para mi las más importantes y en las que me quería enfocar y rebatir. Hay una idea que sí que nunca había oído antes que me ha llamado mucho la atención y en la que creo que merece la pena reflexionar:

If I write the tests first, I also worry that I’ve overfit my code to the tests. This is a problem that happens in statistical modelling. Given any set of data points, I can fit them to a model. The next question is, is the model valid and useful? The way to check is to use them to make predictions, and see how well it matches reality. This in turn means testing the model with data which wasn’t used to make the model.

[Si escribo pruebas primero, también me preocupo de que he me he pasado dando forma al código con las pruebas. Este es un problema que ocurre en modelos estadísticos. Dado cualquier conjunto de puntos de datos, puedo encontrar un modelo que le corresponda. La siguiente pregunta es, ¿es el modelo válido y útil?. La manera de verificar esto es usar el modelo para hacer predicciones y ver cómo de bien refleja la realidad. Esto significar probar el modelo con datos que no han sido usado para crear el modelo]

En principio, esa es una de las grandes ventajas de TDD, el modelado del código mediante las pruebas, pero, ¿es posible que debido a las pruebas estemos haciendo un modelo que se ajuste a las pruebas pero no al comportamiento general? Es posible y realmente merece la pena mirar los modelos estadísticos para entenderlo un poco mejor (lo tengo pendiente ya que la estadística la tengo muy olvidada) (supongo que este es el problema de hacer modelos de dominios infinitos con un número finito de datos). Sin embargo, creo que es obvio que TDD no es la panacea y que si usamos TDD todavía necesitamos usar otras prácticas. El código, después de todo, debe ser sujeto a pruebas de sistema, de estrés, de rendimiento, de exploración que, por otro lado, están fuera del modelo bajo el cual se ha escrito el código.

Como resumen, decir que creo que es estúpido el tratar a TDD como una religión. Pero es igualmente estúpido el tratar de ser “anti-TDD” como religión. No creo que es lógico decir que TDD es la solución a todos mis problemas, al igual que no es lógico decir “TDD es una práctica que no sirve para nada si usas otras prácticas”. Esto no llega a ningún lado y el contexto influye en las prácticas que hay que tomar y cuando utilizar una u otra. En mi experiencia, he visto gente y equipos que han mejorado mucho (sobre todo en número de errores bugs) al empezar a hacer TDD mientras que otros han hecho el mismo código malo con el añadido de que un montón de pruebas horribles. También he visto equipos con gente muy metida en tests (haciéndolos después del código) que al tomar TDD en práctica no han notado mejoría en número de bugs o en rendimiento. Al final, lo más importante es tener buena gente en el equipo que tengan actitud profesional, buenas aptitudes y ganas de mejorar.

P.D.: Dejo algunos enlaces muy interesantes que he estado leyendo últimamente sobre TDD y algoritmos.

http://www.infoq.com/news/2007/05/tdd-sudoku

http://www.reddit.com/r/programming/comments/9sdcm/tdd_sudoku_i_took_a_stab_at_it_see_inside_part_1/

http://norvig.com/sudoku.html

Etiquetas:


Feb 02 2010

Kanban vs. Scrum - Obteniendo lo mejor de ambos

Categoría: ManualesJuan @ 3:34 pm

Una nueva traducción de Agile Spain coordinada por Ángel Medinilla quién ya tradujo el libro anterior de Kniberg y Skarin, “Scrum y XP desde las trincheras“.

Ángel resume muy bien en su anotación el libro y el por qué de esta y anteriores traducciones así que no voy a añadir ni una palabra más.

Nada más que felicitar a todos los que han tomado parte en este proyecto: Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano. Felicitaciones también, cómo no, a Ángel Medinilla.

Aquí tenéis el enlace directo al libro en español.

Lo añado también a la página de Más Información.

Etiquetas: , ,


Feb 01 2010

Juego del Valor de Negocio

Categoría: Manuales, OtrosJuan @ 4:43 pm

Uno de las objetivos que tenemos en Agile Spain es crear y traducir contenido sobre las metodologías ágiles en Español.

Por este motivo, he traducido el Juego del Valor de Negocio creado por Veera Peeters y Pascal Van Cauwenberghe, el cual es un juego de simulación sobre prioridades de funcionalidades e historias de usuario así cómo su valor de negocio. Este juego se ha jugado varias veces en diferentes conferencias como la XP o Scan Agile con muy buenos comentarios sobre él.

Podéis encontrar el juego en aquí (pagina en inglés) o bajarlo directamente desde éste enlace directo. Espero que lo encontréis de utilidad y también, cómo no, que os divirtáis y aprendáis jugando.

Muchísimas gracias a Leo Antolí (también de Agile Spain) y Thomas Wallet (de Pragma Consultores) por la revisión de la traducción y todas sus correcciones y comentarios.

Etiquetas: , ,


Ene 13 2010

Manifiesto de Usuario

Categoría: PrincipiosJuan @ 4:18 pm

Hoy me he encontrado con una página del señor Alistair Cockburn (autor de “Crystal Clear” o “Writing Effective Use Cases” entre otros) dónde se discute una extensión del “Manifiesto Ágil” para mostrar la visión del usuario, lo cual me parece una gran idea.

El manifesto que está ahora mismo bajo discusión (puedes dar tu verisión u opinión en la página -en inglés-) dice más o menos lo siguiente (hay cuatro versiónes que se diferencian en cómo están escritas, no en las ideas, así que traduzco, malamente, sólo la primera):

Queremos equipos de producto que entreguen productos
… que no sólo “funcionen” o concuerden con una lista, sino que resuelvan mis problemas,
… que no sólo encajen con mis necesidades de momento, sino que evolucionen con mis necesidades,
… que no funcionen de la forma que los diseñadores piensan que deberían funcionar, sino que funcionen de la manera que yo trabajo,
… que no sólo los vea como herramientas, sino que lleven a cabo el trabajo que hago,
… que no sólo los use, sino que disfrute usándolos.

Bastante razonables aunque no veo la última del todo. No creo que en muchos casos un usuario quiera “disfrutar” con el producto. Estaría muy bien, claro que sí, pero dudo que sea la palabra correcta para alguien que usa una aplicación durante todo el día para calcular lo que sea, por ejemplo. Yo me decantaría por algo como “sino que sean fáciles de usar”, “sino que hagan mi vida más fácil”, “sino que hagan mi trabajo más placentero”… algo así.

¿Qué pensáis vosotros que debería contener el manifesto?

Nota: No tengo muy claro cual es la traducción correcta de “see through to the work I’m getting done”. Lo he traducido como “llevar a cabo el trabajo que hago” pero quizá debería ser “ayudarme con el trabajo que hago” o alguna otra cosa.

Etiquetas:


Página siguiente »