28 de junio de 2012

26 de junio de 2012

Retrotip #6


Un experto...

"Un experto es una persona que ha cometido todos los errores posibles en un dominio muy acotado." - Niels Bohr (Físico Danes, Premio Nobel) 

25 de junio de 2012

Quinta Reunión de la Comunidad Ágil de Neuquén (Kanban)


Próxima Reunión de Comunidad Ágil de Neuquén

CuándoMiércoles 4 de Julio del 2012, a las 18h
Dónde: Salón Azul del la Biblioteca Central - Universidad Nacional del Comahue - Buenos Aires 1400, Neuquén 
Tema: Kanban

Kanban es un mecanismo japonés ancestral de visualización de información. Fue adaptado en distintas industrias en Japón y en particular en la industria automotriz en el famoso Toyota Production System a mitad del siglo pasado. Hace años se empezó a aplicar en proyectos de Tecnología de la Información y aparece como una evolución y/o complemento de algunas metodologías ágiles.
Es uno de los temas "hot" que hace ruido en los círculos de ingeniería de software y de metodologías ágiles. 

En este encuentro Milena y Thomas contarán qué es Kanban y cómo se implementa. Luego veremos un  caso de aplicación real, y en particular aspectos de diseño del tablero, combinación con otras practicas agiles, integración con la norma ISO, etc.

Facilitadores: Milena Armada y Thomas Wallet

La reunión es gratuita, solo hay que inscribirse a través del siguiente link.

21 de junio de 2012

18 de junio de 2012

5ta Edición del Curso Online de la UTN de Metodologías ágiles para el Desarrollo de Software

El próximo 4 de Julio del 2012 iniciará la 5ta edición del curso online de la UTN sobre Metodologías Ágiles para el Desarrollo de Software, en el cuál soy professor, junto con Ulises Martin y Hernán Ricchio.

El curso está diseñado para adquirir una visión introductoria pero integral en las practicas más reconocidas de gestión de proyectos de desarrollo de software, tanto del enfoque predictivo como del enfoque ágil. Permite conocer las distintas técnicas y sus diferencias para poder elegir y combinar las practicas de gestión más eficientes según el contexto del proyecto.

Más información e inscripciones en este link.

Algunos comentarios de alumnos de ediciones anteriores:

"El curso online de la UTN fue mi primer contacto con las metodologías ágiles. Pasó un año y ahora estoy trabajando todos los días con metodologías ágiles y muy metido en la comunidad ágil y sus eventos." (Juan)
"Quería agradecerles y felicitarlos porque el curso estuvo muy bueno, la documentación muy práctica y amigable." (Lucas) 
"Me gustaron los debates que se generaron en los foros, cada uno aportando desde su contexto y experiencia personal." (Fernanda) 
 "Ya estamos implementando scrum con algunas de las practicas de XP y trataremos de implementar kanban a los procesos de desarrollo nuestros. Muy bueno el curso!" (Gaston)




15 de junio de 2012

14 de junio de 2012

¿Cansado del Planning Poker? 4 alternativas


La única técnica de estimación relativa aplicada que pude constatar en equipos que trabajan con practicas ágiles es el Planning Poker (con contadas excepciones). Para más información sobre estimaciones relativas y Planning Poker recomiendo la presentación Agile Estimating (Moutain Goat Software) y/o el libro Agile Estimating and Planning (Mike Cohn).

Si bien me parece una técnica fantástica por su simplicidad y su aspecto lúdico, vi y apliqué otras técnicas de estimación relativa valiosas. También he estado con equipos que llegan a cierto nivel de cansancio o rutina nefasta luego de estimar con Planning Poker decenas de iteraciones.

Quiero enumerar 4 otras técnicas de estimación relativa que en mi experiencia funcionan muy bien en equipos ágiles:

1. T-Shirt Sizing

Esta técnica se utiliza para clasificar items de trabajo entre si según un orden de magnitud. Se suele usar únicamente 5 medidas que representan el esfuerzo de trabajo para cada item: Extra Small (XS), Small (S), Medium (M), Large (L) o Extra Large (XL). Una persona o grupo define cual de las medidas corresponde a cada item, comparando items entre si. Culturalmente las medidas son muy conocidas e ilustrativas, con lo cual los resultados de estas estimaciones suelen ser bastante explicitas.

Referencias: What Size Are You? Experimenting with T-Shirt Sizes in Story estimationT-Shirt Sizing to Estimate Development Effort in a Software Project



2. Swin-Lane Sizing

Esta técnica es buena para equipos con poca experiencia en estimaciones relativas. Usando un tablero con swinlanes marcadas (columnas), se ubican los items a estimar en las columnas según su complejidad relativa: las más simple en las columnas de izquierda, las más complejas en las columnas de derecha. Con todo un procedimiento en varios pasos, se logra un consenso y una valoración de la complejidad de cada columna que sirve como estimación de los items.

Referencias: Swimlane Sizing – Complete & Fast Backlog Estimation, Reunión sobre Estimaciones de la Comunidad Agile de Neuquén (08/05/2012)

3. Affinity Estimating

Esta técnica (cuyo origen rastree hasta Lowell Lindstrom) tiene muchas similitudes con la de Swin-Lane Sizing. En equipo se trabaja en ordenar en silencio (!) items en una secuencia de acuerdo a su complejidad relativa (por ejemplo con post-its en el piso). Luego en varios pasos se revisa, refina, consensua y asocia valores a cada items. Este mecanismo permite estimar grandes cantidades de items en poco tiempo.

Referencias: Guest Post: Affinity Estimating – A How-ToSCRUM TRAINERS GATHERING (4/4): AFFINITY ESTIMATING



4. No estimar

Finalmente, y como se lo esperaban los que me conocen, una muy buena alternativa al Planning Poker es dejar de estimar (!!!). He tratado de explicar algunos problemas que tenemos con estimaciones (acá, acá y acá), y creo que hay una forma de trabajar que permite no estimar (en el desarrollo de software por lo menos. Les dejo la referencia a una charla que di en varios eventos sobre el tema.

Referencias: ¡No estimarás!

¿Han usado estas técnicas? ¿Con que resultados?
¿Que otras técnicas de estimación relativa recomiendan?

11 de junio de 2012

8 de junio de 2012

7 de junio de 2012

Retrotip #1


Serie de retrotips














En breve voy a empezar una serie de posts de tips para retrospectivas, y quería primero explicar un poco el concepto.
  • ¿Por qué?

Me sorprendió gratamente el interés despertado por la sesión de "Dinámicas y Tips de Retrospectiva" del Open Space del Scrum Gathering Buenos Aires 2012, que moderé en conjunto con Andrés Mumenthaler.

Este interés me motiva para empezar una serie de breve posts sobre tips de retrospectivas, al estilo de la serie #consultip de Ernesto Kiszkurno (¡Gracias Ernesto!).

  • ¿Retrospectiva?

Tengo una pasión por los mecanismos de retrospectiva, que considero como una de las herramientas más potente del trabajo en grupo. Me inspiro de varias personas/libros/sitios, en particular: Agile Retrospectives: Making Good Teams GreatProject Retrospectives: A Handbook for Team Reviews, George DinwiddieAgile Retrospective Wiki y Scrumology.


Me gusta en particular esta definición  de retrospectiva de Diana Larsen:

"Una reunión especial  en la cual un equipo decide hacer una pausa para reflexionar sobre el trabajo realizado, ver qué lecciones pueden capitalizar y decidir cómo aplicar lo que aprendieron en el futuro cercano."
  • ¿Que busco?
1. Compartir experiencias y aprender con ustedes
2. Motivar a algunos para que empiecen a hacer retrospectivas 
3. Ayudar a algunos para que puedan mejorar sus retrospectivas
3. Erradicar del mundo (ágil) las retrospectivas rutinarias que pierden su razón de ser

Espero que sea larga y útil...