Posts tagged talks

This year, we had three of our team members attending the Barcelona Ruby Conference in Spain. Here’s what they found most interesting!

• BARUCO 2015

Esta pasada semana tuve la oportunidad de participar junto con la gente de Salumedia en una muy buena sesión de formación sobre la gestión de equipos y proyectos desde el punto de vista del Scrum Master, impartida por José Ignacio Ortiz de Galisteo.

Fue una sesión muy abierta y dinámica, en la que los que ya habíamos trabajado con Scrum alguna vez pudimos hablar de nuestra experiencia y hacer ver mejor a los “no iniciados” cómo se hacen algunas cosas, mientras que estos últimos pudieron preguntar todas sus dudas (e insistir en algunas de ellas) sin límite. Incluso se consiguió no lanzar la “alerta de trauma” ni una sola vez :)

Durante la sesión, y posteriormente, reflexionando y recordando el ciclo “Lunes ágiles” sobre agilismo que David JGurú, Javier Baena y yo dimos en la Universidad de Sevilla a finales de mayo, y en el que precisamente yo cubrí el rol de Scrum Master, me he dado cuenta de que al introducir Scrum a un equipo nuevo siempre acaban apareciendo los mismos lugares comunes.

La ¿panacea? de la estimación en equipo:

Pese a parece algo liosa en principio (¿planning poker? ¿sucesión de Fibonacci?), es bien recibida. La gente está muy cansada de estimaciones irreales que llegan desde arriba, hechas por gente que generalmente ha oído campanas sobre el desarrollo, pero realmente no sabe dónde. Por tanto, es normal que esta forma de “empoderar” al equipo de desarrollo ilusione tanto. Pese a todo, este tipo de estimaciones tienen riesgos y dificultades, a saber

- La sobreestimación y la subestimación. Mientras que la primera puede ser fruto de la inexperiencia (o de un realismo extremo) y las sucesivas iteraciones deberían ir eliminando esta práctica, lo segundo creo que suele venir por influencias externas (“no se puede tardar tanto en tener esto”) y puede ser altamente tóxica para el equipo. Es algo a evitar SIEMPRE. Una estimación bajo presión que acabe con mucha “subestimación” acabará pasando factura anímica (porque el trabajo es el que es y se tarde lo que se tiene que tardar), por no hablar de que malvender las horas de trabajo es nocivo para el negocio de por sí.

- Compromiso versus contrato. El equipo se tomará las estimaciones como el compromiso que asumen: “en tanto tiempo tendremos tantas cosas”. El problema llega cuando desde el PO/cliente se entiende que una estimación es algo absoluto y escrito en piedra, y que jamás se va a tardar más de lo que se dice porque nunca va a haber imprevistos. Ahi es cuando entra el dolor. Se ha de comprender que hay cosas que hasta que no se está hasta las rodillas en la faena, no aparecen.

- La obsesión con las horas. Esto suele darse entre la gente de las capas “de gestión” que llegan de nuevas. El concepto de puntos de esfuerzo les parece demasiado abstracto, no hacen más que preguntar por la equivalencia en horas. Lo importante es aprender qué implican y significan (y no “cuanto”) para tu equipo tres, cinco, ocho puntos de esfuerzo, y la conversión a horas vendrá sola, gracias al proceso subyacente de auto-conocimiento del equipo que conlleva el adoptar scrum.

Como hacer todo esto de cara al cliente

Esto es más de cara a un PO/comercial que un SM. Por esto es recomendable enlazar aquí la parte que dió David al respecto en el ciclo de agilismo.

Suele ser habitual el “¿como le vendo al cliente esto si no le puedo decir que van a ser 2 meses, tres semanas y cuatro dias JUSTOS de desarrollo?”, “¿como les hablo de sprints? ¿de que en dos semanas van a tener algo que se va a ir transformando en lo que quieren?”, “¿como hago para que cada sprint suponga aumentar el valor del producto, en lugar de pivotar completamente porque el cliente no tiene claro lo que quiere?”.

Todo esto es bastante complicado, concedido, porque requiere en mayor o menor medida reeducar al cliente. Esto es más labor de un PO/comercial si este pertenece a tu organización, en lugar de a la del cliente. Tendréis que aprender a vender proyectos de otra forma (juntos, el PO es parte del equipo, más que un comercial al que solo se le ve de higos a brevas por la ofi y con una bolsa cargadita de marrones). Aprovechad el factor iterativo y el de “más resultados, más pronto”, e involucrad al cliente más en el proceso. Abandonad la mentalidad de “desarrollos caja negra”, y trabajad más codo con codo con el cliente a base de implicarle.

Si toda vuestra organización va a ser ágil, pero vuestros clientes no van a cambiar con vosotros, aquí sólo va a haber DOLOR. Llegará ese momento en el que habrá que decir “no somos los desarrolladores que buscas”. Y sí, perder un cliente es doloroso, pero más doloroso es tener a un equipo encabronado en un ambiente tóxico, un cliente encabronado, y estar tú en medio.

Y si el PO que tenéis es del lado del cliente, y no entiende esto, entonces necesitáis quitaros a esa persona de encima, porque no ha entendido nada de nada.

Conclusión

En definitiva, adoptar Scrum no es cosa de un día. Requiere un aprendizaje, un sacrificio y tiempo de adaptación para todos los roles implicados. Son necesarios paciencia, comprensión y apertura mental.

Pero merece la pena. Porque implica una cultura organizacional diferente. Porque da poder al equipo de desarrollo, y porque nos reeduca a todos, poniéndonos en el sagrado camino de ser felices mientras trabajamos (que al final es lo más importante).

Y porque bueno, cuando lo echas a andar, Scrum funciona y todo.

Hace poco tuve el placer de impartir junto a mis amigos y “camaradas del metal” David “JGurú” Rodríguez y Javier “Javo” Baena, con los que formo el tridente denominado “Bonobo Squad” unas charlas sobre agilismo y Scrum en la Escuela de Ingeniería Informática de Sevilla.

Dividimos la charla en tres partes:

• El papel del Product Owner - David JGurú
• El papel del Scrum Master - Julio Antequera
• Caso de éxito de aplicacion de agilismo y Scrum: SocialBro - Javier Baena

La presentación completa está disponible en speakerdeck.

Disfrutadla.

DISCLAIMER: being a post about a local event, I’ve decided to write it in Spanish. This should help me to finish it fast and publish it while the impressions from the event are still fresh in our heads. If you still want an English version, help yourself with the Google Translation apps.

Este fin de semana acudí a mi primer sarao profesional, el #OpenSpaceSevilla. Lo primero, como debe ser siempre, es agradecer el esfuerzo, dedicación y atención a los organizadores. No faltó de nada, y gracias a ellos y a los asistentes hubo muy buen ambiente en todo momento :)

Web Security por Pedro Laguna

Pese a lo improvisado, es un tema que nunca falla. Siempre hay anéctodas, prácticas y discusiones que salen a la palestra, en especial sobre la valoración que hace el cliente sobre ésto. ¿Debe la seguridad ser un valor añadido, o una core feature del software/servicio que ofrecemos? Personalmente soy más partidario de la segunda opción: la seguridad debe estar ahí, la pida el cliente o no. Esto puede requerirnos más esfuerzo como desarrolladores, o jugárnosla al ser más caros, pero creo que usando buenas metodologías y frameworks de desarrollo el impacto no debería ser tan dramático.

Hablando de frameworks, se hizo hincapié en una cuestión interesante: ¿confiamos demasiado en los frameworks que usamos? ¿los auditamos? ¿o es mejor encargarnos de todo nosotros mismos? Creo que para sustentar mi opinión en el apartado anterior, es obvio que soy partidario de delegar en los frameworks que usamos. La comunidad de usuarios y/o desarrolladores se encargará de mantener seguro el framework, simplemente es cuestión de estar al día de versiones y parches (esto ultimo es muy importante, y no siempre se sigue).

Aplicaciones tipo revista para iOS y Android por Javier Alonso

Bastante interesante por la relativa facilidad para crear este tipo de aplicaciones, me ha dado una idea para algún proyecto personal :) En cuanto a lo negativo: lo de Android era más un “reclamo publicitario” que otra cosa :P

También me gustaría comentar que se preguntó sobre como subir aplicaciones al Market de Apple desde un “Hackintosh”, y la verdad, me parece un absurdo. Si quieres jugar a ser dev de iOS porque mola Apple, sigues las reglas de Apple, pasas por el aro, pagas y te quitas de tonterías. Ah, ¿que es caro? Pues desarrolla para Android. Analogía: si quieres ser guay y moderno y fardar de zapatillas Converse, te compras unas puñeteras Converse originales. Si no te quieres gastar la pasta, te compras la Beppi de imitación cutres de la tienda de tu barrio, PERO NO LES VAYAS A PEGAR EL ICONO DE LAS CONVERSE, MIARMA, NO ME SEAS UN CUTRE.

Garajes en Andalucía, propuesta por José Manuel Beas

Esta charla comenzó muy muy bien, con muy buenas ideas y una muy buena dirección, hasta que fué acaparada por uno de los asistentes y desviada de la dirección original hacia un lamento continuo, un lloro y un solo ver lo negativo. No se consiguieron abordar ideas como la madurez del mercado en la región (se impuso la idea de que hay que irse a buscar el cliente en otro sitio, aun estando situados aquí), ni, -porque no-, la propia madurez de los profesionales del sector que empiezan su carrera profesional en Andalucía.

O lo que es lo mismo: la gente que va a dedicarse a esto, ¿sale imbuida del “espiritu garajero a.k.a. emprendedor” de donde quiera que ha sido instruido? La respuesta, en mi opinión, viene a ser que no, y creo que es algo que viene directamente de los métodos de formación y evaluación, desde mi experiencia, en la universidad. Luego ya está lo de que cada uno debe ser consciente de sí mismo y su entorno, pero es otra faceta más del mismo problema, creo yo.

Al final se atisbó algo de luz, al hablar de la dificultad de hacer comunidad, en concreto en Sevilla. La dificultad de montar eventos y charlas (que nos lo digan a los Wombytes) y que acuda el personal. De nuevo me remito a lo anterior. Me hubiera gustado que se ahondara más en ciertas recomendaciones que iban surgiendo para dar visibilidad a eventos y hacer algo de piña y masa, pero el tiempo no lo permitió.

Yo te la mido (la campaña), por David JGurú y Rubén Teijeiro

Me gustó mucho el planteamiento temático (en torno al surf) de la presentación, la idea, la motivación, toda la explicación del por qué y el como, el equipo, y el insistir y volver a insistir en opensource y el “lo damos gratis y libre”, una auténtica rara avis en éste evento.

Si debo decir que la parte en la que se muestra código me pareció algo floja, perdiendo la atención de muchos asistentes. Creo que es simplemente cuestión de seguir desarrollando la demo y poder mostrar más chicha en acción.

JS’s varios para hacer de todo, propuesta por Javier Alonso

Dada mi inexperiencia con las tecnologías tratadas (no me he pegado de verdad con node.js aún), éste fue el coloquio en el que estuve más perdido, aunque creo que sí que fue el más “open” de todos. Cada uno fué contando su experiencia y sus ideas respecto a los diferentes “js” tratados, consejos, mitos desmontados, referencias, documentaciones, un auténtico ejercicio de compartir conocimientos.

Historias de usuario, por José Manuel Beas

Sin lugar a dudas, la mejor ponencia de las que asistí. Hace poco que sigo a Beas en Twitter, y he leído algo de su blog, y la verdad es que sus intervenciones en el resto de charlas me gustaron mucho, pero me resultó impresionante verle “en acción” llevando realmente la batuta en una ponencia, y hablando de lo que más sabe. En cuanto a las historias de usuario, es algo con lo que tengo contacto en mi trabajo (llevo cuatro meses trabajando en un equipo ágil), y cada vez creo más firmemente que el agilismo es el camino para hacer las cosas bien, y hacerlas a gusto.

Obviamente las inquietudes sobre el mapeo de requisitos no funcionales, el catálogo de requisitos y demás parafernalia proveniente de la metodología tradicional es algo que a todos nos preocupa/ha preocupado en algún momento, pero creo que en muchos casos son cosas que por experiencia van saliendo solas. Me gustó mucho el hincapié que se hizo en el tablón físico, en el “yo soy el que mueve la tarjeta”, el “veo el tablón y de un vistazo tengo una impresión de como va la cosa”, me sentí muy identificado, me gusta tener las cosas apuntadas en papel, y por ejemplo, tachar una tarea realizada en un papel resulta infinitamente más gratificante que marcar un check en una aplicación móvil. Creo que trasladar a lo físico ciertos aspectos de nuestro trabajo, por muy IT que seamos, es esencial, a muchísimos niveles.

Y hasta aquí en cuanto al contenido de las charlas (me salté la última y la retro, soy mala persona).

En cuanto a la experiencia, tremendamente positiva. Al ser la primera vez, considero en global todo, y repetiría sin pensármelo. Quizá en cuanto a contenidos y charlas, podría mejorarse tal o cual cosa (contenido más técnico, o no; más control sobre determinadas actitudes), pero creo que simplemente es cuestión de estar ahí en la próxima ocasión, y aportar/proponer yo mismo algo, callar menos y participar más (aunque soy de natural observador, qué voy a hacer), y adaptar así el evento más a mis gustos y preferencias. Es así de simple y así de bonito. Lo mismo si fuera la cuarta o quinta vez que acudo a un sarao de estos no quizá estaría tan contento, pero la verdad es que me siento muy satisfecho.

Y la verdad, por 12€ un día y medio de conocer a personas, profesionales y absorber tanto conocimiento, los amortizas y amortizarás más y mejor que cualquier Máster de tres al cuarto de esos que hay por ahí.

At my job, we decided that twice a month, a member of the team should host a talk in which he would speak about something he could teach to the others. When we spoke about this, I had just succesfully deployed my first Rails application and I kinda liked it (bear with me, I was a C++ systems dev kid for 2+ years, it was a brave new world for me), so I suggested the possibility of giving a talk on Capistrano, the Rails default-ish option for deploying automation.

I prepared a neat presentation available here (Spanish only). Its most important part is based in a live demo, so I’m sorry if you find that it doesn’t cover essential aspects like tasks syntax and such, because they were covered in the hands-on. In exchange, I offer you some simple recipes I made as examples, or by demand of a fellow dev at Wombytes. They aren’t intended as showcase of my prowess at reciping, but only as simple examples of what namespaces and tasks are about. In fact, they’re the composition of fragments and ideas picked from all around the internets.

This one allows you to see the production log as it grows, without the fuss of having to open a new terminal get into the machine via ssh and navigate to the log folder. Just an elegant cap production log:tail and there you go! In this github repo there’s a similar one, that executes tail on every log present (pre, production, whatever) instead of just one. The addition of the INT signal treatment was shamelessly taken from this post from the almighty Stackoverflow.

  namespace :log do
    desc "Tail production log file"
    task :tail, :roles => :app do
      run "tail -f #{shared_path}/log/production.log" do |channel, stream, data|
        # this catches the INT signal and avoids the ugly capistrano error on CTRL+C

        trap("INT") { puts 'Interupted'; exit 0; }
        # this is to have a cleaner output

        puts "#{channel[:domain]}: #{data}"
        break if stream == :err
      end
    end
  end

The next set of recipes make use of your regular recipe to make dumps (namely ‘backup’) of the production database, and need a couple of extra things. Basically what they do is put some order in your dumps folder, and download new dumps you create easily via scp. I don’t like the fact that they have too much folder information hardcoded on them, but it’s just a matter of refinement and good variable usage.

  #put this with your variable declarations

  #the LOCAL folder where you want to store database dumps

  set :projects_folder, 'projects'

  #put this with the rest of your hooks

  before "db:getnewdump", "db:tidydumps"

  # THESE TASKS GO INTO YOUR namespace :db

  desc "Moves old backups to old folder"
  task :tidydumps do
    puts 'Moving old backups to the old folder'
    run "mkdir -p #{shared_path}/db/backups/old"
    run "mv #{shared_path}/db/backups/*.gzip #{shared_path}/db/backups/old"
  end

  desc "Downloads the las db dump"
  task :getlastdump do
    puts "Downloading latest dump to $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "mkdir -p $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "scp -P #{port} #{user}@#{domain}:/#{shared_path}/db/backups/*.gzip
            $HOME/#{projects_folder}/database_dumps/#{application}/"
  end

  desc "Creates a dump and downloads it"
  task :getnewdump do
    db.backup
    db.getlastdump
  end

  desc "Downloads ALL THE DUMPS!!"
  task :getalldumps do
    puts "Downloading dumps to $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "mkdir -p $HOME/#{projects_folder}/database_dumps/#{application}/"
    system "scp -r -P #{port} #{user}@#{domain}:/#{shared_path}/db/backups/*
            $HOME/#{projects_folder}/database_dumps/#{application}/"
  end

Anyway, the talk went well, as only the devs were present[1] and I felt more comfortable. Some team members learnt something they didn’t know about Capistrano (yay for me!), and some others with more experience explained some things I didn’t have understood too well to me (yay for me again!).  There’s a chance that I will be giving this talk sometime again in the future, so those lucky enought to see me then will get a much better and expanded experience.

This talk gave me the chance to have a conversation with Juanje Ojeda, who kindly pointed me in the direction of some nifty Chef (which is mentioned at the end of the presentation) resources, so I can delve deeper into the devops lore. I guess you’ll be reading about my findings here in the short future. Thanks, mate :)

That’s the best of it: get the satisfaction of teaching a little bit and learn a lot in the process.

[1] Having talks on thursdays at 18:30 in a god forsaken place faraway from downtown doesn’t precisely attract many peeps, no matter how interesting the talk seems to be.