CAS2011: ¿Nos estamos mirando el ombligo?

Hola a todos, tras digerir un poco la experiencia CAS2011, saco dos conclusiones:

• Esta CAS2011 me ha gustado más que la del año pasado. Desde mi punto de vista la organización ha mejorado y ha habido más caras nuevas.
• Nos estamos mirando el ombligo.

Algunos sabréis que hace poco estuve en la ScrumGathering 2011, organizada por la ScrumAlliance en Londres. Cuando la gente se me presentaba, el diálogo resultante llevaba más o menos las siguientes líneas:

Agilista Internacional: ¿Ah, Español?

Agilista de pueblo (o sea, yo): Sí

AI: ¿Y allí hay agilistas también?

AP: Sí, claro, tenemos dos eventos importantes al año, la CAS y el AOS

AI: ¿Y va mucha gente?

AP: Sí, entre 150 y 250 personas a cada una

AI: ¡ Wow, es mucha gente ! Pero, …. ¡ no había oído hablar de estas conferencias en mi vida !»

AP: Claro, por que es todo en español

AI: WTF !

Iteremos sobre toda la gente con la que hablé y os hacéis una idea de lo quemado que me volví al pueblo. Pero eso no fue lo peor, lo peor fue que la mesa redonda de la CAS2011, ¡ fue en español ! El pobre J.B. Rainsberger tuvo que hablar en castellano, ¡ inaudito ! Seguro que @jbrains no vuelve a ninguna conferencia española…

Creo que ha llegado el momento de dar un paso adelante, sacudirnos los complejos y desencasquetarnos la boina de la cabeza. ¿Por qué no empezamos a montar la siguiente CAS pensando en que sea un evento internacional? Creo que eso tendrá al menos los siguientes beneficios:

• Variedad en los asistentes y en las propuestas.
• Proyección internacional de la comunidad española.
• Atraerá a más patrocinadores. Una CAS de 300 o 400 personas con ámbito internacional seguro que es más atractiva que una de 200 con proyección nacional.
• Networking. No es networking si siempre hablamos con la gente que conocemos (gracias por recordarme esto @david_bonilla). Si vienen personas de todo el mundo las oportunidades de networking aumentan.
• Cuando yo vaya a conferencias internacionales no tendré que escuchar más WTF y sufrir más miradas condescendientes 🙂

Por lo tanto yo propongo que orientemos el siguiente evento a un ámbito más amplio. La web y los folletos en inglés. Las sesiones impartidas en inglés. Los voluntarios ayudando en inglés. Nuestros pesos pesados promocionando a nivel internacional (@ecomba, @david_bonilla, @xquesada, @acyment …). Y cualquier acción que se os ocurra.

¿Y el precio? Pues no podemos seguir pensando en pagar 4 perras. Si queremos una conferencia como dios manda hay que pagar más dinero, ¿200 o 300 euros la early bird? Yo se de gente que se puede gastar 200 euros en un fin de semana de fiesta y después dicen que 200 euros es mucho dinero por un fin de semana de agilismo.

Os dejo con una reflexión, ¿qué es la CAS? ¿Un evento de agilismo organizado por españoles para españoles? ¿O un evento de agilismo organizado en España para el mundo entero? Vosotros decidís.

Read Full Post »

HTML5Party: Autoflagelación, o cosas que pasan cuando haces waterfall

Hola a todos, algunos sabréis que @etnassoft, @pasku1 y yo estuvimos en la HTML5Party de Madrid participando en una hackaton. La verdad es que me gustó mucho el evento y me divertí bastante, también tomé notas del «cómo se hizo» ya que me gustó mucho como la organizaron. Pero este post no es para hablar de lo bonita que fue la hackaton, sino para diseccionar el «fracaso» de nuestra aplicación. La verdad es que me gusta mucho diseccionar los fracasos, ya que es en este tipo de ejercicios donde más se aprende.

Algunos pensareis que las hackatones son situaciones especiales donde no se aplican las reglas normales del desarrollo de software. Como tenemos poco tiempo sólo puedes ponerte a codificar como pollo sin cabeza, echar jornadas maratonianas y beber mucho red bull… ¡ nada más lejos de la verdad ! Este tipo de concursos representan muy bien la mayoría de los proyectos que te vas a encontrar en el día a día normal. Veamos… tiempo y recursos insuficientes, lista de requisitos a todas luces excesiva, problemas de última hora, contratiempos, pánico y la sensación de no llegar a producción, o sea, ¡ el verdadero «mundo real» ! Por lo tanto si al participar en una hackaton dejas de lado la disciplina de trabajo, entonces es probable que en un proyecto de verdad también abandones la disciplina. Por eso, cuando me presenté me dije: «esto hay que hacerlo con TDD y entrega continua de valor a muerte» Je, je, que iluso. Veamos que pasó.

El primer día empezamos bien, nos reunimos y nos pusimos de acuerdo en la funcionalidad, hicimos una maqueta papel, y nos pusimos manos a la obra. El compañero @etnassoft decidió hacer una maqueta HTML y @pasku1 y yo nos pusimos a hacer BDD. Todo bien, ¿no? ¡ Mal ! Esa fue la raíz de todos los problemas. Si vas a hacer entrega continua de valor, no puedes dividirte en equipos de especialistas, todos tienen que trabajar en equipo para sacar lo más rápidamente posible cada historia de usuario. Lo que terminó ocurriendo, de forma inconsciente, es que la UI se desarrolló por completo, para todas las historias de usuario. Igualmente, el servidor se desarrolló por separado para todas las historias de usuario. Lo curioso de esto, es que fue un fenómeno totalmente subconsciente, fruto de separarnos «temporalmente». En el fragor de la batalla nos olvidamos de que teníamos que centrarnos en historias y no en capas. Cierto, cada capa se desarrolló por historias, pero no integramos hasta que estuvieron todas las historias hechas en cada componente, ¡demasiado tarde!

En un enfoque orientado a la entrega continua de valor, hubiéramos integrado la UI y el servidor por cada historia. Los problemas los hubiéramos detectado al principio, cuando es más fácil, al ser la aplicación pequeña, y encontrarnos más descansados. Además de ser más eficientes hubiéramos eliminado el factor pánico, al tener al menos algunas historias (las más importantes) listas para producción.

¿Hicimos TDD? ¡ Sí ! ¿De que sirvió? De poco. Nuestra capa de «negocio» quedó cubierta por bastantes tests, ¡ pero ninguna capa de negocio sirve sino está conectada a una UI ! Esto debe servir de lección a los que piensen que sólo con prácticas de ingeniería y usar tecnologías y frameworks puedes llegar al éxito de tu proyecto. Tus prácticas de ingeniería deben usarse en el contexto de unas buenas prácticas de gestión de proyectos, y viceversa. Todas las prácticas se apoyan e interactúan unas con otras y están pensadas para cubrir las debilidades de las demás.

Durante el transcurso de la hackaton ocurrieron los consabidos e inevitables imprevistos de todos los proyectos (lo dicho, igualito que el mundo real). A saber:

• Se cayó el github. ¡Nooooo!
• Twitter tuvo un bajón de rendimiento. Todas las peticiones tardaban al menos 30 seg. Eso hizo que nuestro ciclo de pruebas integradas fuera impracticable. Ayer probé y la respuesta era instantánea.
• Un espacio en una cadena de texto de una configuración nos estuvo fastidiando durante 4 horas hasta que nos dimos cuenta.
• Los drivers de node.js para MongoDB fueron un dolor.
• Heroku no quería arrancar…. (¿qué demonios le pasó a la nube ese fin de semana?)
• Un troll se coló por twitter y nos desconcertó bastante. Sí, es cierto, cosas que pasan.

¿Son estos imprevistos una excusa para no haber entregado la funcionalidad prevista? En absoluto, si hubiéramos hecho entrega continua y usado una «bala trazadora», nos hubiéramos dado cuenta al principio de los problemas con MongoDB y Twitter y hubiéramos hecho un workaround cuando aun estábamos a tiempo.

¿Cómo terminamos el proyecto? Al final nos encontramos con una UI muy bonita (menos mal que estaba @etnassoft) y un servidor sin fallos, pero sin integrar, sin ninguna funcionalidad en producción, cansados y a falta de 5 horas para entregar. En un esfuerzo final conseguimos integrar un 30% de las historias de usuario, pero no precisamente las más interesantes. Si lo hubiéramos hecho con el enfoque ágil, al final de la hackaton nos hubiéramos encontrado con la funcionalidad más interesantes en producción, y no hubiéramos sufrido tanto.

¡ También hicimos cosas bien ! TDD, ritmo sostenible, usar estándares, buen diseño y arquitectura, refactorizar (pero no tanto como hubiera querido), puestas en común, trabajo en equipo, buen ambiente… y por eso no puedo terminar el post sin hacer mención de honor a @pasku1 y @etnassoft. Ha sido un placer trabajar con los dos y una experiencia muy divertida e instructiva. ¡ La próxima ganamos fijo !

P.S. Al final ganamos el segundo premio, que no está nada mal (Pero es que soy un tío exigente)

P.S.S. Enhorabuena a los organizadores, ¡en especial a @VictorSanchez!

Read Full Post »