martes 14 de julio de 2009

Scrum en INTI

Recientemente facilitamos (junto con Pablo "Bauna" Nussembaum), un curso de dos días sobre Scrum, en el INTI. Pueden ver la presentación.
Algunas de las actividades que hicimos:
  • La ronda o el nudo (de autoorganización, ver la descripción en inglés)
  • Hacer un folleto del spa de perros (simulación de tres iteraciones con una sola presentación al usaurio, copiado de Jeff Sutherland)
  • Estimación de paises (estimación, tomado de Mike Cohn, similar a Doggy Planning)
  • Pajarraco (simulación de desarrollo iterativo e incremental, con 3 iteraciones con revisión del producto por el usuario, y nuevos requerimientos al inicio de cada iteración, tomado de Alan Cyment)
  • Retrospectiva (sobre el pajarraco, detectar problemas y sugerir mejoras).
Como siempre, la actividad que se lleva todos los elogios es el Pajarraco, con los grupos tomándose fotos con el producto. Un rasgo muy importante, creo que demuestra que hacer el producto fue divertido o que están orgullosos (o las dos cosas) y tienen ganas de compartirlo con otros. Ese es el sentimiento que buscamos que tengan todos los equipos.

Usamos también la idea de postear las preguntas. Este punto no funcionó muy bien. Creo que lo que faltó es un momento específico para revisarlas y contestarlas.

Por otro lado, hubo muchas preguntas, que fueron complentando el contendido del curso, sin necesariamente seguir el orden de la presentación. Me llevo la fuerte idea de reducir presentación y hacer mucho más foco en la dinámica y actividades del curso.

lunes 13 de julio de 2009

Artful Making

Al pensar usamos nuestro lenguaje. Así el lenguaje limita lo que pensamos o al menos podemos decir que es mucho más dificil manejar conceptos o abstraciones sobre los que no tenemos palabras apropiadas. Cada tanto tenemos la suerte de agregar nuevas palabras a nuestro lenguaje, que nos permiten expresar más sencillamente algo que teníamos dando vuelta en la cabeza.
Esta vez me pasó con el libro “Artful Making”, de Rob Austin y Lee Davin (pueden ver gratuitamente el
prólogo y capítulo 1).
Este libro, entre otras cosas, me dió las palabras-conceptos Artful Making e Industrial Making. El nuevo modelo mental es poderoso (“Mindbending” dice Kent Beck). Me hicieron replantear parte de mis ideas CMMI y Agile con resultado parcialmente reflejado en parte 1, parte 2.
Artful making es el proceso de creación de valor en el cual la innovación es un factor importante. Pero no siempre se puede o no siempre es bueno. Los ejemplos dados son la preparación de las obres teatrales, el desarrollo de software y la planificación estratégica. Pero es probable que estas ideas sean aplicables a la mayoría de los trabadores del conocimiento, simpre que se den condiciones necesarias. Y la tendencia es que los trabajos son cada vez más asimibles a trabajo del conocimiento.
Industrial making es el proceso de creación en el que se replica lo hecho, mientras que en artful making se reconcibe, nunca se hace lomismo. Es la forma en que se trabaja en las fábricas.
¿Cuáles son las caracteríaticas para poder hacer artful making?
Necesidad innovación
Iteraciones cortas: esto implica que sean baratas. El costo de iteración tiene dos componentes:
Exploración: probar caminos y soluciones alternativas. En una automotríz podría ser hacer un nuevo modelo a escala o un prototipo de un nuevo modelo.
Reconfiguración: cambiar el producto/proceso para mejorar el producto u obtener otro producto. Por ejemplo, en una automotriz, los cambios necesariose en las herramientas, layout, etc. necesarios para producir otro modelo.
Repeticiones confiables.
También es interesante descripción y progresión descripta (con justificación económica) entre la forma de trabajo del artesano medieval, del ingeniero de procesos industriales (“white collar”) seguidor del scientific management, y por último, el trabajador de conocimiento, con sus puntos de contacto con el trabajo de los artistas. Tendría que revisar el post que hicimos hace unos meses sobre Ingeniería vs Artesanía.
Hay que tener en cuenta que el público objetivo del libro son los gerentes, de ahí el subtítulo “What managers need to know about how artists work”. Para ver la realción de la innovación con las personas que hacen el trabajo, es más apropiado el libro Free Play.
Hay algunos conceptos del libro que resuenan en la forma en que Tobias Mayer y Alan Cyment realizan las capacitaciones CSM. Y no es extraño, ya que ambos tienen background teatral. Y durante la organización de Ágiles 2008, Tobias se puso en contacto con Lee Davin, para que viniera. Lee estaba de acuerdo, pero lamentablemente no teníamos dinero confirmado en el momento en que lo hablamos. Volviendo a las coincidencias, la idea de trabajar al límite, sentirse ligeramente incómodo. No tan incómodo como para trabajar stressado y tan cómodo como para caer en la complacencia y no mejorar.
Otro punto que me parece muy bueno es el control liberando (Control by release), un concepto complejo de entender y transmitir. Creo que está bien implementado en Scrum: definir claramente los objetivos (tema e items en el backlog), imponer ciertos límites (iteraciones de duración fija con entregables definidos y calidad de producción) y dejar libre al equipo.

Muy recomendable, ¡sobre todo para lo gerentes!


Gracias, Diego Fontdevila, por prestarme el libro!, pero si lo queres comprar ...

viernes 10 de julio de 2009

alt.net Argentina 09

Carlos Peix y Martín Salias catalizaron el inicio de Alt.NET en Argentina. Esta es una movida interesante, y en alguna medida, paralela a los Agile Open.
Las reuniones de Alt.NET son en formato Open Space, igual que los Agile Open, pero la temática es distinta. Son reuniones de gente que desarrolla con la tecnología .NET, pero sin ser "guiada" por Microsoft.
Microsoft Argentina ofreció las oficianas, pero el resto fue todo comunidad. Carlos y Martín están muy relacionadas con el Microsoft User Group (MUG).
No pude asistir, pero me comentaron que salió muy bueno. Algo genial de este evento es que lograron hacerlo más JIT que los Agile Open: pidieron pizzas, tomando en cuanta cuantos asistentes había. Ese tema aún no lo tenemos resuelto en los AO, pero no se si se puede, ya que con eventos más grandes es más complidado.

Pueden ver algunas fotos del evento en el blog de Leo Micheloni, y más aquí.

Y si quieren formar parte de la comunidad, pueden sumarse en http://groups.google.com/group/altnet-argentina

miércoles 8 de julio de 2009

Intro al testing en SADIO

A mediados del mes pasado di un curso sobre Introducción al Testing en SADIO.
Como siempre me pasa la primera vez que organizo cursos con alguna entidad, y a pesar de todas las experiencias previas (SADIO nos ayudó mucho en la organización de Ágiles 2008), antes del curso tenía cierta ansiedad por ver la convocatoria, que tipo de gente participa, cómo es la organización y logística del evento, etc.
Por suerte, la organización estuvo muy bien, y la convocatoria fue muy buena. Encontré a algunos comocidos, pero a muchos desconocidos, lo que es bueno! Todos muy entuciastas y comprometidos. Gente de Gral. Pico, de Córdoba, de La Plata, y por supuesto de la Cdad. de Buenos Aires. Muchos testers, algunos desarrolladores. Una pena que la gente de Córdoba no conocía al Lab de Calidad del INTI, y los cursos que dan sobre testing. Una muestra (y van ...) que los testers no tenemos una comunidad. Los pocos cursos que se dan los conocen pocas personas.

En lineas generales, el experimento salió bien. Pueden ver las transparencias y el código.
En cuanto a contenido, creo que debería haber recortado cantidad, en favor de más ejercicios. Dos días con mucha presentación se vuelve aburrido. Aún así, tuve que saltear contenido.
El códido está con NetBeans, junit, emma, y Marathon. Es el caso ultra simple de los triángulos, que usamos para hacer un brevísimo TDD (junit), mostrar cobertura (emma) y realizar pruebas automatizadas desde GUI (Marathon).

Hicimos el juego del Pajarraco, y como siempre, sirvió a su cometido: ser una referencia para todo lo que vimos después.

No me quedé conforme con la presentación de los temas de cobertura. Quedó como una presentación teórica, dada a las apuradas. No logré lo que buscaba, una herramienta y demostración sobre el valor adicional que podemso tener los testers.

Tampoco dió el tiempo para hacer prácticas sobre pruebas exploratorias, algo que me hubiera gustado.

Veremos si cambio un poco para Rosario (Agosto). Y después vienen los cursos de Automatización, en FIUBA (si logro organizarlos) y en Rosario, también con el Lab de Calidad del Polo.

viernes 3 de julio de 2009

Ágiles 2009 - Llamada a Participación

Qué opinas de formar parte del equipo de expositores que reune nombres como Brian Marick, Diana Larsen, Matt Gelbwaks, Naresh Jain, Dave Nicolette, Joshua Kerievsky, Alan Cyment, Alexandre Magno, entre otros? El próximo lunes 6 de julio será la última oportunidad para presentar tu propuesta de charla en Ágiles 2009!

Ágiles 2009, a realizarse en Florianópolis, Brasil, es un evento sin fines de lucro, organizado por profesionales entusiastas del tema, unidos por el objetivo de crear un espacio amplio de discusión sobre las metodologías ágiles y su adopción en América Latina. (más información)

Como expositor, tendrás acceso libre a la conferencia y otras ventajas que los organizadores están preparando para ti! Puedes proponer una presentación, un tutorial, un reporte de experiencias o un workshop. Accede a http://www.agiles2009.org/es/submissions.php para ver la información que debes proporcionar para presentar tus propuestas.

¡Esperamos contar contigo en Ágiles 2009!

Organizadores de Ágiles 2009
Agiles 2009 es organizado por OnCast y es posible gracias a nuestros sponsors
[Silver Sponsor]
Baufest | Scrum Alliance | Agilar | AdaptWorks | Industrial Logic

[Institutional Sponsor]
SADIO | Agile Alliance

sábado 27 de junio de 2009

Panel CMMI vs Ágil (2/2)

Voy a comentar algunas de las preguntas que nos hicieron al panel (parte 1: resumen de las presentaciones del panel) y algunos pensamientos y situaciones que tuve luego del evento.

asistente: ¿Puede aplicarse ágil en grupos grandes?
yo: ¿qué es grande para vos?
asistente: El sistema de defenza de China
(no conteste, alguien más lo hizo)

Ugh? ¿acaso estaría esa persona en ese equipo? ¿si no, que interés práctico puede tener una pregunta así? Mi hipótesis es que hay una suposición subyacente: lo que es bueno a un proyecto enorme, debe ser bueno para un proyecto chico. Según esta hipótesis, los problemas de escalamiento sólo se darían al agrandar, no al achicar.

asistente (otro):¿cómo logro con ágil que todos los equipos trabajen en forma similar?
yo: ¿Por qué querés que trabajen en forma similar?
asistente: la compañía tiene que tener una forma definida de hacer las cosas
yo: ¿Qué valor de negocio tiene eso? (y comenté el caso de Toyota, en el que cada planta que hace el mismo vehículo tiene layout diferentes, y cada uno es óptimo en cuanto a condiciones locales)
asistente: pero los trabajos que hacen deben tener algo en común ...
(perdí la atención del asistente, y el hilo del diálogo fue hacia otro lado)
¿Por qué la unificación de las formas de trabajo es visto cómo una verdad indiscutible?

La semana pasada estábamos en una clase de la facultad, en la simulación de una retrospectiva. El problema a resolver era: requierimientos muy cambiantes.
alumno: una mejora sería "estandarizar el proceso de elicitación de requerimientos"
yo: ¿Por qué te parece que esto resolvería el problema?
alumno: está muy estudiado como deben obtenerse los requerimientos. Deberíamos incorporar esto a los procesos.
yo: ¿Pero eso ya se hace en la compañia?
alumno: ...
yo: Digo, porque si decimos que queremos estandarizarlos es porque en algún área o grupo ya se están aplicando y queremos llevarlo a otros, no?
alumno: ...
yo: Si no se usaron nunca, quizás debiérmos probarlos en algún grupo, antes de estandarizarlos
alumno: (cara de no estoy de acuerdo con lo que decis pero sos el docente)
Ya no es sólo la unificación dentro de una compañia, sino la unificación a nivel industria. Implísita está la idea de que debe haber sólo una forma de manejar los requerimientos.

Paréntesis
Recientemente me prestaron Artful Making, espero postear más extensamente sobre el libro, pero para este post basta con comentar que los autores plantean que hay dos formas de hacer las cosas: Artful Making, muy ligada a la innovación, con costo de iteración y de error bajo (ejemplos: teatro, software, estrategias corporativas); e Industrial Making, que es lo que ha tenido tanto éxito (revolución industrial), que nos parece como natural e innegable (producción en serie, economía de escala).

¿Qué encuentro en común en las sitiaciones descriptas arriba?
La idea de "la mejor solución". Esta es una visión Taylorista, en la que alguien pude analizar el problema y encontrar la mejor forma de hacerlo. Por lo tanto, los operarios deben seguir al pié de la letra esa solución, ya que es la mejor.
Esto tiene dos problemas: por un lado, si estamos en una situación que permitiría usar Artful Making, lo estamos perdiendo. Por otro lado, si estamos en una situación de Industrial Making, nos quedamos con métodos de principios del siglo XX. Todo lo aprendido a partir de los '60 por los japoneses, y a partir de los '80 por el resto del mundo, no lo aplicamos: Lean Production.

¿Es esto un problema?
¿Es un problema que algunas personas mantengan la idea de "la mejor solución"? Vuelvo sobre mi post CMMI y Agile, y le doy otra vuelta de tuerca, porque voy a tocar el proceso de evaluación.
En una charla con Mary Poppendieck, ella comentó los efectos nefastos y no deseados de las certificaciones: se incian tomando las buenas prácticas, se estandarizan, se instruye a los evaluadores y se los controla para evitar desvios y subjetividades, esto pone restrincciones externas a las empresas, que para no perder su status (certificación) establecen áreas internas que replican la idea de evaluadores que controlan el cumplimiento.
Todo esto genera una gran inercia. Si una empresa quiere innovar tiene que convencer a sus auditores, que tendrán que convencer a los evaluadores, que tendrán que convencer al organismo originador del estandar.

En el panel, yo noté exactamente esa dinámica. El movimiento ágil se desarrolló casi totalmente fuera del alcance del SEI y las empresas CMMI. Luego que tomó fuerza, se hizo notorio que es algo bueno, por lo que muchas empresas emprezaron a usarlo y el SEI se puso a trabajar (luego que las ideas llegaron al mainstream) en mostrar que CMMI no es incompatible con Ágil. Y ahora está tratando de convencer a sus evaluadores de esto (y le cuesta).

Replanteando la pregunta, ¿será que por construcción el CMMI refleja el mainstream, lo común, y no fomenta la innovación?
¿Puede incorporar el estado actual de las prácticas ágiles, pero inmediatamente lo congelará como el nuevo estándar, sólo para ser superado por las empresas que no son CMMI?

Panel CMMI vs Ágil (1/2)

Hace un mes tuve la suerte de participar en un panel organizado por Liveware sobre CMMI y Desarrollo Ágil.
Asistió mucha gente, creo que con alto porcentaje de gente de áreas de mejora de procesos, y por lo tanta bastate CMMI.
Antes del panel huvo una presentación de Jorge Boria sobre la evolución de la Ingeniería del Software, para poner en contexto la aparición de CMM/I y de Agile Software Development, explicando brevemente Scrum y XP, y relacionándolos con ideas previas. Es muy dificil hacer todo esto en 2 hs, exige un nivel de síntesis muy grande. Creo que Boria logró hacerlo bien. Algunos puntos de Scrum y XP yo los habría comentado distintos, lo que me pasa con cualquier discertante.
Luego fue el panel, muy bien moderado por Alejandra Goldin (Liveware). Sobre el panel voy a comentar mi resumen, y en otro post algunas preguntas que se hicieron e ideas que me surgieron, todo filtrado por mi subjetividad y memoria. Espero que los otros panelistas y asistentes me corrijan.
Esteban Zuttion (Liveware): planteo el enfoque que tanto el modelo CMMI como las ideas ágiles pueden ser útiles en la mejora, y que ser evaluados con cierto nivel de CMMI puede tener beneficios de negocio. Que se hace es una decisión que debe analizarse con respecto a la estrategia de la compañía y las necesidades del negocio, como algo absoluto.
Martín Salías (Southworks): comentó que las prácticas ágiles soportan los objetivos de CMMI, incluso las métricas. Se generan un montón de datos como subproducto de las prácticas ágiles (nro de build rotos, % cobertura, etc). Comentó que en algunos casos no hay métrias pero las prácticas pueden equipararse a métricas (me hubiera gustado que se explayara en esto).
Santiago Ceria (Hexacta): Si uno aplica la típica combinación ágil de Scrum + algunas prácticas de XP logra un buen cubrimiento de los Niveles 2 y 3 de CMMI, en particular Scrum con prácticas de Nivel 2 y XP con las de Nivel 3. Digamos por ejemplo que la cobertura es de un 50%. El tema es que al implementar el resto de las prácticas que pide CMMI, se deben hacer cosas que presentan incompatibilidades con los principios ágiles expresados en el Manifesto. En particular mencioné la cantidad de documentación que hay que generar, el concepto de Quality Assurance que es incompatible con el principio de “trust” y la presencia por todos lados en CMMI de cosas que llevan a una implementación de una organización jerárquica (“senior management”, “Project manager”, “Project leader”, “team leader”) que es incompatible con las estructuras horizontales auto organizadas propuestas por los métodos ágiles.
Juan Gabardini (Agilar): hablé sobre lo extraño que es ver que, partiendo de premisas parecidas (mejoras continua, Deming), se llegan a culturas a primera vista tan distintas. Me pregunto si esas diferencias culturales son compatibles en una misma organización, si una de las culturas se impondrá o si surgirá una nueva cultura que sea la síntesis de ambas. Más detalle de mis 10 min aquí.
Mariela Rodriguez (Globant): después de mi vuelo estratosférico, Mariela comentó la realidad de Globant, en la que se realizan proyectos de desarrollo ágil aún con contratos de tiempo y costo cerrado. Hay reuniones periódicas, se muestra producto y se puede agregar nueva funcionalidad ... siempre que se saque otra. Algunos puntos muy interesantes: no lo pueden hacer con todos los clientes, algunos no quieren esto de reunirse cada mes. Y por otro lado, los equipos que trabajaron agilmente no quieren trabajar de otra forma.
Viviana Rubinstein (Liveware): tomó el guante de Santiago y diferenció claramente entre la evaluación y el modelo CMMI. En su punto de vista, el modelo no tiene conflictos con el desarrollo Ágil, pero la evaluación si. Me encantó una frase: "Cuando algún evaluado empieza a quejarse sobre lo que tiene que hacer (para que la evaluación de cierto nivel) le digo: yo estoy acá porque vos me llamaste"
También refutó a Santiago sobre la obligatoriedad de algunas actividades. No puedo opinar sobre este cruce, no tengo conocimiento. Resumen: si querés ser evaluado, y si, te va a salis más caro que si no lo haces.

Finalmente Alejandra resumió nuestras ideas y rescató la cercanía de las mismas.

Fue muy interesante participar, y me dejó pensando, con los resultados que pueden verse en este post.