lunes, 7 de octubre de 2013

Agile Solo: prácticas ágiles para corazones solitarios

Agile Solo

Espero que este post sea el primero de una serie (que quedará bajo el tag AgileSolo para poder rastrearla más fácil) que puede ir creciendo a lo largo del tiempo.

La idea surgió a partir de invitar a un amigo de toda la vida, que mantiene desde hace años su empresa de un sólo hombre con éxito, a uno de los talleres de Scrum que damos en Kleer.

Su experiencia fue muy buena, pero muchas veces durante el taller yo iba pensando cómo aplicar algunas de las prácticas que veíamos en un contexto como el de él, navegante solitario. Y como su situación no es única y yo mismo estuve ahí varios años (trabajando a veces solo y otras en equipos remotos y distribuidos) nació la idea de compartir aquí algunas ideas.

El mito del programador solitario

Lo primero que vale aclarar es que en realidad difícilmente trabajemos realmente solos. Gran parte de la estrategia a la que apunto en esta serie es que aunque nuestro equipo principal seamos nosotros mismos, podemos ampliarlo favoreciendo la colaboración con nuestros clientes, con terceros involucrados en nuestros proyectos, y con la comunidad misma.

Scrum en solitario

Por supuesto, no existe algo como "hacer Scrum al 100%". Como en todo marco de mejora continua, no existe un techo al que debamos alcanzar. Dicho esto, practicar Scrum en solitario es una solución de compromiso, distante del ideal, pero...

Repasemos rápidamente los roles de Scrum:

  • Scrum Master
    Su responsabilidad es facilitar que el equipo de Scrum  (incluyendo al PO) alcance su máxima productividad, calidad y felicidad. En la práctica facilita reuniones, remueve impedimentos y usualmente lleva un backlog de mejoras surgidas de las retrospectivas.
     
  • Product Owner
    Su responsabilidad es lograr que el equipo pueda desarrollar el mejor producto posible, lo que implica un fuerte foco en la prioridad de negocio, estar seguro que todo lo que se necesita está en condiciones de construirse, y lograr impulsar la entrega y puesta en producción lo más frecuentemente posible, para facilitar el aprendizaje conjunto con los usuarios, clientes y otros involucrados.
     
  • Equipo de desarrollo
    Es el equipo multi-disciplinario que se encarga de construir el producto, involucrando diseño, desarrollo, pruebas, arquitectura, manejo de datos y servicios, etc. Scrum propone que el equipo cuente con toda la gente necesaria para construir el producto adecuadamente.

¿Cómo compensamos estos roles en un one-man-team?

En principio, la alternativa para el Scrum Master es sin duda, auto-organizarse. Es todo un desafío hacer retrospectivas con uno mismo, pero se puede apartar un cierto tiempo y poner en práctica, aunque sea de manera individual, algunas ideas clásicas de las retros de equipos, como buscar qué queremos seguir haciendo, qué queremos probar y qué debemos cambiar. 

Un tip para general alto del azar y la perspectiva diferente que aportan otras personas es recurrir a métodos como el I-Ching ó las tarjetas Oblique Strategies de Brian Eno. En ambos casos se trata de una selección de frases o estrategias que tomamos al azar y usualmente nos dan una perspectiva totalmente diferente, por ser cosas muy genéricas. Son un antídoto contra el bloqueo mental, más que nada. Para ambos casos existen muchas aplicaciones gratuitas, con lo que no cuesta nada probar.

Lo importante (al igual que en los equipos) es acostumbrarse a mantener un backlog de mejoras. Mi recomendación usual suele ser priorizar las cosas que queremos mejorar, y comprometerse únicamente a la primera de ellas durante el siguiente sprint.

En el caso del Producto Owner la opción ideal siempre es que sea un rol cubierto por una persona de nuestro cliente. Cuando trabajamos solos es más importante aún para poder separar mejor los criterios, pero como siempre, hasta que esa persona comprenda y ejecute bien ese rol, deberemos asistirla en la priorización y mantenimiento del backlog, en el empleo de historias de usuario, y en la planificación de entregas.

Respecto al Equipo de Desarrollo, es la parte que más tradicionalmente encaramos en solitario. En estos casos solemos ser multi-disciplinarios casi por naturaleza, porque todo debemos resolverlo solos, pero podemos además aplicar sobre todo muchas de las prácticas principales de XP, como TDD y ATDD, integración continua, y si somos algo esquizoides, hasta programación de a pares. :)

En realidad, algo que me sirvió personalmente para compensar los pares de un equipo es buscar oportunidades de trabajar regularmente de a pares con otros colegas, aprovechando los canales comunitarios, y la tecnología disponible hoy día para hacerlo de manera remota.

Pero ya es bastante por esta primer entrega. Espero que les sea útil, y si tienen preguntas o sugerencias, les pido las discutamos en Twitter.

 


miércoles, 2 de octubre de 2013

Se viene RubyConf AR el 27 y 28 de noviembre (+ video)

RubyConf AR

La grandiosa mitad de conferencia de Ruby rio-platense (la otra mitad es la RubyConf UY, que se hace en Montevideo por marzo) ya tiene fecha y unos cuantos oradores anunciados.

Entre las grandes figuras está mi amigo y Maestro Angel "Java" López, con foto y todo en el sitio, lo que es poco frecuente.

Y por algún error administrativo, me han aprobado mi propuesta y estaré facilitando el clásico Yoseki Coding Dojo en el Ruby Fun Day que se realiza el 26 de octubre (un día antes) en la Universidad de Palermo.

La conferencia principal será en Ciudad Cultural Konex, como en el 2011.

Como siempre, RubyConf (tanto en Buenos Aies como en Montevideo) es un evento organizado con amor y pasión, que se nota en cada detalle, desde las camisetas hasta la atención permanente, el ambiente entre asistentes y oradores, las reuniones antes, durante y después del evento, y la magia permanente durante todos los días.

El contenido es muy variado, desde temas súper técnico a cuestiones meteorológicas y más de negocios, por lo que todos tienen algo interesante, pero los encuentros entre charlas son una parte enorme del espíritu de esta conferencia.

Dejo de regalo un video divertidísimo de la charla del amigo Jano Gonzalez, "¿Dónde están mi interfaces?", el año pasado:

jueves, 26 de septiembre de 2013

TDD rocks! con el Maestro Angel "Java" López (+videos)

Desde hace un par de meses el Maestro comenzó a grabar unos Hangouts sobre TDD, mostrando ejemplos de algunos de sus proyectos reales, mientras implementa funcionalidades.

Los vídeos no están en español, sino en Anglish (pueden aprender algo de este dialecto en este post previo), pero si hacen click en su nombre en YouTube encontrarán otros que tiene grabados en español. Me pareció particularmente interesante esta serie porque sigue un hilo temático.

Recuerden que además de multitud de conocimientos compartidos en Twitter, el Maestro también publica un post diario (al menos) los 365 días del año, en alguno de sus blogs:

¡Que disfruten la serie!

miércoles, 25 de septiembre de 2013

Se viene Ágiles 2013, el mes próximo en Lima, Perú

NewImage

Para los que no se enteraron, Ágiles 2013, la 6ta conferencia latinoamericana de metodologías ágiles llega de vuelta a Lima (donde se realizó en 2010), con grandes expectativas.

La cita es el 10, 11 y 12 de octubre en la Cámara de Comercio de Lima, y tendremos:

El registro ya está abierto, así que espero ver a muchos por allá. Pueden buscarme, claro, en el stand de Kleer.

Les dejo un saludo de toda la tropa del último Agile Open Medellín invitando al evento (¡sólo 25 segundos!):

lunes, 23 de septiembre de 2013

¡Opa! ¿Y este framework?

Opa Up and Running

El framework Opa para JavaScript es más que un framework. En realidad, es un lenguaje + una librería, pero con un objetivo bastante ambicioso: Opa intenta cubrir con mismo lenguaje el desarrollo del lado cliente, servidor y el acceso a base de datos.

Según la introducción del proyecto en su repositorio de GitHub (traduzco):

Opa es un framework avanzado para JavaScript, compuesto de dos partes:

  • Un compilador para el lenguaje Opa, que presenta una sintaxis de estilo JavaScript pero con muchas mejoras;
  • Una librería JavaScript, que se usa en tiempo de ejecución.

Siguiendo la tradición de recorrer "Raros lenguajes nuevos", lo que más me interesó de Opa es el lenguaje mismo, y ese objetivo ambicioso, así que veamos algunas características:

Opa es open source (la librería con licencia MIT y el compilador GPL 3) y se autodefine como un lenguaje "full stack" ya que cubre todas las capas, y promete soportar aplicaciones seguras y escalables.

Las aplicaciones terminan ejecutándose sobre Node.js y usan MongoDB para el manejo de datos.

Soporta nativamente HTML5 y CSS y trata de automatizar la comunicación cliente/servidor con Ajax/Comet, y brinda un modelo de programación orientado a eventos y no-bloqueante (básicamente, respeta el modelo JS, pero subiendo el grado de abstracción).

Una de las promesas más atractivas de Opa es que se puede programar sin pensar (a priori) en la distinción entre cliente y servidor. El compilador analiza y distribuye el código, haciéndose cargo de toda la comunicación. Posteriormente, sin embargo, uno puede optimizar algunas situaciones utilizando los modificadores client y server.

Veamos el clásico "Hola, Mundo" en Opa:

Server.start(
   Server.http,
   { title: "Hola, Mundo"
   , page: function() {<h1>¡Hola, Mundo!</h1> }
   }
)

El programa se corre (habiendo instalado el compilador y las herramientas, obviamente) con el comando: opa hola.opa -- y la aplicación puede navegarse en http://localhost:8080

Algo interesante de Opa es que a pesar de compilar a JS (algo ya recurrente) es un lenguaje de tipos estrictos, aunque no hace falta declararlos porque se utiliza inferencia. Sin embargo, el compilador informa de cualquier tipo de violación y es bastante inteligente al sugerir incluso las opciones para solucionarlas.

Veamos un ejemplo más, con acceso a datos. Este ejemplo de los tutoriales cuenta clics y los almacena en una tabla:

import stdlib.themes.bootstrap

database int /counter = 0;

function action(_) {
    /counter++;
    #msg = <div>Thank you, user number {/counter}!</div>
}

function page() {
    <h1 id="msg">Hello</h1>
    <a class="btn" onclick={action}>Click me</a>
}

Server.start(
    Server.http,
    { ~page, title: "Database Demo" }
)

Como puede notarse en el ejemplo de arriba, el HTML queda completamente embebido como parte del lenguaje, sin necesidad de usar comillas para los literales, que además soportan interpolación sencilla. 

Obviamente, como Opa está basado en Node, también es posible usarlo en Linux, FreeBSD, OS X y Windows, y estando disponibles todos los fuentes, es posible compilarlo en otras plataformas también.

También tiene instrucciones para desplegar fácilmente aplicaciones en plataformas como Heroku, Cloud Foundry y otras, y existen packs para varios editores como SublimeText, Emacs, Vim, Eclipse, GEdit y otros.

Esto es una brevísima introducción porque realmente hay mucho por investigar en este interesante lenguaje. Si alguien profundiza, me encantaría que me cuente. Lo mismo haré por mi lado.

Y casi me olvido: como pueden ver en la ilustración más arriba, hay un libro publicado por O'Reilly.