jueves, 26 de marzo de 2009

Ingeniería o Artesanía v1


Hace tiempo que se trata de encontrar una analogía al desarrollo de software. Es un arte, una ciencia, un conjunto de técnicas,...
¿Por qué es esa discusión interesante?
Porque siendo el software una actividad relativamente joven, buscamos utilizar la experiencia existente en otras actividades, por ejemplo para copiar como enseñamos, como organizamos el trabajo y como lo evaluamos.
Diego Fontdevila, Pablo Rodríguez Facal, Vanesa Dell'Acqua y Juan Gabardini nos reunimos en una sesión de Agile Open Buenos Aires 2009 para hablar de estos temas, y estas son nuestras notas.

¿Por qué buscamos la analogía?
¿No podemos simplemente admitir que el software es distinto y analizarlo per se, sin buscar analogías?
Podemos, pero cuando se trabajan con nuevos conceptos, ni siquiera tenemos las palabras para describirlos, lo que hace difícil pensar y discutir sobre ello.
Por ejemplo, Philosophiae Naturalis Principia Mathematica de Newton no es el libro que usamos para aprender física o cálculo matemático. A lo largo de los años se ha mejorado el lenguaje y la forma de explicar los conceptos.
Si logramos una buena analogía, podemos usar el lenguaje y modelos mentales ya probados.

Micah y Bob Martin proponen la idea de artesanía (video en Ágiles 2008 y manifiesto).
Artesano u Operario
Creemos que la analogía se basa en la comparación de las personas que fabricaban artefactos complejos de manera artesanal, a fines del 1800 o principios del 1900. Podemos comparar a estas personas que fabricaban artesanalmente relojes o automóviles versus el operario en una linea de montaje tipo Taylor/Ford.
El resultado del trabajo del artesano es un artefacto de complejidad considerable pero se producía de forma artesanal debido a la falta de la tecnología que permitiera automatizar los procesos (y porque Ford y Taylor todavía no habían metido la cuchara, je).

Pero es útil comparar al desarrollo de software con la fabricación?
Que analogía usamos:
- producción (silla hecha a mano vs silla hecha en linea de producción)
- diseño (diseño de la silla
vs cuadro o escultura de la silla)
- ingeniería civil (diferencias entre el diseño del edificio y el obrero que lo construye - en nuestro entorno el compilador es el "obrero" mientras que cuando programamos estamos haciendo "diseño"). El problema de esta analogía es que en general cuando hablamos de ingeniería civil estamos tratando con un entorno medianamente estático (la estructura del terreno donde se construye un edificio se considera constante) mientras que en software, el entorno cambia permanentemente, cambian las reglas de negocios, las regulaciones y legislaciones, los usuarios, etc.

En muchos casos, parece que el desarrollo de software se parece más al diseño de productos que a la producción repetitiva de los mismos.

Acá tenemos una primera conclusión: si comparamos entre el artesano y el operario, ¡el desarrollador es artesano!
Esta definición no es poco, cuantas veces nos encontramos con formas de trabajo en las que el programador sólo implementa lo que definió el diseñador, que a su vez se basó en lo que dijo el analista.

Ingeniero o Artesano
Esta comparación es más difícil, y cada uno tiene en su cabeza definiciones distintas de Ingeniero y Artesano.

Artesanía: Consiste en la construcción o producción de un objeto complejo, pero el balance de entre resultados y costos es en general desfavorable ¿?
Ingeniería: Consiste en resolver problemas
complejos, siempre con un balance o compromiso entre los resultados y los costos.
Artesanía -> ¿Técnica? Algo hecho directamente por las manos
del hombre con herramientas.
Ingeniería -> ¿Tecnología? Algo hecho indirectamente por las manos del hombre con máquinas capaces de
repetir su trabajo.

¿Open Space es una tecnología o una técnica?
Orgullo de lo producido
Cabe a ambos, el artesano y el ingeniero, en función de su identificación con el producto de su trabajo.
Produce una de las condiciones fundamentales que es la satisfacción con el trabajo por el trabajo en sí. Puede ser conflictivo si implica que tome precedencia sobre la percepción de valor que tiene el usuario final o el cliente.
En ambos casos hay criterios estéticos y de elegancia, aunque no necesariamente compartidos con el usuario. Un ejemplo: para algunos las ecuaciones de Maxwell son elegantes y tienen la belleza de la simetría. Otro ejemplo, en las artes marciales, cuanto más se sabe, menos movimientos se requieren.
¿Están menos orgullosos los ingenieros que participaron en el diseño y construción del Alfa Romeo 8C Competizione que lo que estaría un artesano?
Entonces, ¿cuál es la diferencia?

Separación entre la creación y el producto final
Una posibilidad es que la diferencia esté en la distancia con lo "real", distancia semántica (usamos distintas palabras, distintos idiomas).
Un artesano conoce bien las herramientas, el material con el que trabaja, el producto que realiza. El ingeniero puede hablar el idioma científico para tomar novedades que pueda aplicar en forma novedosa. Puede tener una mayor capacidad para manejar distancia semántica. Pero eso conlleva el riesgo de alejarse del día a día.

El equipo y el especialista
¿Qué sabe cada uno? ¿Qué parte de lo que sabe se pone en juego en el trabajo conjunto? El equipo es un espacio común definido por un espacio físico (
Gemba, en japonés el "Lugar real" donde se produce valor) y un lenguaje común. Este lenguaje limita los conceptos que pueden manejarse (pensamos con las palabras que tenemos a nuestra disposición). Un ejemplo de lenguaje común es el que se desarrolla cuando los integrantes del equipo aprenden del negocio. Sin embargo, muchas cuestiones propias de los especialistas quedan fuera.
El problema aparece cuando ese lenguaje no es capaz de describir todo lo necesario (lógica, comportamiento, interfaces, etc.) En el futuro, es posible que se desarrollen lenguajes propios de cada dominio de problema, o que se formalice el lenguaje del equipo para soportar tanto el negocio como la lógica del software.

El compromiso es aprender, es decir expandir siempre los límites de nuestra ignorancia, alejando a cada paso el horizonte de lo que hay por aprender. ¿Cómo aprende el equipo? Como en Toyota, podrían seleccionarse responsables de aprender o desarrollar ciertos temas o capacidades (costos, calidad, seguridad, etc.) y cada cierto tiempo rotar esas responsabilidad. Este sistema funciona muy bien para temas que escapan a la especialidad de todos los miembros del equipo.

Y nuestra segunda conclusión: todos tenemos que conocer las herramientas, nunca alejarnos mucho del gemba, y quizás somos ingenieros si nos preocupamos en diseñar no sólo el producto, sino también mejorar o crear nuevas herramientas.

¡Da para más! ¿Cómo impacta en la educación? ... lo seguimos en el próximo Agile Open

sábado, 14 de marzo de 2009

Finalizando una stand-up meeting


Fowler tiene un buen artículo sobre las stand-up meeting (o daily scrum). Una de las cosas que recomienda es que se marque el final de la reunión claramente .
El hecho de marcar claramente el final:
  • Facilita que la reunión se mantenga acotada: hay personas con fobia al vacío, y que tienen tendencia  a llenar el vacío con palabras. Ante los segundos de silencio antes de ir a nuestros lugares de trabajo, estas personas encuentra siempre un tema más que es necesario resolver ahora
  • Mantiene la energía: el equipo reunido genera mucha energía, al separarnos, parte de esta energía se pierde. Marcando el final, transferimos esa energía, esa urgencia de hacer, a la próxima tarea que encaramos.
  • Nos une. Los pequeños rituales ayudan a identificarnos como equipo.
En un equipo en el que estuve marcabamos el fin de la Stand-up Meeting con 3 aplausos sincronizados. Un compañero de equipo de esos tiempos (Pablo Molinelli) hace poco me recordó esta práctica y me preguntó de donde salía.
Viene de la cultura japonesa y es usada en los círculos de calidad. 
Estoy hablando del Tejime, la práctica de finalizar una reunión con golpes de palma con una secuencia particular.
La forma tradicional pueden aprenderla en este video, aunque nosotros usábamos una forma ligeramente distinta:
  1. Cuando el último había hablado (las 3 preguntas), alguno preguntaba "Estamos?" o "Listo?" , poniendo las dos manos listas como para aplaudir.
  2. Si no había respuesta rápida, dabamos 3 golpes de palma, y con eso terminaba la reunión.
Viendo ahora la forma tradicional, incorporaria el "Yooo...", ya que teníamos problemas sincronizandonos. 
Además, podría extenderse a otras reuniones, pero al no ser algo entendido culturalmente, hay que manejarlo con cuidado. En nuestro caso dio para malos entendidos y se extendió en forma extraña a otras partes de la organización, pero eso es para otra historia!



jueves, 12 de marzo de 2009

Testers en entornos ágiles

En una de las sesiones en las que participé en Agile Open Buenos Aires 2009 nos reunimos unas 15-20 personas y comentamos sobre como participan los testers en equipos ágiles.
¡Qué tema! Me apasiona, y me lo tomaba mal, hice algo para cambiar. y ahora estoy un poco más tranquilo (Dilema de los testers).
Justamente iniciamos la sesión y para abrir el juego, comenté lo que considero es el Dilema de los testers: Tenemos que trabajar y ayudar al equipo para lograr que el testing (tradicional, al final del desarrollo) ya no sea necesario.

A partir de ahí, tuvimos un intercambio de dudas, experiencias y opiniones, no necesariamente logramos consenso, pero fue muy interesante. Algunos de los ejes de la discusión fueron (ver la imagen):

Perfil de los testers
¿Tiene un tester un ambiente ágil que saber sobre tecnología?
Parece que sería bueno (en eso hay concenso) pero es necesario?
Un tester técnico se integra más fácilmente con un equipo de programadores, pueden más fácilmente tener un leguaje comun y es más factible que participe en la automatización de las pruebas. Puede aportar en las pruebas técnicas, mejora su participación en pares, ...

Selección
Todo bonito, pero ¿existen esos testers? En general vemos que los procesos de selección no los encuentran, y quizás no haya muchos. Una hipótesis es que las personas con interés en lo técnico se hacen programadores/diseñadores/arquitectos, ya que es más redituable en el mercado actual. El mercado lleva a que estos perfiles sean rara avis, ni siquiera se consideran en las clasificaciones de puestos en los anuncios, lo que dificulta que se pongan en contacto las empresas que necesitan con las personas correctas.
Algo de eso comentamos en un thread del grupo de desarrollos ágiles en español.

Homologación
No le dimos mucho tiempo, pero surgió el tema de los grupos de testing fuera del grupo de desarrollo, y como se maneja este caso. Estos grupos consisten en algunas experiencias en ex-usuarios, que conocen muy bien el negocio y el día a día, por lo que son muy buenos proxies de los usuarios reales (si se mantienen actualizados), como aprovechar ese conocimiento?

Tester como Analista/Product Owner
Una forma de aprovechar los conocientos de negocio es que los testers sean parte del equipo de P.O. o desde el equipo de desarrollo, interactuen con los P.O. para lograr que los temas de usabilidad y detalles del negocio estén en las condiciones de aceptación de las historias.

Volvemos al perfil
Si las personas con perfil de testing no son técnicos (como los casos considerados arriba), como los incorporamos para que sean más efectivos al team? Con herramientas que permitan que personas no técnicas definan casos de prueba (se comentó Quality Center y FitNesse), y la otra es que trabaje en pares con programadores. Una preocupación que surgió es que tanto FitNesse y el trabajo en pares consume tiempo de los programadores. 

Compromiso a nivel equipo
Si los progamadores "pierden tiempo" ayudando a los testers, esto huele (smell) a que falta Compromiso a nivel equipo (Whole team commitment). Si no se considera que el resultado del equipo es el producto con las pruebas que sean, cualquier tarea (prueba) u obstaculo (falta de conocimiento técnico de alguno de los miembros) es algo que el equipo completo debe resolver. No es un problema de "los testers".

Equipos con roles
Otra cara de la moneda es el uso de herramientas de automatización que hacen record& play o tienen lenguajes propietarios fáciles (VBScript). No hubo concenso. Algunos comentaron que lo usaban y les funcionaba. Otros creemos que las herramientas de record& play no pueden usarse para generar casos de prueba automatizados robustos. El costo cuando (no si) hay cambios en la aplicación es demasiado alto. Se debe ir a casos de prueba que sean resistentes a los cambios de la aplicación, y eso es dificil de lograr sin tener los casos implementados con algún tipo de lenguaje (no la salidad directa del record). El caso de los lenguajes propietarios tiene varios problemas: mayor costo de aprendizaje, aumenta el riesgo de que un problema con un miembro del equipo afecte la capacidad de finalizar, aumenta posibilidad de cuellos de botella y en general dificulta la formación del Compromiso a nivel de equipo. Sin mensionar que los lenguajes propietarios suelen ser restringidos y no facilitan que se haga código de calidad, robusto.

Impacto de no lograr el Compromiso del equipo
Si los programadores consideran que las pruebas corriendo y verdes no son su problema, pueden hacer cambios en el producto que causen que muchas pruebas se rompan, si considerar el costo de poner nuevamente en funcionamiento las pruebas. Si en cambio lo consideran algo que los afecta, se preocuparán en que las pruebas sean código de igual calidad que el resto del código del producto, para que sea más robusto, extensible, etc. Eso es bueno, ya que los testers no son los mejores preparados para lograr código de calidad. En este caso, surge naturalmente que los programadores preferirán usar las mismas herramientas para el código de prueba que para el resto del código.

Quedaron temas pendientes
¿Cómo se hace en el caso de software embebido? Buscar Nancy Van Schooenderwoert

Mi resumen
Necesitamos equipos con todos los skills. Ojalá tuvieramos miembros que entiendan del negocio y conozcan la tecnología de la solución y sepan probar y tengan en cuenta usabilidad y ...
Cada equipo es particular, por lo que hablar del "rol de tester" es sólo una abstracción... salvo que la persona que cubra ese rol sale de un mercado que tiene cierta demografía. Por lo tanto si no encontramos personas para cubrir ese rol definido como {conocimiento de técnicas de testing, conocimiento del negocio, afinidad técnica sin ser experto} podemos cambiar la definición del rol o cambiar la demografía.


lunes, 9 de marzo de 2009

Popurri de Herramientas

En una de las sesiones en las que participé en Agile Open Buenos Aires 2009 nos reunimos unas 15-20 personas y comentamos las herramientas que usamos o que conocemos.
Como siempre, tuvimos que terminar con la campana (no es una metáfora, Alan Cyment, el moderador, usó una campana Tibetiana para marcar el fin e inicio de las sesiones!). Yo había pensado comentar 6 herramientas, comenté sólo 2.

El resultado, aparte de lo que nos llevamos como interacción, fue:
1- Listas de herramientas, con comentarios sobre para que sirven (ver fotos).
2- Decisión de ir subiendo esta información a agiles.org, y agregar referencias a otros sitios de herramientas, como http://www.userstories.com/products
3- Preview del proyecto FLOSS Agilar taskboard, que busca implementar las ideas de Visual Management de Xavier Quesada Allue.

Posteo las fotos de la sesión. Si alguien puede ayudar a pasarlo al formato y completar contenido para subirlo a la página, por favor que me avise.



Y se comentó sobre manejo de versiones en bases de datos, herramientas como el Migrate de RoR, y un plugin para MS SQL 2008 que mantiene versiones en SVN / SourceSafe.

domingo, 8 de marzo de 2009

Agile Open Buenos Aires 2009 - el día después

Ayer tuvimos un evento con mucho entusiasmo y energía. En los próximos días, todos los asistentes iremos volcando nuestras experiencias, fotos y videos.
También espero que podamos intercambiar algunas ideas sobre lo que salió mejor y lo que podría mejorarse (retrospectiva, le llaman algunos).

Algunos datos del evento (Aún no procesamos las encuestas):
Algunas impresiones personales:
  • Gracias! a los sponsors: SABRE, UNTREF, Epidata consulting y Agilar. Cada uno a su manera hicieron posible que se realizara el evento.
  • La planificación funcionó. Increiblemente, y en forma aprentemente caótica, casi 100 personas propusieron, se organizaron, fusionaron sesiones, aulas, horarios, entre las 50 sesiones propuestas para ocupar 7 track y 5 franjas horarias. Lo esperable con un evento Open Space
  • Siempre aprendí, en todas las sesiones. Al decidir a cual ir o en cual quedarme, el problema era en cual aprendería más.
  • Las aulas resultaron muy cómodas, y nos facilitó disponer de tantas como necesitamos.
  • El espacio para los breaks era muy estrecho, eso dificultó parte del networking. Aún así conocí mucha gente interesante.
  • La necesidad de cobrar en la entrada generó retrasos y complicaciones.
  • El cierre fue raro, corto. ¿Es siempre así? ¿Estábamos cansados?
En el video se ve la realización de un Fishbowl sobre contratos ágiles

 Seguirán otros post sobre esta rica y multifacetica experiencia

jueves, 5 de marzo de 2009

Agile Open Buenos Aires es mañana!

Que espectativa!

Mañana comenzamos el evento Agile Open Buenos Aires 2009, el primero en el Agile Open Tour (Bs As, Córdoba, Tandil, Rosario), y las expectativas están subiendo.

Por lo pronto ya tenemos más de 100 confirmados (sobre 190 interesados). Hicimos un esfuerzo para que no quede gente afuera. Confiamos en que todos los asistentes, con la ayuda de los facilitadores (Alan Cyment y Xavier Quesada Allue) vamos a ser creativos y lograr un gran evento.
Vendrán personas de España, Belgica, y de Córdoba, San Juan, La Plata, Tandil, Rosario, ...; de empresas nacionales, internacionales, del Estado, de las Universidades.

Si querés, todavía podes inscribirte.

Increible que se pueda organizar un evento de este tamaño con dos meses de aviso, y dos meses de vacaciones. Creo que es una indicación del interés y la fuerza que tiene este tema.

Nos vemos allí!