Mostrando entradas con la etiqueta agiles. Mostrar todas las entradas
Mostrando entradas con la etiqueta agiles. Mostrar todas las entradas

domingo, 22 de abril de 2018

Literatura Potencial al Aire Libre

Literatura Potencial al Aire LibreDurante la reciente edición 2018 del Agile Open Camp, en Bariloche, Argentina, presenté una charla relámpago (21 slides de 20 segundos cada uno; 7 minutos en total) que titulé “Restricciones para la Creatividad” y en la que contaba sobre el Oulipo, el “Ouvroir de littérature potentielle” que en los años '60 fundaron en Francia escritores de diferentes orígenes, dedicado a explorar las posibilidades de restricciones auto-impuestas, surgidas sobre todo de las matemáticas y sus derivados (como la música o el ajedrez) para desencadenar procesos creativos.

Debajo queda la presentación, aunque son sólo imágenes. Pero más importante que eso, para mi, es el libro que tiene el mismo título que este post, resultado del taller que realizamos más tarde, durante una sesión del Open Space.

Los asistentes escribieron varios Haiku, y luego comenzaron cuatro cuentos, algunos de los cuales fueron finalizados días más tarde. El librito es una compilación de esos trabajos, más una breve introducción que recupera (con notas adicionales) parte de la charla relámpago.

Gracias a Marta Bendomir, Tommy Christie, Marcela Pelz y María Thompson por participar del taller y del libro, y gracias a Manuel Mandrafina Thompson que colaboró en el cierre de uno de los cuentos.

El libro puede descargarse en forma libre y gratuita desde aquí (o desde la imagen de tapa más arriba).

viernes, 26 de enero de 2018

Espacios de Trabajo para Equipos Ágiles

Este es un tema recurrente con muchas organizaciones a las que ayudo. Como el foco principal del paradigma ágil es la colaboración, muchas veces llega un momento en que ellos notan que sus espacio de trabajo no son ideales para lo que intentan lograr.

 

Espacios frágiles

CubículosLos espacios de trabajo más nocivos que me encuentro suelen incluir desde cubículos hasta oficinas individuales a puerta cerrada. Y aclaro que he trabajado en lugares así, aunque nunca fue mi preferencia. Durante un tiempo -hace muchos años- me tocó una oficina privada, alejada por un pasillo largo del equipo que me tocaba liderar. Al principio me sentí inocentemente importante, pero pronto me di cuenta de que esa distancia no nos beneficiaba en nada.

Algunas variantes de los cubículos son los espacios semi-abiertos con escritorios con divisiones más bajas, que permiten verle los ojos a la persona de enfrente, aunque no alientan una colaboración más allá e una pregunta o conversación esporádica.

Y no sólo los espacios físicos generan fricción. Muchos espacios virtuales también lo son. Muchas de las llamadas "herramientas de colaboración" me resultan consistentemente un impedimento a la conversación cara a cara. A riesgo de controversia, no he visto nunca un equipo que mejore su comunicación (pero si montones que definitivamente empeoraron) por usar Jira, Sharepoint u otras monstruosidades que están más diseñadas para calmar al management que para que la gente se auto-organice.

 

Espacios con "Onda Ágil"

Héroes

Muchas organizaciones, al sentir que la gente se entusiasma con la agilidad, quieren crear lugares atractivos para atraer talento que espera determinadas características laborales que no son tan fáciles de transmitir a simple vista. Así que recurren al folklore y no muy extrañamente, atraen a los estereotipos a los que se dirigen, lo que no siempre da resultado.

Clásicos de ese estilo son las metegoles (o futbolines, según la región), las paredes ploteadas con íconos y slogans sobre creatividad, innovación y talento, aunque frecuentemente esos y otros valores están en las paredes pero no se sienten en el día a día. En algunos extremos (que creo bien intencionados) se ven exaltaciones a los super-héroes, los rock-stars o ninjas. Como si colaborar fuese tratar de ir solo contra todo, inmolándose por alguna causa esquiva.

 

¿Espacios realmente ágiles?

Mis consejos para quienes quieren realmente generar un ambiente de colaboración y dinamismo van siempre en el mismo sentido: empezar por no definir todo, sino dejar lo máximo posible a criterio de los equipos que usarán el lugar.

Para eso, realmente suele ser preferible contar con espacios abiertos, pero como pueden ser ruidosos, se puede recurrir a elementos que la gente pueda usar para crear sub-espacios flexibles y reconfigurables.

Espacio KleerAlgunos de los elementos que prefiero (por experiencia, como materia mínima para que los equipos decidan después):

  • Mesas pequeñas, con patas no intrusivas, donde al menos se pueda trabajar de a dos. O livianas o con rueditas.

  • Tomas de corriente a granel, sobre las paredes. Y que los equipos puedan poner sus (inevitables) extensiones por donde quieran. Si los cables se tornan molestos o peligrosos, ellos deberían encontrar la mejor solución, no un "arquitecto".

  • Pizarras o bastidores fáciles de mover (con rueditas o livianos) pueden servir como separadores, aislantes acústicos y también como soporte para radiadores visuales.

  • Paredes libres (también pueden ser ventanas o paneles de vidrio), sin inscripciones, emblemas ni slogans previos. El uso de las paredes para pegar tableros, indicadores, información necesaria para el equipo, es vital para la comunicación osmótica. Los pizarrones de diferente tipo, sobre todo si son móviles, son un buen recurso para discusiones y diagramas efímeros.

  • Buenas sillas. Pensando que los trabajadores del conocimiento usamos sobre todos nuestro cerebro y nuestro trasero, tener buenas sillas (de nuevo, móviles) es una excelente inversión para cuidar la salud y comodidad de los equipos.

Sobre todo, si queremos promover un ambiente de autonomía y creatividad, demos los elementos básicos y dejemos que los equipos se apropien. Lo que no significa dejarlos a la deriva. Se puede explícitamente pedirles que determinen un plan, tal vez con un presupuesto básico y posibles extensiones iterativas.

Varias veces vi que se diseñan espacios incluyendo áreas de "esparcimiento" para los equipos, donde se incluyen equipos de videojuegos, mesas de ping-pong o instrumentos musicales. Pero este nuevamente es per-determinar qué es lo que ellos querrán, en lugar de preguntarles. Tal vez terminen poniendo la consola de juegos, pero ellos elegirán cuál prefieren y cómo instalarla. O tal vez prefieran otra cosa, como un espacio para cocinar o para hacer yoga.

En definitiva, al pensar espacios ágiles, tenemos que mantener sus principios: flexibilidad, transparencia, diversidad.

Si alguno tiene interés en compartir los espacios que generaron, pueden mandarme fotos, y veo cómo compartirlas.

 

martes, 5 de mayo de 2015

Story Mapping: de la Incepción hacia el Backlog de Producto

Tiempo atrás publiqué una serie de artículos sobre la práctica de Incepción Ágil que tuvieron bastante éxito y generaron varios comentarios y preguntas, entre otras, acerca de otra práctica relacionada, que a veces algunos incluyen como parte de la Incepción: User Story Mapping.

Esta técnica para analizar un proyecto (completo o un sub-proyecto) fue nombrada y documentada originalmente por Jeff Patton, primero en un artículo de su blog, y posteriormente en su libro "User Story Mapping" (pueden ver la tapa a la derecha), ambos inmensamente recomendables.

Conocí los detalles de esta práctica por primera vez alrededor de 2008 o 2009, y comencé a usarla en algunos proyectos míos o de organizaciones a las que estaba ayudando, y después de usarla al menos una docena de veces, comprendí mejor cómo aprovecharla y cómo facilitar su construcción, y se convirtió en una pieza clave para mi en el inicio de proyectos ágiles.

Lo que quiero hacer en este artículo es recorrer qué es un Story Map, cómo se genera, cómo se usa posteriormente y cuáles son sus beneficios. En algunos posteriores entraré en detalle sobre la mecánica de la reunión, las alternativas y conceptos subyacentes.

¿Cómo y cuándo?

Trabajando en conjunto

Como en el caso de la Incepción Ágil, el Story Mapping se realiza al inicio de un proyecto, o una nueva fase, típicamente en formato taller. Algunas veces se realiza como parte final de la Incepción, aunque para mi es bueno entenderlo como momentos diferentes.

La Incepción trata de poner el foco en asegurar que todos los involucrados acuerdan un objetivo común, ciertas características y restricciones del producto, y deciden en conjunto qué van a construir.

Story Mapping es una actividad que nos permite entrar en detalle estratégico sobre cómo construirlo, entender qué es lo fundamental, poner foco en la entrega temprana y entender cómo ir incrementando el valor frecuentemente.

Lo que tienen en común ambas prácticas, que para mi son complementarias, es el tipo de convocatoria: en ambos casos queremos contar durante toda la actividad con gente de negocios a nivel directivo y a nivel operativo, operaciones, procesos, infraestructura, desarrollo, seguridad, etc. Queremos tener representados a la mayor cantidad posible de sectores involucrados en el proyecto del que vamos a hablar, para tener una perspectiva amplia.

También, como en el caso de la Incepción, más allá del entregable (el Story Map) lo más valioso son las conversaciones durante el ejercicio. No deja de sorprenderme al facilitar encuentros de este tipo en diferentes organizaciones (desde micro-emprendimientos hasta corporaciones) cómo surgen discusiones que nunca se habían tocado antes a pesar de estar trabajando en el tema en cuestión durante muchísimo tiempo.

Dependiendo de la complejidad y la importancia del proyecto, la actividad puede durar desde 2 o 3 horas, hasta un día completo. En proyectos críticos he facilitado frecuentemente un día completo de Incepción y otro día completo de Story Mapping.

Entre uno y otro puede pasar un tiempo, porque a veces la Incepción sirve para confirmar qué tipo de proyecto tenemos que realizar (cuanto más temprano la hagamos, mejor, porque tenemos menos cosas decididas de antemano), y podemos tomarnos un tiempo para tener identificado al equipo de trabajo y saber quiénes deberían estar presentes para construir el Story Map.

 

¿Qué queremos lograr?

En los próximos artículos voy a entrar en detalles, pero para cerrar éste, quiero mostrar el resultado final y explicar cuál es la expectativa.

Story Map final

 

La imagen muestra un mapa de un proyecto real. La imagen no tiene nitidez suficiente para leer lo que está escrito en las notas, que es algo específico y particular de este proyecto, pero que no importa para explicar el resultado.

Lo que se ve en la primer fila, en las notas celestes, como cabeceras de cada columna, son las Actividades Principales del proyecto, en el orden en que fluyen en "la historia" contada por los diferentes participantes de la actividad. Hacia abajo de cada Actividad hay Detalles sobre cómo se realiza esa actividad, en muchos casos como alternativas o pasos que pueden ser o no opcionales.

Las líneas azules que cortan transversalmente el mapa (en dos tajadas finas, inicialmente) son las Entregas planificadas, cada una con el mínimo de funcionalidad necesaria para cumplir con el propósito de la solución. Como puede notarse, esas dos primeras entregas son muy pequeñas respecto al total del alcance esperado (el conjunto total de notas debajo de los encabezados celestes). Sin embargo, las dos entregas planificadas concentran el más alto valor de negocio, porque destraban problemas importantes y habilitan nuevas posibilidades. Esto suele suceder en casi todos los proyectos, siguiendo la ley de Pareto: aproximadamente el 20% del alcance da el 80% del valor de negocio de un proyecto.

Utilizando esta práctica, que detallaré más en los próximos artículos, podemos buscar ese mítico 20% y tratar de concentrarnos en tener el más alto valor rápidamente, que además nos permitirá tener un producto real funcionando y poder aprender de la experiencia concreta antes de seguir agregando funcionalidad en abstracto.

Actualización: podés encontrar el siguiente artículo de esta serie aquí.

viernes, 1 de noviembre de 2013

Agile Solo: Manejando el backlog personal

Agile Solo - Backlog

Continuando con la serie Agile Solo, hoy quería comentar algunas ideas para manejar el backlog de tareas y mejorar el nivel de compromiso de uno mismo hacia sus clientes o usuarios.

Una buena práctica para no dejarse tentar por la procrastinación es utilizar alguna herramienta para hacer público nuestro backlog. Como siempre, desde la agilidad le damos prioridad a la interacción entre las personas, por lo que prefiero concentrarme en cómo me comunico, y usar las herramientas más sencillas posibles (en particular me gusta Trello por que es liviano y su funcionalidad es mínima).

Lo importante para mi del backlog es tener donde volcar las clásicas tres columnas: pendiente, en marcha y terminado. Y lo bueno de tener una manera de hacerlo público es que podemos mostrar a las personas involucradas qué planificamos (por ejemplo, para la semana) y cómo vamos. Es posible que tengamos que unificar temas de varios clientes, y puede haber algunos relativamente confidenciales, para lo que prefiero usar nombres de código para los proyectos. De esta manera, cada cliente sabe el nombre de código, y puedo usarlo como “etiqueta” en mi backlog, sin divulgar identidades, preservando su confidencialidad. De la misma manera, no necesito poner detalles demasiado específicos de la tarea pendiente; alcanza con que ponga algo que mi cliente comprenda. Veamos un ejemplo:

Backlog

Algunos tips sobre los nombre de código que me resultan útiles:

  • No hacen falta para cosas no-confidenciales (en mi ejemplo, C&B para este blog, MUG, nombres de amigos)
  • Conviene usar nombres que no signifiquen nada y que no tengan ninguna connotación. 
  • Es bueno tener a mano una serie de muchos nombres disponibles. Yo elijo, por ejemplo, nombres astronómicos (estrellas, planetas o satélites) porque hay miles y usualmente no acarrean ningún significado especial. En otros casos utilicé nombres de ríos, pájaros, flores o plantas, frutas, etc. Google utiliza nombres de dulces para Android, Ubuntu animales más un adjetivo, etc.
  • Lo importante es que el cliente reconozca SU proyecto (en el ejemplo, Fobos y Deimos son proyectos de clientes diferentes).

Obviamente exponer nuestro backlog plantea desafíos, pero yo creo que son sanos. Por ejemplo, el cliente de mi proyecto Fobos podría reclamarme prioridad sobre Deimos, aunque no sepa quien es. Eso nos obliga a ser transparentes, pero también a poder explicar racionalmente nuestra priorización, y el problema se termina si al final de cada iteración todos están conformes. También, aunque no hayan gran nivel de detalle en cada item del backlog, lo que hacemos para un proyecto puede inspirar ideas a otros clientes, y no está mal que esto pase.

Hay otras alternativas, por supuesto, como tener backlogs separados por cliente, donde cada uno vea su parte. En mi experiencia esto nos complica más de lo que nos ayuda, porque oculta la complejidad de nuestras actividades, y hace sentir a cada cliente que trabajamos solamente para él (lo que no está mal si es real).

Como siempre, hay cosas que dependen del nivel de madurez, pero en general yo prefiero que quien actúa de Product Owner en mi cliente tenga acceso a mi backlog y pueda poner todo lo que quiera. ¿Me arriesgo a que cambien prioridades? Si, pero prefiero siempre brindar más libertad y pedir responsabilidad que tratar de controlar. :)

Espero que algunas de estas ideas sirvan aunque sea para cuestionarlas y generar prácticas alternativas.

miércoles, 30 de octubre de 2013

Nuevo sitio: Scrum Masters Community (+ video)

 

El amigo Tobias Mayer, pionero en dictar los talleres de Certified Scrum Master en Argentina, y un combatiente de la metodologías ágiles y Scrum en particular (incluso dando lucha desde adentro de la Scrum Alliance en su momento) lanzó recientemente un muy buen recurso para la comunidad de Scrum: un sitio web llamado scrummasters.community.

En el sitio se pueden encontrar libros, sitios y otros recursos recomendados por la comunidad de Scrum Masters en general, incluyendo algunos comentarios.

Es una especie de catálogo comunitario de recomendaciones, sencillo y útil.

Aprovecho el post para recomendar especialmente el último libro de Tobias, The People’s Scrum, que recopila los mejores artículos de Tobias en los últimos años, y no trata de explicar Scrum, sino que reflexiona sobre el espíritu, sobre el paradigma y las condiciones que estas prácticas crean, y a sus veces requieren.

Les dejo un video corto (~7 minutos; en inglés) de Tobias charlando en un evento sobre Scrum más allá de software.

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, 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!):

viernes, 10 de agosto de 2012

Próxima reunión de Ágiles@Buenos Aires

Carlos Peix

El grupo Ágiles Argentina anunció la próxima reunión mensual de Buenos Aires para el próximo miércoles 15 de agosto (la semana próxima) de 18:30 a 20:30.

Como siempre, la registración a este evento gratuito es a través de Meetup, y el evento es esta vez en el auditorio del MUGRivadavia 1479 1er Piso.

El tema de esta sesión se llama "¿Cómo escribirías tu código si debe funcionar al primer intento?", y estará facilitado por mi amigo y colega de Kleer, Carlos Peix.

Carlos describe su propuesta así:

Ya pocos discuten las ventajas de diseñar nuestro código basándonos en ejemplos (pruebas). TDD ha llegado a nuestra profesión para quedarse. También muchos de ustedes conocerán los coding dojos, ya sea por comentarios, ya sea por referencias.

En esta ocasión me gustaría invitarlos a un coding dojo en el cual intentaremos movernos fuera de la zona de confort para un desarrollador que utiliza TDD: diseñar y escribir nuestro código sin ejecutar un solo test. Para hacerlo más interesante, agregaremos otra condición: el código debe ejecutar correctamente en el primer intento.

No hay trampas, lo lograremos, aunque parezca difícil. Una vez que conozcamos el otro extremo de TDD, nuestro panorama cambiará, o al menos, el mio cambió.

Esta idea tomo forma mientras leia este post, lo que haremos es muy similar pero con la kata Wincofon, inventada con el gran @MartinSalias hace unos cuantos años. 

Como verán, soy un poco pig en esta sesión, aunque no podré asistir por otros compromisos. 

Si quieren ver a Carlos en acción, pueden ver este video con el que inauguramos la serie de programación de a pares en este blog, que espero retomar en breve.

lunes, 30 de julio de 2012

Agiles 2012: 24 al 26 de octubre en Córdoba, Argentina (+ fotos)

NewImage

Como todos los años desde la primer edición en 2008, se acerca la conferencia latinoamericana de metodologías ágiles.

Este año la cita es en la ciudad de Córdoba, más específicamente en la Universidad Tecnológica Nacional, del miércoles 24 al viernes 26 de octubre.

En esta 5ta edición, que se realiza por segundo año consecutivo en Argentina (las anteriores fueron 2008 en Buenos Aires; 2009 en Florianópolis, Brasil; 2010 en Lima, Perú; y 2011 nuevamente en Buenos Aires), se mantendrá la agenda mixta de sesiones, talleres y open space, y también vendrán visitantes de diferentes partes del mundo.

Para mi personalmente este año será especial ya que tendré el honor de dar una de las keynotes, compartiendo esa responsabilidad con David Hussman de DevJam.

El llamado a ponencias de la conferencia cerró hace poco, y estimo que en pocos días estará disponible la primer versión del programa, que como siempre va apareciendo como un proceso "iterativo e incremental".

Como no encontré vídeos de la conferencia del año pasado (seguiré buscando), les dejo un video-collage con imágenes de la edición de 2010 en Lima, para que se den idea del ambiente que se vive en estos encuentros.

lunes, 16 de julio de 2012

Agile Open Buenos Aires - Educando y Aprendiendo

NewImage

Ágiles Argentina organiza este evento de difusión e intercambio de experiencias sobre el proceso de Educación y Aprendizaje.

Es parte del continuo Agile Open Tour que la comunidad local organiza desde hace hace años, recorriendo el país.

Como todos los Agile Open, este evento tiene formato Open Space, y en esta ocasión se unirán algunas técnicas nuevas como Training from the Back of the Room, actividades disparadoras y facilitadoras del aprendizaje, experiencias en la planificación de contenido auto-organizada, educación a distancia, y lo que proponga el público.

Como en todo los casos, el evento es gratuito pero requiere inscripción previa, y se realizará el sábado 4 de agosto, de 9 a 18 horas en la UNTREF, Sede Centro Cultural Borges, Viamonte esq. San Martín piso 3. Hay más información y una agenda preliminar de espacios.

Tomado directamente de la página de difusión del evento:

Los eventos Agile Open se originan en Bélgica en el 2005 pero se realizan en todo el mundo. El primero en Latinoamérica se realizó en Buenos Aires en marzo del 2009. En el país ya se han realizado cerca de 25 eventos en 8 ciudades (Buenos Aires, Córdoba, Tandil, La Plata, Bahía Blanca, Mar del Plata, Rosario y Paraná) con temas tales com Educación, Organizaciones Flexibles, Seguridad, Software Libre, Calidad y Arquitectura. Los eventos Agile Open se organizan y realizan usando Open Space Technology.

Open Space Technology

Esta forma de organización de eventos permite con relativamente poca preparación previa realizar eventos de alta calidad en forma auto-organizada. Funciona para reuniones desde 5 personas hasta reuniones de varios miles de personas.
Es particularmente apto para encuentros en los que se discuten temas que son relevantes, complejos y que los asistentes tienen interés y pasión por tratar.
El interés y la pasión se logra por un proceso de autoselección en la registración: ya que una vez definido el Tema de la conferencia, los asistentes a los que les interesa el tema se anotarán, y al ser en un día no laboral, no dependen tanto del interés de las empresas en las que trabajan como en su deseo personal de participar. A su vez, los temas a tratar en cada sesión son propuestos y votados por los asistentes.

La dinámica durante el evento es:

Se explica el formato y sus pocas reglas
Los asistentes proponen sesiones (presentaciones, paneles, workshops, ...)
Votación de sesiones (todos los asistentes votan)
Armado de agenda (se asignan las sesiones votadas a los horarios y aulas)
Se realizan las sesiones.
Cierre

Auspician el Tour: Kleer (quienes sortean 16 lugares para curso de un día: "Introducción a Scrum" o "Estimación y Planificación con Scrum") e Inicia.

viernes, 13 de julio de 2012

Aprendiendo y enseñando: Principios SOLID (+video)

NewImageLos amigos de Kleer siguen impulsando actividades gratuitas de todo tipo, como sus ya tradicionales Yoseki Coding Dojo, a los que ahora se suman estas sesiones que llaman "Aprendiendo y enseñando", en las que el "pago" simbólico de los asistentes es enseñar a otros lo aprendido en el grupo.

La idea es que cada uno multiplique el conocimiento adquirido en su empresa, grupo de usuarios, blog, vídeos, etc, siguiendo técnicas surgidas del libro "Training from the back of the room", según Fernando Claverino comentaba en este post.

De la primer sesión que efectuaron el mes pasado (espero poder avisar a tiempo de la próxima), sobre principios SOLID algunos de los participantes se conjuraron para publicar ejemplos en sus blogs.

Al menos han cumplido hasta ahora Nelo Pauselli y Fernando (uno de los organizadores de la sesión junto al amigo Carlos Peix). La sesión inicial estuvo basada en ejemplos publicados en http://solidexamples.codeplex.com/, y posteriormente Nelo y Fernando publicaron sus ejercicios de cómo resolver un ejemplo que viola el Principio de Responsabilidad Unica (Single Responsibility Principle).

Para quienes quieran más detalles sobre SOLID, pueden ven una Virtual Alt.NET Meeting de Carlos Peix sobre el tema, o leer sobre estos directamente de la fuente, Uncle Bob Martin.

 

Finalmente, pueden ver los pasos que aplicó Fer en su blog, y les dejo debajo el video con Nelo refactorizando el ejemplo en vivo, pero pueden leer más detalles en su post.

 

Unable to display content. Adobe Flash is required.

martes, 3 de julio de 2012

Video: BDD, por Jorge Gamba, desde el Campus Party Colombia

NewImage

Campus Party es un enorme evento de tecnología que se realiza en diversas partes del mundo, cubriendo muchas facetas de la vida digital, incluyendo desarrollo de software.

La semana pasada se realizó la quinta edición de este evento en Colombia, en la ciudad de Bogotá, y nuestro amigo Jorge Gamba, incansable organizador de las actividades de Alt.NET Hispano, estuvo allí haciendo una presentación excelente sobre Behavior Driven Development, uno de sus temas predilectos.

Dejo para ustedes el video debajo (~56 minutos, en español) para que lo disfruten, y pueden leer muchos más detalles en su propio post sobre la sesión. Debajo del video dejo también sus slides para quienes quieran verlos en más detalle (en el video se aprecian bastante bien, de todas maneras).

Slides:

miércoles, 22 de febrero de 2012

Video: Agiles @ Buenos Aires - Caso de éxito ágil, por Pablo Francavilla

Agiles

En la última reunión mensual de Agiles Buenos Aires, organizada por la comunidad local aproximadamente los segundos martes de cada mes, Pablo Francavilla vino a contarnos los detalles de un caso de éxito para su compañía, GetSense, pero fundamentalmente una experiencia enriquecedora desde el punto de vista de las técnicas que utilizaron.

Una de las claves en este caso, para Pablo, fue la utilización de Story Mapping, una técnica para la definición del producto de manera colaborativa, utilizando un esquema visual con post-it de colores en una pared o mesa, entre todos los participantes: clientes, equipo y cualquiera de importancia en el contexto del proyecto.

Pablo destacó que aprendieron lo básico sobre esta técnica en una reunión prevía de Agiles @ Buenos Aires, lo que también es una referencia interesante en si misma.

La sesión completa, como siempre, llevó casi 120 minutos, y está dividida en 7 partes de unos 17 minutos cada una. Queda a continuación el primer video embebido, y los enlaces a los siguientes debajo. Sepan disculpar mis movimientos un tanto torpes como camarógrafo en los primeros minutos, pero el movimiento del público hacia un lado de la sala al iniciar la sesión me tomó por sorpresa.

Parte 2 de 7

Parte 3 de 7

Parte 4 de 7

Parte 5 de 7

Parte 6 de 7

Parte 7 de 7

martes, 6 de diciembre de 2011

Global Day of Coderetreat

conways-sql

El pasado sábado 3 tuvo lugar el Global Day of Coderetreat, un evento que aglutinó a 2200 desarrolladores en 90 locaciones alrededor del mundo. El raid comenzó en la costa este de Australia y culminó en la costa oeste de América.

Coderetreat

Un coderetreat es un evento en el que programadores realizan una práctica intensiva, generalmente de un día de duración, focalizando en los fundamentos del diseño y desarrollo. Suelen resolverse problemas sencillos (un clásico es el Juego de la vida de Conway) en un entorno en el que solo es importante aprender, sin las presiones día a día. Mas información aquí [inglés].

Por supuesto, cualquiera que lo desee puede organizar un coderetreat, mas información aquí y aquí, ambos en inglés.

Mas allá de la lectura de libros, papers, listas de discusión y artículos especializados, el verdadero aprendizaje en el que el desarrollador mejora sus habilidades esta en la práctica. Esto es lo que motiva el coderetreat (o coding katas y coding dojos).

En Buenos Aires

La edición de Buenos Aires tuvo lugar en las oficinas de Kleer, organizada por el anfitrión con la colaboración y apoyo de Kinetica Solutions y 10Pines.

El resultado fue muy interesante. Participaron desarrolladores de distintas tecnologías (Cobol entre ellas) y los asistentes intercambiaron entornos de programación: Ruby, .NET, Java y hasta Transact-SQL. Este último caso (en la imagen que ilustra este post) fue el mas llamativo no solo por el entorno inusual de desarrollo, también porque fue el único que logro llegar a una implementación funcional.

Todos los presentes, invariablemente y en cada una de las iteraciones de trabajo, reportan haber aprendido algo nuevo. Esto es característico de la práctica relajada, libre de presiones.

A quien este interesado en este tipo de eventos recomendamos asistir a los Yoseki Coding Dojos gratuitos organizados por Kleer el primer miércoles de cada mes.

 

miércoles, 9 de noviembre de 2011

Video: Arquitecturas y Organizaciones, por Diego Fontdevila (+ invitación)

Diego Fontdevila

Comparto con ustedes otros de los vídeos de la reciente Jornada de Arquitectura de Software organizada por el MUG en UADE. Esta vez le toca el turno a Diego Fontdevila y su sesión sobre las similitudes y ecos entre las arquitecturas de software y las organizaciones que las construyen o mantienen.

Diego es uno de los socios fundadores de Grupo Esfera, una empresa dedicada a consultoría, desarrollo y capacitación con fuerte foco en la plataforma Java y otras tecnologías de software libre. Diego también es docente en la UBA, UNTREF y UNLAM, y está estudiando en el programa de Software Engineering Management de Carnegie Mellon y el SEI.

Nos conocimos durante Agiles 2008, la primer edición de las jornadas latinoamericanas, y nos hicimos amigos a través de los años y las actividades conjuntas en torno a esta comunidad. Tuvimos la oportunidad de colaborar en algunos proyectos e incluso publicamos juntos un paper sobre arquitectura y métodos ágiles que también presentamos varias veces, siempre agregando detalles.

En esta sesión Diego habla sobre la relación entre las formas de las organizaciones y las estructuras tecnológicas que engendran, y cómo es altamente improbable poder quitarles la impronta que una impone a la otra, aportando visiones de diferentes disciplinas e ideas de varios autores y vertientes. La sesión da para un intenso debate o mas participación, y para eso Diego va a repetirla la semana próxima en la próxima reunión de Agiles @ Buenos Aires. Como siempre, este evento es abierto y gratuito, pero requiere registro previo.

Les dejo el video, en 4 partes de 15 minutos aproximadamente.

martes, 1 de noviembre de 2011

Video: Equipos Agiles Distribuidos, por Ariel Schapiro

Ariel Schapiro

En la reunión de septiembre de Agiles en Buenos Aires (tomó un tiempo publicar el video, pero finalmente llegó), Ariel Schapiro presentó esta sesión sobre cómo manejar equipos ágiles en contextos distribuidos, algo que hacemos frecuentemente en Southworks, la empresa en la que ambos trabajamos.

Ariel recorrió una serie de desafíos particulares de mantener un enfoque fuertemente iterativo y basado en la comunicación en un contexto de miembros remotos, y comentó muchas de las prácticas que encontramos para minimizar el impacto de la distancia, mapeando los riesgos principales y trabajando preventivamente en minimizarlos.

Pueden ver los slides de Ariel en slideshare.

Todavía no está anunciada la fecha y el tema de la reunión de noviembre, pero en cuanto tenga novedades estaré comunicándolas en este blog.

 

A continuación, el primer segmento de la sesión. Si quieren verla completa, dejo debajo los links a las 5 partes.

Parte 1 - Parte 2 - Parte 3 - Parte 4 - Parte 5

viernes, 7 de octubre de 2011

¡Agiles 2011 la próxima semana!

Ágiles 2011Finalmente llega el evento que viene organizándose desde el cierre de Agiles 2010 en Lima, Perú.

Nuevamente en Buenos Aires, en la Universidad de Palermo (Mario Bravo 1050, esquina Córdoba), y desde el martes 11 al jueves 13 de octubre, llega 4ta edición de la conferencia latinoamericana de metodologías ágiles.

Este año serán dos días con más de 50 presentaciones y talleres, más un día completo de Open Space.

Pueden ver el programa completo del día 11, el día 12, y el esquema de tiempo del 13, aunque recuerden que el Open Space no tiene programa porque las actividades se proponen y diagraman en el momento, por la audiencia misma.

La conferencia contará con keynotes plenarias los tres días a cargo de personalidades destacadas como:

Jeff PattonJeff Patton (el día 11 a las 9:30)

Jeff se especializa en la aplicación de técnicas de diseño centradas en el usuario para mejorar los requerimientos, planificación y productos. Algunos de sus escritos más recientes en la materia pueden encontrarse en www.AgileProductDesign.com y en el libro de Alistair Cockburn “Crystal Clear”.

Su libro de inminente lanzamiento dentro de la serie Agile Development de Addison-Wesley brinda consejos tácticos para quienes buscan entregar software útil, fácil de usar y valioso.

Su sesión plenaria (en inglés) se titula: “Us, them, and the problem with common agile practice”, y se enfoca en el establecimiento de un vocabulario y conceptos comunes sobre el valor de negocio que minimicen la distancia entre el equipo construyendo la solución y los clientes o usuarios que son destinatarios, facilitando el diálogo.

Jeff dictará también durante la conferencia un taller de 4 horas titulado “Product Discovery with User Story Mapping”.

James ShoreJames Shore (el día 12 a las 9:30)

James es uno de los líderes de la comunidad de desarrollo de software ágil.

Orador popular sobre estos temas y ha aparecido en muchas publicaciones de la industria incluyendo IEEE Software, SD Times, y Better Software. Su trabajo es referenciado frecuentemente en la prensa y su blog  Art of Agile está frecuentemente entre los primeros veinte recomendados en AgileDaily. También es co-autor de The Art Of Agile Development (O’Reilly, 2007).

Su sesión plenaria (en inglés) se titula “Agile, Past and Future” y se enfoca en los diez años transcurridos desde la firma del Manifiesto Ágil, y en base al pasado reflexiona sobre el estado actual de la práctica y los desafíos de las metodologías y la comunidad de aquí en adelante.

James dictará también durante la conferencia un taller de 4 horas titulado “Agile Product Management”.

Juan Gabardini (el día 13 a las 17:00)

Juan es uno de los iniciadores de la comunidad ágil local, y uno de los motores principales de las conferencias Ágiles y el Agile Open Tour de Argentina. Juan es Ingeniero Electrónico y Licenciado en Sistemas egresado de FIUBA, miembro del IEEE, SADIO, Scrum Alliance, Agile Alliance, Kleer Latinoamérica y Jefe de Trabajos Prácticos en FIUBA, con más de 10 años de docencia universitaria y más de 20 de experiencia en desarrollo de software, enseñanza y consultoría.

Su sesión plenaria será en español, previa al cierre del evento, y se titula “Equipos pequeños y comunidades de práctica”, y trata sobre los beneficios y desafíos que enfrentan los equipos pequeños con miembros que tienen poca experiencia, el manejo de la complejidad tecnológica, las dinámicas grupales, la innovación y las comunidades de práctica.

 

Este es un evento para no perderse, con figuras internacionales, locales, enormes oportunidades de contacto con la comunidad local, colegas, empresas y consultores, y abundante contenido en español, inglés y portugués.

Hay que apurarse ¡antes de que cierre el registro, o se acaben los lugares!

martes, 13 de septiembre de 2011

Video: Programando de a pares con Emilio Gutter

Emilio Gutter

En esta nueva sesión de programación de a pares me sumo a Emilio Gutter para hacer un ejercicio utilizando Java.

Conocí a Emilio a fines del 2006 cuando fuimos compañeros de equipo durante el curso de Certified Scrum Master dado por Tobias Mayer. Nos divertimos mucho durante ese curso, y varios de los que pasamos por ahí nos mantuvimos en contacto después a través de una primer lista de distribución que fue uno de los puntos focales de donde surgió el grupo de organizadores de la primer conferencia de la serie Ágiles: Ágiles 2008.

Emilio lleva más de 10 años trabajando en desarrollo de software y es un desarrollador trotamundos que ha trabajado en proyectos en Argentina, Brasil, UK, USA, Francia, Rumania y Bulgaria, por lo menos. Actualmente es uno de los líderes de su consultora 10pines, que brinda servicios de desarrollo, entrenamiento y coaching, con fuerte foco métodos ágiles, incluyendo un alto compromiso con la calidad y la cultura organizacional.

En el video podrán ver cómo hacemos un ejercicio de diseño en Java, usando Eclipse con JUnit 4 y la biblioteca de mock objects mockito y planeábamos utilizar también harmcrest,una biblioteca de matchers (o predicados) muy útil para realizar aserciones en las pruebas unitarias, pero no alcanzó el tiempo esta vez, así que quedará para más adelante.

Les dejo el video (de aproximadamente 25 minutos) y espero que lo disfruten:

jueves, 18 de agosto de 2011

Scrum Guide 2011 en español (+ video en inglés)

Jeff Sutherland (arriba) y Ken Schwaber (abajo)Recientemente Scrum.org, la organización detrás de la difusión de la metodología, publicó la versión actualizada de la guía escrita originalmente por Jeff Sutherland y Ken Schwaber y revisada este año: Scrum Guide 2011.

En la misma página se encuentran disponible traducciones de la guía a muchos idiomas, incluyendo la versión en español (PDF, versión del 2010).

Para quienes no conocen más que lo anecdótico de Scrum, dejo un brevísimo resumen de este framework que se basa en tres pilares:

  • Transparencia
  • Inspección
  • Adaptación

El equipo de Scrum está compuesto por:

  • El Product Owner (PO, dueño del producto), que se ocupa de maximizar el valor del producto y el trabajo del equipo de desarrollo. Por eso es el responsable principal del Backlog de producto, y debe asegurarse que esta lista está siempre priorizada, de manera que nadie trabaje en lo que no es la máxima prioridad en cada momento.
  • El Equipo de Desarrollo es el grupo que se encarga de entregar incrementalmente un producto funcional al fin de cada Sprint (iteración). La guía agrega un poco más de detalle incluyendo la composición y tamaño.
  • El Scrum Master se encarga de que las reglas y principios de Scrum se mantengan y de que los bloqueos potenciales se eviten o eliminen cuanto antes. La guía detalla un poco más los servicios que el Scrum Master proporciona al PO, al Equipo de Desarrollo y a la Organización.

Los eventos de Scrum son:

  • El Sprint (o iteración) durante el que el compromiso asumido por el equipo y consensuado por el PO no debe cambiar, y se ejecuta manteniendo el orden de prioridad para el negocio, de manera de que al terminar el límite de tiempo impuesto (entre una semana y un mes) lo que quedó completo e incluido en el incremento de producto es siempre lo más importante. Dentro del Sprint se producen:
    • La planificación del Sprint, en el inicio, donde el Equipo y el PO acuerdan el compromiso para la iteración, tomando los ítems de máxima prioridad en el Backlog de Producto, en orden descendente, hasta donde el equipo estima que puede terminar dentro del límite de tiempo.
    • El Scrum Diario (o stand-up), donde el equipo se reúne (de pie, para evitar prolongar la reunión más de unos minutos) y cada miembro del equipo expone:
      • Qué terminó desde el último stand-up
      • Qué planifica terminar antes del próximo stand-up
      • Qué obstáculos puede llegar a tener (y que el Scrum Master deberá evitar que bloqueen al equipo)
    • El Sprint Review, en el que el equipo muestra el resultado del trabajo al PO y los interesados que éste considere apropiado para ayudarlo a continuar ajustando el Backlog de producto.
    • La retrospectiva en que el equipo reflexiona sobre la manera en que se desarrolló el trabajo, teniendo en cuenta relaciones, técnicas, herramientas y demás, y determina algunas medidas para mejorar en el siguiente Sprint.

Los artefactos de Scrum son muy pocos:

  • El Backlog de Producto, que el PO se encarga de construir y mantener priorizado en base al valor para el negocio a través del tiempo.
  • El Backlog del Sprint, que el Equipo y el PO determinan al comienzo de cada Sprint y cuyo seguimiento determina el nivel de avance dentro del Sprint.
  • El Incremento de producto es la entrega que el equipo realiza a final de cada Sprint, y que debe ser funcional desde el inicio, de manera que esté potencialmente en condiciones de usarse y agregar valor.

En la guía terminan volviendo a la importancia de la definición de cuándo una tarea está “terminada”, lo que debe convertirse en un contrato entre el Equipo, el PO y la Organización, de manera de ajustar las expectativas y evitar discusiones y problemas al respecto.

La guía amplía un poco este resumen, pero sólo tiene 17 páginas, incluyendo algunas con índice, historia, agradecimientos, etc. El framework es muy sencillo de describir, lo que no implica que sea fácil de implementar. Suele decirse que se parece en eso a un deporte: las reglas son sencillas, pero ser un buen jugador es típicamente un gran desafío y el secreto está en la práctica y la dedicación.

Video

Como final, dejo este video de una charla de Schwaber en el 2006 dentro de las oficinas de Google, que me parece que explica bien muchos de los principios, y aunque está en inglés, vale la pena escuchar esto desde uno de sus iniciadores.

miércoles, 17 de agosto de 2011

Video: Agiles @ Buenos Aires–Lean Startup, por Fernando Parra

Ágiles 2011El pasado 19 de julio el grupo Agiles.org de Buenos Aires realizó su ya tradicional reunión mensual, y en esta oportunidad el facilitador fue Fernando Parra (de MicroStrategy), quien contó un poco sobre los conceptos de emprendimiento alrededor del modelo Lean Startup, más basado en el foco en el diseño de producto y en el piloto inicial empujado por los mismos emprendedores más que el clásico modelo de buscar inversores para desarrollar una idea.

Este estilo de desarrollo de negocios está muy basado en una mezcla de métodos ágiles, software gratuito de código abierto, iteraciones cortas y extremo foco en el cliente final.

Algunos links adicionales:

Y como personalmente no pude quedarme a la sesión, agrego las notas tomadas por mi amigo Ricardo Colusso:

La presentación se centró en emprendimientos de desarrollo de producto.

¿Porqué muchos emprendimientos fallan? Algunas razones: Optimismo infundado, foco 100% en el producto antes que pensar en quienes lo van a usar, resultado: el producto no encuentra mercado.

Proceso propuesto: Concepto de producto mínimo viable (MVP). Por ejemplo el primer teléfono de Apple que no permitía copiar y pegar.

Ver http://pathfindersoftware.com/2011/01/exploring-customer-validation/

Hablamos del Lean Canvas: http://leancanvas.com/ - Forma Lean de presentar información de startups.
Puede bajarse gratis y usarlo/adaptarlo a lo que necesitemos (licencia Creative Commons)

La charla luego de la presentación fue por el lado de pensar cuan útil es un plan de negocios para un Llean Startup. Si quiero un subsidio de algún organismo oficial seguro que necesito hacer un plan de negocios, pero se habla de que probablemente me convenga no pedir plata y arreglarme inicialmente con lo que tenga. Se habla también sobre "burbujas" (como las punto com en 2001) que son vistas como oportunidades en el momento, pero que no tienen un sustento firme a nivel ganancias por cliente nuevo obtenido. Después estuvimos analizando en más detalle en que consiste el lean canvas, y encaramos un caso específico.

Nombres y fuentes de información mencionadas en la sesión:

Agradezco a Rick por las notas y les dejo la serie de videos (5 en total, cubriendo unos 80 minutos). Los últimos 10 minutos de la parte 5, aproximadamente, quedaron ocupados por el inicio de una actividad posterior que no tuve oportunidad de editar.