A software developer cookbook

The Sketchnote Handbook

By Yeray Darias in , ,
Hace ya un tiempo que leí uno de los libros de Nancy Duarte, Resonate, y añadí la RSS del blog de su estudio a mi lista de blogs habituales. Y es allí, a principios del mes de febrero, donde encontré una referencia a un libro que parecía bastante interesante, The Sketchnote Handbook, escrito por Mike Rohde. Hoy te voy a contar que me hizo comprármelo y te daré mi opinión personal del mismo.

El aspecto general del libro, que os puedo asegurar está muy bien ilustrado y encuadernado

Una de las constantes del desarrollador de software es que debe estar continuamente aprendiendo, y una de las formas más comunes de hacerlo es en eventos con otros desarrolladores; durante charlas en comunidades locales, conferencias, workshops, lo que sea, pero todas ellas implican un continuo bombardeo de información. Es la necesidad de sintetizar toda esta información lo que me ha hecho buscar formas mejores de atender a las ponencias y talleres, por esta razón he comprado el libro. Aunque al principio el precio parecía excesivo en relación con otras alternativas, he de decir que no me arrepiento en absoluto.

Lo primero que llama la atención, a parte de su elegante cubierta, es que no es un libro al uso lleno de texto en toda su extensión. El propio autor, en colaboración con otros expertos en este campo, hace uso de sketchnotes para explicar las ideas, lo que hace que te puedas leer el libro en unas pocas horas. Se hace muy ameno y la idea de dejar que otros profesionales explicasen su visión permite tener diferentes puntos de vista que fomentan la reflexión del lector.

El libro avanza desde la explicación general de porque es mejor hacer sketchnotes, hasta los últimos capítulos más técnicos y que requieren de práctica por parte del lector. Pero lo mejor es que lo aprecies en el índice del libro.

  1. What are sketchnotes?
  2. Why sketchnotes?
  3. Listen up!
  4. The sketchnoting process
  5. Types of sketchnotes
  6. Sketchnoting approaches, hierarchy, and personalization
  7. Sketchnoting skills & techniques

A quién le puede interesar

En resumen, a todas aquellas personas que necesitan resumir gran cantidad de información, asistentes habituales a conferencias, conferenciantes profesionales, alumnos de universidad, al panadero de mi barrio ... simplemente personas que les gusta probar nuevas ideas :-P

A quien no le interesará

Pues no se me ocurre a quien no le puede resultar interesante, probablemente todas aquellas personas que ya tienen experiencia haciendo sketchnotes. O, quien no le apetezca lo más mínimo mejorar su capacidad de atención en un evento :-)

Mis primeras sketchnotes 

Como bien indican varias veces a lo largo de la lectura, la mejor forma de aprender es practicando, y aunque el libro se lee en un par de horas hay bastantes ejercicios recomendados que harán que te acompañe durante unos cuantos días.

Yo he decidido hacer caso a una de las notas incluidas en el libro y he comenzado por hacer sketchnotes de algunas charlas TED que a priori me parecían interesantes; es una gran forma de practicar en casa. No he logrado hacer ninguna obra de arte, pero sí he comprobado de primera mano como con este sistema mi nivel de atención era bastante mayor. Ya os contaré cuando lo ponga en práctica en un evento real.

Lo sé, me he equivocado con el apellido de Jeff Sutherland, pero los errores son parte del sketchnoting ;-)

Al principio me parece complicado calcular cuanto van a ocupar los dibujos o la organización, pero la práctica hace la perfección

A veces los conceptos explicados no son tan sencillos de dibujar con formas simples, es el momento de las flechas y los diagramas :-)

Bola extra: Vídeos del autor

Por lo menos en la edición que yo he comprado, se incluye un código que permite la descarga de vídeos del autor explicando el proceso. Aunque estos vídeos no expliquen nada que no esté en el libro, son muy útiles para observar todo el proceso de un sketchnote desde el principio, lo cual ayuda bastante. 

Aquí tenéis un ejemplo.


Espero que esta crítica os haya servido y os anime a darle una oportunidad al sketchnoting.

P.D: Si compras una edición electrónica que sea en tablet o PDF porque en una pantalla monocroma como la del Kindle seguro que desluce un poco.

Mi experiencia en el Startup Weekend Tenerife

By Yeray Darias in , ,
Mi experiencia en el Startup Weekend Tenerife
Durante los días 1, 2 y 3 de febrero tuve la oportunidad de participar en el Startup Weekend Tenerife. Es posible que no sepas lo que es un Startup Weekend (SW), pero es un concepto muy sencillo que puedes aprender en su propia web. Pude proponer mi idea, formar un equipo fantástico e incluso al final tuvimos la suerte de ganar. Te daré algunos consejos y te contaré algunas cosas que pude aprender, te podría resultar útil si decides participar en el futuro ;-)

Que buenas las caras de @carlosble, @yurenaghm y @chozero cuando me vieron con un lanyard de Visual Studio ... tranquilos chicos sigo siendo un javero convencido :-P


La preparación es muy importante


Cuando hablo de preparación no me refiero a que trabajes en tu idea, sino a documentarte sobre este tipo de eventos, las cosas que han funcionado o que han fallado a participantes anteriores y a como extraer el máximo valor de la experiencia.

En mi caso personal hay una parte que ya había aprendido debido a mi conocimiento sobre las técnicas de desarrollo ágil, esto es útil en el apartado de ejecución técnica, pero todavía tenía algunas lagunas en aspectos más de negocio. Recuerda que no solo quieres tener un mínimo producto viable para la presentación final, también quieres validar la idea de negocio. En este apartado me resultó bastante útil haber leído The Lean Startup y Startup Weekend (el libro).

Alguna bibliografía interesante de cara al evento

Por otro lado, es muy importante que lleves tus herramientas preparadas, ya sea para trabajar en la idea que propones como para trabajar en ideas de otras personas, los desarrolladores deberíamos tener las herramientas a punto y listas para empezar a producir valor. En mi caso personal el uso de JavaScript, con Node.js en servidor y Backbone.js en cliente, ha funcionado muy bien y ha permitido que el resto de desarrolladores del equipo se integre fácilmente.

Obtén la versión básica de tu idea


El primer día del evento tienes que presentar tu idea al resto de participantes y formar un equipo. Pues tanto para cautivar a esas personas que quieres que formen parte de tu equipo, como para llegar a tener un mínimo producto viable (MVP) al final del fin de semana, debes pensar en una versión básica de la idea.

Unos wireframes en papel fueron más que suficiente para que el equipo supiese cual era el objetivo del fin de semana
No es necesario que hables de todas y cada una de las características que quieres que tenga, ni la infinidad de problemas que quieres que resuelva, centrate en un único problema, algo que le haga la vida más fácil alguien y evoluciona el concepto. Lo bueno del SW es que durante el fin de semana coincidirás con mucha gente, entre ellos los mentores, que te irán aportando nuevas ideas y visiones, es útil que hagas una lista para revisarlas cuando tengas algo más de tiempo.

Deja que las cosas sigan su cauce 


Este punto es muy personal y discutible, en general cada persona lo puede haber vivido a su manera o tiene su propio modo de gestionar. En mi caso particular pude formar un gran equipo, bastante técnico en cierta medida, por lo que decidí no participar como desarrollador y centrarme en la parte de negocio y coordinación del equipo.

Con este pedazo equipo no hacia falta ningún tipo de control :-)

Solo hubo que enfocar a todo el equipo en cual era el objetivo y los tres o cuatro hitos que queríamos ir alcanzando a lo largo del fin de semana y tanto el equipo de desarrollo como el de diseño lo fueron haciendo sin ninguna necesidad de ir controlándolos. En cada hito comentábamos lo que teníamos y si algo no iba bien o necesitaba más tiempo entre todos encontrábamos una solución más adecuada.

Cualquiera que sepa un poco de metodología ágil podría haber visto dos conceptos muy sencillos nada más entrar en la habitación. Primero, utilizábamos un tablón Kanban para controlar el estado del equipo, las tareas en desarrollo y el avance del "product backlog". Segundo, cada componente del equipo era responsable de la tarea que llevaba a cabo y tenía poder decisión sobre la misma (empowerment), lo cual no quiere decir que no se tomasen decisiones en equipo.

Usa timebox para tomar decisiones


Timebox es un concepto muy sencillo, fijar un tiempo máximo para una reunión o tarea. Ni que decir tiene que en un SW el tiempo es el bien más preciado, junto con los diseñadores ;-) Por lo que es necesario no gastar más tiempo del necesario en absolutamente nada.

Por poner un ejemplo. Nosotros limitamos el tiempo a seleccionar el nombre del producto a 30 minutos, después de esos 30 minutos nos quedamos con el que mejor encajaba. Cuando llegó la primera ronda de mentores se comentó que el nombre ya lo usaban otras webs y que algunos de los perfiles sociales ya estaban cogidos. Pues sí, pero de nada hubiera servidor buscar un nombre molón y que no tuviese nadie durante 5 horas, porque no habríamos tenido el producto, ni podríamos haber cerrado colaboraciones con futuros clientes como sí hicimos. El tiempo es tuyo, usalo como quieras, pero recuerda que sólo hay 54 horas y debes hacer las cosas que más valor aporten.

Mentores sí, pero con cuidado


Al final del evento Sergio Montoro dio una breve charla en la que comentaba que no debemos hacer caso a los mentores :-) yo no creo que haya que llegar a esos extremos, pero estoy en parte de acuerdo. Durante el fin de semana te visitarán mentores entre tres y cinco veces, en cada ocasión te darán consejos, nuevas ideas, nuevas opciones de negocio, pero no puedes intentar hacer todas esas cosas. Escoge sólo aquellas cosas que vayan en la línea de lo que estas haciendo y se puedan implementar rápidamente, pero no descartes las otras, apuntalas en la libreta para analizarlas de cara al futuro, recuerda que después del fin de semana puedes seguir trabajando en tu idea.

Acostumbrate, cometerás fallos


Quizás este sea uno de los puntos más importantes, en 54 horas no hay tiempo para lamentarse por los errores, hay que seguir adelante y trabajar en aquellas cosas que nos aporten más valor y beneficios. Por ejemplo, nosotros no llegamos a comprar el dominio para la aplicación, tampoco actuamos en las redes sociales, pero eso no supuso necesariamente un impedimento.

A nivel personal como coordinador del equipo me quedo con un regusto amargo por no haber podido mantener a todo el equipo inicial hasta el final, dos componentes decidieron abandonar el domingo por la mañana. Pero debes saber que esto no es extraño en los SW, son cosas que pasan a menudo y que debes aceptar o de lo contrario no llegarás a la presentación del producto.

Agradecimientos


Ha sido un evento fantástico y me gustaría agradecer a toda la organización el magnifico trabajo que ha realizado. Sé de buena tinta que no es nada fácil organizar un evento como este, pero lo han hecho magnificamente y se merecen un 10 ^_^


Material adicional


Este artículo muestra algunas herramientas que pueden ser de gran valor en un SW.

Aquí puedes encontrar un enlace al análisis que hice hace unas semanas del libro de Startup Weekend.

Vísteme despacio que tengo prisa

By Yeray Darias in , ,
Este domingo por la tarde estaba haciendo un postre, lo he hecho múltiples veces, y por lo que dicen mis compañeros no me queda mal :-) En esta ocasión cuando lo saqué del horno y lo probé, tras dejarlo enfriar claro, casi me muero del susto, no estaba malo, estaba mucho peor. ¡Me olvidé de poner el azúcar!, un error de principiante. Pero se me encendió una bombilla ya que de esta experiencia podía sacar un artículo "interesante" para el blog.

El post de Ancor que me animo a escribir esta entrada en el blog.
Es curioso como puedes conectar cualquier anécdota cotidiana para sacar conclusiones de otro campo que nada tiene que ver. Aquí van las conclusiones que saqué de hacer un postre, aplicadas al desarrollo de software.

Evita el Cowboy Style


Cuando a la gente le hablas por primera vez de desarrollo ágil muchas veces piensa que no es más que tirar la documentación y ponerse a programar como si no hubiese mañana. Nada más lejos de la realidad. El desarrollo ágil intenta evitar hacer cosas que no tienen valor (muy parecido a "lean"), pero eso no quiere decir que no haya que planificar o tener en mente la "imagen global" del proyecto.

Lo que yo he hecho en la cocina es Cowboy Style, he ido cogiendo los ingredientes a medida que los necesitaba y mezclándolos, incluso prestando atención a otras cosas durante el proceso, lo raro es que no hubiese metido la pata más aún. Gracias a Dios no es lo que hago normalmente. Lo que debía haber hecho es terminar con todo lo que estuviese haciendo para que no hubiesen intromisiones, preparar todos los ingredientes antes de empezar revisándolos con la lista de la receta y posteriormente con calma preparar el postre.

En el desarrollo de software es exactamente igual, incluso muchos equipos han incluido un sus tableros Scrum o Kanban (o Scrumban o como quieras llamarlos) una columna que indica cuando una funcionalidad está lista para ser implementada, es decir cuando tienes todos los datos necesarios para no hacer una chapuza y que dicha funcionalidad de verdad aporte valor una vez la hayas completado. Si, en cambio, haces lo que yo he hecho en la cocina terminarás trabajando por dos o peor.

Que lo hayas hecho muchas veces no quiere decir que no te pueda salir mal


Este postre en concreto lo había hecho unas cuantas veces, razón por la que me he confiado, muy mal. Ya habéis visto que incluso cuando tienes experiencia puedes meter la pata, somos humanos. Ya tenía un proceso que me funcionaba, ha sido cuando he modificado ese proceso, sin ninguna razón aparente, cuando todo ha fallado.

Lo mismo se puede aplicar al desarrollo y sus metodologías. Si tienes un proceso que te funciona, o no, no lo puedes cambiar de cualquier manera, tienes que experimentar, documentarte sobre como mejorarlo, pero no cambiarlo a la ligera porque algo simplemente no te gusta. Ocurre muy a menudo que equipos que aplican Scrum en sus proyectos no terminan de sentirse cómodos, pero lo que hacen muchos es cambiar sus practicas sin una experiencia previa, mal, porque no sabes si estas mejorando o empeorando.

Intenta hacer TDD 


Recordando el tweet de Ancor, ha sido el no tener una prueba unitaria lo que ha provocado que fallase al hacer el postre. Imaginad que con la lista de ingredientes los preparo todos y los dispongo para hacer la masa. Luego cuando termino de hacer la masa reviso que los he utilizado todos, no habría cometido ese error, ¿verdad?

En desarrollo de software puedes lograr algo muy similar haciendo uso de TDD (Test Driven Development). Al pensar en una prueba antes de desarrollar la funcionalidad, te está forzando a pensar el problema de forma que se evita fácilmente el Cowboy Style. Y como punto extra, tienes un código soportado por pruebas :-)


Y eso es todo por esta vez amigos :-)